Lizenzkonformer Einsatz von Open Source Software in Embedded Systems - Teil 2: Welche Pflichten bestehen in Bezug auf Urheberrechtsvermerke und Quellcode?

Moderne Cloud-, Embedded- und Mobile-Computing-Technologien basieren zu großen Teilen auf Lösungen mit offenem Quellcode. Open Source Software (OSS) ist auch ein wichtiger Bestandteil von sogenannten embedded systems. Solche eingebetteten Systeme findet man in Automations- und Automobiltechnik, Produktionsmaschinen, Telekommunikationssystemen und Haushaltsgeräten.

Im zweiten Teil dieses Artikels geht es um die Weitergabe von Urheberrechtsvermerken und Quellcode sowie um das Sonderproblem des Copyleft-Effekts (zum Teil 1 des Artikels siehe Open Source in Embedded Systems: Welche Lizenzpflichten sind einzuhalten?)

Weitergabe der Urhebervermerke

Neben dem Lizenztext sind auch bestehende Urhebervermerke unverändert weiterzugeben. Problematisch wird die Einhaltung dieser Verpflichtung dann, wenn das embedded system im Binärcode übermittelt werden soll. Die überwiegende Mehrheit der Urhebervermerke findet sich verteilt in den einzelnen Source Files der OSS.

Wer also die Software nur im Binärcode vertreibt, muss die Urhebervermerke aus den Quelldateien zusammensuchen und in ein eigenständiges Dokument zusammenführen. Bei mehreren Softwarekomponenten muss er zudem die Vermerke einzelnen Dateien zuordnen. Bei komplexen embedded systems kommen hier leicht mehrere hunderttausend Quelldateien zusammen, die dann einzeln auf Urhebervermerke hin durchsucht werden müssen. Auch wenn manche Scanning Tools auf das Zusammensuchen solcher Urhebervermerke spezialisiert sind, finden diese nicht alle Vermerke und erfordern viel manuelle Nacharbeit.

Bei den meisten Geräten mit embedded systems hat der Nutzer keinen vollwertigen Zugriff auf das Dateisystem. Er kann nicht mit Bordmitteln auf dort gespeicherte Quelldateien zugreifen und diese auslesen. Die Urheberrechtsvermerke mögen zwar auf dem Gerät gespeichert sein. Ob sie „angemessen“ und vor allem vor den Nutzer erkennbar sind, ist zu bezweifeln, aber auffallend oder unübersehbar im Sinne des englischen Begriffs „conspicuously“ sind sie womöglich nicht.

Weitergabe des Quellcode

Nicht alle OSS-Lizenzen verlangen die Weitergabe des Quellcode. Aber diejenigen, die eine Verpflichtung vorsehen, machen in der Praxis Probleme. Schließlich verlangt Ziffer 3 der GPLv2 die Verfügbarkeit des Quellcodes. Diese Pflicht kann entweder erfüllt werden, indem der Quellcode direkt mit dem embedded system oder dem Endgerät ausgeliefert wird oder indem ein Angebot an die Allgemeinheit abgegeben wird, den Quellcode für einen Zeitraum von mindestens drei Jahren auf einem Datenträger gegen Erstattung der Vervielfältigungskosten zu erhalten.

In der Praxis bedeutet das entweder das Mitliefern des Quellcodes oder die Abgabe eines Angebotes. Zumindest unter der weit verbreiteten GPLv2 genügt es nicht, auf eine Download-Möglichkeit zu verweisen, vielmehr muss der Quellcode auf einem üblichen Datenträger versandt werden. Natürlich schadet es nicht, dennoch auf eine Download-Möglichkeit hinzuweisen, da dies in der Praxis der am meisten genutzte Weg sein wird. Aus rechtlicher Sicht kommt derjenige, der den Quellcode nicht direkt mitliefert, jedoch nicht um ein solches Angebot umhin.

Sonderproblem Copyleft-Effekt

Verwendet ein Hersteller in einem embedded system sogenannte Copyleft-Lizenzen, muss bei der Entwicklung sichergestellt werden, dass die entsprechenden Komponenten nicht das komplette embedded system infizieren. Es besteht ja in den überwiegenden Fällen auch aus proprietären Softwarekomponenten.

Bei der Entwicklung ist bei jedem Schritt zu klären, welche Kriterien dazu führen können, dass sich die OSS-Lizenz auf die Bearbeitung auswirkt. Damit würde sich gewissermaßen das komplette embedded system infizieren. Dabei ist entscheidend, ob das ursprüngliche Programm bearbeitet wurde oder ein eigenständiger Programmzusatz hinzugefügt wurde. Eine genaue Grenzziehung erweist sich mangels höchstrichterlicher Rechtsprechung und nicht eindeutiger Kriterien in den Lizenztexten als schwierig und kann letztendlich auch nicht abschließend beantwortet werden.

