Elasticsearch lâche l’open source face aux fournisseurs cloud

Elasticsearch est-il encore open source ? Oui, mais plus pour longtemps, admet Elastic, l’entreprise qui porte le projet. En l’occurrence, jusqu’à la sortie, dans quelques semaines, de la version 7.11 du moteur de recherche et d’analyse distribué.

Le code source, actuellement distribué en Apache 2.0, basculera vers un système de double licence « à la carte » : Elastic et SSPL, non approuvées par l’OSI.

La première de ces licences est en place depuis 2018. Elle 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).

Ce modèle avait d’abord impliqué l’adjonction de fonctionnalités payantes. Par exemple, un système d’alertes et des briques de machine learning. S’y étaient ensuite adjointes des composantes gratuites, entre autres pour le monitoring et le débogage.

Elastic avait fini par regrouper toutes ces fonctionnalités dans un X-Pack. Elle l’avait intégré dans la distribution de base de son moteur de recherche et d’analyse, en activant par défaut les outils gratuits. En septembre 2018, elle en avait ouvert le code… sous sa licence maison.
Celle-ci donne, dans les grandes lignes, le droit de consulter le code, de créer des tickets et de soumettre des requêtes pull. Elle interdit, en revanche, la modification – en tout cas pour un usage en production – et la redistribution d’Elasticsearch. À moins de nouer un partenariat avec Elastic.

SSPL : un catalyseur nommé AWS ?

Au sens de la licence Elastic, la « redistribution » inclut la fourniture d’offres SaaS. Plus précisément celles dont Elasticsearch est soit la principale pièce, soit une « raison substantielle » d’adoption.

Fondée sur GPLv3, la licence SSPL (Server Side Public License) lève cette barrière. Mais elle pose une condition importante : quiconque propose un programme – ici, Elasticsearch – à des tiers en tant que service doit ouvrir gratuitement 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 qui tire « entièrement ou principalement » sa valeur dudit programme.

L’obligation d’ouverture ne se limite cependant pas au service fourni. Elle englobe aussi tous les éléments sur lesquels repose ledit service : interfaces de gestion, automatisations, stockage, hébergement, etc. Assez pour qu’un utilisateur « puisse exécuter sa propre instance du service ».

Elastic affirme chercher à canaliser les fournisseurs cloud qui se nourrissent de ses innovations sans contribuer en retour. L’entreprise tente surtout de rassurer au vu de la confusion que son initiative suscite (et que le fragment de thread Twitter ci-dessous illustre).

Made in MongoDB

« L’écrasante majorité des utilisateurs ne seront pas touchés », résume Elastic. Y compris ceux qui développent des applications SaaS… aussi longtemps qu’Elasticsearch est en back-end (c’est une autre affaire si ces applications donnent un accès au moteur). Rien ne changera, par ailleurs, pour ceux qui exploitent la distribution Elasticsearch de base (sous licence Elastic).

MongoDB fut l’instigateur de la licence SSPL. Il avait commencé à l’appliquer en octobre 2018 à son édition Community Server. Son argumentation était du même ordre que celle qu’a aujourd’hui Elastic : protéger les investissements dans le logiciel libre.
Chez les Cloud Service Providers (CSP), AWS avait réagi en lançant, début 2019, l’alternative DocumentDB, partiellement compatible avec MongoDB.

Quelques semaines plus tard, le leader du cloud hyperscale avait reconduit cette approche en ouvrant OpenDistro for Elasticsearch. Un projet « 100 % Apache v2 » engagé avec Expedia et Netflix et dont l’ensemble des contributions remontent jusqu’à Elasticsearch.

Aujourd’hui encore, la branche cloud d’Amazon se défend d’avoir voulu créer un fork. Elle déclare s’être engagée sur cette voie après avoir constaté, depuis la mi-2018, l’ingérence de code propriétaire dans les dépôts Elasticsearch… sans que la documentation le clarifie.

Elastic ne cache pas le contentieux qui est né de cette décision. L’entreprise n’a pas engagé de poursuites contre AWS, mais le cite, notamment, dans la plainte qu’elle a déposée en septembre 2019 contre l’éditeur allemand à l’origine de Search Guard. Il est reproché à ce plug-in pour Elasticsearch d’exploiter du code propriétaire. Et à AWS, de faire usage de ce plug-in.

Illustration principale © agsandrew – shutterstock.com