Bevor Sie das nächste Open-Source-Tool einsetzen

Es gibt Dienstagmorgen, die bleiben im Gedächtnis. Nicht weil etwas Dramatisches passiert wäre, sondern weil ein Routine-Update plötzlich eine Lawine lostritt. Sie öffnen das Release-Blog Ihres liebsten Infrastructure-Tools, bereit für die üblichen Bug-Fixes und Performance-Verbesserungen. Stattdessen lesen Sie: "We're transitioning to the Business Source License to better protect our innovation."

Für viele DevOps-Teams war 2023 voll von solchen Dienstagmorgen. HashiCorp wechselte Terraform von der Mozilla Public License zur Business Source License. Redis verabschiedete sich nach 15 Jahren von der BSD-Lizenz. Elasticsearch hatte bereits 2021 die Apache-2.0-Lizenz gegen proprietäre Lizenzen getauscht.

Das Problem: Diese Lizenzwechsel sind keine technischen Entscheidungen. Sie sind existenzielle Ereignisse, die Pipelines brechen, rechtliche Unsicherheiten schaffen und das Vertrauen in Open Source erschüttern. Und sie folgen fast immer demselben Muster.

Bei Natron beschäftigen wir uns intensiv mit Open-Source-Infrastruktur. Während wir an flex.plane arbeiten, unserem Control Plane für Proxmox-Umgebungen, definieren wir gerade unser eigenes Open-Source-Modell. Die Geschichte der letzten Jahre liefert uns dabei wichtige Inputs – und hat uns veranlasst, diesen Leitfaden zu schreiben: Was ist schiefgelaufen, wie erkennt man die Warnsignale, und wie evaluiert man Open-Source-Tools, bevor man kritische Infrastruktur darauf aufbaut?

Die große Open-Source-Wende (2018–2025)

Die letzten sieben Jahre haben das Verhältnis zwischen Open Source und kommerziellen Interessen fundamental verändert. Was folgt, ist keine abstrakte Diskussion über Lizenz-Philosophie, sondern reale Projekte, die Millionen von Produktionssystemen betreiben, und die Entscheidungen, die ihre Communities erschüttert haben.

MongoDB (2018): Der erste Schuss

MongoDB wechselte 2018 von der AGPL zur Server Side Public License (SSPL), einer Lizenz, die MongoDB selbst erfand, um Cloud-Provider daran zu hindern, MongoDB-as-a-Service anzubieten. Das Ergebnis: Red Hat, Debian und Fedora entfernten MongoDB aus ihren Distributionen, da die SSPL nicht als freie Software gilt. Die Open Source Initiative (OSI) lehnte die SSPL als Open-Source-Lizenz ab.

MongoDB setzte damit den Präzedenzfall für eine neue Generation von "Source Available"-Lizenzen, die den Namen "Open Source" beanspruchen, aber die Freiheiten einschränken. Die Begründung war nachvollziehbar: MongoDB hatte über 300 Millionen Dollar in R&D investiert, während Cloud-Provider wie AWS damit Geld verdienten, ohne nennenswert beizutragen. Die Frage ist: War ein nachträglicher Lizenzwechsel die richtige Antwort?

Redis (2024): 15 Jahre Geschichte enden abrupt

Im März 2024 beendete Redis seine 15-jährige BSD-3-Lizenzgeschichte und wechselte zur dualen Lizenzierung unter Redis Source Available License v2 und SSPL. Die Linux Foundation lancierte binnen Tagen Valkey, einen Fork des letzten BSD-lizenzierten Redis, unterstützt von AWS, Google Cloud, Oracle und anderen. Externe Beiträge zu Redis brachen um über 80 Prozent ein.

Ein Jahr später versuchte Redis einen Teil-Rückzieher mit einer AGPLv3-Relizenzierung des Kerns. Doch das Vertrauen war bereits zerbrochen – die Community hatte sich hinter Valkey versammelt. Die Lektion: Einmal gebrochenes Vertrauen kehrt nicht zurück. Entwickler und Unternehmen migrieren lieber zu einem Fork unter neutraler Governance, als auf weitere Plot-Twists zu warten.

