Open Source und Unternehmenssicherheit: Kontrolle statt Vertrauen

Proprietäre Software ist für die meisten Organisationen eine Blackbox. Man installiert sie, man vertraut ihr, und dieses Vertrauen muss man aufbringen, ohne je hineingeschaut zu haben. Wie die Software mit den eigenen Daten umgeht, welche Verbindungen sie nach außen aufbaut, wo eine Schwachstelle schlummert, all das weiß der Hersteller, und im Zweifel wissen es auch Angreifer besser als der Betreiber selbst. Sicherheit bedeutet in dieser Konstellation vor allem eines: darauf zu hoffen, dass ein anderer seine Hausaufgaben gemacht hat.

Open Source verspricht, dieses Verhältnis umzudrehen. Wenn der Quellcode offenliegt, wird aus der Blackbox eine Whitebox, und aus erzwungenem Vertrauen wird prüfbares Vertrauen. Das Versprechen wiegt schwer, und es erklärt, warum gerade in Europa eine ganze Reihe von Behörden und Organisationen den Umstieg wagt. Doch Kontrolle ist nichts, was einem eine offene Lizenz von selbst verschafft. Sie ist eine Treppe, und wie weit man auf ihr nach oben kommt, entscheidet nicht das Lizenzmodell allein, sondern die eigene Fähigkeit, jede Stufe auch tatsächlich zu betreten. Genau darum geht es hier. Nicht um die schlichte Frage, ob Open Source sicherer ist, sondern um die ehrlichere Frage, wie weit die Kontrolle wirklich reicht, die es verspricht.

Sicherheit ist Kontrolle über die eigene Angriffsfläche

Wer Sicherheit in den Kategorien eines Managementsystems denkt, landet schnell bei den drei Schutzzielen Vertraulichkeit, Verfügbarkeit und Integrität. Sie beschreiben, was zu schützen ist, aber nicht, wovon der Schutz abhängt. Und hier kommt ein Faktor ins Spiel, der leicht übersehen wird: die Abhängigkeit selbst. Wer eine Software nicht einsehen, nicht anpassen und nicht ohne den Hersteller betreiben kann, hat einen Teil seiner Angriffsfläche an einen Dritten delegiert. Fällt dieser Dritte aus, ändert er seine Bedingungen oder unterliegt er einer fremden Rechtsordnung, dann sind die eigenen Schutzziele plötzlich von Entscheidungen abhängig, auf die man keinen Einfluss hat. Abhängigkeit ist damit nicht nur ein wirtschaftliches Thema, sie ist ein eigenständiges Sicherheitsrisiko.

Genau hier setzt das Sicherheitsargument für Open Source an. Die Unterscheidung zwischen Blackbox und Whitebox ist in der Informationssicherheit ohnehin geläufig, etwa beim Blackbox- und Whitebox-Testing, bei dem der Prüfer eine Software einmal ohne und einmal mit Kenntnis des inneren Aufbaus untersucht. Auf die Frage, welche Software man einkauft, überträgt ein Beitrag im Handelsblatt zu Open Source diese Denkweise: Bei eingekaufter Software bleibt der Support des Herstellers der einzige Hebel, wenn etwas nicht stimmt, während offener Code die eigene Prüfung erlaubt. Liegt der Quellcode vor, lassen sich Schwachstellen identifizieren und fehlerhafter Code korrigieren, entsprechende Kompetenz vorausgesetzt. Tom Ritter vom Fraunhofer-Institut FOKUS wird dort mit dem Hinweis zitiert, dass moderne KI-Werkzeuge die Analyse von Code auf Schwachstellen heute deutlich erleichtern, was die Einstiegshürde für diese Prüfung senkt. Das Geld, das nicht in Lizenzen fließt, kann stattdessen in eigene Sicherheits- und Programmierkompetenz gehen.

Dass dieser Gedanke keine Nischenmeinung mehr ist, zeigt der Open Source Monitor 2025 des Bitkom. Fast drei Viertel der Unternehmen in Deutschland setzen mittlerweile Open Source ein. Interessant ist die Reihenfolge der Motive, denn sie mahnt zur Ehrlichkeit: Der meistgenannte Vorteil ist die Kostenersparnis, erst danach folgt der Zugriff auf den Quellcode. Sicherheit ist selten der primäre Beweggrund, sondern eher ein struktureller Nebeneffekt der Offenheit. Zugleich sieht ebenfalls fast drei Viertel in Open Source eine Chance für mehr digitale Souveränität. Die Motive Kosten, Kontrolle und Unabhängigkeit sind also längst zusammengewachsen.

