Redis führt duale Source-Available-Lizenzierung ein

 (redis.com)
2 Punkte von GN⁺ 2024-03-22 | 1 Kommentare | Auf WhatsApp teilen
  • Redis stellt ab Redis 7.4 die Auslieferung unter BSD 3-Clause ein und liefert Redis künftig unter RSALv2 oder SSPLv1 aus, womit sich die Lizenzgrenzen deutlich verschieben
  • Der Quellcode bleibt als Redis Community Edition weiterhin kostenlos verfügbar, aber die neuen Lizenzen entsprechen nicht der OSI-Definition von Open Source
  • Redis plant, Core und Stack zusammenzuführen und Suche, JSON, Vektoren, probabilistische Datenstrukturen und Zeitreihen-Datenmodelle in einem kostenlosen Paket zu bündeln
  • Interne und private Nutzung, Client-Bibliotheken, Integrationspartner und bestehende Redis-Enterprise-Kunden sind nicht betroffen, aber konkurrierende Managed Services dürfen den neuen Redis-Quellcode nicht kostenlos nutzen
  • Ab Redis 8 sollen die Funktionen von Redis Stack direkt in Redis enthalten sein; anschließend wird das Ende des Lebenszyklus separater Redis-Stack-Builds eingeleitet

Umfang der Redis-Lizenzänderung

  • Redis wird künftig alle neuen Redis-Versionen unter einer Source-Available-Lizenz veröffentlichen
  • Ab Redis 7.4 kann die Redis-Core-Software entweder unter der Redis Source Available License v2 oder der Server Side Public License v1 genutzt werden
  • Eine Auslieferung unter der BSD-3-Clause-Lizenz erfolgt nicht mehr
  • Der Redis-Quellcode bleibt über das Redis-GitHub-Repository als Redis Community Edition weiterhin kostenlos verfügbar
  • Sowohl RSALv2 als auch SSPLv1 sind keine von der OSI anerkannten Lizenzen und enthalten jeweils Nutzungseinschränkungen

Integration von Redis Stack und Änderungen am Produktaufbau

  • Künftige Source-Available-Releases führen Redis Core und Redis Stack zusammen
  • Integriert werden Suche, JSON, Vektoren, probabilistische Datenstrukturen und Zeitreihen-Datenmodelle
  • Alles wird als ein kostenloses Download-Paket bereitgestellt, und Redis kann damit eingesetzt werden als
    • hochperformanter Key-Value-Store
    • Dokumentenspeicher
    • Query Engine
    • latenzarme Vektordatenbank für generative KI-Anwendungen
  • Ab Redis 8 sollen neue Datentypen und Verarbeitungs-Engines, die im bisherigen Redis Stack unter RSALv2 oder SSPLv1 bereitgestellt wurden, standardmäßig enthalten sein
  • Nach der Bereitstellung von Redis 8 wird ein separater Redis-Stack-Build nicht mehr nötig sein, womit das Ende des Lebenszyklus von Redis Stack eingeleitet wird

Hintergrund der Änderung und Position von Redis

  • Redis erklärt, dass für die erweiterten Redis-Module in der Redis-Stack-Distribution bereits duale Lizenzierung verwendet wurde und seit Redis 6 mehr als 50 % der Downloads auf redis.io aus Redis Stack stammten
  • Die gleichzeitige Pflege mehrerer Distributionen stehe aus Sicht von Redis im Widerspruch zur künftigen Weiterentwicklung
    • Open-Source-Distribution
    • Source-Available-Distribution
    • kommerzielle Software, optimiert für On-Premises- und Cloud-Plattformen
  • Redis ist der Ansicht, dass große Cloud-Service-Provider die Investitionen von Redis und die Open-Source-Community kommerzialisieren
  • Mit der Änderung soll die kommerzielle Nutzung gesteuert werden, um weiter in funktionsreiche freie Software und Enterprise-Produkte investieren zu können
  • Durch diese Änderung ist Redis gemäß der OSI-Definition kein Open Source mehr

