Von Open-Source- zu Source-Available-Lizenzen Datenbank Redis wechselt die Lizenz – was nun?

Anbieter zum Thema

WatchGuard Technologies GmbH

mibeca GmbH – Mike Bergmann Akademie

Da war und ist die Aufregung natürlich groß: Die vielleicht populärste (NoSQL-)Datenbank der Welt verabschiedet sich von ihrer permissiven Open-Source-Lizenz. Was für Folgen hat das für Redis-Nutzer?

Redis ist als schlanke NoSQL-Datenbank kaum noch wegzudenken. Tausende Anwendungen setzen auf die In-Memory-Datenbank, etwa Konzerne wie Airbnb, Amazon, Adobe, aber auch Open-Source-Projekte wie Checkmk. Mit der freigiebigen BSD-Lizenz war es völlig problemlos möglich, eigene Produkte mit Redis zu unterstützen oder auch Redis-Derivate für eigene Services zu verwenden.

Jetzt aber gibt es Redis nur noch unter der Redis Source Available License 2.0 (RSALV2) und der Server Side Public License (SSPL). In beiden Fällen handelt es sich um so genannte „Source-Available-Lizenzen“. Damit grenzen sich die Lizenzen klar von Open-Source-Lizenzen ab: Zwar ist der Quellcode verfügbar, aber die Anforderungen, die die Open Source Initiative (OSI) stellt, werden nicht erfüllt.

Die RSALV2 ist schnell abgehandelt, da es sich hier um eine Redis-exklusive Lizenz handelt, die zudem sehr kurzgehalten ist. Hier der eigentliche Lizenztext in der nicht-offiziellen Übersetzung: „Der Lizenzgeber gewährt Ihnen eine nicht-exklusive, gebührenfreie, weltweite, nicht unterlizenzierbare, nicht übertragbare Lizenz zur Nutzung, Vervielfältigung, Verteilung, Bereitstellung und Erstellung von Bearbeitungen der Software, jeweils vorbehaltlich der nachstehenden Einschränkungen und Bedingungen.“

Die erwähnten Einschränkungen regeln dann im Wesentlichen, dass die oben gewährten Rechte nicht dafür genutzt werden dürfen, um die Redis-Funktionalität selbst anzubieten. Oder anders ausgedrückt: Die RDALV2 erlaubt die Nutzung, Ableitung und Verteilung, stellt den Quellcode zur Verfügung und verbietet, mit Redis Ltd. in Konkurrenz zu treten. Genauer gesagt darf man die Funktionalität von Redis für Dritte nicht zugänglich machen, die Datenbank darf lediglich im Hintergrund laufen und Daten speichern. Direkte Interaktion zum Beispiel über ein API ist somit nicht gestattet.

Der Vorteil dieser Lizenz: Sie ist relativ kurz und einfach gehalten. Da es sich allerdings um eine Redis-exklusive Lizenz handelt, dürfte sie eher für zahlende Redis-Kunden relevant sein. Die große Mehrheit schielt wohl auf die SSPL.

SSPL und Affero GPL

In den Medien war der Aufschrei groß, als Redis den Lizenzwechsel bekanntmachte. Der Tenor: Redis verabschiede sich von Open Source. Schaut man sich die SSPL aber genauer an, kommt man ins Grübeln. Denn die SSPL ist im Wesentlichen eine AGPL – lediglich ein paar Namensnennungen sind unterschiedlich und der Paragraf 13.

Und Paragraf 13 hat schon bei der AGPL-Veröffentlichung Nutzer auf die Barrikaden gerufen. Das A hat die GPL um eine weitere Nuance des Copyleft-Prinzips erweitert. Die Copyleft-Basis: Wird Software mit GPL-Software verwoben und verteilt, fällt auch diese unter die GPL und der Quellcode muss veröffentlich werden. Genau dieser Punkt hat die Software-Industrie über Jahrzehnte gestört und zu dem wirren Krebsgeschwür-Vergleich von Steve Ballmer geführt.

Die Affero-Variante sollte dann der zunehmenden SaaS-Praxis gerecht werden, wo es nämlich ein Schlupfloch gab. Die GPL greift bei der Verteilung der Software – im Falle von SaaS wird aber nicht verteilt, sondern über das Netzwerk genutzt. Also ließ sich GPL-Software in einer Weise einsetzen, die die GPL-Macher so nicht mögen, um es mal sehr freundlich auszudrücken.

Die Free Software Foundation (FSF) und ihr Vordenker Richard Stallman haben bisweilen ein grundlegend anderes Verständnis: Wo die OSI gerne pragmatisch ist und permissive Lizenzen bevorzugt, die möglichst wenig Hindernisse für die Nutzung in den Weg legen, setzt die FSF auf restriktivere Lizenzen, die sicherstellen, dass die Quelloffenheit bestehen bleibt und sich bestenfalls auf weitere Software überträgt. Dass sich also Copyleft-lizenzierte Software in Web-Services einsetzen lässt, ohne dass die Nutzer ein Recht auf den Quellcode haben, entspricht also nicht dem Ansinnen der FSF.

