CycloneDX / specification

OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM, OBOM, MBOM, VDR, and VEX
https://cyclonedx.org/
Apache License 2.0
362 stars 57 forks source link

Add clarification on what a list of licenses means #349

Open lfrancke opened 10 months ago

lfrancke commented 10 months ago

Component.licenses has this text "EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)"

It is not made clear what a list of licenses means. There are at least two options:

This ambiguity can be avoided using SPDX license expressions but if we get an SBOM with just a list we need to make a decision without any further information.

To be safe I would probably interpret it as AND in that case.

At least a comment should be added that this is undefined. I would probably even go as far as saying that only a single license is allowed and if there are more an expression needs to be used.

I understand that almost all changes except a clarifying comment would be backwards breaking changes.

lfrancke commented 10 months ago

I think there is a case to be made to even deprecate the list of licenses entirely.

This started as a discussion on Slack https://cyclonedx.slack.com/archives/CVA0G10FN/p1701087945143049?thread_ts=1701087945.143049&cid=CVA0G10FN

stevespringett commented 9 months ago

Support for only SPDX license expression is not an option. There are over 2500 open source licenses and SPDX only supports about 500 or so of them. The SPDX project also does not support any commercial licenses, so having support for license names along with attaching the full text of the license is a requirement for any commercial BOM use case.

Maven IMO, has the most ambiguity of any modern build system. For a license list, this is what the Maven POM XSD states:

This element describes all of the licenses for this project. Each license is described by a license element, which is then described by additional elements. Projects should only list the license(s) that applies to the project and not the licenses that apply to dependencies. If multiple licenses are listed, it is assumed that the user can select any of them, not that they must accept all.

An interesting fact is that the last sentence does not appear in their documentation. https://maven.apache.org/pom.html#Licenses

We could strengthen the documentation to read AND or OR - whichever we choose. We could also add a conjunction field to the spec so that the BOM author can specify.

jkowalleck commented 9 months ago

We could strengthen the documentation to read AND or OR - whichever we choose. We could also add a conjunction field to the spec so that the BOM author can specify.

I saw this always as an "OR". like in "Here are some licenses that suite our project. Choose the one that applies in your area." Most multi-license projects I recall had such a sentence in their README and License.txt.


collection of examples:

lfrancke commented 9 months ago

I talked to someone who thought it is AND.

I don't think any of those are more correct than the other which makes it important to document what is meant.

tlandschoff-scale commented 3 weeks ago

I saw this always as an "OR". like in "Here are some licenses that suite our project. Choose the one that applies in your area." Most multi-license projects I recall had such a sentence in their README and License.txt.

collection of examples:

* https://pypi.org/project/text-unidecode/ -- Artistic License, or GPL or GPLv2+

This is one case I have often see. On the other side of the spectrum there are collections of code that was bundled together. To stay on pypi:

I'd like to use a SPDX expression in the SBOM, but we are required to include the full license text for each license. Which is why I am using the licenses as list all the different licenses.