Überarbeitete EVB-IT: Open Source als Regelfall bei neuer Individualsoftware – was Anbieter jetzt wissen sollten

I. Überblick

Die „Ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen“ (EVB-IT) bestehen aus standardisierten Vertragsformularen und Allgemeinen Geschäftsbedingungen für die IT-Beschaffung der öffentlichen Hand. Sie werden bei zahlreichen Beschaffungsvorhaben von Bund, Ländern, Kommunen und sonstigen öffentlichen Auftraggebern eingesetzt. Für Anbieter, die IT-Leistungen an die öffentliche Hand vertreiben, bilden sie daher häufig den maßgeblichen vertraglichen Rahmen.

Am 20. März 2026 veröffentlichte das Bundesministerium für Digitales und Staatsmodernisierung die überarbeiteten Muster, die der IT-Planungsrat bereits am 26. November 2025 zur Kenntnis genommen und seinen Mitgliedern zur Nutzung empfohlen hatte. Betroffen sind acht der zwölf Vertragstypen, darunter die für Softwareanbieter zentralen EVB-IT Erstellung, Überlassung Typ A, Pflege S, Dienstleistung, System, Systemlieferung, Service sowie die EVB-IT Rahmenvereinbarung. Erklärtes Ziel ist es, die rechtssichere Einbindung von Open Source Software (OSS) in öffentliche Beschaffungsvorgänge zu erleichtern und zur digitalen Souveränität der öffentlichen Hand beizutragen.

Für reine SaaS-Leistungen ist die unmittelbare Reichweite der Überarbeitung zunächst begrenzt: Die EVB-IT Cloud – deren Anwendungsbereich ausdrücklich SaaS, PaaS, IaaS und Managed Cloud Services umfasst – war ebenso wie die EVB-IT Überlassung Typ B nicht Gegenstand der OSS-Überarbeitung; sie wurde allerdings ebenfalls in EVB-IT digital überführt und liegt derzeit als Version 1.0.2 vom 1. März 2026 vor. In der amtlichen Übersicht wurden entsprechende Verhandlungen für 2026 in Aussicht gestellt. Die nun veröffentlichten Regelungen können daher Anhaltspunkte für die mögliche Richtung einer künftigen Cloud-Überarbeitung geben; eine inhaltlich identische Übernahme ist damit jedoch nicht vorweggenommen. SaaS-Anbieter können gleichwohl bereits heute betroffen sein, soweit sie neben der eigentlichen Cloudleistung etwa Anpassungs-, Entwicklungs-, Einführungs- oder Serviceleistungen auf Grundlage anderer EVB-IT-Vertragstypen erbringen.

II. Open Source als Regelfall bei neuer Individualsoftware

Die wichtigste Änderung ist die ausdrückliche Integration von OSS in die EVB-IT. Bislang waren die Vertragsformulare und AGB auf proprietäre Software zugeschnitten. Die Einbindung von OSS war auch bisher möglich, musste jedoch häufig durch individuelle Regelungen zu Nutzungsrechten, Lizenzbedingungen, Quellcode, Pflege und Haftung ergänzt werden. Dies erhöhte den Gestaltungs- und Prüfungsaufwand auf beiden Seiten.

Diesen Gestaltungsaufwand können die überarbeiteten EVB-IT deutlich reduzieren. Dabei ist genau hinzusehen, wo OSS tatsächlich zum Regelfall wird: Die neuen EVB-IT Erstellungs-AGB bestimmen, dass der Auftragnehmer Individualsoftware bzw. Individualsoftwarekomponenten als OSS bereitstellt, soweit im Vertrag nichts anderes vereinbart ist. Entsprechendes gilt im EVB-IT Systemvertrag für dort neu erstellte Individualsoftware. Bei Standardsoftware, Pflege, Dienstleistungen und Serviceleistungen wurden dagegen überwiegend Optionen geschaffen, die im konkreten Vertrag aktiviert werden müssen. Die Beschaffung proprietärer Software bleibt ausdrücklich möglich.

Für Anbieter kann die Standardisierung den vertraglichen Prüfungs- und Gestaltungsaufwand reduzieren und OSS-basierten Angeboten den Zugang zu öffentlichen Beschaffungsvorhaben erleichtern. Bei Individualentwicklungen kann sich dadurch auch das Geschäftsmodell verändern: Die wirtschaftliche Bedeutung exklusiver Nutzungsrechte nimmt bei den als OSS bereitzustellenden Komponenten ab, während Entwicklung, Integration, Pflege, Betrieb und Support an Gewicht gewinnen können. Anbieter sollten zugleich klar zwischen neu entwickelter Individualsoftware, vorbestehenden eigenen Komponenten und Drittsoftware unterscheiden. Diese Abgrenzung ist sowohl für die Kalkulation als auch für die spätere OSS-Lizenzierung und eine etwaige Veröffentlichung auf openCode entscheidend und sollte bereits im Angebot, in der Leistungsbeschreibung und ggf. in einer Komponenten- oder Nutzungsrechtsmatrix nachvollziehbar abgebildet werden.

