Docker und Open-Source-Lizenzen

Wenn Open-Source-Software eingesetzt wird, müssen die Lizenzbedingungen für die Open-Source-Software eingehalten werden. Das ist nicht neu. Was gilt jedoch, wenn Open-Source-Software im Rahmen von Containervirtualisierungen wie Docker durch Docker-Images u. ä. genutzt wird — welche lizenzrechtlichen Anforderungen sind nun zu beachten?

Sind nur die Lizenzbedingungen für das Docker-Image zu beachten?

Nein. Wenn Docker-Images oder sonstige Images von Containervirtualisierungslösungen eingesetzt werden, müssen die Lizenzbedingungen sämtlicher Softwarebestandteile beachtet werden. Hier sind aufgrund der zusätzlichen „Ebene“ durch Docker oder die sonstige Containerlösung nun die Lizenzbedingungen für die im Image enthaltene Software zu beachten und zusätzlich die Lizenzbedingungen für die Software auf der Containerebene. Auf der Containerebene sind damit z. B. die Lizenzbedingungen für die Build-Skripte einzuhalten.

Kann man sich auf Angaben unter Portalen wie Docker Hub oder Git Hub verlassen?

Auf Portalen wie Docker Hub, Git Hub und sonstigen Portalen sind oftmals Angaben zu den relevanten Lizenzbedingungen enthalten. Diese Angaben sind in der Regel nicht verbindlich. Wenn dort unzutreffende Angaben vorhanden sind, entsteht dennoch ein Lizenzverstoß. Die Angaben unter solchen Portalen können daher eine erste Orientierung bieten, z. B. bei der Suche nach passenden Images. Vor dem endgültigen Einsatz des Images sollten die lizenzrechtlichen Angaben jedoch überprüft werden.

Was tun, wenn Lizenzangaben zum Docker-Image fehlen?

Es kann vorkommen, dass Lizenzbedingungen für Software auf der Ebene der Container-Lösung, wie z. B. Docker, keine Lizenzangaben enthalten. Was gilt dann?

Software ist (zumindest in der EU) urheberrechtlich geschützt. Dem Softwareurheber stehen die maßgeblichen Nutzungsrechte zu. Wenn Ihnen Nutzungsrechte nicht über Lizenzbedingungen eingeräumt werden, dürfen urheberrechtlich relevante Handlungen wie Vervielfältigungen nicht vorgenommen werden. Sind keine Lizenzbedingungen vorhanden, dürfen Sie das Docker-Image somit nicht nutzen.

Allerdings dürfte es sich bei derart fehlenden Lizenzbedingungen in der Regel um ein Versehen handeln. Es kann sich lohnen, Kontakt mit den Urhebern aufzunehmen, um die Situation zu lösen. Build-Skripte zu Docker-Images werden regelmäßig unter die Apache License 2.0 gestellt. Zudem können sich aus den Allgemeinen Geschäftsbedingungen der jeweils verwendeten Plattform Sonderregelungen ergeben. Hier finden sich zum Teil Bestimmungen dahin, dass automatisch gewisse Nutzungsrechte eingeräumt werden, wenn Inhalte eingestellt werden, ohne dass gesonderte Lizenzbedingungen genannt werden.

Müssen auch Lizenzbedingungen von nicht verwendeter Software beachtet werden?

Docker-Images enthalten oftmals eine Vielzahl unterschiedlicher Softwarekomponenten. Vermutlich wird nicht jede diese Softwarekomponenten wird von Ihnen benötigt. Müssen Sie auch die Lizenzbedingungen für diese Komponenten einhalten?

Ja, denn auch solche Softwarekomponenten werden urheberrechtlich relevant verwendet, z. B. durch Vervielfältigungen des Images mitsamt der technisch nicht benötigten Software.

Wie weitreichend sind die Informationspflichten?

Es gibt zahlreiche Open-Source-Lizenzen. Die vollkommen überwiegende Zahl der Open-Source-Lizenzen enthält – neben anderen Anforderungen – die Voraussetzung, dass bestimmte Informationspflichten mit Bezug auf den jeweiligen Lizenztyp zu beachten sind. Diese Informationspflichten sind im Rahmen von Docker-Images und sonstigen Containervirtualisierungslösungen ebenso hinsichtlich sämtlicher „Ebenen“ einzuhalten.

Nicht sämtliche Informationspflichten müssen jedoch zwingend an einer bestimmten Stelle erteilt werden. Hierzu enthalten die verschiedenen Lizenzbedingungen zum Teil auch unterschiedliche Anforderungen. So sollten z. B. im letztlich über das Docker-Image oder das sonstige Image realisierten Programm die zumindest für dieses Programm maßgeblichen Lizenzbedingungen beachtet werden und die entsprechenden Informationen erteilt werden.

