Toutes les licences open source ne produisent pas les mêmes effets sur la propriété intellectuelle du logiciel qui les intègre. Certaines autorisent une exploitation propriétaire sans contrainte significative. D'autres imposent des obligations de redistribution qui peuvent s'étendre au logiciel intégrateur tout entier.
Cette distinction est déterminante pour toute entreprise qui développe un logiciel propriétaire à partir de composants open source. Qualifier juridiquement chaque licence avant de l'intégrer est un préalable simple, mais structurant. Cet article détaille les effets concrets des trois familles de licences à copyleft - GPL, AGPL et LGPL - et la méthode pour les qualifier.
GPL, AGPL, LGPL : les effets juridiques de chaque licence sur le logiciel propriétaire
Comprendre les différences entre ces trois licences permet d'évaluer précisément le périmètre de chaque obligation et d'arbitrer en connaissance de cause.
GPL v2 et GPL v3 : la redistribution intégrale du code dérivé
Les licences GPL (GNU General Public License) reposent sur un mécanisme de réciprocité. Elles autorisent l'utilisation, la modification et la redistribution du code source, à une condition : tout logiciel dérivé ou intégrant du code GPL doit lui-même être distribué sous licence GPL, avec mise à disposition du code source complet.
Le déclencheur est la distribution. Tant que le logiciel reste utilisé en interne, sans être distribué à des tiers, l'obligation ne s'applique pas. Dès que le logiciel est distribué - livré à un client, mis à disposition en téléchargement - l'obligation de redistribution s'active.
La GPL v3, publiée en 2007, ajoute des dispositions sur les brevets logiciels et les dispositifs de verrouillage technique (DRM). Elle est plus protectrice pour l'utilisateur final, mais aussi plus contraignante pour l'intégrateur.
Le périmètre de la contamination dépend du mode d'intégration. Une intégration statique (le code GPL est compilé avec le code propriétaire dans un même exécutable) déclenche quasi systématiquement l'obligation. Un lien dynamique (le composant GPL est chargé séparément à l'exécution) fait l'objet d'un débat juridique non tranché, la Free Software Foundation considérant qu'il déclenche également l'obligation.
AGPL v3 : l'extension au SaaS et à l'accès réseau
La licence AGPL (Affero GPL) comble une faille de la GPL classique. La GPL ne déclenche l'obligation de redistribution que lors de la distribution du logiciel. Or, un éditeur SaaS ne distribue pas son logiciel : les utilisateurs y accèdent via le réseau sans le télécharger.
L'AGPL v3 étend le mécanisme. Elle impose la mise à disposition du code source dès lors que le logiciel est accessible via un réseau, même sans distribution au sens classique. Pour un éditeur SaaS, l'effet est direct : intégrer un composant AGPL dans sa stack peut déclencher l'obligation de redistribuer l'ensemble du code source de l'application.
Cette licence mérite une vigilance particulière. Elle est présente dans des composants largement utilisés, y compris des bases de données et des bibliothèques de traitement de données. Son effet est souvent découvert tardivement, lors d'un audit de due diligence.
LGPL v2.1 : un copyleft limité à la bibliothèque
La licence LGPL (Lesser GPL) adopte une approche intermédiaire. Elle impose le copyleft sur la bibliothèque elle-même - toute modification de la bibliothèque doit être redistribuée sous LGPL - mais ne l'étend pas au logiciel qui l'utilise, sous certaines conditions.
La condition principale est le mode d'intégration. Si la bibliothèque LGPL est utilisée via un lien dynamique (chargée séparément à l'exécution), le logiciel propriétaire n'est pas contaminé. Si elle est intégrée par lien statique ou si son code est copié dans le logiciel, les obligations s'étendent.
La LGPL constitue un compromis fréquent dans les projets propriétaires. Elle permet d'utiliser des bibliothèques open source éprouvées sans compromettre la maîtrise de l'actif logiciel, à condition de respecter les contraintes d'intégration.
Et les licences permissives ?
Les licences MIT, Apache 2.0 et BSD fonctionnent différemment. Elles n'imposent aucune obligation de redistribution du code source. Leurs contraintes se limitent généralement à la mention de l'auteur original et à la reproduction du texte de la licence. Elles sont pleinement compatibles avec un modèle d'exploitation propriétaire et ne soulèvent pas de difficulté en due diligence.
Comment qualifier juridiquement une licence avant intégration ?
La qualification n'est utile que si elle débouche sur une décision documentée. Voici la méthode en quatre étapes.
Première étape : identifier la licence exacte, version comprise. GPL v2 et GPL v3 ne produisent pas les mêmes effets. La clause "or any later version" présente dans certains composants permet de choisir la version applicable, ce qui modifie le périmètre des obligations. Le fichier LICENSE à la racine du composant est la source de référence.
Deuxième étape : qualifier le mode d'intégration prévu. Le composant sera-t-il lié statiquement, dynamiquement, appelé via une API, ou son code sera-t-il copié dans le projet ? Ce mode d'intégration détermine l'étendue de la contamination. Un même composant sous la même licence peut produire des effets juridiques différents selon la manière dont il est intégré.
Troisième étape : croiser licence et mode d'intégration. C'est le croisement des deux paramètres qui détermine l'effet juridique réel. Une bibliothèque LGPL en lien dynamique ne pose pas de problème. La même bibliothèque intégrée statiquement change la donne. Ce croisement peut être formalisé dans un tableau de décision simple, partagé avec l'équipe technique.
Quatrième étape : documenter la décision. Chaque arbitrage - intégrer, remplacer ou isoler un composant - est consigné dans le registre PI de l'entreprise avec la justification associée. Cette documentation est précieuse en due diligence : elle démontre que les choix techniques ont été faits en connaissance de cause.
Les trois premières étapes relèvent du CTO ou du responsable technique. La quatrième gagne à impliquer un conseil juridique, notamment lorsque le mode d'intégration est ambigu ou lorsque le composant occupe une place centrale dans l'architecture.
Points d'attention pour le dirigeant
Trois sujets méritent une vigilance particulière, au-delà de la qualification licence par licence.
Les dépendances transitives. Un composant sous licence permissive peut lui-même dépendre d'une bibliothèque sous GPL. Cette dépendance indirecte - parfois enfouie sur plusieurs niveaux - peut déclencher une obligation de redistribution inattendue. Les outils d'analyse de composition logicielle (Software Composition Analysis) détectent ces dépendances transitives. Les vérifier fait partie de la qualification.
Le dual-licensing. Certains éditeurs de composants open source proposent deux licences : une licence copyleft (GPL ou AGPL) pour l'usage communautaire, et une licence commerciale payante pour l'usage propriétaire. Cette option permet d'utiliser le composant sans les contraintes du copyleft, moyennant une redevance. Elle représente parfois la solution la plus efficace lorsque le composant est difficile à remplacer.
La compatibilité entre licences. GPL v2 et GPL v3 ne sont pas systématiquement intercompatibles. Combiner des composants sous des licences copyleft différentes peut créer des conflits juridiques. Ce sujet technique nécessite une analyse au cas par cas lorsque le projet utilise plusieurs composants à copyleft.
Conclusion
La qualification juridique des licences open source contaminantes repose sur deux paramètres : le type de licence et le mode d'intégration. Ce croisement détermine si l'entreprise conserve la pleine maîtrise de son actif logiciel ou si des obligations de redistribution s'appliquent.
La démarche est accessible. Elle ne demande pas de renoncer à l'open source, mais de l'utiliser en connaissance de cause. Pour les entreprises qui préparent une levée de fonds ou une cession, cette qualification constitue un maillon essentiel de la sécurisation de la PI logicielle.
--
FAQ
Quelle différence entre une licence open source permissive et une licence copyleft ?
Une licence permissive (MIT, Apache 2.0, BSD) autorise l'intégration dans un logiciel propriétaire sans obligation de redistribution du code source. Une licence copyleft (GPL, AGPL) impose que le logiciel dérivé soit distribué sous la même licence, avec mise à disposition du code source. La différence porte sur l'obligation de réciprocité.
La licence AGPL s'applique-t-elle aux logiciels SaaS qui ne sont pas distribués ?
Oui. C'est précisément l'objet de l'AGPL v3. Elle étend l'obligation de redistribution du code source aux logiciels accessibles via un réseau, même sans distribution au sens classique. Un éditeur SaaS qui intègre un composant AGPL peut être tenu de mettre son code source à disposition des utilisateurs.
Un logiciel utilisant une bibliothèque LGPL peut-il rester propriétaire ?
Oui, sous conditions. Si la bibliothèque LGPL est utilisée via un lien dynamique, le logiciel propriétaire n'est pas soumis au copyleft. Seules les modifications apportées à la bibliothèque elle-même doivent être redistribuées sous LGPL. En revanche, une intégration par lien statique ou copie de code peut étendre les obligations au logiciel intégrateur.
Comment vérifier les licences des dépendances transitives d'un projet logiciel ?
Les outils d'analyse de composition logicielle (Software Composition Analysis) scannent l'arbre complet des dépendances d'un projet et identifient les licences associées à chaque composant, y compris les dépendances indirectes. Cette vérification est à intégrer dans le processus de qualification, car un composant permissif peut dépendre d'une bibliothèque sous licence copyleft.
