6 Punkte von GN⁺ 2024-03-29 | 3 Kommentare | Auf WhatsApp teilen
  • Am 21. März 2024 kündigte Redis Ltd. an, dass das Redis-„In-Memory Data Store“-Projekt ab Redis 7.4 unter einer nicht-freien, Source-available-Lizenz veröffentlicht wird
  • Diese Nachricht war unerquicklich, aber keineswegs völlig unerwartet; bemerkenswert ist vielmehr, dass es mehrere Optionen gibt, die als Redis-Alternative gewählt werden können
  • Nutzer, die weiterhin freie Software verwenden möchten, können unter mindestens vier Optionen wählen, darunter der bestehende Fork KeyDB und das neu angekündigte Valkey-Projekt der Linux Foundation

Eine kurze Geschichte von Redis

  • Redis wurde von Salvatore Sanfilippo (Spitzname „antirez“) als Projekt gestartet, um LLOOGG zu betreiben, eine Echtzeit-Loganalyse-Anwendung mit Anforderungen, die MySQL nicht erfüllte
  • Es wurde als einfache Wörterbuch-Datenbank statt als relationale Datenbank entworfen, und der Name ist die Abkürzung für „remote dictionary server“
  • Redis gewann als Teil der NoSQL-Bewegung schnell an Popularität, und 2010 wurde er von VMware für die Weiterentwicklung eingestellt
  • Redis wurde durch Kunden wie Twitter und Pinterest populär, begann in Linux-Distributionen aufgenommen zu werden und wurde 2013 dem AWS-Dienst ElastiCache hinzugefügt

Cloud gegen Open Source

  • Befürworter nutzungsbeschränkender Lizenzen wie der SSPL und der RSAL von Redis versuchen, dies nur als einen Kampf zwischen riesigen Cloud-Anbietern wie AWS und Open Source darzustellen
  • Ein Blick auf die Liste der Redis-Mitwirkenden zeigt jedoch, dass neben dem Redis-Unternehmen auch verschiedene andere Firmen Beiträge leisten

Änderung des Distributionsmodells

  • Redis ist ein venturefinanziertes Unternehmen und scheint kalkuliert zu haben, sich von Open Source zu entfernen, um mehr Umsatz zu erzielen
  • Das Beispiel MongoDB zeigt, dass das Unternehmen auch nach dem Wechsel zur SSPL weiter gewachsen ist und viele Firmen es bevorzugen, für die Nutzung zu zahlen, statt den Dienst selbst zu hosten

Forks und Alternativen

  • Nur wenige Tage nach der Lizenzänderung von Redis entstand mit Valkey ein direkter Fork; AWS, Google Cloud, Oracle, Ericsson und Snap unterstützen diese Bemühungen
  • KeyDB ist ein 2019 aus technischen Gründen entstandener Fork; nach der Übernahme durch Snap wurde die gesamte Codebasis unter der 3-clause-BSD-Lizenz vollständig Open Source
  • Drew DeVault, Gründer von SourceHut, schuf mit LGPLv3 einen Fork namens Redict
  • Garnet von Microsoft ist ein mit Redis kompatibler Remote-Cache-Store, der unter der MIT-Lizenz veröffentlicht wurde

Wettbewerb um Alternativen

  • Linux-Distributionen stehen vor dem Problem, Software als Ersatz für Redis finden zu müssen.
  • Communities wie Fedora, openSUSE und Debian ziehen KeyDB, Redict, Valkey und andere als Ersatz für Redis in Betracht.

Der Weg nach vorn

  • Es ist noch zu früh, um vorherzusagen, ob einer oder mehrere Forks nennenswerte Zugkraft gewinnen werden, aber Valkey dürfte mit hoher Wahrscheinlichkeit eine glaubwürdige Alternative werden

3 Kommentare

 
iolothebard 2024-03-30

