GPL, MIT ou Apache : que vous impose chaque licence ?

GPL contre MIT contre Apache : ce que chaque licence vous demande

Les licences GPL, MIT et Apache 2.0 répondent à la même question de manière différente : que devez-vous aux autres lorsque vous redistribuez le logiciel ? La licence MIT exige un avis de copyright, et rien de plus. La licence Apache 2.0 exige cet avis, ainsi qu’un accord relatif aux brevets entre toutes les personnes qui modifient le code. La GPL vous demande de publier le code source de ce que vous avez construit par-dessus, sous la même licence que celle que vous avez reçue.

Cela ressemble à une question pour les juristes jusqu’au jour où un projet que vous exploitez change de licence et se scinde en deux. Cela devient alors une question d’exploitation. Vous devez choisir entre deux dépôts de paquets, et certaines bibliothèques clientes cessent de communiquer entre elles. Ce guide porte sur les licences et leurs mécanismes, pas sur le mouvement qui les a produites. Chaque section s’arrête donc lorsqu’elle vous concerne directement : vous devez effectuer la mise à niveau.

Pourquoi la GPL existe : une imprimante que personne n’avait le droit de réparer

Vers 1980, le laboratoire d’intelligence artificielle du MIT a reçu une imprimante laser Xerox 9700. Le laboratoire avait corrigé le logiciel d’une imprimante précédente pour qu’elle indique lorsqu’un travail était bloqué. Pour la nouvelle imprimante, le code source n’était pas disponible. La demande d’accès a été refusée en raison d’un accord de confidentialité. Richard Stallman, alors programmeur au laboratoire, a considéré ce refus comme un problème structurel et non comme un simple incident. Il a annoncé le projet GNU le 27 septembre 1983.

Le copyleft repose sur le droit d’auteur, il ne s’y oppose pas. Par défaut, vous n’avez aucun droit de copier le code d’une autre personne. La GPL vous accorde ce droit à une condition : si vous transmettez le programme à quelqu’un, vous devez lui fournir le code source, selon les mêmes conditions, afin qu’il puisse faire ce que le laboratoire ne pouvait pas faire. Cette condition est opposable, car sans la licence, vous n’aviez aucune autorisation au départ.

Stallman a d’abord écrit une licence pour GNU Emacs, puis l’a généralisée sous la forme de la GPL version 1 le 25 février 1989. La GPL version 2 a suivi en juin 1991. Elle reste la licence de la plupart des logiciels système que vous utilisez. La Lesser GPL a été créée pour les bibliothèques. Une bibliothèque sous copyleft pouvait ainsi être liée par un programme distribué sous n’importe quelle licence, sans soumettre ce programme à la GPL.

Un point détermine la manière dont la GPL s’applique à l’auto-hébergement. L’obligation s’applique lors de la distribution, pas lors de l’utilisation. Vous pouvez modifier un programme sous GPL, l’exécuter sur votre propre serveur et fournir un service au public sans rien devoir à personne, car vous n’avez jamais distribué de copie. C’est cette différence qui explique l’existence de l’AGPL.

La tradition permissive : BSD, puis MIT

Berkeley a suivi une autre voie. Le Computer Systems Research Group publiait son code Unix sous une licence qui imposait de conserver la mention de copyright et excluait toute garantie. La version originale comportait quatre clauses. La quatrième, appelée clause publicitaire, imposait de mentionner l’Université dans tout support publicitaire faisant référence à des fonctionnalités du logiciel. Cette exigence n’est pas viable à grande échelle. Stallman a dénombré 75 mentions distinctes dans une version de NetBSD datant de 1997. L’UC Berkeley a supprimé cette clause le 22 juillet 1999, dans une lettre de William Hoskins, de son Office of Technology Licensing.

