YakobchukOlena - Fotolia
Elastic change son modèle de licence pour contrer AWS
À partir de l’édition 7.11, les distributions d’Elasticsearch et de Kibana ne pourront plus être officiellement considérées comme open source. Elastic fait le choix d’une double licence pour mieux se protéger des éditeurs tiers, surtout d’AWS.
Shay Banon, PDG d’Elastic, a multiplié les articles de blog ces derniers jours concernant une « décision difficile » prise par son entreprise. Elastic souhaite mettre fin à son utilisation de la licence Apache 2.0 pour le code d’Elasticsearch et de Kibana. A la place, la société opte pour une formule double: Server Side Public Licence (SSPL) et la licence Elastic. Cette modification prendra effet dès la disponibilité de la mouture 7.11 du moteur de recherche et de l’outil de visualisation de données. La licence Elastic n’est pas nouvelle, elle s’applique aux versions par défaut de la distribution ELK (Elastic Logstach Kibana) depuis trois ans, rappelle le PDG.
« Ce changement de licence du code source n’a aucun impact sur l’écrasante majorité des utilisateurs de notre communauté qui déploient gratuitement notre distribution par défaut. Il n’a pas non plus d’impact sur nos clients “cloud” ou nos clients de logiciels self-managed », écrit Shay Banon.
Deux licences suivant les usages
Introduite en 2018, la licence Elastic empêche la modification et la redistribution du code source propriétaire associé, mais donne un accès gratuit et couvre certaines fonctionnalités proposées gracieusement reliées aux logiciels développés par l’éditeur.
La licence SSPL permet d’utiliser gratuitement les logiciels et de les modifier sans restriction. Seule la redistribution dépend d’une approche plus limitative. En revanche, elle n’est pas approuvée par l’Open Source Initiative (OSI) et donc ne répond pas officiellement aux critères de l’open source. Elle a été imaginée par MongoDB en 2018 qui a bien effectué la demande d’assentiment auprès de l’OSI, puis l’a retiré. Cette variante de la GPLv3 a été conçue pour se protéger des éditeurs qui vendent « directement » des logiciels libres ou leurs distributions mercantiles. La GPLv3 comporte déjà un mécanisme qui impose l’accès gratuit au code source des programmes modifiés s’ils sont commercialisés, mais MongoDB jugeait cette définition trop permissive.
SSPL transforme principalement la section 13 de l’APGL en ajoutant des précisions plus restrictives. Il ne s’agit plus de donner accès au code source du service, mais « y compris, sans limitation, les logiciels de gestion, les interfaces utilisateurs, les interfaces de programmes d’application, les logiciels d’automatisation, les logiciels de surveillance, les logiciels de sauvegarde, les logiciels de stockage et les logiciels d’hébergement […] ».
Elastic adopte de facto SSPL pour remplacer les versions estampillées avec la licence Apache 2.0 d’ElasticSearch et de Kibana et ainsi forcer les fournisseurs et les éditeurs tiers à payer pour redistribuer ces deux produits. Toutefois, Elastic n’abandonne pas totalement l’open source : il envisage même d’étudier la migration des fonctionnalités propriétaires de Beats, Agent et Logstash sous licence Apache 2.0. D’un autre côté, « 90 % des solutions téléchargées depuis trois ans », utilisées gratuitement ou non, sont sous licence Elastic.
Elastic et AWS, des relations…tendues
En réalité, l’éditeur affirme avoir été contraint à adopter cette approche pour contrer les mouvements d’AWS. Pour rappel, Elastic a porté plainte en septembre 2019 contre le géant du cloud pour publicité mensongère et contrefaçon de marque déposée après le déploiement de l’offre Open Distro for ElasticSearch. Ce projet sous licence Apache 2.0 développé en collaboration avec Netflix et Expedia avait pour but de « nettoyer le code propriétaire à l’intérieur de la structure open source ».
« Quand Amazon a annoncé sa fork pour Elasticsearch, ils ont utilisé un code que nous pensons avoir été copiés par un tiers (le spécialiste de la cybersécurité Floragunn GMBH, NDR) à partir de notre code commercial et l’ont livré dans le cadre du projet Open Distro. Nous pensons que cela a divisé encore plus notre communauté et a créé une confusion supplémentaire », commente le PDG d’Elastic. Et de poursuivre sur Twitter en expliquant que l’éditeur « est heureux de collaborer » avec la plupart des fournisseurs cloud, dont Microsoft et Google et même certaines entités d’AWS.
En février 2020, Andi Gutmans, Vice-président, Analytics et ElastiCache chez AWS, avait répondu par blog interposé qu’AWS avait vérifié le code avant d’entrer en partenariat avec ce tiers et qu’il a trouvé « aucune preuve que le module en question (Search Guard) contenait du code utilisé de manière inappropriée » ou « des éléments soumis à des copyrights ».
Mais cette affaire a réellement débuté en 2015 avec le lancement d’Amazon Elasticsearch Service.
« [Les responsables d’AWS] font des choses que nous pensons ne pas être acceptables depuis 2015 et la situation n’a fait qu’empirer. Si nous ne leur tenons pas tête maintenant, en tant qu’entreprise prospère et leader sur le marché, qui le fera ? », martèle Shay Banon.
« Notre changement de licence vise à empêcher les entreprises de prendre nos produits Elasticsearch et Kibana et de les fournir directement à la demande sans collaborer avec nous », ajoute-t-il.
L’open source se tarit-il ?
L’éditeur suit non seulement les traces de MongoDB, mais également de MariaDB et CockroachDB. CockroachDB a notamment adopté une variante « permissive » de la Business Source Licence (BSL) (imaginée par MariaDB) imposant aux éditeurs d’acheter la licence avant de redistribuer le produit. Le code source des versions entreprises de la base de données est libéré trois ans après leur disponibilité initiale. À terme, Shay Banon étudie la possibilité qu’Elastic adopte un modèle similaire afin d’appliquer une seule licence. Redis Labs et Neo4j ont pour leur part introduit des clauses limitatives pour des modules de base pour empêcher les fournisseurs de cloud de construire des services SaaS à partir de leurs technologies.
La première annonce publiée par Elastic le 14 janvier 2021 a suscité des interrogations au sein de la communauté. Certains ont approuvé la conduite de l’éditeur, d’autres considèrent que la mesure prise est trop forte. Certains se désolent que leurs contributions à un projet open source ne soient pas respectés.
Quelques utilisateurs d’ElasticSearch et de Kibana envisagent de changer d’outils, en se penchant par exemple sur les capacités de Solr et de Grafana.
Comme s’y attendait Elastic, des concurrents entendent « profiter de la confusion » (du FUD, Fear Uncertainty and Doubt en VO) ou proposer des alternatives, suivant de quels points de vue se place-t-on. Tomer Levy, fondateur et CEO de Logz.io, une plateforme de monitoring basée sur ELK (Elasticsearch, Logstash, Kibana) a annoncé la volonté de créer « une véritable distribution open source » d’Elasticsearch et de Kibana.
« Notre objectif est de faire en sorte que ces deux nouveaux projets soient menés par plusieurs organisations et non par une seule. Il est prévu qu’ils soient toujours sous Apache 2.0 et qu’ils soient pilotés par la communauté, de sorte qu’ils puissent finalement être versés à des fondations telles que l’ASF ou la CNCF, comme le suggèrent les comités de pilotage. Notre mission commune sera d’encourager la collaboration, de libérer l’innovation et de servir la communauté au sens large », promet Tomer Levy.
Et de critiquer férocement la position du PDG d’Elastic. « Elastic a énormément profité de la mise à disposition d’Elasticsearch et Kibana à la communauté en tant que “source ouverte”. Cela a permis d’amorcer le marché, de favoriser l’adoption et de créer une entreprise valorisée à plus ou moins 15 milliards de dollars. Après avoir fait cela, il semble opportun de prétendre soudainement qu’ils doivent fermer la source parce que d’autres organisations peuvent en bénéficier ».
Le CTO de Logz.io a également tenu des propos similaires sur Twitter, des déclarations considérées comme mensongères par Shay Banon.
