Les Guerres des Licences Open Source : Comment HashiCorp, Redis et Elastic ont Changé les Règles

Le Schéma qui se Répète

Trois des projets de logiciels d'infrastructure les plus utilisés au monde ont changé leurs licences en l'espace de quelques années. HashiCorp a modifié Terraform, passant de la licence publique Mozilla 2.0 à la Business Source License (BSL) en août 2023. Redis est passé de BSD à la Server Side Public License (SSPL) en mars 2024. Elastic avait déjà déplacé Elasticsearch et Kibana vers SSPL en 2021. Les trois entreprises ont donné des explications similaires : les fournisseurs de cloud utilisaient leurs logiciels pour construire des services gérés concurrents sans contribuer en retour.

Tous les trois ont fait face à des forks immédiats de la communauté. OpenTofu (Terraform) est apparu quelques semaines après l'annonce de HashiCorp, soutenu par la Linux Foundation. Valkey (Redis) a été lancé en mars 2024, également sous la Linux Foundation, avec des commits d'ingénieurs d'AWS, Google, Oracle et Alibaba. OpenSearch (Elasticsearch) avait déjà été lancé en 2021, mené par AWS. Le schéma est suffisamment cohérent pour constituer un manuel de jeu — pour les deux camps.

Ce que les Changements de Licence Font Réellement

La Business Source License (BSL), développée par MariaDB et adoptée par HashiCorp, permet une utilisation gratuite pour la plupart des usages, mais interdit l'utilisation du logiciel dans un produit commercial concurrent sans licence commerciale. De manière cruciale, les logiciels sous licence BSL se convertissent en une licence open source (généralement Apache 2.0) après quatre ans. HashiCorp a fixé une fenêtre de conversion de quatre ans : Terraform 1.6, publié en août 2023, deviendrait Apache 2.0 en août 2027.

SSPL, créée par MongoDB, est plus agressive : elle exige que quiconque propose le logiciel en tant que service géré doit open-sourcer l'ensemble de la pile utilisée pour fournir ce service — y compris l'orchestration, la surveillance et l'infrastructure de support. Comme il est essentiellement impossible pour un fournisseur de cloud disposant d'une infrastructure propriétaire de s'y conformer, SSPL fonctionne comme une interdiction pratique d'offrir des services gérés. L'Open Source Initiative ne reconnaît pas SSPL comme une licence open source. La Free Software Foundation non plus. Redis et Elasticsearch sous SSPL sont, selon les définitions qui comptent le plus dans l'industrie, des logiciels propriétaires qui publient leur code source.

HashiCorp : L'Acquisition qui a Suivi

Le développement le plus significatif sur le plan commercial dans cette histoire est ce qui est arrivé à HashiCorp après le changement de licence. IBM a acquis HashiCorp en avril 2024 pour 6,4 milliards de dollars — l'une des plus grandes acquisitions dans le domaine des logiciels d'infrastructure d'entreprise. IBM exploite Red Hat, qui est construit presque entièrement sur des logiciels open source et est la plus grande entreprise Linux d'entreprise au monde. L'acquisition de HashiCorp apporte Terraform, Vault, Consul et Nomad dans le portefeuille d'IBM aux côtés d'OpenShift et d'Ansible de Red Hat.

Le fork OpenTofu, quant à lui, a atteint la version 1.7 en mai 2024, implémentant des fonctionnalités que Terraform n'avait pas encore livrées. Le soutien de la Linux Foundation signifie qu'OpenTofu bénéficie d'un support institutionnel et est peu susceptible de s'effondrer en raison de l'épuisement des mainteneurs — le sort de nombreux forks communautaires. OpenTofu est désormais une alternative crédible à long terme à Terraform pour les organisations mal à l'aise avec les restrictions de la BSL ou la propriété d'IBM.

La question pratique pour les équipes utilisant actuellement Terraform est simple : si vous n'offrez pas Terraform en tant que service commercialement et que vous n'êtes pas chez un fournisseur de cloud, la BSL ne vous restreint pas. La plupart des utilisateurs en entreprise ne sont pas affectés. Le changement de licence importe surtout aux entreprises qui souhaitent construire des services Terraform gérés — et pour elles, OpenTofu est la voie évidente.

Redis : Le Fork le Plus Rapide

Le changement de licence de Redis a été le plus dramatique en termes de rapidité et d'ampleur de la réponse. En une semaine après l'annonce de mars 2024, AWS, Google Cloud, Oracle et Alibaba Cloud avaient tous engagé des ressources d'ingénierie pour Valkey — un fork de Redis 7.2.4 sous la Linux Foundation, la dernière version sous l'ancienne licence BSD. Le dépôt GitHub de Valkey a eu plus de contributeurs au cours de son premier mois que la plupart des projets open source n'en accumulent en des années.

