Any value of the Data License except CC0-1.0 makes the conversion fail.

[flemminglau]

When my cdx file has a top level license of anything but CC0-1.0 I get this error:

Eror copying metadata: Incorrect data license. Must be CC0-1.0

Not sure what is the purpose.
But if only a single value is allowed why not simply set that value instead of failing the conversion in case the source file has something else.

I am using sbomasm to generate boms and it hardcoded sets CC-BY-1.0

Someone must be doing something wrong here.

[flemminglau]

For now I have done a hack which ignores the input and always sets the (only allowed) output value.

        AnyLicenseInfo dataLicense;
        LicenseChoice lc = metadata.getLicenseChoice();
//        if (Objects.nonNull(lc)) {
//            dataLicense = licenseChoiceToSpdxLicense(spdxDoc, lc);
//        } else {
            dataLicense = ListedLicenses.getListedLicenses().getListedLicenseById(SpdxConstants.SPDX_DATA_LICENSE_ID);
//        }
        spdxDoc.setDataLicense(dataLicense);

[goneall]

@flemminglau The SPDX Spec currently requires the data license to be CC-0 - reference section 6.2.

IMO, we should not be changing the license. If the creator of an SBOM states a particular data license, we would not want to change that on them.

What if the utility issued a warning rather than failing? The resultant SPDX file would not technically be valid, but we would retain the same license information.

BTW - quite a few members of the SPDX community have expressed concerns with this data license requirement. There is an active proposal to relax this requirement in SPDX 3.0. Reference change proposal number 8.

cc'ing leads for the SPDX legal team: @swinslow @jlovejoy

[flemminglau]

Whatever makes most sense.
All I know is that for me the current process does not work.
The sbomasm utility autonomously and unconditionally adds the CC-BY-1.0 license to the cyclonedx sbom.
And cdx2spdx turns it down as it cannot be used for the spdx version.

(It seems strange to me that the spdx specs require a specific license to be set while the author at the same time has the right to define what it should be. So basically I must decide if my SPDX file should be invalid or if I use the prescribed license. A strange dilemma)

PS:
It is possible for sbomasm to define a license for the assembly but that applies to the content/subject of the sbom whereas I understand that the disputed one is about the sbom file itself.

[goneall]

I can create a PR to change this to a warning.

It is possible for sbomasm to define a license for the assembly but that applies to the content/subject of the sbom whereas I understand that the disputed one is about the sbom file itself.

Correct - the data license field applies to the SBOM itself, not the subject of the SBOM. There are separate fields in the Package and File for recording the license of the subjects.

[jlovejoy]

HI @flemminglau - just catching up here. Let me make sure I understand the context:

When you say, "my cdx file has a top level license" - what is the definition and purpose of this field in cdx? It seems we are assuming that it is the same as the SPDX Data License field, but I thought I'd first check that assumption is correct and that these fields in both specs are truly corresponding.

By way of background, I'd recommend you read the purpose and intent of the SPDX Data License field, if you haven't already, at https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#62-data-license-field
At the time this was discussed, there was a lot of consideration by the SPDX-legal team as to what, if any, copyright and database rights might cover an SPDX document. These are different rights with different legal frameworks, and in the case of database rights, differences as to jurisdiction.

The choice of CC-0 was to ensure the goal of (S)BOM data (I put the S in parens, b/c when SPDX started back in 2010, we used "BOM" as the term then, ha ha!) to travel freely through the supply chain and discourage people creating SPDX documents and then trying to sell them. Perhaps this is less of a concern now, but I think the original intent is important to understand as the underpinning of information being exchanged easily through the supply chain is still a goal (aside valid situations where some info may be confidential, which is also fine, but different than making the information itself proprietary).

Hope that additional context helps a bit!

[goneall]

Fixed in #36