Sie haben gestern einen Bug gemeldet. Ein Margin-Problem im Document-Renderer, fünfzehn Zeilen Kontext, zwei Screenshots. Sie haben mit Ihrem Klarnamen signiert. Ihr GitHub-Profil weist es aus; das Projekt, eine europäische Souveränitätsinitiative, schien Ihnen genau die Sorte Arbeit, die eine Signatur verdient.

Heute Morgen funktioniert Ihre Kreditkarte nicht mehr.

Diese Abfolge ist heute nicht dokumentiert. Sie ist die Form einer Abfolge, die die vergangenen achtzehn Monate Schritt für Schritt plausibler gemacht haben. Am 5. Mai 2025 versagte das Microsoft-365-Konto von Karim Khan, Chefankläger des Internationalen Strafgerichtshofs, nachdem die Trump-Regierung ihn unter Executive Order 14203 gelistet hatte. Im Mai 2026 übergab Microsoft die persönlichen Daten und Kommunikationen niederländischer Beamter — Aufsichtsbeamte, die den EU Digital Services Act vollziehen — auf eine Vorladung des US-Kongresses hin. In beiden Fällen hatten die Betroffenen Jahre zuvor einen in den USA ansässigen Dienstleister gewählt — auf der Grundlage einer zu jener Zeit vernünftigen institutionellen Beschaffung. Die politische Folge war eine Eigenschaft der Lieferkette, die niemand auditiert hatte.

Heute startet eine Allianz europäischer Unternehmen eine Alternative zu Microsoft 365. Die Pressemitteilung nennt es einen Meilenstein der europäischen digitalen Souveränität. Der Quellcode wird von Microsoft gehostet. Die Build-Pipeline läuft auf Microsofts Servern. Die Container-Images werden über Microsofts Container-Registry verteilt. Jeder Beitrag zur europäischen Souveränität wird im Moment seiner Einreichung in Microsofts Datenbank protokolliert — unter Ihrem Klarnamen.

Das ist kein Leak, kein Skandal, kein Versehen. Die Euro-Office-Repositorien unter github.com/euro-office sind offen einsehbar. Die Allianz hinter dem Start — IONOS, Nextcloud, EuroStack, Open-Xchange, XWiki, OpenProject und sechs weitere etablierte europäische OSS-Organisationen — hat dieses Hosting bewusst gewählt und hält es weiter für angemessen. Die Fachpresse-Berichterstattung zum heutigen Start erwähnt es nicht. Die Startkommunikation erwähnt es nicht. Das parallel entworfene Tech-Souveränitätspaket der Europäischen Kommission adressiert es nicht.

Man sollte es klar aussprechen: Das ist absurd. Nicht im umgangssprachlichen Sinn von überraschend — bei nüchterner Lektüre der öffentlichen Dokumentation ist es exakt das, was zu erwarten war — sondern in dem Sinn, dass jede Standarddefinition digitaler Souveränität, die der europäische Diskurs in den letzten vier Jahren hervorgebracht hat, mit dem, was eben passiert ist, unvereinbar ist. Entweder ist Euro-Office kein Souveränitätsprodukt, oder die kursierenden Souveränitätsdefinitionen sind nicht konsistent. Der Start erzwingt eine Entscheidung.

Die nützliche Version dieses Artikels ist nicht die Empörung, die sich von selbst schreibt. Sie ist das Audit, der Reframe und die Beschaffungsfrage, die folgen, sobald man akzeptiert: Der gegenwärtige Souveränitätsdiskurs hat einen tragenden Konstruktionsfehler — und der Bug-Report, den Sie gestern eingereicht haben, ist auf hinreichend langer Zeitachse Teil des Audit-Trails.

Was heute startet

Euro-Office veröffentlicht v1.0 am Dienstag, dem 9. Juni 2026. Die Allianz dahinter ist technisch kohärent: IONOS hostet die Managed-Cloud-Variante aus Karlsruhe, Nextcloud integriert die Suite in Hub 26 als neuen Default anstelle von Collabora, Open-Xchange bringt das Groupware-Erbe ein, und XWiki, OpenProject, Soverin, Abilian, BTactic und Office.eu steuern angrenzende Collaboration- und Hosting-Schichten bei.