Darf Software überhaupt im Rahmen von Docker-Images verwendet werden?

Der Frage, ob bestimmte Software in Docker-Images verwendet werden darf, wird in der Praxis oftmals übersehen und bleibt ungeprüft. Letztlich sind die Lizenzbedingungen jeder einzelnen im Docker-Image oder sonstigen Image verwendeten Software zur Beantwortung dieser Frage zu prüfen. Jeder Softwareurheber kann hierzu gesonderte Anforderungen stellen. Überwiegend sollten sich zumindest für die typischen Open-Source-Lizenzbedingungen jedoch kaum Probleme ergeben, die den Einsatz in der Praxis verhindern.

Kann eine Infizierung hinsichtlich des gesamten Containers eintreten?

Einige Open-Source-Lizenzbedingungen enthalten den sog. Copyleft-Effekt, der zu einer „Infizierung“ der eigenen oder sonstigen Software führt. Die General Public License (GPL) dürfte der bekannteste Lizenztyp dieser Art sein. Wird eine GPL-Softwarekomponente in zu enger Abhängigkeit mit sonstiger Software, z. B. der selbst ergänzend programmierten Software, eingesetzt, muss – summarisch zusammengefasst – diese sonstige Software ebenfalls unter der GPL lizenziert werden, also z. B. kostenlos im Quellcode Dritten zugänglich gemacht werden.

Bei proprietären Einsatzzwecken gilt es in der Regel, diesen Effekt um jeden Preis zu vermeiden, da derart die Investitionen in die eigene Software sowie das Unternehmens-Know-how verloren gehen können. Das Problem stellt sich zunächst in direkter Weise im Hinblick auf die eigene Software, die ggf. GPL-Software einbindet.

Fraglich ist allerdings, ob sich die Infizierung auch auf das gesamte Docker-Image oder das sonstige Image ausdehnen kann, wenn darin eine GPL-Komponente enthalten ist. Dies ist eine komplexe Fragestellung, die unter Berücksichtigung der im Docker-Image oder sonstigen Image enthaltenen Softwarekomponenten im Einzelnen zu prüfen ist. So steht z. B. der Linux-Kernel zwar unter der GPL, jedoch mit einer speziellen Ausnahme für User-Space-Anwendungen. Hier ist dann zu untersuchen, inwieweit diese Ausnahme auf das konkrete Docker-Image zu übertragen ist.

Vorangestellt ist jedoch zu untersuchen, ob durch die bloße Aggregierung von Softwarekomponenten unter einer Copyleft-Lizenz, wie z. B. der GPL, eine so enge Abhängigkeit entsteht, dass der Copyleft-Effekt und damit eine „Infizierung“ eintritt. Dies wird mit guten Gründen verneint werden können, da die bloße Aggregierung in einem Docker-Image oder sonstigen Image mit dem bloßen Vertrieb der Copyleft-Komponente in einer Linux-Distribution zu vergleichen sein könnte. Allerdings ist insoweit noch keine gefestigte Rechtsprechung vorhanden. Die bisherige Rechtsprechung führt darüber hinaus eher zu Bedenken hinsichtlich des vorstehenden Vergleichs. So hat z. B. das Landgericht Berlin entschieden, dass die Firmware eines Routers urheberrechtlich ein Sammelwerk gem. § 4 Abs. 1 UrhG darstelle und durch dieses Sammelwerk der GPL-Copyleft-Effekt ausgelöst werde (LG Berlin, Urt. v. 08.11.2011, Az. 16 O 255/10 – „Surfsitter“).

Fazit

Durch die Verwendung von Docker-Images oder sonstigen Containervirtualisierungslösungen wird eine moderne Technologie verwendet, die ein „Continuous Deployment“ und ein „Continuous Delivery“ ermöglichen. Auf diese Technologie wird in Zukunft, insbesondere auf intensiv genutzten Systemen, die keine Downtime erlauben, nicht mehr verzichtet werden können. Allerdings führt der Einsatz dieser zusätzlichen Softwareebene nicht zu einer Vereinfachung der Lizenzthemen im Hinblick auf Open-Source-Software, sondern fügt vielmehr noch eine zusätzliche Schicht an Komplexität hinzu. Duch die Ergänzung einer weiteren „Ebene“ durch den zusätzlichen Einsatz von Orchestrierunglösungen wie Kubernetes (K8s) wird der Komplexitätsgrad nochmals erhöht.

Diese Themen werden in der Regel letztlich kein Hindernis für den Einsatz in der Praxis darstellen. Allerdings dürfen sie nicht übersehen werden und nicht ohne rechtliche und sachliche Ausgestaltung bleiben. Andernfalls drohen die auch ansonsten möglichen Ansprüche z. B. auf Unterlassung und Schadensersatz oder zumindest ein negatives Marketing wegen angeblicher Lizenzverletzungen.