Quo Vadis Open-Source-Datenbanken?

Wie Open-Source-Lizenzmodelle zukünftig aussehen könnten.

In den zurückliegenden Monaten haben sich einige Open-Source-Software-Anbieter aus dem Datenbankbereich dazu entschieden, ihre bisherige Lizenzpolitik zu ändern und zum Teil neuartige, aber auch restriktivere Open-Source-Lizenzmodelle einzuführen.

In diesem Beitrag sollen die Hintergründe dieser Änderungen und die Handlungsoptionen der Beteiligten am Beispiel von MongoDB, Redis und Neo4j näher beleuchtet werden. Darüber hinaus wird diskutiert, inwiefern die vollzogenen Änderungen im Einklang mit den Prinzipien der Open-Source Bewegung stehen.

Lizenzmodelle

Die vorgenannten OSS-Datenbankanbieter MongoDB, Redis und Neo4j haben im Laufe des Jahres 2018 Lizenzänderungen von der AGPLv3 hin zu anderen Lizenzmodellen vollzogen. In der aktuellen Version gestalten sich diese nun wie folgt:

• MongoDB Community Server: Vollständiger Wechsel von AGPLv3 zu SSPL (Server Side Public License = eigene Variante der GPLv3) für alle Patch-Releases und Versionen ab dem 16.10.2018. Unklar und juristisch umstritten ist, ob es sich bei der SSPL, insofern sie eine Offenlegung der Zusatztools der Cloud-Anbieter als Lizenzbedingung erzwingt (Ziffer 13), noch um eine OSS-Lizenz handelt. MongoDB hat eine entsprechende Anfrage an die OSI gestellt.
• Neo4j Enterprise Edition: Zweistufiger Wechsel von AGPLv3 zu einem Open-Core-Modell. Zunächst Wechsel von AGPLv3 zur AGPLv3 mit Commons Clause. Letzteres ist eine kommerzielle Lizenz, die zunächst weiterhin parallel angeboten wurde (sog. „Dual licence“-Modell). Ab Neo4j 3.5 ist nicht mehr wie zuvor der gesamte Source-Code öffentlich. Alle Erweiterungen, die der Enterprise-Version zugerechnet werden, sind nicht mehr länger auf GitHub verfügbar. Konsequenterweise ist Neo4j 3.5 Enterprise auch nur noch als Binärversion unter einer kommerziellen Version erhältlich. Die Community Edition als funktionaler Kern ist weiterhin unter der GPLv3 verfügbar. Diese Kombination stellt das sog. „Open Core“-Modell mit Unterscheidung zwischen offenem Kern und nicht offengelegtem Source-Code für Erweiterungen dar.
• Redis Enterprise Add-ons: Wechsel für einige Enterprise-Add-ons, wie z.B. ReJSON, RediSearch und Redis Graph von APGLv3 zu einer Kombination aus Apache Licence 2.0 mit Commons Clause. Unter der Annahme, dass es sich bei der Commons Clause um eine nicht-Open-Source-konforme Lizenzbedingung handelt, ergibt sich auch hier ein Open Core-Modell in der Variante eines vollständig offen gelegten Source-Codes.

Auch wenn die OSS-Datenbankanbieter unterschiedliche Wege gegangen sind; das Problem, das sie zu lösen haben, ist das gleiche. Die OSS-Datenbankanbieter sehen sich und ihre kommerziellen Interessen zunehmend gefährdet durch sowohl die Verletzung eher impliziter, gabenökonomisch begründbarer Spielregeln als auch explizit vereinbarter Lizenzbedingungen innerhalb der Open-Source-Communities durch die zunehmende Zahl und Bedeutung der verschiedenen Cloud-Anbieter.

Rolle der Cloud-Anbieter

Nicht nur klassische Cloud-Anbieter, sondern auch zunehmend Anbieter von Serverless Computing wie Tencent, Alibaba oder Amazon, stellen OSS-Datenbanken als kommerziell ausgerichtete „As-a-Service“-Leistungen zur Verfügung. Dabei lassen sie die Datenbank selbst unverändert, um deren Lizenzbedingungen nicht zu verletzen.

Allerdings ergänzen sie diese beispielsweise um leistungsstarke eigene Verwaltungssoftware, Benutzeroberflächen und vereinfachte APIs. Dies reicht bis hin zur Bereitstellung von DB-Abstraktionsschichten, was mitunter einen erheblichen Mehrwert gegenüber der reinen Datenbank darstellt. Da diese Zusatzservices in der Regel ohne direkte Mehrkosten und eingebettet in weitere Angebote der Cloud-Anbieter verfügbar sind, werden sie gerne angenommen, selbst wenn die (kosten- und lizenzpflichtigen) Angebote des Datenbankherstellers umfangreicher und von besserer Qualität sind.

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