HashiCorp (2023): Von MPL zu BSL

HashiCorp relizenzierte im August 2023 alle Kernprodukte – Terraform, Vault, Consul, Nomad – von der Mozilla Public License 2.0 zur Business Source License. Innerhalb von zwei Wochen formierte sich OpenTofu, ein Fork von Terraform, der zur Linux Foundation ging. Über 100 Firmen, 10 Projekte und 400 Einzelpersonen unterstützten das Manifest.

Wenige Monate später kaufte IBM HashiCorp für 6 Milliarden US-Dollar. IBM erwarb effektiv ein Produkt, dessen Community bereits zu einem offenen Fork migriert war. Die Ironie: HashiCorp schützte sich vor Cloud-Providern und verlor dabei die Entwickler-Community, die Terraform erst groß gemacht hatte. Bryan Cantrill hatte Jahre zuvor gewarnt: "CLAs sind eine Strategie mit nur einem Zweck – einen Teppich unter das Projekt zu legen, damit man ihn beim ersten schlechten Quartal wegziehen kann."

Elasticsearch (2021): Der AWS-Konflikt

Elastic wechselte 2021 von Apache 2.0 zu einer dualen Lizenzierung unter Elastic License 2.0 und SSPL, um sich gegen den AWS Elasticsearch Service zu schützen. Die Begründung: AWS nannte ihren Service "Amazon Elasticsearch" und profitierte vom Elastic-Trademark, ohne beizutragen. Amazon forkte die letzte Apache-2.0-Version (7.10.2) und lancierte OpenSearch und OpenSearch Dashboards – beide unter Apache 2.0.

2024 versuchte Elastic eine teilweise Rückkehr zur AGPL. Doch wie bei Redis war es zu spät. OpenSearch hatte sich als echte Alternative etabliert, mit eigener Roadmap und wachsender Community. Das Entwickler-Sentiment in den Foren: "Too late, we already migrated. Cost me a bunch of time fixing code when they pulled the plug."

Weitere bedeutende Wechsel

Die Liste geht weiter: Akka wechselte 2022 von Apache 2.0 zu BSL, was das Scala-Ökosystem erschütterte. Das Actor-Framework ist kritisch für viele Enterprise-JVM-Anwendungen. Preis: 1.995 bis 2.995 USD pro Core und Jahr für Produktionssysteme.

Confluent lizenzierte 2018 selektiv Kafka-Komponenten wie Schema Registry und KSQL von Apache 2.0 zur "Confluent Community License" um. Apache Kafka selbst blieb offen, da es von der Apache Software Foundation verwaltet wird – ein wichtiger Unterschied.

Red Hat beschränkte 2023 den Zugang zu RHEL-Source-Code auf zahlende Kunden. Technisch blieb die GPL bestehen, praktisch wurde der Zugang massiv eingeschränkt. Das führte zur Entstehung der OpenELA-Allianz (Open Enterprise Linux Association). Selbst etablierte Open-Source-Firmen stehen unter kommerziellem Druck.

CockroachDB wechselte mehrfach zwischen Apache 2.0, BSL und der eigenen CockroachDB Community License. Jeder Wechsel erodierte das Community-Vertrauen weiter. Die Unentschlossenheit bei der Lizenzierung schadete mehr als eine klare Entscheidung.

Übersicht der wichtigsten Lizenzwechsel

Was macht einen Lizenzwechsel problematisch?

Nicht jeder Lizenzwechsel ist gleich. Es gibt einen fundamentalen Unterschied zwischen verschiedenen Geschäftsmodellen:

Open-Core-Modelle wie GitLab, Grafana oder Nextcloud trennen von Anfang an klar zwischen offenen und kommerziellen Features. Die Community weiß von Tag eins, was sie bekommt. Die Core-Funktionalität bleibt offen, Enterprise-Features sind klar als solche gekennzeichnet. GitLab verdient über 270 Millionen Dollar ARR mit einem transparenten CE/EE-Split. Grafana Labs über 400 Millionen mit Open Core und Cloud-Services. Diese Modelle funktionieren, weil sie ehrlich und konsistent sind.

