Provide mapping for "original licence", "distribution licence", and "effective licence" (BSI TR-03183-2)

[bact]

"original licence", "distribution licence", and "effective licence" are defined and used in the German Federal BSI TR-03183-2: Cyber Resilience Requirements for Manufacturers and Products - Part 2: Software Bill of Materials (SBOM) Version 2.1.0 (see text below).

We may like to assess if it is necessary or desired to provide a mapping of SPDX properties/relationships to those license type definitions. Probably in the Licensing profile description: https://github.com/spdx/spdx-3-model/blob/develop/model/Licensing/Licensing.md

Relevant text from BSI TR-03183-2:

3.2.8 Licence information

This Technical Guideline distinguishes between three categories of licence information:

• Original licence(s)
  Original licence(s) are all licences that have been assigned by the creator of the component.
• Distribution licence(s)
  Distribution licence(s) are all licences under which a component recorded in the current SBOM can be used by a licensee.
• Effective licence
  The effective licence is the licence under which the component is used by the licensee that is the creator of the current SBOM.

The terms “concluded licences” and “declared licences” are not defined and used consistently throughout different SBOM standards and implementations. To avoid inconsistencies and confusion and allow for an easy mapping this Technical Guideline uses different terms.

Note: Because the “effective licence” is set by the creator of the current SBOM, it has to be set anew when merging SBOMs. However, this process may result in the same “effective licence”.

[bennetkl]

@bact Do you have an example of values of license that would go into effective license field. I can see that BSI TR-03183 guideline created the "effective license" term specifically because: SPDX uses "Concluded" vs "Declared"
and CycloneDX uses a totally different field structures for license. BSI introduced this new field for a consistent term for the license under which the creator of this SBOM actually uses the component" The introduction of this 'new' field, also causes problems when merging SBOMs, the effective license must be re-evaluated by the new SBOM creator, as it reflects their specific usage context and license choices (particularly important for dual-licensed components). SPDX Licensing is a key value / benefit of using SPDX. and I'm somewhat concerned after reading BSI suggestion to use the CDX licenses field to represent the effective license . So if we were to add to SPDX structure, it means that most tool developers will likely just use effective license instead of the well thought out SPDX licensing model Not my call, Kate/Gary/Steve can decide, but I don't think think this type of mapping is a priority to add to SDPX. Maybe adding to the issue, who and why, this field has been requested would help with the decision

[bact]

CycloneDX also uses "declared" and "concluded", from https://cyclonedx.org/use-cases/open-source-licensing/:

{
  "license": {
    "id": "Apache-2.0",
    "acknowledgement": "declared"
  }
}

{
  "license": {
    "id": "Apache-2.0",
    "acknowledgement": "concluded"
  }
}

See CycloneDX 1.7 reference https://cyclonedx.org/docs/1.7/json/#metadata_tools_oneOf_i0_components_items_licenses_items_oneOf_i0_license_acknowledgement

[AlexanderDenkBMW]

Hi,

I've had the same issue one week ago when I mapped BSI's TR to SPDX 3.0.

My mapping approach:

This needs to be verified, but is my current state of work:

• Original licence(s): I've mapped them to declared license(s), both in SPDX and CycloneDX
• Effective licence: I've mapped this to concluded license, also both SPDX and CycloneDX, this is also re-evaluated when SBOMs are integrated, merged or modified
• Distribution license: I'd tend to merge this with effective license. Either SPDX nor CycloneDX are acknowledging this topic. Practically I've also no clue how to handle this "correct" or "better" than just ignoring/merging it.

My personal take on that topic:

I'm also not getting the argument of the BSI. In order to avoid "inconsistencies and confusion and allow for an easy mapping" the solution should be to introduce "different terms" without providing a mapping to existing standards/implementations. I'm not getting how an additional layer of abstraction with the freedom to define new mappings should avoid confusion. One term even cannot be really mapped directly. The consequence: Toolchains need additional bespoke mappings, every SBOM requires a new semantic reinterpretation layer. It’s moving confusion up a level.

The SPDX advantage is to be strict and precise:

• Declared = what the artifact says
• Concluded = what the SBOM author legally concludes
  This is perfectly fine to cover the real world requirements and already providing fully sufficient complexity.

Also it's not true that the usage of the terms "concluded license" and "declared license" is not defined or used consistently. SPDX and CycloneDX have clear definitions and the definitions are also compatible. If implementations are fulfilling this standards correctly may be a different topic. However, if it's implemented insufficient already, additional concepts, requirements and complexity won't solve this issue.

And last but not least: SPDX is an ISO standard, CycloneDX is an ECMA standard. Both are internationally acknowledged standards. It's perfectly fine to provide interpretations, usage guidelines or also requirements for future versions or new problems (HBOM).
But, creating an confusion layer of abstraction by introducing new terminology without providing the necessarily background my not be the best idea.

