Liquibase wirbt auch nach der Lizenzänderung weiter als „Open Source“

 (github.com/liquibase)
1 Punkte von GN⁺ 2025-10-17 | 1 Kommentare | Auf WhatsApp teilen
  • Liquibase ist von seiner bisherigen Open-Source-Lizenz auf die Functional Source License (FSL) umgestiegen
  • Obwohl FSL nach den Maßstäben der Open Source Initiative (OSI) keine offiziell anerkannte Open-Source-Lizenz ist, wird das Projekt in README-Dateien und anderen Stellen weiterhin als Open Source vorgestellt, was kritisiert wird
  • In der Community gibt es gegensätzliche Ansichten: Einige meinen, FSL verstoße gegen die offiziellen Open-Source-Kriterien, andere halten sie für mit den Open-Source-Anforderungen vereinbar
  • Im Projekt laufen Korrekturen an der README, um die Open-Source-Bezüge anzupassen
  • Kritisiert wird, dass FSL wegen Klauseln wie der Einschränkung konkurrierender Nutzung mit Teilen der OSI Open Source Definition kollidiere

Überblick über das Problem

  • Die Lizenz des Liquibase-Projekts wurde kürzlich auf die Functional Source License (FSL) umgestellt
  • Gleichzeitig wird Liquibase in offiziellen Dokumenten wie README.md weiterhin als Open-Source-Projekt beschrieben, was in der Community für Verwirrung und Meinungsverschiedenheiten sorgt

Meldung und Kontroverse

  • Der Ersteller des Issues kritisiert, dass Liquibase trotz der Umstellung auf FSL weiterhin ausdrücklich als Open Source bezeichnet wird
  • Liquibase selbst habe bereits erwähnt, dass FSL keine Open-Source-Lizenz sei
  • Gefordert wird, dass der Begriff Open Source in der Projektdokumentation nicht länger verwendet wird, einschließlich Änderungen an README und weiteren Dokumenten

Meinungen aus Community und Umfeld

  • Einige Beteiligte argumentieren, FSL erfülle die Kriterien einer von der OSI genehmigten Open-Source-Lizenz; problematisch sei es erst dann nicht mehr, wenn sie nach formaler Prüfung tatsächlich OSI-anerkannt würde
  • Andere betonen dagegen, dass FSL wegen Formulierungen wie dem Abschnitt zum „permitted purpose“ gegen mehrere Punkte der OSI Open Source Definition (1, 3, 5 und 6) verstößt
  • Es gibt auch Stimmen, die die Unterscheidung zwischen „Fair Source“ und „echtem Open Source“ hervorheben und FSL als Fair Source einordnen wollen

Lösungsprozess und Dokumentationsänderungen

  • Ein Mitwirkender des Projekts reagierte auf die Kritik, indem er README.md anpasste und Open-Source-Erwähnungen schrittweise entfernt
  • Allerdings finden sich im Repository weiterhin einzelne Formulierungen wie open source oder oss, sodass weitere Prüfung und Bereinigung vorgesehen sind

Open-Source-Definition und das Problem mit FSL

  • Vertreter der Open-Source-Community wie Richard Fontana machen deutlich, dass FSL wegen Klauseln wie dem Verbot konkurrierender Nutzung gegen die OSI Open Source Definition verstößt
  • Die Open Source Definition enthält unter anderem Regeln wie das Verbot der Diskriminierung von Personen, Gruppen und Einsatzbereichen, denen Nutzungsbeschränkungen für konkurrierende Zwecke widersprechen
  • FSL soll nach zwei Jahren in die MIT License oder die Apache License übergehen und damit vollständig Open Source werden, bis dahin bleiben jedoch einschränkende Bedingungen bestehen

Fazit und aktueller Stand

  • Das Issue hat im Zuge der Korrektur der Open-Source-Kennzeichnung von Liquibase eine Debatte über Transparenz in der Community und über das Wesen von Open Source angestoßen
  • Die Überarbeitung offizieller Dokumente wie der README hat begonnen, und die Abgrenzung zwischen Fair Source und Open Source wird an einem praktischen Beispiel diskutiert
  • Unabhängig von einer möglichen OSI-Zulassung haben die tatsächlichen Lizenzbedingungen in der internationalen Open-Source-Community erhebliches Gewicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-17
