Il existe un moment qui finit par arriver dans presque tout projet d’envergure. Quelqu’un — généralement un juriste ou un acheteur nerveux — demande : « Quelle licence doit porter ce code ? »

Jusque-là tout allait merveilleusement. Code écrit, tests verts, dépôt poussé. Et soudain des gens débattent de copyleft, de clauses de brevets et d’œuvres dérivées comme si tout en dépendait.

En un sens, tout en dépend effectivement.

Les licences ne sont pas des formalités. Elles sont les règles du jeu auxquelles un logiciel existe. Celui qui les ignore joue quand même — selon des règles choisies par quelqu’un d’autre.

Pourquoi il y a tant de licences

La réponse courte : parce que le logiciel libre a connu deux mouvements qui n’ont jamais été tout à fait les mêmes.

D’un côté, Richard Stallman et la Free Software Foundation, fondée en 1985, avec une posture éthique claire : un logiciel qu’il est impossible d’étudier, de modifier et de redistribuer prive ses utilisateurs de libertés fondamentales. De là est née la GPL — copyleft fort, contagieux, sans compromis.

De l’autre côté, les pragmatiques issus de la tradition Unix de Berkeley puis, plus tard, l’Open Source Initiative (OSI, 1998), qui considéraient le logiciel libre davantage comme un modèle de développement efficace que comme un impératif moral. De là sont venues les licences permissives — MIT, BSD — courtes, libérales, favorables à la commercialisation.

Entre ces pôles s’est constitué un spectre. S’y sont ajoutés avocats, intérêts d’entreprise, brevets, problèmes de compatibilité et l’éternelle envie de réinventer la roue. Aujourd’hui SPDX recense plus de trois cents identifiants de licences valides. Personne ne les connaît toutes. Personne n’a besoin de toutes les connaître. Mais chacun devrait connaître les importantes.

Deux familles, une seule question fondamentale

Au cœur de chaque licence se trouve la même interrogation : *Que peut faire autrui de mon code — et que doit-il rendre en retour ? *

Les licences permissives libèrent presque tout. Utiliser, modifier, vendre, intégrer dans des produits propriétaires — tant que mon nom reste dans la mention de copyright. Donnez-moi reconnaissance, gardez le reste.

Les licences à copyleft exigent en revanche la réciprocité. Celui qui modifie mon code et le redistribue doit publier ses versions sous la même licence. Ce que tu as reçu, tu le repasses.

Les licences à copyleft faible se situent entre les deux : elles n’infectent que la bibliothèque, pas le programme qui l’utilise. Un compromis qui protège les auteurs de bibliothèques sans aliéner les consommateurs.

Avec cette grille, les licences familières trouvent naturellement leur place.

Les licences qu’il faut connaître

MIT. La licence sérieuse la plus courte du monde. Environ 170 mots. Autorise pratiquement tout, exige seulement la mention de copyright. React, Ruby on Rails, jQuery, les bibliothèques clientes Kubernetes — tout est MIT. Qui veut une diffusion maximale choisit MIT.

BSD. Existe en trois variantes pertinentes. La forme à deux clauses est en pratique équivalente à MIT. La forme à trois clauses interdit en outre l’utilisation du nom de l’auteur pour promouvoir des œuvres dérivées. La variante historique à quatre clauses exigeait une mention dans toute publicité de produit — ce qui produisait des avis de copyright absurdes sur des centaines de dépendances et rendait longtemps le code BSD inutilisable dans des projets GPL. FreeBSD, nginx, PostgreSQL utilisent des variantes BSD.

Apache 2.0. Le membre adulte de la famille permissive. Publiée en 2004, elle complète MIT et BSD par trois éléments importants en pratique : une concession explicite de brevets (tout contributeur accorde ses brevets aux utilisateurs), une clause de représailles (celui qui attaque en matière de brevets perd ses droits) et la tenue d’un fichier NOTICE pour les attributions. Apache Kafka, le cœur de Kubernetes, TensorFlow sont sous Apache 2.0. Souvent le meilleur choix pour les piles commerciales.

GPL v2. Depuis 1991, le ciment du noyau Linux. Copyleft fort : celui qui distribue des œuvres dérivées doit également publier leur code source complet sous GPL v2. Volontairement concise, volontairement sans clause de brevet. Sa disposition la plus célèbre est surnommée « Liberty or Death » — si vous ne pouvez pas respecter les conditions, vous ne pouvez rien redistribuer du tout.

