Open-Source-Lizenzen: Compliance ohne Wachstumsbremse

Kurz beantwortet: Open-Source-Software ist urheberrechtlich geschützt (§ 69a UrhG). Die Lizenz ist keine Freigabe ins Rechtefreie, sondern eine Nutzungserlaubnis unter Bedingungen. Wer die Bedingungen verletzt, verliert die Erlaubnis, bei der GPL mit dem Verstoß, und jede weitere Nutzung ist dann eine Urheberrechtsverletzung. Deshalb kommt es darauf an, welche Lizenz eine Komponente hat und ob Sie deren Bedingungen einhalten.

Warum bindet eine Open-Source-Lizenz überhaupt?

Der Rechtsinhaber hat das ausschließliche Recht, seine Software zu vervielfältigen, zu bearbeiten und zu verbreiten (§ 69c UrhG). Ohne Erlaubnis dürften Sie den Code also gar nicht nutzen. Die Open-Source-Lizenz ist genau diese Erlaubnis, erteilt unter Bedingungen. Halten Sie die Bedingungen nicht ein, entfällt die Erlaubnis, bei der GPL mit dem Verstoß, und jede weitere Nutzung wird zur Rechtsverletzung.

Was unterscheidet permissive Lizenzen von Copyleft?

Open-Source-Lizenzen lassen sich grob in zwei Lager einteilen:

• Permissive Lizenzen (etwa MIT, Apache) verlangen wenig, im Kern die Nennung von Urheber und Lizenz und das Mitliefern des Lizenztextes. Der Einsatz in geschlossenen, kommerziellen Produkten ist erlaubt.
• Copyleft-Lizenzen (etwa die GPL) verlangen mehr: Abgeleitete Werke müssen unter derselben Lizenz weitergegeben werden. Im Ergebnis kann das bedeuten, dass Sie eigenen Quellcode offenlegen müssen.

Was ist die Copyleft-Falle?

Der Unterschied ist geschäftskritisch. Eine einzige starke Copyleft-Komponente, zu eng mit Ihrem eigenen Code verbunden, kann die Pflicht auslösen, Ihren Code offenzulegen. Für ein Unternehmen, dessen Wert im proprietären Code liegt, ist das ein ernstes Risiko. Deshalb gehört vor der Einbindung geprüft, welche Lizenz eine Komponente hat und wie sie technisch mit Ihrem Code verbunden wird. Am Ende entscheidet dieselbe Frage über den Schutzumfang Ihres eigenen Codes: Vertiefend dazu Was am Programm ist urheberrechtlich geschützt?

Wie behalten Sie den Überblick über Ihre Komponenten?

Beherrschbar wird Open Source nur mit Überblick: Welche Komponenten stecken mit welchen Lizenzen im Produkt? Eine gepflegte Liste, oft Software Bill of Materials (SBOM) genannt, ist die Grundlage jeder Compliance und zugleich das, was ein Erwerber in der Due Diligence sehen will. Fehlt sie, kauft er ein unkalkulierbares Risiko mit und drückt den Preis oder springt ab.

Wie das in der Praxis aussieht

Ein Beispiel, wie es in dieser Form häufig vorkommt: Ein Hersteller von Steuerungssoftware für Bühnentechnik mit rund 40 Mitarbeitenden will eine fertige Bibliothek für die Videoverarbeitung einbinden. Sie steht unter einer Copyleft-Lizenz. Eine Liste der Open-Source-Komponenten im Produkt fehlt, und ein Theaterbetreiber verlangt sie vor der Unterzeichnung. Zu klären ist die Grundlage: Auch Open-Source-Code ist urheberrechtlich geschützt, und die Lizenz erlaubt die Nutzung nur unter Bedingungen. Wer die Bedingungen verletzt, verliert die Erlaubnis, bei der GPL mit dem Verstoß. Eine Copyleft-Komponente, die eng mit dem eigenen Code verbunden ist, kann die Pflicht auslösen, eigenen Quellcode offenzulegen.

Danach trennen sich die Wege. Für permissiv lizenzierte Komponenten genügen im Kern Urheber- und Lizenzhinweis samt Lizenztext. Für die Videobibliothek wird vor der Einbindung geprüft, wie sie technisch mit der Steuerung verbunden würde; droht die Offenlegung des eigenen Codes, wählt das Team eine Alternative unter permissiver Lizenz oder entwickelt den Teil selbst. Für den Bestand entsteht eine Komponentenliste, eine SBOM, die bei jedem Release fortgeschrieben wird. Am Ende stehen die Liste für den Kunden und eine Regel für neue Komponenten. Wie dieser Freigabeweg im Alltag funktioniert, zeigt das Rechtssystem.

Häufige Fragen

Ist Open-Source-Software rechtefrei?

Nein. Sie ist urheberrechtlich geschützt (§ 69a UrhG). Die Lizenz erlaubt die Nutzung nur unter Bedingungen; ohne diese Erlaubnis dürften Sie den Code gar nicht verwenden.

Was passiert, wenn ich die Lizenzbedingungen verletze?

Die Erlaubnis entfällt, bei der GPL mit dem Verstoß selbst; nach dem LG München I ist der Rechteverlust nach der GPL eine auflösende Bedingung, die nur für die Zukunft wirkt (§ 158 Abs. 2 BGB). Jede weitere Vervielfältigung, Bearbeitung und Verbreitung ist dann eine Urheberrechtsverletzung, weil diese Handlungen dem Rechtsinhaber vorbehalten sind (§ 69c UrhG). Die GPLv3 lässt die Rechte unter den dort genannten Voraussetzungen wieder aufleben, wenn Sie den Verstoß beenden (Ziff. 8 GPLv3).

Was ist die Copyleft-Falle?

Eine einzige starke Copyleft-Komponente, zu eng mit Ihrem eigenen Code verbunden, kann die Pflicht auslösen, Ihren Quellcode offenzulegen. Für ein Unternehmen, dessen Wert im proprietären Code liegt, ist das ein ernstes Risiko.

Warum brauche ich eine SBOM?

Eine gepflegte Liste der eingesetzten Komponenten und ihrer Lizenzen ist die Grundlage jeder Compliance. Sie ist zugleich das, was ein Erwerber in der Due Diligence sehen will; fehlt sie, drückt er den Preis oder springt ab.

Welche Open-Source-Komponenten im Produkt stecken, weiß oft nur das Entwicklungsteam, und die Geschäftsführung erfährt es in der Due Diligence. Im Rechtssystem entstehen Richtlinie, Freigabeweg und Checklisten, mit denen Ihr Team neue Komponenten vor dem Einsatz einordnet. Rechtssystem: Freigabeweg für Open-Source-Komponenten

Sie wollen Ihre Open-Source-Nutzung geordnet aufstellen, ohne die Entwicklung auszubremsen? In einem 60-minütigen Strategiegespräch klären wir Lizenzlage und Vorgehen. Vertiefend zu IP und Code-Eigentum insgesamt: der Leitfaden IP & Code-Eigentum für Softwareunternehmen, zur laufenden vertraglichen Absicherung: IT-Recht (Leistung).