GPL Risk
devsecopsDéfinition
GPL Risk (risque lié aux licences GPL) désigne les risques juridiques et commerciaux associés à l'utilisation de bibliothèques open source sous licence GPL (GNU General Public License) dans des projets logiciels, en particulier dans des produits commerciaux distribués. La GPL est une licence copyleft forte qui impose des obligations légales significatives pouvant affecter le modèle économique d'une organisation. La clause fondamentale de la GPL est le "copyleft" : tout logiciel qui incorpore, dérive ou distribue conjointement avec un logiciel sous GPL doit lui-même être distribué sous GPL — c'est l'obligation dite "virulente" de la GPL. Pour les logiciels propriétaires commerciaux, cette obligation peut être incompatible avec le modèle économique : distribuer le code source sous GPL pourrait exposer la propriété intellectuelle de l'organisation. La GPL existe en plusieurs versions aux implications légèrement différentes. GPL v2 (adoptée par Linux Kernel) est la plus répandue avec la clause "same license" stricte. GPL v3 ajoute des protections contre les brevets et les mesures anti-tivoisation, avec une compatibilité légèrement différente avec d'autres licences. AGPL v3 (Affero GPL) étend la GPL aux logiciels "en réseau" : même un service web utilisant une bibliothèque AGPL doit distribuer son code source (y compris aux utilisateurs qui accèdent via le réseau), sans nécessité de distribution de binaire. Le "GPL linking exception" est une pratique courante : certains projets GPL incluent une exception explicite autorisant le linking avec des logiciels propriétaires (ex : la Classpath Exception pour OpenJDK, permettant à des applications Java propriétaires d'utiliser la JDK sans obligations GPL). L'identification de ces exceptions dans les licences des bibliothèques est une tâche des outils SCA. Les cas limites de la GPL (qu'est-ce qu'un "dérivé" au sens légal ?) font l'objet de débats juridiques non tranchés : un logiciel qui ne fait que communiquer via API avec un logiciel GPL est-il un dérivé ? La réponse dépend du pays et n'est pas universellement établie, générant une incertitude juridique que les organisations gèrent via des politiques de licence strictes.
GPL, LGPL, AGPL : nuances et implications
GPL v2/v3 : tout logiciel distribuant du code GPL doit distribuer ses sources sous GPL (copyleft "fort"). LGPL (Lesser GPL) : l'obligation de copyleft s'applique seulement aux modifications de la bibliothèque elle-même, pas au code qui l'appelle via les interfaces publiques (linking dynamic est généralement considéré comme acceptable pour les logiciels propriétaires). AGPL : étend le copyleft aux services réseaux — utiliser une bibliothèque AGPL dans un SaaS oblige à publier le code du SaaS complet.
Gestion du GPL Risk en entreprise
La gestion du GPL Risk nécessite : 1) Un inventaire automatisé des licences via SCA (FOSSA, Black Duck, Snyk) pour chaque bibliothèque directe et transitive. 2) Une politique de licences documentée (GPL interdite pour les produits distribués, LGPL acceptable sous conditions, AGPL interdite pour les SaaS propriétaires). 3) Un processus de revue des exceptions pour les cas limites. 4) Des alternatives non-GPL pour les bibliothèques clés si nécessaire (ex : remplacer MySQL GPL par MariaDB ou PostgreSQL si les clauses GPL posent problème).
GPL et intégration dans les SBOM
Les SBOM (SPDX ou CycloneDX) incluent les informations de licence pour chaque composant. Cette traçabilité est essentielle pour les acquisitions (M&A due diligence sur les obligations open source) et les audits de conformité. Des outils comme FOSSA génèrent des rapports de licence détaillés identifiant chaque dépendance GPL/AGPL et son chemin de dépendance, permettant une évaluation précise des risques et la documentation des décisions de management pour chaque cas identifié.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.