SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Famille 1 · ~15 min de lecture

Les bascules de licence

Cas qui démontrent que la licence libre d'un projet open source est révocable lorsque le projet dépend d'un sponsor unique.

Thèses illustrées 05 · 11 · 12

Un projet open source dont les contributions, les artefacts ou la roadmap dépendent d’un sponsor unique est un projet dont la licence des versions futures est révocable. Cette précision juridique compte : lorsqu’un éditeur change la licence d’un projet, les versions déjà publiées sous une licence libre restent librement utilisables pour toujours — personne ne peut révoquer rétroactivement la GPL ou la BSD sur du code déjà distribué. Ce qui change, c’est la licence appliquée aux versions futures. Mais cette distinction technique ne console pas pratiquement : un utilisateur figé sur une version libre obsolète perd progressivement les correctifs de sécurité, les nouvelles fonctionnalités, et les patchs de compatibilité. La liberté juridique sur le code passé devient inutile si l’on doit utiliser le code présent.

Les cas qui suivent documentent des bascules de licence opérées par des entreprises ayant accumulé une position dominante sur leur projet open source, puis ayant retiré la liberté qu’elles avaient initialement consentie pour les versions futures. Chaque cas suit un schéma similaire : une licence libre permissive utilisée pour la croissance, suivie d’un changement vers une licence restrictive lorsque le projet devient assez critique pour que la migration coûte cher aux utilisateurs.

Hashicorp — La bascule d’une stack DevOps complète#

Date du fait : 10 août 2023 (annonce de la bascule) Statut : confirmé, deux forks actifs maintenus (OpenTofu, OpenBao) Thèses du manifeste illustrées : 5, 11, 12

Le fait#

Le 10 août 2023, Hashicorp annonce le passage de l’ensemble de son portefeuille produits d’une licence libre MPL 2.0 (Mozilla Public License) vers une Business Source License (BSL) v1.1. Cette licence interdit l’usage commercial concurrent : un acteur tiers ne peut plus proposer ces produits en tant que service managé sans accord avec Hashicorp.

Sont concernés simultanément :

  • Terraform — infrastructure-as-code, le produit le plus médiatisé
  • Vault — gestion de secrets (clés API, certificats, mots de passe), considéré comme le standard de fait dans son segment et souvent décrit comme « impossible à remplacer » à court terme dans les SI matures
  • Consul — service mesh et service discovery, brique centrale de nombreuses architectures microservices
  • Nomad — orchestrateur de conteneurs et de workloads, alternative à Kubernetes pour de nombreuses organisations
  • Packer — création d’images de machines virtuelles, pivot des chaînes de CI/CD d’infrastructure
  • Boundary — accès distant sécurisé aux infrastructures
  • Waypoint — déploiement applicatif

Il ne s’agit donc pas d’un changement isolé sur un seul outil, mais de la bascule simultanée de toute une stack DevOps que de nombreuses organisations européennes — banques, opérateurs télécoms, administrations, industriels — avaient adoptée comme ossature même de leur infrastructure cloud.

La justification publique de Hashicorp : protéger son modèle économique face à des fournisseurs cloud (notamment AWS) qui monétisaient ces outils sans contribuer à leur développement. Mais la décision affecte tout l’écosystème : intégrateurs, fournisseurs européens, communautés, qui se retrouvent juridiquement contraints dans leurs usages.

La réaction est immédiate, mais inégale selon les produits. En septembre 2023, un consortium d’acteurs — dont Gruntwork, Spacelift, Env0, Scalr, Harness, Digger — annonce le fork OpenTF (renommé OpenTofu après acceptation par la Linux Foundation), qui sort en version stable en janvier 2024 sous licence MPL 2.0 préservée. En avril 2024, la Linux Foundation accueille également OpenBao, fork de Vault, sous le même modèle. Pour les autres produits — Consul, Nomad, Packer, Boundary, Waypoint — aucun fork crédible n’a émergé à ce jour.

En avril 2024, Hashicorp est rachetée par IBM pour 6,4 milliards de dollars.

Ce qu’il démontre#

