La semaine dernière, Elasticsearch a repris du galon dans la communauté open source. En effet, Shay Banon, fondateur et directeur technique d’Elastic, a indiqué que « dans les semaines à venir, la société ajoutera l'AGPL [GNU Affero General Public License] comme autre option de licence à côté de l'ELv2 [Elastic License 2.0] et de la SSPL [Server Side Public License] ». Il a ajouté que l’entreprise « n’a jamais cessé de croire en l’open source ». Pour expliquer ce retour aux sources, le dirigeant évoque de meilleurs rapports avec AWS.

Après le changement de licence d'Elastic en 2021, AWS ne pouvait plus copier-coller Elasticsearch pour en faire une de ses offres de services. Finalement, AWS a opté pour un fork et développé un produit concurrent appelé OpenSearch, qui a connu un succès grandissant. Selon Shay Banon, à partir du moment où « Amazon était pleinement investi dans son fork » et que « le manque de clarté du marché autour des marques Elasticsearch d'Elastic avait été en grande partie résolu », Elastic a estimé qu'elle n'avait plus à s'inquiéter de la vente d'Elasticsearch par AWS sous sa marque propre. Au contraire, « le partenariat avec AWS est plus fort que jamais ».

Une licence approuvée par l’OSI

L’affaire des licences chez Elastic avait laissé des traces au sein de la communauté. Ainsi, Vicky Brasseur, experte en open source avait estimé dans un post que la SSPL est un problème pour les entreprises. « Il s’agit d’une licence propriétaire hostile travestie avec des habits open source.  D’autres sont plus radicaux dans leur sentiment suite à l’annonce de l’éditeur. Ainsi, Peter Zaitsev, co-fondateur de la société spécialisée dans l'open source Percona, a déclaré « RIP Elastic Open Source... Une grande perte pour la communauté Open Source mais peut vous aider à gagner quelques dollars supplémentaires, à court terme ».

Au final le choix de la licence AGPL va calmer les esprits en étant approuvée par l’open source initiative (OSI). Elle est plus permissive que l'ELv2 [Elastic License 2.0] et de la SSPL [Server Side Public License] qui était là pour bloquer les fournisseurs de cloud comme AWS. La question, selon le chroniqueur Matt Asay est de savoir si cette décision va entraîner d’autres entreprises vont suivre le mouvement.

Des forks fortuits

Nombreux sont ceux qui pensaient que le fork d'AWS sur Elasticsearch sonnait le glas d'Elastic. Ce n'est pas ce qui s’est passé. OpenSearch, aussi bon soit-il pour AWS, n'a pas été mauvais pour Elastic. Bien au contraire. En forçant AWS à construire OpenSearch plutôt que d'emprunter au code d’Elasticsearch, Elastic s'est donné la possibilité de reprendre sa pratique open source. Comme l'a répété Shay Banon, « en ce qui me concerne, j'ai toujours voulu revenir à l'open source, même quand nous avons changé la licence ». Ajoutant : « Nous espérions qu'AWS développerait un fork et nous laisserait revenir en arrière après un certain temps ». Ce risque calculé semble porter ses fruits : « Nous pensons pouvoir le faire en toute sécurité maintenant que la bifurcation a eu lieu et qu'il s'agit d'un coût irrécupérable important pour AWS », a-t-il déclaré.

Plus récemment, AWS, en collaboration avec d'autres entreprises, a développé un fork de Redis pour créer le projet Valkey. Du point de vue d'AWS, Valkey diffère de tout ce qui a été fait auparavant, car c'est l'un des rares projets où l'un des principaux contributeurs au projet forké était un employé d'AWS. Il est également inhabituel que cette même employée, l'impressionnante Madelyn Olson, contribue plus que n'importe qui d'autre. Par exemple, si l’on regarde un projet typique de la Cloud Native Computing Foundation, AWS ne figure presque jamais parmi les cinq premières entreprises contributrices (Kubernetes, OpenTelemetry, et d'autres). Valkey pourrait être un signe positif pour AWS et l'open source. Le projet pourrait aussi avoir un impact formidable pour Redis, car AWS pourrait tellement investir dans Valkey qu'il n'aurait plus de raison d’offrir un service Redis (ElastiCache), comme cela s'est produit avec Elasticsearch.