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.
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.
- 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.
- 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.
- Mise à jour vers une version sous nouvelle licence — passer de Redis 7.2 (BSD) à Redis 8 (tri-licence) ou de Terraform 1.5 (MPL-2.0) à 1.6 (BSL) change vos droits ; automatiser vos mises à jour sans vérifier le changelog de licence expose votre organisation à une transition non consentie.
BSL, SSPL et AGPLv3 : ce que chaque modèle autorise et interdit
La BSL est une licence temporaire : le code est source-available aujourd'hui, il basculera open source (souvent Apache 2.0) après un délai fixé à l'avance — quatre ans chez HashiCorp. L'usage interne est libre, la concurrence directe est bloquée. La SSPL va plus loin : exposer l'outil comme service à des tiers déclenche une obligation de publication totale de la pile. L'AGPLv3, seule des trois à être approuvée par l'OSI, est un copyleft réseau : elle protège la liberté des utilisateurs finaux sans interdire l'usage commercial, mais oblige à ouvrir le code de l'application contenante dès qu'elle sert des utilisateurs via le réseau.
BSL vs SSPL vs AGPLv3 vs BSD en un coup d'œil
| 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 |
Redis a ajouté l'AGPLv3 à ses options de licence en mars 2026, rejoignant Elastic qui avait fait de même en septembre 2024. Pour un self-hoster, choisir la variante AGPLv3 de Redis 8 est désormais possible sans passer par le fork Valkey — même si Valkey reste en BSD-3-Clause et constitue le choix par défaut sur Ubuntu 24.04 et Debian 13.
Les réflexes à adopter avant d'intégrer un outil dans votre stack
Avant d'ajouter un composant à votre infrastructure, vérifiez sa licence dans le dépôt et dans le changelog des dernières versions majeures. Distinguez votre usage réel : interne, exposé à des partenaires, ou vendu à des clients. Abonnez-vous aux releases GitHub des projets critiques pour détecter un changement de licence avant la prochaine mise à jour automatique. Si un fork sous licence permissive existe et est maintenu activement — OpenTofu, Valkey, OpenSearch — évaluez-le comme alternative pérenne.
