Le conflit entre AWS et Elastic autour d’Elasticsearch
(blog.opsnow.com)Après avoir vu récemment des articles sur l’abandon de l’open source par Elasticsearch, la déclaration du SSPL et la décision d’AWS de créer un fork séparé afin de maintenir une communauté open source sous licence Apache License 2.0, j’ai résumé le conflit entre les deux entreprises qui dure depuis longtemps.
S’il y a des points incomplets ou erronés en cours de route, n’hésitez pas à les signaler en commentaire ; ils seront pris en compte.
10 commentaires
Personnellement, je ne comprends pas bien pourquoi l’OSI a retiré au SSPL son inscription comme licence open source. C’est, à mes yeux, une licence qui précise davantage l’AGPL, et je l’avais comprise comme obligeant les fournisseurs SaaS à rendre public l’ensemble de leur code source. Du coup, j’ai du mal à comprendre pourquoi l’OSI interprète cela comme une « restriction » du SaaS.
Même en lisant la prise de position de l’OSI 1, j’ai l’impression qu’elle pointe surtout l’intention d’Elastic en adoptant le SSPL, sans expliquer quelle clause du SSPL « restreint » réellement son utilisation.
Quand je lis le texte, je ne vois pas bien en quoi il impose plus de « restrictions » que l’AGPL. Peut-être que c’est moi qui interprète mal la licence...
C’est MongoDB qui a retiré la licence. Ce n’est pas l’OSI qui l’a rejetée. Bien sûr, l’OSI a aussi réagi en disant qu’il était difficile de la reconnaître comme open source sur certains points controversés, mais MongoDB avait anticipé cette situation et a donc retiré sa demande.
Merci pour la correction. Ma formulation était un peu imprécise. Cela dit, même si c’est bien MongoDB qui l’a retirée en premier, le billet de l’OSI indiqué dans le lien montre clairement que l’OSI n’a pas l’intention d’accepter la version actuelle de la SSPL… Du coup, la chronologie ne me semble pas si importante.
Je suis d'accord. ^^
Moi aussi, je me pose quelques questions et je faisais des recherches ; j’ai trouvé ce document, donc je partage le lien.
https://ceart.kr/component/file/…
Extrait
Tout d’abord, voici en quoi la SSPL diffère de l’AGPL. L’AGPL, auparavant, exigeait que même lorsqu’un logiciel n’est pas distribué mais exécuté côté serveur, le fournisseur de service rende publics, comme avec la GPL, tous les codes source des modifications et ajouts apportés à ce logiciel ; cette obligation reste toutefois limitée au serveur lui-même.
La SSPL, en revanche, impose de publier non seulement le code concerné, mais aussi le code de tous les logiciels qu’un utilisateur d’un service As-a-Service exécute pour fournir ce service, comme les logiciels d’administration nécessaires en complément, l’interface utilisateur, les API, les logiciels d’automatisation, de supervision, de sauvegarde et de stockage. Autrement dit, lorsque des fournisseurs cloud proposent MongoDB sous forme de service, ils doivent également publier l’intégralité du code source de tous les logiciels qu’ils ont développés pour conserver leur avantage concurrentiel sur ce service.
J’allais aussi me pencher sur MongoDB et Redis... c’était donc déjà très bien expliqué ici !
De plus, si vous regardez le PDF, il y est aussi expliqué quels points ne sont pas conformes à l’OSI. Il s’agirait de restrictions à la liberté et de limitations sur les œuvres dérivées distinctes.
Oh… dans l’ensemble, c’est un PDF remarquablement bien rédigé. Merci pour le lien.
Vu sous cet angle, je comprends la différence avec l’AGPL ainsi que les raisons pour lesquelles la SSPL n’est pas acceptée, mais j’ai aussi l’impression que l’OSI penche un peu trop du côté du permissif.
L’historique complet était très bien récapitulé, ce qui l’a rendu agréable à lire. Merci !
Voir les articles associés
https://fr.news.hada.io/topic?id=3620 - AWS annonce un fork open source d'Elasticsearch et de Kibana
https://fr.news.hada.io/topic?id=3606 - Elastic modifie sa licence pour empêcher l'utilisation par AWS