Die OSS-Datenbankhersteller werten somit einerseits das gesamte Dienstleistungsangebot der Cloud-Anbieter auf, werden andererseits jedoch sowohl als eigenständiges Produkt als auch hinsichtlich ihrer datenbankspezifischen, komplexen Features zunehmend ausgehöhlt - sie werden zum teilweise unsichtbaren, austauschbaren Vorprodukt. Infolgedessen werden Differenzierungen durch eigenständige Produktangebote mit anspruchsvollerem Funktionsumfang sowie spezialisierte und auf die Produkte abgestimmte Dienstleistungsangebote schwerer wahrnehmbar.

Gleichzeitig entfallen auch einzelne Kundenprobleme, die im Zusammenhang mit dem Einsatz von Datenbanken bisher häufig durch die OSS-DB-Anbieter selbst entgeltlich gelöst werden konnten. Selbst wenn die Original-Hersteller im Paket diese wesentlich höhere Komplexität umsetzen können (High Availability, Performance-Monitoring, Lastverteilung, Speicheroptimierung, Individualentwicklung, Troubleshooting, Skalierung etc.), sind die Cloud-Anbieter durch ihre Position in der Wertschöpfungskette, ihre Verbreitung, ihr Preisgefüge und ihre Marktmacht zunehmend im Vorteil und können sich als direkte Wettbewerber positionieren. Ganz zu schweigen davon, dass sie zunehmend auch eigene Produkte herausbringen und aggressiv vermarkten.

Gerade für kleine und mittlere Unternehmen stellt dies ein Problem dar: Ihre Dienstleistungen werden durch die gewaltigen Skalierungsmöglichkeiten der Cloud-Anbieter marginalisiert. Die großen Anbieter sind in der Lage, viele Funktionalitäten zu automatisieren und ohne Mehrkosten als Inklusivleistungen anzubieten. So verschwindet gegenleistungsfrei Monetarisierungspotential für kleine und mittlere Anbieter für Dienstleistungen im Cloud-Umfeld.

Ist alles verloren?

Nach Auffassung der Open-Source-Datenbankanbieter werden hier durch die Cloud-Anbieter grundlegende Regeln der Nutzung von OSS verletzt, ohne die das Open-Source-Universum nicht funktionieren kann. Fakt ist: Es findet seitens der Cloud-Anbieter kein Rückfluss oder Ausgleich an die (hier überwiegend als kleine oder mittlere Unternehmen auftretende) Hersteller-Gemeinschaft (sog. „Contribution“) in Form von Beiträgen zum Source-Code statt. Zusätzlich gibt es auch keine finanzielle Zuwendung bspw. in Form einer Umsatz- oder Marktbeteiligung an den durch die Cloud-Anbieter mittelbar oder unmittelbar mit den involvierten Datenbanken erzielten Umsätzen.

Vor einer solchen Verletzung der Spielregeln sahen sich die OSS-Datenbankanbieter durch die bisher verwendeten Lizenzmodelle nicht ausreichend geschützt. Diese sorgten weder dafür, dass die seitens der Cloud-Anbieter entwickelten Zusatztools dem Datenbankanbieter wieder in Form von offengelegten Source-Code zur Verfügung gestellt werden mussten, noch ließ sich diese Form der Kommerzialisierung durch die Cloud-Anbieter unterbinden.

Die AGPLv3 befasst sich zwar explizit mit der Bereitstellung von Software als SaaS / ASP / Hosting („…über ein Netzwerk mit ihm aus der Ferne agieren…“), geregelt wird hier aber lediglich, dass diese Formen der Bereitstellung ebenfalls einen Fall der Distribution von Software darstellen. Eine Aussage dazu, ob im Falle eines Einsatzes von Zusatztools durch Cloud-Anbieter zwingend immer eine „Copy-left“-relevante Verbindung der Zusatztools mit der Datenbanksoftware vorliegt (d.h. als ein abgeleitetes Werk bzw. als „modified version“), ist der AGPL nicht zu entnehmen und muss somit im Einzelfall schwierig nachgewiesen werden. Zudem würde wohl selbst das Vorliegen von „Copy-left“ wegen der absoluten Dominanz der Cloud-Anbieter in den Anschlussmärkten nicht zu der gewünschten Verlagerung von Marktanteilen zugunsten der Open-Source-Datenbankanbieter führen.

