Une licence logiciel est le contrat qui definit ce que vous avez le droit de faire avec un logiciel ou un composant : l'utiliser, le modifier, le redistribuer, ou l'integrer dans un produit commercial. Ignorer ce contrat n'est pas seulement un probleme juridique. Dans une chaine logicielle moderne ou votre application embarque des centaines de dependances open source, chaque type de licence logiciel qui passe sous le radar devient un risque de conformite et, parfois, un risque de securite.
Ce guide explique les grands types de licence, ce qui distingue les licences permissives des licences copyleft, et comment suivre tout cela concretement sans y passer vos journees.
Pourquoi la licence de logiciel concerne la securite
On associe la licence au juridique, mais l'equipe securite est directement concernee pour deux raisons.
D'abord, on ne peut pas securiser ce qu'on ne connait pas. L'inventaire des licences repose sur le meme inventaire de dependances que la gestion des vulnerabilites : si vous savez quelles bibliotheques vous embarquez et sous quelle licence, vous savez aussi quelles versions sont vulnerables. Le SBOM (Software Bill of Materials) sert les deux objectifs.
Ensuite, une obligation de licence mal respectee peut vous forcer a publier du code, a changer une dependance en urgence, ou a retirer une fonctionnalite. Ces changements de derniere minute sont exactement le genre d'operation precipitee qui introduit des failles.
Les grands types de licence
On peut classer la plupart des licences en trois familles.
Licences permissives. MIT, BSD, Apache 2.0. Elles vous laissent presque tout faire, y compris integrer le code dans un produit proprietaire, a condition de conserver l'avis de copyright. Apache 2.0 ajoute une clause explicite sur les brevets, ce qui est un atout pour un usage en entreprise.
Licences copyleft faible. LGPL, MPL 2.0, EPL. Vous pouvez lier ces composants a votre code proprietaire, mais les modifications apportees au composant lui-meme doivent rester ouvertes. Le copyleft est limite au fichier ou au module, pas a toute votre application.
Licences copyleft fort. GPL v2, GPL v3, AGPL. Si vous distribuez un produit qui integre du code sous GPL, l'ensemble de l'oeuvre derivee peut devoir etre publie sous la meme licence. L'AGPL etend cette obligation au cas ou le logiciel est simplement accessible via le reseau, ce qui vise directement les services SaaS.
Il existe aussi les licences dites source-available (BSL, SSPL) qui ne sont pas des licences open source au sens de l'OSI : elles restreignent certains usages commerciaux. A traiter avec attention.
Le piege du copyleft en SaaS
Beaucoup d'equipes pensent etre a l'abri parce qu'elles ne distribuent pas de binaire : leur produit tourne sur leurs propres serveurs. C'est vrai pour la GPL classique, dont l'obligation se declenche a la distribution. Mais l'AGPL a ete concue precisement pour ce cas : proposer un service en ligne construit sur un composant AGPL peut declencher l'obligation de fournir le code source aux utilisateurs. Un seul composant AGPL importe sans le savoir dans une dependance transitive peut donc changer vos obligations.
Le vrai defi : les dependances transitives
Le type de licence logiciel que vous choisissez pour votre propre projet est facile a maitriser. Le probleme, ce sont les licences que vous heritez sans les voir. Vous installez un paquet npm ou Maven sous licence MIT, mais ce paquet depend lui-meme de dix autres, dont un sous GPL. Ce composant profondement enfoui dans l'arbre porte une obligation que personne n'a lue.
C'est le meme angle mort que pour les vulnerabilites transitives. La reponse est la meme : automatiser l'inventaire. Un outil de SCA (analyse de composition logicielle) parcourt tout l'arbre de dependances, extrait la licence de chaque composant, et signale les licences interdites par votre politique. Un outil de SCA comme Safeguard peut ainsi remonter une licence GPL enfouie jusqu'au paquet de premier niveau qui l'a introduite.
Mettre en place une politique de licence
Une politique exploitable tient en quelques regles claires :
- Definir une liste blanche (MIT, BSD, Apache 2.0 autorisees d'office) et une liste noire (par exemple AGPL interdite pour un produit SaaS proprietaire).
- Marquer les licences copyleft fort comme necessitant une revue juridique avant integration.
- Bloquer automatiquement dans la CI toute nouvelle dependance dont la licence n'est pas approuvee.
- Generer un SBOM a chaque build pour garder une trace de ce que vous expediez.
Un exemple de verrou en integration continue :
# echec du build si une licence interdite apparait dans l'arbre
license-checker --failOn "GPL-3.0;AGPL-3.0" --production
L'idee est de transformer la conformite de licence en controle automatique, au meme titre qu'un test, plutot qu'en audit manuel annuel toujours en retard sur la realite du code.
Bonnes pratiques au quotidien
- Fixez les versions et validez un lockfile : une mise a jour peut changer la licence d'une dependance.
- Conservez les fichiers de licence et les avis de copyright exiges par les licences permissives.
- Reexaminez la politique quand vous changez de modele de distribution (passage on-premise vers SaaS, par exemple).
- Formez les developpeurs a verifier la licence avant d'ajouter une dependance, pas apres.
Bien gerer une licence de logiciel n'a rien de glamour, mais c'est le meme travail d'inventaire qui soutient toute votre securite applicative. Faites-le une fois, automatisez-le, et il cesse d'etre une source de mauvaises surprises.
FAQ
Quelle est la difference entre une licence permissive et copyleft ?
Une licence permissive (MIT, Apache 2.0) vous laisse integrer le code dans un produit proprietaire en conservant l'avis de copyright. Une licence copyleft (GPL, AGPL) exige que les oeuvres derivees que vous distribuez soient publiees sous la meme licence. Le copyleft faible (LGPL) limite cette obligation au composant modifie.
Puis-je utiliser un composant GPL dans un produit commercial ?
Vous pouvez l'utiliser en interne sans probleme. La contrainte apparait a la distribution : un produit distribue qui integre du code GPL peut devoir etre publie sous GPL. Pour un service SaaS, mefiez-vous surtout de l'AGPL, dont l'obligation se declenche meme sans distribution de binaire.
Comment connaitre toutes les licences de mon projet ?
Utilisez un outil de SCA ou un license-checker qui parcourt tout l'arbre de dependances, y compris les dependances transitives, et genere un SBOM. C'est le seul moyen fiable de voir les licences que vous heritez sans les avoir choisies.
Une licence logiciel a-t-elle un impact sur la securite ?
Indirectement, oui. La gestion des licences repose sur le meme inventaire de composants que la gestion des vulnerabilites, et une obligation de licence decouverte tardivement force des changements precipites qui introduisent souvent des failles. Traiter les deux avec le meme outillage est le plus efficace.