Quo Vadis Open-Source-Datenbanken?

Wie Open-Source-Lizenzmodelle in Zukunft aussehen könnten.

In den letzten Monaten haben sich einige Open-Source-Software-Anbieter im Datenbankbereich dazu entschlossen, ihre Lizenzpolitik zu ändern und teilweise neue, aber auch restriktivere Open-Source-Lizenzmodelle einzuführen.

In diesem Artikel werden die Hintergründe dieser Änderungen und die Handlungsoptionen der Beteiligten am Beispiel von MongoDB, Redis und Neo4j untersucht. Darüber hinaus wird erörtert, inwieweit die vorgenommenen Änderungen mit den Grundsätzen der Open-Source-Bewegung in Einklang stehen.

Lizenz-Modelle

Die genannten OSS-Datenbankanbieter MongoDB, Redis und Neo4j haben im Laufe des Jahres 2018 Lizenzänderungen von AGPLv3 auf andere Lizenzmodelle vorgenommen. In der aktuellen Version lauten diese nun wie folgt:

• MongoDB Community Server: Vollständige Umstellung von AGPLv3 auf SSPL (Server Side Public License = eigene Variante der GPLv3) für alle Patch-Releases und Versionen ab 16.10.2018.
  Es ist unklar und rechtlich umstritten, ob die SSPL noch eine OSS-Lizenz ist, soweit sie als Lizenzbedingung die Offenlegung der Zusatztools der Cloud-Anbieter verlangt (Ziffer 13). MongoDB hat einen entsprechenden Antrag bei der OSI eingereicht.
• Neo4j Enterprise-Ausgabe: Zweistufiger Wechsel von AGPLv3 zu einem Open-Core-Modell.Erster Wechsel von AGPLv3 zu AGPLv3 mit Commons-Klausel. Letztere ist eine kommerzielle Lizenz, die zunächst parallel angeboten wurde (sogenanntes „duales Lizenzmodell“).Ab Neo4j 3.5 ist der gesamte Quellcode nicht mehr wie bisher öffentlich. Alle Erweiterungen, die Teil der Enterprise-Version sind, sind nicht mehr auf GitHub verfügbar, so dass Neo4j 3.5 Enterprise nur noch als Binärversion unter einer kommerziellen Version erhältlich ist. Die Community Edition als funktionaler Kern ist weiterhin unter der GPLv3 verfügbar. Diese Kombination repräsentiert das sogenannte „Open Core“-Modell mit einer Unterscheidung zwischen offenem Kern und nicht offengelegtem Quellcode für Erweiterungen.
• Redis Enterprise-Erweiterungen: Wechsel für einige Enterprise Add-ons, wie ReJSON, RediSearch und Redis Graph von APGLv3 zu einer Kombination aus Apache Licence 2.0 mit Commons Clause. Unter der Annahme, dass die Commons-Klausel eine nicht Open-Source-konforme Lizenzbedingung ist, ergibt sich ein offenes Kernmodell in der Variante eines vollständig offengelegten Quellcodes.

Auch wenn die OSS-Datenbankanbieter unterschiedliche Wege gegangen sind, ist das Problem, das sie zu lösen haben, das gleiche. Die OSS-Datenbankanbieter sehen sich und ihre kommerziellen Interessen zunehmend bedroht, sowohl durch die Verletzung eher impliziter Grundsätze der Geschenkökonomie als auch durch explizit vereinbarte Lizenzbedingungen innerhalb der Open-Source-Gemeinschaften durch die zunehmende Zahl und Bedeutung der verschiedenen Cloud-Anbieter.

Die Rolle der Cloud-Anbieter

Nicht nur klassische Cloud-Anbieter, sondern zunehmend auch Anbieter von Serverless Computing wie Tencent, Alibaba oder Amazon stellen OSS-Datenbanken als kommerziell orientierte „As-a-Service“-Dienste bereit. Sie lassen die Datenbank selbst unverändert, um deren Lizenzbedingungen nicht zu verletzen.

Sie ergänzen diese jedoch durch leistungsfähige Verwaltungssoftware, Benutzerschnittstellen und vereinfachte APIs. Dies reicht bis hin zur Bereitstellung von DB-Abstraktionsschichten, die teilweise einen erheblichen Mehrwert gegenüber der reinen Datenbank darstellen. Da diese Zusatzleistungen in der Regel ohne direkte Zusatzkosten und eingebettet in andere Angebote von Cloud-Anbietern verfügbar sind, werden sie gerne angenommen, auch wenn die (kosten- und lizenzpflichtigen) Angebote der Datenbankhersteller umfangreicher und qualitativ besser sind.

Damit gefährden Cloud-Anbieter als direkte Konkurrenten eine der zentralen Monetarisierungsstrategien von Open-Source-Anbietern: von der Möglichkeit, eigene Kundenbeziehungen zu OSS-Nutzern aufzubauen und diesen zusätzliche Dienstleistungen wie Installation, Konfiguration oder Support im Zusammenhang mit OS-Software bis hin zur kundenspezifischen Softwareentwicklung anzubieten.