Auswirkungen auf Nutzer und Partner

  • Endnutzer, die bestehende Open-Source-Versionen von Redis oder neue dual lizenzierte Releases intern oder privat nutzen, sind nicht betroffen
  • Auch für Partner, die Client-Bibliotheken oder andere Integrationen für Redis entwickeln, ändert sich nichts
  • Alle von Redis verantworteten Redis-Client-Bibliotheken bleiben unter einer Open-Source-Lizenz
  • Bestehende Redis-Enterprise-Kunden sind nicht betroffen, da sie die Technologie über gesondert ausgehandelte Lizenzbedingungen erhalten
  • Integrations- und Managed-Service-Partner, die Redis Community Edition oder Enterprise in nicht konkurrierender Form nutzen, können über ihre Partnerschaft mit Redis weiterhin Lösungen entwickeln, betreiben und anbieten
  • Das Partner Program wird künftig exklusiven Zugang zu Redis-Technologie, Funktionen und Releases bieten

Einschränkungen für Cloud-Services und Konkurrenzprodukte

  • Unter den neuen Lizenzen dürfen Cloud-Service-Provider, die gehostete Redis-Dienste anbieten, den Redis-Quellcode nicht kostenlos nutzen
  • Beispielsweise kann ein Cloud-Service-Provider Redis 7.4 nur anbieten, wenn er sich zuvor mit Redis als Maintainer des Codes auf Lizenzbedingungen geeinigt hat
  • Als „konkurrierendes Angebot“ bezeichnet Redis ein Produkt, das aus der Redis-Codebasis abgeleitet ist, sich funktional stark mit den kommerziellen Redis-Produkten überschneidet und an Dritte verkauft wird
    • Dazu zählt auch der Verkauf über kostenpflichtige Supportverträge
    • Beispiele sind Lösungen, die Redis hosten oder einbetten und in Konkurrenz zu Redis Enterprise Software oder Redis Cloud vermarktet werden
  • Lösungen, die Redis nutzen, aber nicht konkret mit Redis selbst konkurrieren, sind davon nicht betroffen
  • Für Fragen zu konkreten Nutzungsszenarien verweist Redis auf redis_licensing@redis.com

Bedingungen von RSALv2 und SSPLv1

  • RSALv2 ist eine nicht-copyleftartige freizügige Lizenz, die das Recht einräumt, die Software zu nutzen, zu kopieren, zu verbreiten, bereitzustellen und abgeleitete Werke zu erstellen
  • RSALv2 hat zwei wesentliche Einschränkungen
    • Die Software darf nicht kommerzialisiert oder als Managed Service für andere bereitgestellt werden
    • Lizenz-, Copyright- und sonstige Hinweise dürfen nicht entfernt oder verdeckt werden
  • SSPLv1 basiert auf der AGPL und verlangt bei Bereitstellung als Service, dass der gesamte Quellcode des Dienstes unter der SSPL offengelegt wird
    • Dazu gehören Verwaltungssoftware, Benutzeroberflächen, API, Automatisierungssoftware, Monitoring, Backup, Storage und Hosting-Software
    • MongoDB ist Herausgeber dieser Lizenz
  • Modifizierte Versionen von unter SSPL lizenzierter Software dürfen nicht unter einer anderen Lizenz weiterverbreitet werden
  • Wer in der dualen Lizenzierung RSALv2 wählt, darf Änderungen und Weiterverbreitung vornehmen, solange die RSALv2-Beschränkungen eingehalten werden, etwa keine Bereitstellung der Funktionen als Dienst an Dritte

Bestehende BSD-Versionen und Sicherheits-Patches

  • Die Lizenzänderung gilt nicht rückwirkend
  • Sämtlicher Quellcode und alle Releases vor der Änderung bleiben unter der BSD-3-Clause-Lizenz
  • Nutzer können diese bestehenden BSD-Versionen unbegrenzt weiterverwenden, solange sie die Bedingungen dieser Lizenz einhalten
  • Redis plant, für die betreffenden Releases gemäß der aktuellen Sicherheitsrichtlinie weiterhin Sicherheitsupdates und kritische Fehlerbehebungen bereitzustellen, solange Redis Community Edition angeboten wird
  • Wichtige Security-Backports für bestehende BSD-3-Clause-Versionen werden bis vor dem Release von Redis Community Edition 9.0 bereitgestellt; danach erfolgen Patches unter der neuen dualen Lizenz