Il reste la licence BSD à 3 clauses, qui interdit en plus d’utiliser le nom des contributeurs pour cautionner votre produit, et la version à 2 clauses, qui supprime même cette interdiction. Le texte de la licence MIT est issu du MIT dans les années 1980, où il couvrait le X Window System. En pratique, il remplit le même rôle que la licence BSD à 2 clauses.

Les motivations étaient différentes. Une université financée par des fonds publics voulait que ses travaux soient utilisés partout, y compris par des entreprises. Le projet GNU voulait préserver un bien commun qui ne puisse pas être fermé. Ces deux positions sont légitimes, et chacune comporte un risque d’échec. Du code permissif peut être approprié par une entreprise, sans aucun retour pour la communauté. Du code copyleft est refusé par les entreprises dont les juristes n’acceptent pas cette condition.

Berkeley offre une deuxième leçon, à laquelle cet article revient régulièrement. AT&T's Unix System Laboratories a poursuivi Berkeley Software Design en 1992 au sujet du code BSD, et l’affaire s’est réglée au début de 1994. Pendant deux ans, personne ne pouvait être certain de pouvoir s’appuyer légalement sur BSD, et son adoption a stagné tandis que Linux progressait. L’incertitude juridique bloque l’adoption plus rapidement qu’une fonctionnalité manquante.

Pourquoi Apache 2.0 a ajouté une concession de licence de brevets

La première licence de l’Apache Group était un dérivé de la licence BSD à 4 clauses, avec le même problème lié à la publicité. La version 1.1, publiée en 2000, a supprimé cette clause. La version 2.0, publiée en janvier 2004, était une réécriture plutôt qu’une simple correction.

L’ajout important concerne les brevets. Les licences MIT et BSD ne disent absolument rien à leur sujet. Un contributeur peut vous accorder une autorisation claire au titre du copyright pour son code tout en détenant un brevet qui couvre ce que fait le code, puis poursuivre en justice les personnes qui l’utilisent. Apache 2.0 comble cette lacune : chaque contributeur accorde une licence de brevets couvrant sa contribution, et toute personne qui poursuit en justice en affirmant que l’œuvre porte atteinte à ses brevets perd sa propre licence de brevets sur cette œuvre. La menace est réciproque ; en pratique, personne ne lance donc de poursuites.

Le reste de la version 2.0 relève de l’administration, ce qui explique pourquoi les entreprises l’apprécient. Le fichier NOTICE est défini, de sorte que les mentions d’attribution sont regroupées au même endroit au lieu d’être dispersées dans l’arborescence. La licence peut être appliquée par référence au lieu d’être copiée dans chaque fichier source. Les contributions sont couvertes par des conditions explicites. Les marques commerciales sont exclues. Lorsqu’un service juridique examine une dépendance sous Apache 2.0, il trouve déjà dans le texte la réponse à chacune des questions qu’il voulait poser. L’approbation devient donc une procédure courante, ce qui constitue l’essentiel de ce que signifie « valeur par défaut en entreprise ».

Ce que la GPLv3 a changé, et pourquoi Linux est resté sous GPLv2

TiVo a commercialisé un enregistreur vidéo fonctionnant sous Linux et a publié le code source du noyau, exactement comme l’exige la GPLv2. Le matériel vérifiait ensuite une signature cryptographique au démarrage et refusait d’exécuter un noyau qu’il ne reconnaissait pas. Vous pouviez lire le code source, le modifier et le compiler. Vous ne pouviez pas l’exécuter sur l’appareil dont il provenait. La lettre de la licence était respectée, mais son objectif était contourné. Cette pratique a pris le nom de tivoïsation.

La version 3 de la GPL, publiée le 29 June 2007, répond directement à ce problème. Lorsque vous distribuez le binaire dans un appareil grand public, vous devez également fournir les « Informations d’installation » : les clés ou les instructions nécessaires pour installer une version modifiée et la faire fonctionner. La version 3 a également ajouté une licence explicite relative aux brevets, des clauses rédigées en réaction à l’accord de brevets conclu entre Microsoft et Novell en November 2006, ainsi qu’une compatibilité à sens unique avec Apache 2.0.

