Package Licenses and Compliance

Artifactory requires Xray to manage license compliance using watches and policies to detect package licenses and violations.

Along with vulnerabilities, ProGet uses policies to manage license compliance, letting you control which licenses are permitted and blocked in your development.

This article will cover managing licenses and license compliance with ProGet’s policies.

Licenses in ProGet

Both Artifactory and ProGet have a large, inbuilt database of licenses, curated from a number of sources such as the SPDX License List. Licenses contain basic information, including the SPDX IDs, URLs, and can also embed license files.

License Detection

ProGet detects licenses automatically in both locally hosted and remote packages by analyzing the metadata. It can also identify licenses by package name, version, SPDX, URL or embedded files.

ProGet can also detect unknown licenses in packages. You can either assign these with an existing license in the database, or create your own.

Adding Licenses in ProGet

You can add additional licenses in ProGet, setting the name and license code:

You can also edit existing licenses in the database, beyond just the “Edit Alias” option that Artifactory offers:

Configuring your License Policies

Just like with vulnerabilities, ProGet uses Policies to manage license compliance. As covered here, these aren’t functionally the same as Artifactory Policies:

• Artifactory Policies: Rules that define criteria, with a corresponding set of automatic actions.
• ProGet Policies: Rules that define how package licenses are evaluated.

ProGet policies determine if a package is:

• ✅Compliant
• ⚠️Warn
• 🚫 Non-compliant

Non-compliant packages in ProGet are similar to violations in Artifactory. They can’t be download and will be prevented from use in builds. ProGet will also notify you when a package is non-compliant.

Policies can be configured on the Policies page:

Once configured, packages flagged as non-complaint will be blocked from being downloaded.

Let’s say you wanted to block downloads of any package with the GPL 3.0 license, known for being risky to use in production. Set the GPL 3.0 license to non-compliant in the Global Policy, preventing packages with this license from being downloaded:

Sometimes you might need to block a license only being used by packages in a particular feed. In this case, you can block licenses at feed-level by creating a Shared Policy:

Setting Exceptions to Policies

Non-compliant licenses may be considered acceptable in some cases, and you can allow packages with these licenses by creating exceptions, much like the Ignore Rules in Artifactory.

Creating exceptions excludes certain packages or versions from global or shared policies. These are created on the Policies page using several filters and allow for wildcards (e.g. 3.* to exclude all version 3 releases):

You may also want to create an exception just for a limited time, such as for internal packages (MyCompany.*) or version ranges where metadata is known to be incorrect.  In these cases, you can also set an expiry date.

Conclusion

ProGet has SCA features for license management, automatically detecting package licenses based on a large curated database.

Use ProGet to edit or add licenses, and assign them to packages with unknown or absent licenses. The create Policies to block non-compliant packages from being used in production.

For more insight into the packages in your builds, import and export SBOMs in ProGet, explained in the next article breaking down Build Artifacts and Metadata.