Licensing as SBOM data
The CRA does not require licence compliance. But the SBOM it does require is precisely the tool that makes compliance demonstrable — the strongest funding argument on the Legal side, and its most immediate benefit.
This page covers licensing as data: how it is expressed in an SBOM and what can be computed from it. The substance of the law is elsewhere:
- what each family requires → The licence families;
- when an obligation triggers → What triggers an obligation;
- the verdict by product type → Nine scenarios;
- your policy and process → Intellectual property.
SPDX identifiers
The SPDX licence list is the global reference for licence identifiers: MIT, Apache-2.0,
BSD-3-Clause, MPL-2.0, LGPL-2.1-only, GPL-3.0-or-later, AGPL-3.0-only, and several
hundred more. Both CycloneDX and SPDX use it.
A standardised identifier is what makes a licence computable: without one, “GPL v3 or later”, “GPLv3+” and “GNU General Public License version 3” are three distinct strings that no automated policy can match against a list.
Licence expressions
They cover compound cases, and each carries a different legal consequence:
| Expression | Meaning |
|---|---|
MIT |
A single licence |
MIT OR Apache-2.0 |
At the recipient’s choice: you pick the one that suits and document it |
GPL-2.0-only AND MIT |
Cumulative: both sets of obligations apply |
GPL-2.0-only WITH Classpath-exception-2.0 |
A licence with a standardised exception narrowing its reach — never ignore it, it changes the verdict |
LicenseRef-… |
A licence outside the SPDX list, whose text must accompany the document |
NOASSERTION |
Undetermined — a blocking defect, not a licence |
The -only and -or-later suffixes are not cosmetic: they determine whether you may apply a
later version of the licence, and therefore compatibility with the rest of the tree.
GPL-2.0-only and GPL-2.0-or-later do not carry the same consequences.
Declared versus concluded
The SPDX format distinguishes two fields that CycloneDX does not separate as cleanly:
| Field | Meaning |
|---|---|
PackageLicenseDeclared |
What the project asserts — the manifest field, the LICENSE file |
PackageLicenseConcluded |
What analysis establishes, after examining the file contents |
The gap between them is the interesting datum. A repository declared MIT whose analysis
concludes MIT AND GPL-2.0-only has a subdirectory nobody looked at — exactly the
multiple licences in one repository pitfall.
Documenting the concluded licence is not fussiness: it is what shows, in a dispute, that you verified rather than took someone’s word.
What an SBOM lets you compute
Once licences are properly populated, four operations become automatic:
| Operation | Output |
|---|---|
| Matching against the policy by context of use | Block or warn in CI |
| Generating the attribution file | NOTICE shipped with the product |
| Inventory by licence across the portfolio | A report for an audit or diligence |
| Diff between two versions | Detection of an upstream licence change |
The last point is underrated: comparing the licence field from one version to the next is the only way to catch, in time, that an infrastructure component has changed licence — see Pitfalls.
Data quality, the precondition for everything else
An SBOM where a significant share of components carries NOASSERTION supports no analysis. The
usual causes:
| Cause | Remedy |
|---|---|
| The generator only reads manifests | Add a content analysis tool, at reduced cadence |
| The manifest declares no licence | Go back to the source, and treat absence as blocking |
| Licence expressed as unnormalised free text | Normalise to an SPDX identifier |
| Vendored component, absent from the manifest | File-hash analysis |
The tolerated NOASSERTION threshold belongs in the
SBOM quality policy, alongside identifier coverage — and it must be
blocking at build time.
Useful frameworks
ISO/IEC 5230 (OpenChain, licence compliance) and ISO/IEC 18974 (OpenChain, open source security assurance) describe recognised management systems, useful for structuring the arrangement and for answering large-account customer requirements.