Le cas Hashicorp est le plus pédagogique de cette famille pour illustrer la thèse 5 (« projet libre révocable »), à plusieurs titres :

  1. La licence libre n’est pas un état permanent pour les versions futures. Toutes les versions des produits Hashicorp publiées avant le 10 août 2023 restent sous MPL 2.0 et le seront toujours — c’est un fait juridique acquis. Mais à partir de cette date, toutes les nouvelles versions sortent sous BSL. Un utilisateur qui veut rester strictement open source doit donc se figer sur des versions vieillissantes, ou migrer vers les forks lorsqu’ils existent.

  2. La profondeur de la dépendance multiplie le coût de la sortie. Une organisation qui n’utilise « que » Terraform peut migrer vers OpenTofu avec un effort raisonnable. Mais une organisation qui a construit son architecture autour de Vault + Consul + Terraform + Packer simultanément se retrouve face à un coût de migration multiplié par le nombre de produits, sans qu’aucun fork unifié n’existe pour l’ensemble de la stack. Plus une organisation a adopté la stack complète d’un éditeur, plus la bascule est coûteuse à contourner.

  3. Le statut « must have » est un facteur de capture. Lorsqu’un produit devient un standard de fait dans son segment, il sort du registre de l’outil pour entrer dans celui de l’infrastructure. Les organisations ne le « choisissent » plus vraiment ; elles l’adoptent parce que tout l’écosystème (formations, certifications, prestataires, intégrations) tourne autour. Ce verrouillage par standardisation est précisément le mécanisme décrit dans la thèse 12 du manifeste.

  4. L’asymétrie du sauvetage révèle la dépendance. Que ce soit AWS, Google ou des consortiums dominés par des acteurs américains qui financent les forks de licence, l’Europe reste structurellement absente de ces opérations de sauvetage. Les bascules se règlent entre acteurs américains, sans participation européenne significative — y compris pour des outils massivement déployés en Europe.

  5. Le rachat ultérieur d’Hashicorp par IBM confirme que la bascule de licence n’était pas une politique stable mais une étape dans une stratégie commerciale plus large. Pour les utilisateurs européens, cela signifie que la roadmap de leurs briques d’infrastructure dépend désormais des arbitrages d’IBM, indépendamment de leurs propres priorités.

Sources#

Redis — Deux bascules en six ans#

Date des faits : août 2018 (Redis Modules → Commons Clause), mars 2024 (Redis Core → SSPL/RSAL) Statut : confirmé, fork Valkey actif Thèses du manifeste illustrées : 5, 11

Le fait#

Redis est l’une des bases de données en mémoire les plus utilisées au monde, longtemps publiée sous licence BSD. Son histoire de bascules s’étale sur plusieurs années :

  • Août 2018 : Redis Labs (renommée Redis Inc. par la suite) ajoute la Commons Clause à plusieurs modules Redis (RedisGraph, RedisJSON, RediSearch, RedisML, RedisBloom). Cette clause restreint l’usage commercial. L’événement provoque un débat important dans la communauté open source.
  • Mars 2024 : Redis Inc. annonce que Redis Core lui-même bascule de la licence BSD vers un dual-licensing SSPL (Server Side Public License) et RSAL (Redis Source Available License). Les deux licences interdisent l’usage commercial concurrent en tant que service managé.

La réaction est immédiate. La Linux Foundation annonce le 1er avril 2024 le fork Valkey, soutenu par AWS, Google Cloud, Oracle, Ericsson et Snap. Valkey conserve la licence BSD originelle. Selon une enquête réalisée la même année, 83 % des grands utilisateurs Redis avaient soit déjà migré vers Valkey, soit étaient en train de le tester.

En mai 2025, Redis Inc. fait machine arrière : Redis 8 est publié sous AGPLv3 (en parallèle des licences SSPL et RSALv2), une licence cette fois reconnue par l’OSI comme open source. Le retour de Salvatore Sanfilippo, créateur historique de Redis, comme developer evangelist en novembre 2024 a précédé ce changement. La trajectoire est désormais identique à celle d’Elasticsearch : bascule restrictive (mars 2024) → fork crédible (Valkey, avril 2024) → érosion de la position commerciale → retour partiel à l’open source (mai 2025).

