zurück zum Artikel

Nach der Anwendung der Commons Clause auf einige Redis-Enterprise-Add-ons schlägt die Open-Source-Community mit einem Fork zurück. Und bei MongoDB sorgt eine Lizenzänderung ebenfalls für Diskussionsstoff.

In Zeiten von Cloud-Diensten und Serverless Computing haben Open-Source-Software- und -Datenbank-Anbieter offenbar zunehmend das Problem, ihre (auch kommerziellen) Interessen zu schützen. Die aktuellen Diskussionen um Redis und nun auch die dokumentenorientierte NoSQL-Datenbank MongoDB zeigen, dass die Entwickler Auswege aus der Gemengelage durch neuartige "Open-Source-Lizenzmodelle" suchen. Die Einführung der Commons Clause für einige Redis-Enterprise-Add-ons [1] und die Umlizenzierung des MongoDB Community Server [2] repräsentieren jedoch zwei unterschiedliche lizenzrechtliche Herangehensweisen, um das gleiche Problem zu lösen.

Um gegen den nach ihrer Auffassung "Bruch der Spielregeln" der Open-Source-Community insbesondere durch Alibaba, Tencent und Yandex vorzugehen, hat MongoDB angekündigt, künftige Versionen des MongoDB Community Server unter die Server Side Public License (SSPL) zu stellen. Die Datenbank stand bislang unter der weitverbreiteten GNU Affero General Public License Version 3.0 (AGPLv3).

SSPL – Server Side Public License

Die SSPL, Version 1, trägt das Datum 16. Oktober 2018. Sie baut auf der GPLv3 – und nicht der AGPLv3 – auf, worauf MongoDB auch hinweist und sogar ein Mark-up der Änderungen der GPLv3 durch die SSPL zur Verfügung stellt [3]. Relevant sind danach nur die abgeänderten Regeln in Artikel 13 der Lizenz, der sinngemäß mit "das Programm als Service anbieten" überschrieben ist. Und genau darum scheint es MongoDB zu gehen. Auf seiner Webseite nimmt der Datenbankentwickler wie folgt Stellung:

"Wir stellen eine neue Lizenz zur Verfügung, um jegliche Verwirrung über die spezifischen Bedingungen für das Anbieten einer öffentlich zugänglichen MongoDB als Dienstleistung [Anm. "as a service"] zu beseitigen. Diese Änderung soll auch sicherstellen, dass Unternehmen, die eine öffentlich zugängliche MongoDB als Service betreiben, oder Software, die der SSPL unterliegt, an die Community zurückgeben. Es sei darauf hingewiesen, dass die neue Lizenz die gleichen Freiheiten beibehält, die die Community mit MongoDB unter der AGPL hatte – sie ist frei, den Quellcode zu verwenden, zu überprüfen, zu modifizieren und weiterzugeben. Lediglich die Voraussetzungen für das Angebot einer öffentlich zugänglichen MongoDB als Dienstleistung werden geändert." [Anm.: Übersetzung des englischen Originaltexts.]

Die SSPL betrifft alle MongoDB Community Patch Releases und Versionen, die ab dem 16. Oktober 2018 erscheinen. Brisant für Nutzer älterer Fassungen könnte sein, dass sie auch für zukünftige Patch Releases älterer Versionen gilt. Ob sie als Open-Source-Lizenz im Sinne der OSI-Definition gelten kann, soll die OSI auf Wunsch von MongoDB prüfen. MongoDB geht dabei davon aus, dass die OSI-Kriterien eingehalten werden.

MongoDB beschreibt das Hauptziel der Lizenzklausel wie folgt:

"Ein Unternehmen, das eine öffentlich zugängliche MongoDB als Dienst anbietet, muss die Software, die es verwendet, um einen solchen Dienst anzubieten, einschließlich der Verwaltungssoftware, der Benutzeroberflächen, der Anwendungsprogrammschnittstellen, der Automatisierungssoftware, der Überwachungssoftware, der Backup-Software, der Speichersoftware und der Hosting-Software, als Open Source dergestalt zur Verfügung stellen, dass ein Benutzer eine Instanz des Dienstes mit dem zur Verfügung gestellten Quellcode ausführen kann."

GPLv3 versus AGPLv3

Zur Begründung, warum die SSPL auf der GPLv3 und nicht der AGPLv3 beruht, erklärt MongoDB:

"Es gibt einige Verwirrung im Markt über den Anwendungsbereich und den Umfang der Remote Network Interaction Provision von AGPL. Aus diesem Grund haben wir uns entschieden, die SSPL auf der GPL v3 zu basieren und einen neuen Abschnitt 13 hinzuzufügen, der die Bedingungen für das Anbieten des lizenzierten Programms als Service klar und deutlich festlegt."

