Open-Source-Software ausschreiben: Lizenzen, Support und EVB-IT rechtssicher regeln

Die Fachanwendung läuft seit Jahren stabil, doch jede Erweiterung, jeder Schnittstellenzugang und jeder Versionswechsel führt zu neuen Abhängigkeiten vom bisherigen Hersteller. Nun soll eine Open-Source-Lösung beschafft werden. In der Vergabestelle stellt sich sofort die zentrale Frage: Kaufst du Software, beauftragst du einen Betriebspartner oder sicherst du dir vor allem die Kontrolle über Quellcode, Daten und Weiterentwicklung?

Open Source kann digitale Souveränität stärken, aber nur dann, wenn die Vergabeunterlagen sauber zwischen Softwarelizenz, Implementierung, Betrieb und Pflege unterscheiden. Der bloße Hinweis, dass eine Lösung „Open Source“ sein müsse, reicht nicht aus. Du musst festlegen, welche Rechte du benötigst, welche Leistungen der Auftragnehmer schuldet und wie der Übergang zu einem anderen Dienstleister funktioniert.

Infografik zu Open-Source-Software ausschreiben: Lizenzen, Support und EVB-IT rechtssicher regeln (KI-generiert).

Open Source als Beschaffungsziel präzise beschreiben

Eine offene Lizenz allein macht ein IT-Verfahren noch nicht herstellerunabhängig. Entscheidend ist, ob du die Lösung tatsächlich betreiben, prüfen, anpassen und durch andere Unternehmen weiterentwickeln lassen kannst.

Beschreibe daher zunächst dein Beschaffungsziel. Typische Anforderungen können sein:

• Die Software muss unter einer anerkannten Open-Source-Lizenz nutzbar sein.
• Der vollständige Quellcode der eingesetzten Version muss verfügbar sein.
• Die Vergabestelle muss die Software selbst oder durch beauftragte Dritte betreiben dürfen.
• Anpassungen und Erweiterungen müssen rechtlich zulässig und technisch möglich sein.
• Für Daten, Schnittstellen und Konfigurationen dürfen keine vermeidbaren Abhängigkeiten von proprietären Formaten entstehen.
• Der Auftragnehmer muss eine nachvollziehbare Dokumentation liefern.

Formuliere Anforderungen nicht allein mit Schlagworten wie „anbieterneutral“, „offen“ oder „zukunftssicher“. Beschreibe stattdessen konkrete Eigenschaften und Nachweise. Wenn du beispielsweise die Ablösung eines bisherigen Systems ermöglichen willst, sind dokumentierte Schnittstellen, exportierbare Daten und übertragbare Betriebsdokumentationen wesentlich aussagekräftiger als ein allgemeines Souveränitätsversprechen.

Eine produktspezifische Vorgabe kann vergaberechtlich zulässig sein, wenn sie sachlich gerechtfertigt ist. Häufig ist jedoch eine funktionale Leistungsbeschreibung der bessere Weg. Dann beschreibst du die benötigten Funktionen, Sicherheitsanforderungen, Integrationen und Betriebsprozesse. Falls du auf ein bestimmtes Produkt oder eine bestimmte technische Referenz verweisen musst, prüfst du sorgfältig, ob ein Gleichwertigkeitszusatz erforderlich ist.

Lizenzmodell und Nutzungsrechte getrennt regeln

Bei proprietärer Standardsoftware stehen häufig Lizenzumfang, Nutzerzahl und Laufzeit im Mittelpunkt. Bei Open Source verschieben sich die Fragen. Die Lizenz kann die Nutzung weitgehend erlauben, zugleich aber Pflichten bei Weitergabe, Änderungen oder Bereitstellung über ein Netzwerk auslösen.

Deshalb sollte deine Leistungsbeschreibung mindestens beantworten:

• Unter welcher Lizenz stehen die Kernsoftware und die einzelnen Komponenten?
• Welche Lizenz gilt für Anpassungen, Erweiterungen und individuell entwickelte Module?
• Darf die Vergabestelle Änderungen selbst vornehmen oder durch Dritte vornehmen lassen?
• Muss der Auftragnehmer Quellcode, Build-Skripte und Abhängigkeiten herausgeben?
• Welche Lizenzhinweise, Copyright-Vermerke und Lizenztexte sind zu dokumentieren?
• Welche Pflichten entstehen bei einer Weitergabe oder Veröffentlichung von Anpassungen?

Nicht jede Open-Source-Lizenz verfolgt dieselbe Logik. Permissive Lizenzen wie MIT- oder Apache-Lizenzen verlangen typischerweise vor allem den Erhalt von Hinweisen. Copyleft-Lizenzen wie die GNU GPL können weitergehende Anforderungen auslösen, wenn Software weitergegeben wird. Bei der GNU AGPL spielt zusätzlich die Bereitstellung über ein Netzwerk eine Rolle. Die EUPL ist insbesondere im europäischen öffentlichen Umfeld verbreitet und enthält eigene Regelungen zur Kompatibilität.

