Open-Source-Compliance

Open-Source-Compliance: warum sie wichtig ist

Open-Source-Compliance bedeutet, die Bedingungen der Lizenzen einzuhalten, unter denen Open-Source-Software genutzt wird, und die damit verbundenen Sicherheits- und Lieferkettenrisiken zu steuern. Nahezu jedes Softwareprodukt, jedes vernetzte Gerät und jedes Unternehmenssystem enthält Open-Source-Komponenten. Sie sind kostenlos, aber nicht frei von Pflichten: Lizenzen verlangen die Namensnennung, die Weitergabe der Lizenztexte und, bei Copyleft-Lizenzen, die Offenlegung des Quellcodes von Bearbeitungen.

Nach deutschem Urheberrecht ist die Nutzung von Software über die Lizenz hinaus eine Urheberrechtsverletzung, und die Gerichte setzen die Bedingungen von Open-Source-Lizenzen seit vielen Jahren durch. Seit dem Cyber Resilience Act der EU hat die Open-Source-Compliance zudem eine Dimension der Cybersicherheit: Hersteller müssen bei der Integration von Open-Source-Komponenten in Produkte mit digitalen Elementen die gebotene Sorgfalt walten lassen.

Für Unternehmen treten Versäumnisse oft im ungünstigsten Moment zutage: bei einem Kundenaudit, bei einer Due-Diligence-Prüfung vor einem Exit, bei einer Abmahnung eines Rechteinhabers oder bei einer ausgenutzten Schwachstelle in einer veralteten Bibliothek. Ein strukturierter Compliance-Prozess ist weitaus günstiger als eine Nachbesserung unter Zeitdruck. Er schafft zudem Vertrauen bei Kunden, von denen viele inzwischen im Rahmen der Beschaffung SBOMs und Compliance-Erklärungen verlangen, und er verkürzt die Due Diligence, wenn das Unternehmen Kapital aufnimmt oder verkauft wird.

Lizenztypen und ihre Pflichten

Open-Source-Lizenzen lassen sich für die Praxis grob in zwei große Familien einteilen:

• Freizügige (permissive) Lizenzen (etwa MIT, BSD, Apache 2.0) erlauben Nutzung, Bearbeitung und Weitergabe, auch in proprietären Produkten, vorbehaltlich vor allem der Namensnennung, der Beifügung des Lizenztextes und bei einigen von Hinweisen auf Änderungen und patentrechtlichen Bestimmungen.
• Copyleft-Lizenzen (etwa die GPL-Familie, LGPL, MPL, AGPL) verlangen, dass an andere weitergegebene Bearbeitungen unter denselben Bedingungen lizenziert werden und der Quellcode zugänglich gemacht wird. Die Reichweite des Begriffs „Bearbeitung“ und die Bedingungen, die Pflichten auslösen, unterscheiden sich: Die GPL wird durch Weitergabe ausgelöst, die AGPL auch dadurch, dass Software über ein Netzwerk zugänglich gemacht wird, und LGPL und MPL sehen ein schwächeres, datei- oder bibliotheksbezogenes Copyleft vor.

Folgen von Verstößen nach deutschem Recht

Nach deutschem Urheberrecht können Nutzungsrechte unter Bedingungen eingeräumt werden (§ 31 UrhG), und die ausschließlichen Rechte des Urhebers an Computerprogrammen umfassen Vervielfältigung, Bearbeitung und Verbreitung (§ 69c UrhG). Viele Open-Source-Lizenzen sehen vor, dass die Rechte bei einem Verstoß gegen ihre Bedingungen automatisch erlöschen, und deutsche Gerichte haben anerkannt, dass ein Nutzer, der gegen solche Bedingungen verstößt, die Lizenz verliert und das Urheberrecht verletzt. Rechteinhaber können dann Unterlassung, Auskunft, Beseitigung und bei Verschulden Schadensersatz verlangen.

