Open-Source-Software ausschreiben: Vergaberecht, Lizenzen und Herstellerneutralität

Die Fachabteilung möchte eine bekannte Open-Source-Lösung einführen, weil sie bereits in anderen Behörden oder Unternehmen genutzt wird. Gleichzeitig liegt ein Angebot eines Dienstleisters vor, der genau diese Lösung betreut. Für dich in der Vergabestelle beginnt damit die eigentliche Aufgabe: Du musst den Bedarf rechtssicher beschreiben, ohne die Ausschreibung auf ein bestimmtes Produkt, einen Hersteller oder eine einzelne Community zuzuschneiden.

Open-Source-Software kann digitale Souveränität stärken, Abhängigkeiten reduzieren und mehr Transparenz über technische Grundlagen schaffen. Sie ist vergaberechtlich aber kein Sonderfall, der eine direkte Beauftragung erleichtert. Auch bei quelloffener Software gelten Wettbewerb, Transparenz und Gleichbehandlung. Entscheidend ist deshalb nicht, ob ein Produkt als „Open Source“ bezeichnet wird, sondern welche Leistung du tatsächlich benötigst und wie du diese Leistung vergabekonform beschreibst.

Infografik zu Open-Source-Software ausschreiben: Vergaberecht, Lizenzen und Herstellerneutralität (KI-generiert).

Digitalen Souveränitätsbedarf konkret begründen

Digitale Souveränität ist ein legitimes Beschaffungsziel. Der Begriff allein ersetzt jedoch keine Leistungsbeschreibung. Wenn du Open-Source-Software bevorzugen möchtest, solltest du die dahinterstehenden Ziele in überprüfbare Anforderungen übersetzen.

Mögliche sachliche Ziele sind:

• Verfügbarkeit und Prüfbarbarkeit des Quellcodes
• Unabhängigkeit von einzelnen Herstellern oder proprietären Dateiformaten
• Möglichkeit, Betrieb, Wartung und Weiterentwicklung durch verschiedene Dienstleister zu vergeben
• Nutzung offener, dokumentierter Schnittstellen und Datenformate
• Sicherstellung der Datenportabilität bei einem Anbieterwechsel
• Nachvollziehbare Sicherheitsupdates und ein belastbares Schwachstellenmanagement
• Recht zur Anpassung der Software für eigene Zwecke oder durch beauftragte Dritte

Diese Ziele sind vergaberechtlich besser handhabbar als die bloße Vorgabe eines bestimmten Produkts. Formuliere also nicht: „Beschafft wird die Software X.“ Beschreibe stattdessen, welche fachlichen Prozesse, technischen Schnittstellen, Sicherheitsvorgaben und Betriebsleistungen benötigt werden.

Eine Anforderung wie „Der Auftragnehmer muss die Anpassung der eingesetzten Software durch Dritte ermöglichen“ kann zulässig sein, wenn sie für den späteren Betrieb erforderlich ist. Dagegen wäre es problematisch, wenn du ohne sachliche Begründung nur Dienstleister zulässt, die einen besonderen Community-Status oder eine Herstellerpartnerschaft nachweisen.

Funktional statt produktbezogen ausschreiben

Nach § 121 GWB muss die Leistungsbeschreibung eindeutig und erschöpfend sein. Für technische Spezifikationen gelten je nach Verfahren insbesondere die Vorgaben des § 31 VgV. Produkt- oder Herstellerbezeichnungen sind nur ausnahmsweise zulässig und müssen grundsätzlich mit dem Zusatz „oder gleichwertig“ versehen werden.

Bei Open-Source-Beschaffungen entsteht häufig ein Spannungsfeld: Die Vergabestelle kennt bereits eine konkrete Lösung und möchte deren Vorteile sichern. Dennoch darf die Ausschreibung nicht so formuliert sein, dass nur genau diese Software oder deren bisheriger Dienstleister in Betracht kommt.

Stattdessen arbeitest du mit funktionalen Anforderungen und nachvollziehbaren Mindestkriterien.

Beschaffungsziel	Problematische Formulierung	Bessere funktionale Formulierung
Datenportabilität	„Die Lösung muss Produkt X verwenden.“	„Die Lösung muss Daten in einem dokumentierten, maschinenlesbaren und ohne Lizenzhindernisse nutzbaren Format exportieren können.“
Erweiterbarkeit	„Der Bieter muss Kernentwickler der Community Y sein.“	„Der Bieter muss nachweisen, dass er Fehler analysieren, Sicherheitsupdates einspielen und erforderliche Anpassungen am Quellcode umsetzen kann.“
Schnittstellen	„Es ist die Schnittstelle des Herstellers Z zu nutzen.“	„Die Lösung muss die benannte Fachanwendung über dokumentierte, standardisierte oder offen dokumentierte Schnittstellen anbinden.“
Betrieb	„Gesucht wird Support für Produkt X.“	„Gesucht wird ein Betriebs-, Wartungs- und Supportmodell für eine Lösung, die die beschriebenen fachlichen und technischen Anforderungen erfüllt.“