Du musst nicht jede Lizenz im Detail selbst auslegen. Du solltest aber verlangen, dass der Auftragnehmer ein Lizenzkonzept vorlegt. Dieses sollte alle eingesetzten Open-Source-Komponenten, ihre Versionen, Lizenztexte und daraus folgenden Pflichten enthalten. Ein Software-Stücklistenverzeichnis, häufig als Software Bill of Materials bezeichnet, hilft dir, Abhängigkeiten und Sicherheitsmeldungen später nachvollziehen zu können.

Wichtig ist auch die Lizenzierung individuell entwickelter Leistungen. Soll ein Dienstleister Erweiterungen programmieren, genügt es nicht, den Quellcode irgendwie zu erhalten. Du brauchst eine klare vertragliche Regelung, ob die Erweiterung unter derselben Open-Source-Lizenz wie das Ausgangsprojekt steht, unter einer kompatiblen Lizenz veröffentlicht wird oder dir umfassende Nutzungsrechte eingeräumt werden. Die gewünschte Regelung muss mit den Lizenzpflichten der Basiskomponenten vereinbar sein.

Leistungsbeschreibung: Software, Einführung und Betrieb aufteilen

In der Praxis scheitern Ausschreibungen oft daran, dass alle Leistungen in einer unscharfen Position „Open-Source-Software inklusive Support“ zusammengefasst werden. Das erschwert Vergleichbarkeit, Preiswertung und Vertragssteuerung.

Gliedere die Leistung stattdessen in sachlich getrennte Bestandteile:

Leistungsbereich	Typische Inhalte
Softwarebereitstellung	Bereitstellung der Software, Version, Dokumentation, Lizenzinformationen
Implementierung	Installation, Konfiguration, Migration, Schnittstellen, Tests
Betriebsunterstützung	Monitoring, Incident-Bearbeitung, Administration, Rufbereitschaft
Pflege und Wartung	Fehlerkorrekturen, Releases, Kompatibilitätsprüfungen, Sicherheitsupdates
Weiterentwicklung	Fachliche Erweiterungen, Anpassungen, Entwicklungsleistungen
Übergang und Exit	Datenexport, Dokumentation, Übergabe, Unterstützung beim Anbieterwechsel

Diese Struktur bedeutet nicht zwingend, dass du mehrere Verträge oder Lose bilden musst. Sie sorgt aber dafür, dass Bieter ihre Leistungen eindeutig kalkulieren und du die Erfüllung kontrollieren kannst.

Lege bei Betriebsleistungen fest, welche Systeme der Auftragnehmer verantwortet. Gehören Infrastruktur, Datenbank, Betriebssystem, Container-Plattform, Fachanwendung und Schnittstellen zum Leistungsumfang? Oder stellt der Auftragnehmer nur Second-Level-Support für die Anwendung bereit? Je klarer die Verantwortungsgrenzen beschrieben sind, desto weniger Streit entsteht bei Störungen.

Support, Wartung und Sicherheitsupdates verbindlich definieren

Open Source bedeutet nicht, dass es automatisch professionellen Support gibt. Gerade bei kritischen Fachverfahren solltest du daher nicht auf die Community allein vertrauen. Der Auftragnehmer muss konkret schulden, wie er Fehler bearbeitet, Sicherheitslücken bewertet und Updates bereitstellt.

Regle insbesondere:

• Supportzeiten und Kontaktwege
• Priorisierung von Störungen nach Auswirkung
• Reaktionszeiten und, soweit erforderlich, Wiederherstellungs- oder Lösungszeiten
• Verfahren für Eskalationen
• Verantwortlichkeiten bei Sicherheitsvorfällen
• Beobachtung relevanter Sicherheitsmeldungen
• Bewertung der Betroffenheit deiner eingesetzten Version
• Bereitstellung, Test und Einspielung von Sicherheitsupdates
• Information über abgekündigte Versionen und notwendige Upgrades

Unterscheide dabei zwischen Reaktionszeit und Behebungszeit. Eine schnelle Eingangsbestätigung hilft wenig, wenn unklar bleibt, wann ein kritischer Fehler tatsächlich analysiert, entschärft oder behoben wird. Fordere bei sicherheitsrelevanten Schwachstellen ein nachvollziehbares Verfahren mit Risikobewertung, Maßnahmenplan und Dokumentation.

Auch der Umgang mit Upstream-Projekten gehört in die Unterlagen. Der Auftragnehmer kann bei vielen Open-Source-Projekten nicht jede Korrektur selbst garantieren, weil Änderungen zunächst in der Entwicklergemeinschaft entstehen. Das entbindet ihn jedoch nicht von seiner vertraglichen Leistung. Er kann beispielsweise verpflichtet sein, Patches zu prüfen, sichere Zwischenmaßnahmen vorzuschlagen oder selbst eine Korrektur zu entwickeln, wenn dies erforderlich ist.

Gewährleistung nicht mit Community-Support verwechseln

Viele Open-Source-Lizenzen schließen Gewährleistung und Haftung des ursprünglichen Rechteinhabers weitgehend aus. Für deinen Vertrag mit dem erfolgreichen Bieter ist das aber nicht der Maßstab. Der Auftragnehmer schuldet die vereinbarte Leistung.

