Ce qui déclenche une obligation

C’est la page qui explique pourquoi la même licence change complètement de nature d’un produit à l’autre. Huit mécanismes, dont trois seulement décident de l’essentiel.

1. La distribution — le mécanisme principal

Presque toutes les obligations de copyleft sont conditionnées à la transmission du logiciel à un tiers. La GPL-3.0 parle de conveying : tout acte qui permet à quelqu’un d’autre de faire ou de recevoir des copies.

Est une distribution :

livrer un binaire, un installeur, un paquet, un micrologiciel ;
publier une image de conteneur sur un registre, même privé mais accessible à un tiers ;
servir du JavaScript à un navigateur — c’est du code, et il change de main ;
fournir une appliance virtuelle ou une image machine ;
déployer chez un client, en on-premise ;
transmettre à une autre personne morale du groupe : une filiale est un tiers.

N’est pas une distribution :

exécuter le logiciel sur vos propres serveurs pour rendre un service ;
l’utiliser en interne, y compris par des milliers de salariés ;
le déplacer entre vos propres machines.

La conséquence la plus contre-intuitive du droit des licences libres : vous pouvez construire un service en ligne entier sur du code GPL sans avoir la moindre obligation de publier quoi que ce soit. C’est ce qu’on appelle la « faille du fournisseur de service », et c’est précisément ce que l’AGPL a été écrite pour fermer.

2. L’interaction par un réseau

Mécanisme propre à l’AGPL-3.0 et à l’OSL-3.0. L’obligation naît de l’usage à distance, sans qu’aucun binaire ne change de main.

Trois conditions cumulatives pour l’AGPL, article 13 :

le programme a été modifié — ou combiné avec votre code, ce qui revient au même ;
des utilisateurs interagissent avec lui à distance par un réseau ;
votre version prend en charge cette interaction.

Le détail de la nuance sur la version non modifiée est traité dans Les familles. Retenez la règle pratique : dans un service exposé, un composant AGPL doit être considéré comme déclencheur sauf démonstration contraire, documentée.

3. L’œuvre dérivée et l’œuvre combinée

C’est la question la plus disputée du domaine, et il faut le dire clairement : elle n’a pas de réponse jurisprudentielle stabilisée en Europe pour le logiciel.

Le copyleft ne se propage qu’à ce qui constitue une œuvre dérivée au sens du droit d’auteur. Reste à savoir ce qui en est une.

Ce qui fait consensus :

modifier le code source d’un composant crée une œuvre dérivée ;
copier une portion substantielle de code dans votre fichier crée une œuvre dérivée ;
placer deux programmes indépendants côte à côte n’en crée pas (voir la simple agrégation).

Ce qui ne fait pas consensus : la liaison. La Free Software Foundation soutient, dans sa foire aux questions sur la GPL, que lier un programme à une bibliothèque, statiquement ou dynamiquement, crée une œuvre combinée soumise au copyleft. Cette position est une interprétation de l’auteur de la licence, pas du droit positif ; une partie de la doctrine la conteste, en particulier pour la liaison dynamique via une interface stable et publique.

Les critères habituellement retenus dans une analyse, du plus au moins contaminant :

Situation	Analyse dominante
Code copié dans votre fichier	Œuvre dérivée, sans discussion
Liaison statique	Œuvre combinée selon la lecture majoritaire
Liaison dynamique, structures de données partagées, appels intimes	Œuvre combinée selon la FSF, contesté
Liaison dynamique via une interface stable et documentée	Zone grise
Processus séparés communiquant par tube, socket ou HTTP	Généralement pas une œuvre dérivée
Exécution d’un programme comme sous-processus	Généralement pas une œuvre dérivée

La conséquence d’ingénierie. Lorsqu’un composant sous copyleft fort est indispensable et qu’on veut préserver le reste du code, la parade classique consiste à l’isoler dans un processus séparé communiquant par une interface réseau ou par ligne de commande. Ce n’est pas une astuce d’avocat : c’est une décision d’architecture, à prendre tôt, et à documenter comme telle.

4. La simple agrégation

Réunir plusieurs programmes indépendants sur un même support de distribution ne crée pas d’œuvre dérivée. La GPL le dit expressément.

Exemples d’agrégation, donc sans contamination :

une distribution Linux qui livre côte à côte des milliers de paquets sous des licences différentes ;
une image de conteneur contenant votre application et, séparément, des utilitaires GPL du système de base ;
un installeur qui dépose plusieurs exécutables indépendants.