Wenn du eine vorhandene Systemlandschaft berücksichtigen musst, darfst du konkrete Integrationsanforderungen benennen. Wichtig ist, dass du den Zusammenhang dokumentierst. Beispielsweise kann eine bestehende Fachanwendung nur bestimmte Schnittstellen unterstützen oder ein Migrationsprojekt erfordert eine bestimmte Datenstruktur. Dann ist die Einschränkung nicht willkürlich, sondern aus dem Beschaffungsgegenstand abgeleitet.

Lizenzpflichten bereits in der Vergabe prüfen

„Open Source“ bedeutet nicht „rechtsfrei“ oder „ohne Pflichten“. Die konkrete Lizenz entscheidet darüber, was die Vergabestelle, der Auftragnehmer und spätere Dritte mit der Software tun dürfen und müssen.

Bei der Beschaffung solltest du mindestens klären:

• Unter welcher Lizenz stehen die eingesetzten Komponenten?
• Gilt eine einheitliche Lizenz oder besteht die Lösung aus Komponenten mit unterschiedlichen Lizenzen?
• Welche Pflichten entstehen bei Verbreitung, Anpassung oder Weitergabe?
• Muss der Quellcode bestimmter Änderungen offengelegt werden?
• Müssen Lizenztexte, Urhebervermerke oder Hinweise in Dokumentationen und Benutzeroberflächen erhalten bleiben?
• Dürfen Auftragnehmer und Unterauftragnehmer den Quellcode bearbeiten?
• Wer prüft, ob zusätzliche Bibliotheken oder Module mit den eingesetzten Lizenzen vereinbar sind?

Besondere Aufmerksamkeit verdienen sogenannte Copyleft-Lizenzen. Sie können bei Weitergabe oder Verteilung von bearbeiteter Software Verpflichtungen auslösen, etwa zur Bereitstellung des korrespondierenden Quellcodes unter bestimmten Bedingungen. Ob und wann eine solche Pflicht entsteht, hängt vom Lizenztext und vom konkreten Nutzungsszenario ab. Eine bloße Nutzung innerhalb der eigenen Organisation ist rechtlich anders zu bewerten als die Weitergabe an Dritte oder der Betrieb einer Lösung für externe Nutzer.

Du solltest deshalb keine pauschale Klausel verwenden, wonach „alle Open-Source-Lizenzen zulässig“ seien. Sinnvoller ist ein Lizenzkonzept als Vergabeunterlage. Der Bieter legt darin offen, welche Komponenten er einsetzt, unter welchen Lizenzen diese stehen und wie er die Lizenzpflichten erfüllt.

Bei komplexeren Projekten kann außerdem ein Software Bill of Materials sinnvoll sein. Darin werden die verwendeten Softwarekomponenten, Versionen und Lizenzinformationen dokumentiert. Das unterstützt nicht nur die Lizenz-Compliance, sondern auch das Schwachstellenmanagement.

Support und Wartung getrennt von der Software denken

Der Quellcode kann frei verfügbar sein, der professionelle Betrieb ist es nicht. Gerade bei Open-Source-Software beschaffst du häufig weniger eine klassische Softwarelizenz als Dienstleistungen: Implementierung, Migration, Betrieb, Support, Wartung, Schulung und Weiterentwicklung.

Beschreibe diese Leistungen getrennt und konkret. Sonst bleibt offen, was der Auftragnehmer tatsächlich schuldet.

Für das Supportmodell gehören typischerweise folgende Punkte in die Vergabeunterlagen:

• Supportzeiten und erreichbare Kontaktwege
• Reaktionszeiten nach Prioritätsstufen
• Wiederherstellungs- oder Lösungszeiten, soweit diese sinnvoll vereinbart werden können
• Verfahren zur Klassifizierung von Störungen
• Regelungen für Sicherheitsvorfälle und kritische Schwachstellen
• Update-, Patch- und Release-Management
• Dokumentationspflichten
• Qualifikation des eingesetzten Personals
• Umgang mit Unterauftragnehmern
• Regelmäßige Berichte über Störungen, Änderungen und Sicherheitsupdates

Formuliere dabei nicht nur allgemeine Erwartungen wie „zeitnaher Support“. Lege fest, woran die Leistung messbar ist. Eine Reaktionszeit beschreibt beispielsweise, wann der Auftragnehmer die Bearbeitung aufnimmt. Sie ist nicht automatisch eine Zusage, dass der Fehler innerhalb dieser Zeit behoben wird. Diese Unterscheidung verhindert spätere Streitigkeiten.

Für Verträge im öffentlichen Bereich können die EVB-IT eine geeignete Grundlage sein. Welches Vertragsmuster passt, hängt vom Beschaffungsgegenstand ab: Für Dienstleistungen, Pflege, Systemlieferung oder Überlassung kommen unterschiedliche Regelungsmodelle in Betracht. Die Besonderheiten der Open-Source-Lizenzen müssen dabei zusätzlich geprüft und in den Vertrag integriert werden. Standardklauseln ersetzen keine Lizenzanalyse.