Hacker-News-Kommentare

  • Wir haben angefangen, nach Alternativen zu suchen, falls wir die 4.x-Versionen künftig nicht mehr nutzen können.
    Ich kann verstehen, wenn jemand mit nützlicher Software Geld verdienen will und daher von einer OSS-Lizenz zu einem kostenpflichtigen Modell wechselt.
    Aber bei Open Source nachträglich die Lizenz zu ändern, wirkt auf mich wie eine Art Lockvogel-und-Wechsel-Taktik.
    Solche Entscheidungen zerstören sofort Vertrauen und kosten auch eine Nutzerbasis, die sich kurzfristig schwer monetarisieren lässt, langfristig aber Potenzial hätte.
    Ich hätte erwartet, dass man aus den Fällen Elastic und Terraform bereits wichtige Lehren gezogen hat.
    Auch Flyway könnte jederzeit einen ähnlichen Weg einschlagen, was das Vertrauen ebenfalls schmälert.
    Falls kein Fork entsteht, ziehen wir sogar in Betracht, für unseren realen Einsatzfall selbst eine passende Migration-Bibliothek zu bauen.
    Wir nutzen Liquibase nur, weil es praktisch ist, nicht weil es unersetzlich wäre.

    • Ich finde, auch EventStoreDB (heute KurrentDB) und NATS stehen in Bezug auf Service-Verlässlichkeit unter Verdacht.
      EventStoreDB hat die Lizenz bereits geändert, und NATS hat die Pläne nur wegen Gegenreaktionen der Nutzer aufgegeben.
      Inzwischen wirkt dieses Vorgehen fast wie eine Art Geschäftsstrategie.

    • Der größte Vorteil von Open Source ist, dass man frühere Versionen jederzeit forken und weiterverwenden kann.
      Ich sehe diese Umstellung im Kern nicht als etwas anderes als eine Preiserhöhung des Produkts.

    • Nur für Postgres, aber es gibt auch das Projekt pgroll, das die Automatisierung noch einen Schritt weiter bringt.

    • Neben Flyway (Apache-Lizenz) gibt es mit Atlas (Apache) und Sqitch (MIT) noch genügend Lizenzen beziehungsweise Projekte, die weiterhin Open Source sind.

    • Ich frage mich, ob die Lizenzänderung von Elastic aus deren Sicht wirklich ein Fehlschlag war.
      Der Aktienkurs ist eine Zeit lang gefallen, aber das Unternehmen selbst ist nach wie vor kerngesund.
      Alle Entwickler, die ich aus dem Such- und RAG-Bereich kenne, nutzen weiterhin ausschließlich Elasticsearch von Elastic NV (keine Open-Source-Forks oder Alternativen).
      Gerade bei der für Elastic wichtigsten Kundengruppe, also den zahlenden Kunden, scheint es eher keinen Vertrauensverlust, sondern sogar einen gegenteiligen Effekt gegeben zu haben.
      Auch der tatsächliche Umsatz hat sich gegenüber 2020 verdoppelt.

  • Manche behaupten noch immer, es sei Open Source, aber Liquibase selbst erklärt ausdrücklich, dass FSL keine Open-Source-Lizenz ist.
    Siehe die offizielle Ankündigung im Liquibase-Blog

    • Da diese Änderung noch keine vollen vier Wochen alt ist, wurde sie vielleicht im README noch nicht sauber nachgezogen.
      Schade ist, dass es zuletzt viele Projekte gibt, die nur noch den Quellcode offenlegen und sich dabei dennoch als Open Source vermarkten.

  • Wenn Liquibase statt starkem Copyleft (zum Beispiel GNU AGPL) Apache gewählt hat, dann hätte man natürlich damit rechnen müssen, dass andere geschlossene Derivate daraus bauen.
    Letztlich ist das eine Entscheidung, die Liquibase selbst getroffen hat, und deshalb liegt die Verantwortung dafür auch bei Liquibase.

    • Es sieht so aus, als würde nach einer gewissen Zeit automatisch auf Apache umgestellt.
      Ob das besser ist oder nicht, weiß ich nicht.

    • Unternehmen können ihre Ziele durchaus auch mit Lizenzen wie AGPL erreichen.
      Redis hat ebenfalls umgestellt, und die Reaktion der Community war positiv.
      Ich glaube nicht, dass Nutzer sich beschweren würden, wenn Liquibase ein AGPL-Dual-Licensing wählen würde.

  • Man sollte es wohl „Open Source mit 2 Jahren Verzögerung“ oder „in 2 Jahren Open Source“ nennen.
    Für mich ist es in Wahrheit eher „Open Source, wenn es nicht mehr nützlich ist“.
    Im Kern vermittelt so etwas nur das Image, echte Freiheit zu respektieren, ohne es tatsächlich zu tun.

    • Dass alte Versionen so schnell nutzlos werden, ist eher selten.
      Ich sehe darin keinen Mangel an Respekt gegenüber meiner Freiheit.
      Das Ziel ist, Unternehmen (nicht Menschen) gewisse Einschränkungen aufzuerlegen.

    • Im Enterprise-Bereich ist das Wesentliche an Open Source meiner Meinung nach weniger „Freiheit“ als vielmehr Vertrauen und Transparenz.
      Schon eine Quelloffenlegung reicht aus, um die Vorteile von FOSS zu nutzen, ohne rechtliche oder Monetarisierungsprobleme auszulösen.
      Online zeigt sich oft eine übertriebene, fast blinde Gläubigkeit gegenüber dem Open-Source-Modell.
      Auch eine gemischte 2-Jahres-Regelung halte ich für durchaus vernünftig; wer die neue Lizenz nicht will, kann einfach die alte Version verwenden.

    • Verzögertes Open Source, mit einer Doppeldeutigkeit wie beim englischen „late“.

    • #source-washing

  • Falls dir die neue Lizenz nicht vertraut ist, siehe Erklärung zu FSL

    • Mehr Kontext zu FSL: Die Lizenz wurde von Sentry entwickelt; warum sie nötig war und welches Problem sie lösen sollte, lässt sich im Sentry-Blog nachlesen

    • Persönlich wäre die einzige proprietäre Lizenz, die ich noch akzeptabel fände, BuSL, die „Business Source License“.
      Nach 4 Jahren wird sie zwangsläufig zu Open Source, und bis dahin bleibt der Quellcode offen.
      Außerdem verhindert sie unnötige Lizenzzersplitterung.
      Auch der Wikipedia-Artikel zur Business Source License ist hilfreich.

    • Ich frage mich, ob ein Zeitraum von 2 Jahren nicht zu kurz ist.
      Große Unternehmen nutzen ohne Probleme auch 5 Jahre alte Software, und ich finde auch Redis von 2012 oder Postgres von 2020 völlig in Ordnung.

  • Ich habe einmal die Historie solcher Fälle und eine Liste der Unternehmen zusammengestellt.
    Im zugehörigen Blogbeitrag habe ich das dokumentiert; wenn jemand noch weitere kennt, bitte gern teilen.

  • Die Pro-Funktionen haben immer wieder die Syntax der Community-Version gebrochen, daher empfinde ich überhaupt keine Transparenz.
    Natürlich braucht Arbeit eine faire Vergütung, aber dieses „wir waren mal Open Source und sind es nun still und leise nicht mehr“ wird zu häufig.
    Solche Umstellungen passieren offenbar immer leise, in der Hoffnung, dass es niemand merkt.

    • Tatsächlich hat FSL für gewöhnliche Entwickler im Alltag kaum Auswirkungen.
      Mich würde interessieren, worin konkret der Schaden oder das Hauptproblem besteht.
      Im Gegenteil gefällt mir die Unterscheidung zwischen konkurrierenden und nicht konkurrierenden Bereichen.

  • Die Stimmung in den Kommentaren wirkt etwas seltsam.
    Die meisten sehen offenbar nur „base“, empfehlen dann völlig irrelevante Dienste oder behaupten, Quelloffenlegung allein mache etwas bereits zu Open Source.

  • Ich wusste gar nicht, dass Liquibase die Lizenz geändert hat.
    Eigentlich gibt es für fast jedes Web-Framework Alternativen, und auch framework-unabhängige Alternativen wie Alembic und Flyway sind zahlreich vorhanden.
    Zu diesem Zeitpunkt wirkt das etwas merkwürdig.

  • Dieses Thema könnte auch für OSS-Projekte wie Keycloak Probleme verursachen.
    Nach den CNCF-Richtlinien dürfen keine nicht-offenen Lizenzen verwendet werden, daher kann Keycloak Liquibase nicht nutzen.
    Auch bei Debian, Fedora und ähnlichen Distributionen gibt es OSS-Lizenzanforderungen, daher frage ich mich, ob Projekte mit Liquibase-Abhängigkeit dort aufgenommen werden können.
    Details im Keycloak-Issue

    • Liquibase kann nicht in die Haupt-Repositories von Debian oder Fedora aufgenommen werden.
      In individuellen Repositories oder benutzerdefinierten Quellen wie rpm fusion non-free kann es aber enthalten sein.