„Wir steigen auf Linux um.“ „Wir setzen auf freie Software.“ Diese Sätze tauchen immer wieder auf, sobald sich ein Ausschuss mit der Software-Souveränität befasst, und sie werden mit einem Tonfall ausgesprochen, als sei es eine Selbstverständlichkeit, als würde der offene Code die Frage allein durch seine Natur lösen. Er löst zwar einen Teil davon. Einen anderen Teil lässt er unberührt, und manchmal verlagert er das Problem, ohne es zu lösen. Bei der Software-Souveränität geht es nicht um den Gegensatz zwischen proprietärer und freier Software. Es geht um jede einzelne Ebene: Wer kontrolliert was, und kann man sich davon lösen?

Was Open Source tatsächlich garantiert

Freie Software basiert auf vier Freiheiten, die von der Free Software Foundation formuliert wurden: das Programm für jeden beliebigen Zweck auszuführen, seine Funktionsweise zu untersuchen, es weiterzuverbreiten und es zu verändern sowie die veränderten Versionen zu verbreiten. Open Source, wie es von der Open Source Initiative definiert wird, deckt einen ähnlichen Bereich ab. Diese Freiheiten sind nicht theoretischer Natur. Sie führen zu drei konkreten Eigenschaften.

Zunächst einmal die Überprüfbarkeit. Der Quellcode ist lesbar und somit überprüfbar. Eine Organisation, die dies wünscht, kann überprüfen lassen, was eine Software tatsächlich ausführt, ohne sich auf das Wort des Herstellers verlassen zu müssen. Für einen regulierten Sektor hat diese Transparenz Beweiskraft.

Zweitens das Fehlen einer widerrufbaren Lizenz. Eine freie Lizenz – sei es die GPL, Apache oder MIT – erlischt nicht durch einseitige Entscheidung. Der Herausgeber kann weder den Zugriff auf eine bereits erworbene Version sperren noch deren Nutzung von heute auf morgen untersagen. Die Kontinuität hängt nicht vom guten Willen eines Dritten ab.

Und schließlich die Möglichkeit eines Forks. Wenn das Projekt seinen Kurs ändert, eingestellt wird oder in feindliche Hände fällt, bleibt der Code verfügbar, und jemand kann die Entwicklung fortsetzen. Die Wartungsgemeinschaft, sofern es eine gibt, verteilt diese Aufgabe auf mehrere Mitwirkende und Organisationen.

Was nicht garantiert wird

Keine dieser Freiheiten ist eine Dienstleistung. Offener Code beinhaltet weder Support noch eine Fehlerbehebungsgarantie noch eine Roadmap. Die Freiheit zur Änderung gilt nur für diejenigen, die wissen, wie man Änderungen vornimmt, und die Freiheit zur Überprüfung gilt nur für diejenigen, die über die entsprechenden Mittel verfügen. Den Quellcode eines Kernels, eines Hypervisors oder einer Datenbank zu lesen, um sicherzustellen, dass er keine Sicherheitslücken enthält, setzt seltene Fachkenntnisse und einen kontinuierlichen Aufwand voraus. Der verfügbare Code ist nicht gleichbedeutend mit geprüftem Code.

Bei der Sicherheit gilt dieselbe Logik. Freie Software ist nicht sicher, nur weil sie offen ist; sie ist sicher, wenn kompetente Menschen sie lesen, testen und im Laufe der Zeit korrigieren. Der Vorfall mit der kritischen Sicherheitslücke in log4j im Jahr 2021 – einer Komponente, die in unzähligen Systemen vorhanden ist und von einer Handvoll Freiwilliger gepflegt wird – hat erneut gezeigt, dass eine offene und allgegenwärtige Komponente unterfinanziert und unzureichend überwacht bleiben kann. Offenheit ermöglicht die Überprüfung, führt sie aber nicht durch.

Vor allem sagt Open Source nichts über die Infrastruktur aus. Freie Software läuft immer irgendwo, auf Rechnern, in einem Netzwerk, unter einer Rechtsordnung. Die Lizenz des Codes und die rechtliche Zugehörigkeit des Hosting-Anbieters sind zwei getrennte Fragen, und die erste beantwortet niemals die zweite.

Fälle, in denen OSS wirklich etwas bewirkt