GPL v3. Révisée en 2007 après que les brevets, les DRM et les appareils verrouillés (« tivoïsation ») eurent ouvert de nouvelles attaques contre le logiciel libre. Elle a ajouté la concession de brevets, exigé la mise à disposition des informations d’installation pour les appareils, codifié des clauses anti-contournement et amélioré la compatibilité avec d’autres licences. Politiquement contestée, juridiquement plus propre. Nombre de projets phares sont restés en v2 (Linux), d’autres ont migré (Bash, GCC, Samba).

LGPL v2.1 et v3. Les variantes « Lesser ». Copyleft faible pour les bibliothèques : celui qui modifie la bibliothèque et la redistribue doit placer ses modifications sous LGPL — mais les programmes qui se contentent de lier la bibliothèque peuvent rester propriétaires. Le compromis classique : protéger la bibliothèque, laisser le consommateur libre. glibc, GTK, Qt (par moments) sont sous LGPL.

MPL 2.0. La licence maison de Mozilla, janvier 2012. Copyleft faible au niveau du fichier : celui qui modifie des fichiers MPL individuels et les redistribue doit publier ces fichiers sous MPL — le reste d’un programme peut demeurer propriétaire. Clairement rédigée, pragmatique, prisée des consortiums industriels. Firefox, Thunderbird et de nombreux crates Rust utilisent MPL.

AGPL v3. La GPL réseau. Elle referme la fameuse faille ASP : le copyleft classique ne se déclenche qu’à la distribution du logiciel. Celui qui se contente de l’héberger en tant que service ne distribue rien — et ne devait donc jusqu’alors aucune divulgation de source. L’AGPL a inversé cela : l’usage réseau lui-même déclenche l’obligation de divulgation. Prisée par les fournisseurs SaaS souhaitant dissuader les concurrents d’héberger leur travail sans autorisation. Mastodon, Nextcloud, Plausible Analytics, MinIO.

EPL. L’Eclipse Public License, héritière de la tradition IBM, actuellement en version 2.0. Copyleft faible semblable au MPL, avec une concession de brevets claire et une convivialité commerciale explicite. Eclipse IDE, Jakarta EE, la plupart des projets de la fondation Java, les JDK Adoptium/Temurin. Fréquemment l’alternative pragmatique lorsque la GPL semble risquée commercialement mais que BSD apparaît trop permissif.

Unlicense et CC0. Les radicales. Toutes deux renoncent entièrement au droit d’auteur — dans la mesure où cela est même possible dans certains pays. Unlicense (2010) vise directement les logiciels, CC0 (2009, Creative Commons) visait initialement les données, œuvres artistiques et textes. Toutes deux partagent une faiblesse : là où le droit d’auteur est inaliénable (Allemagne notamment), une incertitude juridique subsiste. Par ailleurs, CC0 ne contient pas de clause de brevet. Pour des systèmes de production robustes, MIT est donc généralement préférable à CC0.

Ce que les licences restreignent ou permettent

Concrètement, les licences orientent cinq axes :

  1. Utilisation — Puis-je l’utiliser commercialement ? Pour toutes celles évoquées ici : oui.
  2. Modification — Puis-je modifier le code ? Oui, partout.
  3. Distribution — Sous quelles conditions ? Ici le troupeau se sépare.
  4. Brevets — Reçois-je une concession de brevet explicite ? Seulement Apache 2.0, GPLv3, MPL 2.0, EPL 2.0, AGPL v3.
  5. Usage réseau — L’hébergement déclenche-t-il une obligation de divulgation ? Seulement l’AGPL.

À quoi s’ajoutent des points annexes : marques déposées (toujours conservées par le projet d’origine), exonération de responsabilité (partout), attribution (partout) et compatibilité mutuelle — un domaine entier dans lequel des cabinets d’avocats entiers gagnent leur vie. La vérité amère : les licences ne sont pas nécessairement combinables. Du code GPLv2 ne peut être fusionné avec du code Apache 2.0 sans une exemption. CDDL et GPL sont jugées incompatibles — la base de querelles de plusieurs années autour de ZFS-sur-Linux.

Des histoires qu’il faut connaître

Le massacre BusyBox. À partir de 2007, Erik Andersen, la Software Freedom Law Center puis plus tard la Software Freedom Conservancy ont poursuivi environ quatorze fabricants d’électronique — Verizon, Samsung, Best Buy, Westinghouse — pour avoir livré routeurs, enregistreurs vidéo et caméras embarquant BusyBox sans divulguer le code source modifié. Les procès se sont soldés par des transactions financières et des injonctions fondatrices. Ils ont démontré : la GPL est applicable. Prendre du code copyleft et ignorer ses conditions comporte un risque juridique réel.