Weil Entwickler das Urheberrecht behalten, sind einzelne Beitragende zu Open-Source-Projekten klagebefugt, und einige haben GPL-Bedingungen vor deutschen Gerichten durchgesetzt. Eine Abmahnung mit der Forderung nach einer Unterlassungserklärung und der Herstellung der Compliance ist ein typischer erster Schritt.

Über das Urheberrecht hinaus berühren Open-Source-Fragen die Wirtschaftsverträge in der gesamten Lieferkette: Kunden verlangen zunehmend Garantien, dass Software die Open-Source-Lizenzen einhält und keine Copyleft-Komponenten enthält, die ihren eigenen Code beeinträchtigen würden. Verstöße gegen solche Garantien können zu Ansprüchen, Kündigungen und Reputationsschäden führen. Öffentliche Auftraggeber und große Industriekunden gehen oft noch weiter und verlangen die Einhaltung anerkannter Programmstandards sowie mit jedem Release die Lieferung von SBOMs in vereinbarten Formaten.

Der Cyber Resilience Act und Open Source

Der Cyber Resilience Act (Verordnung (EU) 2024/2847, CRA) legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem EU-Markt bereitgestellt werden. Bei Open Source unterscheidet er zwischen verschiedenen Rollen:

• Hersteller, die Open-Source-Komponenten in ihre kommerziellen Produkte integrieren, bleiben für die Konformität des Produkts voll verantwortlich. Sie müssen bei der Integration von Komponenten Dritter, einschließlich freier und quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, die gebotene Sorgfalt walten lassen, damit diese Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen (Art. 13 Abs. 5 CRA). Stellen sie eine Schwachstelle in einer integrierten Komponente fest, müssen sie diese der Person melden, die die Komponente pflegt, und die Schwachstelle beheben (Art. 13 Abs. 6 CRA).
• Verwalter quelloffener Software (Open-Source Software Stewards) – juristische Personen wie Stiftungen, die die Entwicklung freier und quelloffener Software für Geschäftstätigkeiten systematisch unterstützen – unterliegen einem schlanken Regime: einer dokumentierten Cybersicherheitsstrategie, der Zusammenarbeit mit den Marktüberwachungsbehörden und bestimmten Meldepflichten (Art. 24 CRA). Geldbußen gelten für Verwalter nicht.
• Nicht kommerzielle Open-Source-Entwicklung fällt grundsätzlich nicht in den Anwendungsbereich, da der CRA für Produkte gilt, die im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt werden.

Die Meldepflichten des CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten ab dem 11. September 2026, und die Verordnung gilt vollständig ab dem 11. Dezember 2027 (Art. 71 CRA). Hersteller müssen zudem als Teil der technischen Dokumentation eine Software-Stückliste (SBOM) erstellen. Siehe unseren Beitrag zu den Pflichten nach dem Cyber Resilience Act.

Ein Programm für Open-Source-Compliance aufbauen

Ein wirksames Programm verbindet Richtlinien, Prozesse und technische Werkzeuge zu einem stimmigen Ganzen:

1. Richtlinie: zugelassene und beschränkte Lizenzen, Freigabeprozesse für neue Komponenten und Regeln für Beiträge zu externen Projekten festlegen.
2. Inventar: für jedes Produkt und jedes Release eine SBOM pflegen, automatisch erzeugt durch Werkzeuge zur Analyse der Softwarezusammensetzung.
3. Prüfung: vor jedem Release Lizenzpflichten und Lizenzkompatibilität prüfen, mit rechtlicher Prüfung von Copyleft-Komponenten und ungewöhnlichen Lizenzen.
4. Erfüllung: Lizenztexte, Namensnennungen und Quellcode bereitstellen, wo dies erforderlich ist, etwa über ein schriftliches Angebot oder ein Quellcodeportal.
5. Sicherheit: Schwachstellen in Komponenten fortlaufend überwachen, zügig patchen und gemäß den Pflichten nach dem CRA melden.
6. Lieferkette: von Lieferanten und Subunternehmern SBOMs, Quellcodepakete und Garantien zur Open-Source-Compliance verlangen und diese vor dem Release überprüfen.
7. Schulung: Entwickler, Produktmanager und Einkauf zu Lizenzgrundlagen, zum Freigabeprozess und zu Eskalationswegen schulen.

