Elastic setzt auf SSPL

Elastic geht mit seiner neuen Lizenzänderung gegen Amazon Web Services (AWS) vor. Elastic, Hersteller der Open-Source-Such- und Analyse-Engine Elasticsearch und des dazugehörigen Datenvisualisierungs-Dashboards Kibana, hat angekündigt, den Quellcode beider Programme von der Apache 2.0-Lizenz auf die Server Side Public License (SSPL) und die Elastic-Lizenz umzustellen.

Elastic erklärte dazu: „Diese Änderung der Quellcode-Lizenzierung hat keine Auswirkungen auf die überwältigende Mehrheit unserer Anwender-Community, die unsere Standard-Distribution kostenlos nutzen. Sie hat auch keine Auswirkungen auf unsere Cloud-Kunden oder Kunden mit selbstverwalteter Software.“ Aber während das bei den reinen Anwenderzahlen stimmen mag, sieht es bei den Zahlen der kommerziellen Nutzung ganz anders aus.

Das liegt daran, dass viele große Unternehmen keine Verträge mit Elastic haben. Stattdessen nutzen diese Unternehmen den Amazon Elasticsearch Service. Elasticsearch ist auch in anderen großen öffentlichen Clouds wie Elastic on Azure oder Elastic on Google Cloud verfügbar, aber in diesen Fällen hat Elastic eine Geschäftsbeziehung mit den Cloud-Anbietern. Das ist bei AWS nicht der Fall.

Dazu stellt Elastic ausdrücklich fest: „Warum also der Wechsel? AWS und Amazon Elasticsearch Service machen seit 2015 Dinge, die wir einfach NICHT OK finden, und es ist nur noch schlimmer geworden. Wenn wir uns ihnen jetzt nicht entgegenstellen, als erfolgreiches Unternehmen und Marktführer, wer dann?

Unsere Lizenzänderung zielt darauf ab, Unternehmen daran zu hindern, unsere Produkte Elasticsearch und Kibana zu nehmen und sie direkt als Service anzubieten, ohne mit uns zusammenzuarbeiten.“

Damit AWS oder andere Cloud-Anbieter Elasticsearch-Dienste unter der SSPL anbieten können, müssen sie der Giftpille zustimmen. Wenn sie solche Dienste anbieten, müssen sie alle Open-Source in der Infrastruktur ihrer Hosting-Cloud einsetzen. Die überwiegende Mehrheit der AWS-Software ist bereits quelloffen, und AWS wird wahrscheinlich niemals zustimmen, den ganzen Rest quelloffen zu machen.

Als AWS das erste Mal mit der SSPL konfrontiert wurde, reagierte es mit dem Forking des Codes, anstatt dieser Lizenz zuzustimmen. MongoDB, ein NoSQL-Datenbank-Unternehmen mit Open-Source-Dokumenten, hat die SSPL entwickelt. Seine Absicht war die gleiche wie die von Elastic, es wollte einen Anteil an den riesigen Gewinnen, die AWS mit dem Angebot von Elasticsearch-Diensten in seinen Cloud-Angeboten macht.

Eliot Horowitz, CTO und Mitbegründer von MongoDB, argumentierte dafür in der Diskussion der Open Source Initiative (OSI), ob die SSPL wirklich eine Open-Source-Lizenz sei: „Wir glauben, dass in der heutigen Welt das Verlinken durch die Bereitstellung von Programmen als Dienste und die Verbindung von Programmen über Netzwerke als Hauptform der Programmkombination abgelöst wurde. Es ist unklar, ob die bestehenden Copyleft-Lizenzen eindeutig auf diese Form der Programmkombination anwendbar sind, und wir beabsichtigen, dass die SSPL eine Option für Entwickler ist, um dieser Unsicherheit zu begegnen.“

