Ü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ürSoftwareanbieter 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 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 alsVersion 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ünftigenCloud-Ü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 etwaAnpassungs-, 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 dieEVB-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 AuftragnehmerIndividualsoftware bzw. Individualsoftwarekomponenten als OSS bereitstellt, soweit im Vertrag nichts anderes vereinbart ist. Entsprechendes gilt im EVB-ITSystemvertrag 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. DieBeschaffung proprietärer Software bleibt ausdrücklich möglich.

Für Anbieter kann die Standardisierung den vertraglichen Prüfungs- undGestaltungsaufwand 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 entwickelterIndividualsoftware, 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 openCodeentscheidend – 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 laufendeAktualisierung vorgesehen werden (EVB-IT Pflege S).

Eine SBOM wird damit nicht automatisch zur Pflicht, sondern zu einem optional vereinbarbaren Leistungsbestandteil. Ö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 die Option gezogen wird.

Wer die SBOM-Erzeugung noch nicht automatisiert hat, sollte entsprechendeProzesse aufbauen. Auch der Cyber Resilience Act 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: AndereBehörden können prüfen, ob eine bereits entwickelte Lösung übernommen oderweiterentwickelt 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 sieneben 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 dieVeröffentlichungsvorbereitung. Sie müssen insbesondere klären, welcheBestandteile neu entwickelt wurden, welche vorbestehenden 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 eineBereinigung 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 vonLizenzen 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 derOpen-Source-Definition der Open Source Initiative entspricht und keine erkennbarenSchwierigkeiten 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 oderBSD-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), dieElastic License 2.0 sowie verschiedene Creative-Commons-Lizenzen mit NC- oder ND-Einschränkungen.

Für Anbieter kommt es deshalb auf die konkrete Komponente undLizenzierung an. Der MongoDB Community Server steht in aktuellen Versionen grundsätzlich unter der SSPL. Bei Elasticsearch und Kibana ist die Lagedifferenzierter, weil erhebliche Teile des Quellcodes seit 2024 zusätzlich unter der AGPLv3 angeboten werden. Eine produkt- oder herstellerbezogenePauschalbetrachtung 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 eingesetztenLizenzen 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 rechtlicheGestaltung des Beschaffungsvorhabens abgeschlossen. Das Tool unterstützt dieAuswahl 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 bleibt beim Anwender.

Fazit

Die Überarbeitung der EVB-IT ist ein wichtiger Schritt für die öffentliche IT-Beschaffung. Open Source Software wird erstmals systematisch indie Vertragsmuster integriert. Bei neu erstellter Individualsoftware ist dieBereitstellung 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 rechtlichen und technischen Prüfungen entbehrlich.

Softwareanbieter sollten insbesondere klären, welche Bestandteile ihrerLö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 SBOMsin ihre Entwicklungs- und Releaseprozesse integrieren. BeiIndividualentwicklungen sind außerdem Kalkulation und Angebotsstrategie darauf auszurichten, dass die wirtschaftliche Wertschöpfung bei den betroffenenKomponenten weniger auf Exklusivität und stärker auf Entwicklung, Integration,Betrieb, Pflege und Support beruhen kann.

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.

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.

‍