Ce qu’il démontre#

Le cas Redis est instructif à triple titre. D’abord, parce qu’il montre que les bascules de licence ne sont pas des événements isolés mais des trajectoires : une entreprise commence par restreindre les modules périphériques (2018), teste la réaction de la communauté, puis passe au cœur du produit (2024). Ensuite, parce que la réponse — le fork Valkey — est portée principalement par AWS et Google, c’est-à-dire les acteurs mêmes que Redis Inc. accusait de monétiser son travail sans contribuer. La défense du libre se fait donc à coup de plusieurs millions de dollars d’engagement de la part de fournisseurs cloud américains, pas par une mobilisation européenne ou citoyenne. Enfin, parce que le retour de Redis à l’AGPLv3 en mai 2025 confirme que l’existence d’un fork crédible discipline les éditeurs : sans Valkey, il est probable que Redis Inc. ne serait jamais revenu à une licence open source.

Sources#

Elasticsearch — La bascule SSPL et la naissance d’OpenSearch#

Date du fait : 14 janvier 2021 Statut : confirmé, fork OpenSearch actif Thèses du manifeste illustrées : 5, 11

Le fait#

Le 14 janvier 2021, Elastic NV (entreprise néerlandaise cotée à la NYSE) annonce le passage d’Elasticsearch et de Kibana d’une licence libre Apache 2.0 vers un dual-licensing SSPL et Elastic License. Comme dans le cas Redis, ces licences interdisent l’usage commercial concurrent en tant que service managé. La justification publique d’Elastic : empêcher AWS de monétiser Elasticsearch via son service Amazon Elasticsearch Service sans contribuer à son développement.

AWS répond rapidement. En avril 2021, Amazon annonce le fork OpenSearch sous licence Apache 2.0 préservée. OpenSearch est aujourd’hui un projet sous gouvernance de la Fondation Linux (depuis septembre 2024), avec des dizaines de mainteneurs salariés AWS et un écosystème de contributeurs établi.

Trois ans plus tard, en août 2024, Elastic fait machine arrière : Elasticsearch et Kibana retrouvent une licence open source (AGPL v3) en parallèle de leurs licences propriétaires. La concurrence d’OpenSearch avait visiblement érodé la position d’Elastic plus vite qu’il ne l’avait anticipé.

Ce qu’il démontre#

Le cas Elasticsearch est intéressant par sa double trajectoire : la bascule de 2021, puis le retour partiel de 2024. Il montre que :

  1. La bascule de licence peut être contre-productive même pour son auteur. Elastic a perdu plus de parts de marché qu’il n’en a gagné en monopolisant le service managé.
  2. L’existence d’un fork crédible discipline les éditeurs. Sans OpenSearch, Elastic n’aurait probablement jamais reverti.
  3. La domiciliation européenne d’Elastic n’a rien changé. Bien que basée aux Pays-Bas, Elastic NV est cotée à la NYSE et opère selon la logique commerciale américaine. Cela illustre que la « domiciliation européenne » d’une entreprise n’est pas une garantie de comportement souverain.

Sources#

MongoDB — Le précédent fondateur de la SSPL#

Date du fait : 16 octobre 2018 Statut : confirmé, sans fork dominant Thèses du manifeste illustrées : 5, 11

Le fait#

Le 16 octobre 2018, MongoDB Inc. annonce le passage de sa base de données MongoDB d’une licence libre AGPL v3 vers la Server Side Public License (SSPL) — licence qu’elle a elle-même créée pour l’occasion. La SSPL interdit l’exploitation commerciale concurrente en tant que service managé : tout fournisseur tiers qui propose MongoDB en SaaS doit publier sous SSPL l’ensemble de son code de service, ce qui est commercialement impossible pour la plupart des opérateurs.

