News

Erklärende Worte zur Änderung des Lizenzmodells

Von
Shay Banon

Zu unserer Änderung des Lizenzmodells für Elasticsearch and Kibana gab es eine Reihe Fragen. Während wir unsere FAQ entsprechend aktualisieren, möchten wir kurz erläutern, wer von dieser Änderung betroffen ist:

  • Die Änderung hat keine Auswirkungen auf unsere „On-Premises“- und Elastic Cloud-Kunden.
  • Die Änderung hat keine Auswirkungen auf die übergroße Mehrheit unserer Nutzer.
  • Die Änderung hat Auswirkungen auf all jene, die unsere Produkte nehmen und sie direkt im Rahmen ihres SaaS-Angebots als Dienst verkaufen, wie z. B. der Amazon Elasticsearch Service.

Wenn Sie die Produkte verwenden oder eine Anwendung entwickeln, die auf Elasticsearch und Kibana aufsetzt, möchten wir nichts an Ihrem Status ändern. Da wir viele Fragen erhalten, aktualisieren wir unsere FAQ ständig, aber wenn Sie noch eine Frage haben, die in den FAQ nicht beantwortet wird, kontaktieren Sie uns bitte unter [email protected].

Wir möchten außerdem erläutern, wie die duale Lizenz funktioniert. Wir haben den Quellcode von Elasticsearch und Kibana von der Apache-2.0-Lizenz auf ein duales Lizenzmodell aus Elastic-Lizenz und SSPL umgestellt. Sie können wählen, welche Lizenz Sie verwenden möchten:

  • Die SSPL ist eine sehr bekannte Lizenz – MongoDB wird von Millionen unter dieser Lizenz genutzt. Wir haben uns für diese Lizenz als Option entschieden, um den Millionen von Entwicklern, die mit MongoDB arbeiten, die Entscheidung zu erleichtern. Die SSPL, eine „Copyleft“-Lizenz auf der Basis von GPL, ist zwar keine OSI-Lizenz und wird auch nicht als Open Source angesehen, bietet aber viele der Freiheiten von Open Source.
  • Die Elastic-Lizenz ist ebenfalls eine sehr bekannte Lizenz – wenn Sie, wie Millionen anderer und mehr als 90 Prozent unserer Downloads in den letzten drei Jahren, unsere Standarddistribution verwenden, nutzen Sie sie bereits und es bleibt für Sie alles beim Alten. Es handelt sich bei ihr um eine „Source-available“-Lizenz. Sie erlaubt die kostenlose Nutzung ohne die „Copyleft“-Einschränkungen der SSPL. Die Elastic-Lizenz erlaubt es jedoch nicht, das Produkt direkt als SaaS-Dienst zu verkaufen, wie das beim Amazon Elasticsearch Service der Fall ist, die Produkte weiterzuvertreiben, den Quellcode zu hacken, um auch ohne Abonnement Zugriff auf kostenpflichtige Features zu erhalten, oder in Produktionsumgebungen mit abgeänderten Versionen der Produkte zu arbeiten.

Zukunft der Elastic-Lizenz

Wie bereits in unseren FAQ angemerkt, sind wir angesichts des bisher eingegangenen Feedbacks dabei zu überlegen, wie wir die Elastic-Lizenz weiter vereinfachen können. Wir finden uns mit unseren Zielen recht gut im Geist der von MariaDB entwickelten BSL wieder, die auch von CockroachDB genutzt wird. Im exzellenten Blogpost von CockroachDB zur dortigen Entscheidung für den Umstieg auf die BSL heißt es: „Wir glauben, dass dies die beste Möglichkeit darstellt, ein Gleichgewicht zwischen den betriebswirtschaftlichen Anforderungen und unserem Engagement für Open Source zu schaffen“.

Die BSL, die auch vom OSI-Gründer Bruce Perens befürwortet wird, ist eine einfache, parametrisierte Lizenz, die jedes Unternehmen an die eigenen Bedürfnisse anpassen kann. Sie gewährt das Recht, das lizenzierte Werk zu kopieren, abzuändern, abgeleitete Werke zu erstellen und zu verteilen, solange die „Zusätzliche-Nutzungsrechte“-Parameter erfüllt sind. Wir denken gegenwärtig über ein zusätzliches Nutzungsrecht nach, das einen Einsatz in Produktionsumgebungen gestatten würde. Dabei würden lediglich die folgenden drei Einschränkungen gelten:

  • Das lizenzierte Werk darf nicht für ein „Elasticsearch/Kibana-as-a-Service“-Angebot genutzt werden.
  • Die Software darf nicht gehackt werden, um auf kostenpflichtige Features zuzugreifen, ohne dass ein Abonnement abgeschlossen wurde.
  • Es dürfen weder Verweise auf die Marke Elastic noch Elastic-Warenzeichen aus dem Produkt entfernt, ersetzt oder unkenntlich gemacht werden (z. B. durch das Ersetzen von Logos usw.).

Nach Ablauf einer bestimmten Zeit, in der Regel 3 bis 4 Jahre, jedoch nicht mehr als 5 Jahre, laufen die Einschränkungen aus und der Quellcode wird automatisch unter eine Open-Source-Lizenz gestellt; in unserem Fall wäre dies Apache 2.0.

Um Unklarheiten zu vermeiden, sei hiermit darauf verwiesen, dass BSL keine von der OSI bestätigte Lizenz ist.

Wir möchten, dass die Sache Hand und Fuß hat, und nehmen uns daher so viel Zeit, wie wir benötigen. Im Idealfall haben wir am Ende eine einzige Lizenz, die sowohl unsere kostenlosen als auch unsere kostenpflichtigen Features abdeckt und trotzdem weitestgehend offen ist. Das ist jedoch nicht ganz einfach zu bewerkstelligen, vor allem, wenn der Code nach 3 bis 4 Jahren Open Source werden soll. Wenn uns das so gelingt, dass uns daraus kein Schaden erwächst, können wir für unsere kommerziellen Features mehr Freiheiten gewähren und unsere Distribution unter eine einfache Lizenz stellen. Dies ist eine Herausforderung, die es wert ist, mit ganzer Kraft angegangen zu werden. Wir haben Sorge, dass sie missbraucht wird – Sie wissen schon, von wem :) –, und möchten daher um Nachsicht bitten, wenn es etwas länger dauert.

Sollten wir zu dem Schluss kommen, dass dieser Weg nicht der richtige ist, werden wir darüber nachdenken, das Lizenzmodell in eine Elastic-Community-Lizenz auf BSL-Basis und eine vereinfachte Elastic-Lizenz für unsere kostenpflichtigen Features aufzuteilen.

Wie im Blogpost erwähnt, beabsichtigen wir, das Ganze bis zur Veröffentlichung von Version 7.11 abzuschließen. Daher sind wir sehr an Ihrem Feedback interessiert! Lassen Sie uns unter [email protected] wissen, ob diese Herangehensweise für Ihren Anwendungsfall funktionieren würde.