Redis Ltd. (l'entreprise, distincte du projet Redis) a maintenu que Redis n'a jamais été vraiment "open source communautaire" de la même manière que Linux ou PostgreSQL — il a toujours été contrôlé par l'entreprise. C'est techniquement vrai : Redis Ltd. détenait le droit d'auteur, exigeait un CLA pour les contributions et prenait toutes les décisions architecturales majeures. La licence BSD était un choix commercial, pas un principe fondateur. Lorsque le calcul commercial a changé — en particulier, lorsque AWS ElastiCache et d'autres services Redis gérés ont suffisamment grandi pour réduire de manière significative le marché adressable de Redis Ltd. — la licence a changé.

Valkey 7.2 est désormais l'offre compatible Redis par défaut sur plusieurs grandes plateformes cloud. Pour les nouveaux projets commençant aujourd'hui, le choix pratique se situe entre Valkey (Linux Foundation, Apache 2.0, support cloud natif) et Redis 7.4+ (SSPL, Redis Ltd., licence commerciale pour les services gérés). Les deux sont matures, performants et l'API est presque identique. L'écosystème se divise.

Elastic : Le Cas Plus Ancien qui Semble Maintenant le Modèle

Le changement de licence d'Elastic en 2021 a été le plus précoce et, à certains égards, le cas le plus clair. Elastic a déplacé Elasticsearch et Kibana vers SSPL en réponse directe à Amazon offrant un service Elasticsearch géré — Amazon Elasticsearch Service — sans contributions substantielles en retour au projet. La réponse d'Amazon a été de forker Elasticsearch 7.10 (la dernière version sous Apache 2.0) et de créer OpenSearch, qu'il maintient désormais et a contribué à la Linux Foundation.

Quatre ans plus tard, OpenSearch a divergé de manière significative d'Elasticsearch. AWS livre des fonctionnalités dans OpenSearch qui n'ont pas d'équivalent chez Elastic, et Elastic a livré des fonctionnalités dans Elasticsearch qui ne sont pas dans OpenSearch. Les deux ne sont plus interchangeables pour les cas d'utilisation avancés. Les équipes qui choisissent entre eux aujourd'hui choisissent en réalité entre deux produits différents qui partagent un ancêtre commun, pas entre "le vrai" et "un fork".

Le Modèle Open Core et ses Limites

Les entreprises qui ont le mieux évité cette dynamique sont celles qui ont construit des modèles open core dès le début, plutôt que de compter sur des licences permissives pour des produits populaires qu'elles espéraient monétiser plus tard. GitLab, Grafana et le propre Vault de HashiCorp sont des exemples où le produit de base est open source, mais des fonctionnalités substantielles pour l'entreprise (SSO, journalisation d'audit, RBAC avancé, outils de conformité) sont exclusivement commerciales. Cela crée une capture de valeur claire sans restreindre l'utilisation communautaire qui stimule l'adoption.

La voie du changement de licence — publier sous une licence permissive, construire une adoption massive, puis passer à une licence plus restrictive une fois qu'un fournisseur de cloud est en concurrence — est de plus en plus considérée comme une porte à sens unique. Une fois qu'un fork communautaire existe et bénéficie d'un soutien institutionnel, le projet original a perdu la bonne volonté de la communauté que la licence permissive générait. Il reste avec l'activité commerciale, mais sans le positionnement de "projet open source que tout le monde utilise" qui l'a porté.

Pour les développeurs et les équipes d'infrastructure, le message pratique est : traitez tout projet open source contrôlé par une seule entreprise avec une exigence de CLA comme potentiellement propriétaire. La licence que vous voyez aujourd'hui peut ne pas être celle qui régira le logiciel dans trois ans. Le logiciel open source le plus sûr, du point de vue du risque de licence, est celui qui appartient à une fondation (Linux Foundation, Apache Software Foundation, CNCF) ou qui a une gouvernance véritablement distribuée plutôt qu'un contrôle par une seule entreprise.

Ce qui Vient Ensuite

Les guerres de licences ne sont pas terminées. Plusieurs autres projets d'infrastructure largement utilisés — maintenus par des entreprises bien financées confrontées à la concurrence des fournisseurs de cloud — sont confrontés à des dynamiques similaires. Les entreprises ont observé ce qui est arrivé à HashiCorp, Redis et Elastic et prennent des décisions de licence en conséquence.

Un modèle émergent : la double licence dès le premier jour, où le logiciel est disponible à la fois sous une licence open source pour un usage communautaire et sous une licence commerciale pour un usage en entreprise en production, avec des limites claires qui ne changent pas rétroactivement. Un autre : la propriété par une fondation dès le départ, sans qu'une seule entreprise ne contrôle la licence. Aucun modèle ne résout parfaitement la tension fondamentale entre la dynamique d'adoption de l'open source et la monétisation commerciale des logiciels — mais les deux évitent les dommages de confiance qui découlent du changement de licence après que la communauté a déjà construit sur votre logiciel.