- Supabase hat die endgültige Übernahme des OrioleDB-Patents abgeschlossen
- Stellt allen Nutzern von OrioleDB eine nicht exklusive Lizenz für das US-Patent 10,325,030 (Durable multiversion B+-tree) zur Verfügung
- OrioleDB ist eine leistungsstarke Erweiterung, die die bestehende Storage Engine von Postgres ersetzt und Leistung sowie Skalierbarkeit in Cloud-Umgebungen deutlich verbessert
- Das Projekt wird weiterhin als Open Source entwickelt und zielt in Zusammenarbeit mit der Postgres-Community auf Standardisierung und die Aufnahme in den Kern ab
- Die Patentlizenz dient dem Schutz geistigen Eigentums (IP) und fungiert als „Schutzschild“ gegen Bedrohungen für Open Source
Freigabe des OrioleDB-Patents und Hintergrund der Übernahme
- Supabase hat kürzlich den vollständigen rechtlichen Übernahmeprozess von OrioleDB abgeschlossen
- Das Unternehmen hält nun sämtliche Rechte einschließlich des US-Patents 10,325,030 (Durable multiversion B+-tree)
- Ab sofort stellt Supabase dieses Patent für OrioleDB und alle Forks, einschließlich kommerzieller Services, allen Nutzern offiziell auf nicht exklusiver Basis zur Verfügung
- Diese Lizenzpolitik gilt im Rahmen der OrioleDB-Lizenz
Überblick über OrioleDB und seine Leistung
- OrioleDB ist eine Storage-Erweiterung, die das pluggbare Storage-System von Postgres nutzt
- Sie arbeitet als Drop-in-Ersatz für die bestehende Postgres-Storage-Engine
- Durch Optimierung für moderne Hardware und Cloud-Infrastruktur maximiert sie Leistung und Skalierbarkeit von Postgres
- Laut offiziellen Benchmarks erreicht sie etwa 5,5-fach höhere Leistung gegenüber der Heap-Engine (TPC-C, auf Basis von 500 Warehouses)
Entwicklungsrichtung des Projekts und Open-Source-Politik
- Supabase konzentriert sich gemeinsam mit dem OrioleDB-Team mit einer Postgres-first-Strategie auf die Entwicklung einer leistungsstarken Storage-Engine
- OrioleDB ist ein Open-Source-Projekt, zu dem jeder mit Code, Dokumentation, Tests, Issues usw. beitragen kann
- Ziel ist es, auf Basis der Table Access Method API von Postgres eine Drop-in-Storage-Engine fertigzustellen
- In Zusammenarbeit mit der Postgres-Community wird daran gearbeitet, OrioleDB als Erweiterungsmodul zu standardisieren und in den Mainline-Zweig aufzunehmen
Lizenz- und IP-Kompatibilitätspolitik
- Die OrioleDB-Lizenz basiert auf der PostgreSQL-Lizenz
- Supabase gewährt allen Nutzern von OrioleDB eine nicht exklusive Lizenz, damit sie das Patent (US 10,325,030) frei verwenden können
- Dieses Patent dient als „Schutzschild“ zur Abwehr feindseliger IP-Klagen, die Open Source bedrohen
Abgestimmte Weiterentwicklungsstrategie mit Postgres
- OrioleDB soll nicht mit Postgres selbst konkurrieren, sondern zielt darauf ab, Funktionalität und Leistung von Postgres zu verbessern
- Langfristig wäre die Aufnahme von OrioleDB in das offizielle Postgres-Repository die ideale Richtung
- Dafür arbeitet das Team kontinuierlich mit der Postgres-Community an Patches zur Erweiterbarkeit der Storage-Engine zusammen
- Verbesserungen bei Leistung und Stabilität, Validierung für Produktionsumgebungen, Dokumentation und Onboarding werden fortlaufend vorangetrieben
- Geteilt und gefördert werden Benchmarks, Migrationshinweise, Feedback aus realen Einsätzen, lebhafte Diskussionen in der technischen Community sowie das eigene Ausprobieren und Beiträge über Issues/PRs
1 Kommentare
Hacker-News-Kommentare
Nach einem schnellen Blick auf das Patent und den Code hatte ich den Eindruck, dass fast alles auf früheren Arbeiten beruht, die bereits von vielen Forschern geleistet wurden.
Etwas zu stehlen und dann zu sagen, man teile es mit guten Absichten, bleibt am Ende dennoch Diebstahl.
Nur weil das US-Patentamt einen Genehmigungsstempel auf ein Patent setzt, heißt das nicht, dass wirklich etwas Neues erfunden wurde.
Es bedeutet eher, dass man Verwaltungsmitarbeiter davon überzeugt hat, einem eine Grundlage zu geben, fremde Forschung als die eigene darzustellen.
Wenn man auf der richtigen Seite stehen will, sollte man dieses Patent aufgeben und sich bei der Forschungsgemeinschaft entschuldigen, deren Arbeit man sich aneignen wollte.
Mich würde interessieren, wie du zu diesem Schluss kommst.
Der Inhalt des Patenttexts muss größtenteils aus bekannten Dingen bestehen.
Entscheidend ist, ob die Patentansprüche neue Inhalte enthalten.
Die Patentbeschreibung muss so ausführlich sein, dass ein Fachmann sie reproduzieren kann; es reicht nicht aus, dass sich einzelne Schritte schon in früheren Papers finden lassen.
Wie detailliert Anwälte das ausformulieren, ist von Fall zu Fall unterschiedlich, und manchmal mussten sogar Dinge wie CPUs oder Programme sehr weitschweifig erklärt werden.
Um Kontroversen zu vermeiden, ist es besser, auch bekannte Techniken zu erwähnen, weil man sonst später wegen Kleinigkeiten vor Gericht landen kann.
Ich finde, das ist eine zu harte Bewertung von Supabase.
Forschung ist wichtig, aber dass es beim USPTO Konzepte wie „Reduction to Practice“ gibt, zeigt letztlich, dass alles auf früherer Forschung aufbaut.
Man sollte nicht übersehen, dass es ebenfalls neu sein kann, aus vorhandenen Bausteinen ein funktionierendes System zusammenzusetzen.
https://en.wikipedia.org/wiki/Reduction_to_practice
Zur Forderung „Schafft das Patent ab“: Was Supabase gerade anbietet, kommt dem in der Praxis fast gleich.
Jeder soll durch dieses Patent geschützt sein, wodurch die Abwehr gegen Patenttrolle oder IP-Klagen etwas einfacher werden könnte.
Ich verstehe diesen Kommentar nicht ganz.
Tatsächlich versucht Supabase, das Patent Open Source zugänglich zu machen, und arbeitet außerdem an Upstream-Beiträgen für Postgres.
Sie haben ein anderes Unternehmen übernommen, dadurch das Patent erhalten und geben nun sogar Geld für Anwälte aus, um es der Community zurückzugeben.
Wenn ein Unternehmen sich unredlich verhält, sollte es natürlich kritisiert werden, aber dieser Kommentar wirkt etwas so, als wolle man sich um jeden Preis empören.
Wenn jedes Mal, wenn Unternehmen mit einer Community interagieren wollen, solche Vorwürfe kommen, werden sie sich irgendwann gar nicht mehr beteiligen.
Auch wenn es einzelne Kritikpunkte geben mag, etwa bei Lizenzänderungen, sollte man sich über positive Schritte mitfreuen.
Solche Veränderungen kommen letztlich der gesamten Community zugute.
Im Blog stand Folgendes:
„Dieses Patent dient als Schutzschild gegen IP-Probleme, die Open Source feindlich gegenüberstehen.“
In der aktuellen Lizenz steht jedoch auch:
„Wenn ein lizenzierter Nutzer eine Klage gegen Supabase einreicht, endet die Lizenz ab diesem Zeitpunkt.“
Damit könnte man die Lizenz schon durch eher nebensächliche rechtliche Konflikte wie etwa eine Steuerklage verlieren.
Für staatliche Stellen könnte das problematisch sein; sinnvoller wäre wohl eine enger auf Patentfragen zugeschnittene Formulierung oder gleich eine OSI-zertifizierte Lizenz.
https://github.com/orioledb/orioledb/blob/main/LICENSE
(Supabase-CEO)
Ich werde das zusammen mit unserem Legal-Team noch einmal prüfen, damit es klarer formuliert ist.
Unsere Absicht ist eindeutig, und wenn es gute Beispiele oder Vorschläge gibt, verbessern wir das gern, notfalls auch bis hin zu einer unwiderruflichen Regelung.
Wenn die Community bereit ist, die laufenden Verwaltungskosten zu tragen, sind wir auch offen dafür, das Patent selbst zu spenden.
Die Apache-2.0-Lizenz ist bei Patentfragen besser.
Dort führt nur eine feindselige Patentklage zur Beendigung der Lizenz; Dinge wie Steuerfragen fallen nicht darunter.
https://opensource.org/license/apache-2-0
Das ist ein Schutzschild für Supabase, nicht für uns.
Ich frage mich, ob die aktuelle Lizenz auch freundliche Forks oder Redistribution erlaubt.
Zunächst heißt es, Nutzung, Kopieren, Änderung und Verbreitung seien frei erlaubt,
später steht dort aber auch, dass „eine Lizenz für das Patent gewährt wird“, und es ist unklar, ob das auch für veränderten und weiterverbreiteten Code gilt.
GPLv2 ist zum Beispiel eindeutig: Bei jeder Weiterverbreitung erhält man die Lizenz vom ursprünglichen Rechteinhaber.
Wenn man Open-Source-Code mit problematischen Klauseln versieht, müssen deren Auswirkungen für alle Nutzer klar sein.
Ich sehe darin kein großes Problem.
Wie sie selbst sagen, dient es als Schutzschild, und wenn man sie verklagt, sollte man meiner Meinung nach keinen Anspruch auf eine kostenlose Lizenz haben.
Dass ein Datenbankpatent Open Source gestellt wird, ist selten.
Ich frage mich, ob das andere Unternehmen dazu bringt zu erkennen, dass ein offenes Ökosystem schneller übernommen wird als geschlossene IP.
Abgesehen von einigen Sonderfällen ist es in der Regel schwer, wenn etwas nicht Open Source ist.
Supabase lizenziert das US-Patent von OrioleDB nicht exklusiv an alle Nutzer, einschließlich kommerzieller Forks.
Außerdem wurde OrioleDB vor etwa einer Stunde auf die Apache-2.0-Lizenz umgestellt.
https://github.com/orioledb/orioledb/commit/44bab2aa9879feb74bb1b6f056f7dba2d3ae5a90
Ich mag es überhaupt nicht, Patente auf Datenstrukturen anzumelden.
OrioleDB wurde schon vor der Übernahme entwickelt, und wir bemühen uns, eine so freie Open-Source-Lizenz wie möglich beizubehalten.
Softwarepatente sind wirklich eine sehr amerikanische Kultur.
In solchen Fällen erscheint mir ein Ansatz wie in China, wo das Patentrecht eher ignoriert wird, fast besser.
China geht generell anders mit geistigem Eigentum und Diebstahl um als entwickelte Länder.
In der Fertigungsindustrie wird IP eher ignoriert, aber sobald eine Branche selbst auf IP basiert, wird IP auch aktiv genutzt.
In den USA scheint in letzter Zeit eine Kultur stärker zu werden, die IP sehr betont — etwa die Vorstellung, Urheberrecht sei extrem wichtig oder LLMs müssten gestoppt werden.
So ein Ansatz tötet Innovation und lässt auch die Forschungsfinanzierung austrocknen.
Ich wusste gar nicht, dass man Dinge wie Datenstrukturen patentieren kann.
IP-Inhaber handeln oft nach dem Motto: „Patentiere alles, was patentierbar ist, und nutze den Rest als Druckmittel in Verhandlungen.“
Es geht nicht um die Datenstruktur an sich, sondern darum, dass ein neuer Algorithmus oder eine Verbesserung als „innovatives Verfahren“ anerkannt werden kann.
Wenn Gerichte einen Nutzenzuwachs oder technischen Fortschritt anerkennen, kann ein Verfahrenspatent tatsächlich Bestand haben.
Selbst gegen triviale Patente vorzugehen kann enorm viel Zeit und Geld kosten.
Ich bin weder Anwalt noch Richter, aber ich verfolge dieses Feld schon lange und habe diese Tendenz oft gesehen.
In den USA ist das möglich, außerhalb der USA aber oft schwierig.
Das hängt von der jeweiligen Rechtsordnung ab.
Europa erlaubt solche Patente bisher noch nicht, aber es wird weiterhin Lobbyarbeit dafür betrieben.
Es wird immer wieder Versuche geben, das doch durchzusetzen, und ich finde, diese Hartnäckigkeit, die bürgerliche Freiheiten aushöhlt, sollte rechtlich sanktioniert werden.
Ich habe wirklich große Erwartungen an OrioleDB.
Es wirkt wie der nächste Schritt, um Postgres so zu skalieren, dass es für alle Arten von Datenbanken geeignet ist, und ich schaue mir gerade selbst die Benchmarks an — die Ergebnisse sind sehr beeindruckend.
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
Danke, dass du dir die Benchmarks angesehen hast.
Wir werden bald RC-ready sein und peilen Dezember an.
Wenn du nicht nur am Code, sondern auch an Benchmarks und Stresstests mitarbeiten möchtest, wäre das eine große Hilfe.
Laut README und den Kommentaren scheint OrioleDB besonders bei schreiblastigen Workloads dank Techniken wie Anti-Bloat Vorteile zu haben.
Mich würde interessieren, ob die Leistung auch dann stark ist, wenn Text- oder JSONB-Felder groß sind und per TOAST verarbeitet werden.
Und gibt es vielleicht etwa 1 % an Workload-Typen, die ihr nicht empfehlen würdet, oder andere Nachteile?
https://github.com/orioledb/orioledb?tab=readme-ov-file#orioledb--a-cloud-native-storage-engine-for-postgresql
https://news.ycombinator.com/item?id=30462695
OrioleDB wirkt auf jeden Fall interessant, aber wenn sich die Speicherstruktur ändert, könnte die Kompatibilität mit anderen Erweiterungen problematisch werden.
pg_search (ParadeDB), Timescale und andere könnten betroffen sein; ein ähnlicher Fall war YugabyteDB, das RocksDB integriert hat und dadurch Schwierigkeiten bei der Zusammenarbeit mit PostgreSQL-Erweiterungen hatte.
Supabase liefert dem Postgres-Ökosystem kontinuierlich enormen Mehrwert.
Das ist keine Open-Source-Lizenz.
„Wenn der Lizenznehmer eine Klage gegen Supabase einreicht, endet die Lizenz sofort.“
Das ist eine toxische Klausel.
Im besten Fall ist die Lizenz nur naiv formuliert und hält sogar Supabase-Kunden von der Nutzung ab; im schlimmsten Fall ist es ein Versuch, Supabase unter dem Banner eines Community-Projekts Immunität zu verschaffen.
Wer wegen Verträgen, IP, Arbeitsverhältnissen oder anderen Themen klagt, verliert die Lizenz.
Selbst wenn man wegen Datenverlust klagt, könnte sofort mit einer Gegenklage wegen Lizenzverstoßes reagiert werden.
Erstaunlich ist auch, dass man sich dabei auf die Postgres-Lizenz beruft und dennoch so eine Klausel einbaut.
OrioleDB ist eindeutig ein vielversprechendes Projekt, aber unter dieser Lizenz ist es weder Open Source noch für viele überhaupt nutzbar.
Sam, du kennst mich vermutlich gut genug, um zu wissen, wie wichtig Open Source für unser Team ist.
Ich hätte das aktiver steuern müssen, das war mein Versäumnis.
Inzwischen wurde auf Apache 2.0 umgestellt, die Patentrechte werden dort klar eingeräumt, und beim Upstreaming des Codes kann er auch unter PostgreSQL neu lizenziert werden.
Den Blog werden wir ebenfalls anpassen.
https://github.com/orioledb/orioledb/pull/558
Früher hatte auch Facebook in der React-Lizenz eine ähnliche Klausel und hat sie erst nach langer Zeit entfernt.
Sie wirkt zwar ähnlich wie die Patentklausel in Apache 2, ist in Wirklichkeit aber nicht nur auf die Nutzung einer bestimmten Software begrenzt.
Ist das nicht einfach eine permissive Lizenz im Stil von Apache 2?