Passende Seminare und Termine findest du bei uns auf cmt.de.

Sicherheitsupdates und Schwachstellenmanagement verbindlich regeln

Open-Source-Software bietet den Vorteil, dass Sicherheitslücken häufig öffentlich nachvollziehbar sind. Das entbindet die Vergabestelle aber nicht davon, Zuständigkeiten zu definieren. Gerade bei frei verfügbaren Komponenten bleibt sonst unklar, wer Sicherheitsmeldungen beobachtet, Updates bewertet und Patches einspielt.

Lege im Vertrag fest:

• Wer überwacht Sicherheitsmeldungen und bekannte Schwachstellen?
• Welche Quellen und Verfahren nutzt der Auftragnehmer?
• Nach welchen Kriterien werden Schwachstellen priorisiert?
• Innerhalb welcher Fristen werden kritische Sicherheitsupdates bewertet und umgesetzt?
• Wer entscheidet über Updates, die Auswirkungen auf Schnittstellen oder Fachprozesse haben?
• Wie werden Notfallmaßnahmen, Rollback und Kommunikation organisiert?
• Welche Nachweise erhält die Vergabestelle über durchgeführte Updates?

Auch die Laufzeit ist relevant. Wenn eine Version nur begrenzt gepflegt wird, kann ein günstiges Angebot langfristig erhebliche Risiken verursachen. Fordere deshalb Angaben zur Release- und Wartungsstrategie. Der Bieter muss nicht die Zukunft einer gesamten Community garantieren können. Er kann aber darstellen, wie er bei ausbleibenden Updates, Projektabbrüchen oder kritischen Sicherheitslücken handlungsfähig bleibt.

Exit-Rechte und Weiterentwicklung absichern

Digitale Souveränität zeigt sich besonders beim Vertragsende. Wenn nach Ablauf des Vertrags niemand außer dem bisherigen Auftragnehmer die Lösung betreiben oder weiterentwickeln kann, besteht trotz Open Source ein faktischer Lock-in.

Regle deshalb frühzeitig die Exit-Situation. Die Vergabestelle sollte insbesondere Zugriff auf die für den Betrieb notwendigen Informationen erhalten. Dazu gehören Konfigurationen, Dokumentationen, Schnittstellenbeschreibungen, Datenmodelle, Betriebshandbücher, Automatisierungsskripte und gegebenenfalls individuell entwickelte Erweiterungen.

Wichtig ist die Unterscheidung zwischen bereits vorhandener Open-Source-Software und neu erstellten Leistungen des Auftragnehmers. Für individuelle Anpassungen, Konfigurationen oder Schnittstellen solltest du Nutzungsrechte so vereinbaren, dass du diese nach Vertragsende selbst nutzen, ändern und durch Dritte weiterentwickeln lassen kannst. Es genügt nicht, wenn du die Ergebnisse nur im bisherigen System weiterverwenden darfst.

Ein belastbares Exit-Konzept beantwortet mindestens diese Fragen:

• Welche Daten werden in welchem Format übergeben?
• Welche Dokumentationen und Zugangsinformationen erhält die Vergabestelle?
• Welche Unterstützung schuldet der Auftragnehmer beim Übergang?
• Dürfen Dritte die Anpassungen übernehmen und fortentwickeln?
• Wie wird sichergestellt, dass keine vertraulichen Informationen oder personenbezogenen Daten beim bisherigen Dienstleister verbleiben?
• Welche Mitwirkungspflichten gelten für den Wechsel?

Checkliste vor Veröffentlichung der Ausschreibung

Prüfe vor der Bekanntmachung, ob du die folgenden Punkte belastbar beantworten kannst:

• Ist der Bedarf funktional beschrieben und dokumentiert?
• Sind produktbezogene Anforderungen sachlich begründet?
• Ist bei ausnahmsweise genannten Produkten oder Standards die Gleichwertigkeit geregelt?
• Sind Lizenzarten, Lizenzpflichten und Nachweise eindeutig benannt?
• Werden Support, Wartung, Sicherheitsupdates und Weiterentwicklung als konkrete Leistungen beschrieben?
• Sind Eignungskriterien von den Zuschlagskriterien getrennt?
• Werden keine unnötigen Hersteller-, Partner- oder Community-Nachweise verlangt?
• Sind Datenherausgabe, Dokumentation und Übergangsunterstützung für das Vertragsende geregelt?
• Können andere qualifizierte Dienstleister die Lösung nach Vertragsende betreiben und weiterentwickeln?

Eine gute Open-Source-Ausschreibung beschafft nicht bloß Software. Sie schafft die Voraussetzungen dafür, dass du die Lösung dauerhaft sicher, rechtssicher und unabhängig betreiben kannst.