Le Linksys WRT54G et la naissance d’OpenWrt. En 2003, des bricoleurs découvrent que le routeur Wi-Fi extrêmement populaire Linksys WRT54G fonctionnait en interne sous Linux et BusyBox — tous deux sous GPL. Linksys, devenu filiale de Cisco, n’avait pas publié le code source. Après une démarche de la Free Software Foundation et de Bradley Kuhn, Cisco finit par publier l’arborescence complète. Ce qui commença comme un événement de conformité devint l’un des moments les plus féconds de l’informatique grand public : du code libéré naquirent OpenWrt, DD-WRT, Tomato et toute une génération de microprogrammes routeurs open source. Des millions d’appareils que leurs fabricants ont depuis longtemps oubliés sont encore entretenus par une communauté aujourd’hui. Leçon : le copyleft imposé ne produit pas seulement la conformité — il peut libérer tout un écosystème.

L’épisode React BSD-plus-Brevets. Facebook a publié React en 2013 d’abord sous Apache 2.0, puis en 2014 est passé à une licence BSD modifiée assortie d’un cavalier de brevets : quiconque attaquait Facebook pour violation de brevet perdait instantanément ses droits sur React. En juillet 2017, l’Apache Software Foundation, suivie par Jenkins, WordPress et d’autres, a déclaré la chose intenable. En quelques semaines, React a perdu une part substantielle de la confiance institutionnelle. En septembre 2017, Facebook a capitulé et placé React, Jest, GraphQL et Immutable.js sous pur MIT. Leçon : une licence cachant des clauses asymétriques peut menacer un écosystème entier.

Le revirement de HashiCorp. En août 2023, HashiCorp a annoncé que Terraform, Vault, Consul et d’autres projets passeraient de MPL 2.0 à la Business Source License (BSL) — une licence à source disponible interdisant aux concurrents de proposer des services gérés concurrents. Pendant des années, utilisateurs et contributeurs avaient fait confiance à ces projets sous MPL. La communauté a réagi avec OpenTofu, un fork sous MPL désormais chaperonné par la Linux Foundation. HashiCorp a largement gaspillé sa réputation de pionnier open source.

Le virage brutal de Redis. En mars 2024, Redis Ltd. a modifié du jour au lendemain la licence de sa base de données éponyme, passant de BSD 3-Clause à un dispositif double RSALv2 / SSPL. Aucune des deux ne constitue plus de l’open source au sens de l’OSI. Les principaux fournisseurs de cloud — AWS, Google, Oracle, Snap — ont réagi en quelques jours avec Valkey, un fork sous BSD 3-Clause désormais hébergé par la Linux Foundation. En quelques semaines, Redis a perdu une part notable de son marché entreprise.

Le passage assumé de MinIO à l’AGPL. Contrairement à HashiCorp et Redis, MinIO, le stockage d’objets compatible S3, a choisi en 2021 une voie restée dans l’open source. L’entreprise est passée du permissif Apache 2.0 à l’AGPL v3 — une véritable licence reconnue par l’OSI. Objectif : empêcher les fournisseurs de cloud d’offrir MinIO comme service géré sans divulguer leurs modifications. L’AGPL s’active précisément là où le copyleft classique est impuissant : lors de l’usage en réseau. Quiconque exploite MinIO comme service et l’adapte doit publier ses modifications sous AGPL. La différence décisive avec BSL ou SSPL : MinIO est resté open source. Les contributeurs n’ont pas été exclus, les forks sont restés légitimes, la licence reste compatible avec le vaste écosystème GPL. Leçon : se protéger contre la cannibalisation commerciale n’exige pas de quitter l’open source — il suffit de choisir la bonne licence.

CentOS et les limites du licencié. L’histoire la plus célèbre se déroule en 2020/2023. Depuis 2004, CentOS était un reconstitution communautaire de Red Hat Enterprise Linux — RHEL sans marque, gratuit, compatible au niveau binaire. En 2014, Red Hat a intégré le projet, embauché les mainteneurs, rapatrié la maison. Tout semblait en bon ordre. Le tournant arriva en décembre 2020 : Red Hat annonça la fin de CentOS Linux 8 fin 2021 et le remplaça par CentOS Stream — un canal aval continu alimentant RHEL plutôt qu’une distribution stable en aval. Des milliers de déploiements en production bâtis sur CentOS comme substitut gratuit à RHEL durent migrer. La communauté répondit avec Rocky Linux (lancé par Gregory Kurtzer, l’un des fondateurs originels de CentOS) et AlmaLinux. En juin 2023, nouveau coup : le code source de RHEL cessa d’être publié sous forme de tarballs librement téléchargeables, et ne fut plus accessible qu’aux clients via le portail Red Hat Customer Portal. La GPL ne fut pas violée — le code resta ouvert pour les ayants droit. Mais la faille permettant les distributions clones était fermée. Leçon : une licence correcte à elle seule ne protège pas contre les revirements stratégiques. Construire sur un projet impose de lire, au-delà de la licence, la gouvernance, le financement et les intérêts du gardien.