Problematisch wird es, wenn Unternehmen eine Community unter einer permissiven Lizenz aufbauen, alle von der "offenen" Software abhängig werden, und dann die Lizenz wechseln. Das folgt oft dem "Drug Dealer"-Muster: Die erste Dosis ist kostenlos, finanziert durch VC-Geld. Sobald die Abhängigkeit da ist und die Investoren ihre Returns sehen wollen, wird über Lizenz-Restriktionen monetarisiert.

Chad Whitacre formulierte es treffend in seinem Essay "Relicensing and Rug Pulls": Es ist nur ein Rug Pull, wenn jemand auf dem Teppich stand. Wenn ein Projekt keine echte Community von externen Entwicklern hat, sondern nur Nutzer, dann ist ein Lizenzwechsel vielleicht ärgerlich, aber kein Vertrauensbruch im gleichen Ausmaß. Der Beweis: Entsteht ein viables Fork? Bei HashiCorp (OpenTofu), Redis (Valkey) und Elasticsearch (OpenSearch) lautete die Antwort: Ja.

Warnsignale erkennen: Die Evaluations-Checkliste

Bevor Sie ein Open-Source-Tool in Ihre kritische Infrastruktur aufnehmen, sollten Sie diese Faktoren systematisch prüfen:

1. Foundation-Hosting

Wird das Projekt von der Linux Foundation, CNCF, Apache Software Foundation oder ähnlichen neutralen Organisationen gehostet? Foundation-gehostete Projekte haben neutrale Governance, rechtlichen Schutz und Multi-Stakeholder-Aufsicht. Kein einzelnes Unternehmen kann unilateral die Lizenz ändern.

Beispiele erfolgreicher Foundation-Projekte:

• Kubernetes ist bei der CNCF – Google kann keinen Rug Pull machen, obwohl sie es erschaffen haben
• OpenTofu ging nach dem HashiCorp-Lizenzwechsel zur Linux Foundation
• Valkey ging nach Redis zur Linux Foundation, mit Backing von AWS, Google, Oracle
• Apache Kafka bleibt stabil unter der Apache Software Foundation

Der Unterschied ist fundamental: Eine Foundation besitzt die Trademarks, verwaltet die IP und hat eine Charter, die unilaterale Änderungen verhindert. Mehrere Unternehmen finanzieren die Entwicklung gemeinsam, was Nachhaltigkeit schafft ohne einzelne Abhängigkeit.

2. Finanzierung und Investoren

Wie ist das Projekt finanziert? Diese Frage ist kritischer, als viele denken.

Die Zahlen sprechen für sich: HashiCorp hatte 350 Millionen Dollar VC-Finanzierung raised, Elastic 162 Millionen, MongoDB investierte nach eigenen Angaben 300 Millionen in R&D. VCs erwarten 10x-Returns innerhalb weniger Jahre. Wenn organisches Wachstum nicht ausreicht, wird der Druck groß, die Lizenz zu ändern, um mehr Kontrolle über die Monetarisierung zu haben.

Vergleichen Sie das mit Proxmox, das profitabel durch Enterprise-Subscriptions und Support läuft, ohne Exit-Druck. Oder Canonical mit Ubuntu, das seit Jahrzehnten stabil durch Professional Services Geld verdient. Diese Modelle sind langfristig nachhaltiger.

3. Contributor License Agreements

Verlangt das Projekt ein CLA? Ein CLA gibt dem Unternehmen die Macht, Ihre Beiträge zu relizensieren, ohne Sie zu fragen. Das schafft eine fundamentale Machtasymmetrie. HashiCorp, Elasticsearch und andere Rug-Pull-Kandidaten hatten CLAs.

Developer Certificate of Origin (DCO) ist das bessere Modell, verwendet vom Linux-Kernel und den meisten Foundation-Projekten. Bei DCO behalten Contributors die Rechte an ihren Beiträgen. Das Projekt kann nicht ohne Konsens relizenziert werden.

Wie Sie das überprüfen: Schauen Sie in CONTRIBUTING.md oder die Dokumentation. Die Frage "CLA oder DCO?" ist ein starker Indikator für zukünftiges Verhalten.

