Pourquoi les changements de licence vous concernent même en self-hosting
Un changement de licence s'applique aux nouvelles versions du logiciel, pas rétroactivement à ce que vous avez déjà déployé. Mais rester sur une ancienne version signifie renoncer aux correctifs de sécurité. Le vrai risque n'est donc pas le procès immédiat : c'est la dette technique qui s'accumule pendant que vous attendez une clarification juridique.
Même un usage purement interne peut être concerné si votre organisation facture des services à des tiers ou expose l'outil via une API externe. Et la frontière entre « usage interne » et « service exposé » est précisément celle sur laquelle la SSPL et la BSL divergent — l'une en se concentrant sur la concurrence commerciale, l'autre en regardant qui consomme le service.
Depuis 2021, quatre vagues de relicenciements ont touché des composants présents dans des milliers de stacks de production : Elasticsearch (janvier 2021 → SSPL), Redis (mars 2024 → RSALv2+SSPL, puis mai 2025 → AGPLv3 disponible), Terraform (août 2023 → BSL), MariaDB MaxScale (janvier 2025 → propriétaire pur). À chaque fois, le changement a été annoncé avec moins d'un mois de préavis effectif sur la version suivante.
Les quatre cas où la licence crée une contrainte réelle
- Revente d'un service cloud concurrent — la BSL interdit explicitement d'offrir à des tiers un service commercial concurrent au produit d'origine. Héberger Terraform pour vos propres infrastructures reste autorisé ; le proposer comme plateforme managée à vos clients ne l'est plus depuis la version 1.6 (août 2023). C'est exactement ce qu'AWS, Google et Azure faisaient avec Redis, ce qui a motivé le relicenciement de mars 2024.
- Exposition d'un service tiers via SSPL — si vous construisez un service que des utilisateurs externes consomment et qui repose sur un composant SSPL, vous êtes tenu de publier l'intégralité de votre pile logistique, y compris vos scripts de provisionnement et d'orchestration. MongoDB applique la SSPL depuis octobre 2018 ; l'obligation ne s'active qu'au moment où vous proposez MongoDB « en tant que service » à d'autres.
- Intégration dans un SaaS sous AGPLv3 — tout éditeur qui intègre une bibliothèque AGPLv3 dans une application accessible via le réseau doit distribuer le code source complet de cette application. Pour un self-hoster interne, la contrainte est légère ; pour un éditeur SaaS, elle est structurante. Depuis août 2024, Elasticsearch propose à nouveau l'AGPLv3, ce qui le distingue de la SSPL dont il était sorti en 2021.
- Mise à jour vers une version sous nouvelle licence — passer de Redis 7.2 (BSD) à Redis 7.4+ (RSALv2+SSPL) ou de Terraform 1.5 (MPL-2.0) à 1.6+ (BSL) change vos droits sans que votre pipeline de mise à jour automatique ne s'en aperçoive. Redis 8.0 (2025) introduit une troisième option AGPLv3 — mais la version par défaut du paquet Ubuntu 24.04 est désormais Valkey (BSD-3-Clause), pas Redis.
Chronologie des relicenciements majeurs (2021–2025)
Comprendre le contexte de chaque décision aide à anticiper les suivantes. Voici la séquence qui a reconfiguré l'écosystème open source côté infrastructure :
Janvier 2021 — Elasticsearch et Kibana (Elastic). Elastic passe d'Apache 2.0 à une double licence SSPL / Elastic License 2.0 à partir de la version 7.11. La raison officielle : AWS proposait Elasticsearch managé sans contribuer en retour. AWS répond en forquant Elasticsearch 7.10.2 (dernière version Apache 2.0) pour créer OpenSearch, lancé en avril 2021 sous Apache 2.0 et transféré à la Linux Foundation en septembre 2024. En août 2024, Elastic fait marche arrière partielle et rajoute l'AGPLv3 comme option de licence — Elasticsearch est de nouveau « open source » au sens OSI.
Octobre 2018 / mars 2024 — MongoDB et Redis (SSPL). MongoDB est le premier à adopter la SSPL en 2018, créant un précédent que Redis finit par suivre le 20 mars 2024 en passant de BSD-3-Clause à RSALv2+SSPL à partir de la version 7.4. La Linux Foundation lance Valkey le 28 mars 2024 — quatre jours après l'annonce Redis — comme fork de Redis 7.2.4 sous BSD-3-Clause. Ubuntu 24.04, sorti en avril 2024, adopte Valkey comme paquet par défaut. En mai 2025, Redis ajoute l'AGPLv3 à son portefeuille de licences, notamment sous l'influence du créateur original Salvatore Sanfilippo (antirez), qui avait rejoint Redis Inc. en novembre 2024.
Août 2023 — Terraform et HashiCorp (BSL). Le 10 août 2023, HashiCorp bascule Terraform de MPL-2.0 à BSL 1.1 à partir de la version 1.6. Le manifeste OpenTF paraît le 15 août, recueille 32 000 étoiles GitHub en dix jours, et OpenTofu est accepté par la Linux Foundation le 20 septembre 2023. OpenTofu 1.6.0 (premier release sous gouvernance Linux Foundation) sort en janvier 2024 sous MPL-2.0.
Janvier 2025 — MariaDB MaxScale (propriétaire pur). MariaDB franchit un pas de plus : MaxScale 25.01 passe de BSL à licence entièrement propriétaire, nécessitant un abonnement MariaDB actif. Les versions antérieures (24.02, 23.08) restent sous BSL et convertiront vers GPL selon la clause de conversion temporelle.
BSL, SSPL et AGPLv3 : ce que chaque modèle autorise et interdit
La BSL (Business Source License) est une licence temporaire : le code est source-available aujourd'hui et basculera en open source — souvent Apache 2.0 ou GPL — après un délai fixé à l'avance (quatre ans chez HashiCorp, deux à trois ans chez MariaDB pour ses versions antérieures). La clause de restriction porte sur un « usage supplémentaire autorisé » défini par l'éditeur : chez HashiCorp, c'est la fourniture d'un service managé concurrent. L'usage interne, même commercial, reste libre.
La SSPL (Server Side Public License, version 1) va plus loin : exposer l'outil comme service à des tiers déclenche une obligation de publication totale de la pile — management software, interfaces utilisateur, APIs, outils d'automatisation, de monitoring, de backup et d'hébergement. MongoDB publie une FAQ précisant que l'obligation ne s'active que si vous offrez MongoDB « en tant que service » ; utiliser MongoDB comme base de données dans votre propre SaaS ne le déclenche pas. La SSPL n'est pas reconnue par l'OSI comme licence open source.
L'AGPLv3, la seule des trois approuvée par l'OSI, est un copyleft réseau : elle ne restreint pas l'usage commercial, mais oblige à ouvrir le code source de toute application qui intègre un composant AGPLv3 dès lors qu'elle sert des utilisateurs via le réseau. Pour un self-hoster qui ne distribue pas son application, la contrainte est quasi nulle. Pour un éditeur SaaS qui intègre une bibliothèque AGPLv3 dans un produit fermé, la contrainte est existentielle.
Les licences BSD / MIT / Apache 2.0 restent sans obligation de publication dans tous les cas d'usage : commercial, SaaS, service managé. C'est pourquoi les forks communautaires (Valkey, OpenTofu, OpenSearch) choisissent BSD-3-Clause ou Apache 2.0.
BSL vs SSPL vs AGPLv3 vs BSD en un coup d'œil
Faites défiler le tableau
| Licence | Self-hosting interne | Usage SaaS (revente) |
|---|---|---|
| BSL | Autorisé sans condition | Interdit si le service concurrence l'éditeur d'origine |
| SSPL | Autorisé sans condition | Autorisé si vous publiez toute votre pile logistique |
| AGPLv3 | Autorisé sans condition | Autorisé si vous distribuez le code source de votre application |
| BSD / MIT / Apache 2.0 | Autorisé sans condition | Autorisé sans obligation de publication |
Par outil : ce que le relicenciement change concrètement
Redis → Valkey ou Redis 8 AGPLv3.
Redis 7.2.x (BSD-3-Clause) reste librement utilisable à l'identique. Dès Redis 7.4, vous êtes sous RSALv2+SSPL : si votre usage est interne, il n'y a pas de contrainte immédiate, mais vous ne pouvez plus le redistribuer sous BSD. Le choix pratique : migrer vers Valkey (fork BSD, API-compatible Redis 7.2, paquet par défaut Ubuntu 24.04 et Debian 13, maintenu par AWS, Google et Oracle) ou, si vous souhaitez rester sur la codebase officielle, choisir la variante AGPLv3 de Redis 8 (disponible depuis mai 2025). La migration Valkey est non-destructive : le protocole RESP et les commandes sont identiques, et les clients Redis existants (redis-py, ioredis, Jedis) fonctionnent sans modification.
Elasticsearch → OpenSearch ou Elasticsearch AGPLv3.
OpenSearch 1.0 (fork d'Elasticsearch 7.10.2, Apache 2.0) est en production depuis juillet 2021. Il supporte les indices Elasticsearch jusqu'à la version 7.10. Si vous êtes sur Elasticsearch 7.x et ne migrez pas, vous restez sur une version sans correctifs de sécurité depuis mi-2023. Si vous souhaitez continuer avec Elastic, la variante AGPLv3 d'Elasticsearch 8.x (disponible depuis août 2024) est l'option la plus propre : pas d'obligation de redistribution pour un self-hoster interne. OpenSearch reste pertinent si vous avez des plugins ou des pipelines construits sur son API.
Terraform → OpenTofu.
OpenTofu 1.6+ est la continuité directe de Terraform 1.5 sous MPL-2.0. La syntaxe HCL est identique, les providers Terraform Registry sont compatibles (OpenTofu maintient son propre registry depuis 2024). Si votre usage se limite à gérer votre propre infrastructure, Terraform BSL est techniquement toujours gratuit — mais vous renoncez à la liberté de redistribution et vous dépendez d'une clause restrictive que HashiCorp peut modifier. OpenTofu est le choix sans friction pour un opérateur VPS qui automatise ses infras.
MongoDB → usage interne libre, service managé à couvrir.
Pour un self-hoster qui utilise MongoDB comme base d'une application interne ou d'un SaaS maison (où vous êtes l'opérateur du service), la SSPL ne s'active pas. Si vous envisagez de proposer « MongoDB as a Service » à des tiers, soit vous ouvrez votre pile complète (SSPL), soit vous prenez une licence commerciale MongoDB Enterprise. FerretDB (Apache 2.0) est une alternative compatible wire protocol PostgreSQL-backed, mais ne supporte pas encore tous les opérateurs de MongoDB 6+.
MariaDB MaxScale 25.01 → version antérieure BSL ou alternative.
La version 24.02 de MaxScale reste sous BSL et convertira vers GPL. Si vous dépendez de MaxScale pour le routage ou la réplication, geler sur 24.02 est la voie sans licence commerciale. ProxySQL (GPL-2.0) et HAProxy avec le module MySQL sont des alternatives établies pour le routage de trafic MySQL/MariaDB.
Redis a ajouté l'AGPLv3 à ses options de licence en mai 2025, rejoignant Elastic qui avait fait de même en août 2024. Pour un self-hoster qui n'expose pas son application à des tiers, choisir la variante AGPLv3 de Redis 8 est désormais possible sans passer par le fork Valkey — même si Valkey reste sous BSD-3-Clause et constitue le paquet par défaut sur Ubuntu 24.04 et Debian 13. Le critère de choix entre les deux : si vous avez besoin des nouvelles fonctionnalités de Redis 8 (Vector Sets, RESP3 amélioré), restez sur Redis AGPLv3 ; si vous voulez la licence la plus permissive sans aucune contrainte réseau, Valkey est le chemin sans friction.
Matrice de décision : quel fork pour quel cas d'usage
Avant de choisir entre l'outil original et son fork, posez trois questions dans l'ordre :
1. Quel est mon usage réel ? Interne uniquement (aucun tiers ne consomme le service) → la BSL et la SSPL ne créent aucune obligation immédiate, mais vous perdez la liberté de redistribution. Service exposé à des partenaires ou clients → vérifiez si votre cas entre dans la définition « service concurrent » (BSL) ou « offre du service à des tiers » (SSPL).
2. Y a-t-il un fork activement maintenu ? Pour Terraform → OpenTofu (Linux Foundation, 12 000+ étoiles en 2024). Pour Redis → Valkey (Linux Foundation, AWS + Google + Oracle). Pour Elasticsearch → OpenSearch (Linux Foundation depuis septembre 2024). Ces trois projets ont des SLA de patch de sécurité et des cycles de release publiés — critères minimaux pour un composant de production.
3. Le fork est-il API-compatible ? Valkey et Redis 7.2 : compatible à 100 % (protocol RESP, mêmes commandes). OpenTofu et Terraform 1.5 : compatible HCL, providers identiques. OpenSearch et Elasticsearch 7.10 : compatible pour la plupart des queries DSL, mais les plugins Elasticsearch 8.x ne sont pas portables.
Si un fork maintenu existe, est API-compatible et tient une cadence de sécurité : passez-y. Le coût d'une migration préventive est mesurable ; le coût d'une mise en conformité sous pression — notamment si une clause SSPL est activée par un changement d'usage — ne l'est pas.
Les réflexes à adopter avant d'intégrer un outil dans votre stack
Vérifiez la licence avant d'ajouter une dépendance. La licence se lit dans le fichier LICENSE à la racine du dépôt et dans le changelog des dernières versions majeures. Un outil qui était sous MIT il y a deux ans peut être sous BSL aujourd'hui — la mise à jour de votre docker-compose.yml ne le signalera pas.
Abonnez-vous aux releases GitHub. Le bouton « Watch → Custom → Releases » sur le dépôt d'un composant critique vous envoie un e-mail à chaque nouvelle version. C'est le seul canal qui garantit que vous voyez un changement de licence avant qu'il soit embarqué dans votre prochain apt upgrade ou helm upgrade.
Distinguez votre cas d'usage réel de celui que la licence cible. La BSL de HashiCorp ciblait AWS, Azure et Google — pas les équipes qui automatisent leur propre infrastructure. La SSPL de MongoDB ciblait les cloud providers — pas les développeurs qui utilisent MongoDB comme base d'un produit SaaS. Lire la FAQ officielle de chaque licence (MongoDB en publie une détaillée) évite de prendre des décisions conservatrices inutiles.
Évaluez le fork en amont, pas sous pression. Valkey, OpenTofu et OpenSearch existent précisément pour qu'une équipe puisse migrer sans urgence. Tester la compatibilité en environnement de développement prend quelques heures ; migrer en production sur une semaine après une annonce de relicenciement est une autre affaire.
Documentez la licence de chaque dépendance dans votre inventaire. Un tableau simple — outil, version en production, licence, date de dernier contrôle, fork disponible — transforme un audit ponctuel en maintenance continue. À mettre à jour à chaque bump de version majeure.