Die OSI Open Source Initiative ist dieser Argumentation damals nicht gefolgt und tut es auch heute nicht. In einer Stellungnahme erklärte die OSI ganz offen: Die SSPL ist keine Open-Source-Lizenz. „Open-Source-Lizenzen sind die Grundlage für das Open-Source-Software-Ökosystem, ein System, das die gemeinschaftliche Entwicklung von Software fördert und erleichtert. Fauxpen-Source-Lizenzen erlauben dem Anwender zwar die Einsicht in den Quellcode, lassen aber andere höchst wichtige Rechte, die durch die Open-Source-Definition geschützt werden, nicht zu, wie z.B. das Recht, das Programm für jedes beliebige Arbeitsgebiet zu nutzen. Wie der jüngste Anwender Elastic in einem Posting mit dem unironischen Titel „Doubling Down on Open“ erklärt, kann Elastic nun „Cloud-Service-Provider davon abhalten, unsere Software als Service anzubieten“, was gegen OSD6 verstößt. Elastic hat nicht verdoppelt, sondern die Karten auf den Tisch gelegt.“

AWS hat als Antwort auf MongoDB DocumentDB auf den Markt gebracht, eine Datenbank, die „so konzipiert ist, dass sie mit Ihren bestehenden MongoDB-Anwendungen und -Tools kompatibel ist“, schrieb AWS-Evangelist Jeff Barr damals. Es gibt keinen Grund zu glauben, dass AWS dieses Mal nicht genau dasselbe tun wird.

Adrian Cockcroft, VP of Cloud Architecture Strategy bei AWS, erklärte bereits 2019: „Wenn AWS einen Service einführt, der auf einem Open-Source-Projekt basiert, gehen wir eine langfristige Verpflichtung zur Unterstützung unserer Kunden ein. Wir tragen Fehlerbehebungen, Sicherheits-, Skalierbarkeits-, Leistungs- und Funktionserweiterungen zurück in die Community. So haben wir zum Beispiel maßgeblich zu Apache Lucene beigetragen, das den Amazon Elasticsearch Service betreibt.

Elasticsearch hat eine Schlüsselrolle bei der Demokratisierung der Analyse von maschinengenerierten Daten gespielt. Es ist zunehmend zentral für die tägliche Produktivität von Entwicklern, Sicherheitsanalysten und Betriebsingenieuren weltweit geworden. Dank der freizügigen Apache 2.0-Lizenz konnte sie sich schnell durchsetzen und erlaubte die uneingeschränkte Nutzung der Software. Leider haben wir seit Juni 2018 eine signifikante Vermischung von proprietärem Code in die Codebasis erlebt. Zwar ist eine Apache 2.0-Lizenz immer noch verfügbar, aber es herrscht ein extremer Mangel an Klarheit darüber, was Kunden, denen Open Source wichtig ist, bekommen und worauf sie sich verlassen können.“

Damals sagte Cockcroft: „Unsere Absicht ist es nicht, Elasticsearch zu forken, und wir werden Beiträge zurück zum Apache 2.0-lizenzierten Elasticsearch-Upstream-Projekt leisten, wenn wir Erweiterungen für die Open-Source-Basis-Software entwickeln.“

Elastic hält jedoch dagegen: „Das ist nicht in Ordnung.  Unsere Lizenzänderung kommt nach Jahren dessen, was wir als Irreführung und Verwirrung der Community durch Amazon/AWS ansehen – genug ist genug.

Wir haben jeden verfügbaren Weg versucht, einschließlich der Gerichte, aber angesichts des anhaltenden Verhaltens von AWS haben wir uns entschlossen, unsere Lizenz zu ändern, damit wir uns auf die Entwicklung von Produkten und Innovationen konzentrieren können, anstatt Rechtsstreitigkeiten zu führen.“

Stephen O’Grady, Open-Source-Lizenzierungsexperte und Mitbegründer von RedMonk, einem auf Entwickler fokussierten Analystenunternehmen, meint: „Natürlich ist Elastic juristisch gesehen im Recht, die Änderung vorzunehmen: Aber ich bin generell kein Anhänger davon, dass Lizenzen eine Lösung für Geschäftsmodellprobleme sind. Ich glaube auch, dass einseitige Änderungen an Lizenzen, die ein vermeintliches Problem lösen sollen, wahrscheinlich wiederum unvorhergesehene andere Probleme schaffen werden.“

Für Unternehmen, die derzeit den ELK-Software-Stack verwenden, gilt: Bleiben Sie dran. Es kann sein, dass die Kosten steigen oder dass Ihr Cloud-Provider Sie dazu drängt, auf seinen selbstgebauten ELK-Stack umzusteigen, der auf der Software von vor dem Inkrafttreten der neuen Lizenz basiert.