4. Contributor-Diversität

Schauen Sie sich die GitHub-Contributors an. Kommen 80 Prozent oder mehr von einem einzigen Unternehmen? Das bedeutet hohes Risiko. Bei einem Fork hätte die Community keine kritische Masse an Entwicklern. Das Projekt ist effektiv ein Single-Vendor-Projekt, das nur als Open Source vermarktet wird.

Prüfen Sie das unter: GitHub → Insights → Contributors

Projekte mit diversen Contributors von mehreren Unternehmen sind resilienter. Bei Redis waren vor dem Fork fast doppelt so viele externe Contributors wie interne – deshalb konnte Valkey sofort durchstarten. Bei Elasticsearch war die Situation ähnlich, was OpenSearch ermöglichte.

5. Geschäftsmodell-Klarheit

Ist klar, wie das Projekt Geld verdient? Open Core, Support-Verträge oder Managed Cloud Services sind etablierte Modelle. Vage Aussagen wie "commitment to open source" ohne Details oder "wir finden später ein Modell" sind Warnsignale.

Erfolgreiche transparente Modelle:

Wenn ein Projekt keine klare Antwort auf "Wie verdient ihr Geld?" hat, aber Millionen an VC-Finanzierung hat, ist das ein massives Warnsignal.

6. Cloud-Provider-Konflikte

Gibt es öffentliche Spannungen mit AWS, GCP oder Azure? Beschwerden über Cloud-Provider, die das Tool als Service anbieten, sind oft Vorboten eines Lizenzwechsels. Der Elastic-AWS-Konflikt begann mit Trademark-Streitigkeiten, endete mit Lizenzwechsel und Fork.

MongoDB, HashiCorp, Redis, Elasticsearch – alle hatten explizite Konflikte mit Cloud-Providern, bevor sie die Lizenz änderten. Die Begründungen für die Lizenzwechsel nannten immer Cloud-Provider als Hauptgrund.

Projekte mit stabilen Partnerschaften oder neutraler Foundation-Governance haben dieses Problem nicht im gleichen Ausmaß. CNCF-Projekte werden von allen großen Cloud-Providern gemeinsam unterstützt.

Die Entscheidungs-Matrix

Kombinieren Sie diese Faktoren in einer einfachen Risiko-Bewertung:

Geringes Risiko: Foundation-gehostet, DCO statt CLA, diverse Contributors von mehreren Firmen, klares Geschäftsmodell von Anfang an, entweder bootstrapped oder mit etabliertem Revenue-Stream.

Mittleres Risiko: Community-governed aber nicht Foundation-gehostet, gemischte Contributor-Basis, Open Core Modell im Entstehen, kleine VC-Runde, einige Spannungen mit Cloud-Providern.

Hohes Risiko: Dominiert von einem Unternehmen, CLA erforderlich, Series B+ VC-Finanzierung, vages Geschäftsmodell, aktive Konflikte mit Cloud-Providern, über 80 Prozent der Commits von einer Firma.

Diese Matrix hätte vor den großen Rug Pulls der letzten Jahre gewarnt. Sie wird auch in Zukunft helfen.

Warum passiert das?

Das grundlegende Problem ist strukturell. Cloud-Provider können jede Open-Source-Software als Managed Service anbieten. Sie tragen oft wenig zur Entwicklung bei, kassieren aber einen Großteil des Umsatzes. Original-Entwickler investieren hunderte Millionen in R&D, Cloud-Giganten profitieren kostenlos davon.

Das ist legal unter den meisten Open-Source-Lizenzen. Die Frage ist: Ist es fair? MongoDB, HashiCorp und Elastic argumentierten: Nein. Ihre Lösung: Lizenzwechsel, um Cloud-Provider zu blockieren. Das Resultat: Community-Forks unter neutraler Governance, die oft erfolgreicher wurden als die Originale.

Die Investoren-Perspektive verschärft das Problem. VCs investieren mit der Erwartung von 10x-Returns innerhalb weniger Jahre. Open Source allein garantiert keine Profite. Wenn das Wachstum stockt oder ein Exit naht, wird der Druck groß. Ein Lizenzwechsel scheint dann der einfachste Weg, mehr Kontrolle über die Monetarisierung zu bekommen.

