Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

LicenseDeclared not as per SPDX License List #3030

Closed
aniketdn opened this issue Jul 12, 2024 · 7 comments · Fixed by #3461
Closed

LicenseDeclared not as per SPDX License List #3030

aniketdn opened this issue Jul 12, 2024 · 7 comments · Fixed by #3461
Assignees
Labels
bug Something isn't working

Comments

@aniketdn
Copy link

What happened:
For the following package, the licenseDeclared is not as per the SPDX license list https://spdx.org/licenses/

        {
            "name": "libbsd",
            "SPDXID": "SPDXRef-Package-rpm-libbsd-bfec4299ebaea3ed",
            "versionInfo": "0.11.7-2.el7",
            "supplier": "Organization: Fedora Project",
            "originator": "Organization: Fedora Project",
            "downloadLocation": "NOASSERTION",
            "filesAnalyzed": true,
            "packageVerificationCode": {
                "packageVerificationCodeValue": "755d51732dcefe93fa28bb52e42df740e8aca0a0"
            },
            "sourceInfo": "acquired package info from RPM DB: /var/lib/rpm/Packages",
            "licenseConcluded": "NOASSERTION",
            "licenseDeclared": "(Beerware AND BSD-2-Clause AND BSD-3-Clause AND BSD-4-Clause AND ISC AND libutil-David-Nugent AND MIT AND LicenseRef-Fedora-Public-Domain)",
            "copyrightText": "NOASSERTION",
            "externalRefs": [
                {
                    "referenceCategory": "SECURITY",
                    "referenceType": "cpe23Type",
                    "referenceLocator": "cpe:2.3:a:fedoraproject:libbsd:0.11.7-2.el7:*:*:*:*:*:*:*"
                },
                {
                    "referenceCategory": "SECURITY",
                    "referenceType": "cpe23Type",
                    "referenceLocator": "cpe:2.3:a:libbsd:libbsd:0.11.7-2.el7:*:*:*:*:*:*:*"
                },
                {
                    "referenceCategory": "PACKAGE-MANAGER",
                    "referenceType": "purl",
                    "referenceLocator": "pkg:rpm/centos/libbsd@0.11.7-2.el7?arch=x86_64&upstream=libbsd-0.11.7-2.el7.src.rpm&distro=centos-7"
                }
            ]
        }

The value LicenseRef-Fedora-Public-Domain does not match any of the SPDX identifiers listed.

This value is causing the ntia-checker to generate a ValidationMessage Unrecognized license reference: LicenseRef-Fedora-Public-Domain.

What you expected to happen:
licenseDeclared field to have license values as per SPDX identifiers list.
If its a valid license, it can also be submitted to SPDX for its consideration as per: https://github.com/spdx/license-list-XML/blob/main/CONTRIBUTING.md

Steps to reproduce the issue:

Anything else we need to know?:

Environment:

  • Output of syft version: syft 1.9.0
  • OS (e.g: cat /etc/os-release or similar): Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10 PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64
@aniketdn aniketdn added the bug Something isn't working label Jul 12, 2024
@kzantow
Copy link
Contributor

kzantow commented Jul 15, 2024

The prefix LicenseRef- indicates that this is a reference to a license in the other licenses section, which has not resolved to a known SPDX License ID. This is valid to do in SPDX -- I think the validator might be incorrect here. The NTIA Minimum requirements doc only says this about licenses, nothing indicating these must be valid SPDX license IDs:

License Information. License management was an early use case for SBOM, helping
organizations with large and complex software portfolios track the licenses and terms of their
diverse software components, especially for open source software. SBOMs can convey data
about the licenses for each component. This data can also allow the user or purchaser to know if
the software can be used as a component of another application without creating legal risk. 16

16 Both CycloneDX and SPDX support the expression of licenses in several ways, including a license ID on the
SPDX license list, or using SPDX license expressions. See SPDX License List, SPDX https://spdx.org/licenses/
(May 20, 2021).

Is there anything I'm missing?

@aniketdn
Copy link
Author

