Wie Open-Source-Firmen sich finanzieren – und was das für Ihre Abhängigkeiten bedeutet

Keine Anlageberatung. Dieser Beitrag beschreibt Geschäftsmodelle, er bewertet keine Unternehmen als Investition.

Open-Source-Software darf jeder kostenlos nutzen, verändern und weitergeben. Trotzdem stehen hinter vielen wichtigen Projekten Unternehmen mit Hunderten Beschäftigten. Sie finanzieren sich vor allem über kostenpflichtige Zusatzfunktionen (Open Core), Abonnements für Support und Updates, gehostete Angebote und kommerzielle Lizenzen; Stiftungen und öffentliche Förderung tragen vor allem gemeinsame Infrastruktur. Für Entscheider ist die Frage praktisch relevant: Wer weiß, wovon ein Hersteller lebt, kann besser einschätzen, wie stabil ein Projekt ist, wo Kosten entstehen können – und wie wahrscheinlich ein späterer Lizenzwechsel ist.

Open Core

Beim Open-Core-Modell ist der Kern einer Software Open Source, zusätzliche Funktionen gibt es nur in einer kostenpflichtigen, proprietären Edition. Typische Zusatzfunktionen sind solche, die vor allem größere Organisationen brauchen: zentrale Benutzerverwaltung, erweiterte Rechte, Compliance-Berichte, Hochverfügbarkeit.

Ein bekanntes Beispiel ist GitLab, das in seinem öffentlichen Handbuch beschreibt, nach welchen Grundsätzen es Funktionen der freien oder der bezahlten Edition zuordnet.

Für Sie relevant: Prüfen Sie, ob die Funktionen, die Sie brauchen, im offenen Kern enthalten sind. Die Grenze kann sich zwischen Versionen verschieben.

Support und Subscriptions

Hier ist die Software vollständig Open Source, verkauft wird ein Abonnement: getestete und zertifizierte Versionen, Sicherheitsupdates über lange Zeiträume, Support mit Reaktionszeiten, Zertifizierungen für bestimmte Hardware oder Anwendungen. Das bekannteste Beispiel ist Red Hat mit Red Hat Enterprise Linux.

Für Sie relevant: Sie bezahlen nicht für ein Nutzungsrecht, sondern für Verlässlichkeit. Das Modell ist für Kunden gut planbar – die Abhängigkeit liegt eher im Ökosystem (Zertifizierungen, Werkzeuge) als in der Lizenz.

Gehostete Angebote

Viele Hersteller betreiben ihre eigene Software als Cloud-Dienst und verdienen an Betrieb, Skalierung und Wartung. Beispiele sind MongoDB Atlas oder Elastic Cloud. Kunden sparen den Eigenbetrieb, die Software bleibt aber prinzipiell selbst betreibbar – ein Vorteil gegenüber rein proprietären Diensten, weil ein Ausstieg technisch möglich bleibt. Wie Sie solche Optionen kostenseitig vergleichen, beschreibt unser Leitfaden Gesamtkosten ehrlich rechnen.

Doppellizenzierung

Beim Dual Licensing bietet ein Hersteller dieselbe Software unter zwei Lizenzen an: einer Copyleft-Lizenz wie der GPL, die verlangt, dass abgeleitete Werke ebenfalls offengelegt werden, und einer kommerziellen Lizenz für Kunden, die das nicht möchten – etwa weil sie die Software in ein proprietäres Produkt einbauen. Qt ist ein bekanntes Beispiel: Das Framework ist unter Open-Source-Lizenzen (GPL/LGPL) und unter kommerziellen Lizenzen erhältlich.

Voraussetzung für dieses Modell ist, dass der Hersteller die Rechte an praktisch allen Beiträgen hält. Deshalb verlangen solche Projekte meist eine Beitragsvereinbarung (Contributor License Agreement, CLA). Die Grundlagen zu Copyleft und permissiven Lizenzen erklärt Open-Source-Lizenzen für Entscheider.

Stiftungen

Stiftungen wie die Linux Foundation, die Apache Software Foundation oder die Eclipse Foundation sind herstellerneutrale Träger. Sie halten Markenrechte, stellen Infrastruktur und Governance-Regeln bereit und finanzieren sich überwiegend aus Mitgliedsbeiträgen von Unternehmen, Spenden und Veranstaltungen. Die Entwicklung selbst leisten meist Beschäftigte der Mitgliedsfirmen.

Für Sie relevant: Ein Projekt unter dem Dach einer Stiftung mit mehreren beitragenden Firmen ist weniger anfällig dafür, dass ein einzelnes Unternehmen die Lizenz ändert. Die Eclipse Foundation hat ihren Sitz in Brüssel und ist damit auch für europäische Souveränitätsüberlegungen interessant.

Öffentliche Förderung

Ein jüngerer Baustein ist die staatliche Finanzierung offener digitaler Infrastruktur – nicht als Wirtschaftsförderung für einzelne Firmen, sondern zur Pflege von Komponenten, auf die alle angewiesen sind.

Sovereign Tech Agency