III. SBOM als optionaler Leistungsbestandteil

Neu ist außerdem der Einbezug der „Software Bill of Materials“ (SBOM) – vereinfacht: einer strukturierten Komponentenliste, die transparent macht, aus welchen Bibliotheken, Frameworks und Abhängigkeiten eine Software besteht. Die überarbeiteten EVB-IT ermöglichen es, die Übergabe einer SBOM vertraglich zu vereinbaren; bei der Pflege von Standardsoftware kann zudem ihre laufende Aktualisierung vorgesehen werden (EVB-IT Pflege S).

Eine SBOM wird damit nicht automatisch zur Pflicht, sondern zu einem Leistungsbestandteil, der optional vereinbart werden kann. Öffentliche Auftraggeber können ihre Übergabe allerdings bereits in den Vergabeunterlagen verbindlich vorgeben, etwa um bei einer Sicherheitslücke in einer Komponente schnell feststellen zu können, ob die eingesetzte Software betroffen ist. Anbieter sollten daher damit rechnen, dass von der vertraglichen Option Gebrauch gemacht wird.

Wer die SBOM-Erzeugung noch nicht automatisiert hat, sollte entsprechende Prozesse aufbauen. Auch der Cyber Resilience Act (CRA) verpflichtet Hersteller der von ihm erfassten Produkte mit digitalen Elementen künftig zur Erstellung einer maschinenlesbaren SBOM, die zumindest die Abhängigkeiten der obersten Ebene abdeckt. CRA-Compliance und die Erfüllung einer konkreten EVB-IT-SBOM-Klausel sind jedoch nicht automatisch deckungsgleich: Insbesondere Format, Granularität, Aktualisierungsrhythmus und vertragliche Verantwortlichkeit müssen gesondert geprüft werden.

IV. Optionale Veröffentlichung auf openCode

Ebenfalls neu ist die Möglichkeit, die zusätzliche Veröffentlichung entwickelter Software auf der Plattform openCode zu vereinbaren. Dadurch soll die Nachnutzung öffentlich finanzierter Software erleichtert werden: Andere Behörden können prüfen, ob eine bereits entwickelte Lösung übernommen oder weiterentwickelt werden kann, statt eine vergleichbare Entwicklung erneut zu beauftragen.

Die Veröffentlichung auf openCode erfolgt nicht automatisch. Sie ist nur geschuldet, wenn sie im konkreten Vertrag vereinbart wurde. Auch dann tritt sie neben die Bereitstellung der Software unter einer Open-Source-Lizenz und die weiteren Nutzungsrechte des Auftraggebers; sie ersetzt die Rechteverschaffung nicht.

Für Auftragnehmer entstehen daraus zusätzliche Anforderungen an die Veröffentlichungsvorbereitung. Sie müssen insbesondere klären, welche Bestandteile neu entwickelt wurden, welche bestehenden Eigenkomponenten verwendet werden und welche Drittkomponenten enthalten sind. Erforderlich sind zudem eine belastbare Rechtekette – einschließlich der Rechte von Beschäftigten und Unterauftragnehmern –, die Prüfung der Lizenzkompatibilität sowie eine Bereinigung des Repositorys von Zugangsdaten, personenbezogenen Daten und vertraulichen Informationen.

V. Lizenzlisten als Orientierung

Die Vielzahl unterschiedlicher Open-Source-Lizenzen war in der Praxis stets eine Herausforderung. Die überarbeiteten EVB-IT enthalten erstmals eine eigene Definition von "Open Source Software" und greifen für die Einordnung von Lizenzen auf eine von openCode geprüfte Open Source Lizenzliste zurück. openCode veröffentlicht daneben eine Negativliste ausdrücklich nichtakzeptierter Lizenzen. Grundlage der Prüfung ist, dass die Lizenz der Open-Source-Definition der Open Source Initiative entspricht und keine erkennbaren Schwierigkeiten für die öffentliche Verwaltung hervorruft.

Die Positivliste umfasst eine große Zahl verbreiteter und weniger verbreiteter Lizenzen – neben permissiven Lizenzen wie MIT, Apache-2.0 oder BSD-3-Clause auch Copyleft-Lizenzen wie GPL-3.0-only bzw. GPL-3.0-or-later, AGPL-3.0-only bzw. AGPL-3.0-or-later, MPL-2.0 und die EUPL-1.2. Nichtakzeptiert werden unter anderem die Server Side Public License (SSPL-1.0), die Elastic License 2.0 sowie verschiedene Creative-Commons-Lizenzen mit NC- oder ND-Einschränkungen.