Linux n’a pas suivi cette évolution. Le noyau est uniquement sous GPL version 2, sans clause de sortie « ou toute version ultérieure », et son fichier COPYING le précise. Linus Torvalds s’est publiquement opposé aux clauses anti-tivoïsation concernant le matériel signé. L’obstacle pratique est plus important que ce désaccord : le noyau compte des milliers de titulaires de droits d’auteur. Il serait donc impossible de réunir les autorisations nécessaires à une relicence, même si tout le monde le souhaitait. Ce simple fait constitue la meilleure protection possible pour un projet. Il faut s’en souvenir lorsque le projet appartient à une seule entreprise.

L’autre licence publiée en 2007 vous concerne davantage. La GNU Affero GPL version 3, publiée en November de la même année, étend l’obligation de fournir le code source aux personnes qui interagissent avec le programme sur un réseau. Si vous exploitez un service AGPL modifié pour le public, vous devez fournir le code source à ces utilisateurs. C’est pourquoi tant de logiciels web auto-hébergés sont sous AGPL. Nextcloud en est un exemple. Si vous comparez les alternatives auto-hébergées à Nextcloud, la licence indiquée dans le dépôt de chaque candidat vous en apprendra davantage sur ses cinq prochaines années que sa liste de fonctionnalités.

Quelles licences pouvez-vous réellement combiner ?

La compatibilité fonctionne dans un seul sens, des licences permissives vers les licences copyleft.

• Du code sous MIT ou BSD peut être intégré à n’importe quel projet, y compris à un produit propriétaire.
• Du code sous Apache 2.0 peut être inclus dans un projet sous GPLv3. L’œuvre combinée est alors distribuée sous GPLv3.
• Du code sous Apache 2.0 ne peut pas être inclus dans un projet exclusivement sous GPLv2. Les clauses de résiliation des droits de brevet et d’indemnisation constituent des conditions supplémentaires que la GPLv2 ne vous autorise pas à ajouter. La FSF et l’ASF publient toutes deux cette conclusion.
• Vous ne pouvez pas convertir vous-même du code sous GPL en code sous licence permissive. Seuls les titulaires des droits d’auteur peuvent le faire. Il faut donc déterminer qui ils sont.

L’ère des changements de licence : SSPL, BUSL et ce qu’elles ne sont pas

Le déclencheur était commercial. Une entreprise détient les droits d’auteur d’un produit, un fournisseur cloud le vend comme service managé à grande échelle et apporte peu en retour, puis l’entreprise modifie la licence pour y mettre fin. Redis Labs a fait le premier mouvement visible en août 2018 en ajoutant la Commons Clause à Apache 2.0 pour plusieurs de ses modules. MongoDB a suivi le 16 octobre 2018 en passant d’AGPLv3 à la Server Side Public License.

La SSPL est l’AGPL avec une section réécrite. Si vous proposez le programme à des tiers sous forme de service, vous devez publier le code source de tout ce que vous utilisez pour le proposer, y compris les logiciels de gestion et d’orchestration qui l’entourent. La portée de cette obligation n’est pas clairement délimitée et aucun tribunal ne l’a encore examinée. L’OSI n’a jamais approuvé cette licence, et MongoDB a retiré sa demande en mars 2019. Debian avait déjà indiqué en décembre 2018 que les logiciels sous SSPL n’avaient pas leur place dans son archive. Fedora a ensuite conclu en janvier 2019 que cette licence n’était pas libre. Red Hat a alors retiré MongoDB de Fedora et de Red Hat Enterprise Linux. C’est la conséquence mécanique d’un changement de licence : la distribution cesse de fournir le logiciel sous forme de package, et vos mises à niveau proviennent désormais d’un dépôt du fournisseur, selon son propre calendrier.