Da kam die AGPL ins Spiel. Diese gewährt nun das Recht auf Quellcode schon dann, wenn die lizenzierte Software über das Netz genutzt wird. Wer also zum Beispiel einen Webmailer nutzt, der mit AGPL-Software umgesetzt wird, besitzt in dem Moment schon den Anspruch, den Quellcode zu bekommen. Wäre die Software GPL-lizenziert, bestünde dieser Anspruch nur, wenn diese auch distribuiert würde.

Die SSPL wurde von MongoDB ins Leben gerufen, ebenfalls eine vormals Open-Source-NoSQL-Datenbank. Einen direkten Vergleich von SSPL und AGPL hat MongoDB selbst in Form eines Diff-Dokuments veröffentlicht.

Der besagte Paragraf 13 wird hier fast komplett neu verfasst und massiv ausgeweitet. Der wichtige Begriff hier: „Service Source Code“. Zunächst mal geht es um Fälle, in denen ein Service angeboten wird, dessen Wert nur oder vor allem aus der Redis-Funktionalität besteht. Und in solchen Fällen muss der gesamte „Service Source Code“ verfügbar gemacht werden.

Gemeint sind damit „alle Programme, die Sie verwenden, um das Programm oder eine geänderte Version als Dienst zur Verfügung zu stellen, einschließlich, aber nicht beschränkt auf Verwaltungssoftware, Benutzerschnittstellen, Anwendungsprogrammschnittstellen, Automatisierungssoftware, Überwachungssoftware, Sicherungssoftware, Speichersoftware und Hosting-Software […].“ Letztlich geht es darum, „[…] dass ein Benutzer eine Instanz des Dienstes unter Verwendung des von Ihnen zur Verfügung gestellten Service-Quellcodes zur Verfügung stellen kann.“

Das ist schon eine sehr weitreichende und nicht wirklich präzise Formulierung. Gemeint ist im Grunde Folgendes: Wenn ein Managed-Service-Provider (MSP) die Nutzung von Redis anbietet, angereichert durch eine eigene grafische Nutzeroberfläche, eine Backup-Funktion und einen eigenen API-Layer, müsste dieser MSP den Quellcode zu all diesen Extras offenlegen.

Was nun?

Die drängende Frage ist in der Praxis wohl schlicht un einfach: Können wir unsere Software, die Redis als Datenbank nutzt, weiterhin so vertreiben? Und die Antwort ist ziemlich klar: Ja, das ist erlaubt – es sei denn, die damit unterfütterte Software bzw. der Dienst steht selbst in direkter Konkurrenz zu Redis.

Bezüglich Redis gibt es da rege Diskussionen und auch Nutzer, die sich selbst als Redis-Mitarbeiter und -mitarbeiterinnen zu erkennen geben, melden sich zu Wort, dass die reine Nutzung als Datenbank zum Beispiel in einem CRM-System kein Problem sei. Mehr Gewissheit bringt aber ein Auszug aus dem FAQ von MongoDB, hier wieder in der nicht offiziellen Übersetzung:

„Die Copyleft-Bedingung von Abschnitt 13 der SSPL gilt nur, wenn Sie die Funktionalität von MongoDB oder modifizierte Versionen von MongoDB Dritten als Dienst anbieten. Es gibt keine Copyleft-Bedingung für andere SaaS-Anwendungen, die MongoDB als Datenbank verwenden.“ Das ist nun die Aussage von MongoDB, aber als SSPL-Autoren sollten sie es ja wissen.

Nun könnte man fragen, warum die SSPL im Gegensatz zur AGPL nicht OSI-zertifiziert ist. OSI-Mitgründer Bruce Perens antwortet darauf in seinem Review mit „Abschnitt 13 in der neu vorgelegten Fassung entspricht offensichtlich nicht der OSD #9, weil er versucht, unverbundene Programme zu belasten.“ Und Punkt 9 der Open Source Definition (OSD) lautet: Die „Lizenz darf andere Software nicht einschränken.“

Die SSPL versucht quasi, das Copyleft auf alles auszuweiten, was auch nur annähernd im selben Rahmen läuft wie die lizenzierte Software selbst. Das originale Copyleft-Prinzip beschränkt sich auf Software, die tatsächlich Copyleft lizenzierten Code einbaut.

Die Intention von MongoDB und Redis ist zumindest auf den ersten Blick nachvollziehbar: Große MSPs sollen nicht mittels MongoDBs/Redis’ freiem Code direkt konkurrierende Dienstleistungen anbieten. Die SSPL ist aber ein Weg mit Tücken. Denn auch wenn Redis betont, weiterhin dem Open-Source-Gedanken verpflichtet zu sein: Es ist „[…] schwierig, sich als Open-Source-Unternehmen zu bezeichnen, wenn man eine Lizenz verwendet, die von der OSI nicht akzeptiert wird“, so Rai Dutt, Gründer von Grafana Labs über Grafanas Entscheidung pro AGPL und gegen die SSPL.

Aber wie es bei Open Source nun mal so ist: Mit Valkey gibt es einen Fork, betreut von der Linux Foundation.

(ID:50068153)