La limite : l’agrégation cesse dès qu’il y a combinaison. Une image qui contient un binaire GPL que votre application se contente d’exécuter reste une agrégation. La même image où votre application est liée à une bibliothèque GPL ne l’est plus.

Chaque composant agrégé conserve en revanche ses propres obligations : l’agrégation ne dispense ni de l’attribution, ni de la fourniture du source pour les composants GPL présents.

5. Liaison statique contre liaison dynamique

Décisif pour la LGPL, et pour elle seule.

La LGPL autorise une application propriétaire à utiliser la bibliothèque, à condition que l’utilisateur puisse la remplacer par une version modifiée et faire fonctionner l’application avec.

Mode	Ce que vous devez fournir
Liaison dynamique	Rien de plus : l’utilisateur remplace la bibliothèque partagée. Le mode naturel.
Liaison statique	Les fichiers objets de votre application, ou tout moyen équivalent permettant à l’utilisateur de relier avec sa propre version de la bibliothèque.

Le point aveugle : de nombreux écosystèmes modernes ne connaissent que la liaison statique — Go, Rust, les bundles JavaScript, les applications mobiles, la plupart des micrologiciels. Dans ces contextes, la condition de remplacement est en pratique inatteignable, et la LGPL doit être traitée comme du copyleft fort.

6. Le produit de consommation et les informations d’installation

Mécanisme propre à GPL-3.0 et LGPL-3.0, article 6 — l’« anti-verrouillage ».

Si le logiciel est distribué dans un produit de consommation, vous devez fournir les informations d’installation : les méthodes, procédures, clés d’autorisation ou autres éléments nécessaires pour installer et exécuter une version modifiée sur ce produit.

Autrement dit : si l’appareil refuse de démarrer un logiciel que l’utilisateur a modifié, vous ne respectez pas la GPL-3.0.

C’est le mécanisme qui rend la GPL-3.0 problématique dans l’embarqué verrouillé et sur les plateformes à signature de code obligatoire — et qui explique pourquoi tant de projets embarqués restent délibérément en GPL-2.0. Voir Embarqué / IoT.

7. Les mesures techniques de protection

GPL-3.0, article 3 : le logiciel couvert ne doit pas être considéré comme faisant partie d’une mesure technique de protection, et vous renoncez au droit d’en interdire le contournement.

Conséquence directe : un composant GPL-3.0 ne peut pas participer à un dispositif de gestion des droits numériques. Point de friction récurrent avec les plateformes de distribution d’applications et avec les décodeurs.

8. Les clauses de brevets et leur résiliation

Présentes dans Apache-2.0 (article 3), GPL-3.0 (article 11), MPL-2.0 (article 2.1 b), EPL-2.0.

Deux effets, souvent ignorés des équipes techniques :

une concession : les contributeurs vous accordent une licence sur leurs brevets couvrant leur contribution ;
une résiliation : si vous engagez une action en contrefaçon de brevet contre un contributeur au sujet de ce logiciel, vous perdez cette concession, et parfois la licence entière.

Pour une entreprise qui détient un portefeuille de brevets, cette seconde clause est un sujet à part entière : elle peut neutraliser une stratégie contentieuse. Elle relève de la direction juridique, pas de l’équipe qui choisit la bibliothèque.

Tableau de synthèse

Quel mécanisme déclenche quelle famille :

Mécanisme	Permissive	MPL / EPL	LGPL	GPL	AGPL
Usage interne, sans transmission	—	—	—	—	—
Exposition réseau, sans transmission	—	—	—	—	✔
Distribution binaire	Attribution	Fichiers modifiés	Bibliothèque + remplacement	Œuvre entière	Œuvre entière
Liaison statique	—	—	✔ objets à fournir	✔	✔
Produit de consommation verrouillé	—	—	✔ en v3	✔ en v3	✔
Action en contrefaçon de brevet	Apache : résiliation	Résiliation	v3 : résiliation	v3 : résiliation	Résiliation

Ce qu’il faut en faire

Avant d’autoriser un composant, trois questions suffisent à instruire 90 % des dossiers :

Ce composant sortira-t-il de l’entreprise sous forme exécutable ?
Sera-t-il exposé à des utilisateurs par un réseau ?
Sera-t-il lié à votre code, et de quelle manière ?

Les réponses désignent le scénario applicable, et le scénario donne le verdict.