Kontrolle ist eine Treppe, keine Tür

Die entscheidende Einsicht ist, dass Offenheit nicht gleich Kontrolle bedeutet. Kontrolle entsteht in Stufen, und jede höhere Stufe verlangt mehr als die darunter.

Die erste Stufe ist die Einsicht. Man darf den Code lesen. Das ist die reine Transparenz, die Verwandlung der Blackbox in eine Whitebox, und sie kostet zunächst nichts außer der Bereitschaft, hineinzuschauen. Die zweite Stufe ist die Prüfung. Lesen dürfen und beurteilen können sind zwei verschiedene Dinge. Wer eine Schwachstelle erkennen, verstecktes Sende-Verhalten aufspüren oder die Qualität eines Verschlüsselungs-Bausteins einschätzen will, braucht Fachwissen, Werkzeuge und Zeit. Die dritte Stufe ist die Änderung. Erst wer patchen und die eigene Fassung ausrollen darf, ist vom Fahrplan eines Herstellers unabhängig. Diese Unabhängigkeit ist allerdings nur verlagert, denn nun hängt es am eigenen Team oder an einer Gemeinschaft von Mitwirkenden, ob und wie schnell eine Korrektur entsteht. Die vierte Stufe schließlich ist die Lieferkette. Hier geht es nicht mehr um den Code, den man sieht, sondern um die Frage, woher er stammt, welche Abhängigkeiten er mitbringt und wer sie pflegt.

Diese Treppe ist der rote Faden für alles Weitere. Bei proprietärer Software steht man auf der untersten Stufe, man muss vertrauen. Open Source macht die höheren Stufen begehbar, aber es trägt einen nicht hinauf. Und wie sich zeigen wird, entscheidet gerade der Sprung von der ersten auf die zweite Stufe darüber, ob die Offenheit zu echter Sicherheit führt oder nur zu einem beruhigenden Gefühl.

Die Treppe der Kontrolle. Open Source macht die Stufen eins bis vier begehbar, die oberste Stufe der Betriebs- und Datenhoheit ist Thema des Folgeartikels.

Die Lizenz als Fundament

Bevor es um Prüfung und Lieferkette geht, lohnt ein Blick auf das rechtliche Fundament, auf dem die gesamte Treppe ruht. Denn ob man Code ändern, weitergeben und selbst betreiben darf, das steht nicht im Code, sondern in der Lizenz. Eine Whitebox, die man ansehen, aber nicht anfassen darf, ist nur die halbe Kontrolle. Der oft belächelte Lizenzdschungel ist deshalb kein Randthema, sondern die Statik des Ganzen.

Grob lassen sich drei Familien unterscheiden. Permissive Lizenzen wie die MIT-Lizenz, die BSD-Lizenz und die Apache-Lizenz 2.0 erlauben nahezu alles, bis hin dazu, den Code später in einem geschlossenen, proprietären Produkt zu verwenden, solange die ursprünglichen Urhebervermerke erhalten bleiben. Copyleft-Lizenzen wie die GNU General Public License (GPL), ihre schwächere Variante LGPL und die von der Open Source Initiative anerkannte GNU Affero General Public License (AGPL) verlangen dagegen, dass Änderungen unter derselben Lizenz offen bleiben. Die AGPL geht dabei am weitesten, denn sie löst diese Pflicht sogar dann aus, wenn die Software gar nicht weitergegeben, sondern nur als Dienst über ein Netzwerk bereitgestellt wird. Damit schließt sie die bei Cloud-Angeboten verbreitete Lücke, dass ein Anbieter offenen Code nutzt, ohne seine Änderungen je offenlegen zu müssen. Und dann gibt es eine dritte, sicherheitspolitisch heikle Kategorie, die sogenannten source-available-Lizenzen wie die Business Source License (BSL) oder die Server Side Public License (SSPL). Sie gewähren Einsicht in den Code, gelten aber ausdrücklich nicht als Open Source im Sinne der Open Source Initiative, weil sie die kommerzielle Nutzung beschränken. Wer hier nicht genau hinsieht, verwechselt sichtbaren Code mit offener Lizenz, und das ist ein folgenreicher Irrtum.

