Open Source als trojanisches Pferd : Lizenzrisiken in der Softwarelieferkette

Die unsichtbare Abhängigkeit

Über 90 Prozent aller modernen Softwareprodukte enthalten Open-Source-Komponenten. Was auf den ersten Blick als kostengünstige und innovative Lösung erscheint, birgt erhebliche rechtliche Risiken. Denn Open-Source-Software (OSS) ist keineswegs „frei" im Sinne von „ohne Bedingungen". Jede OSS-Komponente unterliegt einer Lizenz, die präzise Pflichten definiert -- und deren Verletzung gravierende Konsequenzen haben kann.

Für Unternehmen, die Software entwickeln, integrieren oder vertreiben, ist die Kenntnis und Einhaltung von Open-Source-Lizenzen keine optionale Best Practice, sondern eine zwingende rechtliche Notwendigkeit. Die Risiken reichen von Unterlassungsansprüchen über Schadensersatzforderungen bis hin zum Verlust eigener Schutzrechte.

Die Lizenzlandschaft: Von permissiv bis Copyleft

Open-Source-Lizenzen lassen sich grundsätzlich in zwei Kategorien einteilen, deren Unterscheidung für die Risikobewertung entscheidend ist.

Permissive Lizenzen

Lizenzen wie die MIT-Lizenz oder die Apache License 2.0 sind vergleichsweise unkompliziert. Sie gestatten die freie Nutzung, Modifikation und Weiterverbreitung der Software -- auch in proprietären Produkten. Die wesentlichen Pflichten beschränken sich auf die Beibehaltung des Copyright-Hinweises und des Lizenztextes. Die Apache License 2.0 enthält darüber hinaus eine ausdrückliche Patentlizenz, die dem Nutzer Sicherheit vor Patentansprüchen des Lizenzgebers gibt.

Copyleft-Lizenzen: Der „virale" Effekt

Deutlich komplexer sind Copyleft-Lizenzen, allen voran die GNU General Public License (GPL). Das zentrale Merkmal der GPL ist der sogenannte Copyleft-Effekt: Wer GPL-lizenzierten Code in ein eigenes Programm integriert und dieses verbreitet, muss das gesamte daraus resultierende Werk ebenfalls unter der GPL veröffentlichen -- einschließlich des vollständigen Quellcodes.

Diese Verpflichtung wird häufig als „viraler Effekt" bezeichnet, weil sich die Lizenz gleichsam auf alle verbundenen Codeteile ausbreitet. Für Unternehmen, deren Geschäftsmodell auf proprietärer Software basiert, kann dies existenzbedrohend sein: Die unbeabsichtigte Integration einer GPL-Komponente kann dazu führen, dass der gesamte proprietäre Quellcode offengelegt werden muss.

Die LGPL (Lesser General Public License) mildert diesen Effekt ab. Sie erlaubt die Einbindung von LGPL-Bibliotheken in proprietäre Software, solange die Bibliothek dynamisch gelinkt wird und der Nutzer in der Lage ist, die Bibliothek auszutauschen. Auch hier lauern jedoch Fallstricke bei statischem Linking oder der Modifikation der Bibliothek selbst.

Hellwig gegen VMware: Ein Weckruf für die Industrie

Die Bedeutung der GPL-Compliance wurde durch den Fall Hellwig gegen VMware eindrucksvoll illustriert. Christoph Hellwig, einer der produktivsten Entwickler des Linux-Kernels, klagte 2015 vor dem Landgericht Hamburg gegen VMware wegen Verletzung der GPLv2.

Der Vorwurf: VMware habe Linux-Kernel-Code in seinen Hypervisor ESXi integriert, ohne den Quellcode des gesamten abgeleiteten Werks unter der GPL offenzulegen. Obwohl die Klage letztlich aus beweisrechtlichen Gründen abgewiesen wurde -- Hellwig konnte nicht hinreichend nachweisen, welche konkreten Codezeilen von ihm stammten -- hat der Fall die Industrie wachgerüttelt.

Die zentrale, bis heute ungeklärte Rechtsfrage betrifft den Begriff des abgeleiteten Werks (derivative work) im Sinne der GPL: Ab wann wird die Kombination von proprietärem und GPL-lizenziertem Code zu einem einheitlichen Werk, das insgesamt der GPL unterliegt? Diese Unsicherheit zwingt Unternehmen zu besonderer Vorsicht bei der Architektur ihrer Software.