Die vier primären Repositorien unter github.com/euro-office — eurooffice-nextcloud (PHP, AGPL-3.0), server (JavaScript, AGPL-3.0), sdkjs-forms (JavaScript, AGPL-3.0) und document-templates (Apache-2.0) — wählen die defensive Lizenzierungshaltung, die für als Dienst gehostete Software angemessen ist: Jeder kommerzielle Anbieter, der ein gehostetes Euro-Office anbietet, muss seine Modifikationen veröffentlichen. Apache-2.0 für die Templates ist die richtige Wahl für Inhalte. Das ist die stärkste Lizenzkombination auf dem europäischen Markt für OSS-Office-Suiten, materiell stärker als die MPL-2.0 von Collabora Online oder die Single-Vendor-AGPL von OnlyOffice.

Die Dateiformat-Kompatibilität zu Office Open XML hält bei den Workloads stand, an denen europäische OSS-Office-Migrationen historisch gescheitert sind: mehrblättrige Excel-Arbeitsmappen mit Pivot-Tabellen, Word-Dokumente mit Änderungsverfolgung und Kommentaren, PowerPoint mit eingebetteten Animationen. Die Deployment-Optionen reichen von Managed Cloud über Hybrid bis zu selbst gehostetem Docker oder Kubernetes, auf dem kundeneigenen Proxmox oder VMware. Die Laufzeit-Souveränitätsgeschichte ist real: Daten in deutschen Rechenzentren, Lizenzierung gegen Closed-Source-Forks geschützt, Formatunabhängigkeit vom Release-Takt von Microsoft.

An diesem Teil gibt es kein Sternchen. Das Produkt ist gut. Die Beschaffungsentscheidung als Produktentscheidung ist verteidigbar.

Das Audit

Die Beschaffungsentscheidung als Souveränitätsentscheidung ist der Punkt, an dem die Architektur aufhört mitzuspielen.

Jeder Commit in jedes Euro-Office-Repositorium, jedes Issue, jeder Pull-Request, jeder CI/CD-Pipeline-Lauf, jeder Container-Image-Build und jedes Release-Artefakt läuft über github.com. GitHub ist seit Juni 2018 hundertprozentige Tochter von Microsoft. Die Startkommunikation thematisiert das nicht. Die Fachpresse-Berichterstattung zum Start thematisiert es nicht. Die Allianz hat sich nicht auf einen Codeberg- oder Forgejo-Spiegel festgelegt und keine Absicht angekündigt, eine nicht-US-amerikanische Build-Pipeline zu betreiben.

Das ist kein vertragliches Problem — die AGPL-Lizenz wahrt das Recht, zu spiegeln, zu forken und neu zu bauen — es ist ein operatives Problem. Das Recht zu spiegeln ist wertlos, solange der Spiegel nicht existiert.

Der Vollzugspräzedenzfall ist dokumentiert und konkret. Im Juli 2019 beschränkte GitHub den Zugang zu privaten Repositorien und bezahlten Organisationskonten für Entwickler im Iran, in Syrien und auf der Krim, in Übereinstimmung mit den Sanktionen des OFAC. Private Projekte verschwanden über Nacht. Öffentliche Repositorien blieben im Nur-Lese-Modus erreichbar, aber die Arbeitsinfrastruktur — Issue-Tracker, Pull-Requests, GitHub Actions, Container-Images, Paketverteilung — war für betroffene Konten unzugänglich, bis GitHub im Januar 2021 eine OFAC-Lizenz erhielt, um den Dienst für iranische Entwickler wiederherzustellen. Im März und April 2022 griff derselbe Mechanismus gegen Einheiten in Russland und gegen die unter OFAC-Listung stehenden besetzten Teile der Ukraine. Konten, die mit sanktionierten Einheiten verbunden waren, verloren den Zugang; bezahlte Organisationskonten auf der Krim, in Donezk und Luhansk bleiben bis heute eingeschränkt. GitHubs Acceptable Use Policies führen weiterhin US-Exportkontroll-Compliance als maßgebliche Regel an.