Für Anbieter kommt es deshalb auf die konkrete Komponente und Lizenzierung an. Der MongoDB Community Server steht in aktuellen Versionen grundsätzlich unter der SSPL. Bei Elasticsearch und Kibana ist die Lage differenzierter, weil erhebliche Teile des Quellcodes seit 2024 zusätzlich unter der AGPLv3 angeboten werden. Eine produkt- oder herstellerbezogene Pauschalbetrachtung reicht daher nicht aus – ein Blick in die eigene SBOM lohnt sich auch aus diesem Grund.

Die Aufnahme in die Lizenzliste besagt zudem weder, dass die Lizenz für jedes Projekt geeignet ist, noch dass sie mit allen anderen eingesetzten Lizenzen kompatibel ist. Die Listen geben eine wertvolle Orientierung und können den Prüfungsaufwand beider Vertragsparteien reduzieren; eine individuelle Prüfung der konkreten Lizenz- und Nutzungssituation ersetzen sie nicht – eine saubere Lizenz-Compliance bleibt erforderlich.

VI. Vom Formular zur Legal-Tech-Lösung

Schließlich wurde der Zugang zu den EVB-IT selbst modernisiert: Alle aktuellen Vertragstypen stehen im Vertragserstellungstool „EVB-IT digital“ als Playbooks für die interviewgestützte Erstellung zur Verfügung. Das Tool führt den Anwender durch den Vertrag und erzeugt auf Grundlage der Antworten ein editierbares Vertragsdokument; ein Repro-Code ermöglicht zudem die Prüfung, ob ein erzeugtes Dokument nachträglich verändert wurde. Die Muster sind kostenfrei und barrierefrei abrufbar.

Die interviewgestützte Benutzerführung kann allerdings den Eindruck erwecken, mit dem vollständigen Ausfüllen des Playbooks sei auch die rechtliche Gestaltung des Beschaffungsvorhabens abgeschlossen. Das Tool unterstützt die Auswahl und Zusammenstellung der Vertragsregelungen; die Prüfung, ob der gewählte Vertragstyp, die aktivierten Optionen und die ergänzenden Anlagen zum konkreten Vorhaben passen, ersetzt es nicht. Die inhaltliche Verantwortung verbleibt beim Anwender.

Fazit

Die Überarbeitung der EVB-IT ist ein wichtiger Schritt für die öffentliche IT-Beschaffung. Open Source Software wird erstmals systematisch in die Vertragsmuster integriert. Bei neu erstellter Individualsoftware ist die Bereitstellung als OSS nun grundsätzlich der vertragliche Ausgangspunkt, sofern nichts anderes vereinbart wird; in anderen Leistungsbereichen stehen insbesondere zusätzliche Auswahl- und Gestaltungsoptionen zur Verfügung. Vertragliche Hürden werden dadurch reduziert, nicht jedoch sämtliche rechtliche und technische Prüfungen entbehrlich.

Softwareanbieter sollten insbesondere klären, welche Bestandteile ihrer Lösungen neu entwickelt, vorbestehend oder von Dritten übernommen sind, ob die erforderlichen Rechte für eine OSS-Lizenzierung und ggf. eine Veröffentlichung auf openCode vorliegen und ob die eingesetzten Lizenzen miteinander kompatibel sind. Daneben sollten sie die Erzeugung und versionsbezogene Pflege von SBOMs in ihre Entwicklungs- und Releaseprozesse integrieren. Bei Individualentwicklungen sind außerdem Kalkulation und Angebotsstrategie darauf auszurichten, dass die wirtschaftliche Wertschöpfung bei den betroffenen Komponenten weniger auf Exklusivität und stärker auf Entwicklung, Integration, Betrieb, Pflege und Support beruhen kann.

Die EVB-IT stellen hierfür eine standardisierte Vertragsstruktur bereit. Die sorgfältige Leistungsbeschreibung sowie die rechtliche, technische und insbesondere lizenzrechtliche Prüfung des jeweiligen Vorhabens ersetzen sie nicht.

Für Anbieter reiner Cloud- bzw. SaaS-Leistungen bleibt eine künftige inhaltliche Überarbeitung der EVB-IT Cloud besonders relevant. Die jetzigen Änderungen geben Hinweise auf mögliche künftige Anforderungen, nehmen deren konkrete Ausgestaltung aber nicht vorweg.