Skip to content

Improve definition of unknown licenses

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Problem to solve

License scanning identifies licenses used by components reported in CycloneDX SBOM files.

On occasion, the license cannot be identified, and it is recorded as unknown.

image

Note that this feature is not related to the license identification of source code in a repository, which uses the licensee gem for this purpose and is managed by groupsource code.

The unknown identifier is a catchall term, but there are different reasons for it:

  1. The component is not in the local copy of the PMDB.
    1. The PURL type is not supported.
    2. The component name has no match.
    3. The component version has no match, and it's out of range for the default licenses. See export format v2.
  2. The component version can't be parsed.
  3. The component (name and version) is in the PMDB but it doesn't have a license because:
    1. The license is not in the SPDX license list. In other words we found a license but it is not an SPDX identifier.
    2. The license is not specified for the component.
    3. The license is a valid SPDX license but is a license expression which is currently not supported.
    4. PMDB was not able to identify the correct license. That can happen when we identify a license string that cannot be matched to an SPDX license, although in reality it is a valid SPDX license.
  4. We have valid licenses for previous versions of the component but not for the latest version. That can happen due to the fact that PMDB refreshes once every day. We could infer the correct license by looking on the latest available version license.

The action required to correct each of these is different, if they can be corrected.

Moreover, they have different implications to a user of License approval policies. For example, an organization may want to define different actions for each situation.

User experience goal

The reason for a license being unknown should be clear to the user.

They should be able to see this reason on the relevant features, such as dependency list, pipeline licenses tab, and license approval policy.

We might also want to look at the situation where the components are missing. E.g. a SBOM report doesn't exist in the latest pipeline. This doesn't cause an unknown license, but it does cause the license approval policy to require approval.

Proposal

Is this a cross-stage feature?

Somewhat, as changes to unknown may have a knock-on effect on other features.

Links / references

Edited by Nick Ilieskou