Die Wahrscheinlichkeit, dass dieser Vollzugsmechanismus in einem beliebigen Quartal ein deutsches Stadtwerk oder einen französischen établissement public trifft, ist gering. Die Wahrscheinlichkeit über einen fünfjährigen Beschaffungshorizont, gegen einen Euro-Office-Stack mit mehreren hundert global gepflegten OSS-Upstream-Abhängigkeiten, liegt materiell über null. Die relevante Basisrate sind nicht die Schlagzeilenfälle — Iran, Russland, Krim — sondern der lange Schwanz: irgendeine einzelne kritische Abhängigkeit, gehostet von irgendeinem Entwickler in irgendeiner Jurisdiktion, die aus irgendeinem von Dutzenden plausibler Gründe innerhalb von fünf Jahren OFAC-relevant wird. Die meisten dieser Ereignisse werden Euro-Office-Anwender nicht treffen. Einige werden es.

Es gibt eine zweite Kategorie von Lieferketten-Exposition, die operativ wahrscheinlicher ist als Sanktionsdurchsetzung: politischer Druck auf den Plattformbetreiber, der in freiwillige Compliance umschlägt. Das Microsoft-Compliance-Muster 2025–2026 — die Suspendierung des E-Mail-Kontos des IStGH-Chefanklägers im Mai 2025 nach US-Sanktionen, die freiwillige Übergabe niederländischer Regulierernamen an den US-Kongress im Mai 2026 — gehört in diese Spalte. Wenn ein in den USA ansässiger Dienstleister unter US-politischen Druck gerät, lautet die Antwort Compliance, nicht Widerstand. GitHub ist dieselbe Architektur. Eine künftige US-Regierung, die entschiede, dass europäische Souveränitätsprojekte Aufmerksamkeit verdienen, bräuchte kein OFAC. GitHubs Acceptable Use Policies sind nach Ermessen der Plattform ausreichende Grundlage für Beschränkungen.

Die Audit-Schlussfolgerung ist schlicht und wenig schmeichelhaft: Eine Euro-Office-Einführung ohne SBOM, ohne Spiegelinfrastruktur und ohne Kontinuitätsplan ist architektonisch nicht souveräner als die M365-Installation, die sie ersetzt. Sie ist vertraglich souveräner — die Daten liegen in Karlsruhe, die Lizenz ist AGPL — aber die Lieferkette endet auf derselben Microsoft-eigenen Repository-Plattform, auf der auch die Quellverteilung von M365 enden würde, wenn der M365-Quellcode überhaupt verfügbar wäre, was er nicht ist.

Die Menschen im Audit

Das architektonische Argument hat das Risiko bisher institutionell behandelt — was passiert mit einem Stadtwerk, was passiert mit einer Beschaffungsentscheidung. Dasselbe Argument landet anders, wenn es bei Menschen beginnt, deren Namen dokumentiert sind.

Nehmen wir zunächst Khan. Der IStGH ist eine ständige internationale Institution mit Sitz in Den Haag, außerhalb US-amerikanischer Jurisdiktion. Dass die Kommunikation seines Chefanklägers über Microsoft 365 lief, war kein Zufall: Der Gerichtshof hatte dieselbe Beschaffungsentscheidung getroffen wie jeder andere große öffentliche Käufer in Europa, auf denselben damals vernünftigen Grundlagen. Als die Trump-Regierung Khan im Februar 2025 unter Executive Order 14203 listete, gab es weder für den Ankläger noch für das Gericht eine sinnvolle operative Option: Microsoft ist ein in den USA ansässiges Unternehmen, die OFAC-Pflicht ist bindend, die Suspendierung folgte. Die Beschaffungsentscheidung lag Jahre zurück; die Folge kam im Mai, namentlich zurechenbar und persönlich.

