Introduction
Le logiciel open source est partout. Selon le rapport Synopsys 2024, 96 % des bases de code commerciales contiennent des composants open source. Pourtant, la majorité des développeurs et des entreprises ne lisent jamais les licences associées.
Or, toutes les licences open source ne se valent pas. Certaines vous laissent une liberté quasi totale, d'autres imposent des obligations contraignantes. Mal les comprendre peut exposer votre entreprise à des risques juridiques sérieux.
Les deux grandes familles de licences
Les licences permissives
Elles autorisent presque tout, y compris l'intégration dans des logiciels propriétaires. Les plus courantes :
MIT License
- La plus simple et la plus populaire (environ 28 % des projets GitHub)
- Vous pouvez utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre le logiciel
- Seule obligation : inclure la notice de copyright et la licence
- Utilisée par React, Node.js, jQuery, Rails
Apache License 2.0
- Similaire à MIT mais avec une clause de brevet explicite
- Les contributeurs accordent automatiquement une licence de brevet aux utilisateurs
- Si quelqu'un vous poursuit pour violation de brevet liée au logiciel, sa licence est automatiquement révoquée
- Utilisée par Android, Kubernetes, TensorFlow, Swift
BSD License (2-clause et 3-clause)
- Très proche de MIT
- La version 3-clause ajoute une interdiction d'utiliser le nom du projet pour promouvoir des produits dérivés
- Utilisée par FreeBSD, Nginx (historiquement), Flask
Les licences copyleft
Elles imposent que les œuvres dérivées soient distribuées sous la même licence. C'est le principe du « partage à l'identique ».
GPL v3 (GNU General Public License)
- La plus connue des licences copyleft
- Si vous modifiez et distribuez un logiciel GPL, vos modifications doivent aussi être sous GPL
- Le code source doit être rendu disponible
- Utilisée par Linux, WordPress, GIMP, Bash
LGPL (Lesser GPL)
- Version assouplie de la GPL
- Autorise la liaison (linking) avec du code propriétaire sans contamination
- Si vous modifiez la bibliothèque LGPL elle-même, les modifications doivent rester LGPL
- Utilisée par GTK, FFmpeg (certaines parties)
AGPL (Affero GPL)
- La plus restrictive : même l'utilisation côté serveur déclenche l'obligation de partage
- Si vous proposez un service en ligne utilisant du code AGPL, vous devez publier le code source
- Utilisée par MongoDB (historiquement), Nextcloud, Grafana
Tableau comparatif des licences
| Critère | MIT | Apache 2.0 | GPL v3 | LGPL | AGPL |
|---|---|---|---|---|---|
| Usage commercial | Oui | Oui | Oui | Oui | Oui |
| Modification | Oui | Oui | Oui | Oui | Oui |
| Distribution | Oui | Oui | Oui | Oui | Oui |
| Code source obligatoire | Non | Non | Oui | Partiel | Oui |
| Même licence obligatoire | Non | Non | Oui | Partiel | Oui |
| Protection brevet | Non | Oui | Oui | Oui | Oui |
| Usage serveur = distribution | Non | Non | Non | Non | Oui |
Les pièges courants
Le problème de la compatibilité
Toutes les licences ne sont pas compatibles entre elles. Vous ne pouvez pas combiner du code MIT et du code GPL dans un même projet et distribuer le résultat sous MIT — le résultat doit être sous GPL.
La Free Software Foundation maintient une liste de compatibilité. En règle générale :
- Le code permissif (MIT, BSD) peut être intégré dans du code copyleft (GPL)
- L'inverse est interdit
La « contamination » GPL
Le terme est controversé mais décrit un phénomène réel : si vous incluez du code GPL dans votre projet, l'ensemble du projet doit être distribué sous GPL. C'est pourquoi de nombreuses entreprises ont des politiques strictes concernant l'utilisation de code GPL.
Les licences Creative Commons pour le code
Les licences CC (Creative Commons) ne sont pas adaptées au code source. Elles sont conçues pour les œuvres créatives (textes, images, musique). Pour le code, utilisez toujours une licence logicielle reconnue par l'OSI (Open Source Initiative).
Comment choisir une licence pour votre projet
Pour maximiser l'adoption
Choisissez MIT ou Apache 2.0. La barrière d'entrée est minimale pour les utilisateurs et les entreprises.
Pour garantir que le code reste libre
Choisissez GPL v3. Les améliorations apportées par d'autres devront être partagées avec la communauté.
Pour un service en ligne
Choisissez AGPL si vous voulez que même les utilisateurs côté serveur partagent leurs modifications.
Pour une bibliothèque
Choisissez LGPL ou MIT. La LGPL permet d'imposer le partage des modifications de votre bibliothèque tout en autorisant son utilisation dans des projets propriétaires.
Les obligations pratiques
Ce que vous devez faire (quelle que soit la licence)
- Conserver les notices de copyright dans le code source et les binaires
- Inclure le texte de la licence dans votre distribution
- Documenter les composants open source utilisés (un fichier NOTICE ou THIRD-PARTY est recommandé)
Ce que vous devez faire en plus pour le copyleft
- Publier le code source des parties sous copyleft
- Indiquer les modifications apportées au code original
- Distribuer sous la même licence
Les outils de conformité
Plusieurs outils aident à gérer les licences open source :
- FOSSA : analyse automatique des dépendances et de leurs licences
- Snyk Open Source : détection des vulnérabilités et des licences à risque
- license-checker (npm) : liste les licences de toutes vos dépendances Node.js
- SPDX : standard d'identification des licences (Software Package Data Exchange)
Conclusion
Les licences open source sont le contrat social du logiciel libre. Les ignorer, c'est prendre un risque juridique ; les comprendre, c'est pouvoir tirer pleinement parti de l'écosystème open source tout en respectant le travail des autres développeurs. Prenez le temps de lire la licence avant d'intégrer un composant — et choisissez la vôtre en connaissance de cause.