Comprendre les licences open-source : le guide complet 2025

1. Introduction

Depuis plus de trente ans, les licences libres et open-source structurent l’économie numérique. Pourtant, les obligations juridiques qui en découlent restent mal comprises. En 2025, l’essor du “Everything-as-Code” et la généralisation des conteneurs rendent la conformité encore plus critique. Ce guide reprend les bases et livre des conseils pratiques, quel que soit votre niveau.

2. Permissives vs copyleft : deux philosophies

On distingue traditionnellement :

• Licences permissives : elles autorisent presque tout, y compris la ré-appropriation propriétaire, à condition de conserver le copyright et la notice. Ex. : MIT, BSD.
• Licences copyleft : elles imposent la réciprocité. Si vous distribuez un dérivé, vous devez le publier sous la même licence. Ex. : GPL, AGPL.

Le choix impacte votre modèle économique, notamment si vous vendez du SaaS ou des appliances.

3. Zoom sur les principales licences

3.1 MIT

Courte (≈ 170 lignes), très utilisée dans l’écosystème JavaScript. Obligation : inclure la notice et la mention de non-responsabilité. Compatible avec tout, y compris GPL.

3.2 Apache 2.0

Apporte la clause de patent grant : le concédant accorde gratuitement ses brevets nécessaires. Recommandée pour les projets d’entreprise. Voir la licence officielle.

3.3 GPLv3

Copyleft fort ; toute distribution d’un dérivé déclenche l’obligation de publier le code sous GPLv3. Inclut des sections anti-Tivoisation et un langage sur la gestion des brevets.

3.4 LGPLv3

Copyleft atténué : vous pouvez lier dynamiquement une bibliothèque LGPL à un soft propriétaire sans libérer celui-ci, tant que l’utilisateur peut remplacer la lib par une version modifiée.

3.5 AGPLv3

Étend le copyleft au SaaS : si vous modifiez un soft AGPL et le mettez à disposition via un service réseau, vous devez publier vos modifications. Très employé pour garantir la réciprocité dans le cloud.

3.6 BSD 2 & 3 clauses

Proches de MIT mais avec nuances sur l’utilisation du nom des contributeurs. Souvent choisies par des fondations académiques.

4. Compatibilités & dual-licensing

La compatibilité s’étudie dans les deux sens. Exemple : du code MIT peut entrer dans un projet GPL, mais l’inverse n’est pas vrai. Les éditeurs exploitent aussi le dual-licensing : une version communautaire copyleft (GPL) et une version commerciale propriétaire avec support premium.

Pour analyser rapidement les compatibilités, utilisez l’outil SPDX.

5. Quelles obligations légales ?

• Conserver les notices de copyright & licence.
• Fournir le code source (ou une offre écrite) si licence copyleft et distribution.
• Informer vos clients des éventuels brevets (Apache 2.0).
• Documenter vos dépendances (fichier LICENSES.html ou NOTICE).

Le non-respect peut entraîner une résolution automatique de la licence (termination clause). Les fondations OSI et FSF fournissent les textes originaux.

6. Check-list conformité 2025

1. Intégrer un audit SBOM (Software Bill of Materials) dans votre CI/CD.
2. Automatiser le scan des licences via FOSSA ou ScanCode.
3. Sensibiliser les devs : charte interne + fiche réflexe.
4. Mettre en place un processus de “third-party code approval”.
5. Prévoir un budget pour la gestion des correctifs de sécurité.

Besoin d’accompagnement ? Consultez notre guide migration open-source.

7. FAQ rapide

Une licence MIT est-elle compatible GPL ?

Oui. La GPL peut intégrer du code MIT, mais l’ensemble final doit être distribué sous GPL.

Dois-je ouvrir mon code si je modifie un soft GPL en interne ?

Non, tant que vous ne le distribuez pas hors de votre organisation.

8. Conclusion

Maîtriser les licences libres n’est pas qu’un enjeu juridique ; c’est aussi un levier de compétitivité. En 2025, les acheteurs IT exigent de plus en plus une gouvernance open-source claire. Anticiper la conformité, c’est gagner du temps… et éviter des litiges.

Pour aller plus loin, découvrez le dossier Les avantages stratégiques de l’open-source.

← Retour à l’accueil