Ursprünglich war Redis auch ein Ersatz für memcached.
Allerdings habe ich noch nie gesehen, dass ein Ersatz für eine bestimmte Technologie durch so eine Kampagne (?) entschieden wird.
Only time will tell.

 
GN⁺ 2024-03-29
Hacker-News-Kommentare
  • Die Redis Community Edition bleibt weiterhin kostenlos nutzbar, wird unterstützt, gepflegt und verbessert.

    • Entwickler müssen Redis in SaaS-Anwendungen und webbasierten Softwareprojekten nicht ersetzen.
    • Damit soll verhindert werden, dass AWS Redis als Service anbietet, ohne die Redis-Entwickler dafür zu vergüten.
  • Neal Gompa hat auf der Fedora-Entwickler-Mailingliste eine Diskussion über die Lizenzänderung angestoßen und darauf hingewiesen, dass Redis möglicherweise aus Fedora entfernt werden muss.

    • Gompa hat das Thema auch auf der Factory-Mailingliste von openSUSE angesprochen.
    • Nachdem Docker schrittweise ersetzt wurde, haben mehrere Distributionen Podman als Alternative zu Docker übernommen. Bei Redis scheint sich eine ähnliche Entwicklung abzuzeichnen.
  • Ich habe gerade erst erfahren, dass Binbin Wang, Committer von Apache Kvrocks (einer Flash-basierten Redis-Alternative), fast 25 % der Commits zur neuen Redis-Version beigetragen hat.

  • Der Grund, warum die AGPL-Lizenz zunehmend an Beliebtheit gewinnt, ist wohl, dass sich alle außer dem Rechteinhaber an sehr strenge Regeln halten müssen, die Kernsoftware aber Open Source bleibt und die Community weiterhin davon profitiert.

    • Insbesondere die BSD-Lizenz wirkt wie eine besonders schlechte Grundlage, um ein Geschäft zu betreiben.
  • AWS hat ElasticSearch zu dem DBaaS "OpenSearch" geforkt. Das führte in meinem früheren Job dazu, dass wir auf eine bestimmte Version der NEST-.NET-Bibliothek beschränkt waren und neue Funktionen nicht nutzen konnten. Angesichts des technischen Fortschritts scheint das in die falsche Richtung zu gehen.

  • Eine einfache Lösung für dieses und andere potenzielle Probleme ist es, die MIT-Lizenz zu verwenden und Einnahmen über Support zu erzielen.

  • Interessant ist, dass etwa 40 % der Commits zu Reddit von chinesischen Unternehmen stammen (Tencent 24,8 %, Alibaba 6,8 %, Huawei 5,2 %, Bytedance 2 %).

  • Zum jetzigen Zeitpunkt scheint ein urheberrechtlich restriktiveres Lizenzmodell vorteilhafter zu sein. Wenn es keine Garantie gibt, dass für alle zukünftigen Releases dieselbe Lizenz gilt, welchen Wert hat dann eine freiere und geschäftsfreundlichere Lizenz überhaupt? Das wirkt wie eine Lockvogel-und-Wechsel-Strategie.

  • Redis wirkt auf Entwickler wie ein trojanisches Pferd. Anfangs sieht es wie eine einfache Key-Value-Datenbank aus, man kann es aber auch als Cache verwenden, und alles zu cachen wirkt attraktiv. Das steht jedoch im Gegensatz zum alten Unix-Prinzip, dass jedes Programm eine Sache gut machen sollte. Nach zehn Jahren muss man dann Whitepaper zur Redis-Enterprise-Version herunterladen, um die richtigen Caching-Entscheidungen zu treffen.

    • Das basiert auf meiner Erfahrung in einem Projekt, in dem Redis auf unterschiedlichen Ports sowohl als Datenbank als auch als Cache verwendet wurde. Die meisten Entwicklungsteams lasen das Handbuch nicht, weil Redis als „einfach und funktioniert gut“ galt, und es traten viele Probleme auf. In Startups, die ums Überleben kämpfen, bleibt oft keine Zeit, das aufzuräumen.
  • Ich stimme Andrew Kelleys Sichtweise zu: Das Redis-Projekt sollte in Redict umbenannt werden, und das Projekt, das derzeit "Redis" heißt, sollte als seltsamer kommerzieller Fork von Redict betrachtet werden.