Ein Anbieter ändert sein Preismodell, streicht eine Funktion oder wird übernommen. Die Frage, die dann zählt, ist nicht, ob das fair ist. Die Frage ist, wie schnell Sie das System verlassen könnten, wenn Sie wollten – und was Sie dabei verlieren würden.
Das ist der Kern digitaler Souveränität. Sie ist keine Technologiewahl, sondern eine Eigenschaft Ihrer Handlungsspielräume. Open Source ist dafür ein wirksames Mittel, aber kein Automatismus.
Souveränität heißt, eine Entscheidung später revidieren zu können
Das Bundesministerium für Digitales und Staatsmodernisierung definiert digitale Souveränität als „die Fähigkeiten und Möglichkeiten von Individuen und Institutionen, ihre Rolle(n) in der digitalen Welt selbstständig, selbstbestimmt und sicher ausüben zu können”. Als Ziele nennt es Unabhängigkeit von einzelnen Anbietern und Produkten, Resilienz durch austauschbare Komponenten sowie offene, wettbewerbsfähige Märkte.
Für einen Betrieb mit 30 oder 200 Mitarbeitern lässt sich das auf vier prüfbare Eigenschaften herunterbrechen.
Ausstiegsoption. Können Sie das System innerhalb einer definierten Frist verlassen, mit vollständigen Daten in einem dokumentierten Format, einschließlich Anhängen, Historie und Rechtezuordnung? Ein Export, der nur die Stammdaten liefert und die Verknüpfungen verliert, ist kein Ausstieg, sondern ein Neuanfang.
Datenort und Zugriffswege. Nicht nur „in welchem Rechenzentrum”, sondern auch: Wer kann administrativ auf die Daten zugreifen, unter welcher Rechtsordnung, und wird dieser Zugriff protokolliert? Das ist bei einer selbst betriebenen Instanz genauso zu beantworten wie bei einem SaaS-Vertrag – nur beantwortet es dort niemand anderes für Sie.
Lizenzrisiko. Unter welchen Bedingungen dürfen Sie die Software heute nutzen, und wer kann diese Bedingungen ändern? Bei einem proprietären Produkt ist die Antwort: der Hersteller, mit der nächsten Vertragsverlängerung.
Forkbarkeit. Falls das Projekt oder der Anbieter eine Richtung einschlägt, die für Sie nicht tragbar ist – kann jemand die letzte für Sie brauchbare Version weiterführen? Diese Möglichkeit ist nicht theoretisch: Nach der Lizenzänderung bei Redis kündigte die Linux Foundation im März 2024 die Bildung von Valkey an, einer Weiterentwicklung des Standes 7.2.4 unter der BSD-3-Clause-Lizenz, getragen unter anderem von AWS, Google Cloud, Oracle und Ericsson.
Keine dieser vier Eigenschaften ist ein Ja oder Nein. Alle vier lassen sich vor der Entscheidung prüfen – und alle vier werden meistens erst geprüft, wenn es zu spät ist.
Der Quellcode allein sagt nichts, die Lizenz sagt, was Sie dürfen
„Open Source” ist ein definierter Begriff. Die Open Source Initiative beschreibt ihn in der Open Source Definition mit zehn Kriterien. Dazu gehört, dass das Programm den Quelltext enthalten und dessen Weitergabe in Quell- wie in kompilierter Form erlauben muss, und dass die Lizenz Veränderungen und abgeleitete Werke zulassen muss.
Daraus folgt eine Unterscheidung, die im Vertrieb gern verwischt wird: einsehbarer Quellcode ist nicht dasselbe wie Open Source. Lizenzen wie die Server Side Public License oder die Business Source License legen den Code offen, stehen aber nicht auf der Liste der von der OSI anerkannten Lizenzen. Wer seine Ausstiegsstrategie darauf gründet, gründet sie auf eine Zusage, die der Hersteller einseitig ändern kann.
Innerhalb der anerkannten Lizenzen gibt es vier Familien mit sehr unterschiedlichen Folgen:
| Familie | Beispiele | Was sie Ihnen abverlangt |
|---|---|---|
| permissiv | MIT, BSD-2/3-Clause, Apache-2.0 | Urheber- und Lizenzhinweise weitergeben. Apache-2.0 verlangt zusätzlich, geänderte Dateien zu kennzeichnen und eine vorhandene NOTICE-Datei mitzuliefern. |
| schwaches Copyleft | MPL-2.0, LGPL | Änderungen an den betroffenen Dateien beziehungsweise Bibliotheken bleiben unter derselben Lizenz. Eigener Code daneben nicht. |
| starkes Copyleft | GPL-2.0, GPL-3.0 | Wer das Werk weitergibt, muss den vollständigen zugehörigen Quelltext unter derselben Lizenz mitliefern. |
| Netzwerk-Copyleft | AGPL-3.0 | Greift bereits bei der Nutzung über ein Netzwerk, ganz ohne Weitergabe. |
Die AGPL ist der Fall, der intern am häufigsten übersehen wird. Abschnitt 13 verlangt von demjenigen, der das Programm verändert und Nutzern die Interaktion über ein Netzwerk ermöglicht, diesen Nutzern „an opportunity to receive the Corresponding Source of your version” anzubieten – der geänderte Quelltext muss also verfügbar gemacht werden, obwohl die Software nie im klassischen Sinn ausgeliefert wird. Wer ein Kundenportal auf AGPL-Basis betreibt und es um eigene Funktionen erweitern lässt, hat damit eine reale Pflicht, keine theoretische.
Apache-2.0 hat einen zweiten Aspekt, der für Unternehmen zählt: Abschnitt 3 erteilt eine ausdrückliche Patentlizenz, die erlischt, sobald der Lizenznehmer selbst Patentklage wegen des Werks erhebt. Das ist ein bewusster Schutzmechanismus und einer der Gründe, warum Unternehmen Apache-2.0 häufig gegenüber MIT bevorzugen.
Für europäische und öffentliche Vorhaben kommt die European Union Public Licence hinzu. Die Europäische Kommission hat die EUPL 1.2 im Mai 2017 im Amtsblatt veröffentlicht; sie ist in 23 Amtssprachen rechtsgültig und besitzt eine Copyleft-Klausel mit einer definierten Kompatibilitätsliste zu anderen Lizenzen.
Praktisch heißt das: Bevor eine Open-Source-Komponente in ein Produkt, ein Kundenportal oder eine ausgelieferte Anwendung wandert, gehört die Lizenz in dieselbe Prüfung wie ein Vertrag. Bei der Auswahl und dem Betrieb von Open-Source-Systemen ist die Lizenzfrage deshalb Teil der Auswahl, nicht ein Nachtrag der Rechtsabteilung.
Die Abhängigkeit verschwindet nicht, sie wandert
Der häufigste Denkfehler ist, Open Source als Abwesenheit von Abhängigkeit zu verstehen. Zutreffender ist: Sie tauschen eine Abhängigkeit gegen drei andere ein, die Sie besser steuern können – wenn Sie sie kennen.
Vom Hersteller zum Betreiber. Sobald ein System selbst oder durch einen Dienstleister betrieben wird, hängt die Verfügbarkeit an diesem Betrieb. Der entscheidende Unterschied zum SaaS-Vertrag ist nicht, dass diese Abhängigkeit kleiner wäre, sondern dass sie ersetzbar ist: Wenn Installation, Konfiguration und Wiederherstellung dokumentiert sind, kann ein anderer Partner übernehmen. Ist nichts davon dokumentiert, haben Sie den Anbieterwechsel nur von der Software auf die Person verlagert – und diese Variante ist die schlechtere, weil sie in keinem Vertrag steht.
Vom Vertrag zur Community. Bei proprietärer Software kaufen Sie eine Zusage, dass jemand Sicherheitslücken schließt. Bei Open Source hängt das an der Kapazität des Projekts. Wie fragil das sein kann, hat die Hintertür in den XZ-Utils gezeigt: Schadcode gelangte in die Versionen 5.6.0 und 5.6.1 eines Kompressionswerkzeugs, das in nahezu jeder Linux-Distribution steckt. Das BSI stufte die Schwachstelle (CVE-2024-3094) mit dem höchstmöglichen CVSS-Wert von 10 als kritisch ein. Der Angriff funktionierte nicht über eine technische Lücke, sondern über das Vertrauen eines überlasteten Projekts in einen langfristig aufgebauten Mitwirkenden.
Die EU hat diesen Punkt inzwischen adressiert. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) führt die Rolle des „open-source software steward” ein: Organisationen, die die Entwicklung quelloffener Software dauerhaft und mit kommerziellem Bezug tragen, müssen nach Artikel 24 eine Cybersicherheitsstrategie nachvollziehbar dokumentieren, mit Marktüberwachungsbehörden zusammenarbeiten und aktiv ausgenutzte Schwachstellen melden. Die Meldepflichten greifen ab dem 11. September 2026, die übrigen Hauptpflichten ab dem 11. Dezember 2027. Nicht monetarisierte, nicht am Markt bereitgestellte Open-Source-Software bleibt außerhalb des Anwendungsbereichs.
Vom Anbieter zur eigenen Organisation. Die unangenehmste Abhängigkeit entsteht intern. Eine angepasste Instanz, die genau eine Person versteht, ist weniger souverän als ein Standardprodukt, das drei Personen bedienen können. Prüfen Sie das ehrlich: Wenn diese Person zwei Wochen ausfällt, wer spielt das Sicherheitsupdate ein?
Manchmal ist das proprietäre Produkt die souveränere Wahl
Open Source aus Prinzip zu wählen, ist keine Strategie. Ein Projekt, das seit anderthalb Jahren keine Sicherheitsversion mehr veröffentlicht hat, gibt Ihnen formal alle Rechte und praktisch keine Handlungsfähigkeit. Sie dürfen den Code lesen, ändern und weitergeben – aber niemand in Ihrem Unternehmen wird das tun, und ein Dienstleister, der es täte, ist teurer als die Lizenz, die Sie vermeiden wollten.
Ein kommerzielles Produkt mit sauberem Export, dokumentierten Schnittstellen und einer belastbaren Vertragsstrafe bei Nichtverfügbarkeit kann in dieser Lage die souveränere Wahl sein. Souveränität misst sich an Ihrer Handlungsfähigkeit, nicht an der Lizenz.
Bevor Sie sich auf ein Open-Source-Projekt festlegen, gehört deshalb dessen Zustand auf den Prüfstand:
- Wie viele Organisationen tragen bei – nicht: wie viele Sterne hat das Repository?
- Gibt es eine veröffentlichte Security Policy und einen benannten Meldeweg für Schwachstellen?
- Erscheinen Sicherheitsupdates auch für die Version, die Sie einsetzen würden, oder nur für die neueste?
- Ist der Upgradepfad zwischen Hauptversionen dokumentiert?
- Steht eine Stiftung, ein Verein oder ein Konsortium hinter dem Projekt, oder ein einzelnes Unternehmen, das die Lizenz jederzeit ändern kann?
- Wie viele Releases gab es in den letzten zwölf Monaten, und wie schnell wurden gemeldete Schwachstellen geschlossen?
Diese Fragen kosten einen halben Tag. Sie ersetzen die Diskussion über Weltanschauung durch eine über Nachweise.
Souveränität lässt sich prüfen, bevor sie zum Problem wird
Der Bund führt vor, wie ein solcher Prüfpfad aussehen kann: Das Zentrum für Digitale Souveränität (ZenDiS) wurde im Dezember 2022 gegründet und entwickelt mit openDesk eine offene Arbeitsplatzlösung für die Verwaltung, ergänzt um openCode als gemeinsame Plattform für nachnutzbaren Code. Der Maßstab dabei ist nicht „kein Microsoft”, sondern austauschbare Komponenten und offene Schnittstellen.
Für ein Unternehmen genügt eine kompaktere Version. Beantworten Sie die folgenden Fragen für jedes System, das einen kritischen Prozess trägt – für SaaS und für selbst betriebene Instanzen gleichermaßen:
| Bereich | Frage | Belegt durch |
|---|---|---|
| Daten | Können wir vollständig exportieren, inklusive Anhängen und Historie? | Testexport, nicht Vertragstext |
| Format | Ist das Exportformat dokumentiert und ohne den Anbieter lesbar? | Beispieldatei plus Schemabeschreibung |
| Identität | Lassen sich Benutzer und Rechte übernehmen? | Rollenkonzept, Verzeichnisanbindung |
| Betrieb | Wer kann das System administrieren, wenn die üblichen Personen ausfallen? | Betriebsdokumentation, zweite Person |
| Lizenz | Wer kann die Nutzungsbedingungen ändern und mit welcher Frist? | Lizenztext, Vertrag |
| Wiederanlauf | Wann wurde die Wiederherstellung zuletzt tatsächlich getestet? | Datum des letzten Restores |
| Ausstieg | Wie lange dauert ein Wechsel, und was bleibt dabei liegen? | grobe Aufwandsschätzung |
Die letzte Spalte ist der eigentliche Punkt. Souveränität, die nur behauptet wird, ist keine.
Seit dem 12. September 2025 gilt zusätzlich die EU-Datenverordnung (Data Act, Verordnung (EU) 2023/2854). Sie schafft einen Rahmen dafür, dass Kunden zwischen Anbietern von Datenverarbeitungsdiensten wechseln können. Das ersetzt keine eigene Ausstiegsplanung, verbessert aber die Verhandlungsposition – und es lohnt sich, bestehende Anbieterverträge daran zu messen.
Handlungsaufruf
Wenn Sie wissen wollen, wie abhängig Ihre wichtigsten Systeme tatsächlich sind, beginnen Sie mit einem Testexport und der Frage, wer außer Ihnen das System betreiben könnte. TakFlow unterstützt bei der Bewertung von Projekten und Lizenzen, bei Auswahl und Migration sowie beim laufenden Betrieb – auch mit dem Ergebnis, dass das vorhandene System bleibt.
Open-Source-Vorhaben besprechen
Weiterführend: Open Source, Self-Hosting und Betrieb · Open Source oder proprietär: die Kostenseite · Standardsoftware oder Individualsoftware?
Quellenhinweise
- BMDS: Digitale Souveränität in der öffentlichen Verwaltung – Definition, Ziele, ZenDiS und openDesk
- Open Source Initiative: The Open Source Definition – die zehn Kriterien
- Open Source Initiative: Lizenzliste – welche Lizenzen als Open Source anerkannt sind
- GNU Affero General Public License v3, Abschnitt 13 – Remote Network Interaction
- Apache License 2.0, Abschnitte 3 und 4 – Patentlizenz und NOTICE-Pflicht
- Europäische Kommission: EUPL 1.2 – Veröffentlichung im Amtsblatt, 23 Sprachfassungen
- Europäische Kommission: Cyber Resilience Act und Open Source – Rolle und Pflichten des Open-Source-Software-Verwalters
- Europäische Kommission: Cyber Resilience Act, Zusammenfassung – Geltungstermine
- BSI-Cyber-Sicherheitswarnung: Kritische Backdoor in XZ für Linux – CVE-2024-3094
- Linux Foundation: Launch der Valkey-Community – Fork nach Lizenzwechsel
- Europäische Kommission: Data Act – Geltungsbeginn und Wechselrahmen