Branchenstandards für Open-Source-Compliance-Programme und SBOM-Formate helfen, diese Prozesse zu strukturieren und für Kunden und Erwerber prüfbar zu machen. Die Automatisierung des Inventars in der Build-Pipeline stellt sicher, dass die SBOM abbildet, was tatsächlich ausgeliefert wird, und nicht das, woran sich die Entwickler erinnern.

Eingebettete Systeme, Automobil und Industrieprodukte

Besonders anspruchsvoll ist die Open-Source-Compliance bei Produkten, die Software in Hardware ausliefern – Fahrzeuge, Maschinen, Router, Medizinprodukte, Unterhaltungselektronik. Firmware kombiniert oft einen Linux-Kernel und andere GPL-Komponenten mit proprietären Treibern und Anwendungen. Jedes ausgelieferte Gerät ist eine Weitergabe, sodass Lizenztexte und Quellcodeangebote dem Produkt beiliegen oder für die gesamte Dauer der Verpflichtung zugänglich sein müssen. Lieferketten erhöhen die Komplexität: Tier-1-Zulieferer liefern Softwarestacks mit Hunderten von Komponenten von Unterlieferanten. Hersteller sollten von ihren Lieferanten vertraglich vollständige SBOMs, Compliance-Garantien und Quellcodepakete verlangen und diese vor dem Release überprüfen. Brancheninitiativen in der Automobil- und Elektronikindustrie haben dafür gemeinsame Standards entwickelt.

KI-Modelle und Open-Source-Lizenzen

Künstliche Intelligenz wirft zusätzlich ganz neue Lizenzfragen auf. Modelle werden unter unterschiedlichsten Lizenzen veröffentlicht – klassischen Open-Source-Lizenzen, Open-Weight-Lizenzen mit Nutzungsbeschränkungen oder Acceptable-Use-Policies und Lizenzen, die die kommerzielle Nutzung ab bestimmten Nutzerzahlen beschränken. Nicht alle als „offen“ bezeichneten Modelle erfüllen die Open-Source-Definition. Unternehmen, die solche Modelle nutzen oder feinabstimmen, müssen die Lizenzbedingungen auf erlaubte Nutzungen, Namensnennung und nachgelagerte Pflichten prüfen und die gesonderten Fragen der Rechte an Trainingsdaten und der Pflichten nach der KI-Verordnung für KI-Modelle mit allgemeinem Verwendungszweck berücksichtigen, die unter freien und quelloffenen Lizenzen veröffentlicht werden. Siehe unseren Beitrag zu den Pflichten von Anbietern von KI-Modellen mit allgemeinem Verwendungszweck.

Reaktion auf einen Lizenzanspruch

Macht ein Rechteinhaber einen Verstoß geltend – oft mit einer Abmahnung und der Forderung nach einer Unterlassungserklärung –, sollten Unternehmen zunächst den Sachverhalt klären: welche Komponente, welche Version, welche Produkte und welche Pflichten nicht erfüllt wurden. In vielen Fällen lässt sich die Compliance schnell herstellen, indem Lizenztexte, Namensnennungen oder Quellcode bereitgestellt werden. Die Unterlassungserklärung sollte auf den tatsächlichen Verstoß beschränkt und sorgfältig formuliert werden, weil für künftige Verstöße Vertragsstrafen gelten. Eine einvernehmliche Lösung ist üblich; die Durchsetzung durch die Community zielt oft auf Compliance statt auf Schadensersatz, es gibt aber auch eine kommerzielle Durchsetzung.

Beiträge und eigene Open-Source-Veröffentlichungen

