Eine Verwaltung darf in einer IT-Ausschreibung Open Source verlangen. Nicht immer, nicht als Bauchgefühl und schon gar nicht als politischer Sticker auf einer schlecht geschriebenen Leistungsbeschreibung. Aber sie darf. Genau das macht ein Gutachten der Wissenschaftlichen Dienste des Bundestages jetzt ziemlich deutlich.
Der sperrige Titel des Papiers lautet: „Vergabeverfahren zur Bereitstellung, Entwicklung und Änderung von Computersoftware“. Dahinter steckt eine Frage, die in deutschen Behörden seit Jahren wie ein schlecht kommentiertes Shell-Skript herumliegt: Darf der Staat in Ausschreibungen ausdrücklich quelloffene Software fordern, oder verletzt er damit die Produktneutralität?
Die kurze Antwort: Ja, Open Source First ist vergaberechtlich möglich. Die längere Antwort ist interessanter. Das Gutachten sagt nicht: „Nehmt immer Open Source, fertig.“ Es sagt: Eine Beschränkung auf Open-Source-Software kann zulässig sein, wenn sie sachlich begründet, verhältnismäßig, transparent dokumentiert und am konkreten Auftrag ausgerichtet ist.
Für die öffentliche IT ist das mehr als eine juristische Fußnote. Es geht um Vendor Lock-in, um digitale Souveränität, um langfristige Wartbarkeit und um die ziemlich banale Frage, warum eine Behörde Software bezahlen soll, deren Quellcode sie am Ende nicht prüfen, anpassen oder weitergeben darf.
Wir bei digital-magazin.de haben uns das Gutachten, die Reaktionen der Open-Source-Szene und die vergaberechtlichen Knackpunkte genauer angeschaut. Das Ergebnis: Das Papier räumt einen alten Mythos ab, aber es ersetzt keine saubere Beschaffung. Wer Open Source in Behörden wirklich will, muss besser ausschreiben, nicht nur lauter fordern.
Open Source First heißt nicht: Lieblingsprojekt bevorzugen
Der wichtigste Punkt zuerst: Open Source ist keine Marke. Es ist auch kein einzelnes Produkt, kein Anbieter und kein netter Community-Aufkleber fürs Laptop. Open Source beschreibt ein Lizenz- und Entwicklungsmodell, bei dem der Quellcode einsehbar ist und Nutzende die Software verwenden, prüfen, ändern und weiterverbreiten dürfen.
Genau deshalb ist die Beschränkung auf Open Source vergaberechtlich anders zu bewerten als eine Ausschreibung, die faktisch nur auf ein bestimmtes Produkt passt. Eine Behörde darf nicht einfach „Produkt X von Hersteller Y“ verlangen, wenn es dafür keinen belastbaren Grund gibt. Sie darf aber Anforderungen formulieren, die mit offenen Lizenzbedingungen, Auditierbarkeit, Weiterentwicklungsrechten oder Interoperabilität zu tun haben.
Das Gutachten arbeitet dabei mit dem klassischen Spannungsfeld des Vergaberechts. Auf der einen Seite stehen Wettbewerb, Gleichbehandlung und Transparenz. Auf der anderen Seite darf der öffentliche Auftraggeber seinen Beschaffungsbedarf definieren. Wenn eine Behörde also begründen kann, warum offener Quellcode für Sicherheit, Anpassbarkeit oder langfristige Unabhängigkeit nötig ist, wird Open Source nicht automatisch zum Wettbewerbsverstoß.
Oder trockener gesagt: Die Verwaltung muss erklären können, warum sie Open Source braucht. Sie muss nicht so tun, als seien Lizenzmodell und Quellcodezugang technisch egal.
Das passt zu dem, was wir schon im Artikel über typische Vorurteile gegenüber Open Source in Unternehmen und Behörden beschrieben haben. Die alte Gleichung „offen gleich unsicher, proprietär gleich professionell“ hält der Praxis nicht stand. Sie war nie besonders gut, aber immerhin langlebig.
Die 7 Folgen für Behörden und Anbieter
Die rechtliche Einordnung ist spannend. Noch spannender ist, was sie in der Praxis auslöst. Denn Vergaberecht klingt nach Aktenordner, entscheidet aber darüber, welche Software Verwaltungen über Jahre bindet.
1. Behörden bekommen mehr Spielraum
Viele öffentliche Stellen haben Open Source bisher defensiv behandelt. Nicht aus technischer Abneigung, sondern aus Angst vor Rügen, Nachprüfungsverfahren oder dem Vorwurf, sie würden den Wettbewerb beschränken. Dieses Gutachten nimmt dieser Angst einiges an Schärfe.
Behörden können künftig selbstbewusster formulieren, dass sie offenen Quellcode, offene Schnittstellen, Änderungsrechte oder bestimmte Lizenzfreiheiten brauchen. Sie müssen den Bedarf aber sauber aus dem Auftrag herleiten. Ein Fachverfahren mit langer Laufzeit, sensiblen Daten und vielen Schnittstellen hat andere Anforderungen als eine kleine Standardsoftware für einen begrenzten Zweck.
Für IT-Leitungen ist das eine gute Nachricht. Sie müssen nicht mehr in jeder Ausschreibung so tun, als sei der spätere Betrieb völlig unabhängig von Lizenzbedingungen, Quellcodezugang und Migrationsfähigkeit. Wer jahrelang Systeme betreiben muss, weiß: Diese Dinge werden spätestens beim nächsten Anbieterwechsel teuer.
2. Der Vendor Lock-in wird zum Vergaberisiko
Das Gutachten verweist auf eine Entwicklung, die viele Verwaltungen lieber früher ernst genommen hätten. Wer sich bei der ersten Beschaffung sehenden Auges in eine exklusive Abhängigkeit bringt, kann später nicht dauerhaft behaupten, nur der bisherige Anbieter könne die Software pflegen oder erweitern.
Genau hier wird Open Source zum strategischen Werkzeug. Offener Quellcode verhindert Lock-in nicht automatisch. Schlechte Architektur bleibt schlechte Architektur, auch mit freier Lizenz. Aber Open Source senkt die Hürden für Wartung, Prüfung und Anbieterwechsel. Eine Behörde kann Dienstleister austauschen, ohne jedes Mal den gesamten technischen Besitzstand neu zu verhandeln.
Die Open Source Business Alliance bewertet das Gutachten deshalb als Signal für Open Source First. Das ist erwartbar, weil der Verband genau diese Linie seit Jahren vertritt. Aber der Kern stimmt: Vergaberecht belohnt nicht nur den billigsten Einkauf, sondern auch eine nachvollziehbare Strategie gegen spätere Abhängigkeiten.
3. „Oder gleichwertig“ bleibt der juristische Sicherheitsgurt
Wer Open Source ausschreibt, ist nicht automatisch aus der Produktneutralität entlassen. Das Gutachten macht klar, dass pauschale oder unscharfe Vorgaben riskant bleiben. Besonders im Kartellvergaberecht kann eine Beschränkung in der Leistungsbeschreibung als produkt- oder herkunftsbezogene Begrenzung gewertet werden.
Praktisch heißt das: Wenn eine Behörde Merkmale verlangt, die bestimmte Unternehmen oder Produkte ausschließen, braucht sie objektive Gründe. In vielen Fällen wird der Zusatz „oder gleichwertig“ eine Rolle spielen. Der darf aber nicht zum Feigenblatt werden. Gleichwertigkeit muss messbar sein, sonst schreibt man eine offene Tür an eine Wand.
Rechtlich hängt das unter anderem an § 31 VgV, der produktbezogene Vorgaben in der Leistungsbeschreibung nur unter engen Bedingungen zulässt. Unterhalb der EU-Schwellenwerte zeigt § 23 UVgO für die Leistungsbeschreibung im Unterschwellenbereich in eine ähnliche Richtung. Kurz: Open Source darf gefordert werden, aber nicht schlampig.
Für Beschaffungsstellen ist das anstrengend. Für den Markt ist es fair. Denn ein proprietärer Anbieter kann unter Umständen eine gleichwertige Lösung anbieten, wenn die Behörde nicht den Quellcode selbst, sondern bestimmte Rechte, Schnittstellen oder Kontrollmöglichkeiten verlangt. Manchmal wird das reichen. Manchmal nicht.
4. Wirtschaftlichkeit wird langfristiger gedacht
In IT-Projekten wird Wirtschaftlichkeit gern beim Anschaffungspreis verengt. Das ist bequem und meistens falsch. Eine Lizenz kann im ersten Jahr günstig wirken und über fünf Jahre trotzdem teuer werden, wenn Migration, Schnittstellen, Vertragsbindung, Audit-Aufwand und fehlende Änderungsrechte mitgerechnet werden.
Das Gutachten betont, dass im Haushaltsvergaberecht Wirtschaftlichkeit und Sparsamkeit besonders schwer wiegen. Genau diese Grundsätze können eine bevorzugte Berücksichtigung von Open Source stützen, wenn offene Lösungen langfristig Kosten, Abhängigkeiten oder Migrationsaufwände reduzieren.
Das ist der Punkt, an dem Open Source aus der Idealismus-Ecke herauskommt. Es geht nicht darum, proprietäre Software moralisch abzustrafen. Es geht darum, die echten Lebenszykluskosten zu sehen. Wer eine Fachanwendung beschafft, kauft nicht nur Software. Er kauft Pflege, Anpassbarkeit, Datenmigration, Integrationsfähigkeit und die Möglichkeit, bei Problemen nicht mit verschränkten Armen auf einen Hersteller zu warten.
Die Suchdaten zeigen übrigens, dass das Thema längst nicht nur Verwaltungskreise interessiert. Laut unserer DataForSEO-Abfrage kommt „Open Source“ in Deutschland auf rund 9.900 monatliche Suchanfragen, „Open Source Software“ auf 3.600 und „digitale Souveränität“ ebenfalls auf 3.600. Das ist kein Massenthema wie „Linux“ mit 60.500 Suchanfragen, aber für IT-Entscheidungen erstaunlich präsent.
Warum digitale Souveränität plötzlich sehr konkret wird
Digitale Souveränität ist ein Wort, das in politischen Papieren oft klingt, als hätte jemand drei Konferenzfolien zu lange geredet. Beim Thema Open Source wird es konkret. Kann eine Behörde prüfen, was eine Software tut? Kann sie eine kritische Komponente weiterpflegen lassen, wenn der ursprüngliche Anbieter ausfällt? Kann sie Daten in ein anderes System migrieren, ohne jedes Mal einen Lizenzvertrag zu sezieren?
Genau solche Fragen entscheiden darüber, ob öffentliche IT souverän ist oder nur souverän klingt. Ein offener Quellcode allein löst noch kein organisatorisches Problem. Ohne internes Know-how, Dienstleistermarkt, Sicherheitsprozesse und Pflegebudget bleibt Open Source ein Versprechen auf Papier.
Aber ohne Zugriff auf Quellcode und Nutzungsrechte wird es eben noch schwerer. Deshalb ist die Verbindung aus Open Source, offenen Standards und professioneller Wartung so wichtig. Im Beitrag zur Datenstrategie und digitaler Souveränität haben wir bereits beschrieben, warum offene Systeme vor allem dann wirken, wenn Organisationen sie aktiv beherrschen.
Mal ehrlich: Eine Verwaltung, die sich über Jahrzehnte in proprietäre Speziallösungen einmauert, bekommt irgendwann kein Beschaffungsproblem mehr. Sie bekommt ein Freiheitsproblem.
5. Open Source-Anbieter müssen professioneller auftreten
Das Gutachten ist auch ein Wink an die Open-Source-Wirtschaft. Wenn Behörden künftig häufiger Open Source verlangen dürfen, reicht der Hinweis auf die Lizenz nicht mehr. Anbieter müssen Vergabeunterlagen, Supportmodelle, Security-Prozesse, Dokumentation, Service-Level und Referenzen liefern können.
Das ist gesund. Öffentliche Verwaltung braucht nicht romantische Projektwebseiten, sondern belastbare Lieferfähigkeit. Wer Open Source professionell anbietet, kann hier punkten: mit nachvollziehbaren Wartungswegen, transparenten Beitragsmodellen, Auditierbarkeit und klaren Verantwortlichkeiten.
Gleichzeitig wird der Markt breiter. Wenn nicht nur der ursprüngliche Hersteller Änderungen liefern kann, entstehen Chancen für mittelständische Dienstleister, spezialisierte Beratungen und regionale IT-Unternehmen. Vorausgesetzt, die Ausschreibung ist so geschrieben, dass diese Unternehmen auch realistisch bieten können.
6. Proprietäre Anbieter müssen ihre Argumente schärfen
Für proprietäre Softwarehäuser ist das kein Weltuntergang. Aber es ist unbequem. Wer bisher mit „das war schon immer so“ oder „nur wir können das System pflegen“ durchkam, muss künftig besser erklären, warum geschlossene Software im konkreten Fall die bessere Wahl ist.
Das kann sie durchaus sein. Es gibt Fachverfahren, Spezialanwendungen und Integrationsszenarien, in denen proprietäre Produkte fachlich, wirtschaftlich oder organisatorisch überzeugen. Das Gutachten verbietet sie nicht. Es zwingt Behörden aber dazu, Abhängigkeiten nicht als Naturgesetz zu behandeln.
Proprietäre Anbieter könnten darauf reagieren, indem sie mehr Schnittstellen öffnen, Quellcode-Hinterlegung anbieten, Exit-Rechte verbessern oder modulare Architekturen liefern. Anders gesagt: Wer geschlossen bleiben will, muss wenigstens beweisen, dass die Tür im Notfall aufgeht.
7. Beschaffung wird politischer, aber hoffentlich präziser
Open Source First ist ein politischer Begriff. Vergaberechtlich trägt er aber nur, wenn er in konkrete Anforderungen übersetzt wird. „Wir wollen Open Source“ ist noch keine Leistungsbeschreibung. „Die Software muss unter einer anerkannten Open-Source-Lizenz stehen, der Quellcode muss vollständig zugänglich sein, Änderungen müssen ohne Zustimmung eines einzelnen Herstellers möglich sein, Schnittstellen müssen dokumentiert werden“ kommt der Sache näher.
Genau hier entscheidet sich, ob das Gutachten praktische Wirkung entfaltet. Die Verwaltung braucht bessere Mustertexte, mehr Schulung und Beschaffungsteams, die IT-Architektur verstehen. Sonst landet Open Source First in derselben Schublade wie viele schöne Digitalstrategien: gut gemeint, mittelmäßig umgesetzt.
Was das Gutachten rechtlich wirklich sagt
Die Wissenschaftlichen Dienste formulieren vorsichtig, wie es sich für ein juristisches Gutachten gehört. Eine Beschränkung öffentlicher Aufträge auf Open Source ist demnach weder generell unzulässig noch uneingeschränkt zulässig. Entscheidend ist der Einzelfall.
Im Oberschwellenbereich, also bei größeren Vergaben mit EU-Bezug, greifen die Regeln des Kartellvergaberechts. Dazu gehören die Grundsätze aus § 97 GWB zu Wettbewerb, Transparenz, Wirtschaftlichkeit und Gleichbehandlung. Eine Leistungsbeschreibung darf den Wettbewerb nicht ohne Grund verengen.
Aber: Der Auftraggeber darf seinen Bedarf beschreiben. Wenn IT-Sicherheit, Interoperabilität, langfristige Weiterentwicklungsfähigkeit oder die Vermeidung von Vendor Lock-in sachlich für Open Source sprechen, kann die Vorgabe zulässig sein. Wichtig ist die Dokumentation. Behörden müssen später zeigen können, warum die Anforderung notwendig war.
Im Unterschwellenbereich gilt ein etwas anderer Rechtsrahmen, aber kein Freifahrtschein. Auch dort muss die Leistungsbeschreibung klar, vergleichbar und fair sein. Gleichzeitig treten Wirtschaftlichkeit und Sparsamkeit stärker hervor. Das kann Open Source helfen, wenn die Verwaltung plausible Lebenszykluskosten vorlegt.
Die Heise-Meldung zum Bundestags-Gutachten ordnet das als wichtige Klarstellung für Behörden ein. Die Computerwoche hebt zusätzlich den Zusammenhang mit Vendor Lock-in und digitaler Souveränität hervor. Beides trifft den Kern, solange man die Grenzen nicht unterschlägt.
Der EuGH-Faktor: selbst gemachte Abhängigkeit zählt nicht mehr so leicht
Ein besonders interessanter Teil ist der Bezug zur neueren Rechtsprechung des Europäischen Gerichtshofs. Die Botschaft ist unangenehm für Verwaltungen, die jahrelang Abhängigkeiten aufgebaut haben und dann bei Folgeaufträgen sagen: Leider kann das nur unser bisheriger Anbieter.
Der EuGH schaut strenger darauf, ob eine solche Ausschließlichkeit wirklich unvermeidbar war oder ob der Auftraggeber sie selbst geschaffen hat. Genau deshalb wird die Erstvergabe wichtiger. Wer dort keine Exit-Rechte, keine offenen Schnittstellen, keinen Quellcodezugang und keine Anbieterwechsel-Optionen einplant, baut das spätere Problem gleich mit ein.
Open Source kann diese Spirale brechen. Nicht magisch. Aber praktisch. Wenn Code, Dokumentation und Rechte offen genug sind, sinkt die Wahrscheinlichkeit, dass jede spätere Änderung nur noch über einen einzigen Anbieter laufen kann.
Für Behörden heißt das: Eine gute Ausschreibung denkt den nächsten Betreiberwechsel mit. Für Anbieter heißt es: Lock-in als Geschäftsmodell wird juristisch ungemütlicher.
Open Source ist kein Sicherheitsbonus per Lizenz
Ein häufiger Fehler in der Debatte: Open Source wird wahlweise als Sicherheitsrisiko oder als Sicherheitsgarantie behandelt. Beides ist Unsinn. Offener Quellcode kann geprüft werden. Das heißt nicht, dass ihn automatisch jemand prüft.
Für Behörden liegt der Vorteil in der Möglichkeit zur Kontrolle. Code-Audits, reproduzierbare Builds, externe Sicherheitsprüfungen, Community-Reviews und unabhängige Wartung sind leichter, wenn der Quellcode zugänglich ist. Aber diese Möglichkeiten kosten Arbeit und Geld.
Gerade bei kritischen Systemen ist das relevant. Wie schnell aus Software-Lieferketten ein Behördenproblem werden kann, zeigte etwa unser Beitrag zum Supply-Chain-Angriff auf EU-Institutionen über Behördensoftware. Transparenz ersetzt kein Sicherheitsmanagement. Sie macht es aber weniger blind.
Was Behörden jetzt in Ausschreibungen ändern sollten
Aus dem Gutachten lassen sich einige sehr praktische Regeln ableiten. Erstens: Open Source nicht als Glaubenssatz formulieren, sondern als Bedarf. Warum braucht die Behörde offenen Quellcode? Geht es um Auditierbarkeit, Anpassbarkeit, Weitergabe an andere Behörden, offene Schnittstellen oder Unabhängigkeit von einzelnen Herstellern?
Zweitens: Anforderungen messbar machen. Eine Ausschreibung sollte nicht nur „Open Source“ sagen, sondern Lizenz, Quellcodezugang, Build-Prozess, Dokumentation, Änderungsrechte, Schnittstellen und Wartungsmodell beschreiben. Je klarer die Kriterien, desto geringer das Rüge-Risiko.
Drittens: Lebenszykluskosten einrechnen. Lizenzkosten sind nur ein Teil. Migration, Betrieb, Schulung, Support, Sicherheitsupdates, Exit-Szenarien und spätere Erweiterungen gehören dazu. Genau hier können offene Lösungen stark sein, aber nur, wenn die Verwaltung nicht am falschen Ende spart.
Viertens: „oder gleichwertig“ ernst nehmen. Wenn eine gleichwertige Lösung ohne offene Lizenz tatsächlich denselben Zweck erfüllt, muss die Behörde sie prüfen. Wenn nicht, muss sie sauber begründen, warum Offenheit selbst Teil der Leistung ist.
Fünftens: Kompetenz aufbauen. Eine schlechte Open-Source-Ausschreibung ist nicht besser als eine schlechte proprietäre Ausschreibung. Sie ist nur anders schlecht.
Und jetzt?
Das Bundestags-Gutachten ist kein Gesetz und keine automatische Open-Source-Pflicht. Es ist aber eine hilfreiche Klarstellung für alle, die öffentliche IT aus der Dauerabhängigkeit von einzelnen Herstellern holen wollen.
Mein Eindruck: Der größte Effekt liegt nicht darin, dass morgen jede Behörde Linux-Desktops ausrollt. Das wäre auch eine ziemlich platte Lesart. Der wichtige Punkt ist, dass Beschaffungsteams Open Source künftig offensiver als fachliche Anforderung behandeln können. Nicht als Ausnahme, nicht als Hobby, sondern als legitimes Mittel gegen Lock-in, Intransparenz und teure Folgeverträge.
Der Staat muss dafür allerdings erwachsen beschaffen. Open Source First ist kein Zauberspruch. Es ist eine Architekturentscheidung mit juristischem Beipackzettel. Wer den liest, bekommt mehr Freiheit. Wer ihn ignoriert, bekommt nur die nächste Vergabepanne mit besserem Logo.