Das Tragische: Die Rechnung geht selten auf. HashiCorp verlor die Community an OpenTofu. Redis verlor sie an Valkey. Elasticsearch verlor sie an OpenSearch. Die kurzfristige Kontrolle wurde mit langfristigem Vertrauensverlust erkauft.

Was erfolgreiche Modelle anders machen

Es gibt funktionierende Geschäftsmodelle für Open Source. Der Schlüssel ist Transparenz von Anfang an:

GitLab trennte von Tag eins klar zwischen Community Edition und Enterprise Edition. Keine Überraschungen, keine nachträglichen Änderungen. Resultat: Eine gesunde Community und über 270 Millionen Dollar ARR.

Grafana Labs baute Open Core mit Grafana Cloud als primäre Revenue-Source. Vollständig transparent, klar kommuniziert. Resultat: Über 400 Millionen Dollar ARR, 7.000 zahlende Kunden, massive Community-Adoption.

Nextcloud fokussiert auf Privacy und Self-Hosting, mit klaren Enterprise-Features für Organisationen. Die Community weiß genau, was offen ist und was nicht.

Canonical macht Ubuntu komplett kostenlos für die Community, verdient durch Ubuntu Pro, Support und Cloud-Services. Nach Jahrzehnten immer noch stabil.

Proxmox bietet die komplette Funktionalität Open Source, verdient durch Enterprise-Subscriptions für Repository-Zugang, Updates und Support. Kein Vendor-Lock-in, keine künstlich beschränkten Features.

Diese Modelle funktionieren, weil sie ehrlich sind und bleiben. Keine nachträglichen Regel-Änderungen. Keine Überraschungen. Keine gebrochenen Versprechen.

Praktische Empfehlungen für Infrastructure-Teams

Entwickeln Sie eine Tool-Evaluation-Policy

Bevor ein Open-Source-Tool in kritische Infrastruktur aufgenommen wird, prüfen Sie systematisch:

1. Foundation-Hosting – Neutral gehostet oder Single-Vendor?
2. Finanzierung – Bootstrapped, kleine Runde oder Series B+?
3. CLA/DCO – Welche Contributor-Rechte gibt es?
4. Contributor-Diversität – Eine Firma oder breite Community?
5. Geschäftsmodell – Klar oder vage?
6. Cloud-Provider-Beziehungen – Partnerschaft oder Konflikt?

Dokumentieren Sie Lizenz-Abhängigkeiten

Wissen Sie, unter welcher Lizenz jedes Tool in Ihrem Stack läuft. Tracken Sie Lizenzänderungen aktiv. Setzen Sie Alerts für Major-Version-Updates der kritischen Dependencies.

Planen Sie für Forks

Wenn ein Tool hohes Risiko hat aber kritisch ist, haben Sie einen Plan B. Kennen Sie die Fork-Kandidaten. Valkey existierte Tage nach dem Redis-Lizenzwechsel, OpenTofu Wochen nach HashiCorp. Communities reagieren schnell, wenn sie vorbereitet sind.

Präferieren Sie Foundation-gehostete Projekte

Wenn Sie zwischen zwei ähnlichen Tools wählen müssen, geben Sie dem Foundation-gehosteten den Vorzug. Die Governance-Struktur ist ein Feature, kein Nice-to-have.

Engagieren Sie sich in Communities

Projekte mit echter Community-Beteiligung sind resilienter gegen Rug Pulls. Wenn Ihr Unternehmen ein Tool kritisch nutzt, contributen Sie Code, sponsern Sie, nehmen Sie an Governance teil. Das gibt Ihnen Einfluss und Warnzeit.

Die Zukunft von Open Source Infrastructure

Wir sehen mehrere positive Entwicklungen: Mehr Foundation-gehostete Projekte nach erfolgreichen Forks wie OpenTofu und Valkey. Die Community hat gelernt, schnell und koordiniert zu reagieren. Klarere Verständnisse darüber, welche Geschäftsmodelle funktionieren. Open Core ist legitim, wenn transparent. Community-bewusstes Investieren wächst, wo Investoren verstehen, dass Vertrauen ein Asset ist.