Cannibalisation sous couvert de protection

Ces épisodes ne sont pas isolés. Ils s’inscrivent dans une tendance qui prend de l’ampleur depuis 2018 : MongoDB (SSPL, octobre 2018), Elastic (Elasticsearch et Kibana d’Apache 2.0 vers SSPL, janvier 2021), Sentry, Cockroach Labs, Confluent — la liste pourrait continuer. Le motif commun : des projets construisent pendant des années une base de contributeurs et une marque sous une licence permissive ou à copyleft faible. Dès qu’un grand acteur du cloud domine le commerce plus lucratif des services gérés, le titulaire substitue à la licence un modèle qui protège précisément ce commerce.

Parfois c’est légitime. Les mainteneurs ont droit à une durabilité économique, et l’open source n’a jamais signifié exploitation gratuite. Mais la manière d’exécuter compte : accepter des contributions sous l’ancienne licence puis enfermer les mêmes contributeurs sous la nouvelle rompt un contrat social implicite. Le résultat n’est plus de l’open source — et l’écosystème apprend que de tels projets peuvent devenir à tout moment des facteurs de risque.

Pour les acheteurs, cela signifie : la stabilité de licence est devenue un critère de sélection, pas un détail.

Ce que cela signifie pour libcom.de

Depuis un quart de siècle, moi — Jochen Demmer, libcom.de — je travaille avec des produits open source. J’ai commencé en 2001, lorsque Linux s’imposait comme système d’exploitation serveur. Aujourd’hui, il fait tourner des infrastructures bancaires mondiales, des réseaux télécoms, l’informatique hospitalière et des installations industrielles.

De cette expérience viennent des jugements qu’aucun livre blanc n’enseigne : quelles licences tiennent dans des environnements régulés, où le copyleft mord réellement, quand l’AGPL signale un avertissement plutôt qu’une recommandation, comment repérer précocement les risques de renversement de licence en lisant gouvernance, financement et structure des contributeurs — pas seulement le README. Que vous ayez besoin d’une stratégie de conformité, d’un audit de pile, de formulation d’appel d’offres ou d’accompagnement de planification de migration, ce sont des tâches où la maîtrise des licences fait la différence entre une planification pluriannuelle sereine et une renégociation surprise.

Et je ne vois plus d’avenir viable aux licences purement propriétaires dans la vaste infrastructure informatique. Les raisons sont empiriques : les systèmes d’exploitation, bases de données, serveurs web, runtimes de conteneurs, orchestrateurs, systèmes de construction et compilateurs de langages les plus importants sont open source. Même les plus grands vendeurs propriétaires construisent désormais sur de l’open source — les racines Darwin d’Apple, le noyau Linux d’Android, la base de Visual Studio Code chez Microsoft. Qui croit encore en 2026 que le code fermé serait le chemin le plus sûr néglige que sa chaîne d’approvisionnement soi-disant sûre se compose déjà de logiciel libre. Les licences propriétaires peuvent persister dans des spécialisations étroites. À grande échelle, elles ne sont plus contemporaines.

L’open source est le nouveau standard de fait. Non par idéologie. Par performance, transparence, auditabilité et pérennité.

Si vous vous demandez si vos piles informatiques sont solides sur le terrain des licences, si une dépendance particulière pose un risque, ou à quoi pourrait ressembler une stratégie de conformité pour votre environnement : écrivez à contact@libcom.de. Nous faisons un inventaire honnête. Sans pression commerciale. Avec le regard sur ce qui dure à long terme.

Le logiciel libre n’est pas la solution à tous les problèmes. Mais c’est la seule catégorie de solutions dont les règles restent consultables — même dans vingt ans.

Avertissement : Cet article propose une orientation générale et ne remplace pas un conseil juridique. Les questions de licence peuvent dépendre des cas particuliers ; toute indication est fournie sans garantie.