Wie real dieser Unterschied ist, hat die Welle an Lizenzwechseln der vergangenen Jahre vorgeführt, und sie ist zugleich eine Lehrstunde zur Leitfrage dieses Artikels. Als HashiCorp die Lizenz von Terraform 2023 auf die Business Source License umstellte, spaltete die Gemeinschaft das Projekt kurzerhand ab und führte es als OpenTofu offen weiter. Eine solche Abspaltung wird im Fachjargon Fork genannt, also eine eigenständige Weiterentwicklung des Quellcodes unter neuem Namen. Als Redis 2024 zur Server Side Public License wechselte, entstand mit Valkey ein von großen Cloud-Anbietern getragener offener Fork, und Redis kehrte später selbst wieder zu einer offenen Lizenz zurück. Und als Elasticsearch bereits 2021 auf die SSPL gegangen war, spaltete Amazon es als OpenSearch unter der Apache-Lizenz 2.0 ab. Die Lehre ist unbequem: Selbst offene Kontrolle kann teilweise widerrufen werden, wenn ein Hersteller die Lizenz unter den Nutzern ändert. Der einzige verlässliche Rückversicherer gegen diesen Fall ist das Recht, einen Fork zu erstellen, und dieses Recht hängt wiederum allein an der Lizenz. Wer Kontrolle will, muss die Lizenz also genauso ernst nehmen wie den Code. Dass unklare Gewährleistung und Lizenzrecht im Bitkom-Monitor zu den größten Hürden zählen, ist vor diesem Hintergrund kein Zufall, sondern der Preis dieser Kontrolle.

Warum gerade Europa jetzt umsteigt

Die Theorie der Kontrolle wird derzeit in großem Maßstab in der Praxis erprobt, und viele der jüngsten Beispiele stammen aus Europa. Der gemeinsame Nenner liegt wieder bei der Abhängigkeit, diesmal auf der Ebene des Rechtsraums. Wer geschäftskritische Software eines außereuropäischen Anbieters betreibt, unterliegt am Ende auch der Rechtsordnung des Herstellerlandes und dessen unternehmerischen wie politischen Entscheidungen. Wie schnell das konkret werden kann, führten zuletzt zwei Fälle vor Augen. Nachdem die US-Regierung Anfang 2025 Sanktionen gegen den Chefankläger des Internationalen Strafgerichtshofs verhängt hatte, soll Microsoft dessen E-Mail-Konto gesperrt haben, sodass der Ankläger auf den Schweizer E-Mail-Dienst Proton Mail auswich. Microsoft bestreitet diese Darstellung, doch der Gerichtshof wendet sich seither von Microsoft ab und dem offenen openDesk zu. Und das KI-Modell Fable 5 von Anthropic war zeitweise gar nicht mehr verfügbar, weil US-Exportauflagen es für rund zwei Wochen ausbremsten, bis diese wieder aufgehoben wurden. In beiden Fällen entschied nicht der Nutzer über die Verfügbarkeit seiner Werkzeuge, sondern eine Regierung.

Das vielleicht deutlichste Beispiel einer bewussten Konsequenz daraus liefert die Schweizer Armee. Ihr Kommando Cyber verabschiedet sich von Microsoft und stellt bis Oktober 2026 auf die offene Alternative openDesk um. Die Begründung liest sich wie ein Lehrbuch der Schutzziele: Ein zunehmend in die eigene Cloud gedrängtes Office-Paket erfülle die höchsten Anforderungen an Vertraulichkeit, Verfügbarkeit und Integrität nicht mehr. Der Leiter des Kommandos, Simon Müller, bringt es auf den Punkt, dass Anbieter, die Gesetzen wie dem US-amerikanischen CLOUD Act unterliegen, für bestimmte militärische Zusammenhänge schlicht nicht mehr nutzbar seien. Bemerkenswert ist, dass die Armee nicht nur konsumiert, sondern als Beitragende auftritt und eigene Werkzeuge offen veröffentlicht, was sie auf der Kontrolltreppe bis in die oberen Stufen führt.