Der Fall ACM/AP unterscheidet sich von Khans Fall in einem wichtigen Punkt: Es gab keine Executive Order. Die Vorladung kam vom House Judiciary Weaponization Subcommittee von Jim Jordan, dessen erklärter Auftrag die Prüfung dessen ist, was es „foreign censorship of American speech" nennt — eine Formulierung, die nach eigenem Verständnis den EU Digital Services Act und die Arbeit der Beamten der Autoriteit Consument en Markt (ACM) und der Autoriteit Persoonsgegevens (AP) umfasst, deren Namen Microsoft herausgab. Die niederländische Staatssekretärin für digitale Souveränität, Willemijn Aerdts, bestellte den US-Botschafter an dem Freitag ein, an dem die Übergabe öffentlich wurde. Die Daten waren bereits unterwegs. Microsofts Compliance war im juristischen Sinn freiwillig — das Unternehmen reagierte auf eine Vorladung, nicht auf eine OFAC-Anordnung — und operativ ebenso unausweichlich, wie es die Compliance jedes US-ansässigen Dienstleisters unter demselben politischen Druck wäre.

Weder Khan noch das Personal von ACM und AP haben sich ausgesucht, an die Oberfläche US-politischen Drucks zu geraten. Sie haben Jahre zuvor Microsoft als Dienstleister gewählt, auf der Grundlage einer vollkommen vernünftigen institutionellen Beschaffung. Die politische Oberfläche war eine Eigenschaft der Lieferkette, die sie nicht auditiert hatten.

Auf dieser Ebene befinden sich nun die Mitwirkenden und Anwender von Euro-Office.

Jeder Entwickler, der einen Pull-Request gegen github.com/euro-office öffnet, erzeugt in Microsofts Datenbank einen Datensatz, der seine persönliche Identität — bei den meisten Konten der bürgerliche Name, eine reale E-Mail-Adresse, die IP-Adresse pro Sitzung, Zeitmuster der Beiträge — mit aktiver Teilnahme an einem europäischen Digitalsouveränitätsprojekt verknüpft, das Teile des US-Kongresses öffentlich als Bedrohung US-amerikanischer Handelsinteressen rahmen. Beruf, Arbeitgeber, Wohnsitzland und politische Zuordnung des Mitwirkenden lassen sich aus der öffentlichen Commit-Historie ableiten. Heute ist das Framing rhetorisch. Der Fall Khan und der Fall ACM/AP zeigen, dass die Lücke zwischen rhetorischer Rahmung und persönlicher Folge höchstens eine Executive Order breit ist.

Jede öffentliche Verwaltung, die Euro-Office einführt, erbt transitiv dieselbe Protokollkette. Jeder IT-Leiter, der ein Upstream-Issue kommentiert, sieht seine berufliche Position öffentlich mit dem Projekt verknüpft. Jeder Stadtwerke-Entwickler, der einen Bug-Report einreicht, hinterlässt seine Identität im Microsoft-Audit-Trail. Der kommunale CISO, der die Allianz für eine Sicherheitsklärung anschreibt, der Datenschutzbeauftragte, der einen Grenzfall der Exportkontrolle nachfragt — jede Interaktion wird unter einem Klarnamen aufgezeichnet, auf der Infrastruktur des Unternehmens, von dem das Projekt wegmigrieren soll.

Nichts davon ist böswillig von Microsoft. Es ist die schlichte Mechanik des Betriebs eines Code-Hosting-Dienstes. Es ist zugleich die schlichte Mechanik einer künftigen Vorladung. Der Fall Khan zeigt, was geschieht, wenn eine US-Executive-Order eine Person nennt. Der Fall ACM/AP zeigt, was geschieht, wenn eine Vorladung des US-Kongresses eine Kategorie nennt. In beiden Fällen erfuhren die Betroffenen davon, nachdem Microsoft bereits geliefert hatte.

Die strategische Implikation ist nüchtern. Wer — individuell oder institutionell — am europäischen Souveränitätsprojekt auf Mitwirkenden- oder Anwenderebene teilnimmt, solange es auf Microsoft-Infrastruktur gehostet wird, erzeugt einen Audit-Trail unter dem eigenen Namen, auf der Plattform jener Partei, von der das Projekt die Abhängigkeit reduzieren soll. Der Trail entsteht heute, in Echtzeit, mit jedem Commit und jedem Issue-Kommentar. Die Partei, die Zugriff auf den Trail hat, muss nicht handeln, damit er tragend wird — er muss nur existieren.