Next steps:

• I'd be glad if there would be an official statement how SPDX would recommend to map/interpret/handle the terms.
• I'd hope that the newly introduced term does not get a backchannel to SPDX: While the Cyber Resilience Act (EU) 2024/2847 is a legal binding obligation, the BSI TR is just a guideline to comply with these requirements. Deviations are allowed and in this case I'd guess that ignoring this three term approach can be backed by good arguments.

[AlexanderDenkBMW]

Additional statement for ensuring completeness:

8.1.13 Licence information
The required data fields for components include licence information. On the one hand handling licence
information is a common use case for SBOMs. On the other hand, licence information can be crucial in
handling vulnerabilities, e.g. if the licence of a component does not allow the user to modify the code to
mitigate a vulnerability.
The original licence of an upstream component may differ from its distribution licence assigned by a
creator of a downstream component utilising the upstream component. An example for this is if the
primary licensee is forced by the component creator to choose from different sets of licences which are
mutually exclusive. A classic example is Qt where the primary licensee has to decide between GPL and a
proprietary licence; only the made choice can be handed further down the supply chain. Hence the
distribution licences can differ from the original licences.
The statement in section 5.1 about multiple component instances with different meta-information also
applies if only the licence information differs.
In general, the licence fields for both, “declared licenses” and “concluded licenses” should be filled according
to the utilised format specification (i.e. a specific version of CycloneDX or SPDX). Note that these format
specifications provide slightly deviating definitions for “declared license(s)” and “concluded license(s)”,
though both specifications focus on the manner in which this information was obtained to differentiate
their license fields. BSI TR-03183-2 rather focusses on the licence situation from the perspective of the
SBOM creator up to the original source (i.e. the “tip” of the supply chain) and from the SBOM creator
downwards in the supply chain (“downstream licence(s)”), because this is the relevant licence information
for a recipient of a software (component) to determine their degree of freedom to use, analyse, alter,
distribute it, and under which licence(s) a software (component) can be obtained from its original source.
Consequently, this Technical Guideline deliberately specifies different terms and definitions for licence
information than both format specifications to avoid overloading the terms “declared license” and
“concluded license” even more with a third definition. The licence information specified by BSI TR-03183-2
must be mapped to the corresponding format specification as follows, but mind that one should also avoid
violating the definitions of these fields by the utilised format specification version.

This section adds some explanation of the BSI approach.

While it's giving some background, it is not too helpful at all:

• it finally distinguishes three different problem spaces:
  • how license information is obtained (SPDX / CycloneDX)
  • how license situations evolve along a supply chain (orginal --> downstream/distribution)
  • what matters to an SBOM recipient legally and operationally
• it provides with Qt a valid real-world example
• it also acknowledges that SPDX and CycloneDX definitions must be respected at all (damage control?)

Still it fails in the essential topics:

• "these format specifications provide slightly deviating definitions for ‘declared’ and ‘concluded’" is not backed by the reality. The meaning is the same in SPDX and CycloneDX, mechanics in tooling may be different. As said above this is a different topic and not a problem of the standards
• "both specifications focus on the manner in which this information was obtained" may be the core of their issue. However, creating new terms and doing re-labling does not solve the issue that they see the requirement to maintain additional information that may be relevant for downstream recipients
• just acknowledging a mapping issue and introduced ambiguity does not solve it.

[AlexanderDenkBMW]

Additional Remark:
In the examples there is also a suggestion how to map the "effective license":

I'm not sure if this is really required (technically it's optional, however I doubt the need) at all and somehow it's not really elegant. But at least this could complete then an kind of official mapping (which is purely defined by the examples in the document, not the descriptive part).

Somehow I guess (unverified) that the terminology was changed, the (outdated?) wording cited in this document was more straight forward and would cause less issues: https://github.com/OpenChain-Project/Automotive-SBOM/blob/5fb1ff22c4d21837b3fe67c43936073a289f1fd0/docs/Automotive%20SBOM%20Specification.md#62-license-type-definitions-in-bsi--tr-03183-
Concluded and declared remain untouched. Associated licenses are an additional information.

[bact]

Thanks @AlexanderDenkBMW a lot for the research and all the useful information.

[AlexanderDenkBMW]

Hi,

maybe this section should be updated with the outcome of the discussion here:
https://github.com/spdx/using/blob/main/docs/comply-with-norms.md#bsi-tr-03183---technical-guideline-cyber-resilience-requirements-for-manufacturers-and-products

[bennetkl]

Agree, update, the link for BSI 1.1 went to file not found, but found the information here: https://github.com/interlynk-io/sbom-insights/blob/main/content/posts/bsi-tr-03183-v1.1-compliance.md