Pour faire écho à Elastic, qui a changé la licence de ses produits Elasticsearch (moteur de recherche) et Kibana (visualisation de données), Amazon vient d’annoncer il y a peu la sortie de son produit OpenSearch en open-source, un fork de ces deux produits.
Pour rappel, en janvier 2021, à l’issue de la sortie d’Elastic 7.11, la compagnie qui publiait ses produits Elasticsearch et Kibana sous licence Apache 2.0, a fini par les proposer sous deux licences, au libre choix de ses utilisateurs : Server Side Public License ou licence publique côté serveur (SSPL) et sous licence Elastic (ELv2).
Bien qu’étant toutes deux des licences « code source disponible », la seconde pose trois limites principales (plus de détails sur ces limites), là où la première se limite à une seule condition : publier les modifications apportées, y compris le code source sous la même licence.
D’ailleurs, pour appuyer ce changement de licence, Shay Banon, fondateur et CEO d’Elastic expliquait que le fait qu’Amazon et Amazon Elasticsearch Service s’autorisent des libertés comme fournir directement ses produits (Elasticsearch et Kibana) sans coopération avec eux (alors qu’ils avaient collaboré sur d’autres produits Amazon) ne pouvait être accepté. Un comportement jugé non-conforme aux normes et valeurs importantes de l’écosystème open-source, appuie-t-il.
Mais les rivalités sur ce point ne sont pas terminées, semble-t-il, et au regard des réponses de la team d’Amazon concernant ce changement de licence en SPPL, qui selon eux ressemble à de l’open-source mais ne respecte pas le côté libre et ouvert. Selon la team, ce changement ne limitera pas d’autres d’offrir des services hébergés sur la base d’Elasticsearch. https://aws.amazon.com/fr/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/
Pour Banon, Amazon et la dénomination de son produit Amazon Elasticsearch Service sème la confusion parmi les utilisateurs, en faisant croire que le service a été fourni via une collaboration d’Elastic.
Maintenant, Amazon explique que son fork, en version Alpha, d’Elasticsearch et Kibana, est basé sur la version 7.10, sous licence Apache v2 (APLv2), et qu’il continuera de s’appuyer sur les efforts de la communauté open-source, planifiant par la même occasion de changer le nom de son service en Amazon OpenSearch Service.
# libre
Posté par CrEv (site web personnel) . Évalué à 9.
J'enfonce un peu des portes ouvertes, mais j'ai l'impression que la dépêche tourne un peu autour du pot :
Le point principal ici est que la suite elastic n'est désormais uniquement disponible sous des licences non libres. Amazon fork donc en permettant de garder cette suite sous licence libre.
Ni la SSPL ni la ELv2 ne sont compatibles GPL ni approuvées par l'OSI.
[^] # Re: libre
Posté par Sébastien Dinot (site web personnel) . Évalué à 4.
Il existe moult licences libres non compatibles avec la licence GNU GPL. Le caractère libre d'une licence ne se mesure pas à sa compatibilité avec la licence GNU GPL, mais à sa conformité avec la Free Software Definition (FSD).
De même, une licence peut être libre ou open source sans être approuvée par l'OSI, tout simplement parce que les auteurs de la licence n'ont pas entrepris la démarche d'adoubement par l'OSI. Il s'agit donc plutôt ici de savoir si la licence est conforme ou non à l'Open Source Definition (OSD).
Pour illustrer mon propos, prenons le cas des licences de la famille « ESA Public License », à ne pas confondre avec celles de la famille « ESA Community License ». Les licences ESA Public License (il en existe 3, dites « Strong Copyleft », « Weak Copyleft » et « Permissive », respectivement nommées « Type 1 », « Type 2 » et « Type 3 » dans les précédentes versions) sont des licences libres, au sens où elles me semblent parfaitement conformes à la FSD et à l'OSD (elles ont été rédigées en ce sens). Pourtant, elles ne sont identifiées et cataloguées ni par la FSF, ni par l'OSI.
Quant à savoir si l'ESA a eu raison ou non de rédiger ses propres licences plutôt que d'opter pour des licences libres bien connues du public, cela est une autre question…
[^] # Re: libre
Posté par CrEv (site web personnel) . Évalué à 7.
Certes.
Le point principal étant "la suite elastic n'est désormais uniquement disponible sous des licences non libres."
Déjà fait : The SSPL is Not an Open Source License
Quant à la license ELv2 elle ne respecte par le point 3 de l'OSD
Donc bref, on peut discuter des licences libres par rapport aux définitions de la FSF, de l'OSI, ni la SSPL ni la ELv2 ne sont des licences libres.
[^] # Re: libre
Posté par Sébastien Dinot (site web personnel) . Évalué à 2.
Je sais que ni la SSPL, ni l'ELv2 ne sont libres, de nombreux commentaires ont été fait un peu partout sur Internet à ce sujet. Mon message n'avait pas pour but d'évoquer un doute à ce sujet, mais juste de signaler que la justification donnée dans le message que j'ai commenté n'était pas valide.
Je suis un peu pointilleux sur le sujet, cela fait partie de mon job.
[^] # Re: libre
Posté par barmic 🦦 . Évalué à 1.
Ils ont annoncé redistribuer le code en apache avec un délai. C'est ce qu'on retrouve avec l'open core de gitlab par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: libre
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Intéressant. Je ne savais pour gitlab ; ils le font ?
[^] # Re: libre
Posté par CrEv (site web personnel) . Évalué à 3.
Tu as un lien sur ce point ? J'ai pas trouvé et la FAQ est assez clair sur le fait que ce n'est plus open source du tout.
[^] # Re: libre
Posté par barmic 🦦 . Évalué à 3.
Je ne l'ai pas retrouvé moi non plus. J4avais entendu ça dans un podcast, mais j'ai dû me fourvoyer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: libre
Posté par Sébastien Dinot (site web personnel) . Évalué à 4.
Je ne sais pas ce qu'il en est d'Elastic Search, mais Gitlab n'a pas de politique de publication à retard « programmée ».
Je suis admiratif de la maturité de Gitlab vis-à-vis du libre et de sa communauté. L'entreprise a opté pour un modèle open core assez classique, mais la plupart des éditeurs qui optent pour ce modèle n'ont pas l'intelligence d'enrichir continuellement (et avec des fonctions attrayantes) la version libre. Ils ne songent qu'à accroitre l'écart fonctionnel qui sépare la version libre de la version payante, en espérant que cela conduira les clients à payer. Or, en faisant cela, ils nourrissent l'amertume des utilisateurs de la version libre, qui finissent par se tourner vers une alternative dès qu'ils le peuvent. Ils frustrent en outre terriblement les quelques contributeurs qu'ils arrivent à ferrer et ceux-ci finissent eux aussi par tourner le dos au projet. Le modèle open core, souvent mal géré, asphyxie les communautés. L'éditeur ne réalise pas qu'il se condamne à endurer tous les inconvénients du libre, sans jamais bénéficier de ses avantages et de la dynamique qu'il peut susciter.
Gitlab a compris cela et entretient intelligemment sa communauté, il la nourrit de nouvelles fonctions chaque mois (une nouvelle version de Gitlab étant publiée le 22 de chaque mois), organisant même le buzz à l'approche de la libération des fonctions les plus excitantes. Il interagit avec elle, lui pointe des bugs faciles à corriger, des fonctions qu'il serait ravi d'intégrer, mais qu'il a décidé – en tout cas pour l'instant – de ne pas implanter lui-même (cf. label Accepting merge request). Bref, Gitlab sait qu'il a une communauté exigeante et il sait être à la hauteur. Sa communauté accepte du coup plutôt bien la logique open core qui la révulse chez d'autres.
Ceci étant, notons que cette intelligence est sans doute aiguillonnée par le fait que Gitlab doit évoluer dans un écosystème très concurrentiel, entre outils libres (Gitea), outils propriétaires gratuits (Github) ou payants (suite Atlassian), sans oublier d'autres outils open core (Tuleap).
# Ça va permettre de comparer deux modèles de développement
Posté par Jean Gabes (site web personnel) . Évalué à 8.
Les deux le font pour des motivations uniquement économiques. Amazon ne peux se payer le luxe d'avoir à négocier avec un partenaire qui peux via sa licence l’empêcher de proposer telle ou telle offre, donc il n'ont pas le choix que forker.
De l'autre, ne gagnant que 0$ de la part d'Amazon, ils ont besoin d'une offre qui va différentier leur offre commerciale (c'est pas sur l'hébergement cloud d'un même code que tu peux concurrencer Amazon…).
Bref, mouvement normal des deux côtés d'un point de vue économique, rien à voir avec la morale ou tout autre point de vue.
Par contre ça va être intéressant à voir sur qui va avoir le plus de contributeurs: est-ce qu'un projet principalement hébergé chez Amazon va attirer des dev, plus qu'un code ouvert mais pas open source.
Sachant que ce sont les deux modèles auxquels il va falloir s'habituer dans le futur, il va être intéressant de suivre où les utilisateurs et les dev vont aller.
[^] # Re: Ça va permettre de comparer deux modèles de développement
Posté par Psychofox (Mastodon) . Évalué à 6.
En dehors de la licence qui le permettait, on peut se poser la question si il y avait beaucoup de contribution externe à la compagnie Elasticsearch B.V. et si celle-ci avait créé un environnement encourageant les contributions externes. Ce n'est pas parce que tu distribues ton licence sous licence libre que tu acceptes les patches des autres et/ou que le code est sur une forge publique ou qu'une mailing list a été mise en place pour traiter les contributions.
[^] # Re: Ça va permettre de comparer deux modèles de développement
Posté par Paf . Évalué à 4.
Elasticsearch est super basique sur AWS. Il y a pas mal de limitations et ne rend pas la vie facile.
Du point de vu experience utilisateur, la version d'Elastic est a des annees lumiere. Ils ont aussi des opportunites qu'AWS ne pourra jamais explorer (ex: cross-cloud).
Je trouve qu'au contraire cela a beaucoup a voir avec la morale. Elastic avait un melange de code libre et non-libre au sein du meme depot. Ils n'encouragent pas non plus une communaute de developpeurs. En fait, ils ont une position qui n'est pas egale aux autres contributeurs.
Ils veulent surtout le benefice du libre sans les inconvenients de facon a ce que leur produit soit facile a introduire et essayer, mais que l'on soit force de leur payer si on veut utiliser cela en production.
Je comprends l'appetit economique d'Elastic et leur attitude anti-competitive, mais en tant qu'utilisateur de logiciel libre, cela me force a considerer d'autres alternatives libres telles qu'Apache Solr.
[^] # Re: Ça va permettre de comparer deux modèles de développement
Posté par barmic 🦦 . Évalué à 6.
D'autres cloud ont des partenariats avec elastic et ça n'a pas l'air de les tuer. Je vois pas en quoi c'est du luxe.
J'ai beaucoup de mal à imaginer amazon savoir gérer un projet communautaire. Je ne les ai jamais vu ailleurs que dans leur propre écosystème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Quelle alternative à Elasticsearch et Opensearch ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Dans le cas où cette rivalité entraîne la mort des produits, quelle serait l'alternative? SOLR ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Quelle alternative à Elasticsearch et Opensearch ?
Posté par claudex . Évalué à 3.
Il faut voir ton cas d'utilisation. Si c'est juste pour stocker des logs, tu as Loki aussi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelle alternative à Elasticsearch et Opensearch ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est pour la recherche foule texte sur des données métiers.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.