Thanks to pointing me to this. I did check the hasExtractedLicensingInfos section of the generated SBOM and there's no mention of the LicenseRef-Fedora-Public-Domain license. Hence, the ntia-checker generated a vailidationMessage. I manually added the below block and now the checker does not complain about invalid licenses

       {
            "licenseId": "LicenseRef-Fedora-Public-Domain",
            "extractedText": "Fedora Public Domain"

        }

For other licenses that didn't resolve to a known SPDX License ID, this information was already extracted. Do you know why it failed to add extractionInfo for this?

@kzantow
Copy link
Contributor

kzantow commented Jul 17, 2024

@aniketdn -- I can't say why this entry wasn't added. Is there a public image or other reproduction steps you could share to get an SBOM in this state?

@aniketdn
Copy link
Author

Unfortunately I do not have a public image I can point you to.
I generated the SBOM using standard syft command syft <imageName> -o spdx-json=fileName.json

@aniketdn
Copy link
Author

@kzantow when i run a rpm query on the package on the libbsd package, the License field has the value Beerware AND BSD-2-Clause AND BSD-3-Clause AND BSD-4-Clause AND ISC AND libutil-David-Nugent AND MIT AND LicenseRef-Fedora-Public-Domain. I checked a few more of other packages on the container which did not have valid SPDX license identifiers. All of them had License values without any LicenseRef- prefix.

Could it be the case that the license value that is obtained for libbsdis causing syft to not add this entry in the hasExtractedLicensingInfos section?

@willmurphyscode
Copy link
Contributor

Hi @kzantow and @aniketdn I think I've found minimal repro steps that use only public images and data:

FROM fedora:42
RUN yum install -y libbsd

obtaining SBOM:

docker build -t test-syft-3030 .
syft -o spdx-json=spdx.json test-syft-3030

Filtered spdx-json, obtained by running jq '.packages[] | select(.name | contains("libbsd"))' spdx.json:

{
  "name": "libbsd",
  "SPDXID": "SPDXRef-Package-rpm-libbsd-26e6215123b65c52",
  "versionInfo": "0.12.2-4.fc41",
  "supplier": "Organization: Fedora Project",
  "originator": "Organization: Fedora Project",
  "downloadLocation": "NOASSERTION",
  "filesAnalyzed": true,
  "packageVerificationCode": {
    "packageVerificationCodeValue": "e82748ac35a0f41140355ab271c11a058fb7fa58"
  },
  "sourceInfo": "acquired package info from RPM DB: /usr/lib/sysimage/rpm/rpmdb.sqlite",
  "licenseConcluded": "NOASSERTION",
  "licenseDeclared": "(Beerware AND BSD-2-Clause AND BSD-3-Clause AND ISC AND libutil-David-Nugent AND MIT AND LicenseRef-Fedora-Public-Domain)",
  "copyrightText": "NOASSERTION",
  "externalRefs": [
    {
      "referenceCategory": "SECURITY",
      "referenceType": "cpe23Type",
      "referenceLocator": "cpe:2.3:a:fedoraproject:libbsd:0.12.2-4.fc41:*:*:*:*:*:*:*"
    },
    {
      "referenceCategory": "SECURITY",
      "referenceType": "cpe23Type",
      "referenceLocator": "cpe:2.3:a:libbsd:libbsd:0.12.2-4.fc41:*:*:*:*:*:*:*"
    },
    {
      "referenceCategory": "PACKAGE-MANAGER",
      "referenceType": "purl",
      "referenceLocator": "pkg:rpm/fedora/libbsd@0.12.2-4.fc41?arch=aarch64&upstream=libbsd-0.12.2-4.fc41.src.rpm&distro=fedora-42"
    }
  ]
}

Note that the licenseDeclared includes LicenseRef-Fedora-Public-Domain which I think is this issue. @aniketdn do these steps reproduce your issue?

@aniketdn
Copy link
Author

aniketdn commented Oct 7, 2024

Yes @willmurphyscode you are absolutely right! These steps reproduce the issue.

@willmurphyscode willmurphyscode moved this to Backlog in OSS Oct 11, 2024
@spiffcs spiffcs self-assigned this Oct 14, 2024
@spiffcs spiffcs moved this from Backlog to In Progress in OSS Oct 14, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in OSS Nov 19, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants