Open Source in öffentlichen Ausschreibungen

Was das Gutachten ändert

Ein Gutachten des Bundestags-Wissenschaftsdienstes räumt die letzte vergaberechtliche Hürde für Open Source in Ausschreibungen weg. Was das für Vergabestellen und IAM-Projekte bedeutet und wie eine rechtssichere Anforderung konkret aussieht.

Inhaltsverzeichnis

Endlich dürfen Behörden Open Source verlangen, statt es nur zu hoffen

Bis vor kurzem steckten Vergabestellen in einer unangenehmen Lage. Wer eine Ausschreibung schrieb, musste sie technologieoffen halten und grundsätzlich jedes Angebot zulassen, das die geforderte Leistung erfüllte. Eine verpflichtende Open-Source-Vorgabe galt als rechtlich heikel, also formulierte man sicherheitshalber neutral. Das Ergebnis dieser Vorsicht war paradox. Eine Verwaltung, die aus guten Gründen einen quelloffenen Weg einschlagen wollte, wertete am Ende Angebote aus, unter denen auch geschlossene Produkte waren, und landete nicht selten genau dort, wo sie eigentlich nicht hinwollte. Der Wunsch nach digitaler Souveränität und die Regeln der Beschaffung zogen in unterschiedliche Richtungen.

Diese Zwickmühle hat der Wissenschaftliche Dienst des Bundestages jetzt aufgelöst.

Am 16. Juli 2026 wurde ein Gutachten bekannt, das die entscheidende Frage klärt. Dürfen öffentliche Auftraggeber quelloffene Software in einer Ausschreibung verbindlich vorschreiben? Die Antwort der Wissenschaftlichen Dienste fällt deutlich aus. Sie dürfen es, und in vielen Fällen spricht sogar mehr dafür als dagegen.

Was sich vergaberechtlich verschiebt

Der Kern ist schnell erzählt. Eine Open-Source-Anforderung in der Leistungsbeschreibung ist zulässig, solange sie sachlich gerechtfertigt, verhältnismäßig und transparent begründet wird. Das bleibt kein Freibrief. Eine Behörde, die Open Source verlangt, muss erklären können, warum diese Vorgabe der Sache dient. Wo geeignete quelloffene Angebote fehlen, empfiehlt das Gutachten weiterhin den Zusatz „oder gleichwertig“, damit der Wettbewerb offen bleibt.

Der wichtige Unterschied zur alten Praxis liegt an anderer Stelle. Früher musste die Vergabestelle die Tür für jedes technologische Angebot offenhalten und hoffen, dass am Ende das Richtige gewinnt. Künftig darf sie die gewünschte Eigenschaft von vornherein zur Bedingung machen, statt sie dem Zufall der Angebotslage zu überlassen. Das Gutachten geht sogar einen Schritt weiter und hält eine solche Vorgabe unter bestimmten Umständen für geboten, nicht nur für erlaubt.

Vier Gründe, die eine Open-Source-Vorgabe in Ausschreibungen rechtfertigen

Das Papier nennt mehrere Rechtfertigungen für eine Open-Source-Vorgabe, und sie decken sich auffällig gut mit dem, was wir aus IAM-Projekten kennen.

Der erste ist IT-Sicherheit. Quelloffener Code lässt sich prüfen, auditieren und unabhängig weiterentwickeln, während eine geschlossene Blackbox genau das verhindert. Gerade im Identitätsmanagement, wo eine einzige Software die Zugriffsrechte tausender Konten steuert, ist Nachvollziehbarkeit kein akademischer Luxus.

Dazu kommt die Interoperabilität. Offene Standards und dokumentierte Schnittstellen erleichtern die Anbindung an bestehende Systeme, was in gewachsenen Behördenlandschaften mit einem Dutzend Quellsystemen oft über Erfolg oder Dauerbaustelle entscheidet.

Am schwersten wiegt der dritte Punkt, die Herstellerabhängigkeit. Die jüngere Rechtsprechung des Europäischen Gerichtshofs verlangt von öffentlichen Auftraggebern, schon bei der Erstvergabe strategisch mitzudenken, ob eine Beschaffungsentscheidung künftige, wettbewerbsbeschränkende Abhängigkeiten begründet. Ein selbst herbeigeführter Vendor Lock-in reicht später regelmäßig nicht als Rechtfertigung für eine Direktvergabe ohne Teilnahmewettbewerb. Die eigentliche Pflicht liegt also darin, solche Abhängigkeiten von vornherein zu vermeiden. Genau das leistet Open Source, weil die Bindung an einen einzelnen Hersteller gar nicht erst entsteht.

Bleibt die langfristige Kosteneffizienz, bei der die Lizenzgebühr nur der sichtbare Teil ist. Teurer ist meist der Posten, der auf keiner Rechnung steht, nämlich die verlorene Verhandlungsmacht gegenüber einem Anbieter, der genau weiß, dass man nicht wechseln kann.