La Business Source License est un mécanisme différent. Elle vient des fondateurs de MariaDB, et la version 1.1 date de 2017. Ce n’est pas une licence copyleft et ce n’est pas une licence open source. Le code source est public et l’utilisation est libre, sauf pour l’usage que le fournisseur exclut explicitement. Il s’agit normalement de l’exploitation d’un service hébergé concurrent. Chaque release est automatiquement convertie vers une véritable licence open source à une date de changement située au plus tard quatre ans après cette release. La licence de conversion doit être compatible avec GPLv2. HashiCorp a placé Terraform et ses autres produits sous BUSL 1.1 le 10 août 2023. Outline l’utilise également. C’est utile à savoir si vous choisissez parmi les alternatives auto-hébergées à Notion : vous pouvez l’exécuter pour votre propre équipe, mais vous ne pouvez pas bâtir un service dessus.

Aucune de ces licences n’est malhonnête. Toutes deux indiquent clairement que le code source est disponible. Aucune n’est open source selon la définition de l’OSI. Cette différence vous concerne, plutôt que le fournisseur cloud visé par ces licences.

OpenSearch : le coût d’un fork de licence pour l’opérateur

Elastic a annoncé le 14 janvier 2021 qu’Elasticsearch et Kibana quitteraient Apache 2.0 au profit de la SSPL ou de l’Elastic License, à partir de la release 7.11. La version 7.10.2 était la dernière release sous Apache 2.0. Environ une semaine plus tard, AWS a annoncé la création et la maintenance d’un fork Apache 2.0 des deux projets. Le fork a été nommé OpenSearch le 12 avril 2021, et Kibana a été renommé OpenSearch Dashboards. OpenSearch 1.0 est devenu généralement disponible le 12 juillet 2021, à partir d’Elasticsearch 7.10.2 et de Kibana 7.10.2.

Examinez ce que cela a coûté aux personnes qui exploitaient les clusters. Les noms des packages et des repositories ont changé. Chaque référence à Kibana dans un runbook est devenue une référence à OpenSearch Dashboards. Les noms des plugins ont changé. Puis la séparation a atteint le code applicatif : à partir de la version 7.13 des bibliothèques clientes officielles d’Elastic, le client vérifie le service auquel il s’est connecté et refuse de continuer avec autre chose qu’Elasticsearch. Il signale alors que le serveur est un produit inconnu. Une décision de licence prise par une entreprise pour laquelle vous ne travaillez pas s’est transformée en appel en échec dans votre propre application.

L’histoire a ensuite connu deux nouveaux changements. Elastic a ajouté AGPLv3 comme troisième option de licence le 29 août 2024. Elasticsearch actuel est donc de nouveau un logiciel open source approuvé par l’OSI. Le 16 septembre 2024, AWS a transféré OpenSearch à l’OpenSearch Software Foundation, hébergée par la Linux Foundation. Le fork dispose ainsi d’une structure de gouvernance qui ne dépend pas d’une seule entreprise. Cinq ans après la séparation, les deux projets sont open source et tous deux sont maintenus. En août 2026, OpenSearch est dans sa série 3.x.

La conclusion est la suivante. La licence a changé de nouveau, mais le fork est resté. Lorsqu’un écosystème possède deux exemplaires de chaque élément, annuler les formalités ne suffit pas à les réunir.

Le nombre qui détermine l’impact d’un changement de licence est le délai entre l’annonce et un fork stable que vous pouvez réellement déployer.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Chaque délai est calculé entre l’annonce publique du fournisseur et la première release stable du fork, à partir des dates indiquées ci-dessous. OpenSearch 1.0 a nécessité 179 jours, car le fork devait être renommé et reconstruit sans fork antérieur dont il aurait pu reprendre le travail. OpenTofu a nécessité 153 jours. Valkey a nécessité 27 jours, car il a forké Redis 7.2.4 en conservant le protocole et le format sur disque à l’identique. C’est cette évolution qui est utile : un fork crédible apparaît désormais en quelques semaines, avec une fondation et des mainteneurs rémunérés dès le premier jour.

