Lizenzpflichten

Hinter dem Begriff der „Lizenzpflichten“ verbergen sich die zunächst verhältnismäßig harmlos erscheinenden Verpflichtungen zur Weitergabe des Quellcodes und der Urheberrechtsvermerke. Selbst daraus ergeben sich viele ungeklärte Fragen:

• Eine hohe Anzahl von OSS-Lizenzbedingungen verlangt die Mitlieferung einer Kopie der Lizenztexte. Wie diese Verpflichtung erfüllt werden kann, ist in Literatur und Rechtsprechung nicht geklärt.

• Es zeichnet sich eine Tendenz ab, dass diese Verpflichtung nicht mit der Verlinkung von Lizenztexten oder der Angabe von Links auf generische Versionen erfüllt werden kann. Solange es nur um einzelne Lizenztexte geht, erscheint eine Mitlieferung in Papierform (zum Beispiel als Bestandteil einer Dokumentation) denkbar. Wie aber lässt sich diese Verpflichtung umsetzen, wenn es um hunderte Komponenten mit unterschiedlichen Lizenztexten geht? Was gilt, wenn diese Vielzahl von Open–Source-Software in einem Embedded System (zum Beispiel in der Entertainment-Einheit eines Kfz oder der Steuerung eines Küchengeräts) steckt? Können die Lizenztexte dann über Webseiten, Displays oder Interfaces „mitgeliefert“ werden?

• Eine Lizenzverletzung kann sich auch daraus ergeben, dass für den Lizenznehmer kein unmittelbarer Bezug zwischen der OSS-Komponente und dem Lizenztext erkennbar ist: Der Lizenznehmer muss aber seine Rechte in Bezug auf die konkrete OSS-Komponente erkennen können. Der Bezug zwischen Lizenztext und OSS-Komponente muss also vorhanden sein. Das ist für viele Hersteller aber unerwünscht, denn sie möchten ja gerade nicht offenlegen, was alles in ihren Produkten enthalten ist. Auch Sicherheitsaspekte können solchen Angaben entgegenstehen: Der konkrete Hinweis auf enthaltene Komponenten liefert unter Umständen ein Einfallstor für Hacker.

Der sogenannte „Copyleft-Effekt“

Neben den allgemeinen Lizenzpflichten enthalten einige Open Source Licenses einen sogenannten Copyleft-Effekt („viraler Effekt“), d. h. die Verpflichtung, Bearbeitungen und Weiterentwicklungen unter der gleichen Lizenzbestimmung zu verbreiten. Das wäre dann einfach, wenn klar wäre, was unter eine Bearbeitung oder Weiterentwicklung fällt. Das ist es aber gerade nicht.

• Wesen des viralen Effekts ist es, dass sich eine OSS-Lizenzbedingung mit Copyleft-Effekt auf alle Komponenten erstrecken muss, die die erhaltene OSS-Komponente vollständig oder in Teilen enthalten oder deren Bearbeitung („Derivative Work“) darstellen. Die Festlegung, wann eine Bearbeitung oder ein „Derivative Work“ vorliegt, ist komplex und nicht abschließend geklärt: Die statische Verlinkung von Bibliotheken löst zum Beispiel den viralen Effekt bei GPL (General Public License) und LGPL (Lesser General Public License) aus, aber auch bei der dynamischen Verlinkung kann ein Copyleft-Effekt nicht von vornherein ausgeschlossen werden.

• Welche technischen Verknüpfungen zulässig sind, damit der virale Effekt nicht ausgelöst wird, ist nicht abschließend geklärt. Das Landgericht Berlin hat in einer Entscheidung eine TV-Set-Top-Box zum Sammelwerk im urheberrechtlichen Sinne erklärt. In der Konsequenz greift der virale Effekt für alle in der TV-Set-Top-Box enthaltenen Komponenten. Die Entscheidung ist höchst umstritten, kann aber dennoch nicht einfach ignoriert werden.

Die weitere Rechtsprechung der deutschen Gerichte macht deutlich, dass Rechteinhaber ihre Ansprüche geltend machen und auch durchsetzen können.

Lizenzpflichten hängen von der geplanten Verwendung ab

Es gibt nicht „die“ Open-Source-Lizenzbestimmung, sondern eine Vielzahl von Open Source Licenses. Diese können zwar in bestimmte Lizenztypen systematisiert werden, aber dennoch starke Unterschiede in den Verpflichtungen haben. Damit steht der Nutzer vor erheblichen Herausforderungen, wenn er beurteilen will, unter welchen Voraussetzungen er eine Open-Source-Softwarekomponente rechtssicher einsetzen kann. Dies gilt umso mehr, weil die Entstehung der diversen Lizenzpflichten auch davon abhängt, wie der Nutzer die Softwarekomponente einsetzen will.

Die reine Nutzung zu unternehmensinternen Zwecken ist lizenzrechtlich meist unproblematisch, aber schon bei der Weitergabe an eine Konzerngesellschaft treten die ersten Fragestellungen auf. Ein Konzernprivileg gibt es jedenfalls nach deutschem Recht nicht. Spätestens dann, wenn eine Open-Source-Softwarekomponente als Bestandteil proprietärer Software vertrieben werden soll, wird die lizenzrechtliche Bewertung komplex. Erfolgt der Vertrieb nicht klassisch (durch Übermittlung einer Kopie der Anwendung), sondern als Software-as-a-Service oder Cloud, stellen sich weitere Fragen.

Viele Softwareanwendungen enthalten heute Open-Source-Softwarekomponenten, die unter unterschiedlichen Open-Source-Lizenzbestimmungen verbreitet werden. Nicht alle Lizenzbestimmungen sind miteinander kompatibel. Das heißt, in manchen Fällen führt die Einhaltung einer Open Source License zur Verletzung einer anderen.

• Anwendungen können nur dann lizenzrechtlich unbedenklich vertrieben werden, wenn die Lizenzpflichten aller implementierten Komponenten auch praktisch eingehalten werden können.

• Inkompatibilität liegt vor, wenn die Lizenzpflichten verschiedener Lizenzen miteinander unvereinbar sind, das heißt, dass die Einhaltung der Pflichten aus der einen Lizenz unweigerlich gegen die Pflichten der anderen Lizenz(en) verstößt.

• Copyleft-Lizenzbedingungen verlangen die Erstreckung ihrer Bestimmungen auf andere Komponenten. Deren Lizenzbedingungen dürfen nicht mit der Copyleft-Lizenzbedingung inkompatibel sein.

Für die Frage der Inkompatibilität spielt auch die Softwarearchitektur eine Rolle. Bei der Beschaffung sind neben rechtlichen auch technische Fragen relevant. Im Umgang mit Open Source im Unternehmen sind daher besondere Anforderungen zu beachten.