Der EU Cyber Resilience Act und die SBOM-Pflicht

Mit der Verordnung (EU) 2024/2847 -- dem Cyber Resilience Act (CRA) hat der europäische Gesetzgeber eine neue Dimension der Transparenzpflichten geschaffen. Der CRA, der am 10. Dezember 2024 in Kraft getreten ist und ab dem 11. Dezember 2027 vollständig anwendbar wird, verpflichtet Hersteller von Produkten mit digitalen Elementen zur Erstellung und Pflege einer Software Bill of Materials (SBOM).

Was ist eine SBOM?

Eine SBOM ist ein maschinenlesbares Verzeichnis aller Softwarekomponenten eines Produkts -- vergleichbar mit einer Zutatenliste bei Lebensmitteln. Sie dokumentiert sämtliche verwendeten Bibliotheken, Frameworks und Module einschließlich ihrer Versionen und Lizenzen.

Die NTIA hat bereits 2021 Mindestanforderungen für SBOMs definiert, die inzwischen von der CISA in einer aktualisierten Fassung von 2025 weiterentwickelt wurden.

Anforderungen des CRA an die SBOM

Der CRA verlangt, dass die SBOM:

• in einem gängigen, maschinenlesbaren Format erstellt wird
• mindestens die Top-Level-Abhängigkeiten des Produkts auflistet
• als Teil der technischen Dokumentation aufbewahrt wird
• den Marktüberwachungsbehörden auf Anfrage zur Verfügung gestellt wird

Die SBOM muss zwar nicht öffentlich zugänglich sein, aber die Pflicht zur Erstellung und Pflege erzwingt eine systematische Erfassung aller OSS-Komponenten -- und damit auch ihrer Lizenzen.

Gängige Lizenztypen und ihre Implikationen

Für die unternehmerische Praxis ist ein klares Verständnis der häufigsten Lizenztypen unerlässlich:

MIT-Lizenz

• Pflichten: Copyright-Hinweis und Lizenztext beibehalten
• Risiko: Gering
• Praxis: In proprietärer Software problemlos verwendbar

Apache License 2.0

• Pflichten: Copyright-Hinweis, Lizenztext, NOTICE-Datei beibehalten; ausdrückliche Patentlizenz
• Risiko: Gering bis mittel
• Besonderheit: Patentretaliation-Klausel (Verlust der Patentlizenz bei Patentklage gegen den Lizenzgeber)

GPL v2 / v3

• Pflichten: Gesamtes abgeleitetes Werk unter GPL stellen; Quellcode offenlegen
• Risiko: Hoch
• Praxis: Nur in klar abgegrenzten, separat vertriebenen Modulen oder als reines Backend-Tool verwendbar

LGPL

• Pflichten: Modifikationen an der Bibliothek selbst unter LGPL offenlegen; dynamisches Linking erforderlich
• Risiko: Mittel
• Praxis: Bei Einhaltung der Linking-Anforderungen in proprietärer Software verwendbar

AGPL (Affero GPL)

• Pflichten: Wie GPL, aber bereits bei Bereitstellung über ein Netzwerk (SaaS) greift die Offenlegungspflicht
• Risiko: Sehr hoch
• Praxis: Für kommerzielle SaaS-Anwendungen besonders kritisch

M&A Due Diligence für Open-Source-Software

Bei Unternehmenstransaktionen wird die OSS-Compliance zunehmend zum Deal-Breaker. Käufer müssen sicherstellen, dass das Zielunternehmen keine Lizenzverstöße begeht, die nach Vollzug der Transaktion zu Haftungsrisiken führen.

Prüfungsschwerpunkte

Eine OSS-Due-Diligence sollte mindestens folgende Aspekte umfassen:

• Bestandsaufnahme: Vollständige Erfassung aller verwendeten OSS-Komponenten und ihrer Lizenzen
• Lizenzkompatibilität: Prüfung, ob die Kombination verschiedener Lizenzen zulässig ist
• Copyleft-Kontamination: Identifizierung von GPL- oder AGPL-Komponenten in proprietären Produkten
• Einhaltung der Lizenzbedingungen: Sind Copyright-Hinweise, Lizenztexte und ggf. Quellcode korrekt bereitgestellt?
• Organisatorische Compliance: Existieren interne Prozesse und Verantwortlichkeiten für die OSS-Verwaltung?