Orwell hätte die Architektur gewürdigt. Eine Bewegung organisiert sich, um ihre Abhängigkeit von einer Entität zu verringern. Dafür unterschreibt jeder Teilnehmer seinen Beitrag, unter Klarnamen, auf einer Plattform, die der Entität gehört. Die Entität bewahrt die Unterschriften auf unabsehbare Zeit auf, durchsuchbar, exportierbar auf rechtliche Anforderung. Ob die Entität jemals handelt, ist mittelfristig zweitrangig; ob die Architektur ihr das Handeln erlaubt, ist mittelfristig entschieden. Es wird jetzt entschieden, mit jedem Issue-Ticket, von jedem, der auf Absenden klickt.

Souveränität ist nichts, was Sie kaufen

Das ist der Reframe, dem nach diesem Start kaum noch auszuweichen ist.

Die Beschaffungsindustrie hat die Frage als Lieferantenauswahl trainiert. Die DSGVO, der CLOUD Act, das Tech-Souveränitätspaket, die §58-VgV-Novelle, das ES³-Reifegradmodell — all diese Instrumente akzeptieren die Annahme, Souveränität sei eine Eigenschaft, die der Käufer durch die Wahl des richtigen Lieferanten erwirbt. ES³ zertifiziert Lieferanten. CADA klassifiziert Lieferanten. §58 VgV erlaubt Käufern, bestimmte Lieferanten zu bevorzugen. Innerhalb dieser Annahme sind die Instrumente kohärent.

Der Euro-Office-Start ist der sauberste Fall, in dem diese Annahme sichtbar versagt. Das Produkt ist die beste verfügbare Antwort auf die Lieferantenfrage. Wer es ohne architektonische Arbeit einführt, ändert nur den Lieferanten in der Beschaffungszeile und lässt die tatsächliche Abhängigkeit unangetastet. Der Lieferant in der Zeile ist jetzt europäisch; die Lieferkette, von der dieser Lieferant abhängt, ist es nicht. Der Käufer hat den Anschein der Souveränität ohne die Substanz erworben — und die Substanz, die Kontinuität der Lieferkette, stand im Beschaffungsvertrag nie zur Verfügung.

Souveränität, in dem Sinn, der für die Frage relevant ist, die öffentliche und regulierte private Käufer eigentlich beantworten wollen, ist keine Eigenschaft von Lieferanten. Sie ist eine Eigenschaft von Architekturen. Eine Organisation ist digital souverän in dem Maß, in dem sie weiterarbeiten kann, wenn ein beliebiges einzelnes Stück ihrer Software-Lieferkette ausfällt. Diese Eigenschaft wird gebaut, nicht gekauft. Die Lieferantenentscheidung liegt vorgelagert; die Arbeit des Souverän-Werdens liegt nachgelagert. Die nachgelagerte Arbeit zu überspringen und die vorgelagerte Entscheidung als Souveränitätsantwort zu deklarieren — das ist der Fehler, den der Euro-Office-Start unübersehbar macht.

Die praktische Konsequenz: Der Microsoft 365-Stack und der Euro-Office-Stack sind auf der Lieferketten-Dimension strukturell nicht verschieden. Sie unterscheiden sich auf der Laufzeit-Dimension (Datenort, Jurisdiktion des Betreibers), und sie unterscheiden sich in der Option, Lieferketten-Unabhängigkeit aufzubauen. M365 schließt die Option aus; Euro-Office bewahrt sie. Eine Option zu bewahren ist aber nicht dasselbe, wie sie auszuüben. Das Ausüben ist die Arbeit.

Die Beschaffungsfrage, die wirklich zählt

Wenn die Souveränitätsfrage richtigerweise architektonisch ist, folgt die Beschaffungsfrage daraus. Sie lautet nicht mehr bei welchem Lieferanten kaufen wir? Sie wird zu: Wie sieht unsere Architektur der Unabhängigkeit aus, und wo steht sie in unserer GuV?

Drei Arbeitspakete beantworten die neu gerahmte Frage. Sie sind nicht optional, sie sind nicht „nice to have", und jede Souveränitätsbeschaffung, die sie auslässt, ist eine Beschaffungs-Inszenierung, keine Beschaffungsentscheidung.

