Elasticsearch redevient open source… mais pas sous sa licence d’origine
![Elasticsearch open source](https://www.silicon.fr/wp-content/uploads/2024/09/Elasticsearch-open-source.jpg)
Elasticsearch revient à l’open source non pas en réadoptant Apache 2.0, mais en proposant une option « compatible » : AGPLv3.
Elasticsearch, à nouveau open source ?
C’est une question de semaines, selon Elastic, l’entreprise commerciale qui porte le projet. Elle entend effectivement adopter la licence AGPL, reconnue par l’OSI.
Pas de retour, donc, vers Apache 2.0, licence sous laquelle le code source fut distribué jusqu’en janvier 2021. Elasticsearch avait ensuite basculé vers un système « à la carte » avec deux options : une licence maison (Elastic License) et SSPL (Server Side Public License).
SSPL-Elastic License : depuis 2021, Elasticsearch sorti des clous de l’open source
Mise en place en 2018, la licence maison a accompagné le développement du modèle open core (cœur fonctionnel ouvert + modules additionnels propriétaires) sur l’ensemble de la pile Elastic (Elasticsearch, Kibana, Beats, Logstash). Elle donne le droit de consulter le code, de créer des tickets et de soumettre des PR. Elle interdit la modification, en tout cas pour un usage en prod. Ainsi que la redistribution, à moins de nouer un partenariat avec Elastic. Le terme « redistribution » inclut la fourniture d’offre SaaS. Plus précisément celles dont Elasticsearch est soit la principale pièce, soit une « raison substantielle » d’adoption. En ligne de mire, les fournisseurs cloud se nourrissant du code pour lancer des offres managées sans contribuer en retour.
SSPL – dont MongoDB est l’instigateur – lève cette barrière, mais pose une condition importante, destinée là aussi à canaliser les CSP. Quiconque proposer un programme à des tiers en tant que service doit gratuitement ouvrir le code source de son implémentation. Cela vaut pour qui donne accès au programme en lui-même (ou à une version modifiée). Mais aussi pour qui propose un service tirant « entièrement ou principalement » sa valeur dudit programme. L’obligation d’ouverture n’englobe pas que ledit service. Elle comprend aussi les éléments sur lesquels il repose : interfaces de gestion, automatisations, stockage, hébergement, etc. Assez pour qu’un utilisateur puisse « exécuter sa propre instance du service ».
Principale cible de ce changement de licence, AWS avait réagi en lançant un fork, aujourd’hui connu sous le nom d’OpenSearch. Fondé sur Elasticsearch 7.10, il a pris le relais du projet OpenDistro for Elasticsearch, en conservant la licence Apache 2.0. Aiven, Canonical, Cohere, Intel, Linagora, NetApp, Oracle, SAP et Slack y contribuent, entre autres. La compatibilité avec Elasticsearch n’est plus garantie sur la branche 2.x, ouverte en mai 2022.
Pas d’Apache2, mais une licence « compatible »
SSPL et Elastic License resteront d’actualité. Elastic y ajoutera l’option AGPLv3. Sans pour autant supprimer le CLA, qui suppose donc que les contributeurs continueront à céder leurs droits.
Contrairement à SSPL, AGPL est « compatible » avec Apache 2.0… en étant néanmoins plus restrictif. Il n’impose pas de donner accès au code source de l’ensemble des implémentations, mais tout de même à celui de tout programme (ou dérivé) auquel on donne accès par voie de réseau. Et ce sous la même licence.
Grafana Labs a aussi fait le choix d’AGPL, pour l’essentiel du code de Grafana, Loki et Tempo. Une transition effectuée en 2021. Il fit de même en 2022 pour la base de données Cortex, forkée pour l’occasion sous le nom de Mimir.
Plus récemment Canonical a opéré la même bascule depuis Apache 2.0 pour le projet LXD. Redis a pour sa part abandonné BSD au profit du duo SSPL-RSALv2 (Redis Sources Available License). La seconde de ces licences interdit toute commercialisation on fourniture en tant que service managé.
Elastic assure que quasiment quatre ans après le changement de licence et le conflit ouvert qui s’est ensuivi, son partenariat avec AWS est « plus fort que jamais ». Par ailleurs, le marché a désormais bien compris le positionnement d’Elasticsearch par rapport à OpenSearch, veut croire l’éditeur. Et d’affirmer avoir choisi AGPL « [en espérant] que [ses] travaux avec l’OSI aboutiront à davantage d’options dans le monde des licences open source »…
Illustration © pexels – Shutterstock