Auf ziviler Ebene ist unter den deutschen Bundesländern Schleswig-Holstein am weitesten fortgeschritten. Rund vier Fünftel der Arbeitsplätze laufen dort bereits auf LibreOffice, Zehntausende Postfächer sind auf eine offene Groupware migriert, am Horizont steht der Wechsel von Windows auf Linux, und das Land beziffert die Einsparung bei den Lizenzkosten auf einen zweistelligen Millionenbetrag. Das Beispiel zeigt, dass Souveränität und Wirtschaftlichkeit keine Gegensätze sein müssen. Mecklenburg-Vorpommern wiederum steht für den pragmatisch gestuften Weg. Dort ersetzt zunächst die offene Plattform Nextcloud, die das Land nach eigenen Angaben selbst kontrollieren und prüfen kann, die bisherige Kollaborationslösung, mittelfristig für über 50.000 Beschäftigte. Der lokal kontrollierte Verwaltungs-Chatbot LEA auf Basis der offenen Software OpenWebUI setzt zudem auf europäische Sprachmodelle wie Mistral aus Frankreich und Tilde aus Lettland statt auf US-Dienste wie OpenAI, während der Abschied von Windows ausdrücklich keine kurzfristige Priorität hat. Das ist keine Halbherzigkeit, sondern die realistische Einsicht, dass Fachverfahren tief verzahnt sind und Migration Zeit braucht.

Über die deutschen Grenzen hinaus zeigt sich dieselbe Bewegung. Dänemark hat in seinem Digitalministerium den Ausstieg aus Microsoft Office eingeleitet, getrieben nicht zuletzt von der geopolitischen Sorge, im Konfliktfall könnte der Zugriff auf Dienste außereuropäischer Anbieter zum Druckmittel werden. Hier ist eine Nuance wichtig: Beim Office-Paket ist Dänemark konsequent, beim Betriebssystem fällt der Umstieg zögerlicher aus. Das widerlegt die These nicht, es zeigt nur, dass die höheren Stufen der Ablösung schwerer zu erreichen sind. Dass der Ansatz auch langfristig tragen kann, belegt Frankreich, dessen Gendarmerie mit dem Ubuntu-Derivat GendBuntu schon seit rund anderthalb Jahrzehnten Zehntausende Arbeitsplätze betreibt. Das österreichische Bundesheer migriert ebenfalls auf LibreOffice. Damit nicht jede Verwaltung diese Aufgabe für sich allein bewältigen muss, entsteht mit openDesk vom Zentrum für Digitale Souveränität ein bundesfinanzierter, offener Unterbau, den mehrere Stellen gemeinsam nutzen können, vom deutschen öffentlichen Sektor über die Schweizer Armee bis hin zum Internationalen Strafgerichtshof.

Wie weit die Kontrolle wirklich reicht

An dieser Stelle lohnt ein ehrlicher Schritt zurück. Das Sicherheitsargument wird oft so zugespitzt, dass es mehr verspricht, als es halten kann. Die bekannteste Formel stammt von Eric Raymond und besagt sinngemäß, dass jeder Fehler schnell entdeckt wird, sobald nur genügend Augenpaare auf den Code schauen. Dieses nach Linus Torvalds benannte Prinzip ist ein Ideal, kein Automatismus. Es beschreibt, was geschehen kann, wenn viele kompetente Menschen tatsächlich hinsehen, nicht was zwangsläufig passiert, nur weil der Code offenliegt.

Zwei Fälle haben das eindrücklich vorgeführt. Der Heartbleed-Fehler steckte 2014 rund zwei Jahre lang unentdeckt in OpenSSL, einer Verschlüsselungsbibliothek, auf die ein Großteil aller Webserver angewiesen war, gepflegt aber nur von einer Handvoll Menschen. Viele nutzten den Code, kaum jemand prüfte ihn. Noch beunruhigender ist die Hintertür in xz-utils aus dem Jahr 2024. Hier hatte sich ein Angreifer über zweieinhalb Jahre hinweg mit geduldiger Mitarbeit das Vertrauen und schließlich die Rechte an einem weit verbreiteten Kompressionswerkzeug erschlichen, um eine Hintertür einzuschleusen, die praktisch jeden betroffenen Linux-Server angreifbar gemacht hätte. Aufgefallen ist die Sache nicht durch ein systematisches Audit, sondern durch den Zufall, dass einem einzelnen Entwickler eine minimale Verzögerung beim Anmelden verdächtig vorkam.

Die Lehre aus beiden Fällen ist dieselbe, und sie ist die ehrliche Antwort auf die Titelfrage. Transparenz ist eine notwendige, aber keine hinreichende Bedingung für Sicherheit. Offenheit allein sorgt nicht dafür, dass tatsächlich jemand prüft. Und beide Fälle zeigen ein strukturelles Problem, das mit Technik wenig zu tun hat: Kritische Bausteine der digitalen Welt ruhen oft auf den Schultern weniger, schlecht bezahlter und überlasteter Freiwilliger. Kontrolle reicht am Ende exakt so weit, wie die Fähigkeit reicht, sie auszuüben, und diese Fähigkeit ist eine Frage von Personal, Prozessen und Geld. Der Bitkom-Monitor nennt den Mangel an Fachkräften folgerichtig als größte Hürde, noch vor allen rechtlichen Bedenken.