La SSPL n’a pas été reconnue comme open source par l’Open Source Initiative, qui maintient la définition de référence du logiciel libre. MongoDB retire de lui-même sa demande d’approbation en mars 2019 plutôt que d’attendre un rejet formel. La Free Software Foundation considère également la SSPL comme non libre. Ces qualifications sont des positions d’organisations de référence, pas des qualifications juridiques officielles — en droit strict, la SSPL est une licence qui distribue du code source avec des conditions de copyleft élargies. Néanmoins, MongoDB continue à se présenter comme « source available » et la SSPL devient le modèle copié par Redis, Elastic et d’autres dans les années qui suivent.

Contrairement aux cas Redis et Elasticsearch, aucun fork dominant n’a émergé pour MongoDB. AWS a lancé son propre service compatible MongoDB API (Amazon DocumentDB), mais sans véritable fork du code MongoDB lui-même.

Ce qu’il démontre#

Le cas MongoDB est le précédent fondateur de toutes les bascules ultérieures. Il a montré qu’une entreprise pouvait :

  1. Inventer sa propre licence restrictive présentée comme « open source-like ».
  2. Tenir face à la critique de l’OSI et de la FSF sans subir de désaffection majeure de ses utilisateurs.
  3. Préserver sa position dominante sans qu’un fork crédible n’émerge, parce que la complexité du projet et l’absence d’acteur ayant à la fois les moyens et la motivation rend le fork irréalisable.

Ce dernier point est le plus inquiétant pour la souveraineté européenne. Forker un projet aussi complexe que MongoDB exige une masse salariale, une expertise et une distribution mondiale dont aucun acteur européen ne dispose. La bascule MongoDB est donc, à ce jour, irréversible — et cette irréversibilité est exactement ce que craint la thèse 5.

Sources#

RHEL / CentOS Stream — La bascule de la redistribution des sources#

Date du fait : 21 juin 2023 Statut : confirmé, Rocky Linux et AlmaLinux réorganisés en mode dégradé Thèses du manifeste illustrées : 5, 7, 11, 12

Le fait#

Le 21 juin 2023, Red Hat annonce que CentOS Stream deviendra le seul dépôt public de code source lié à Red Hat Enterprise Linux (RHEL). Avant cette date, les sources de chaque release de RHEL étaient publiées sur git.centos.org, librement accessibles à toute personne ou entreprise. Après cette date, l’accès aux sources complètes de RHEL est restreint aux clients et partenaires sous contrat, via le Red Hat Customer Portal.

La formulation officielle, en anglais : « CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal. » Le motif invoqué a été l’efficacité éditoriale (éviter la maintenance de dépôts redondants), mais l’effet pratique a été immédiat sur l’écosystème des distributions communautaires dérivées de RHEL : Rocky Linux, AlmaLinux et Oracle Linux se sont retrouvées privées de leur source canonique de reconstruction binaire 1:1 contre RHEL.

Cette décision s’inscrit dans une trajectoire commencée fin 2020, quand Red Hat avait annoncé que CentOS Linux 8, jusque-là un downstream fidèle de RHEL, deviendrait CentOS Stream, un upstream de RHEL. Les utilisateurs qui voulaient une compatibilité 1:1 avec RHEL devaient migrer vers d’autres distributions. Rocky Linux (porté par Greg Kurtzer, l’un des fondateurs historiques de CentOS) et AlmaLinux (porté par CloudLinux) avaient été créés en 2021 précisément pour répondre à ce besoin. La décision de juin 2023 a frappé ces deux projets de plein fouet : ils avaient construit leur modèle technique sur l’accès libre aux sources RHEL, modèle qui disparaissait sans préavis.

Rocky Enterprise Software Foundation et AlmaLinux OS Foundation ont mis plusieurs mois à se réorganiser. AlmaLinux a publiquement choisi d’abandonner la compatibilité binaire 1:1 stricte pour adopter une compatibilité ABI (Application Binary Interface), qui couvre l’essentiel des cas d’usage entreprise sans exiger l’accès aux sources exactes de RHEL. Rocky Linux a opté pour des stratégies d’accès indirect aux sources via les UBI (Universal Base Images) de Red Hat et les abonnements gratuits developer. Les deux projets continuent d’exister en 2026, mais dans un mode dégradé par rapport à ce qu’ils auraient été avec un accès libre aux sources RHEL.

