Die EU stellt Open Source ins Zentrum der europäischen Technologiesouveränität. Wir sind bereit.
Die Zahl, die jeden europäischen CIO aufhorchen lassen sollte
Kürzlich veröffentlichte die Europäische Kommission das European Technological Sovereignty Package. Es umfasst das Chips Act 2.0, das Cloud and AI Development Act, eine strategische Roadmap für Digitalisierung und KI im Energiesektor sowie erstmals in der Geschichte der EU-Digitalpolitik eine vollständige EU-Open-Source-Strategie.
Die wichtigste Zahl im Factsheet: 264 Milliarden Euro werden jährlich für Produkte und Dienstleistungen aus Drittstaaten ausgegeben. Diese Zahl sollte jeden europäischen CIO und Einkaufsverantwortlichen dazu bringen, das Dokument aufmerksam zu lesen. Nicht 264 Millionen. 264 Milliarden. Pro Jahr. Sie fließen größtenteils an einige wenige große proprietäre Cloud- und Softwareanbieter – Unternehmen, deren Nutzungsbedingungen, Preisgestaltung, Produkt-Roadmaps und Datenzugriffsrichtlinien in Vorstandsetagen festgelegt werden, ohne Rechenschaft gegenüber europäischen Institutionen oder Bürgern.
Kommissionspräsidentin Ursula von der Leyen bringt es auf den Punkt: „Wir können es uns nicht leisten, von anderen abhängig zu sein, wenn es um Technologien geht, die unsere Krankenhäuser am Laufen halten, unsere Energienetze stabilisieren und unsere Dienste absichern. Es geht darum, unsere Bürger zu schützen, unsere Interessen zu verteidigen und eigene Entscheidungen zu treffen.“
Das ist kein technologiepolitisches Statement. Das ist ein geopolitisches. Und es kommt zu einem Zeitpunkt, an dem der geopolitische Druck auf die europäische digitale Infrastruktur so hoch ist wie seit der DSGVO nicht mehr.
Open Source ist kein Randthema mehr
Frühere EU-Digitalstrategien erwähnten Open Source nur am Rande – ein Stichpunkt hier, ein Verweis auf das Free and Open Source Software (FOSS)-Ökosystem dort. Das Tech Sovereignty Package ist anders. Die EU-Open-Source-Strategie rückt Open Source ins Zentrum der technologischen Souveränität der EU. Das Cloud and AI Development Act bekräftigt das Bekenntnis der Kommission zu einer offenen, kollaborativen und resilienten digitalen Umgebung.
Die Kommission zieht explizit eine Linie zwischen Vendor-Lock-in und strategischer Verwundbarkeit und stellt die Konzentration der digitalen EU-Infrastruktur in den Händen weniger dominanter proprietärer Anbieter nicht nur als Wettbewerbsproblem, sondern als strategische Schwäche dar. Das ist ein bedeutender Wandel. Jahrelang war das Argument für Open Source bei öffentlichen Ausschreibungen wirtschaftlich (geringere Total Cost of Ownership) oder ideologisch (digitale Gemeingüter). Das Tech Sovereignty Package macht daraus eine strategische Frage. Die Abhängigkeit von proprietärer Software von nicht kontrollierbaren Anbietern behindert die digitale Souveränität. Das ist die Position der Kommission – festgehalten in einem veröffentlichten Strategiepapier.
Das Factsheet nennt außerdem 3 Millionen Open-Source-Beitragende in Europa, die digitale Lösungen liefern. Das ist die Workforce. Strategie, Beitragende und politischer Wille sind jetzt aufeinander abgestimmt.
Was „Souveränität“ wirklich erfordert
Hier möchte ich präzise sein, denn „digitale Souveränität“ ist inzwischen ein Label, das jeder Cloud-Anbieter auf sein Frankfurter Rechenzentrum klebt und damit alles erledigt sieht.
Echte Souveränität hat vier Anforderungen. Das Tech Sovereignty Package adressiert sie alle.
- Sie müssen die Software selbst betreiben können.
Eine „souveräne Cloud“, bei der der Code proprietär ist und der Anbieter Ihre Lizenz beenden, die Bedingungen ändern oder jederzeit auf Ihre Daten zugreifen kann, ist nicht souverän. Das ist Miete mit Marketing-Sprache. Das gilt unabhängig davon, wo der Anbieter seinen Hauptsitz hat. Proprietärer Lock-in mit Frankfurter Rechenzentrum bleibt Lock-in. Open Source mit Self-Hosting-Fähigkeit ist das Minimum. Das Cloud and AI Development Act führt einen Souveränitäts-Bewertungsrahmen ein, weil die Kommission diesen Unterschied versteht. - Sie müssen wissen, was in der Software steckt.
Supply-Chain-Security ist kein Buzzword. Es geht darum, ob Sie wissen, welcher Drittanbieter-Code in Ihrer Infrastruktur läuft, woher er stammt und ob er geprüft wurde. SBOMs (Software Bill of Materials), signierte Builds und Richtlinien zur Schwachstellenmeldung sind die praktische Umsetzung von Souveränität in der Software. - Sie brauchen überprüfbare Governance.
Ein Anbieter, der sagt „Wir setzen auf Open Source“, aber kein veröffentlichtes Governance-Charter, kein Community Advisory Board und keinen definierten Entscheidungsprozess hat, gibt ein Marketing-Versprechen, aber kein strukturelles Commitment. Die Open-Source-Strategie fordert explizit organisatorische und Governance-Fähigkeiten, die Open-Source-Projekte langfristig tragen. - Sie brauchen rechtliche Klarheit.
Open-Source-Lizenzen sind nicht alle gleich. Die Apache-2.0-Lizenz ist permissiv, beschaffungssicher und mit den meisten Anforderungen von Unternehmen und öffentlicher Hand in Europa kompatibel. AGPL ist eine Copyleft-Lizenz, was bedeutet, dass Software, die sie enthält, oft unter denselben Bedingungen veröffentlicht werden muss (häufig ein Ausschlusskriterium bei proprietären öffentlichen Ausschreibungen). Die Kenntnis Ihres Lizenz-Stacks ist Teil der souveränen Beschaffungspraxis.
Was wir gebaut haben, bevor die Politik kam
ownCloud wurde 2010 in Deutschland gegründet. Die Lösung wird seit 16 Jahren in europäischen Schulen, Behörden, Forschungseinrichtungen und Public-Clouds eingesetzt. Millionen Anwender verlassen sich auf oCIS.
Am 5. Mai, einen Monat vor Veröffentlichung des Pakets, haben wir das Kiteworks Open Source Program Office ins Leben gerufen. Alles, was wir im Rahmen unseres OSPO-Launchs umgesetzt haben, entspricht exakt dem, was das Tech Sovereignty Package nun auf politischer Ebene fordert:
Apache 2.0 als Standard.
oCIS nutzt die Apache-2.0-Lizenz. Neue Repositories sind standardmäßig Apache 2.0. Kein Copyleft-Risiko bei Ihrer Beschaffung. Keine Lizenz-Unklarheiten als kommerzielles Druckmittel. Das haben wir in unserem Manifest schriftlich festgehalten.
CLA abgeschafft, DCO eingeführt.
Beitragende behalten ihr Urheberrecht. Das ist für Souveränität entscheidend, weil so kein einzelner Anbieter den gesamten Code besitzt. Der Code gehört den Entwicklern, lizenziert für die Welt unter Apache 2.0.
Veröffentlichtes Governance-Charter.
Keine Wunschvorstellung, sondern ein Dokument mit klaren Rollen, Entscheidungsprozessen, Konfliktlösung, Zeitplan für das Community Advisory Board und einer 30-tägigen öffentlichen Kommentierungsphase für jede Richtlinienänderung. Es ist explizit festgehalten, dass Kiteworks die Roadmap steuert – und ebenso, wie die Community Einfluss nehmen kann. Das ist das strukturelle Commitment, das die Open-Source-Strategie fordert.
SBOM, signierte Builds, VDP.
Supply-Chain-Security ist für uns gelebte Praxis. Wir haben eine Richtlinie zur Schwachstellenmeldung veröffentlicht, betreiben ein Bug-Bounty-Programm auf YesWeHack, generieren SBOMs zu jedem Release, signieren unsere Container-Images und veröffentlichen Patch-Management-Dokumentationen. Anfang des Jahres haben wir einen Supply-Chain-Vorfall (CVE-2026-33634, Trivy) mit öffentlichem Incident-Report, Benachrichtigungen an betroffene Kunden in deren Sprache und aktualisierten Images innerhalb des Exposure-Zeitraums bewältigt. Das ist Souveränität unter Druck – nicht nur Marketing.
12 veröffentlichte Dokumente.
Vision, Mission, Manifest, Governance-Charter, KI-Beitragsrichtlinie, Sicherheitsrichtlinie, Contribution Guide, Lessons Learned, Code of Conduct, Engagement, Empowerment, Produktvision (mehr dazu auf unserer OSPO-Seite). Jedes Commitment ist schriftlich fixiert und öffentlich überprüfbar.
Warum das OSPO die richtige Struktur ist
Das Tech Sovereignty Package adressiert Open Source auf politischer Ebene. OSPOs (Open Source Program Offices) sind die organisatorische Struktur, die Politik in Unternehmen und öffentliche Institutionen überführt.
Die Open-Source-Strategie der Kommission ist der bislang wichtigste Schritt Europas, Open Source für eine souveräne und resiliente digitale Zukunft zu nutzen. Aber eine Strategie ohne Umsetzung bleibt ein Dokument. Das Kiteworks OSPO macht die ownCloud-Implementierung konkret: eine veröffentlichte Sicherheitsrichtlinie, ein definierter Beitragspfad, eine Community-Governance-Struktur und ein kommerzielles Supportmodell, das das Open-Source-Produkt finanziell tragfähig macht, ohne seine Offenheit zu kompromittieren.
Die vier Elemente unseres kommerziellen Modells adressieren direkt die Anforderungen europäischer öffentlicher Auftraggeber für den verantwortungsvollen Open-Source-Einsatz:
- Support und SLAs.
Der Code ist kostenlos. Aber jemanden zu erreichen, wenn Ihr Virtual Data Room um 2 Uhr morgens ausfällt, ist es nicht. Die Support-Tiers bieten öffentlichen Einrichtungen die vertragliche Reaktionssicherheit, die sie für kritische Infrastrukturen benötigen. - Gehärtete Builds und SBOM.
Den Auditor interessiert nicht der GitHub-Link. Er braucht eine signierte SBOM, eine Patch-Management-Dokumentation und eine Anbieterbescheinigung. Wir liefern alle drei. - Compliance-Dokumentation.
Öffentliche Einrichtungen in Deutschland und der gesamten EU arbeiten nach diesen Vorgaben. Unsere Kiteworks-Abonnements beinhalten Compliance-Mapping, Audit-Support und einen dedizierten Compliance-Kontakt, der ownCloud in regulierten Umgebungen revisionssicher macht. - Rechtlicher Schutz.
Apache 2.0 ist permissiv. Unsere Support-Abonnements bieten IP-Freistellung für Organisationen, die einen Anbieter brauchen, der hinter der Lizenz steht.
Die Zahl, die zählt
264 Milliarden Euro. Pro Jahr. Für Anbieter, deren Roadmaps, Preise und Bedingungen europäische Organisationen nicht wirklich beeinflussen können.
Das Tech Sovereignty Package wird diese Zahl nicht über Nacht verändern. Gesetzgebungsprozesse brauchen Zeit. Beschaffungszyklen sind lang. Institutionelle Routinen sind schwer zu ändern.
Aber die Richtung ist klar. Die EU will Europas Kapazitäten in Halbleitern, KI, Cloud Computing und Open Source ausbauen. Die Open-Source-Strategie, die Souveränitätsanforderungen des Cloud and AI Development Act, das Mandat für Open Source im öffentlichen Sektor: Das sind die strukturellen Voraussetzungen, damit offene, gesteuerte und revisionssichere Alternativen zum Standard werden.
Das Problem war nie der Hauptsitz des Anbieters. Es geht darum, ob Sie den Code prüfen, bei Bedarf forken, die Lieferkette verifizieren und ihn auf eigener Infrastruktur unter eigenem Rechtsrahmen betreiben können. Vendor-Lock-in scheitert an allen vier Punkten. Open Source, richtig gemacht, erfüllt sie alle.
ownCloud ist diese Alternative seit 2010. Das OSPO macht Governance und Community-Commitments strukturell statt nur verbal. Und das kürzlich veröffentlichte Tech Sovereignty Package bestätigt, dass wir genau das bauen, was die europäische Digitalpolitik jetzt fordert.
Das Timing ist kein Zufall. Das Problem ist seit Jahren sichtbar. Wir arbeiten an der Lösung.
—
Lesen Sie das EU Tech Sovereignty Factsheet: ec.europa.eu/commission/presscorner
ownCloud OSPO: kiteworks.com/opensource · owncloud.com/blogs
Testen Sie oCIS: github.com/owncloud/ocis · owncloud.dev
David Walter ist VP des Open Source Program Office bei Kiteworks und verantwortet dort Open-Source-Governance, Lizenzierung und Community-Engagement für ownCloud. Er ist seit 2014 Teil des ownCloud-Ökosystems.