Das eigentliche Risiko einer proprietären IAM-Lösung ist nicht der Lizenzpreis von heute. Es ist die Rechnung, die kommt, wenn der Vertrag verlängert werden muss und es keine Alternative mehr gibt.

„Open Source ist ein Lizenzmodell, keine Technologie“

Peter Ganten, Vorstandsvorsitzender der Open Source Business Alliance, bringt die praktische Wirkung des Gutachtens auf den Punkt, wenn er sagt, es befreie Mitarbeitende in der Verwaltung von einer Unsicherheit, die sie lange gelähmt hat. Sein zweiter Gedanke wiegt schwerer, als er zunächst klingt. Open Source sei ein Lizenzmodell, nicht eine bestimmte Technologie, und daraus erst entstünden Transparenz und Resilienz.

Diese Unterscheidung räumt mit einem verbreiteten Missverständnis auf. Quelloffene Software ist nicht automatisch moderner oder sicherer programmiert als kommerzielle. Der Unterschied liegt in den Rechten, die eine Organisation an ihrer eigenen Software behält. Sie darf den Code einsehen, ändern, von einem anderen Dienstleister betreuen lassen und behält die Kontrolle auch dann, wenn der ursprüngliche Anbieter die Preise anzieht oder vom Markt verschwindet. Für eine Verwaltung, die Systeme über zehn oder fünfzehn Jahre betreibt, ist das ein handfestes Argument.

Warum uns das im IAM-Umfeld besonders angeht

Identity & Access Management ist ein Paradebeispiel für die Abhängigkeiten, die das Gutachten adressiert. Ein IAM-System sitzt an einer der sensibelsten Stellen der gesamten Infrastruktur. Es weiß, wer welche Rechte hat, provisioniert Konten in Fachverfahren, gleicht Bestände per Reconciliation ab und entzieht Zugriffe, sobald jemand die Organisation verlässt. Wer diese zentrale Schaltstelle an ein geschlossenes Produkt bindet, macht sich ausgerechnet dort abhängig, wo ein späterer Wechsel besonders aufwendig ist.

Wir sehen bei Hochschul- und Verwaltungskunden regelmäßig, dass die eigentliche Hürde selten die Lizenz ist. Es sind die Konnektoren und die Datenlogik dahinter. Wenn die Regeln, nach denen Identitäten korreliert und Rechte vergeben werden, in einem proprietären Format stecken, gehört einem die eigene Prozesslandschaft nur noch bedingt. Mit einer quelloffenen Plattform wie midPoint bleibt diese Logik einsehbar und übertragbar, was den Unterschied macht, sobald ein Dienstleister gewechselt oder ein System migriert werden soll.

Ehrlich bleiben gehört dazu. Open Source löst nicht jedes Problem, und der häufigste Grund dafür hat mit der Software selbst wenig zu tun. Er heißt Personalknappheit. Viele Organisationen müssen sich auf die Kompetenzen konzentrieren, die tatsächlich im Haus sind, und der eigenständige Betrieb einer quelloffenen IAM-Plattform gehört selten dazu. Genau deshalb haben wir bewusst auf Managed Services und SaaS gesetzt. So bekommt eine Hochschule oder eine Behörde die Vorteile einer offenen, herstellerunabhängigen Lösung, ohne dafür ein eigenes Betriebsteam aufbauen zu müssen. Das Gutachten zwingt niemanden zu Open Source. Es nimmt nur den Zwang weg, sehenden Auges bei einer Lösung zu landen, die man gar nicht wollte.

Von der neutralen Ausschreibung zur klaren Anforderung

Für Vergabestellen verschiebt sich mit diesem Gutachten die Ausgangslage spürbar. Bisher stand unter Rechtfertigungsdruck, wer Open Source verlangte. Künftig gerät eher in Erklärungsnot, wer eine zentrale Komponente bewusst an einen einzigen Hersteller bindet, obwohl quelloffene Alternativen bereitstehen. Eine sauber formulierte Anforderung benennt statt eines bestimmten Produkts die nachprüfbaren Eigenschaften, die man braucht, etwa offengelegten Quellcode, dokumentierte Schnittstellen und das Recht zur Weiterentwicklung durch Dritte. Damit lässt sich das gewünschte Ergebnis absichern, ohne die Tür für den echten Wettbewerb zwischen quelloffenen Anbietern zu schließen.

Digitale Souveränität war lange ein Wort für Sonntagsreden. Jetzt existiert eine juristische Grundlage, sie in konkrete Ausschreibungstexte zu übersetzen. Der Rahmen dafür war im Grunde schon da, das Gutachten macht ihn belastbar.

Sie wollen nicht länger warten und Ihre nächste Ausschreibung nicht wieder in der neutralen Notlösung enden lassen? Dann melden Sie sich jetzt über das Kontaktformular bei uns. Wir zeigen Ihnen, wie eine rechtssichere Open-Source-Anforderung in Ihrem IAM-Vorhaben konkret aussieht, von der Leistungsbeschreibung bis zum Betrieb.