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, selon leurs termes, une logique de réciprocité. Si vous distribuez un dérivé, vous pouvez devoir le publier sous la même licence ou sous une licence compatible prévue. 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

Licence courte et très utilisée dans l’écosystème JavaScript. Obligation : inclure la notice et la mention de non-responsabilité. Compatible avec de nombreux usages, y compris dans certains projets GPL selon les conditions applicables.

3.2 Apache 2.0

Apporte la clause de patent grant : le texte prévoit une concession de brevets par les contributeurs, selon les conditions de la licence. Recommandée pour les projets d’entreprise. Voir la licence officielle.

3.3 GPLv3

Copyleft fort ; en cas de distribution d’un dérivé, la GPLv3 impose en principe de redistribuer le code sous GPLv3, selon les conditions de la licence. 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, dans les conditions prévues par la licence, notamment lorsque 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, la licence peut imposer de rendre disponibles vos modifications selon ses conditions. 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 généralement entrer dans un projet GPL, mais l’inverse dépend des conditions de redistribution et du projet cible. 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 identifiants et références de licences, utilisez la liste SPDX des licences.

5. Quelles obligations légales ?

• Conserver les notices de copyright & licence.
• Fournir le code source ou l’offre correspondante uniquement lorsque la licence applicable l’exige et dans les conditions prévues par cette licence.
• Prendre en compte les clauses de brevets lorsque la licence en contient, notamment Apache 2.0.
• Documenter vos dépendances (fichier LICENSES.html ou NOTICE).

Le non-respect peut entraîner la résiliation de la licence selon ses termes (termination clause). Pour vérifier les obligations applicables, référez-vous aux textes officiels, par exemple la GPLv3, la AGPLv3 ou la licence MIT.

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

Sources

• Texte officiel de la licence MIT
• Texte officiel de la licence Apache 2.0
• Texte officiel de la GNU GPLv3
• Texte officiel de la GNU LGPLv3
• Texte officiel de la GNU AGPLv3
• Texte officiel de la licence BSD 2-Clause
• Texte officiel de la licence BSD 3-Clause
• SPDX License List