Ce qu’il démontre#

Cet épisode illustre, avec une précision qu’aucun raisonnement abstrait ne pourrait égaler, la mécanique qu’opérationnalise la nouvelle section « Le syndrome du distributeur » de l’inventaire des lacunes. Le 20 juin 2023 au soir, des centaines de fournisseurs européens — hébergeurs, intégrateurs, éditeurs métier — avaient construit leur infrastructure sur la chaîne CentOS Stream → RHEL ou sur ses dérivés. Le 21 juin 2023 au matin, ces fournisseurs ont appris par un communiqué public que cette chaîne venait de changer de règles. Aucun d’entre eux n’avait été consulté. Aucun d’entre eux n’avait été averti à l’avance. Aucun d’entre eux n’avait de recours.

La décision elle-même n’était ni illégitime ni illégale : Red Hat est dans son droit de définir comment ses produits sont distribués. Mais elle illustre que le statut juridique « open source » d’une brique ne protège pas contre la modification unilatérale des conditions de redistribution par son producteur. Quand le producteur de la brique est étranger, quand les fournisseurs européens qui le redistribuent ne participent pas à la gouvernance de cette brique, et quand les acheteurs publics qui valorisent la souveraineté n’ont pas exigé de plan de continuité technologique en cas de bascule unilatérale, l’écosystème entier devient vulnérable à des décisions prises hors de son contrôle.

L’écho avec OpenShift est direct : OpenShift est la propriété de Red Hat ; rien ne protège, dans la structure actuelle, contre une décision Red Hat-IBM analogue à celle de juin 2023, qui modifierait demain les conditions d’accès, de redistribution, de pricing ou de support d’OpenShift — produit redistribué dans plusieurs offres SecNumCloud françaises (voir famille 3).

Sources#

Synthèse de la famille#

Les cinq cas documentés (Hashicorp, Redis, Elasticsearch, MongoDB, RHEL/CentOS Stream) suivent un schéma reconnaissable :

  1. Phase de croissance : licence libre permissive (Apache 2.0, BSD, MPL, AGPL) ou redistribution publique des sources, qui maximise l’adoption.
  2. Phase de domination : le projet ou la distribution devient critique pour ses utilisateurs et accumule une base d’utilisateurs payants ou de redistributeurs.
  3. Phase de bascule : l’éditeur change la licence (Hashicorp, Redis, Elasticsearch, MongoDB) ou les conditions de redistribution des artefacts (RHEL/CentOS) pour interdire la concurrence sur le service managé ou sur la reconstruction binaire 1:1.
  4. Phase de réaction : selon les cas, fork (Terraform → OpenTofu, Vault → OpenBao, Redis → Valkey, Elasticsearch → OpenSearch) ou pas de fork (MongoDB ; Consul, Nomad, Packer, Boundary, Waypoint), ou réorganisation dégradée (Rocky Linux, AlmaLinux).

Le cas RHEL/CentOS élargit le périmètre du schéma : il ne s’agit pas d’une bascule de licence stricto sensu (les versions de RHEL sous GPL restent sous GPL pour qui les obtient), mais d’une restriction d’accès aux artefacts qui produit le même effet pratique sur l’écosystème de redistribution. Le mécanisme commun — décision unilatérale d’un sponsor unique modifiant la redistribution — se généralise à toutes les briques où une entité commerciale concentre la production.

Ce schéma est désormais documenté, prévisible, et reproductible. Tout projet open source à fort succès porté par une entreprise unique, et toute distribution propriétaire dont l’écosystème dépend de la publication de sources, sont candidats à cette trajectoire. Les organisations européennes qui adoptent ces projets aujourd’hui doivent intégrer la possibilité de cette bascule dans leur évaluation de souveraineté — et privilégier, à équivalence fonctionnelle, des projets à gouvernance distribuée (voir famille 5).

→ Engagements opérationnels associés#

Le dispositif documente plusieurs engagements concrets que peuvent prendre les acteurs de la chaîne pour anticiper, contourner ou sortir des schémas de bascule de licence illustrés ci-dessus.

Catalogue complet des engagements →

Lire le manifeste →