Eins: Bestandsaufnahme. Ein Software-Bill-of-Materials-Audit der aktuellen produktiven OSS-Komponenten, mit Geltungsbereich für jedes System mit Laufzeit-Exposition zu Internet oder Kundendaten. Output pro Komponente: primärer Distributionsendpunkt, Lizenz, Tiefe des Abhängigkeitsbaums, Jurisdiktion des Maintainers. Für eine mittelgroße Organisation mit 50–80 distinkten OSS-Komponenten in Produktion dauert das Audit 6–10 Wochen und kostet bei einem externen Spezialisten 25.000–55.000 Euro. Das Ergebnis ist eine Liste, kein Plan; der Plan ergibt sich aus der Liste. Die meisten Organisationen entdecken, dass 80 % ihrer Lieferketten-Exposition sich auf 15 % ihrer Komponenten konzentriert — und dass die Konzentration nicht dort liegt, wo sie sie erwartet haben.

Zwei: Spiegelinfrastruktur. Eine selbst gehostete Forgejo-Instanz, bidirektional synchronisiert mit GitHub für die in Arbeitspaket eins identifizierten kritischen Komponenten. Gehostet in vorhandener Infrastruktur (Proxmox, VMware oder einer Hetzner-VM), zwei VMs, getrennt von der Produktion. Die Cash-Kosten sind vernachlässigbar; die Arbeit umfasst 8–15 Personentage Architektenzeit über zwölf Wochen, abhängig von der Repository-Anzahl. Der Spiegel ersetzt GitHub nicht für die tägliche Entwicklung; er überlebt GitHub für die Kontinuität. Codeberg kann substituieren, wo Forgejo-Selbsthosting nicht gerechtfertigt ist.

Drei: Pilot. Ein eingegrenzter Euro-Office-Pilot auf einem Workflow ohne öffentliche Exposition — Finanzen, internes HR, kontrollierte Groupware — mit Laufzeit 6–12 Monate und expliziten Go-/No-Go-Kriterien, die an das Erreichen produktiver Zuverlässigkeit der Spiegelinfrastruktur gekoppelt sind. Kosten: 8.000–20.000 Euro Setup-Unterstützung durch einen Nextcloud-Partner plus interne Zeit. Der Pilot validiert das Produkt; Arbeitspakete eins und zwei validieren die Souveränität.

Ein Käufer, der alle drei durchführt, hat Euro-Office gekauft und Souveränität gebaut. Ein Käufer, der nur Arbeitspaket drei durchführt, hat einen anderen Lieferanten gekauft. Die Beschaffungsentscheidung ist in beiden Fällen dieselbe. Die Architekturentscheidung ist es nicht.

Die strategische Positionierungsfrage für die nächsten zwölf Monate ist nicht, ob Euro-Office das richtige Produkt ist. Sie ist, ob Ihre Organisation bereit ist, Souveränität als Architektur statt als Beschaffung zu behandeln — und ob Ihr Vorstand, Ihre Auditoren und Ihre Regulierer die Architekturantwort als Souveränitätsantwort akzeptieren werden. Sie werden es zunehmend tun. Das Tech-Souveränitätspaket schlägt eine CADA-konforme Klassifizierung bis 2027 vor. ES³ zertifiziert bereits Methodik statt Produkte. Die Signale aus der regulatorischen Schicht konvergieren auf Architektur, nicht auf Lieferantenlogo. Das Lieferantenlogo ist der nachlaufende Indikator; die Architektur ist der vorlaufende.

Was dieser Artikel nicht ist

Es ist keine Behauptung, Euro-Office sei die falsche Wahl. Das Produkt ist die stärkste Open-Source-Alternative zu M365 auf dem europäischen Markt. Es ist keine Behauptung, GitHub werde EU-Entwickler blockieren. Es ist die Behauptung, dass Souveränität als Beschaffungskategorie das falsche Frame ist, dass der Euro-Office-Start das sauberste verfügbare Beispiel dafür ist und dass die Arbeit, die das Frame verdeckt hat, die eigentliche Antwort auf die Frage ist, die öffentliche und regulierte private Käufer zu stellen versuchen.

Quellen

Themenübersicht: Digitale Souveränität in Europa Verwandte Artikel: EU-Tech-Souveränitätspaket, Microsoft liefert NL-Beamte aus