Freie Software wirkt sich auf die Souveränität aus, wenn sie an den richtigen Hebeln ansetzt. Drei Situationen verdeutlichen dies.

Die lokale Bereitstellung. Freie Software, die auf einer Infrastruktur installiert ist, über die die Organisation die Kontrolle hat, beseitigt die Abhängigkeit von einem entfernten Dienstanbieter. Der Code befindet sich vor Ort, unter einem selbst gewählten Recht, ohne ausgehende Aufrufe an Dritte. Dies ist der Fall, der einer echten Unabhängigkeit am nächsten kommt.

Regulatorische Nachprüfbarkeit. Für eine Gesundheitsbehörde, eine Bank oder einen systemrelevanten Betreiber ist die Möglichkeit, den genauen Code vorzulegen, der sensible Daten verarbeitet, kein Komfort, sondern manchmal eine Verpflichtung. Eine versiegelte proprietäre Komponente verhindert diesen Nachweis; eine offene Komponente ermöglicht ihn.

Das Fehlen einer widerrufbaren Lizenz. Bei einem kritischen proprietären Dienst können sich die Bedingungen ändern, der Preis steigen oder der Zugang auf Beschluss eines Anbieters oder aufgrund einer extraterritorialen Maßnahme gesperrt werden. Die freie Lizenz schützt die Software-Schicht selbst vor diesem Risiko. Den Rest schützt sie jedoch nicht.

Fälle, in denen sich nichts ändert

Umgekehrt bietet das Label „Open Source“ in vielen gängigen Konstellationen keinerlei Garantie für Souveränität.

Freie Software, die bei einem Dritten eingesetzt wird. Eine freie Datenbank oder ein freier Orchestrator, die bzw. der als Managed Service auf einer fremden Infrastruktur betrieben wird, unterliegt dem Recht dieses Betreibers, genau wie ein proprietäres Produkt. Der Code ist offen, die Abhängigkeit bleibt jedoch vollständig bestehen. Die Art der Lizenz ändert nichts an der rechtlichen Zugehörigkeit desjenigen, der die Maschine betreibt.

Die Abhängigkeit von proprietären Komponenten. Ein freies Betriebssystem, das nur mit proprietären Treibern, signierten Mikrocodes oder geschlossener Firmware startet, ist nicht autonom. Die sichtbare Ebene ist offen, stützt sich jedoch auf Bausteine, die man weder lesen, noch reproduzieren, noch ersetzen kann. Die Freiheit endet beim ersten versiegelten Hardware-Bauteil.

Das Fehlen interner Wartungsmöglichkeiten. Die Freiheit, einen kritischen Kernel zu forken, gilt nur für diejenigen, die ihn auch tatsächlich warten können. Ein stark reguliertes Unternehmen oder ein Akteur im Verteidigungsbereich, der nicht über die technischen Ressourcen verfügt, um die Entwicklung eines Betriebssystems fortzusetzen, dessen Herausgeber sich zurückzieht, ist von einem Dienstleister abhängig – egal, ob dieser offen ist oder nicht. Das Recht auf Änderung schafft noch nicht die Fähigkeit zur Änderung.

In diesen drei Fällen wird das entscheidende Eigentumsmerkmal – die Kontrolle über die jeweilige Ebene und die Möglichkeit, diese zu verlassen – durch die Lizenz nicht gewährleistet. Es hängt davon ab, wo die Software läuft, worauf sie basiert und wer sie beherrscht.

Die richtige Frage bezieht sich also niemals auf die Bezeichnung. Sie stellt sich Schicht für Schicht, von der Hardware bis zum Dienst: Wer kontrolliert diese Schicht, unter welchem Recht, und was geschieht an dem Tag, an dem diese Kontrolle wegfällt? Freie Software verschiebt einige dieser Antworten in die richtige Richtung. Die anderen schreibt sie jedoch nicht für Sie vor.

Quellen

  • Free Software Foundation, Definition von freier Software, gnu.org
  • Open Source Initiative, Open Source Definition, opensource.org
  • Apache Software Foundation, Log4Shell-Sicherheitslücke (CVE-2021-44228), Dezember 2021
  • ANSSI, Empfehlungen zur Sicherheit von Software-Basisplattformen, cyber.gouv.fr

