No transcript available for this episode.
Redaktionsstand: 30. Juli 2026
Geplante Sprechdauer: etwa 25 Minuten
Status: Entwurf, nicht veröffentlicht, Freigabe durch Andreas erforderlich
Kernaussage: Deutschland hat 2026 brauchbare Hebel für souveränere IT-Beschaffung geschaffen. Eine allgemeine gesetzliche Open-Source-Pflicht gibt es aber nicht.
Zwei Beispiele aus dem Server- und Community-Alltag:
Zum Vorlesen: „Eine Vertragsvorlage beendet keinen Vendor-Lock-in – das schafft erst ein Vertrag, der den Ausstieg technisch und rechtlich absichert.“
Deutschland hat Open Source zum Standard gemacht. So könnte man die Meldungen der vergangenen Monate verstehen. Ein neues Vergabegesetz, modernisierte IT-Vertragsmuster, ein Deutschland-Stack mit offenen Standards: Das klingt nach der großen Wende. Nach dem Ende der ewigen Abhängigkeit von einzelnen Softwarekonzernen.
Aber genau hier müssen wir bremsen und den Wortlaut lesen.
Seit dem 1. Juli 2026 kann digitale Souveränität ausdrücklich als Zuschlagskriterium bei öffentlichen Vergaben berücksichtigt werden. Acht sogenannte EVB-IT-Vertragsmuster wurden überarbeitet, damit Behörden Open-Source-Software rechtssicher beschaffen können. Neue Softwareprojekte werden in diesen Mustern nach Angaben des Bundesdigitalministeriums als Open Source zum Standard gemacht. [3][5]
Das sind echte Fortschritte. Doch das Vergabebeschleunigungsgesetz schreibt Open Source nicht allgemein vor. Im veröffentlichten Regelungstext kommen die Begriffe „Open Source“, „Software“ und „Quellcode“ nicht vor. Und § 58 Absatz 2 der Vergabeverordnung sagt, Aspekte digitaler Souveränität können berücksichtigt werden. Dort steht nicht „müssen“. [3][4]
Diese Differenz ist keine juristische Wortklauberei. Sie entscheidet darüber, ob eine Beschaffungsstelle handeln muss oder nur handeln darf. Eine Erlaubnis kann eine mutige Vergabe absichern. Sie zwingt aber keine Behörde, ihre gewohnten Ausschreibungen zu ändern. Und ein Vertragsmuster kann gute Klauseln anbieten. Es garantiert nicht, dass jede Klausel im einzelnen Vertrag landet.
Der neue Deutschland-Bericht des europäischen Open Source Observatory, kurz OSOR, beschreibt Deutschland als führendes europäisches Beispiel für Open Source im öffentlichen Sektor. Der Bericht nennt ZenDiS, openDesk, openCode, die Sovereign Tech Agency und den Deutschland-Stack. Das ist als Gesamtbild nachvollziehbar. An einer entscheidenden Stelle formuliert der Bericht jedoch stärker als der deutsche Normtext: Er spricht davon, Beschaffungsstellen seien verpflichtet, digitale Souveränität bei nicht preislichen Kriterien zu berücksichtigen. Außerdem soll ein Anhang Open Source und offene Standards als Beispiele nennen. Im verkündeten Gesetzestext lässt sich das so nicht belegen. [1][2][3]
Belegte Tatsache: Die neuen rechtlichen und vertraglichen Werkzeuge existieren.
Nachprüfung vom 31. Juli 2026: Die Fußnote 37 des OSOR-Berichts verweist ausschließlich auf BGBl. 2026 I Nr. 137. Der amtliche 19-seitige Regelungstext enthält keinen Anhang und keinen Treffer für „Open Source“, „offene Standards“, „Software“ oder „Quellcode“. Die Behauptung ist daher durch die vom OSOR selbst genannte Quelle nicht gedeckt und wird als fehlerhafte Darstellung des Länderberichts behandelt.
Meine Meinung: Gerade wer Open Source politisch stärken will, darf aus einem „kann“ kein „muss“ machen. Übertreibung hilft der Sache nicht. Sie verdeckt, wo der eigentliche Konflikt liegt: in jeder einzelnen Ausschreibung, in jedem Vertrag und im späteren Betrieb.
Das kennen wir aus dem Community-Alltag. Synapse ist freie Software. Das allein verhindert aber nicht, dass nur eine Person den Dienst retten kann. Wenn Admin-Tokens, Raumrechte, Signaturschlüssel und Restore-Ablauf nicht dokumentiert sind, ist die Community abhängig – nicht von einer Lizenzfirma, aber von einem Wissensmonopol.
Dasselbe passiert bei einer offenen Webanwendung. Der Quellcode liegt vielleicht öffentlich. Wenn aber Nginx-Regeln, Zertifikatserneuerung, Datenbankmigration und Monitoring beim bisherigen Integrator bleiben, kann der Auftraggeber den Betreiber nicht real wechseln. Offenheit auf dem Papier ist noch keine Handlungsfähigkeit.
Kernaussage: Das Gesetz erleichtert die Berücksichtigung digitaler Souveränität, definiert aber weder eine Open-Source-Pflicht noch einen automatischen Vorrang.
Zwei Beispiele aus dem Server- und Community-Alltag:
Zum Vorlesen: „Ein Rechenzentrum in Europa macht eine geschlossene Sackgasse noch nicht souverän.“
Das Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge wurde nach Angaben der Bundesregierung am 23. April 2026 vom Bundestag beschlossen, am 8. Mai vom Bundesrat angenommen, am 18. Mai im Bundesgesetzblatt verkündet und trat am 1. Juli in Kraft. Sein Schwerpunkt liegt nicht auf Open Source. Es soll Vergaben insgesamt beschleunigen und vereinfachen: durch höhere Direktauftragsgrenzen, flexiblere Gesamtvergaben, weniger Nachweispflichten, schnellere Nachprüfungsverfahren und mehr elektronische Kommunikation. [3][6]
Für digitale Souveränität ist die Änderung von § 58 Absatz 2 VgV wichtig. Dort werden Kriterien genannt, die neben Preis und Kosten in die Zuschlagsentscheidung einfließen können. Neu hinzugekommen sind „Aspekte der digitalen Souveränität“. [4]
Damit bekommt eine Vergabestelle eine deutlichere Rechtsgrundlage, nicht nur den kurzfristig niedrigsten Preis zu betrachten. Sie kann etwa Kontrollrechte, Datenportabilität, offene Schnittstellen, Abhängigkeiten oder Betriebsstandorte bewerten. Das ist relevant, weil der billigste Einstieg langfristig sehr teuer werden kann, wenn ein späterer Anbieterwechsel praktisch unmöglich ist.
Aber die Norm beantwortet zwei Fragen nicht.
Erstens definiert sie an dieser Stelle nicht, was digitale Souveränität im einzelnen Verfahren genau bedeutet. Ein Auftraggeber kann darunter Open Source und offene Standards verstehen. Er kann aber auch nur auf einen europäischen Unternehmenssitz, einen bestimmten Hostingort oder besondere Sicherheitsanforderungen schauen.
Zweitens verpflichtet die Formulierung „können berücksichtigt werden“ nicht zur Anwendung. Eine Beschaffungsstelle, die weiter hauptsächlich Preis, bekannte Marken und bestehende Rahmenverträge gewichtet, wird durch diesen Satz allein nicht gestoppt.
Das ist politisch heikel. Denn „europäisch“ und „souverän“ sind nicht dasselbe. Ein europäischer Anbieter kann Daten in geschlossenen Formaten halten, Schnittstellen nur gegen Aufpreis öffnen und den Betrieb an sein eigenes Kontrollpanel binden. Dann bleibt die Wechselmacht beim Unternehmen. Umgekehrt kann eine international entwickelte Open-Source-Komponente in Deutschland kontrolliert, geprüft, betrieben und notfalls von einem anderen Dienstleister weitergepflegt werden.
Nehmen wir ein Matrix-Angebot. Der Anbieter betreibt Synapse in einem deutschen Rechenzentrum. Das klingt souverän. Doch die Benutzerkonten hängen an seinem Identitätsdienst. Push-Benachrichtigungen laufen über eine geschlossene Zusatzkomponente. Admin-Tokens werden nicht an den Auftraggeber übergeben. Ein vollständiger Export von Rollen, Räumen und Moderationsregeln ist nicht Vertragsbestandteil. Dann ist zwar der Serverstandort europäisch, der Wechselpfad aber blockiert.
Oder eine Webplattform: Die Daten liegen in Frankfurt, aber nur das herstellereigene Panel kann sie vollständig exportieren. Die Nginx-Konfiguration ist „Betriebsgeheimnis“, die Dokumentation bleibt unvollständig, und ein zweiter Betreiber kann den Dienst nicht starten. Das ist geografische Nähe ohne technische Kontrolle.
Technische Analyse: Digitale Souveränität braucht messbare Kriterien. Dazu gehören vollständiger Daten- und Konfigurationsexport, dokumentierte Schnittstellen, kontrollierte Schlüssel, unabhängige Betriebsrechte und eine nachweisbare Migration.
Meine Meinung: Der neue § 58 ist eine geöffnete Tür. Jetzt braucht es Verwaltungen, die hindurchgehen, und politische Kontrolle darüber, welche Kriterien sie tatsächlich verwenden. Sonst wird „digitale Souveränität“ zum dehnbaren Etikett für dieselben alten Verträge.
Kernaussage: Die modernisierten EVB-IT können den juristischen Aufwand für Open-Source-Beschaffung senken. Ihre Wirkung hängt aber davon ab, welche Klauseln konkret vereinbart werden.
Zwei Beispiele aus dem Server- und Community-Alltag:
Zum Vorlesen: „Ein Mustervertrag ist ein Werkzeug – ob daraus Freiheit entsteht, entscheidet der ausgefüllte Vertrag.“
EVB-IT steht für „Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen“. Diese Muster werden von Bund, Ländern und Kommunen genutzt. Sie übersetzen Anforderungen in Vertragsklauseln: Welche Software wird geliefert? Welche Rechte erhält der Auftraggeber? Wie werden Pflege, Anpassung, Dokumentation, Haftung oder Abnahme geregelt?
Am 20. März 2026 meldete das Bundesministerium für Digitales und Staatsmodernisierung, acht Vertragsmuster seien für die rechtssichere Beschaffung von Open Source überarbeitet worden. Die Entwicklung und Bereitstellung neuer Softwareprojekte als Open Source werde als Standard abgebildet. Zusätzlich sehen die Muster nach Ministeriumsangaben Optionen für mehr Transparenz vor, darunter die Übergabe einer Software Bill of Materials, kurz SBOM. Proprietäre Software bleibt trotzdem ausdrücklich beschaffbar. [5]
Warum ist das wichtig? Weil Open-Source-Beschaffung bislang oft individuellen juristischen Aufwand erzeugt hat. Standardklauseln können diese Reibung senken. Eine Vergabestelle muss dann nicht jedes Mal von vorn erklären, wie freie Lizenzen, Quellcodebereitstellung und Nutzungsrechte in einen öffentlichen Vertrag passen.
Aber auch ein gutes Muster ist keine automatische Abnahmegarantie.
Ein Beispiel: Eine Behörde lässt ein Zusatzmodul für Synapse entwickeln. Der Quellcode wird geliefert. Formal ist die Forderung erfüllt. Doch ohne Build-Anleitung, genaue Abhängigkeiten, Testumgebung und Release-Prozess kann ein anderer Betreiber daraus möglicherweise kein lauffähiges Paket herstellen. Wenn Änderungen nicht sauber upstream eingebracht werden, trägt die Behörde außerdem dauerhaft einen eigenen Sonderstand. Bei jedem Sicherheitsupdate muss sie hoffen, dass der ursprüngliche Dienstleister die Anpassung erneut einpflegt.
Die SBOM verbessert die Transparenz. Sie listet Softwarekomponenten und Abhängigkeiten auf. Bei einer Sicherheitslücke lässt sich schneller prüfen, ob der eigene Dienst betroffen ist. Doch eine SBOM spielt kein Update ein. Sie definiert keine Reaktionszeit, benennt keine verantwortliche Stelle und garantiert keinen gepflegten Patchpfad.
Ein zweites Beispiel: Eine Nginx-basierte Anwendung wird vollständig dokumentiert und mit SBOM übergeben. Das ist gut. Bei der Abnahme wird aber nur geprüft, ob die Startseite erreichbar ist. Niemand testet, ob Datenbank, Medien, Zertifikate, Konfiguration und Secrets aus einem Backup auf einer frischen Umgebung wiederhergestellt werden können. Der Vertrag hat Transparenz gekauft, aber noch keine Wiederanlauffähigkeit.
Eine wirklich souveräne Vertragsgestaltung sollte mindestens klären: