Open source et SaaS : maîtriser les risques des licences GPL/AGPL

En 2026, la quasi‑totalité des SaaS reposent sur de l’open source. Mais toutes les licences ne se valent pas. Les licences à « réciprocité » (copyleft) — GPL, AGPL, et dans une moindre mesure LGPL — peuvent imposer la mise à disposition du code source dérivé, y compris sans distribution classique pour l’AGPL. Mal gérées, elles exposent à la contrefaçon, à des injonctions de retrait et à des dommages‑intérêts.

Licences « restrictives » : de quoi parle‑t‑on exactement ?

Les licences copyleft imposent, sous conditions, que les œuvres dérivées soient licenciées sous les mêmes termes et que leur code source soit accessible. On distingue :

• Copyleft fort : GPL v2/v3 (au moment de la distribution) et AGPL v3 (même sans distribution, en cas d’accès via un réseau).
• Copyleft faible : LGPL, qui tolère le lien avec du code propriétaire sous conditions (possibilité de relier/mettre à jour la bibliothèque, communication des modifications de la bibliothèque, etc.).

Pour un panorama pédagogique, voyez l’INPI sur le statut du logiciel et les licences et les ressources de l’OSOR (Commission européenne). En droit, les logiciels sont protégés par le droit d’auteur (UE : directive 2009/24/CE ; France : CPI – droits exclusifs sur le logiciel).

Pourquoi le modèle SaaS est particulièrement exposé (AGPL)

En SaaS, on pense souvent « pas de distribution = pas d’obligation GPL ». C’est fréquemment vrai pour la GPL classique côté serveur. Mais l’AGPL ferme la « faille ASP » : si des utilisateurs interagissent avec votre logiciel sur un réseau, vous devez leur offrir l’accès au code source correspondant. Ce point est central pour toute brique AGPL utilisée côté back‑end ou pour du JavaScript exécuté chez l’utilisateur via le navigateur.

Les autorités françaises et européennes promeuvent l’open source tout en rappelant l’exigence de conformité : l’ANSSI met à jour sa politique open source et recommande une gouvernance outillée ; la CNIL insiste sur la transparence et la maîtrise des composants.

Les risques juridiques concrets en France et dans l’UE

• Perte de licence et contrefaçon : le non‑respect des conditions de licence peut entraîner la résolution de la licence et vous placer en situation d’utilisation sans droit. En France, la contrefaçon est pénalement réprimée (art. L. 335‑2 CPI) et civilement sanctionnée (injonction de cesser, dommages‑intérêts, retrait).
• Effet « viral » : l’intégration d’une bibliothèque copyleft dans un module propriétaire peut imposer la publication du code dérivé. L’AGPL étend cette logique à l’accès réseau.
• Conformité « produit » : avec le futur Règlement européen sur la cyber‑résilience (Cyber Resilience Act), les attentes en matière de sécurité, de gestion des vulnérabilités et de traçabilité des composants (SBOM) se renforcent au niveau UE (voir EUR‑Lex).
• Réputation et coûts : publication contrainte du code, réécriture accélérée, suspension de fonctionnalités et négociations en urgence avec les titulaires de droits.

La jurisprudence française admet de longue date l’exécutabilité et les sanctions en cas de non‑respect des licences libres, sur le terrain du droit d’auteur. Le cadre est également consolidé par la directive (UE) 2019/790 (DSM), qui modernise certains mécanismes de droit d’auteur à l’ère numérique.

Situations à risque typiques en SaaS

• Microservice AGPL dans le back‑end : si des utilisateurs interagissent avec ce service via votre application, l’obligation d’offrir le code source complet du service concerné peut s’appliquer.
• Agent/SDK déployé chez le client : distribuer un binaire intégrant une bibliothèque GPL déclenche les obligations de distribution du code source correspondant (et potentiellement du code lié).
• Bibliothèque LGPL modifiée : vous devez publier les modifications de la bibliothèque et permettre le relinkage. Le simple « lien dynamique » ne suffit pas toujours à écarter le risque si l’architecture empêche toute reliaison effective.
• JavaScript AGPL côté client : le code téléchargé par le navigateur est une distribution ; l’AGPL peut exiger de rendre disponible le code source complet correspondant.
• Copier‑coller/IA générative : un snippet introduit sous GPL/AGPL contamine le module receveur. D’où la nécessité d’auditer aussi le code généré par IA.

Méthode de conformité « zéro surprise » (tech + juridique)

1) Cartographier et classer

• Inventaire exhaustif des composants (y compris transitive deps) et génération d’un SBOM outillé. L’ANSSI recommande la gestion maîtrisée des dépendances et des vulnérabilités.
• Classification des licences : permissives (MIT, BSD, Apache‑2.0) = faible risque ; copyleft faible (LGPL) = risque moyen et conditions techniques ; copyleft fort (GPL/AGPL) = risque élevé en SaaS.

2) Décider et remédier

