feat: licenses acknowledgement SHOULD be unique

[jkowalleck]

as discussed in #619

• license acknowledgement should be be unique
• license acknowledgement should be be unset when used if evidences

---

this is considered a non-breaking change,
as the introduction of the keyword "should" does not alter existing behavior, it just exp recces a preference,
which may be ignored by users if they have a good reason to do so....

---

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

---

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

[jkowalleck]

this is the designed solution for your request, @pombredanne

[jkowalleck]

will fix merge conflicts soon, then ask a smaller part of the community for their input, and then,
this should be go into RFC phase very soon.

[jkowalleck]

will rebase this one ASAP, and then, the RFC phase will start.

[jkowalleck]

ready for review.

maybe ask @swinslow for his thoughts.
maybe ask @nickvidal for his thoughts.

[pombredanne]

@jkowalleck Since this is only advisory, I wonder if you could introduce some clarifications to support future enforcement of something stricter?

For instance rather than:

A list of SPDX licenses and/or named licenses and/or SPDX License Expression.\nThere should be no more than one per license acknowledgement.

What about something more or less along these lines:

A list with a single SPDX License Expression (preferred). Alternatively, for legacy compatibility, a list of SPDX license identifiers, named licenses, or SPDX License Expressions. \nThere should be no more than one item in this list. If there are more than one item, then the conjunction of all the listed licenses applies.

[jkowalleck]

Since this is only advisory, I wonder if you could introduce some clarifications to support future enforcement of something stricter

Plan was to keep #619 open for 2.0 -
then we can introduce breaking changes safely, and we would change the "should" to a "must" and would be good, right?

[Regul-000]

Safety aside, clear definition "Should" "Must" "Shall" shouldn't hurt too much