Auswirkungen auf die Bewertung

Festgestellte OSS-Risiken können erhebliche Auswirkungen auf den Transaktionspreis haben. In gravierenden Fällen -- etwa wenn ein Kernprodukt GPL-kontaminiert ist -- kann dies den Abbruch der Transaktion bedeuten. Vertragliche Absicherungen in Form von Zusicherungen (Representations), Gewährleistungen (Warranties) und Freistellungen (Indemnities) sind daher essenziell.

Organisatorische Compliance-Programme

Ein wirksames OSS-Compliance-Programm basiert auf mehreren Säulen:

Governance-Struktur

• Benennung eines Open Source Program Office (OSPO) oder zumindest eines verantwortlichen Compliance-Officers
• Klare Richtlinien für die Verwendung von OSS (Allowlist/Denylist für Lizenztypen)
• Definierte Freigabeprozesse vor der Integration neuer OSS-Komponenten

Technisches Tooling

Moderne Werkzeuge ermöglichen die automatisierte Erkennung und Verwaltung von OSS-Komponenten:

• FOSSA: Automatisierte Lizenzerkennung, SBOM-Generierung und Policy-Enforcement
• Snyk Open Source: Kombination von Sicherheits- und Lizenz-Compliance-Scanning
• Black Duck (Synopsys): Umfassende Software Composition Analysis mit Deep Binary Inspection

ISO/IEC 5230 -- Der OpenChain-Standard

Der OpenChain-Standard der Linux Foundation, seit 2020 als ISO/IEC 5230 internationaler Standard, definiert Kernanforderungen für hochwertige Open-Source-Compliance-Programme. Die Zertifizierung nach OpenChain schafft Vertrauen in der Lieferkette und reduziert den Prüfungsaufwand bei Geschäftspartnern und in Due-Diligence-Prozessen.

Praktische Handlungsempfehlungen

Für Geschäftsführer und Vorstände

1. Awareness schaffen: OSS-Risiken auf die Agenda der Geschäftsleitung setzen
2. Budget bereitstellen: Compliance-Tools und -Personal sind eine Investition, keine Kosten
3. Verantwortlichkeiten definieren: Klare Zuständigkeiten für OSS-Compliance festlegen

Für Entwicklungsteams

1. Vor der Integration prüfen: Jede neue OSS-Komponente vor der Einbindung auf Lizenzkompatibilität prüfen
2. Abhängigkeiten dokumentieren: SBOMs kontinuierlich pflegen und aktualisieren
3. Build-Pipeline integrieren: Automatisierte Lizenzscans in die CI/CD-Pipeline einbinden

Für Rechtsabteilungen

1. Lizenz-Policy erstellen: Klare Vorgaben, welche Lizenzen unter welchen Bedingungen akzeptiert werden
2. Vertragliche Absicherung: Lizenzzusicherungen in Entwickler- und Zuliefererverträge aufnehmen
3. Schulungen durchführen: Regelmäßige Sensibilisierung aller Beteiligten für OSS-Rechtsfragen

Fazit

Open-Source-Software ist aus der modernen Softwareentwicklung nicht mehr wegzudenken -- und das ist gut so. Doch die damit verbundenen Lizenzrisiken erfordern ein professionelles Management. Der EU Cyber Resilience Act mit seiner SBOM-Pflicht erhöht den Handlungsdruck zusätzlich. Unternehmen, die ihre OSS-Compliance vernachlässigen, riskieren nicht nur rechtliche Sanktionen, sondern auch erhebliche wirtschaftliche Schäden -- von gescheiterten M&A-Transaktionen bis zur erzwungenen Offenlegung proprietären Quellcodes.

Bei compleneo unterstützen wir Sie bei der rechtlichen Bewertung Ihrer Open-Source-Nutzung, der Implementierung von Compliance-Programmen und der OSS-Due-Diligence bei Unternehmenstransaktionen. Sprechen Sie uns an.