Ob der Copyleft-Effekt eintreten kann, lässt sich in drei Schritten überprüfen. Zunächst ist festzustellen, ob es zu Veränderungen der ursprünglichen Programmkopie oder von Teilen davon gekommen ist, mithin ein sogenannter „derivative work“ entstanden ist. Im zweiten Schritt ist dann zu klären, ob die Dateien, die verbreitet werden sollen, Werkteile enthalten, die funktional unabhängig und eigenständig gegenüber der ursprünglichen Programmkopie sind. Sollten eigenständige Werke vorhanden sein, ist in einem letzten Schritt zu untersuchen, ob die Vertriebsform getrennt oder als Ganzes erfolgt.

Die Infektionswirkung bestimmter OSS-Lizenzen stellt Unternehmen vor erhebliche Herausforderungen. Diese haben umfassende und zum Teil - mangels eindeutiger Regelungen - schwierige Untersuchungen ihrer Programme und Softwareentwicklungen durchzuführen und tragen dabei das Risiko hoher wirtschaftlicher Verluste und gravierender Imageschäden.

Neben einem pauschalen Zustimmungsvorbehalt für den Einsatz von jeglicher OSS ist es denkbar, dass nur der Einsatz von Copyleft-Lizenzen eine Zustimmung erfordert. Ergänzend denkbar sind Anforderungen an die Architektur des embedded systems, die eine Infektion etwaiger proprietärer Bestandteile vermeiden sollen.

Wer prüft den Quellcode?
Wenn der Quellcode bereitgestellt werden muss, sollte die Lieferverpflichtung die Übermittlung sämtlicher Quellcode-Dateien einschließlich Makefiles und Skripte umfassen sowie die Bereitstellung einer Anleitung zum Kompilieren des Quellcodes. Das Landgericht Hamburg hat in einer Entscheidung festgehalten, dass sich ein Vertriebspartner nicht ausschließlich auf Zusicherungen des Lieferanten verlassen darf, sondern auch Prüfungs- und Erkundigungspflichten bestehen. Dies trifft sowohl die Hersteller von embedded systems als auch diejenigen Abnehmer, die solche Systeme in ihren Endgeräten verbauen. Damit nicht alle Beteiligten einer Lieferkette in gleichem Umfang technische Prüfungen durchführen müssen, sollte bei der Vertragsgestaltung berücksichtigt werden, wer welche Aufgaben ausführt und welche Verpflichtungen übernimmt.

Zusicherungen und Freistellungsklauseln

Ohne Zusicherungen und Freistellungsklauseln werden die Vertragspartner im Regelfall nicht auskommen (wollen). Bei deren Gestaltung sind grundsätzlich auch die Vorgaben der § 307 ff BGB zu beachten. Vertriebsverträge sind als AGB zu werten – es sei denn sie sind im Einzelfall vollständig ausgehandelt worden. Eine unangemessene Benachteiligung sollte folglich nicht entstehen. Dessen ungeachtet sollte eine Zusicherung folgende Themen abdecken:
• Die bereitgestellten Materialien und Informationen sind vollständig und zutreffend,
• die verwendeten OSS-Komponenten stehen unter OSS-Lizenzen, die miteinander kompatibel sind, d.h. die Verwendung einer OSS-Lizenz darf nicht dazu führen, dass die Bestimmungen einer anderen OSS-Lizenz verletzt werden,
• die Verwendung der OSS-Komponenten darf nicht zu einem Copyleft-Effekt für das gesamte Produkt führen,
• alle einschlägigen Lizenzpflichten sind im Zeitpunkt der Verbreitung erfüllt.
Bei einer Verletzung der Zusicherungen sollte der Lieferant dazu verpflichtet werden, Abhilfe zu schaffen und von Schäden freizustellen.

Wir beraten Hersteller von embedded systems und Hersteller von Endgeräten mit embedded systems beim Identifizieren und Minimieren von rechtlichen Risiken und unterstützen sie bei allen Fragen der Lizensierung und des Urheberrechts.

Michaela Witzel, LL.M. (Fordham University School of Law), Fachanwältin für IT-Recht
witzel@web-partner.de

Verwandte Artikel:
• Open Source Software – Teil 1: Welche Geschäftsmodelle stehen dahinter?
• Open Source Software -Teil 2: Welche rechtlichen Risiken drohen?
• Open Source Software -Teil 3: Worauf kommt es bei der Compliance an?