Open source licensing

The one idea to hold on to

A licence is never a problem in the abstract. It is a problem in a scenario.

The same library under AGPL-3.0 is harmless in an internal tool and fatal in a SaaS backend. The same library under GPL-3.0 is unremarkable on a desktop and blocking in a locked-down connected device. A CC-BY-NC asset is irrelevant in a mock-up and prohibited in a product you sell.

What triggers an obligation is not the licence’s name: it is what you do with the software — do you distribute it? to whom? in what form? do you expose it over a network? can the user replace the component?

That is why this section is built as a matrix: the licence families on one axis, the distribution scenarios on the other, and what connects them in between.

The matrix, on one page

Key: ● no difficulty · ◐ conditional, needs review · ○ avoid · ✕ incompatible in practice.

Scenario	Permissive	Weak copyleft, file	Weak copyleft, library	Strong copyleft	Network copyleft	Source-available
	MIT, Apache-2.0	MPL-2.0, EPL-2.0	LGPL-2.1/3.0	GPL-2.0/3.0	AGPL-3.0	BSL, SSPL, ELv2
Worst case	●	◐	○	○	✕	✕
SaaS backend	●	●	●	●	✕	○
Web frontend	◐	◐	○	✕	✕	✕
Desktop / CLI app	●	●	◐	◐	○	✕
Mobile app	●	●	○	✕	✕	✕
Library / SDK	●	◐	○	○	○	✕
On-premises	●	●	◐	◐	○	✕
Embedded / IoT	●	●	○	○ v2 / ✕ v3	✕	✕
Internal tool	●	●	●	●	◐	◐

Every cell is explained on the corresponding scenario page. The symbols do not replace the reading: a ◐ can hide a heavy engineering constraint, and a ● never removes the attribution duty.

What this section is not

It does not replace legal advice. Free software licensing rests on copyright, which is national; the notion of a “derivative work” has no settled European case law for software, and the positions taken by licence authors — on linking in particular — are not binding law. Where a question is contested, the page says so.

It also does not cover your internal process: the licence policy, the allow / review / deny lists, the exception register and the attribution deliverables are in Intellectual property.

How this relates to the CRA

Regulation (EU) 2024/2847 does not require licence compliance. It makes it measurable, and it turns it into a diligence matter:

• the mandatory inventory (Annex I, Part II, point 1) carries licence identifiers: for the first time, legal compliance becomes computable across the portfolio;
• due diligence on third-party components (Art. 13(5)) includes examining the licence, alongside maintenance and security history;
• the duty to report fixes upstream (Art. 13(6)) presupposes a contribution policy that allows your engineers to publish code;
• the five-to-ten-year support period requires keeping the corresponding source and the build chain — exactly what the GPL requires anyway.

Put differently: CRA compliance work and licence compliance work share their artefacts. Running them separately means paying for them twice.

Where to start

• New to the topic: The licence families.
• To understand why one licence changes nature with the context: What triggers an obligation.
• You have a specific product in mind: go straight to the matching scenario.
• Looking for what the matrix does not show: Pitfalls.