MongoDB erklärt zudem, dass ein konzerninterner Einsatz der MongoDB etwa für verbundene Unternehmen nicht unter den Anwendungsbereich der Klausel 13 fällt. Der Entwickler nimmt auch Stellung dazu, wie sich die SSPL von den umstrittenen Commons Clauses unterscheidet, die teilweise bei Redis zum Einsatz kommen:

"Die Commons-Klausel verbietet den Verkauf von Produkten oder Software, die auf der lizenzierten Software basieren, und ist daher kein Open Source. Die SSPL klärt lediglich die spezifischen Bedingungen für das Anbieten einer öffentlich zugänglichen MongoDB als Dienst, die mit den Prinzipien von Open Source übereinstimmen; es steht den Nutzern frei, die Software zu nutzen, zu überprüfen, zu modifizieren, zu verteilen oder Änderungen an der Software weiterzugeben."

Spannend sind die Ausführungen zur Frage, ob die SSPL mit "Freedom 0" der Free Software Foundation (FSF) in Einklang stehen:

"Die SSPL steht in Einklang mit "Freedom 0", da sie keine Einschränkungen für die Ausführung der Software für einen bestimmten Zweck vorsieht, sondern nur eine Bedingung stellt."

"Freedom 0" beschreibt die Freiheit, ein Programm nach eigenen Wünschen und für jeden Zweck auszuführen. Und genau hier setzen einige der Kritiker der SSPL an, die diese Bedingung als unvereinbar mit "Freedom 0" halten und daher der SSPL die Open-Source-Qualität absprechen. Sie gehen teilweise sogar noch weiter und werfen MongoDB bewusst vor, die SSPL unter Verwendung des Textes der GPLv3 als Open Source zu tarnen, was die SSPL in Wirklichkeit gar nicht ist.

Für andere ist das Vorgehen von MongoDB bei der Einführung der SSPL-Lizenz vergleichbar mit der Ergänzung der GPL-Lizenzfamilie im Rahmen der AGPL. Bei der AGPL wurde die GPL – ebenfalls in Abschnitt 13 – um eine Regelung für den Einsatz entsprechend lizenzierter Module im Rahmen von ASP oder Hosting ergänzt. Die AGPL ist sowohl von der OSI als auch der FSF als Open-Source-Lizenz anerkannt.

Alternative Monetarisierungsstrategie

MongoDB reichte die AGPL offenbar nicht aus. Sie verlangt die Lizenzierung der verwendeten AGPL-lizenzierten Programme nur, wenn diese auch verändert wurden. In Abschnitt 13 der AGPL heißt es: "… wenn Sie das Programm ändern, muss Ihre geänderte Version allen Benutzern, die über ein Computernetzwerk mit ihm aus der Ferne interagieren (wenn Ihre Version eine solche Interaktion unterstützt), die Möglichkeit bieten, den korrespondierenden Quellcode Ihrer Version zu erhalten". Zum einen greift dieses Recht also nur zugunsten derjenigen, die mit der "geänderten Version interagieren". Zum anderen besteht kein Lizenzanspruch, wenn ein unverändertes Modul eingesetzt wird.

Die AGPL bietet also keine Lösung, wenn man als kommerziell ausgerichteter Open-Source-Entwickler eine Monetarisierungsstrategie im Hinblick auf kommerziell ausgerichtete As-a-Service-Nutzer der Open-Source-Module fahren möchte, die die Datenbank unverändert verwenden. Wenn man sich die Umsätze und Größe von Unternehmen wie Yandex, Alibaba und Tencent anschaut, ist der Ärger von MongoDB nachvollziehbar.

Redis unterstellt "nur" Enterprise-Add-ons seinen restriktiveren neuen Lizenzbedingungen. Darüber, dass das für einige Add-ons gewählte Lizenzmodell von Redis nicht mehr den Open-Source-Definitionen von OSI und FSF entspricht, besteht in der Open-Source-Community weitgehend Einigkeit. Redis verlautete, dass der Redis Core auch in Zukunft unter einer Open-Source-Lizenz verbleibt und verfolgt damit einen Open-Core-Ansatz, bei dem es zusätzlich kommerzielle Angebote mit proprietären Versionen oder proprietären Add-ons gibt, für die Lizenzgebühren fällig werden.

Abkehr vom Open-Core-Ansatz

MongoDB verlässt mit seiner SSPL-Lizenz den Open-Core-Ansatz und stellt das Lizenzmodell für sein Hauptprodukt in Gänze um. Die Frage lautet also lediglich, ob MongoDB damit künftig noch Open Source ist oder nicht. Entscheidend dabei ist, ob die Bedingung der SSPL, sämtliche Module einer Serviceapplikation veröffentlichen zu müssen, eine Einschränkung im Sinne des "Freedom 0" darstellt. Vermutlich wird keine Antwort auf diese Frage alle Kritiker zufriedenstellen, denn ob es sich um eine "Einschränkung der Nutzbarkeit/Ausführbarkeit (und damit ein klarer Verstoß gegen die OS-Definition) oder eine "Bedingung für die Nutzung" (und damit zumindest nach Meinung von MongoDB kein Verstoß gegen die OS-Definition) handelt, ist doch eine sehr spitzfindige Angelegenheit. Zumal noch nicht klar ist, wie Gerichte verschiedener Jurisdiktionen die Sache deuten werden.