Die OSS-Datenbankhersteller bereichern damit einerseits das gesamte Leistungsspektrum der Cloud-Anbieter, werden aber andererseits sowohl als eigenständiges Produkt als auch hinsichtlich ihrer datenbankspezifischen, komplexen Eigenschaften zunehmend ausgehöhlt – sie werden zu einem teilweise unsichtbaren, austauschbaren Vorprodukt. Eine Differenzierung über eigenständige Produktangebote mit einem anspruchsvolleren Funktionsumfang sowie spezialisierte, auf die Produkte zugeschnittene Serviceangebote wird dadurch schwieriger wahrnehmbar.

Gleichzeitig entfallen individuelle Kundenprobleme im Zusammenhang mit der Nutzung von Datenbanken, die früher oft von den OSS-Datenbankanbietern selbst kostenpflichtig gelöst werden konnten. Auch wenn die Originalhersteller diese deutlich höhere Komplexität im Paket umsetzen können (Hochverfügbarkeit, Performance Monitoring, Lastverteilung, Speicheroptimierung, Individualentwicklung, Troubleshooting, Skalierung etc.), sind die Cloud-Anbieter aufgrund ihrer Position in der Wertschöpfungskette, ihrer Distribution, ihrer Preisstruktur und ihrer Marktmacht zunehmend im Vorteil und können sich als direkte Wettbewerber positionieren. Ganz zu schweigen davon, dass sie zunehmend eigene Produkte auf den Markt bringen und aggressiv vermarkten.

Dies ist ein besonderes Problem für kleine und mittlere Unternehmen: Ihre Dienste werden durch die massive Skalierbarkeit der Cloud-Anbieter an den Rand gedrängt. Die großen Anbieter sind in der Lage, viele Funktionalitäten zu automatisieren und als Inklusivleistungen ohne zusätzliche Kosten anzubieten. Auf diese Weise verschwinden Monetarisierungspotenziale für kleine und mittlere Anbieter von Diensten im Cloud-Umfeld ohne Gegenleistung.

Ist alles verloren?

Nach Ansicht der Anbieter von Open-Source-Datenbanken verletzen die Cloud-Anbieter grundlegende Regeln für die Nutzung von OSS, ohne die das Open-Source-Universum nicht funktionieren kann.
Tatsache ist, dass die Cloud-Anbieter die Herstellergemeinschaft (hier überwiegend kleine oder mittlere Unternehmen) nicht in Form von Beiträgen zum Quellcode entschädigen oder entschädigen (sog. „contribution“). Auch gibt es keine finanzielle Beteiligung, z.B. in Form eines Umsatz- oder Marktanteils an den Umsätzen, die die Cloud-Anbieter direkt oder indirekt mit den beteiligten Datenbanken erzielen.

Vor einem solchen Verstoß gegen die Spielregeln fühlten sich die OSS-Datenbankanbieter durch die bisher verwendeten Lizenzmodelle nicht ausreichend geschützt. Diese stellten weder sicher, dass die von den Cloud-Anbietern entwickelten Zusatztools dem Datenbankanbieter in Form von offengelegtem Quellcode wieder zur Verfügung gestellt werden mussten, noch konnte diese Form der Kommerzialisierung durch die Cloud-Anbieter verhindert werden.

Die AGPLv3 befasst sich zwar explizit mit der Bereitstellung von Software als SaaS / ASP / Hosting („…mit ihr über ein Computernetz aus der Ferne interagieren…“), jedoch wird hier nur geregelt, dass auch diese Bereitstellungsformen einen Fall der Verbreitung von Software darstellen. Eine Aussage darüber, ob bei der Nutzung von Zusatztools durch Cloud-Anbieter immer eine „copy-left“-relevante Verbindung der Zusatztools mit der Datenbanksoftware zwingend erforderlich ist (d.h. als abgeleitetes Werk oder als „modifizierte Version“), findet sich in der AGPL nicht und dürfte daher im Einzelfall schwer nachzuweisen sein. Zudem würde selbst die Existenz von „copy-left“ aufgrund der absoluten Dominanz von Cloud-Anbietern auf den Zugangsmärkten nicht zu der gewünschten Verschiebung der Marktanteile zugunsten der Open-Source-Datenbankanbieter führen.

Es ist davon auszugehen, dass die Nutzer wahrscheinlich weiterhin die Datenbankangebote der Cloud-Anbieter nutzen würden. Die fast ausschließliche Kommerzialisierung der Software durch die Cloud-Anbieter würde also nicht verhindert werden.

Mögliche Lösungen?

