Intellectual property and licensing
The substance is covered elsewhere: the licence families and what they require, the mechanisms that trigger an obligation, the verdict by product type and the pitfalls the grid does not capture. Licensing as SBOM data is in Licensing as SBOM data.
This page describes the arrangement: the policy, the process, the register and the deliverables.
Why this is a CRA workstream
The CRA does not require licence compliance. But it requires an SBOM, and a properly populated SBOM makes licence compliance automatable for the first time. That is a major side benefit, and the argument that lets the tooling be funded from two budgets rather than one.
The licence policy
Three lists, broken down by context of use:
| Context | What changes |
|---|---|
| Product distributed to customers | The strictest: strong copyleft is denied |
| Online service | Network copyleft (AGPL) becomes blocking |
| Internal tool, not distributed | The most permissive: most obligations are not triggered |
| Test code, not shipped | A lighter regime, still monitored |
The policy is a versioned document, approved, with an effective date. It is published to the teams and enforced by the build chain, not merely displayed.
The process, end to end
- Detection. The SBOM carries the licences; the platform matches them against the policy.
- Automatic decision. Allow list: the build passes. Deny list: the build fails. Review list: warning and a ticket.
- Analysis. Engineering documents the component’s introduction path and actual use, and proposes an option: replace, isolate, or request an exception.
- Legal decision. Legal rules, with conditions and an expiry date.
- Recording. Entry in the exception register, timestamped.
- Re-examination. At expiry, or earlier if the context changes.
The exception register
| Column | Content |
|---|---|
| Component and version | Identified by purl |
| Licence | Full SPDX expression |
| Product and context | Where the exception applies |
| Reason for the request | No alternative, migration cost, criticality |
| Conditions | Technical isolation, no distribution, enhanced attribution |
| Expiry date | Mandatory |
| Decider | Name and function |
| Status | Active, expired, revoked |
An exception with no expiry date becomes an unwritten rule. That is the main defect observed in existing arrangements.
Deliverables
| Deliverable | When | Generated from |
|---|---|---|
Attribution file (NOTICE) shipped with the product |
Every version | The SBOM |
| Written offer to provide source code | Where a copyleft component requires it | The register |
| Compliance report for a customer | On request | The SBOM + the register |
| Portfolio inventory by licence | Quarterly | The platform |
The attribution file is the most frequent and most easily fixed breach: its generation must be automatic and its presence checked in CI.
Preparing for audits
Requests come from three sources: large-account customers, investors in a transaction, and acquirers. They always cover the same points:
- the existence of a written and enforced licence policy;
- the completeness of the inventory, transitive dependencies included;
- consistency between the inventory and the attributions shipped;
- the treatment of licences with strong obligations;
- the exception register and how it is kept.
Answering these is instantaneous where the arrangement exists, and takes several weeks where it does not. It is the best indicator of real maturity.
The friction point to resolve
An intellectual property policy forbidding employees from publishing code conflicts directly with the Regulation’s obligation to report security fixes upstream — see Integrating open source.
The two policies must be reconciled in writing, with a contribution procedure light enough to be compatible with a fix deadline of a few days.