Viele Unternehmen veröffentlichen inzwischen auch selbst Software als Open Source oder tragen zu externen Projekten bei. Sie sollten entscheiden, welche Lizenz sie verwenden, prüfen, ob ihnen der gesamte beigetragene Code gehört oder sie die erforderlichen Rechte daran haben, Contributor License Agreements klären und die Auswirkungen auf Patente berücksichtigen – manche Lizenzen räumen den Nutzern Patentlizenzen ein. Mitarbeiter, die während ihrer Arbeitszeit beitragen, handeln für den Arbeitgeber; Richtlinien sollten dies regeln, um Streit über die Inhaberschaft zu vermeiden. Siehe unseren Beitrag zu Technologietransfer und Patentlizenzen.

Verbreitete Irrtümer

Einige weit verbreitete Annahmen führen Unternehmen regelmäßig in die Irre. „Open Source heißt: keine Regeln“ ist falsch – Lizenzen sind verbindliche Bedingungen. „Interne Nutzung ist immer unbedenklich“ trifft für die GPL, die durch Weitergabe ausgelöst wird, weitgehend zu, nicht aber für die AGPL, und die Weitergabe an verbundene Unternehmen oder auf Geräte von Kunden zählt als Weitergabe. „Dynamisches Linken vermeidet Copyleft“ ist eine Vereinfachung: Die Wirkung hängt von der Lizenz und der technischen Integration ab. „Unser Lieferant ist verantwortlich“ stimmt nur vertraglich; gegenüber Rechteinhabern und nach dem CRA gegenüber Behörden ist das Unternehmen verantwortlich, das das Produkt in Verkehr bringt. Schließlich unterschätzt „Wir beheben das später“, wie schwierig es ist, tief eingebettete Komponenten zu ersetzen, wenn Produkte bereits ausgeliefert sind.

Governance und Verantwortlichkeiten

Open-Source-Compliance braucht im Unternehmen einen klar benannten Verantwortlichen. Viele Unternehmen richten ein Open Source Program Office ein oder benennen ein bereichsübergreifendes Team aus Entwicklung, Recht, Sicherheit und Einkauf. Zu seinen Aufgaben gehören die Pflege der Richtlinie und der Liste zugelassener Lizenzen, der Betrieb der Scan- und SBOM-Werkzeuge, die Entscheidung über Ausnahmen, die Koordinierung eigener Beiträge und die Berichterstattung an die Geschäftsleitung. Die Geschäftsleitung sollte regelmäßig über den Compliance-Status und über Schwachstellen in Komponenten informiert werden, weil sowohl Lizenzverstöße als auch Sicherheitsvorfälle erhebliche Haftungsrisiken und nach dem CRA aufsichtsrechtliche Risiken begründen können.

Open Source bei Transaktionen

Open-Source-Compliance ist heute ein Standardthema jeder IP-Due-Diligence. Käufer verlangen SBOMs, Scan-Ergebnisse und Nachweise eines Compliance-Prozesses und achten auf Copyleft-Komponenten in vertriebenen Produkten, auf AGPL-Nutzung in SaaS-Angeboten und auf veraltete Komponenten mit bekannten Schwachstellen. Die Befunde führen zu Abhilfeverpflichtungen, spezifischen Freistellungen oder Kaufpreisanpassungen. Siehe unseren Beitrag zur IP-Due-Diligence bei Transaktionen.

So unterstützt TRW & Co bei der Open-Source-Compliance

Wir helfen Softwareunternehmen, Herstellern vernetzter Produkte und Nutzern von Open-Source-Software, Programme für die Open-Source-Compliance aufzubauen und zu prüfen: beim Entwurf von Richtlinien, bei der Prüfung von Lizenzpflichten und Lizenzkompatibilität, bei Fragen zu Copyleft und AGPL, bei der Vorbereitung auf die Pflichten nach dem CRA, bei der Verhandlung von Open-Source-Garantien in Kunden- und Lieferantenverträgen und bei der Abwehr oder Durchsetzung von Lizenzansprüchen. Für Scans und die Erstellung von SBOMs arbeiten wir mit technischen Partnern zusammen. Siehe unsere Seiten zu Cybersicherheit und NIS2 und zu IP und Patenten, oder kontaktieren Sie uns.