Bezeichnungen, Beiträge und Bedingungen für Code-Mischung

  • Redis 7.2 und frühere Releases heißen weiterhin Redis OSS
  • Ab Redis 7.4 wird die öffentlich und kostenlos bereitgestellte Version Redis Community Edition genannt
  • In Produktnamen dürfen „Redis“ oder „for Redis“ nicht mehr verwendet werden, in Produktbeschreibungen darf jedoch Redis-Kompatibilität oder eine Basis auf legacy-Redis angegeben werden
  • Beiträge aus der Community werden weiterhin angenommen, für die Prüfung von Beiträgen ist jedoch die Zustimmung zur Contributor License Agreement erforderlich
  • Code unter RSALv2 oder SSPLv1 kann zusammen mit Code unter anderen Lizenzen verwendet werden, sofern jede Komponente ihre eigene Lizenz behält und nicht mit starkem Copyleft-Code wie GPL vermischt wird
  • Das Hosten von Redis als Service innerhalb einer Organisation ist zulässig; zur Organisation zählen auch verbundene Unternehmen und Tochtergesellschaften

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-22
Meinungen auf Hacker News

  • Das dürfte Redis Labs mit hoher Wahrscheinlichkeit genauso beschädigen, wie Hashicorp unter Druck geraten ist und nach einem Käufer sucht, und es wird wohl auch niemanden davon abhalten, Redis Labs zu kopieren.
    Die wirklich Geschädigten sind kleine Startups, die einfach einen Redis-Cache ohne juristischen Ärger nutzen wollen. AWS kann Redis forken, und wenn sie diesen Fork sogar unter einer permissiven Lizenz veröffentlichen, könnte Redis Labs lizenzseitig zur schlechteren Wahl werden.
    Es ist eine schwierige Entscheidung, aber ich denke, es wäre besser, den Code entweder proprietär zu halten oder bei Apache oder MIT zu bleiben. Mitten im Spiel die Lizenz zu ändern, ist wirklich schlecht und wirkt wie etwas, das zwangsläufig nach hinten losgeht.
    Open Source bedeutet, dass Nutzer die Software besitzen können. Wenn man versucht, das mit juristischen Tricks zu umgehen, um Geld zu verdienen, trifft es nicht die Teams großer Unternehmen, sondern die Nutzer. Redis war immer ein permissives Open-Source-Projekt, und genau deshalb war es erfolgreich. Ändert man diese Bedingungen, ändert sich auch die Rechnung für die Zukunft, und das kündigt für alle Beteiligten schlechte Ergebnisse an.

    • Das scheint langfristig die Vorstellung, Unternehmen könnten gute Verwalter der Bedürfnisse von Open-Source-Nutzern sein, fast endgültig zu erledigen.
      Wir sollten den Unterschied zwischen Software im Besitz einer Stiftung, wie PostgreSQL, und Open Source im Besitz eines Unternehmens klarer sehen. Wenn der Fokus auf „Maximierung des Shareholder Value“ liegt, muss das Ziel, die Freiheit der Nutzer zu schützen, am Ende zwangsläufig in den Hintergrund treten.
      Für die Redis-Community wäre es viel besser gewesen, wenn Antirez Anstellung und Projekteigentum getrennt und Letzteres einer gemeinnützigen Organisation übergeben hätte. Etwas wie Apache Redis wäre für die Community besser gewesen, und Redis Labs hätte darum herum weiterhin proprietäre Erweiterungen und ein Cloud-Geschäft aufbauen können.
    • Mit der Zeit bin ich dieser Sichtweise zugeneigt und fasse es so zusammen: Wenn das Ziel Gewinn ist, sollte man das Kernprodukt nicht als Open Source veröffentlichen.
      Wir haben immer wieder gesehen, dass ein Unternehmen seine Kernsoftware unter einer permissiven Lizenz veröffentlicht und dann ein größerer Konkurrent kommt und eine Lösung verkauft, die genau diese Software weitervertreibt.
      Wenn das zentrale Ziel des Unternehmens Gewinn ist, ist das eine existenzielle Bedrohung. Wenn das Ziel des Unternehmens dagegen darin besteht, als gemeinnütziger Verwalter sicherzustellen, dass die Software weiter existiert, ist es ein großer Erfolg.
      Diese Logik gilt nicht für unterstützende Software, die nicht das Kernprodukt ist, etwa nützliche Tools, die während der Entwicklung entstanden sind, aber nicht direkt verkauft werden, um Geld zu verdienen.
    • Open Source hat ein Problem nach dem Motto: „Ihr implementiert es, wir verkaufen es, danke.“
      Diese Lizenzänderung zielt genau auf dieses Problem ab, nämlich darauf, Cloud-Hyperscaler am Trittbrettfahren zu hindern.
      Für mich klingt das wie eine bessere AGPL. Philosophische Nuancen oder die OSI-Liste genehmigter Lizenzen interessieren mich nicht; am Ende ist es deutlich weniger restriktiv als die AGPL. Es gibt Quellcode, ich kann es lokal ausführen, und ich kann es in meinem Projekt, in kommerziellen Projekten, bei der Arbeit, auf Bare Metal, in VMs, Docker, k8s und Azure auf die gleiche Weise nutzen.
      Dass Microsoft einen Teil der Prämie, die es ohnehin schon einnimmt, teilen muss, betrifft mich nicht. Im Gegenteil: Dass sie ein nachhaltiges Geschäftsmodell gefunden haben, verdient Applaus.
    • Die Aussage „Open Source ist Software-Eigentum der Nutzer“ ist falsch.
      OSS-Entwickler behalten das Urheberrecht. Abgesehen von Public Domain können nur die Autoren die Lizenz und Bedingungen ändern. Nutzer erhalten eine Lizenz, mit der sie verschiedene Dinge mit der Software und dem Code tun können; Eigentum erhalten sie nicht.
    • „Mit juristischen Tricks umgehen, um Geld zu verdienen“ erinnert mich an Enshittification.
      Ich stimme voll zu, und es fühlt sich an, als käme ein weiteres Beispiel zu Cory Doctorows Argumentation hinzu.

  • Inzwischen dürfte schon ein Fork in Arbeit sein. Es ist etwas traurig zu sehen, wie sich ein Unternehmen von seiner eigenen Entwickler-Community abkoppelt.
    Ich verstehe, warum sie das tun, aber ich glaube nicht, dass es langfristig funktioniert.
    Die meisten Redis-Nutzer haben dem Unternehmen dahinter nie auch nur einen Cent gezahlt, ich ebenfalls nicht. Ich verstehe, dass sie das tun, um Geld zu verdienen, aber mein Verhalten wird sich dadurch nicht ändern. Ich werde einfach den Fork nutzen. Das werden die meisten anderen Redis-Nutzer, externe Contributor und alle Cloud-Anbieter, die Redis kommerziell angeboten haben, ebenfalls tun; und mit der Zeit könnten auch ziemlich viele der heutigen Redis-Mitarbeiter dorthin wechseln.
    Da es viele kommerzielle Nutzer und Cloud-Anbieter gibt, wird es meiner Meinung nach nicht lange dauern, bis sie sich organisieren. Bei so vielen zahlenden Nutzern ist das im Grunde unvermeidlich.
    Ähnliche Präzedenzfälle gibt es bereits bei Terraform, Elasticsearch, Red Hat usw. Einen großen Teil der Zielnutzer und potenziellen Kunden dazu zu bringen, sich auf einen Open-Source-Fork zu verlassen, wirkt als Geschäftsstrategie wie der falsche Weg.
    Als Oracle Suns Open-Source-Projekte wie mysql, hudson, openoffice usw. übernahm, verlor es ebenfalls schnell den Großteil der Kontrolle. Der Versuch, die Leute zur Nutzung von Oracles geschlossenen Produkten zu bewegen, brachte wenig Erfolg. Sogar bei Java ist man am Ende ein Stück zurückgerudert; heute liegt der Schwerpunkt auf openjdk. Abgesehen von ein paar Banken nutzt kaum jemand Oracle JDK. Es gibt keinen Grund dazu, und Oracle hat schon vor langer Zeit aufgehört, so zu tun, als hätte es Vorteile. Die gesamte Entwicklung findet in OpenJDK statt, und es gibt mehrere Unternehmen, die zertifizierte Builds anbieten.
    Ich berate persönlich zu Elasticsearch und Opensearch, und die meisten meiner jüngeren Kunden nehmen Opensearch als Standard. Es hat sich einfach so entwickelt. Alle entscheiden sich für die kostenlose und Open-Source-Option.
    Es gibt nur eine Schlussfolgerung: Es wird einen Redis-Fork geben, den die große Mehrheit der heutigen Redis-Nutzer verwenden wird.

    • Microsoft hat vor drei Tagen einen nahezu Drop-in-Ersatz veröffentlicht[1]. Er soll mit den meisten Redis-Clients funktionieren. Zumindest für Azure-Nutzer dürfte das ziemlich viel verändern.
      [1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
    • Als langfristige Strategie könnte es aus einer Broadcom-Perspektive funktionieren: nicht darauf abzielen, viele Nutzer zu gewinnen, sondern auf wenige sehr teure Kunden, die ihre Systeme um das Produkt herum aufgebaut haben.
      Unternehmen könnten Preiserhöhungen hinnehmen, um nicht komplett migrieren zu müssen, oder zumindest kurzfristig während einer Migration.
      Um kurzfristige Abwanderung zu verhindern, könnte ein Anbieter auch „Zeit kaufen“, die Preise zunächst niedrig halten und sie dann erhöhen, wenn sich das Projekt weit genug vom Fork entfernt hat, dass ein Umstieg deutlich schwieriger geworden ist.
      So oder so lässt sich langfristig möglicherweise mit einigen wenigen Unternehmen viel Geld verdienen, statt weiterhin viele Firmen unterschiedlicher Größe zu unterstützen. Es gefällt mir nicht, aber es könnte funktionieren.
    • Es gibt bereits einen Fork in Arbeit: https://codeberg.org/redict/redict
    • Langfristig könnte FOSS als eine vorübergehende Mode der Branche gelten und sich nie wiederholen. Die Branche könnte sich wieder in Richtung Test- und Demoversionen einpendeln, bei denen der kostenlose Tier oder der Quellcode nicht den vollen Funktionsumfang bietet.
    • Zynisch betrachtet musste Oracle MySQL nicht auf Profit trimmen, weil es bereits eine viel teurere Alternative hatte.
      Schon das Spalten der MySQL-Community, das Eindämmen von Nutzung und externer Entwicklung sowie das Verlangsamen des gesamten Projekts könnten einen guten Return on Investment gebracht haben.

  • Ein großer Treiber dieser Projekte bleibt Hosting-Umsatz, und deshalb kommt es zu Lizenzänderungen.
    Schaut man sich den Trend an, scheint Open Source, das zu einem projektbesitzenden Unternehmen passt, nur bei Libraries zu funktionieren. Handelt es sich um Programme, etwa Server-Software wie Datenbanken, müssen sie wohl entweder source-available werden oder unter eine Foundation. Das ist schwierig, und ich weiß nicht, was die Antwort ist.
    Ich würde gern ein Modell sehen, das permissive Open-Source-Lizenzen auch für komplexe Programme zurückbringt, aber mir ist noch kein praktikabler Weg erkennbar. Vielleicht über Durchsetzung von Markenrechten, Open-Source-Code und ausschließlich lizenzierte Builds.
    So oder so werden wir weiterhin den Aufstieg und Fall populärer Open-Source-Software oder Lizenzänderungen sehen. Die Vorteile für Entwickler und Unternehmen, anfangs mit Open Source zu starten, sind zu groß, und der spätere Druck, etwas zu ändern, ist ebenfalls zu groß.
    Zumindest möchte ich anerkennen, dass Redis der Welt weit mehr Wert gegeben hat, als es ihr genommen hat. Der Unterschied ist wirklich überwältigend.
    Es wird interessant sein zu sehen, wie schnell ein Fork erscheint und erfolgreich wird, und wie die Umsatzwachstumskurve der Firma Redis in fünf Jahren aussieht.

    • Am Ende ist es doch wohl eine Struktur, in der die riesigen Cloud-Anbieter Firmen wie Redis das Mittagessen wegessen.
      Ich kenne mich mit den Lizenzen nicht gut aus, aber ich habe viel Verständnis dafür, dass kleine und mittelgroße Unternehmen, die Basistechnologien geschaffen haben, von oligopolistischen Cloud-Giganten zur Commodity gemacht und zu hohen Preisen weiterverkauft werden. Eher erstaunlich, dass es so lange gedauert hat.
      Wenn man davon ausgeht, dass sowohl Unternehmen als auch Open Source ein gesundes Ökosystem wollen, frage ich mich, welche Alternativen es zu Lizenzänderungen gibt.
    • Ich sehe Foundations nicht als magische Lösung für dieses Problem.
      Es gab viele Fälle, in denen ein einzelnes Unternehmen faktisch aus einer Foundation heraus „geforkt“ und sich abgespalten hat, und die Community stand am Ende vor demselben Ergebnis.
    • Mit „permissiver Open-Source-Lizenz für komplexe Programme“ ist so etwas wie AGPL3 gemeint?
      https://spdx.org/licenses/AGPL-3.0-or-later.html
    • Es würde helfen anzuerkennen, dass Entwickler sich nicht von anderen Berufsgruppen unterscheiden. Die Haltung, für die eigene Arbeit bezahlt werden zu wollen, aber den Leuten, die die Arbeitswerkzeuge bauen, keinen Cent zahlen zu wollen, ist nicht nachhaltig.
      Auch die Menschen, die Arbeitswerkzeuge bauen, müssen Rechnungen bezahlen.
      In gewisser Weise tragen Entwickler selbst Mitverantwortung dafür, dass der FOSS-Traum gescheitert ist.
      Wir bewegen uns langsam zurück in die Zeiten von Public Domain und Shareware.
    • „Nur lizenzierte Builds von Open-Source-Code anbieten“ ist kein Open Source.

  • Es wurde immer gesagt, das Modell, mit Open Source Geld zu verdienen, seien Support-Dienstleistungen. Wenn ein Unternehmen zum Beispiel Postgres nutzt, helfen Expert:innen bei einer On-Premises-Konfiguration und beheben Ausfälle.
    Im Zeitalter der „Cloud“ nutzen Unternehmen jedoch einfach Managed Services von Amazon, Microsoft, Google usw., und die finanziellen Chancen für Projekt-Maintainer und das Umfeld verschwinden faktisch. Niemand will sehen, wie er sich für OSS abrackert, während AWS Millionen Dollar verdient, ohne etwas zurückzugeben.

    • Offenlegung: Ich arbeite bei Amazon, bin aber nicht direkt an Redis-bezogenen Cloud-Services beteiligt. Ich stehe dem Open Source Program Office nahe und schätze die Menschen sehr, die die harte Arbeit leisten, die für die Zusammenarbeit in Open-Source-Projekten nötig ist.
      Madelyn Olson hat über Jahre hinweg, während sie bei AWS angestellt war, harte Arbeit geleistet, das Vertrauen anderer Redis-Core-Entwickler gewonnen und wurde Core-Maintainerin. Sie und andere AWS-Entwickler haben viel zur Redis-Core-Engine beigetragen. Man kann also sagen, dass auch sie hart für die Redis-Community gearbeitet haben.
      Mehr zu den entsprechenden Beiträgen kann man hier lesen: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

  • Mehr Open-Source-Projekte sollten SSPL übernehmen oder mit Modellen experimentieren, die wie Llama 2 die Unternehmensgröße für die kostenlose Nutzung begrenzen. Also etwa Open Source, aber nicht für milliardenschwere Cloud-Hyperscaler.
    Als einzelne:r Entwickler:in habe ich nicht beigetragen, um AWS das Trittbrettfahren zu ermöglichen.
    Der Hauptgrund, warum Projekte zu restriktiveren Lizenzen gedrängt werden, ist AWS. Das Richtige für AWS wäre gewesen, die Arbeit der ursprünglichen Autor:innen oder Unternehmen zu respektieren und den von den ursprünglichen Entwickler:innen unterstützten Produkten den Rücken zu stärken. Stattdessen baut AWS Konkurrenzprodukte, sobald es sieht, dass ein OSS-Produkt erfolgreich ist. Wegen engerer Integration und Marketingmacht haben Drittanbieter keine Chance.
    Hinzu kommt, dass Amazon und AWS große, vielleicht die größten Nutznießer von Open Source sind und dennoch kaum etwas zurückgeben. Google, Microsoft und sogar Oracle tragen mehr zu Open Source bei als Amazon.

    • SSPL und AGPL sind in Ordnung, aber nur unter der Bedingung, dass es keine CLA gibt, die mich dazu zwingt, meine Rechte an andere abzutreten.
      Zu Projekten mit CLA habe ich nie beigetragen und werde das auch künftig nicht tun, sofern mich mein Arbeitgeber nicht dafür bezahlt.
    • Ich habe früher einmal für eine FOSS-Lizenz plädiert, die verhindert, dass KI Code schreibt. Darauf gab es viel negative Reaktion, weil sie Einschränkungen auferlegt und damit nicht FOSS sei. Bei der SSPL ist es genauso.
      Für die langfristige Überlebensfähigkeit von FOSS könnten jedoch Einschränkungen nötig sein, um uns vor Großkonzernen zu schützen, die FOSS-Entwickler:innen faktisch ausbeuten.
    • Man darf auch nicht vergessen, dass AWS einer der Hauptgründe dafür ist, dass viele OSS-Projekte populär geworden sind.
      Redis, Mongo, ES, die HashiCorp-Produktpalette und das gesamte Big-Data-Ökosystem wurden durch das Angebot von AWS bekannter. Es gibt auch viele wenig bekannte Datenbanken, die über Jahre entwickelt wurden und die bis heute kaum jemand kennt, weil AWS oder andere große Cloud-Anbieter sie nicht gepusht haben.
      Außerdem erhalten viele Projekte dank freizügiger Lizenzen durch wachsende Nutzung und Popularität Beiträge wie Bug Reports, PRs und Patches. Zu Dingen mit SSPL-, BSL-ähnlichen Lizenzen möchte ich kaum beitragen, weil ich keine Zeit in etwas verschwenden will, das ich später nicht frei nutzen kann.
    • Es wird vergessen, dass Redis gerade deshalb groß geworden ist, weil es kostenlos und offen war.
      Wäre Redis von Anfang an mit ähnlichen Einschränkungen wie Llama 2 erschienen, wäre es gescheitert. Die Hauptnutzer sind Unternehmen, und der Hauptgrund für die Popularität von Llama 2 war, dass es früh ein hochwertiges LLM bot, das Einzelpersonen für private Zwecke nutzen konnten.
      Ein RESP-kompatibler Key-Value-Store ist nichts besonders Außergewöhnliches. Microsoft hat gerade mit garnet eine eigene Implementierung unter MIT-Lizenz veröffentlicht. Der Wert von Redis lag immer darin, kostenlos und Open Source zu sein, sowie in der Community, die das getragen hat. Jetzt hat Redis den wichtigsten Grund aufgegeben, es zu verwenden.
    • AWS unterstützt in manchen Fällen auch die ursprünglichen Entwickler. Bei Managed Grafana und Prometheus arbeitet AWS mit Grafana Labs zusammen.
      Aber das ist praktisch der einzige Fall, den ich kenne; bei fast allen anderen Fällen wie MongoDB, Redis, Memcached, MySQL, PgSQL usw. ist es nicht so.

  • Redis Inc. verschiebt das Projekt https://github.com/redis/redis/ von der 3-Klausel-BSD-Lizenz auf eine Doppellizenz aus zwei nicht von der OSI genehmigten Lizenzen.
    Zuvor hieß es einmal: „Redis core license ist unter der 3-Clause-BSD lizenziert und wird es auch immer bleiben.“ (https://redis.com/blog/redis-labs-modules-license-changes/)

    • Das ist das Ergebnis davon, dass MBA-CEOs Unternehmen übernehmen, die Open-Source-Projekte nicht entwickelt, sondern nur übernommen haben

  • Falls Sie sich Sorgen um das Support-Ende machen: Redis 7.4 wird das erste Release unter der neuen Lizenz sein, und 7.2 das letzte Release unter der alten Lizenz.
    Redis unterstützt zu einem bestimmten Zeitpunkt zwei zusätzliche Releases: latest major.(minor-1), (major-1).(last-minor)
    Grob bedeutet das: Wenn 8.0 erscheint, endet der Support für 6.2; und wenn 7.6 oder 8.0 erscheint, endet der Support für 7.2.
    Mit Blick auf frühere Releases ist 8.0 etwa im März bis Mai 2025 zu erwarten. Wer also unter der 3BSD-Lizenz von Redis abhängig ist, sollte entsprechend planen.
    Ubuntu paketiert redis im universe-Repository, daher sind Sicherheits-Upgrades nur für Ubuntu-Pro-Kunden verfügbar. Für Ubuntu 20.04 enden redis-Upgrades damit im April 2024, außer für ESM-Nutzer von Ubuntu Pro.
    Debian 11/12 folgen Redis 6.0/7.0 und sind daher dafür verantwortlich, Patches aus 7.2 zurückzuportieren. Falls 7.2 keine Sicherheitsupdates mehr erhält und diese nur noch im 7.4-Branch bereitgestellt werden, ist unklar, wie das laufen wird.
    Selbst wenn die eigene direkte Nutzung mit der neuen Lizenz vereinbar ist, kann man indirekt betroffen sein. Da Distributionen redis in kommenden Releases wahrscheinlich aus ihren offiziellen Repositories entfernen werden, sollte man das im nächsten Distributions-Upgrade-Zyklus berücksichtigen.
    (Ich pflege https://endoflife.date/redis; wenn jemand genau weiß, welche Auswirkungen es auf Support-Ende und Support gibt, kann ich PRs mergen.)

  • Die neue Lizenz SSPL ist zumindest wegen der Einschränkung des Einsatzbereichs sehr wahrscheinlich keine Open Source: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

    • SSPL ist definitiv keine Open Source und verstößt gegen Punkt 6.
      https://opensource.org/definition-annotated#6
      Genau das ist der Kern von Open Source und in gewisser Hinsicht auch von freier Software. Copyleft-Lizenzen haben Einschränkungen, aber wenn man diese Einschränkungen einhält, kann man mit der Software bauen, was man will. SSPL-, FSL- und BUSL-Lizenzen verhindern bestimmte kommerzielle Formen des Wettbewerbs vollständig.
      Nur weil die meisten Geschäftsmodelle Copyleft nicht einhalten wollen, heißt das nicht, dass es keine Open Source ist. Es passt nur nicht zu diesem Geschäftsmodell.
    • Nicht „wahrscheinlich“, sondern schlicht und eindeutig eine unfreie Lizenz.
    • Ich denke, für solche Dinge brauchen wir einen neuen Begriff.
      Neue Lizenzen wie SSPL, BSL und FSL werden immer beliebter, und das aus nachvollziehbaren Gründen. Vor 20 Jahren gab es keine Situation, in der AWS FOSS weltweit weiterverkaufte; die Rahmenbedingungen waren also ganz andere als heute.
      Wegen der Einschränkungen ist es keine „Open Source“, aber der nächstliegende Begriff „source-available“ bildet die Realität ebenfalls schlecht ab. Das klingt eher danach, dass der Quellcode technisch gesehen irgendwo herumliegt.
      ElasticSearch, Sentry usw. werden weiterhin öffentlich entwickelt, auch Personen ohne Bezug zum Projekt können PRs einreichen, und solange man nicht öffentlich mit dem Unternehmen hinter dem Projekt konkurrieren will, kann jeder damit machen, was er möchte.

  • Gleichzeitig hat Microsoft Garnet veröffentlicht: https://github.com/microsoft/garnet
    Gutes Timing.

    • In der HN-Diskussion zu Garnet sagte jemand, er werde sich niemals mit MS einlassen.
      Die Logik war, dass MS erst den Köder auslegen und dann bei Bedarf die Lizenz ändern würde, weshalb Redis, das immer eine Open-Source-Lizenz behalten werde, besser sei. Eine großartige Prognose.
    • Microsoft und Azure scheinen diese Änderung vollständig zu unterstützen: https://azure.microsoft.com/en-us/blog/redis-license-update-...
    • Ich frage mich, ob das ein Forschungsprodukt ist oder für Produktionsumgebungen gedacht ist.
    • Ich verstehe nicht, warum man eine so wichtige Software in einer Sprache wie C# oder Java schreibt, die die Installation einer ganzen Runtime und VM erfordert.

  • Die technischen Gründer von Redis und Hashicorp sind jeweils zurückgetreten, bevor ihre Unternehmen sich von FOSS entfernten und in einen großen Sturm gerieten. Zumindest, wenn die Zeitachse stimmt.
    Ich frage mich, ob sie davon im Voraus wussten und dagegen waren, oder ob sie es wussten, aber den Reputationsschaden vermeiden wollten. Ob man diesen Schritt gutheißt oder nicht, Reputationsschaden gibt es. Oder konnten die Änderungen erst durchgesetzt werden, weil sie gegangen waren?
    Reine Spekulation, aber es fällt auf, dass sich bei Redis anscheinend wiederholt, was wir bei Hashi gesehen haben.

    • Vielleicht hatten sie vor ihrem Weggang genug Einfluss, um es zu verhindern.
      Die Ähnlichkeit zu Hashi ist auch mir nicht entgangen.
    • Plausibler ist vielleicht einfach, dass sie das Projekt oder Unternehmen schon ziemlich lange geführt hatten und zu etwas Neuem, Interessanterem wechseln wollten. Oder vielleicht wollten sie einfach Kasse machen.