CycloneDX
[FEATURE]: there SHOULD be at most one "declared" and one "conclude" license per component
Describe the feature
CycloneDX allows multiple licenses in parallel, per component/evidence/etc.
Currently, it is possible to have multiple "declared" licenses. Currently, it is possible to have multiple "concluded" licenses.
It is desired to only have one "concluded" license -- how would you have multiple? Similar situation with the "declared" licenses.
For evidences, we have the desire to not have any license acknowledgement at all.
Changing this from a "MAY" (current state) to a "MUST"/"MUST NOT" - would be a breaking change.
Using a "SHOULD" might be possible easily for ambiguous license lists. Using a "MUST" for license expressions - for "concluded", and "SHOULD" for "declared".
There must be no constraints for license evidence!
Possible solutions
Change the spec tests
- for evidences, have a text say "licenses should not have an
acknowledgement, it they do, it shall be ignored." - for components/services/etc, have the text say "licenses should have an
acknowledgement; the same acknowledgement shall be used not more than once."
a follow up: create a ticket for v2.0 that makes these should/shall a must.
Alternatives
What other things would suite the needs?
Additional context
this ticket was created because of
- https://github.com/CycloneDX/specification/issues/454#issuecomment-2764224451
- https://github.com/CycloneDX/specification/issues/454#issuecomment-2710949796
this is a ticket that is intended to handle your remarks from https://github.com/CycloneDX/specification/issues/454#issuecomment-2710949796
@pombredanne, could you see whether it covers your ideas?
had a call with @pombredanne, and we modified the ticket's test until he was satisfied.
Describe the feature
CycloneDX allows multiple licenses in parallel, per component/evidence/etc.
Currently, it is possible to have multiple "declared" licenses. Currently, it is possible to have multiple "concluded" licenses.
Yes, in the Linux ecosystem. I just focus here on that. This ecosystem is one of the biggest in the world and I see it here as one of the most significant and relevant ecosystems. The licenses are bound to the input of the authors, NOT to the package as output like we have for most other components. The source code file/file sets are NOT components in CycloneDX context (I saw a feature request for "source" component type, but this is not what we are dealing with here). The sources result into the (compiled) package component.
Package X
author/copyright A,B,C file set /
license 1
author/copyright D, file set /a
license 2
author/copyright E, file set /b/c
license 3 or 4
Simple example for a package (=component):
It is desired to only have one "concluded" license -- how would you have multiple? Similar situation with the "declared" licenses.
Who desires this?
One point that is absolutely a requirement for me: Any SBOM specification must consider licenses practices that are established in the real world (and not vice versa) by every ecosystem we need to consider for products.
@pombredanne, you wrote in #454 :
"- Allow a list of expressions with unique "acknowledgment" across all expressions"
When I read this my understand was that an acknowledgement can effectively done for the whole licensing of the component only (which may include simple and (resolved) compound expessions).
It is impossible to reduce a set of different licenses to a single one. All licenses have the same weight. The coverage of the source file sets may have a significant diference, but finally there is no license that has a bigger impact than another one.
A "concluded" acknoledgement attribute marks
(1.) a component with a disjunctive compound expression where a conclusion was done OR a reference to a component that was not properly declared by the component creator (see below) (in component.licenses) With the bom-ref we have the possibility to see the relation between declared (evidence) and concluded (component) single license.
(2.) a "miss" declaration of a certain license of the component creator (in evidence.licenses) It might be possible that during component analysis we find out that the component creator missed to declare one or more licenses. In that case it could make sense that the "evidence" (which tells the truth, otherwise the wording is wrong!) shows a differentiation between these cases.
For "declared" acknoledgements it means
(according to 1.) The "declared" acknoledgement attribute marks all components that have an identical content like the declared components we find in evidence.
(according to 2.) the author explicitly declared the license in a correct way.
For evidences, we have the desire to not have any license acknowledgement at all.
My first thought was: I agree.
But, as described above, after thinking deeper this would mean that we cannot distinguish here between a proper and improper declaration anymore, if we do not have an attribute that shows a present or missing in the declaration. The tag's name is "evidence", not "declaration". So that also means that the content has to be true and complete.
The conclusion includes not only to decide what license applies from a disjunctive expression, but also includes the decision of the user that declares applicable license(s).
The description that comes with acknoledgement ("Declared license are ...") are fully correct for me. But, depending in the context of component.licenses and evidence.licenses, the semantic purpose should be explained differently.
So, if the attribute values "declared" and "concluded" are not thought in that way, they are completely useless and redundant for me.
It is desired to only have one "concluded" license -- how would you have multiple? Similar situation with the "declared" licenses.
Who desires this?
@pombredanne does. I opened this very ticket to address his ideas/wishes; and to see how others think about the proposed changes.
I personally don’t have any strong feelings about this—I don’t really care. I only wrote down what others wished for. So, I won’t step into this argument.
I'm personally really frustrated about the outcome of my previous activities which let me conclude (like other people I heard from), that CycloneDX is not good enough to solve license compliance requirements.
I encourage you to drive your own ideas as change/feature proposals. Create tickets/discussions, and eventually open pull requests so that things might be changed the way it suites your real world needs.
maybe ask @swinslow for his thoughts. maybe ask @nickvidal for his thoughts.
see also: CycloneDX/cyclonedx-core-java#674
@jkowalleck FWIW, if you need this to be improved, we could extract some mappings from the 40K rules from scancode-toolkit. We are also embarked on detailed scanning of the whole maven central. Note that at scale, the license declared in a POM is a weak statement that may not match the license of the actual code... but that's another problem.
RFC notice sent 2025-08-14
- via mailing group: https://groups.io/g/CycloneDX/topic/rfc_uniqueness_to_license/114703672
- via slack: https://cyclonedx.slack.com/archives/CVA0G10FN/p1755188890704749
This RFC will be open for 4 weeks. At the end of the RFC period, the CycloneDX community will vote, by lazy consensus, to accept or reject the proposal. RFC period end: 2025-09-11
see also: CycloneDX/cyclonedx-core-java#674
@jkowalleck FWIW, if you need this to be improved, we could extract some mappings from the 40K rules from scancode-toolkit. We are also embarked on detailed scanning of the whole maven central. Note that at scale, the license declared in a POM is a weak statement that may not match the license of the actual code... but that's another problem.
nope, we dont care for this noise, here. this is only about the enhancement of CycloneDX spec.
see also: CycloneDX/cyclonedx-core-java#674
@jkowalleck FWIW, if you need this to be improved, we could extract some mappings from the 40K rules from scancode-toolkit. We are also embarked on detailed scanning of the whole maven central. Note that at scale, the license declared in a POM is a weak statement that may not match the license of the actual code... but that's another problem.
nope, we dont care for this noise, here. this is only about the enhancement of CycloneDX.
@jkowalleck I am not sure you get what I meant, and I would not qualify my comment as noise.
- https://github.com/CycloneDX/cyclonedx-core-java/blob/7e18d1d141d46c79e42ba050d88fb57935e605c3/src/main/resources/license-mapping.json is incomplete. You could enhance this list with a few more based on actual observed licenses seen in POMs. If you consider this as noise, then your small list is also noise, and furthermore incomplete and therefore less useful.
see also: CycloneDX/cyclonedx-core-java#674
@jkowalleck FWIW, if you need this to be improved, we could extract some mappings from the 40K rules from scancode-toolkit. We are also embarked on detailed scanning of the whole maven central. Note that at scale, the license declared in a POM is a weak statement that may not match the license of the actual code... but that's another problem.
nope, we dont care for this noise, here. this is only about the enhancement of CycloneDX.
@jkowalleck I am not sure you get what I meant, and I would not qualify my comment as noise. [...]
i did not mean your comment with "noise". :-) I meant my own comment is just some noise, that is not really related to this very ticket - and should be discusses not here.