In Deutschland ist das wichtigste Instrument die Sovereign Tech Agency, eine Tochtergesellschaft der Bundesagentur für Sprunginnovationen (SPRIND). Sie ist aus dem 2022 gestarteten Sovereign Tech Fund hervorgegangen; der Fund besteht heute als eines von mehreren Programmen der Agentur weiter. Laut ihrer Website wird sie vom Bundesministerium für Digitales und Staatsmodernisierung auf Grundlage eines Beschlusses des Deutschen Bundestages unterstützt. Zu den Programmen zählen (Stand Ende Oktober 2026):

• Sovereign Tech Fund: beauftragt Arbeit an grundlegenden offenen Softwarekomponenten, etwa Wartung, Sicherheit und Dokumentation,
• Sovereign Tech Resilience (früher Bug Resilience Program): Vorbeugung und Behebung von Sicherheitslücken,
• Sovereign Tech Fellowship: finanziert Maintainer direkt; die Bewerbungsphase 2026 lief bis April,
• Sovereign Tech Standards und Sovereign Tech Challenge.

Weitere Förderprogramme

• NGI Zero / NLnet: Die niederländische Stiftung NLnet vergibt im Rahmen der EU-Initiative Next Generation Internet Fördermittel für offene Internettechnologien. Nach Angaben von NLnet war die 13. Ausschreibung des NGI Zero Commons Fund, die am 1. Juni 2026 endete, die letzte dieses Fonds; andere Programme laufen weiter.
• Prototype Fund: Das von der Open Knowledge Foundation Deutschland betriebene und vom Bundesforschungsministerium finanzierte Programm fördert Einzelpersonen und kleine Teams bei der Entwicklung von Open-Source-Prototypen.

Für Sie relevant: Öffentliche Förderung stabilisiert vor allem kritische Basiskomponenten. Sie ersetzt keinen kommerziellen Support für Anwendungen, die Sie produktiv einsetzen.

Lizenzwechsel zu „Source Available“

Seit einigen Jahren haben mehrere Unternehmen ihre Software von Open-Source-Lizenzen auf sogenannte Source-Available-Lizenzen umgestellt. Der Quellcode bleibt einsehbar, die Nutzung ist aber eingeschränkt – meist wird untersagt, die Software als konkurrierenden Dienst anzubieten. Solche Lizenzen sind nicht von der OSI anerkannt.

Die Begründung ist fast immer dieselbe: Große Cloud-Anbieter verdienen mit gehosteten Versionen der Software, ohne die Entwicklung angemessen mitzufinanzieren. Der Lizenzwechsel schützt das eigene Hosting- und Enterprise-Geschäft.

Beispiele

• MongoDB führte 2018 die Server Side Public License (SSPL) ein. Die OSI hat erklärt, dass die SSPL keine Open-Source-Lizenz ist.
• Elastic stellte Elasticsearch und Kibana 2021 auf SSPL und die eigene Elastic License um. Im August 2024 nahm das Unternehmen die AGPL als zusätzliche, OSI-anerkannte Option auf.
• HashiCorp wechselte am 10. August 2023 für künftige Versionen seiner Produkte – darunter Terraform – von der Mozilla Public License 2.0 zur Business Source License 1.1. Konkurrierende Angebote dürfen künftige Versionen danach nicht mehr einbauen.
• Redis wechselte im März 2024 zu einer Doppellizenz aus RSALv2 und SSPL. Mit Redis 8 kam im Mai 2025 die AGPLv3 als zusätzliche Open-Source-Option hinzu.

Die Reaktion der Community: Forks

Lizenzwechsel lösen häufig Abspaltungen aus. Nach dem Redis-Wechsel startete unter dem Dach der Linux Foundation das Projekt Valkey auf Basis der letzten offen lizenzierten Version. Nach dem HashiCorp-Wechsel entstand OpenTofu als offener Terraform-Fork, ebenfalls bei der Linux Foundation. Elastic war bereits 2021 von einem Fork betroffen: OpenSearch.

Die Beispiele Elastic und Redis zeigen auch: Lizenzentscheidungen sind nicht endgültig. Beide Unternehmen haben nach einigen Jahren wieder eine OSI-anerkannte Lizenz hinzugefügt.

Was Entscheider daraus ableiten können

1. Geschäftsmodell verstehen. Fragen Sie bei jeder kritischen Komponente: Wovon lebt der Hersteller, und wo stehen seine Einnahmen im Konflikt mit Ihrer Nutzung?
2. Rechteinhaber prüfen. Hält ein einzelnes Unternehmen alle Rechte (erkennbar etwa an einer CLA ohne Stiftung), ist ein Lizenzwechsel rechtlich leichter möglich als bei einem Projekt mit vielen Rechteinhabern.
3. Governance bewerten. Projekte unter Stiftungsdach mit mehreren tragenden Firmen gelten als stabiler.
4. Ausweichoptionen kennen. Gibt es einen Fork oder eine Alternative? Unser Beitrag zur Exit-Strategie gegen Lock-in zeigt, wie Sie das systematisch vorbereiten.
5. Bezahlen, was Sie brauchen. Wer Open Source produktiv nutzt, sichert mit Support-Verträgen oder Mitgliedschaften auch die Zukunft der Projekte – das ist oft günstiger als ein erzwungener Wechsel.

Keine Anlageberatung.