Pitfalls the matrix does not show
The family × scenario matrix handles the normal case: an identified component, under a known licence, in a defined product. Real incidents almost always come from elsewhere.
1. The upstream licence change
The most active risk of the period. Several major infrastructure projects have left a free licence for a source-available one in recent years — databases, search engines, infrastructure tools, monitoring, ticketing systems.
The mechanism: versions already published stay under the old licence, permanently. But later versions do not — and your security fixes come from later versions.
The organisation then faces three options, all costly:
| Option | Cost |
|---|---|
| Stay on the last free version | No more upstream security fixes: a direct regulatory liability under the CRA |
| Move to a community fork | Uncertain maturity, fragmented ecosystem |
| Accept the new licence | Commercial negotiation, usage restrictions, recurring cost |
What to put in place:
- pin versions and licences in the SBOM, and compare across versions — a change in the
licensefield is an event to handle, not just another data point; - watch the ten to twenty critical infrastructure components, the ones whose replacement would take months;
- record the risk in the compliance risk register, with a named owner.
2. No licence at all
A public repository with no licence file is not open source. Absent an express grant, copyright applies in full: all rights reserved. The code being visible grants nothing, and a forge’s terms of service grant at most a right to view and copy within the platform.
In SPDX this is NOASSERTION. In a licence policy it must be blocking — on the same footing
as a prohibited licence, not treated as missing metadata.
A frequent and more insidious variant: the repository announces a licence in its README but
contains no licence text, or contains a different one.
3. Multiple licences in one repository
The repository declares MIT. A vendor/, third_party/ or contrib/ subdirectory holds code
under another licence, sometimes copyleft.
No package manager sees it: they read the licence field declared in the manifest, not the contents of the files.
The only remedy is analysing the contents of the files, by hash, with dedicated tools — see Generators. It is slow and verbose, and it is the difference between declared compliance and established compliance.
4. Copied code
From a Q&A site or forum. Contributions to the main platforms are under a share-alike licence. A substantial snippet copied into proprietary code raises, in theory, a contamination question. Universal practice ignores it for a few trivial lines, and the doctrine holds that below an originality threshold there is no protectable work. The risk becomes real for a whole function copied across.
From another project. Copy-pasting a function from a copyleft project creates a derivative work, with no dependency manager recording it.
Vendored code. Copying a component into your tree rather than declaring it as a dependency breaks traceability: it appears neither in the manifest nor in the SBOM generated from the manifest. It only appears under content analysis.
5. AI-generated code
An open question, to be handled as such rather than settled.
The established facts: code generation assistants are trained on public code under a range of licences, copyleft included. They have been shown to reproduce substantial, near-identical excerpts of their source, particularly for uncommon code.
The open questions: the legal status of the output, ownership of rights, whether it qualifies as a derivative work, and liability in case of reproduction. No settled European case law to date.
What is reasonable in the meantime:
- enable the match filters the tools offer, which block the reproduction of excerpts identical to known public code;
- review generated code for non-trivial functions, as you would review a contribution;
- do not generate code in areas where contamination would be irrecoverable — cryptographic core, a component intended for publication under a permissive licence;
- document the position taken, so it does not have to be improvised during acquisition diligence, where the question is now asked.
6. Assets, which no tool looks at
No dependency scanner examines fonts, icons, images, sounds, 3D models or datasets. Yet they cause very concrete problems, because their licences are often more restrictive than those of the code.
| Asset | Pitfall |
|---|---|
| Fonts | OFL-1.1: reserved font name clause; subsetting is a modification. Commercial fonts: licences per domain or per page view |
| Icons | CC-BY-NC prohibited in a product you sell; CC-BY requires an attribution rarely given |
| Images | Stock libraries: licence by use, often not transferable to the customer |
| Sounds | Same rules, plus neighbouring rights |
| Datasets | ODbL: copyleft on derived databases. Decisive for a machine learning product |
| Pre-trained models | Their own licences, sometimes with usage restrictions — the so-called “responsible” family |
What to do: keep an asset inventory separate from the software SBOM, with the source, the licence, proof of acquisition and the scope of use granted. Nobody does this spontaneously; it is nonetheless the first place an audit finds something.
7. Mutual incompatibilities
Two licences can both be free and impossible to combine. The combinations to know:
| Combination | Status |
|---|---|
Apache-2.0 + GPL-2.0-only |
Incompatible on the FSF’s reading |
Apache-2.0 + GPL-3.0 |
Compatible |
CDDL-1.0 + GPL-2.0 |
Incompatible — the origin of the ZFS-on-Linux problem |
GPL-2.0-only + GPL-3.0-only |
Incompatible with each other |
GPL-2.0-or-later + GPL-3.0 |
Compatible, by moving to v3 |
BSD-4-Clause + GPL |
Incompatible — advertising clause |
EPL-1.0 + GPL |
Incompatible; EPL-2.0 resolves it with an optional clause |
| Two different strong copylefts | Generally incompatible with each other |
An incompatibility cannot be worked around: it makes distributing the combined work impossible. It is caught early, or paid for in rewriting.
8. Patent clauses and their backfire
Apache-2.0, GPL-3.0, MPL-2.0 and EPL-2.0 carry a patent grant with a termination: bringing patent infringement litigation against a contributor over the software forfeits the grant, and sometimes the whole licence.
For a company holding a patent portfolio this is a legal-department matter, not an engineering one: a litigation strategy can be neutralised by a library choice a developer made three years earlier.
9. The missing CLA
Without a contributor licence agreement or a developer certificate of origin, every external contributor keeps their rights. Consequences for a project you publish:
- relicensing impossible without everyone’s consent;
- dual commercial licensing impossible;
- enforcement difficult against a third party breaching your licence, since you do not hold all rights.
To settle before the first external contribution. See Library / SDK.
10. Fake free licences
Texts that look like free licences without being one:
| Text | Problem |
|---|---|
| Commons Clause | An addendum grafted onto a free licence, removing the right to sell. “MIT + Commons Clause” is not MIT |
| JSON License | Contains the clause “the Software shall be used for Good, not Evil”: ambiguous, non-free in practice, banned by several foundations |
| “Home-made” licences | Written by the author, unreviewed, unpredictable in interpretation. Treat as proprietary |
| “Ethical” licences | Usage restrictions by purpose. They fall outside the open source definition and create a permanent judgement problem |
What these ten pitfalls have in common
None is caught by a dependency scanner reading manifests. All require either file content analysis, or monitoring over time, or a governance decision.
That is why licence compliance does not reduce to a tool: it requires a policy, a register, a watch and a named owner — see Intellectual property.