[FEATURE]: there SHOULD be at most one "declared" and one "conclude" license per component

[jkowalleck]

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 anacknowledgement; 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

• licenses: allow mix of multiple SPDX expressions AND/OR multiple named/spdx licenses #454 (comment)
• licenses: allow mix of multiple SPDX expressions AND/OR multiple named/spdx licenses #454 (comment)

[jkowalleck]

this is a ticket that is intended to handle your remarks from #454 (comment)

@pombredanne, could you see whether it covers your ideas?

[jkowalleck]

had a call with @pombredanne, and we modified the ticket's test until he was satisfied.

[Joerki]

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.

[jkowalleck]

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.

[jkowalleck]

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.

[jkowalleck]

see also: CycloneDX/cyclonedx-core-java#674