Der französische Staat hat entschieden, und das verändert die Dimension

Die Debatte hat die Foren verlassen. Im Jahr 2026 fordert die interministerielle Direktion für Digitalisierung (DINUM) von jedem Ministerium einen Plan zur Verringerung der Abhängigkeiten von außereuropäischen Anbietern im Digitalbereich. Der Umfang ist groß: Arbeitsplätze, Tools für die Zusammenarbeit, Antivirenprogramme, künstliche Intelligenz, Datenbanken, Virtualisierung, Netzwerkausrüstung. Die Umstellung des Betriebssystems von Windows auf Linux ist nur die sichtbarste Ebene eines tiefgreifenderen Vorhabens.

Rund um das Betriebssystem treibt der Staat seinen eigenen Software-Stack voran: „Tchap“ für den E-Mail-Verkehr, „Visio“ für Videokonferenzen, „FranceTransfert“ für Dateien, zusammengefasst in der „Suite numérique“. Die Krankenkasse hat bereits 80.000 Mitarbeiter auf diese Tools umgestellt. Das erklärte Ziel liegt bei über zwei Millionen Mitarbeitern bis 2027. Der Auslöser ist keine technische Laune. Die erneuten Handelsspannungen im Jahr 2025 haben die Frage der Rechtshoheit wieder aufgerollt, und das Thema „CLOUD Act“ ist zu präsent geworden, um ignoriert zu werden.

Die Gendarmerie hat dies bereits vor zwanzig Jahren getan

Neu ist das Ausmaß, nicht das Prinzip. Die Gendarmerie nationale arbeitet seit 2008 mit Linux, und zwar mit GendBuntu, einer maßgeschneiderten Version von Ubuntu. Im Juni 2024 waren 103.164 Arbeitsplätze damit ausgestattet, was 97 Prozent des Bestands entspricht. Die Einsparungen sind deutlich: rund zwei Millionen Euro weniger für Lizenzen pro Jahr und um etwa 40 Prozent gesenkte Betriebskosten.

Entscheidend ist nicht die Zahl, sondern die Methode. Die Gendarmerie hat die Umstellung nicht auf einen Schlag vollzogen. Sie begann bereits 2004 mit „schmerzfreien“ Bausteinen – dem Browser, der Office-Suite und dem E-Mail-System –, während sich die internen Kompetenzen und die Governance aufbauten. Das Betriebssystem kam zuletzt, auf bereits vorbereitetem Terrain. Im Jahr 2026 nennt die DINUM dieses Modell ausdrücklich als Vorbild für andere Ministerien. Software-Souveränität lässt sich nicht kaufen, sondern muss über Jahre hinweg Schicht für Schicht aufgebaut werden.

Offen bedeutet nicht sicher

Es bleibt eine Falle, und genau darauf weist dieser Artikel von Anfang an hin. Die Entscheidung für Linux und Open Source beseitigt zwar eine Abhängigkeit, bietet aber Sicherheit nicht als Gratisgeschenk. Ein souveränes Tool ist nicht von Haus aus sicher. Es muss weiterhin geprüft, gehärtet und gewartet werden – mit derselben Sorgfalt wie bei jeder proprietären Software, manchmal sogar noch mehr, da die Verantwortung nicht mehr an einen Hersteller ausgelagert wird.

Das staatliche E-Mail-System hat dies auf die harte Tour gelernt, als es feststellte, dass die französische Herkunft und der offene Quellcode keineswegs von der Arbeit an der Sicherheit entbinden. Ganz im Gegenteil: Die Freiheit, unter die Haube zu schauen, bringt die Pflicht mit sich, dies auch zu tun. Open Source macht Sicherheit überprüfbar, sie garantiert sie jedoch nicht. Wer nicht überprüft, bleibt in einer Abhängigkeit gefangen, von der er glaubte, sie beseitigt zu haben – und erhält obendrein die Illusion, geschützt zu sein.

Genau darin liegt die Bedeutung von „reicht nicht aus“. Linux ist eine Voraussetzung, keine Lösung. Die Lösung liegt darin, was man aus der Freiheit macht, die es ermöglicht: die Kompetenz, die man sich bewahrt, die Schichten, die man wirklich kontrolliert, und die Sicherheit, die man selbst übernimmt, anstatt sie zu delegieren.