Licences open source

La seule idée à retenir

Une licence ne pose jamais problème dans l’absolu. Elle pose problème dans un scénario.

La même bibliothèque sous AGPL-3.0 est inoffensive dans un outil interne et fatale dans un backend SaaS. La même bibliothèque sous GPL-3.0 est banale sur un poste de travail et bloquante dans un objet connecté verrouillé. Un composant sous CC-BY-NC est sans conséquence dans une maquette et interdit dans un produit vendu.

Ce qui déclenche une obligation, ce n’est pas le nom de la licence : c’est ce que vous faites du logiciel — le distribuez-vous ? à qui ? sous quelle forme ? l’exposez-vous par le réseau ? l’utilisateur peut-il remplacer le composant ?

C’est pourquoi cette section est organisée en matrice : les familles de licences d’un côté, les scénarios de distribution de l’autre, et ce qui fait le lien entre les deux.

La matrice, en une page

Lecture : ● sans difficulté · ◐ sous conditions, à instruire · ○ à éviter · ✕ incompatible en pratique.

Scénario	Permissive	Copyleft faible fichier	Copyleft faible bibliothèque	Copyleft fort	Copyleft réseau	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
Cas général	●	◐	○	○	✕	✕
Backend SaaS	●	●	●	●	✕	○
Frontend web	◐	◐	○	✕	✕	✕
Application bureau / CLI	●	●	◐	◐	○	✕
Application mobile	●	●	○	✕	✕	✕
Bibliothèque / SDK publié	●	◐	○	○	○	✕
On-premise	●	●	◐	◐	○	✕
Embarqué / IoT	●	●	○	○ v2 / ✕ v3	✕	✕
Outil interne	●	●	●	●	◐	◐

Chaque case est expliquée dans la page du scénario correspondant. Les symboles ne remplacent pas la lecture : un ◐ peut cacher une contrainte d’ingénierie lourde, et un ● ne dispense jamais de l’attribution.

Ce que cette section n’est pas

Elle ne remplace pas un avis juridique. Le droit des licences libres repose sur le droit d’auteur, qui est national ; la notion d’« œuvre dérivée » n’a pas de définition jurisprudentielle stabilisée en Europe pour le logiciel, et les positions des auteurs de licences — notamment sur la liaison — ne sont pas du droit positif. Là où une question est disputée, la page le dit.

Elle ne traite pas non plus de votre processus interne : la politique de licences, les listes blanche/grise/noire, le registre des exceptions et les livrables d’attribution sont dans Propriété intellectuelle.

Le rapport avec le CRA

Le règlement (UE) 2024/2847 n’impose pas la conformité aux licences. Il la rend mesurable, et il en fait un sujet de diligence :

• l’inventaire obligatoire (annexe I, partie II, point 1) porte les identifiants de licence : pour la première fois, la conformité juridique devient calculable à l’échelle du portefeuille ;
• la diligence sur les composants tiers (art. 13, paragraphe 5) inclut l’examen de la licence, au même titre que la maintenance et l’historique de sécurité ;
• l’obligation de remonter les correctifs à l’amont (art. 13, paragraphe 6) suppose une politique de contribution qui autorise vos ingénieurs à publier du code ;
• la période de support de cinq à dix ans impose de conserver le code source correspondant et la chaîne de compilation — exactement ce que la GPL exige par ailleurs.

Autrement dit : le travail de conformité CRA et le travail de conformité aux licences partagent leurs artefacts. Les mener séparément, c’est les payer deux fois.

Par où commencer

• Vous découvrez le sujet : Les familles de licences.
• Vous voulez comprendre pourquoi la même licence change de nature selon le contexte : Ce qui déclenche une obligation.
• Vous avez un produit précis en tête : allez directement au scénario qui lui correspond.
• Vous cherchez ce qui échappe à la matrice : Les pièges.