Ähnlich der GPL soll sich die SSPL auf weitere mit dem Lizenzgegenstand verknüpfte Module erstrecken. As-a-Service-Anbieter sollen nämlich Verwaltungssoftware, Benutzeroberflächen et cetera ebenfalls unter der SSPL lizenzieren. Das ist ein pauschaler und womöglich schwerwiegender Eingriff in die Rechtspositionen des Verwenders SSPL-lizenzierter Module. Für die betroffenen Unternehmen bedeutet das eine möglicherweise aufwendige juristische Prüfung, ob die jeweiligen Module nach den für sie geltenden Lizenzbedingungen überhaupt lizenziert werden dürfen. Hinzukommt die geschäftspolitische Frage, ob sie das im Einzelfall überhaupt wollen. Letztlich würden hierdurch nämlich andere As-a-Service-Anbieter gleichfalls das Recht auf Nutzung auch dieser Module bekommen, was beispielsweise einen Wettbewerbsvorteil zunichte machen könnte.

Fazit

Die Open-Source-Community kommt in Zeiten von Cloud- und insbesondere Serverless Computing nicht drumherum, Fälle wie Redis und MongoDB zu diskutieren. Die beiden Entwickler haben lizenzvertragliche Ansätze für das Dilemma "kommerzieller Open-Source-Entwickler" vorgelegt, die sich von insbesondere Cloud-Anbietern ausgenutzt fühlen. Redis wählt hierfür eindeutig den Open-Core-Ansatz, während MongoDB nach eigener Aussage "nur eine Bedingung" (condition) für die Nutzung beziehungsweise Ausführbarkeit künftiger Versionen der Datenbank "as a Service" aufstellt, nicht jedoch eine Einschränkung (restriction).

Es zeichnet sich ein Richtungsstreit ab, der nicht kurzfristig entschieden sein dürfte. Kritiker befürchten, dass immer mehr Entwickler nicht mehr auf bekannte Lizenzmodelle, wie etwa (A)GPL oder BSD zurückgreifen, sondern wie Redis und MongoDB ihre eigenen Lizenzen aufsetzen. Bis diese jeweils in die bekannten OS-Kriterien eingestuft sind, vergeht einige Zeit.

Problematisch ist die mit neuen OS-Lizenzmodellen einhergehende Konfusion auf dem Markt. Unternehmen mit einer Open-Source-Richtlinie stehen etwa vor der Aufgabe, neuartige Lizenzmodelle für sich zu bewerten und können nicht mehr ohne Weiteres auf ihre bisherigen Richtlinien zugreifen. Andererseits müssen auch Lizenzbedingungen für proprietäre Produkte stets auf deren Vereinbarung mit den unternehmerischen Anforderungen überprüft werden.

Die Auswirkungen der Entscheidungen von Redis und MongoDB sind noch nicht absehbar. Die schärferen Kritiker argumentieren im Sinne von "wehret den Anfängen" und befürchten eine Erosion des Open-Source-Ansatzes. Das erklärt ihre teils scharfe und polemische Argumentation. Andererseits müssen sich auch die Verfechter der etablierten Lizenzmodelle – seien es restriktive oder weniger restriktive – die Frage stellen, ob diese Lizenzmodelle angesichts des Wandels hin zu Cloud Computing noch zeitgemäß sind. Der Richtungsstreit dürfte noch eine Weile offen diskutiert werden. Sein Ausgang ist jedenfalls offen.

Tobias Haar, LL.M. (Rechtsinformatik), LL.M.,
ist Rechtsanwalt bei Vogel & Partner in Karlsruhe. Er beschäftigt sich seit über 15 Jahren mit IT-rechtlichen Fragestellungen, veröffentlicht regelmäßig in der iX und hält Vorträge, unter anderem zu Aspekten im Bereich Open Source. (map [4])

URL dieses Artikels:
https://www.heise.de/-4198630

Links in diesem Artikel:
[1] https://www.heise.de/ratgeber/Aerger-um-den-Einsatz-der-Commons-Clause-4156716.html
[2] https://www.heise.de/news/MongoDB-wechselt-die-Lizenz-4192568.html
[3] https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf?_ga=2.19279288.1654724984.1539951719-1312892386.1539951719&_gac=1.237816116.1539951725.EAIaIQobChMIwYmtlr-S3gIVSpztCh07VgHTEAAYASAAEgJ8__D_BwE
[4] mailto:map@ix.de

Copyright © 2018 Heise Medien