Der Konflikt zwischen AWS und Elastic rund um Elasticsearch
(blog.opsnow.com)Nachdem ich in letzter Zeit Artikel über den Verzicht von Elasticsearch auf Open Source, die Ausrufung der SSPL und darüber gelesen habe, dass AWS separat forken und die Open-Source-Community unter der Apache License 2.0 aufrechterhalten will, habe ich den seit Längerem andauernden Konflikt zwischen den beiden zusammengefasst.
Wenn es zwischendurch unvollständige oder falsche Stellen gibt, hinterlasst bitte Kommentare; diese sollen dann berücksichtigt werden.
10 Kommentare
Ich persönlich verstehe nicht so recht, warum die OSI die Einordnung der SSPL als Open-Source-Lizenz aufgehoben hat. Ich habe sie als eine gegenüber der AGPL etwas konkreter formulierte Lizenz verstanden, nach dem Motto, dass SaaS-Anbieter den gesamten Sourcecode offenlegen müssen. Deshalb kann ich nicht gut nachvollziehen, warum die OSI das als eine "Einschränkung" von SaaS auslegt.
Auch wenn man die Stellungnahme der OSI 1 liest, kritisiert sie eher die Absicht von Elastic bei der Einführung der SSPL, erklärt aber nicht, welche Klausel der SSPL die Nutzung "einschränkt". Wenn ich den Text lese, ist für mich nicht klar, ob sie im Vergleich zur AGPL tatsächlich zusätzliche "Einschränkungen" enthält. Vielleicht interpretiere ich die Lizenz auch falsch ...
MongoDB hatte den Lizenzantrag zurückgezogen. Er wurde nicht von der OSI abgelehnt. Zwar reagierte auch die OSI so, dass es wegen der umstrittenen Punkte schwer sei, dies als Open Source anzuerkennen, aber MongoDB hatte die Situation im Voraus erkannt und den Antrag selbst zurückgezogen.
Danke für die Korrektur. Meine Formulierung war etwas ungenau. Es stimmt zwar, dass MongoDB die Lizenz zuerst zurückgezogen hat, aber selbst wenn man sich den im Link genannten OSI-Beitrag ansieht, macht die OSI klar deutlich, dass sie die SSPL in ihrer aktuellen Version nicht akzeptieren will ... daher scheint mir die zeitliche Abfolge nicht besonders wichtig zu sein.
Ich stimme zu. ^^
Ich habe dazu auch einige Fragen und bin deshalb am Recherchieren; dabei habe ich dieses Material gefunden und verlinke es hier.
https://ceart.kr/component/file/…
Auszug
Zunächst unterscheidet sich die SSPL von der AGPL wie folgt. Die bisherige AGPL verlangt – ähnlich wie die GPL –, dass ein Diensteanbieter auch dann den gesamten Quellcode der Änderungen und Ergänzungen offenlegen muss, die er an einer Software vorgenommen hat, wenn diese Software nicht verteilt, sondern serverseitig ausgeführt wird; dies ist jedoch auf den Server selbst beschränkt.
Die SSPL verlangt dagegen nicht nur für den betreffenden Code, sondern bei einer Bereitstellung in Form von As-a-Service auch die Offenlegung des Quellcodes sämtlicher Software, die dafür ergänzend erforderlich ist und vom As-a-Service-Anbieter betrieben wird, etwa Verwaltungssoftware, Benutzeroberflächen, APIs, Automatisierungssoftware, Monitoring-Software sowie Backup- und Speichersoftware. Mit anderen Worten: Wenn Cloud-Anbieter MongoDB als Dienst bereitstellen, müssen sie nach dieser Bedingung sogar den gesamten Quellcode aller Software offenlegen, die sie entwickelt haben, um den Wettbewerbsvorteil ihres eigenen Dienstes zu erhalten.
Ich wollte mir auch noch MongoDB und Redis genauer ansehen … hier wurde das ja wirklich gut erklärt!
Zusätzlich wird im PDF auch erklärt, welche Teile nicht mit der OSI vereinbar sind. Es gehe dabei um Einschränkungen der Freiheit und Beschränkungen für separate Werke.
Oh … insgesamt ist das ein hervorragend gut geschriebenes PDF. Danke für den Link.
So betrachtet kann ich den Unterschied zur AGPL und auch den Grund, warum die SSPL nicht zugelassen wird, nachvollziehen, aber ich habe auch den Eindruck, dass die OSI etwas zu sehr auf permissive Lizenzen ausgerichtet ist.
Die gesamte Vorgeschichte war sehr gut aufbereitet und ließ sich angenehm lesen. Vielen Dank!
Siehe dazu:
https://de.news.hada.io/topic?id=3620 - AWS kündigt einen Open-Source-Fork von Elasticsearch und Kibana an
https://de.news.hada.io/topic?id=3606 - Elastic ändert die Lizenz, damit AWS sie nicht mehr nutzen kann