Une licence logicielle est le contrat qui definit ce que vous avez le droit de faire avec un logiciel : l'utiliser, le modifier, le redistribuer, et sous quelles conditions. Dans une application moderne, ce n'est pas une mais des centaines de licences logicielles qui s'appliquent en meme temps, car chaque dependance open source arrive avec la sienne. Ignorer cette realite, c'est s'exposer a un risque juridique et de securite bien reel : une obligation copyleft mal comprise peut vous forcer a ouvrir votre code source, et une licence absente peut cacher un composant que personne n'a le droit d'utiliser.
Qu'est-ce qu'une licence logicielle, concretement
Une licence logicielle accorde des droits d'usage sans transferer la propriete. L'auteur reste titulaire du droit d'auteur ; vous obtenez la permission d'utiliser son travail selon des regles. Ces regles varient enormement d'une licence a l'autre, et c'est precisement la que naissent les problemes.
Il faut distinguer trois grandes familles :
- Les licences permissives (MIT, BSD, Apache 2.0). Elles imposent peu de contraintes : en general, conserver l'avis de droit d'auteur suffit. Vous pouvez integrer le code dans un produit proprietaire sans obligation de publier le votre.
- Les licences copyleft (GPL, LGPL, AGPL). Elles exigent que le code derive soit distribue sous la meme licence. L'AGPL va plus loin en couvrant meme l'usage via un service reseau, ce qui surprend beaucoup d'equipes SaaS.
- Les licences proprietaires. Le fournisseur fixe des conditions specifiques, souvent avec des restrictions d'usage, de nombre d'utilisateurs ou de redistribution.
Une licence logicielle appartient presque toujours a l'une de ces categories, mais les nuances comptent : Apache 2.0 inclut une clause de brevet que MIT n'a pas, et LGPL autorise l'edition de liens dynamiques la ou GPL ne le fait pas.
Pourquoi une licence logicielle est un enjeu de securite
On associe la securite aux vulnerabilites, pas aux licences. C'est une erreur. Le risque de licence et le risque de vulnerabilite proviennent de la meme source : les dependances open source que vous ne controlez pas directement.
Trois scenarios concrets :
Le premier est l'obligation copyleft non maitrisee. Si une bibliotheque sous GPL se retrouve liee a votre produit proprietaire distribue, vous pouvez etre contraint juridiquement de publier votre propre code. Une licence logicielle copyleft dans la mauvaise dependance transitive peut ainsi transformer un produit ferme en obligation d'ouverture.
Le deuxieme est le composant sans licence. Un paquet publie sans aucune licence n'est pas "libre" par defaut : en l'absence de licence, le droit d'auteur classique s'applique et vous n'avez, en theorie, aucun droit de l'utiliser. C'est un angle mort frequent.
Le troisieme est le changement de licence en cours de route. Plusieurs projets majeurs ont modifie leur licence entre deux versions, passant d'une licence permissive a une licence restrictive. Une mise a jour de dependance qui semble anodine peut ainsi vous faire basculer, sans que personne s'en apercoive, vers des conditions que votre entreprise n'accepte pas.
Le SBOM : la base de la gestion des licences
On ne peut pas gerer ce qu'on ne voit pas. La reponse pratique est le SBOM (Software Bill of Materials), l'inventaire complet des composants de votre application avec, pour chacun, sa version et sa licence.
Un SBOM au format standard comme CycloneDX ou SPDX permet de repondre en quelques secondes a des questions qui prenaient des jours : quelles licences copyleft avons-nous ? Quels composants n'ont pas de licence declaree ? Une nouvelle version a-t-elle change de licence par rapport a la precedente ?
Genere automatiquement a chaque build, le SBOM devient un instantane fiable plutot qu'un audit ponctuel realise une fois par an et deja perime. C'est aussi une exigence croissante des clients et des reglementations, qui demandent de plus en plus la tracabilite des composants logiciels.
Definir une politique de licences
L'inventaire ne suffit pas ; il faut une politique qui decide automatiquement ce qui est acceptable. Une approche courante consiste a classer les licences en trois listes :
- Autorisees sans revue (MIT, BSD, Apache 2.0 dans la plupart des contextes commerciaux).
- A revoir au cas par cas (LGPL, MPL, selon la maniere dont le composant est integre).
- Interdites par defaut (AGPL pour un SaaS proprietaire, licences sans texte clair, licences avec restrictions d'usage incompatibles).
Cette politique, appliquee dans le pipeline CI/CD, bloque l'introduction d'une licence problematique avant la fusion, au moment ou la correction coute le moins cher. Un outil de SCA comme Safeguard peut evaluer chaque dependance, y compris transitive, par rapport a cette politique et signaler une licence non conforme avant la mise en production.
Mettre en place la verification en continu
La gestion des licences n'est pas un projet ponctuel mais un controle permanent. Concretement :
- Generez un SBOM a chaque build et conservez l'historique.
- Faites echouer la CI lorsqu'une licence interdite apparait, y compris dans une dependance transitive.
- Revoyez les changements de licence lors des montees de version, au lieu de les fusionner automatiquement.
Cette discipline evite le scenario le plus penible : decouvrir une obligation copyleft au moment d'un audit de diligence raisonnable, alors que le composant est deja profondement integre. Pour aller plus loin sur la gestion des dependances open source, notre page produit SCA et l'Academy detaillent la methode.
FAQ
Une licence logicielle open source signifie-t-elle "gratuit et sans contrainte" ?
Non. Open source signifie que le code est accessible et que la licence accorde certains droits, mais ces droits s'accompagnent de conditions. Une licence copyleft comme la GPL impose des obligations fortes, notamment la redistribution sous la meme licence.
Que se passe-t-il si une dependance n'a aucune licence ?
En l'absence de licence explicite, le droit d'auteur par defaut s'applique et vous n'avez, en principe, pas le droit d'utiliser, copier ou redistribuer le composant. Un composant sans licence doit etre traite comme un risque, pas comme un logiciel libre.
Comment savoir quelles licences se trouvent dans mon application ?
En generant un SBOM. Cet inventaire liste chaque composant avec sa licence, y compris les dependances transitives que vous n'avez jamais ajoutees directement. C'est le point de depart de toute gestion de conformite serieuse.
La licence AGPL est-elle un probleme pour un service SaaS ?
Souvent, oui. L'AGPL etend les obligations copyleft a l'usage via un reseau : proposer un service base sur du code AGPL peut vous obliger a en publier le code source. Beaucoup d'entreprises SaaS l'interdisent par defaut dans leur politique de licences.