Definiere daher Abnahmekriterien für Implementierungs- und Anpassungsleistungen. Dazu können fachliche Testfälle, Lasttests, Sicherheitsprüfungen, Schnittstellentests und Dokumentationsprüfungen gehören. Halte fest, wann eine Leistung als abgenommen gilt und wie Mängel dokumentiert sowie nachgebessert werden.

Bei Standardsoftware, die lediglich bereitgestellt wird, ist die Vertragsgestaltung anders als bei einer individuell konfigurierten oder entwickelten Lösung. Gerade deshalb solltest du die Vertragsunterlagen passend auswählen. Für die dauerhafte Überlassung von Standardsoftware kommen etwa EVB-IT Überlassung Typ A und bei zeitlich begrenzter Überlassung EVB-IT Überlassung Typ B in Betracht. Für Pflegeleistungen ist EVB-IT Pflege S einschlägig, für Entwicklungs- und Beratungsleistungen häufig EVB-IT Dienstleistung. Komplexe Integrationsvorhaben können einen Systemvertrag erfordern.

Die EVB-IT-Vertragsmuster ersetzen keine Leistungsbeschreibung. Sie bilden den rechtlichen Rahmen, während du Leistungsumfang, Abnahme, Service Levels, Sicherheitsvorgaben und Lizenzanforderungen in Anlagen konkretisieren musst.

Exit-Regelungen von Beginn an einplanen

Herstellerbindung kann auch bei Open Source entstehen. Sie verlagert sich dann häufig auf Spezialwissen, individuelle Konfigurationen, proprietäre Erweiterungen oder unvollständige Betriebsdokumentationen. Deshalb gehören Exit-Regelungen nicht ans Ende der Vertragslaufzeit, sondern in die ursprüngliche Ausschreibung.

Fordere für den Übergang an dich oder einen Nachfolger mindestens:

• vollständige und aktuelle technische Dokumentation
• Konfigurationsdaten, Infrastrukturdefinitionen und Automatisierungsskripte
• Datenexport in einem dokumentierten, maschinenlesbaren Format
• Beschreibung der Datenstrukturen und Schnittstellen
• Zugang zu Quellcode-Repositories, soweit vereinbart
• Build- und Deployment-Anleitungen
• Liste der verwendeten Komponenten und Versionen
• Übergabegespräche sowie Unterstützung während einer angemessenen Transition

Definiere außerdem, wann diese Unterlagen zu liefern sind. Eine Übergabe erst am Vertragsende ist riskant. Besser ist es, Dokumentation und Quellcode fortlaufend als Liefergegenstände zu verlangen und in regelmäßigen Abständen zu prüfen.

Eignung und Zuschlag sinnvoll bewerten

Trenne Eignungsanforderungen von Zuschlagskriterien. Erfahrung des Unternehmens, personelle Ressourcen und vergleichbare Referenzen gehören grundsätzlich zur Eignung. Die Qualität des konkreten Betriebskonzepts, das Sicherheitsupdate-Verfahren oder die Übergabestrategie können dagegen Zuschlagskriterien sein, wenn sie sich auf die angebotene Leistung beziehen.

Bewertbar sind zum Beispiel:

• Plausibilität des Lizenz- und Compliance-Konzepts
• Qualität des Sicherheits- und Patchmanagements
• Vorgehen bei Migration und Datenübernahme
• Qualität der Betriebs- und Supportorganisation
• Umfang und Praktikabilität des Exit-Konzepts

Lege vorab fest, welche Inhalte du erwartest und wie du sie bewertest. Allgemeine Präsentationen mit Werbeaussagen sollten keine hohen Punktzahlen ermöglichen. Frage nach konkreten Prozessen, Rollen, Artefakten und Beispielen aus dem vorgesehenen Leistungsmodell.

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

Checkliste vor der Veröffentlichung

Prüfe deine Vergabeunterlagen abschließend anhand dieser Fragen:

• Ist klar, welche Open-Source-Lizenzen zulässig sind und welche Nachweise du verlangst?
• Sind Kernsoftware, Anpassungen und individuelle Erweiterungen lizenzrechtlich eindeutig geregelt?
• Sind Implementierung, Betrieb, Pflege und Weiterentwicklung voneinander abgegrenzt?
• Sind Supportzeiten, Störungsklassen und Sicherheitsupdate-Prozesse messbar beschrieben?
• Enthalten die Unterlagen Abnahmekriterien und Regeln zur Mängelbeseitigung?
• Passt der ausgewählte EVB-IT-Vertrag zu den tatsächlich beschafften Leistungen?
• Kannst du Daten, Konfigurationen, Dokumentation und Wissen bei Vertragsende übernehmen?
• Sind Eignungsanforderungen und Zuschlagskriterien vergaberechtlich sauber getrennt?

Eine rechtssichere Open-Source-Ausschreibung beschafft nicht nur eine Anwendung. Sie sichert dir die Fähigkeit, diese Anwendung langfristig zu betreiben, weiterzuentwickeln und bei Bedarf kontrolliert in andere Hände zu geben.