Die negativen Beispiele lehren uns mehr als die positiven. MongoDB, HashiCorp, Redis und Elasticsearch zeigen, was nicht funktioniert. Kurzfristige Kontrolle durch Lizenzwechsel führt zu langfristigem Vertrauensverlust und erfolgreichen Forks. Die Rechnung geht nicht auf.

Foundation-Governance wird zunehmend als Qualitätsmerkmal gesehen, nicht als bürokratischer Overhead. CNCF, Linux Foundation und Apache SF sind Garantien für Stabilität und faire Governance.

Unsere eigene Reise

Bei Natron arbeiten wir aktuell an flex.plane, einem Control Plane für Proxmox VE. Während wir das Projekt entwickeln, definieren wir parallel unser Open-Source-Modell. Die Geschichte der letzten Jahre – MongoDB, HashiCorp, Redis, Elasticsearch – liefert uns dabei wichtige Inputs.

Wir wissen, was wir vermeiden wollen: Nachträgliche Lizenzwechsel. CLAs, die uns unilaterale Macht geben würden. Vage Kommunikation über unser Geschäftsmodell. Konflikte mit der Community, die wir aufbauen wollen.

Wir wissen auch, was funktioniert: Transparenz von Anfang an. Klare Trennung zwischen Open und Commercial, wenn wir Open Core wählen. Foundation-Governance in Betracht ziehen. DCO statt CLA. Ehrlichkeit und Konsistenz über Jahre.

flex.plane ist noch in der Definition. Aber die Lektionen sind klar. Und wir nehmen sie ernst.

Fazit

Die letzten sieben Jahre haben Open Source fundamental verändert. Die Ära der bedingungslos offenen Infrastruktur-Software ist vorbei. Kommerzielle Interessen und Open Source müssen koexistieren. Die Frage ist: Wie?

Die Antwort liegt nicht in Ideologie, sondern in Vertrauen. Open Core kann funktionieren. Kommerzielle Lizenzen können funktionieren. Subscriptions und Support können funktionieren. Der Schlüssel ist: Von Anfang an ehrlich sein und dabei bleiben. Keine nachträglichen Regel-Änderungen. Keine gebrochenen Versprechen.

Für Teams, die Open-Source-Tools evaluieren: Die Warnsignale sind identifizierbar. Foundation-Hosting, Finanzierung, CLAs, Contributor-Diversität, Geschäftsmodell-Klarheit – diese Faktoren sagen viel über zukünftiges Verhalten voraus. Nutzen Sie sie.

Die Community hat gelernt, sich zu wehren. Forks wie OpenTofu, Valkey und OpenSearch zeigen: Wenn das Vertrauen gebrochen wird, kann die Community schnell und effektiv reagieren. Das ist die eigentliche Stärke von Open Source – nicht dass es kostenlos ist, sondern dass es forkbar ist.

Vertrauen ist schwer aufzubauen und leicht zerstört. Die Firmen, die das verstehen – GitLab, Grafana Labs, Nextcloud, Canonical, Proxmox – prosperieren. Die Firmen, die es nicht verstehen, verlieren ihre Communities an Forks.

Die Zukunft von Open Source Infrastructure ist nicht weniger offen. Sie ist bewusster. Transparenter. Realistischer über Geschäftsmodelle. Und das ist gut so.

---

Quellen und weiterführende Links:

• Linux Foundation: OpenTofu Project
• Linux Foundation: Valkey Project
• HashiCorp: "HashiCorp Adopts Business Source License" (August 2023)
• Redis Licensing FAQ
• Elastic: License Change History
• MongoDB: SSPL Documentation
• LWN.net: "Rug pulls, forks, and open-source feudalism"
• Chad Whitacre: "Relicensing and Rug Pulls"
• RedMonk: "Software Licensing Changes and Their Impact on Financial Outcomes"
• Jeff Geerling: "Corporate Open Source is Dead"
• Open Source Initiative: SSPL Discussion