Was kann man also tun, um langfristig gegen die Cloud-Anbieter zu bestehen? Die gewählten Lösungsvarianten der Datenbankanbieter unterscheiden sich vor allem im Umfang des von der Lizenzänderung betroffenen Quellcodes (von Teilen bis hin zum gesamten Quellcode) und der mit der Lizenzänderung verfolgten Zielsetzung (Offenlegung des Quellcodes von DB-Add-on-Tools der Cloud-Anbieter bis hin zum umfassenden Verbot der Kommerzialisierung) voneinander.

Allen Varianten gemeinsam ist jedoch, dass das Unterscheidungsmerkmal „OSS“ als starker Markenbestandteil nicht aufgegeben wird und die Lizenzänderungen die OSS-Bewegung stärken sollen.

So zielt MongoDB, insbesondere durch Abschnitt 13 seiner SSPL (Server Side Public License), auf die Rückgabe („Contribution“) von Quellcode an die Community ab:

Alle Unternehmen, die MongoDB als Dienst anbieten, sind verpflichtet, die zusätzlichen Werkzeuge, die zur Bereitstellung des Dienstes verwendet werden (Verwaltungssoftware, Benutzerschnittstellen, Anwendungsprogrammschnittstellen, Automatisierungssoftware, Überwachungssoftware, Sicherungssoftware, Speichersoftware und Hosting-Software) so bereitzustellen, dass ein „Benutzer eine Instanz des Dienstes mit dem bereitgestellten Quellcode ausführen kann“.

Redis hingegen will eine Kommerzialisierung durch Cloud-Anbieter gänzlich verhindern: Redis verwendet für seine Enterprise-Add-ons die sogenannte Commons-Klausel (in Verbindung mit einer Apache-Lizenz), die den Verkauf der betroffenen Add-ons durch Dritte explizit untersagt, wenn es sich um Produkte/Dienstleistungen des Dritten handelt, deren Wert sich ganz oder teilweise aus der Funktionalität der Redis-Software selbst ergibt. Verkauf bedeutet hier sowohl die Bereitstellung gegen Entgelt als auch eine sonstige Gegenleistung („…einschließlich und ohne Einschränkung, Hosting-Gebühren…“).

Natürlich lassen sich gegen jede der vorgenommenen Lizenzänderungen Einwände im Hinblick auf ihre „OSS-Reinheit“ und die Einhaltung der Reinheitsdoktrin erheben:

Ist die SSPL von MongoDB tatsächlich ein Verstoß gegen die „Freedom 0“ der Free Software Foundation (FSF), weil sie die Ausführung der Software für einen bestimmten Zweck einschränken kann?

Oder ist sie nur eine sekundäre Bedingung für die Ausführung (laut MongoDB und dem Autor dieses Artikels)?

Ist die Common Clause zu jeder Zeit und in jeder denkbaren Situation mit den OSS-Prinzipien unvereinbar? Muss immer der gesamte Quellcode eines Produkts veröffentlicht werden oder genügt dafür der Softwarekern des Produkts?

Einige Linux-Distributionen wie Debian und Red Hat haben zumindest im Falle von MongoDB die Frage der OSS-Reinheit bereits für sich entschieden und MongoDB aus den Distributionen entfernt. Ob der von MongoDB vorgelegte Entwurf einer SSPLv2 an der Akzeptanz seitens OSI und der Distributionen etwas ändern wird, ist derzeit offen.

Wenn die Diskussion jedoch nicht nur zu akademischen Zwecken geführt werden soll, scheint es wichtiger zu sein, bei der Bewertung von Zulassungsänderungen und deren möglicher Anpassung an drogenökonomische Implikationen den folgenden Aspekt im Auge zu behalten:

Die Spielregeln von OSS-Projekten werden durch das Vorgehen der Cloud-Anbieter intensiver auf den Prüfstand gestellt und das Überleben von OSS-Unternehmen nachhaltiger gefährdet als durch die beschriebenen „vorsichtigen“ Lizenzänderungen. Jedenfalls ist derzeit nicht ersichtlich, dass Cloud-Anbieter tatsächlich ein vitales Interesse an (OSS-Datenbank-)Vorlieferanten haben, die sich nicht als rein altruistische OSS-Gemeinschaft (und damit „community-driven“), sondern auch als Unternehmen / „Wettbewerber“ positionieren.

Insbesondere Amazon macht vor, wie die Zukunft aussehen könnte: MongoDB wird in Form von Amazon DocumentDB auf Basis einer älteren Version geschmiedet, wobei fehlende DB-Features kurzfristig nachgebaut und in der unveränderten Endkundenbeziehung zur Verfügung gestellt werden.

Vor diesem Hintergrund erscheinen die aktuellen Lizenzanpassungen von Neo4j, die Teile der Software dem Zugriff der Cloud-Anbieter entziehen, als moderat. Unserer Meinung nach hat Neo4j den angemessensten, eindeutigsten und damit einfachsten Weg gewählt, um die Situation dem Nutzer zu vermitteln, dem wir bei Structr gerne folgen.