• Politique « licences approuvées/interdites » par famille de produit. Interdire l’AGPL dans le back‑end SaaS, et la GPL si distribution d’agents.
• Alternatives et dual licensing : envisager des bibliothèques permissives ou acquérir une licence commerciale quand le projet open source le propose.
• Isolation architecturale : séparer par processus, API réseau et formats ouverts. Attention : l’AGPL déclenche ses obligations même en cas de séparation réseau.

3) Outiller le cycle de vie

• CI/CD avec scans de licences bloquants et revue humaine pour les cas limites.
• Process d’approbation pour toute nouvelle dépendance « à risque » et revue des snippets/IA.
• Notices et attributions systématiques (Apache‑2.0 : NOTICE, etc.).

4) Contractualiser et gouverner

• Clauses avec sous‑traitants (intégrateurs, freelances, éditeurs tiers) : respect de votre politique open source, SBOM obligatoire, interdiction des copyleft forts sans accord écrit, assistance en cas de réclamation, indemnisation. Voir nos bonnes pratiques pour gérer les dépendances dans les contrats de sous‑traitance techniques.
• Contrats clients SaaS : prévoir un droit de correction/suspension d’une fonctionnalité en cas de réclamation tierce, une garantie limitée sur les composants open source, des obligations de mise à jour de sécurité, et une limitation de responsabilité adaptée. Consultez les clauses essentielles d’un contrat SaaS et pourquoi éviter les modèles génériques.
• Politique interne validée par le juridique et la tech, formation des équipes, et journalisation des décisions.

Pour cadrer juridiquement vos droits d’usage et de distribution, relisez les fondements du contrat de licence logiciel (SaaS, open source et propriétaire) et protégez vos actifs stratégiques : protection du code source par le droit d’auteur.

Que faire si une bibliothèque GPL/AGPL est déjà dans votre SaaS ?

1. Geler les releases et ouvrir une task force tech/juridique.
2. Qualifier l’usage : serveur uniquement ? interaction réseau ? distribution d’agents/SDK ? modifications apportées ?
3. Décider : (a) remplacer par une alternative permissive ; (b) isoler le composant pour limiter l’œuvre dérivée ; (c) se conformer (publication du code requis) ; (d) obtenir une licence commerciale.
4. Mettre en conformité : fournir le code source correspondant, les notices, et les moyens de reliaison (LGPL).
5. Documenter et ajuster la politique open source pour éviter la récidive.

Notez que l’ANSSI encourage une approche outillée et pragmatique, et que le cadre de sécurité de développement logiciel (guide ANSSI) rejoint les bonnes pratiques de gestion des dépendances et SBOM. Les exigences européennes en matière de sécurité logicielle (voir EUR‑Lex) vont dans le même sens.

Checklist 30 jours pour CTO/GC

• Semaine 1 : SBOM complet, y compris transitive deps et code front‑end.
• Semaine 2 : matrice de compatibilité licences × modèles d’usage (SaaS pur, agent, on‑prem, mobile/SDK).
• Semaine 3 : remédiations prioritaires (AGPL côté serveur/JS, GPL dans agents), choix d’alternatives, plan de remplacement.
• Semaine 4 : mise à jour des contrats (clients et sous‑traitants), notices OSS, pipeline CI de scans bloquants, formation devs + politique open source signée.

Points de droit à garder en tête

• Les droits exclusifs de l’auteur sur le logiciel s’exercent pleinement en matière de licences libres : voir CPI et la directive 2009/24/CE.
• Le non‑respect d’une licence libre expose à la contrefaçon (L. 335‑2 CPI), avec injonctions et dommages‑intérêts.
• L’ANSSI et la Commission européenne (via l’OSOR) promeuvent l’open source responsable et la gouvernance documentaire.
• La CNIL rappelle que la conformité logicielle participe à la sécurité et à la confiance, notamment en environnement data/IA.

FAQ rapide

Puis‑je utiliser une bibliothèque GPL côté serveur sans publier mon code ?

Souvent oui si vous ne distribuez rien et qu’il ne s’agit pas d’AGPL. Mais attention aux agents, SDK, plug‑ins, images distribuées et au code front‑end : ces cas déclenchent des obligations.

L’AGPL m’oblige‑t‑elle à tout publier ?

Elle impose d’offrir le code source du programme auquel l’utilisateur accède via le réseau. L’étendue exacte dépend de l’architecture et des interactions entre composants.

La LGPL est‑elle « sûre » pour un SaaS ?

Moins risquée que GPL/AGPL, mais obligations spécifiques : publier les modifications de la bibliothèque, permettre le relinkage et la mise à jour indépendante.

Que faire en cas de mise en demeure ?

Geler les livraisons, auditer, qualifier l’usage, corriger (ou remplacer), négocier si besoin une licence commerciale et mettre en place une politique de conformité.

Les licences permissives (MIT/Apache) posent‑elles des contraintes ?

Oui, des attributions et parfois des obligations spécifiques (NOTICE d’Apache‑2.0). Elles sont toutefois nettement plus compatibles avec un modèle SaaS propriétaire.

Besoin d’un audit express de vos dépendances et contrats ? Contactez‑nous : nous adaptons vos CGV/contrats SaaS et vos clauses open source à votre architecture et à vos risques.