Valkey et OpenTofu : le même schéma, plus rapidement

Redis Ltd est passé de la licence BSD à 3 clauses à un choix entre RSALv2 et SSPLv1 le 20 March 2024. Huit jours plus tard, la Linux Foundation a annoncé Valkey, un fork de Redis 7.2.4 qui reste sous licence BSD à 3 clauses. Valkey 7.2.5 est sorti le 16 April 2024 avec le même protocole et les mêmes fichiers de données. Pour la plupart des opérateurs, la migration s’est donc limitée à changer le nom du paquet. Redis a ensuite ajouté AGPLv3 comme troisième option dans Redis 8 en May 2025. Redis est ainsi redevenu open source selon la définition de l’OSI, tandis que Valkey poursuit son développement avec sa propre gouvernance. Le schéma est très proche de celui d’Elasticsearch.

Terraform a suivi le même parcours, avec un chapitre supplémentaire. OpenTofu a forké la dernière version publiée sous Mozilla Public License 2.0, a rejoint la Linux Foundation en September 2023 et a publié la version 1.6.0 le 10 January 2024. Le 3 April 2024, les avocats de HashiCorp ont envoyé au projet une mise en demeure de cesser et de s’abstenir, en affirmant que du code provenant d’une version de Terraform sous licence BUSL avait été copié dans le fork. OpenTofu a publié une réponse détaillée le 11 April 2024 pour le nier. Le projet a attribué le code contesté à l’historique sous licence MPL partagé par les deux projets. Aucune autre suite n’a été rendue publique. Le risque réel à retenir est le suivant : une simple accusation peut bloquer l’adoption pendant un trimestre. C’est le même effet que le procès de Berkeley avait produit trente ans plus tôt.

Tous les forks ne commencent pas par une question de licence. Forgejo a forké Gitea en 2022 après que le développement de Gitea a été placé sous la responsabilité d’une entreprise. Il s’agissait d’un désaccord de gouvernance, et non d’un problème de licence. Forgejo est resté sous licence MIT pendant sa série de versions 8, puis est passé à la licence GPLv3 ou ultérieure à partir de la version 9.0 en 2024. Son code ne pouvait ainsi pas être réintégré dans un produit contrôlé commercialement. Si vous évaluez les options de serveurs Git auto-hébergés, ce duo est l’exemple concret le plus clair d’une même base de code et de deux philosophies.

Le test à effectuer avant d’adopter un projet

Quatre questions à poser avant la première installation, et non après.

1. Qui détient les droits d’auteur ? Une nouvelle licence nécessite l’autorisation de chaque détenteur des droits d’auteur. Un projet réunissant des centaines de contributeurs indépendants, sans cession de droits, ne peut donc pas raisonnablement changer de licence. En revanche, un projet dont une seule entreprise détient tous les droits peut changer de licence lors d’une réunion du conseil d’administration.
2. Existe-t-il une CLA et que permet-elle ? Un accord de licence de contribution qui autorise l’entreprise à changer la licence de votre contribution selon les conditions de son choix est le mécanisme exact à l’origine de chaque changement de licence mentionné ci-dessus. Un DCO (developer certificate of origin), c’est-à-dire la ligne de sign-off adoptée par le noyau Linux en 2004, ne transfère aucun droit. Une CLA détenue par une fondation est plus sûre qu’une CLA détenue par une entreprise, car une entreprise peut être vendue.
3. Qui détient la marque ? Elastic a conservé le nom Elasticsearch. Le fork a donc dû changer de nom, et tous les runbooks mentionnant Kibana ont dû être réécrits.
4. Quel serait le coût d’un changement de licence pour vous ? Prenez en compte le format des données, les bibliothèques clientes, la configuration à réécrire et l’existence éventuelle d’un fork compatible.

