„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