· IT-Compliance, Teil 1
Open-Source-Software: Freiheit für Nutzer oder Herausforderung für die Einkaufsorganisation?
von RA, FA für Informationstechnologierecht Michaela Witzel, LL.M., München
| Open-Source-Software (OSS) ist eine der technischen Grundlagen der Digitalisierungsstrategie vieler Unternehmen und findet sich in allen Branchen und Marktsegmenten ‒ von der Automobilbranche bis zur öffentlichen Hand. Linux, Mozilla und Wikipedia gehören zu etablierten technischen Standards, die ihren Eingang auch in die IT der großen Konzerne gefunden haben. Doch trotz der hohen Verbreitung fehlt es bei vielen Unternehmen noch an einem Open-Source-Compliance-System. Warum aber Compliance? |
Open-Source-Software ist nicht rechtsfrei und nicht in der Public Domain
Der Begriff „Open Source“ steht für Softwarekomponenten, die ihrem Nutzer mit dem Quellcode (Source Code) angeboten werden. Der Nutzer soll eine Anwendung nicht nur nutzen, sondern auch bearbeiten, ändern und weiterentwickeln können. Durch möglichst viele Beiträge qualifizierter Entwickler soll sich der Funktionsumfang einer Anwendung rasch erweitern, aber auch die Qualität, Stabilität und Performance verbessern. Das klingt alles sehr vielversprechend. Allerdings ist Open-Source-Software keineswegs „rechtsfrei“. Die Open-Source-Softwarekomponenten sind nicht in der ‒ nach deutschem Urheberrecht nicht vorgesehenen ‒ Public Domain, wonach der Rechteinhaber ausdrücklich auf seine Rechte verzichtet.
Im Gegenteil: Viele der unzähligen Open-Source-Lizenzbestimmungen (Open Source Licenses, siehe auch www.ifross.org) enthalten Verpflichtungen, die der Nutzer unter bestimmten Voraussetzungen beachten muss. Sonst droht eine Urheberrechtsverletzung, die zu einer Abmahnung, Unterlassungsverpflichtung und ggf. auch Schadenersatz führen kann. Hinzu kommt, dass viele OSS-Lizenzbedingungen für den Fall der Lizenzverletzung den Wegfall von Nutzungsrechten vorsehen. Nach deutschem AGB-Recht könnten solche Klauseln als überraschende Klauseln unwirksam sein, nach „US-Rechte“ ist der Bestand solcher Klauseln sehr wahrscheinlich.
MERKE | Fallen in der Vertriebskette nachträglich Nutzungsrechte weg, drohen Ansprüche wegen Rechtsmängeln seitens der weiteren Lizenznehmer. Lizenzverstöße können demnach weitreichende Folgen haben. In Betracht kommen urheberrechtliche Unterlassungs- und Schadenersatzansprüche, ggf. strafrechtliche Sanktionen. Eine fehlende oder unzureichende Compliance kann auch zur Haftung der Unternehmensleitung führen. |
Lizenzpflichten und der sogenannte „Copyleft-Effekt“
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 (Ballhausen, DSRITB, 15, 635; Schöttle, DSRITB 17, 463).
- 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 (z. B. 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 (z. B. 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 u. U. ein Einfallstor für Hacker.
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 z. B. den viralen Effekt bei GPL und LGPL aus, aber auch bei der dynamischen Verlinkung kann ein Copyleft-Effekt nicht von vornherein ausgeschlossen werden (Galetzka, DSRITB 15, 647).
- Welche technischen Verknüpfungen zulässig sind, damit der virale Effekt nicht ausgelöst wird, ist nicht abschließend geklärt. Das LG Berlin (8.11.11, 16 O 255/10, GRUR-RR 12, 107) 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 (z. B. LG München I 19.5.04, 21 O 6123/04, MMR 04, 693; LG Berlin 21.2.06, 16 O 134/06, CR 06, 735; LG Hamburg 14.6.13, 308 O 10/13, CR 13, 498; LG Köln (Teilurteil) 17.7.14, 14 O 463/13, CR 14, 704) macht deutlich, dass Rechteinhaber ihre Ansprüche geltend machen und auch durchsetzen können. Eine der aktuellen Entscheidungen stammt vom OLG Köln und betraf den Linux-Kernel (20.10.17, 14 O 188/17, GRUR-RR 18, 11).
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 (d. h. 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. D. h., 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, d. h., 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.
PRAXISHINWEIS | Aufgrund der Allgegenwärtigkeit von Open-Source-Software und den Risiken, die sich aus Lizenzverstößen ergeben, ist der Aufbau einer Compliance-Organisation für Beschaffung und Vertrieb erforderlich, deren Ziel die Prävention und Minimierung der Risiken beim Einsatz von Open Source ist. |
Weiterführender Hinweis
