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

@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.