Dass die Kontrolle nicht an der Technik scheitert, sondern an der Organisation, hat kein Beispiel deutlicher gezeigt als München. Das Projekt LiMux migrierte ab 2004 einen Großteil der städtischen Arbeitsplätze auf Linux, wurde 2017 zugunsten einer Rückkehr zu Microsoft wieder aufgegeben und mündet seit einigen Jahren erneut in einen vorsichtigen Kurs Richtung offene Software. Gescheitert ist es selten an der Technik, sondern an der Zusammenarbeit mit einer von Microsoft-Formaten geprägten Umwelt, an der Steuerung des Projekts und am schwankenden politischen Willen. Wer heute umsteigt, gewinnt Kontrolle, aber er bekommt sie nicht als fertiges Produkt, sondern als Daueraufgabe.

Wie das Ökosystem den Boden anhebt

Man könnte an dieser Stelle resigniert schließen, offener Code allein bringe also wenig, doch das wäre die halbe Wahrheit. Denn genau auf die Schwächen, die Heartbleed und xz offengelegt haben, antwortet das Ökosystem inzwischen mit eigenen Institutionen, und dieser Teil der Geschichte wird zu selten erzählt.

Die erste Antwort sind die Stiftungen. Wenn ein Projekt wie Kubernetes unter dem Dach der Cloud Native Computing Foundation den Reifegrad graduated erreicht, dann steht dahinter ein unabhängiges Sicherheitsaudit, eine dokumentierte Steuerung, ein geregelter Prozess für die Aufnahme und den Abschied von Mitwirkenden sowie eine breite Basis an Beitragenden. Aus dem blinden Vertrauen in eine einzelne Person wird so ein prüfbares Verfahren. Die Trägerschaft durch eine Stiftung wird damit selbst zu einem Signal für die Vertrauenswürdigkeit der Lieferkette, also für die vierte Stufe der Kontrolltreppe. Ein Nebeneffekt ist, dass die riesige Übersichtskarte all dieser Projekte, die sogenannte CNCF Landscape, zugleich hilft, den Wildwuchs zu ordnen, ganz ähnlich wie ein klarer Lizenzkatalog den Lizenzdschungel lichtet.

Näher am Sicherheitskern liegt die Open Source Security Foundation, kurz OpenSSF, ebenfalls unter dem Dach der Linux Foundation. Ihr Vorläufer entstand als direkte Reaktion auf Heartbleed, um kritische Projekte wie OpenSSL überhaupt erst auf ein finanziell tragfähiges Fundament zu stellen. Aus dieser Linie sind konkrete Werkzeuge hervorgegangen, mit denen sich die vierte Stufe tatsächlich begehen lässt: die Scorecard, die die Sicherheitspraxis eines Projekts automatisiert bewertet, das Rahmenwerk SLSA, also die Supply-chain Levels for Software Artifacts, das die nachweisbare Herkunft von Software-Bausteinen beschreibt, und Sigstore für deren Signatur und Überprüfung. Die staatliche Flanke dazu bildet in Deutschland die Sovereign Tech Agency, eine aus dem Bundeshaushalt finanzierte Einrichtung des Bundes, angesiedelt bei der Bundesagentur für Sprunginnovationen SPRIND. Sie fördert seit 2022 aus Steuermitteln kritische offene Infrastruktur und adressiert mit dem Modell des Maintainer-in-Residence genau die menschliche Wartungslast, die xz so schmerzhaft sichtbar gemacht hat.

Die dritte Antwort kommt aus der Regulierung. Der Cyber Resilience Act (CRA) ist dabei keine Schöpfung der ENISA, sondern eine Verordnung der Europäischen Union. Die ENISA, die Agentur der Europäischen Union für Cybersicherheit, betreibt lediglich die zentrale Meldeplattform. Der CRA verpflichtet Hersteller von Produkten mit digitalen Elementen künftig zu grundlegenden Sicherheitsanforderungen, zu Sicherheitsupdates über den Lebenszyklus, zu einer koordinierten Meldung von Schwachstellen über die Plattform der ENISA und zur Führung einer Stückliste aller verbauten Software-Bestandteile, im Fachjargon Software Bill of Materials (SBOM) genannt. In Kraft ist die Verordnung seit Ende 2024, die Meldepflichten greifen ab September 2026, der Hauptteil der Pflichten ab Dezember 2027.

Beim Thema SBOM lohnt eine Präzisierung, die die These dieses Artikels stützt, statt sie zu widerlegen. Eine SBOM ist eine maschinenlesbare Inventarliste der Bestandteile in einem etablierten Format wie CycloneDX oder SPDX, die zumindest die direkten Abhängigkeiten erfasst. Sie ist nach heutigem Stand vor allem Teil der technischen Dokumentation, muss also nicht automatisch an jeden Kunden ausgeliefert werden, sondern kann von den Aufsichtsbehörden angefordert werden. Vor allem aber ist sie ein Inventar, kein Schutzschild. Sie beschleunigt die Antwort auf die Frage, ob man von einer neu entdeckten Schwachstelle betroffen ist, sie behebt aber keine einzige davon. Transparenz über die Bestandteile ist notwendig, nicht hinreichend, und damit landet auch der CRA genau auf der Linie der Kontrolltreppe. Wer die deutsche Ausgestaltung dieser Anforderungen sucht, findet sie in der technischen Richtlinie TR-03183 des Bundesamts für Sicherheit in der Informationstechnik (BSI), die den CRA und speziell das SBOM-Format konkretisiert, ausdrücklich als Hilfestellung und nicht als bindende Vorschrift.

Bemerkenswert ist schließlich, wie der CRA mit Open Source umgeht, denn hier schließt sich der Kreis zum Wartungsproblem. Der erste Entwurf hatte in der Gemeinschaft große Sorge ausgelöst, ehrenamtliche Entwickler könnten für Fehler in fremden Endprodukten haften, was genau die Menschen abgeschreckt hätte, auf deren unbezahlter Arbeit die Lieferkette ruht. Der Kompromiss nimmt rein nicht kommerzielle Open Source aus dem Anwendungsbereich und schafft die neue Rolle des Open-Source-Stewards für Stiftungen und Einrichtungen, die offene Software tragen, mit leichteren Pflichten und ohne Bußgelder. Die Regulierung erkennt damit an, was die Vorfälle gelehrt haben, dass nämlich die menschliche Substanz hinter dem Code selbst ein schützenswertes Gut ist.

Fazit

Am Ende steht keine Parole, sondern eine nüchterne Bilanz. Open Source macht Software nicht von selbst sicher, und wer das behauptet, verwechselt eine Möglichkeit mit einer Garantie. Was Open Source tut, ist etwas Wertvolleres und zugleich Anspruchsvolleres: Es verwandelt erzwungenes Vertrauen in prüfbares und verdienbares Vertrauen. Die Blackbox wird zur Whitebox, die Abhängigkeit vom Wohlwollen eines Herstellers wird zur eigenen Gestaltungsmöglichkeit, und die Kontrolle über die eigenen Schutzziele kehrt zurück, Stufe um Stufe, von der Einsicht über die Prüfung und die Änderung bis zur Lieferkette.

Doch jede dieser Stufen verlangt etwas. Sie verlangt die richtige Lizenz als Fundament, sie verlangt Personal und Prozesse, um aus dem Recht zu prüfen ein tatsächliches Prüfen zu machen, und sie verlangt die Bereitschaft, die menschliche Wartungslast ernst zu nehmen, statt sie stillschweigend Freiwilligen aufzubürden. Die gute Nachricht ist, dass Ökosystem und Gesetzgeber diesen Boden gerade anheben, durch Stiftungen, durch Werkzeuge für die Lieferkette und durch eine Regulierung, die die richtigen Fragen stellt. Gerade für Europa ist das mehr als eine technische Wahl. Es ist die Entscheidung, die Kontrolle über die eigene digitale Grundlage nicht dauerhaft an fremde Rechtsräume zu delegieren.

Eine Stufe hat dieser Artikel bewusst ausgespart. Selbst der am gründlichsten geprüfte und selbst gepflegte offene Stack nützt wenig, wenn er in einer Infrastruktur läuft, über die rechtlich oder physisch ein Dritter herrscht. Wo die Software liegt, wer auf sie zugreifen kann und unter welcher Rechtsordnung sie betrieben wird, das ist die oberste Stufe der Kontrolle. Und sie ist das Thema des nächsten Artikels über die souveräne Cloud.