Es ist zu vermuten, dass Nutzer wohl weiterhin das Datenbankangebot der Cloud-Anbieter nutzen würden. Die annähernd alleinige Kommerzialisierung der Software durch die Cloud-Anbieter wäre also nicht verhindert.

Lösungsansätze?

Was also tun, um langfristig gegen die Cloud-Anbieter bestehen zu können? Die gewählten Lösungsvarianten der Datenbank-Anbieter unterscheiden sich voneinander, insbesondere im Umfang des von der Lizenzänderung betroffenen Source-Codes (von Teilen bis hin zum gesamten Source-Code) und des mit der Lizenzänderung verfolgten Ziels (Offenlegung des Source-Codes von DB-Zusatztools der Cloud-Anbieter bis hin zum umfassenden Verbot einer Kommerzialisierung).

Gemeinsam ist aber allen Varianten, dass das auszeichnende Merkmal „OSS“ als starker Markenbestandteil nicht aufgegeben werden und die Lizenzänderungen die OSS-Bewegung stärken sollen.

So zielt MongoDB, insbesondere mittels Ziffer 13 seiner SSPL (Server Side Public License), auf den Rückfluss („Contribution“) von Source-Code an die Community ab:

Alle Unternehmen, die MongoDB als Dienst anbieten, sind verpflichtet, diejenigen Zusatz-Tools, die zum Anbieten des Dienstes verwendet werden (Verwaltungssoftware, Benutzeroberflächen, Anwendungsprogrammschnittstellen, Automatisierungssoftware, Überwachungssoftware, Backup-Software, Speichersoftware und Hosting-Software), so zur Verfügung zu stellen, dass ein „Benutzer eine Instanz des Dienstes mit dem zur Verfügung gestellten Quellcode ausführen kann."

Dagegen will Redis die Kommerzialisierung durch die Cloud-Anbieter überhaupt verhindern: Redis verwendet für seine Enterprise Add-ons die sog. Commons Clause (i.V. mit Apache-Lizenz), die den Verkauf der betroffenen Add-ons durch Dritte dann explizit verbietet, wenn es sich um solche Produkte / Dienstleistungen des Dritten handelt, deren Wert sich eben ganz oder teilweise aus der Funktionalität der Software von Redis selbst ergibt. Mit Verkauf ist hier sowohl die Bereitstellung gegen Gebühr als auch gegen eine andere Gegenleistung gemeint („…einschließlich und ohne Einschränkungen Gebühren für Hosting…“).

Natürlich lassen sich für jede der vorgenommenen Lizenzänderungen Einwände hinsichtlich ihrer „OSS-Reinheit“ und einer Einhaltung der reinen Lehre vorbringen:

Stellt die SSPL von MongoDB tatsächlich einen Verstoß gegen „Freedom 0“ der Free Software Foundation (FSF) dar, weil sie möglicherweise eine Einschränkung der Ausführung der Software für einen bestimmten Zweck vorsieht?

Oder handelt es sich doch lediglich um eine Nebenbedingung zu ihrer Ausführung (so MongoDB und der Verfasser dieses Beitrages)?

Ist die Common Clause zu jedem Zeitpunkt und in jeder vorstellbaren Situation mit OSS-Grundsätzen unvereinbar? Muss immer der gesamte Source-Code eines Produktes veröffentlicht sein oder reicht hierfür der Software-Kern des Produktes aus?

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 aktuell offen.

Wichtiger erscheint aber, sofern die Diskussion nicht nur in akademischer Absicht geführt werden soll, bei der Bewertung der Lizenzänderungen und ihrer möglichen Anpassung an gabeökonomische Implikationen insbesondere folgenden Aspekt im Auge zu behalten:

Durch das Agieren der Cloud-Anbieter werden die Spielregeln von OSS-Projekten intensiver auf die Probe gestellt und das Überleben von OSS-Unternehmen nachhaltiger gefährdet, als durch die beschriebenen „vorsichtigen“ Lizenzänderungen. Derzeit ist jedenfalls nicht erkennbar, dass die Cloud-Anbieter tatsächlich ein vitales Interesse an (OSS-Datenbank-)Vorlieferanten haben, die sich nicht als rein altruistische OSS-Community (und damit „Community-driven“), sondern auch als Unternehmen / „Wettbewerber“ positionieren.

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

Im Hinblick hierauf scheinen die aktuellen Lizenzanpassungen von Neo4j moderat, die Teile der Software dem Zugriff der Cloud-Anbieter entziehen. Neo4j hat unserer Meinung nach einen angemessenen, eindeutigen und damit dem Nutzer angesichts der geschilderten Situation am leichtesten zu vermittelnden Weg gewählt, dem wir als Structr gerne folgen.