Deux commandes permettent de répondre à une partie de ces questions en quelques secondes.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Chaque paquet Debian et Ubuntu installe un fichier à l’emplacement /usr/share/doc/<package>/copyright. Ce fichier indique la licence de la version installée, et non celle utilisée actuellement par le projet. Pour bash sur Ubuntu 24.04, ce fichier indique la GNU General Public License version 3. Exécutez la deuxième commande dans un checkout du code source pour obtenir l’historique du fichier de licence lui-même. Un commit effectué au cours des deux dernières années mérite d’être examiné avant toute utilisation du projet. Si la commande n’affiche rien, le dépôt utilise un autre nom pour son fichier de licence. Listez alors le répertoire racine et recherchez ce fichier.

Aucune licence ne vous protège contre toutes les conséquences, et choisir selon une idéologie est le meilleur moyen d’être surpris. Privilégiez les projets dont les droits d’auteur sont répartis entre de nombreux détenteurs ou détenus par une fondation, et conservez vos données dans un format que vous pouvez exporter. Déterminez ensuite vers quel fork vous migreriez et notez son nom avant d’en avoir besoin. Effectuer ce contrôle pour chaque candidat prend moins d’une heure. C’est ce qui fait la différence entre une mise à niveau et une migration lorsque vous décidez quoi auto-héberger en 2026.

FAQ

La licence MIT est-elle identique à la licence BSD ?

En pratique, la licence MIT correspond à la licence BSD à 2 clauses : conserver la mention de copyright et l’exclusion de garantie, puis faire ce que vous voulez, notamment créer un produit propriétaire. La licence BSD à 3 clauses ajoute une restriction : vous ne pouvez pas utiliser le nom des contributeurs pour promouvoir votre produit sans autorisation. L’ancienne version à 4 clauses imposait également une mention dans les supports publicitaires. UC Berkeley a supprimé cette clause le 22 juillet 1999. Presque aucun projet actuel ne l’utilise encore.

Puis-je intégrer du code Apache 2.0 dans un projet GPLv2 ?

Non. Apache 2.0 ajoute des conditions que GPLv2 ne vous autorise pas à ajouter, principalement la clause de résiliation des droits liés aux brevets. Une œuvre combinée ne peut donc pas respecter les deux licences simultanément. La FSF et l’ASF publient toutes deux cette conclusion. L’autre sens fonctionne : du code Apache 2.0 peut être inclus dans un projet GPLv3, et le résultat est soumis à GPLv3. C’est également pourquoi le code Apache 2.0 ne peut pas être intégré au kernel Linux, qui est uniquement sous GPL version 2.

La SSPL est-elle une licence open source ?

Non, et cette réponse a des conséquences pratiques. L’OSI ne l’a jamais approuvée, et MongoDB a retiré sa demande en mars 2019. Debian a indiqué en décembre 2018 que les logiciels sous SSPL n’avaient pas leur place dans son archive. Fedora a conclu en janvier 2019 que cette licence n’était pas libre. Red Hat a ensuite retiré MongoDB de Fedora et de Red Hat Enterprise Linux. Pour vous, cela signifie qu’un package auparavant maintenu par votre distribution provient désormais d’un dépôt du fournisseur, selon le calendrier de support de ce dernier. La Business Source License rend également le code disponible plutôt qu’open source, même si chaque release est convertie en licence open source dans un délai de quatre ans.

Un changement de licence s’applique-t-il à la version que j’utilise déjà ?

Non. Une licence accordée avec une release ne peut pas être retirée des copies déjà publiées. C’est précisément ce qui permet de créer des forks. OpenSearch a été créé à partir d’Elasticsearch 7.10.2, la dernière release publiée par Elastic sous Apache 2.0. Ce que vous perdez, c’est l’avenir : le prochain correctif de sécurité sera fourni selon les nouvelles conditions. Épingler la dernière version sous licence permissive vous fait gagner quelques mois. Ce n’est pas une stratégie.