Restrict licenses
The Spectra Assure platform identifies a variety of licenses in your software and its components during analysis.
Software licenses define all conditions and requirements for using, modifying, and distributing the software, and are typically legally binding.
Lack of insight into licenses and other software provenance data puts organizations at risk of legal action and reputation damage. Failure to comply with the requirements of a software license, even if the software is used indirectly, negatively impacts the entire supply chain, including an organization's customers, partners, and integrators.
For this reason rl-secure
lets you restrict any unusual or unwanted licenses in your policy configuration.
Depending on your settings, the presence of restricted licenses can raise a warning or even fail the build.
This helps you exclude software dependencies that have licenses incompatible with your organization's practices and requirements.
Licenses in the policy configuration can be controlled either by their individual names or by the license family they belong to.
Therefore, you can modify policy configuration files to:
The approach you'll choose primarily depends on your use case.
Examples in this guide show how to modify the policy configuration for existing projects and packages in a previously created package store. If you haven't yet created any projects and packages, follow the instructions in the quick start guide.
Set the base license tolerance levelโ
Individual licenses are categorized into license families that impose a similar set of restrictions on software development, distribution and usage. If your use-case doesn't require fine-grained license controls, you can allow or disallow entire families of licenses at once by setting the base license tolerance level in the policy configuration. This is a quick way to enforce license compliance in your software projects.
If Spectra Assure detects the presence of any licenses stricter than the configured base license level, the analysis report will show warnings for relevant software components. Spectra Assure can only trigger a warning (SQ12401 policy violation) for license families configured in this way.
The following configuration values are supported for license families, ordered from most to least permissive (top to bottom):
public-domain
permissive
weak-copyleft
copyleft
freeware
shareware
freemium
non-commercial
proprietary
When you configure any of these families as the base license level, the configured family and the more permissive families are considered allowed. Warnings are triggered for license families less permissive than the configured one.
For example, when license_level
is set to shareware
, all licenses in less permissive families (freemium
, non-commercial
, proprietary
) trigger a warning policy.
If you choose public-domain
, license violations are triggered for permissive
and all other license families (weak-copyleft
, copyleft
, freeware
, shareware
, freemium
, non-commercial
, proprietary
).
In this example, our package called my-package
contains components with licenses that might pose a legal risk.
Multiple undesirable licenses are in the permissive
category, but also in other license families (weak-copyleft
, copyleft
, freeware
, shareware
, freemium
, non-commercial
, proprietary
).
We want to call attention to them by issuing warnings in the analysis report.
To do this, we're modifying the policy configuration file for the package.
Specifically, we're telling rl-secure
to look for all licenses in less permissive license families than the one we're allowing, and trigger the appropriate policy.
1. Modify package policy settingsโ
1) In the rl-secure
package store, navigate to the policy configuration file for the package and open it in a text editor.
In this example, the full path to the file we're editing is /home/armando/my-repository/.rl-secure/projects/my-project/packages/my-package/.package_policy.info
.
2) In the .package_policy.info
file, add the license_level
option and set it to one of the supported license families. This determines the baseline for the behavior of compliance-related policies during software analysis. In other words, a warning in the analysis reports will be shown for all dependencies with licenses in less permissive families than the specified family.
policies
{
profile "package_profile"
{
inherit_rules "project_profile"
license_level "public-domain"
}
}
3) Save changes to the file and close it.
2. Apply and verify configuration changesโ
1) To apply your policy configuration changes, run the following command in your package store:
rl-secure sync
The command automatically detects which packages in the package store require synchronization.
Using the sync
command does not count towards the monthly analysis capacity.
2) To make sure the new policy configuration is reflected in analysis reports, you have to regenerate them for all applicable package versions:
rl-secure report all --purl=pkg:rl/my-project/my-package@1.0 --bundle=report.zip
3) To confirm that the policy configuration change has been successfully applied, check the rl-secure
output or the SAFE report (rl-html
) for details on targeted licenses.
Check the CLI outputโ
Use the find command to see whether the expected SQ policy was triggered. The output should confirm that the policy violation is detected in the package for which the configuration was modified.
rl-secure find --term=SQ12401 --purl=pkg:rl/my-project/my-package@1.0
The output should be similar to the following example. It indicates the policy triggered due to the configuration change and shows the details on the targeted license families.
--------------------------------------------------------------------------------
[ MATCHED ] my-project/my-package@1.0
[ SQ12401 ] [ L5:PASS ] <P2> / [M] Severity [H] Effort / (x55)
Detected presence of license families that were marked to issue a
warning.
Violations ---------------------------------------------------------------------
1) samples/testsample
2) samples/test.jar
Check the SAFE reportโ
- In the SAFE report, select Issues from the left sidebar.
- On the Issues page that opens, use the Add Filter button to check for instances of the SQ12401 policy violation (Filter by: Issue > Operator: is > Value: SQ12401).
- If the configuration change has been successfully applied, you will find the relevant policy in the list. Expand it to show files with licenses marked to issue a warning.
- You can then select every file in the list to show more information about it.
Restrict specific licensesโ
Usage of specific licenses in a software project can be fully controlled in policy configuration. Depending on your use-case, you can configure how Spectra Assure will behave when it detects the presence of a particular license in a software component, in a statically linked file, or a file that dynamically links to the specified license. Spectra Assure can trigger either a warning (SQ12402) or a CI fail status (SQ12403) for individual licenses specified by name.
To target a specific license, you must provide its full name (e.g., LGPL-2.1-or-later
) or use pattern matching (globbing) with wildcard characters *
and ?
to specify an inclusive range (e.g., LGPL-2.*
).
You can copy the license name directly from the License column on the Bill of Materials page of analysis reports. The License column displays information in the following format:
License family (License name)
where the license name inside the brackets is an SPDX expression with operators.
You only need to copy the license name, not the whole expression. For example, if the License column displays the following:
Permissive (WTFPL OR MIT)
you need to copy either WTFPL
or MIT
, depending on which license you want to target.
Alternatively, use the reference documentation to look up specific licenses by name and copy the names from there.
In this example, our package called my-package
contains files with licenses that might pose a legal risk.
Since only specific licenses are critical, we can restrict them by their name instead of blocking the whole license family.
We want to call attention to them both by issuing a warning policy (SQ12402) and triggering a failing policy (SQ12403).
The failing policy affects the CI status for the package, while the warning policy does not.
To do this, we're modifying the policy configuration file for the package.
Specifically, we're telling rl-secure
to look for all licenses with that name and trigger the appropriate policies.
1. Modify package policy settingsโ
1) In the rl-secure
package store, navigate to the policy configuration file for the package and open it in a text editor.
In this example, the full path to the file we're editing is /home/armando/my-repository/.rl-secure/projects/my-project/packages/my-package/.package_policy.info
.
2) In the .package_policy.info
file, add the licenses
section.
- In
license
, specify the targeted license. Wildcard matching is supported with the*
or?
characters. In this example,Zlib
licenses, as well as multipleGPL
andLGPL
license versions will be matched, if they exist. - In the same
license
section, setpresent
either to pass, warning, or fail. - The audit information about the author, date and time, and reason for the policy configuration change is mandatory in the
license
section.
policies
{
profile "package_profile"
{
inherit_rules "project_profile"
licenses
{
license "Zlib"
{
present fail
author "Spectra Assure"
timestamp "2023-01-01T12:00:00+00:00"
reason "Targeting specific licenses"
}
license "*GPL-*"
{
present warning
author "Spectra Assure"
timestamp "2023-01-01T12:00:00+00:00"
reason "Targeting specific licenses"
}
}
}
}
3) Save changes to the file and close it.
2. Apply and verify configuration changesโ
1) To apply your policy configuration changes, run the following command in your package store:
rl-secure sync
The command automatically detects which packages in the package store require synchronization.
Using the sync
command does not count towards the monthly analysis capacity.
2) To make sure the new policy configuration is reflected in analysis reports, you have to regenerate them for all applicable package versions:
rl-secure report all --purl=pkg:rl/my-project/my-package@1.0 --bundle=report.zip
3) To confirm that the policy configuration change has been successfully applied, check the rl-secure
output or the SAFE report (rl-html
) for details on targeted licenses.
Check the CLI outputโ
Use the find command to see whether the expected SQ policies were triggered. The output should confirm that the policy violation is detected in the package for which the configuration was modified.
rl-secure find --term=SQ1240* --purl=pkg:rl/my-project/my-package@1.0
The output should be similar to the following example. It indicates the policy triggered due to the configuration change and shows the details on the targeted licenses.
--------------------------------------------------------------------------------
[ MATCHED ] my-project/my-package@1.0
[ SQ12402 ] [ L5:PASS ] <P1> / [M] Severity [H] Effort / (x2)
Detected presence of licenses that were marked to issue a warning.
Violations ---------------------------------------------------------------------
1) samples/testsample
2) samples/test.jar
--------------------------------------------------------------------------------
[ MATCHED ] my-project/my-package@1.0
[ SQ12403 ] [ L5:FAIL ] <P0> / [H] Severity [H] Effort / (x1)
Detected presence of licenses that were explicitly restricted.
Violations ---------------------------------------------------------------------
1) samples/testsample
Check the SAFE reportโ
- In the SAFE report, select Issues from the left sidebar.
- On the Issues page that opens, use the Add Filter button to check for instances of the SQ12402 and the SQ12403 policy violations (Filter by: Issue Category > Operator: is > Value: License Compliance).
- If the configuration change has been successfully applied, you will find the relevant policies in the list. Expand them to show files with licenses you specified in the configuration.
- You can then select every file in the list to show more information about it.