Source: https://www.ra-plutte.de/open-source-software-recht-grosse-faq-tipps/
Timestamp: 2020-01-24 03:04:19+00:00

Document:
Kanzlei » News » IT-Recht » Open Source Software Recht: Große FAQ mit vielen Praxistipps
Nutzung, Weiterentwicklung und der Vertrieb von Software unter Open Source Lizenz (OSS) liegen im Trend. Einher gehen oft rechtliche Unsicherheiten. Auf die häufigsten Rechtsfragen rund um Open Source Software gehen wir in diesen FAQ ein.
1. Was bedeutet Open Source Software (OSS) und welche Arten gibt es
2. Was sind die wichtigsten Unterschiede bei Open Source Lizenzen?
3. Welche sind die bekanntesten und häufigsten OSS-Lizenzen?
4. Wie grenzt man OSS zu anderen „freien“ Lizenzarten ab?
5. Was bedeutet der Begriff „proprietäre Software“?
6. Kann man OSS in Software integrieren, ohne dass diese zu OSS wird?
7. Was ist der virale Effekt bei Lizenzen mit strengem Copyleft-Effekt?
8. Wann greift der virale Effekt ausnahmsweise nicht?
9. Kann man den Copyleft-Effekt umgehen?
10. Kann man den Copyleft-Effekt durch Software as a Service (SaaS) umgehen?
11. Welche Rechtsfolgen drohen bei Verstoß gegen die Nutzungsbedingungen?
– Welche Ansprüche hat der Rechteinhaber?
– Welche Ansprüche haben Anwender?
12. Wie lizenziert man eigene Software unter OSS Lizenz?
13. Können englische Lizenzbedingungen in Deutschland verwendet werden?
14. Welche Rechte stehen einem Weiterentwickler von OSS zu?
15. Kann man allein Rechte aus einer OSS durchsetzen?
– Was ist bei Miturheberschaft zu beachten?
– Was gilt bei Werkverbindung zu beachten?
16. Was ist bei Geltendmachung eines Unterlassungsanspruchs wegen Verstoßes gegen die Nutzungsbedingungen einer bearbeiteten Software zu beachten?
17. Tabellarische Übersicht zu Rechtspflichten bei beliebten OSS Lizenzen
1. Was bedeutet Open Source Software (OSS) und welche Arten gibt es?
Der Begriff „Open Source Software“ wurde in IT-Fachkreisen entwickelt, eine gesetzliche Definition existiert nicht. Damit eine Software nach der Definition der Open Source Initiative (OSI) als Open Source Software gilt, muss die Lizenz die folgenden zehn Kriterien erfüllen:
Freie Redistribution: Die Lizenz muss es jedermann erlauben, die Software weiter zu vertreiben oder anzubieten. Es darf keine Lizenzgebühr verlangt werden.
Zugang zum Quellcode: Das Programm muss im Quellcode für den Nutzer leicht verfügbar sein.
Zulässigkeit von Weiterentwicklungen: Die Lizenz muss die Weiterentwicklung des Programms sowie die Schaffung eigener Programme zulassen sowie auch deren Verbreitung unter denselben Bedingungen wie die Originalsoftware.
Zulässige Beschränkungen des Vertriebs von Modifikationen: Die Lizenz muss zwar die Verteilung von Modifizierungen des Originalquellcodes zulassen, darf aber verlangen, dass die Software dann einen anderen Namen bekommt und dass die Änderungen dokumentiert werden.
Keine Diskriminierung von Personen oder Personengruppen.
Keine Nutzungseinschränkung: Die Nutzung der Software darf nicht für bestimmte Zwecke ausgeschlossen werden.
Lizenz muss für alle zutreffen: Die Lizenz muss für jeden gelten, der die Software erhält. Es dürfen keine Sonderlizenzen vergeben werden.
Produktneutralität der Lizenz: Die Lizenz darf nicht nur auf eine Software zugeschnitten sein, sondern muss auch für daraus entwickelte Software gleichermaßen gelten.
Keine Einschränkung anderer Software: Die Lizenz darf keine Bestimmungen über andere Software treffen.
Technologieneutralität: Die Lizenz darf die Verbreitung der Software nicht auf eine bestimmte Technologie beschränken.
In einem Atemzug mit Open Source Software wird regelmäßig Free Software genannt. Die Mutter des Konzepts der Free Software, die Free Software Foundation (FSF), legt zwar Wert darauf, dass die Begriffe nicht deckungsgleich sind. Gleichzeitig räumt sie ein, dass beide Begriffe nahezu die gleiche Softwarekategorie erfassen. Der Begriff „Open Source“ beschreibe lediglich die Entwicklungsmethodik, während „Free Software“ eine soziale Bewegung mit einer dahinterstehenden (freiheitlichen) Ideologie bezeichne.
Hinweis: In der Praxis werden beide Begriffe synonym verwendet. Die Darstellungen in diesem Artikel beziehen sich daher sowohl auf Programme, die als Open Source Software bezeichnet werden als auch auf Free Software. Der besseren Lesbarkeit halber verwenden wir nur den Begriff „Open Source Software“.
Alle Open Source Lizenzen haben die Einräumung eines Vervielfältigungs- und Verarbeitungsrechts gemeinsam, welches meist bestimmten Voraussetzungen bzw. Beschränkungen unterliegt. Die einzelnen Lizenzen unterscheiden sich vor allem hinsichtlich der Nutzungsbedingungen und der Verpflichtungen, die dem Lizenznehmer zur Wahrnehmung des Vervielfältigungsrechts und des Verarbeitungsrechts aufgegeben werden.
Wichtigster Gesichtspunkt ist, welche Anforderungen an die Weiterverbreitung von veränderten Versionen der Software bzw. neuer Software gestellt werden, die auf Grundlage von Open Source Software entwickelt wurde.
Die verschiedenen Lizenzmodelle lassen sich am besten danach unterscheiden, ob die jeweilige Lizenz einen sog. Copyleft-Effekt beinhaltet oder nicht. Der Copyleft-Effekt beschreibt die Verpflichtung des Lizenznehmers, die Software sowie jede Bearbeitung ebenfalls unter denselben Lizenzbedingungen als Open Source Software auszugeben.
a. Lizenzen mit strengem Copyleft-Effekt
Lizenzen mit strengem Copyleft-Effekt verpflichten den Lizenznehmer, die Software oder jede Bearbeitung ebenfalls unter denselben Lizenzbedingungen wie die Originalsoftware als Open Source Software auszugeben.
Beispiele: GNU General Public License (GPL), Deutsche Freie Softwarelizenz (d-fsl).
b. Lizenzen mit beschränktem Copyleft-Effekt
Bei Lizenzen mit beschränktem Copyleft-Effekt sind bestimmte Formen der Weiterverarbeitung vom Copyleft-Effekt ausgenommen.
Beispiele: GNU Lesser General Public License, Zimbra Publice License (ZPL); Mozilla Public License (MPL).
c. „Interoperable“ Copyleft-Lizenzen
Die Europäische Kommission vertritt auf ihrer joinup-Plattform die Ansicht, dass die Unterscheidung zwischen strengem und eingeschränkten Copyleft-Effekt rechtlich nur selten relevant sei, weil sie die Tragweite des viralen Effekts als wesentlich geringer einschätzt. Daher gelten insoweit einige Besonderheiten bei der von der EU-Kommission herausgegebenen European Union Public Licence (EUPL). Es handelt sich auch bei dieser um eine Copyleft-Lizenz (https://eupl.eu/ – Objectives). Gleichwohl greift der virale Effekt nach Meinung der Kommission nicht bei Verlinkungen (auch nicht bei statischen) von anderen Programmen, wenn diese zum Zwecke der Interoperabilität erfolgen. Die Kommission ordnet die EUPL daher in eine neue Kategorie der „Interoperable Copyleft„-Lizenzen ein.
d. Lizenzen ohne Copyleft-Effekt
Lizenzen ohne Copyleft-Effekt, auch „Permissive Licenses“ genannt, räumen dem Lizenznehmer alle Freiheiten einer Open Source Lizenz ein, verpflichten hinsichtlich der Weiterverbreitung aber zu keinem bestimmten Lizenztyp. Daher kann der Lizenznehmer veränderte Versionen problemlos als proprietäre Software vertreiben.
Beispiele: MIT Lizenz; BSD-Lizenzen; Apache 2.0 License; Mozart License.
e. Lizenzen mit Wahlmöglichkeiten oder Sonderrechten
Über die genannten Lizenztypen hinaus existieren Mischformen der obigen Lizenzen, die sich dadurch auszeichnen, dass dem Lizenznehmer bestimmte Wahlmöglichkeiten zur Verbreitung von Weiterentwicklungen eingeräumt werden oder dass sie dem Lizenzgeber besondere Privilegien hinsichtlich der Weiterentwicklungen einräumen.
Beispiele: Artistic License, RealNetworks Public Source License.
Eine ausführliche Übersicht über alle wichtigen Open Source-Lizenzen finden Sie beim Institut für Rechtsfragen der Freien und Open Source Software (ifrOSS).
Beispiele für populäre Open Source Software: Linux, WordPress, Java, Joomla, Apache OpenOffice, Ubuntu.
Nach einer Studie handelt es sich bei der MIT Lizenz um die am weitesten verbreitete Open Source Lizenz ohne Copyleft-Effekt. Bekannte Beispiele unter MIT Lizenz sind etwa Ruby on Rails, Node.js und JQuery. Auch auf GitHub stehen die mit Abstand meisten Projekte unter MIT Lizenz. Die MIT Lizenz ist sehr freizügig, sie enthält nahezu keine Beschränkungen. Insbesondere können Weiterentwicklungen von Software unter MIT Lizenz unproblematisch als proprietäre Software kommerziell vertrieben werden, ohne dass der Quelltext offengelegt werden muss.
Die bekannteste und am häufigsten genutzte Open Source Lizenz mit Copyleft-Effekt ist die GNU General Public License in ihrer aktuell dritten Version (GPLv3), die von der Free Software Foundation im Rahmen des GNU-Projekts entwickelt wurde. Jede Weiterentwicklung oder Umgestaltung von GPL-Software darf ebenfalls nur unter GPL-Bedingungen weiterverbreitet werden. Software, die unter GPL lizenziert ist, kann daher grundsätzlich nicht zur Gewinnerzielung verwendet werden, da die GPL lediglich die Zahlung eines Entgelts für die Anfertigung von Kopien oder besondere Gewährleistungs- und Serviceleistungen zulässt. Die FSF hat mit der GNU Lesser General Public License (LGPL) auch eine Lizenzversion mit schwächerem Copyleft-Effekt veröffentlicht, die insbesondere eine Einbindung in proprietäre Software erlaubt, ohne dass der Quellcode der eigenen Ergänzungen offengelegt werden muss.
Die hier vorgestellten Open Source Lizenzen weisen gewisse Ähnlichkeiten mit anderen Lizenzarten auf. Umso wichtiger ist es, eine sorgfältige Abgrenzung vorzunehmen:
Freeware: Ebenso wie Open Source Software ist Freeware unentgeltlich erhältlich und darf auch weiterverbreitet werden. Freeware wird in der Regel aber ohne Quellcode ausgeliefert. Änderungen sowie Weiterentwicklungen sind untersagt.
Shareware: Bei Shareware handelt es sich um gewöhnliche proprietäre Software, die (aus Marketinggründen) in einer Testphase unentgeltlich angeboten wird. Um die Software nach Ablauf der Testphase weiter nutzen zu können, muss die geforderte Vergütung gezahlt werden. Shareware wird ebenfalls ohne Quellcode ausgeliefert und darf nicht verändert werden.
Public Domain Software: Public Domain Software beschreibt ein aus den USA stammendes Prinzip, bei dem gänzlich auf Urheberrechte verzichtet wird. Da ein Verzicht auf das Urheberrecht nach deutschem Recht unmöglich ist (§ 29 Abs. 1 UrhG), wird eine Public Domain Lizenz in Deutschland als einfaches Nutzungsrecht gewertet, das eine unbeschränkte Verwertung der Software zulässt (vgl. Marly, Handbuch Softwarerecht, Rn. 883 ff.).
Um die bisherigen Ausführungen zu veranschaulichen, zeigen wir anhand eines Beispiels, wie man mit Open Source Software umgehen kann, die unter a) GPL V3 bzw. b) CC BY-Lizenz angeboten wird.
Ein Unternehmen möchte die Software „OS“ einsetzen, die es ermöglicht, Dateien auf einem Computer übersichtlich zu organisieren und zu verknüpfen. Das Unternehmen hat verschiedene Pläne, wie es die Software verwenden will:
Nutzung: Die Software soll auf eigenen PCs installiert und dort zur Organisation der eigenen Dateien verwendet werden.
Bearbeiten: Das Unternehmen will den Quellcode von „OS“ verändern („Customizing“), um die Funktionen an seine eigenen Bedürfnisse anzupassen und die Software danach für eigene Zwecke zu verwenden.
Weiterverbreitung: Das Unternehmen will die von ihm bearbeitete und optimierte Version der Software auf seiner Website für Dritte zum Download anbieten.
Nachfolgend beschreiben wir, was das Unternehmen rechtlich beachten muss, je nachdem, ob „OS“ unter GPL V3 oder CC BY lizenziert ist:
GPL V3: Die einfache Nutzung der Software wird durch die GPL in keiner Weise eingeschränkt (Nr. 2 Abs. 1 S. 2 GPL V3). Nutzung heißt hier das Laden der Software in den Arbeitsspeicher sowie das Ablaufenlassen des Quellcodes. Das Unternehmen kann das Programm für sich also nach Belieben nutzen und muss dabei nichts weiter beachten.
CC BY: Die CC BY-Lizenz schränkt die Nutzung der Software ebenfalls in keiner Weise ein.
GPL V3: Auch in der Bearbeitung des Programms unterliegt das Unternehmen keinen Beschränkungen (Nr. 2 Abs. 2 GPL V3). Es kann die Software „OS“ nach Belieben modifizieren und sie danach uneingeschränkt verwenden.
CC BY: Auch nach der CC BY-Lizenz gilt das Gleiche wie bei einer Lizenzierung unter GPL V3.
Unterschiede machen sich beim Weiterverbreiten der Software bemerkbar:
GPL V3: Unter welchen Voraussetzungen das Unternehmen die von ihm modifizierte Version der Software auf der eigenen Webseite zum Download anbieten darf, ist in Nr. 5 GPL V3 geregelt. Danach müssen bei Verbreitung einer modifizierten Version der Software folgende Bedingungen erfüllt sein:
Urheberrechtsvermerk: Nach Nr. 5 i.V.m. Nr. 4 GPL V3 muss die modifizierte Software einen Urheberrechtsvermerk auf den Urheber der „OS“-Software enthalten.
Vermerk der Modifizierung: Nach Nr. 5 lit. a GPL V3 muss die modifizierte Software einen Vermerk enthalten, dass sie modifiziert wurde, von wem sie modifiziert wurde und wann sie modifiziert wurde.
Vermerk der Lizenzierung unter GPL: Nach Nr. 5 lit. b GPL V3 muss die modifizierte Software einen deutlichen Vermerk enthalten, dass sie unter der GPL V3 lizenziert wird.
Lizenzierung unter der GPL: Konsequenterweise darf dann auch die modifizierte Software nur unter der GPL V3 an Dritte lizenziert werden. Insbesondere muss daher jedem Erwerber ein Exemplar der GPL V3 Lizenz mitgegeben werden (Nr. 5 lit. c, Nr. 4 GPL V3).
Rechtliche Hinweise in Programm: Nicht nur beim Erwerbsvorgang, sondern auch bei der Programmnutzung selbst müssen den Erwerbern Hinweise zur Rechtslage gegeben werden, vorausgesetzt, der Nutzer kann interaktiv auf das laufende Programm einwirken. Das Unternehmen muss daher in seine modifizierte Version einen Menüpunkt mit rechtlichen Hinweisen einbauen.
CC BY: Die CC BY-Lizenz stellt etwas geringere Anforderungen an die Weiterverbreitung von bearbeiteten Versionen. Ist „OS“ unter CC BY lizenziert, muss das Unternehmen bei der Verbreitung der modifizierten Version Folgendes einhalten:
Urheberrechtsvermerk mit Namensnennung: Am wichtigsten ist, dass der Lizenzgeber (= Urheber von „OS“) mit seinem Namen als Urheber der abgewandelten „OS“ bezeichnet wird.
Hinweis auf CC BY: Es muss ein Hinweis erfolgen, dass die ursprüngliche „OS“ unter CC BY lizenziert war, wobei die CC BY Lizenzbedingungen verlinkt werden müssen.
Hinweis auf Haftungsausschluss: Es muss ein Hinweis auf den Haftungsausschluss nach der CC BY erfolgen.
Wenn möglich Link zur Ursprungssoftware: Sofern umsetzbar, muss eine URL oder ein Hyperlink zur Ursprungssoftware gesetzt werden, in unserem Beispiel also zu „OS“.
Vermerk der Modifizierung: Wie bei der GPL muss auch unter der CC BY Lizenz gekennzeichnet werden, dass das Unternehmen die „OS“ in seiner ursprünglichen Form abgeändert hat.
Unterschied zu GPL: Im Gegensatz zur GPL V3 ist bei der CC BY mangels Copyleft-Effekt nicht erforderlich, dass die abgewandelte Version auch unter CC BY lizenziert wird.
In der Literatur wird als Gegenbegriff zu Open Source Software der Begriff der proprietären Software verwendet. Proprietäre Software bezeichnet nach der FSF Software, deren Nutzung, Neuvertrieb oder Modifizierung untersagt oder stark eingeschränkt ist. Proprietäre Software zeichnet sich u.a. dadurch aus, dass ihr Quellcode nicht zugänglich gemacht wird.
Beispiele: Microsoft Windows, McAfee, Apple iOS, Adobe Photoshop.
Die wichtigste Frage für viele Unternehmen ist, ob eigene Software, in die Open Source Software integriert bzw. die auf Grundlage von Open Source Software entwickelt wurde, als proprietäre Software ohne Offenlegung des Quellcodes vertrieben werden kann oder ob diese zwingend selbst zu Open Source Software wird. Entscheidend sind die Lizenzbedingungen der jeweiligen Open Source Lizenz. Hierbei kommt es maßgeblich auf den bereits mehrfach angesprochenen Copyleft-Effekt an:
Bei Lizenzen ohne Copyleft-Effekt (sog. Permissive Licenses) kann die jeweilige OSS in das eigene Produkt integriert werden, ohne dass dieses unter der Open Source Lizenz der OSS vertrieben werden müsste. Vorsicht: Sofern die OSS Lizenz Einschränkungen enthält (typischerweise die Pflicht zur Anbringung eines Urhebervermerks sowie Angabe der Lizenzbestimmungen im Quelltext, ggf. weitere Anforderungen), müssen diese beachtet werden. Andernfalls entfällt das Nutzungsrecht mit der Folge, dass Unterlassungs- und Schadensersatzansprüche drohen.
Bei Lizenzen mit strengem Copyleft-Effekt wie der GPLv2 darf eine Verarbeitung und Vervielfältigung nur unter der Bedingung stattfinden, dass der vollständige neue Quellcode offengelegt wird (vgl. LG Hamburg, Urteil vom 14.06.2013, Az. 308 O 10/13 – FANTEC).
Bei Lizenzen mit beschränktem Copyleft-Effekt oder solchen mit Wahlmöglichkeiten und Sonderrechten müssen die konkreten Lizenzbestimmungen im Einzelfall geprüft werden. Die Beschränkung des Copyleft-Effekts besteht z.B. oftmals darin, dass der Quellcode der eigenen Softwareteile nicht veröffentlicht werden muss.
Handelt es sich bei der bearbeiteten Open Source Software um eine solche mit strengem Copyleft-Effekt, muss besonders auf den sog. viralen Effekt geachtet werden.
Der virale Effekt bezeichnet die Gefahr, dass bei Einbindung von Open Source Software mit (strengem) Copyleft-Effekt auch selbst kreierte Software-Teile nur noch als Open Source Software vertrieben werden können und ihr Quellcode im Rahmen der Open Source Lizenz offenzulegen ist (vgl. LG Hamburg, Urteil vom 14.06.2013, Az. 308 O 10/13 – FANTEC). Bei der GPLv3 ist der virale Effekt beispielsweise in § 5 lit. c der GPLv3 Lizenzbedingungen verankert. Die Bezeichnung „viral“ ist in der Wirkung des Copyleft-Effekts begründet, der wie ein Virus selbständig entwickelte Softwareteile „infiziert“. Von der umgekehrten Warte aus wird teilweise auch von einem „immunisierenden Effekt“ gesprochen, weil das Copyleft-Modell einen Quellcode vor Geheimhaltung und Ausschließlichkeitsrechten schützt.
Beispiel für den viralen Effekt: AVM als Hersteller der bekannten FRITZ!Box Router hatte für deren Firmware verschiedene Dateien zusammengefügt. Darunter befand sich der Linux Kernel, der unter der GPL lizenziert ist. Wegen des in der GPL geregelten viralen Effekts stellte das Landgericht Berlin fest, dass AVM verpflichtet war, seine Firmware der GPL zu unterstellen. AVM konnte daher insbesondere keinen Unterlassungsanspruch gegen einen konkurrierenden Anbieter von WLAN-Routern geltend machen, der die Firmware des FRITZBox-Herstellers bearbeitet und selbst verwendet hatte (vgl. LG Berlin, Urteil vom 08.11.2011, Az. 16 O 255/10).
Der virale Effekt tritt nur bei Einbindung / Integration der Open Source Software in die eigene Software auf. Eine solche Integration liegt nicht vor, wenn der Programmierer lediglich eine Software-Entwicklungsumgebung mit Open Source Lizenz für seine Softwareentwicklung nutzt.
Beispiele: JDeveloper; Eclipse
Ebenso liegt keine Integration in eine eigene Software vor, wenn eine Open Source Software-Komponente lediglich als eigenständiges Subsystem ausgeführt wird, da hierzu nicht deren Quellcode benötigt wird (vgl. Hoppen/Thalhofer in CR 2010, 275 ff.).
Beispiel: JasperReports
Sobald aber der Quellcode der Open Source Software in irgendeiner Weise mit der eigenen Software verknüpft wird, soll nach Ansicht der Free Software Foundation der virale Effekt greifen (siehe auch: Intveen/Gennen/Karger, Handbuch Softwarerecht, § 16 Rn. 30). Gleichwohl wird in der juristischen Literatur vielfach nach Umgehungsmöglichkeiten gesucht.
Die Europäische Kommission ist der Ansicht, dass der virale Effekt auch dann nicht greift, wenn eine Verlinkung eines Open Source-Programms zu Zwecken der Interoperabilität erfolgt. Sie begründet dies damit, dass nach den Erwägungsgründen 10 und 15 der EU-Richtlinie 2009/24/EG das Urheberrecht an Software nicht verletzt wird, wenn diese lediglich zum Zwecke der Herstellung von Interoperabilität mit anderen Programmen eingebunden wird. Daher stelle die Verlinkung von Software keine urheberrechtlich relevante Handlung dar, weshalb auch die Lizenzbedingungen nicht griffen. Unter dieser Prämisse würde auch der virale Effekt in derartigen Fällen keine Rolle spielen. Die Kommission verweist zur Untermauerung ihrer Ansicht insbesondere auf ein Urteil des EuGH vom 02.05.2012 (Az. C-406/10), in welchem dieser in der Untersuchung eines fremden Programms zur Herstellung von Interoperabilität keine Verletzung des Urheberrechts sah.
Der virale Effekt ist eine ungewünschte Folge der Integration von Open Source Software in eigene Software. Daher verwundert es nicht, dass mangels gefestigter Rechtsprechung in der juristischen Literatur intensiv nach Möglichkeiten gesucht wird, Open Source Software mit Copyleft-Effekt verwenden zu können, ohne dass die eigene Software „infiziert“ wird.
Diese Bemühungen waren bisher nicht sonderlich erfolgreich. Die erfolgversprechendste Möglichkeit zur Umgehung des Copyleft-Effekts dürfte darin bestehen, die eigene Software und die Open Source Software nicht als Teil eines Ganzen zu werten. Dies muss unter zwei Gesichtspunkten sichergestellt werden (nach Intveen/Gennen/Karger/Völkel/Kremer, Handbuch des Softwarerechts, § 16 Rn. 31 f.):
Formale Trennung von Open Source Software und eigener Software: Open Source Software und eigene Software dürfen zum einen nicht verbunden werden, zum anderen müssen sie getrennt verbreitet werden, zum Beispiel durch getrennten Download. Eine Verlinkung muss dynamisch (und nicht statisch) erfolgen.
Inhaltlich-funktionale Eigenständigkeit: Sowohl eigene Software als auch Open Source Software müssen ihrer Funktion nach als eigenständige Programme betrachtet werden können.
Im Ergebnis würde nach diesem Ansatz die Wirkung von zwei eigenständigen Programmen erzeugt, die zusammengeführt werden und sich in ihren Wirkungen ergänzen; jedoch nicht so, als würde ein neues einheitliches „Ganzes“ geschaffen. Inwieweit dann noch von der Open Source Software profitiert werden kann, ist freilich ein anderes Thema.
Achtung: Ob der vorstehende Ansatz die gewünschte Trennungswirkung erzeugt, wurde noch nicht gerichtlich überprüft. Deswegen bestehen Unsicherheiten, zumal das Landgericht Berlin angedeutet hatte, dass es von einem weiten Wirkungskreis des viralen Effekts ausgeht (LG Berlin, Urteil vom 08.11.2011, Az. 16 O 255/10 – Surfsitter)
Da Software heute in zunehmendem Maße nicht mehr verkauft, sondern in Form von Software as a Service (SaaS) angeboten wird, könnte es interessant sein, Open Source Software (bzw. eigene Software, die mit Open Source Software verbunden wurde) als SaaS anzubieten.
Beinhalten die Lizenzbedingungen der genutzten Open Source Software einen (strengen) Copyleft-Effekt, stellt sich die Frage, ob dadurch der virale Effekt eintritt und die Bereitstellung des SaaS nach den Lizenzbedingungen der Open Source Software erfolgen muss, insbesondere also eine Offenlegung des Quellcodes zu erfolgen hat.
Nach herrschender Ansicht in der juristischen Literatur soll der virale Effekt des Copyleft-Effekts bei SaaS jedoch nicht greifen. In der Leistung eines Software as a Service könne keine Verbreitung der Open Source Software nach den gängigen Lizenzbedingungen gesehen werden, da der Anwender gerade keine Privatkopie der Software erhalte.
Achtung: Der virale Effekt greift nur dann nicht, wenn der SaaS-Anbieter die Software mit den integrierten Open Source Softwarebestandteilen selbst entwickelt hat. Hatte der Anbieter die Software bei einem Dritten in Auftrag gegeben, liegt darin schon eine Distributionshandlung nach den Lizenzbedingungen, so dass der Copyleft-Effekt und insbesondere die Offenlegungspflicht greifen (so Intveen/Gennen/Karger/Völkel/Kremer, Handbuch des Softwarerechts, § 16 Rn. 12; Hilber/Reintzsch in CR 2014, 697 ff.).
Hilber/Reintzsch betonen, dass ihrer Ansicht nach zwar der Copyleft-Effekt nicht greift, aber Zweifel daran bestehen, ob die Lizenzbedingungen der GPL die Verwendung von Software als SaaS an sich überhaupt erlauben. Die GPL äußert sich hierzu nicht ausdrücklich. Möglicherweise könnte gerade diese fehlende Thematisierung zum Verhängnis werden, da nach deutschen Urheberrecht die Zweckübertragungslehre zu beachten ist (§ 31 Abs. 5 UrhG).
Die Zweckübertragungslehre bezeichnet einen Auslegungsgrundsatz, wonach der Urheber seinem Vertragspartner Nutzungsrechte im Zweifel nur in dem Umfang einräumt, den der Vertragszweck unbedingt erfordert. Im Umkehrschluss verbleiben nicht genannte und für den Vertrag nicht zwingend erforderliche Rechte im Zweifel beim Lizenzgeber.
Das könnte hier bedeuten, dass die Verwendung von Software für SaaS keine zulässige Nutzung darstellt und somit ein Verstoß gegen die Lizenzbedingungen der Open Source Lizenz vorliegt (vgl. Hilber/Reintzsch in CR 2014, 697 ff).
Was zunächst wie eine vielversprechende Variante wirkt, birgt mangels Rechtsprechung ein hohes Risikopotential. Die Verwendung von Open Source Software mit Copyleft-Effekt im Rahmen von SaaS ist daher aktuell nicht risikofrei möglich.
Ein Verstoß gegen die Lizenzbedingungen der Open Source Software stellt eine Urheberrechtsverletzung dar. Grund ist, dass die Nutzungsrechte an Open Source Software unter der auflösenden Bedingung (§ 158 Abs. 2 BGB) eingeräumt werden, dass nicht gegen die Lizenzbestimmungen verstoßen wird (vgl. OLG Hamm, Urteil vom 13.06.2017, Az. 4 U 72/16). In diesem Fall entfällt das Nutzungsrecht des Anwenders und der Rechteinhaber kann gemäß §§ 97 ff. UrhG Ansprüche auf Unterlassung, Auskunft, Schadensersatz und ggf. Ersatz von Abmahnkosten geltend machen (vgl. LG Hamburg, Urteil vom 14.06.2013, Az. 308 O 10/13).
Das OLG Hamm ging in der vorstehenden Entscheidung davon aus, dass ein Verstoß gegen die Lizenzbedingungen zwar einen Unterlassungsanspruch aus § 97 Abs. 1 UrhG auslöse, jedoch kein Schadensersatz verlangt werden könne. Andere Gerichte hatten Schadensersatz nach den Grundsätzen der Lizenzanalogie zugesprochen (LG Bochum, Urteil vom 03.03.2016, Az. I-8 O 294/15; LG Hamburg, Urteil vom 14.06.2013, Az. 308 O 10/13). Knackpunkt ist die Frage, worin genau ein Schaden zu sehen ist, da Open Source Software kostenfrei angeboten wird. Hier wird häufig eingewandt, dass eine Befreiung von den Pflichten der Open Source-Lizenzen – insbesondere dem strengen Copyleft – einen wirtschaftlichen Wert habe, der auszugleichen sei. Eine gefestigte Rechtsprechung existiert jedoch nicht, so dass die weitere Entwicklung beobachtet werden muss.
Wenn ein Softwareanbieter Open Source Software in seinen Produkten nutzt und an Anwender abgibt, ohne diese darüber zu informieren, drohen auch in diesem Verhältnis Probleme. Der Anwender kann nicht ahnen, dass er es mit Open Source Software zu tun hat. Verstößt der Anwender gegen die Lizenzbedingungen, kann der Rechteinhaber auch gegen den Anwender gemäß §§ 97 ff. UrhG Ansprüche auf Unterlassung, Auskunft, Schadensersatz und ggf. Ersatz von Abmahnkosten geltend machen. Der Anwender wird sich dann wiederum an den Anbieter halten und von diesem Schadensersatz verlangen.
Eine nicht abgesprochene Verwendung von Open Source-Elementen (insbesondere solche mit Copyleft-Effekt) in Software für einen Anwender kann einen Rechtsmangel im Sinne von § 435 BGB darstellen und Gewährleistungsansprüche des Anwenders begründen.
Tipp: Achten Sie als Anbieter von Software mit Open Source-Bestandteilen darauf, Ihre Kunden über die Verwendung der Open Source-Bestandteile zu informieren. Wir empfehlen, bereits bei der Programmierung den Einsatz von Open Source-Software zu dokumentieren. Falls Sie Software extern entwickeln lassen, raten wir dazu, im Vertrag Dokumentationspflichten im Hinblick auf den Einsatz von Open Source Software zu regeln.
12. Was muss man beachten, wenn man eigene Software als OSS lizenzieren will?
Wer selbst entwickelte Software unter Open Source Lizenz zur Verfügung stellen möchte, muss sich vor allem Gedanken über die gewünschte Lizenz machen. Es ist hilfreich, sich im ersten Schritt einen groben rechtlichen Überblick zum Angebot eigener Software als Open Source Lösung zu verschaffen.
Die urheberrechtliche Lage bestimmt sich immer nach dem Recht des Landes, in welchem das Urheberrecht geltend gemacht wird (sog. Territorialitätsprinzip). Daher ist das Urheberrecht an Software in Deutschland allein nach dem deutschen Urheberrechtsgesetz (UrhG) zu beurteilen, auch wenn die Software in einem anderen Land programmiert wurde. Umgekehrt ist in Deutschland programmierte Software in Frankreich nach dem französischen Urheberrecht geschützt.
In Deutschland genießt Software Urheberrechtsschutz nach §§ 2 Abs. 1 Nr. 1, 69a UrhG, und zwar sowohl das Quellprogramm als auch das Objektprogramm. Was dieser Schutz genau umfasst, ist in den §§ 69c, 69d UrhG geregelt: Dem Rechtsinhaber steht das ausschließliche Recht zur Vervielfältigung, Bearbeitung, Verbreitung und öffentlichen Wiedergabe der Software zu.
Das Urheberrecht kann nicht einfach „abgelegt“ werden, weil dies nach § 29 S. 2 UrhG unzulässig ist (sog. Unverzichtbarkeit des Urheberrechts; vgl. Marly, Handbuch Softwarerecht Rn. 883). Ein Urheber kann aber unentgeltlich ein einfaches Nutzungsrecht (§ 31 Abs. 2 UrhG) für jedermann einräumen. Das ist sogar ausdrücklich in der sog. Linux-Klausel in § 32 Abs. 3 S. 3 UrhG geregelt. Dieses Recht muss nicht vollumfassend eingeräumt werden, sondern kann gemäß § 31 Abs. 1 S. 2 UrhG räumlich, zeitlich oder inhaltlich beschränkt werden.
Hiervon ausgehend ist das Bereitstellen von eigener Software rechtlich folgendermaßen einzuordnen: Grundsätzlich entsteht mit jedem Anwender der unentgeltlich zur Verfügung gestellten Software ein Schenkungsvertrag (§ 516 BGB). Jedem Anwender wird durch den Schenkungsvertrag ein einfaches Nutzungsrecht im Sinne von § 31 Abs. 2 UrhG eingeräumt, das allerdings in der Regel durch bestimmte Nutzungsbedingungen beschränkt ist. Die genauen Bedingungen der Nutzung (= die Lizenzbedingungen) werden als Allgemeine Geschäftsbedingungen Bestandteil des Vertrags, sofern sie wirksam einbezogen wurden. Die Lizenzbedingungen gelten dann verbindlich. Bei Open Source-Lizenzen ist es gängig, für den Fall von Verstößen gegen die Nutzungsbedingungen eine auflösende Bedingung (§ 158 Abs. 2 BGB) in den Vertrag aufzunehmen. Verstöße haben dann zur Folge, dass der Vertrag nichtig wird und das Nutzungsrecht rückwirkend entfällt.
Schwierig wird es, wenn es an die Wahl der passenden Lizenz für die eigene Software geht. Hier ist abzuwägen, aus welchem Grund man die eigene Software zur Verfügung stellt, um danach diejenige Lizenz zu wählen, die das Erreichen des Ziels am besten fördert. Die verschiedenen Möglichkeiten sind vielfältig und einzelfallabhängig. Eine gute Hilfestellung auf der Suche nach der passenden Open Source-Lizenz für das eigene Produkt bietet choosealicense.com.
Bei Lizenzbedingungen handelt es sich um Allgemeine Geschäftsbedingungen (AGB). Ihre Wirksamkeit richtet sich nach den §§ 305 ff. BGB. Die meisten Lizenzen sind in englischer Sprache verfasst. Zwar sind für einige Lizenzen online auch deutsche Übersetzungen verfügbar (so etwa die bereits mehrfach angesprochene Open Source-Lizenz „General Public License„). Allerdings wird gleich zu Beginn der Übersetzungen ausdrücklich angemerkt, dass die englischen Sprachfassungen rechtlich maßgeblich sind und die Übersetzungen nur der besseren Verständlichkeit dienen.
Damit stellt sich die Frage, ob englischsprachige Lizenzbedingungen überhaupt Vertragsbestandteil mit deutschen Unternehmern oder gar Verbrauchern werden können. Wegen des rechtlichen Fachvokabulars besteht in der juristischen Literatur die Sorge, dass es zumindest bei Verträgen mit Verbrauchern (also Privatpersonen, die nicht gewerblich handeln) an einer zumutbaren Möglichkeit zur Kenntnisnahme fehlen könnte (§ 305 Abs. 2 BGB).
Des Weiteren werden in der juristischen Literatur auch Zweifel an der inhaltlichen Wirksamkeit der Open Source-Lizenzen geäußert. So ist der dort geregelte vollständige Haftungsausschluss nach deutschem Recht gemäß § 276 Abs. 3 BGB unzulässig, auch wenn die Lizenzbedingungen diesen nur „soweit zulässig“ anordnen (vgl. Marly, Handbuch Softwarerecht, Rn. 964 f.). Hinzu wird im Speziellen die GPL als nicht hinreichend eindeutig und verständlich angesehen, was ebenfalls nach § 307 Abs. 1 S. 2 BGB zu ihrer Unwirksamkeit führen würde (vgl. Marly, Handbuch Softwarerecht, Rn. 942).
Im Gegensatz zu den in der Literatur geäußerten Bedenken gehen die deutschen Gerichte jedoch einhellig davon aus, dass die bekannteste Open Source Lizenz „GPL“ jedenfalls gegenüber Unternehmern wirksam (auf Englisch!) als Allgemeine Geschäftsbedingungen in den Vertrag einbezogen werden. Erstmals wurde dies 2004 vom LG München entschieden (LG München I, Urteil vom 19.05.2004, Az. 21 O 6123/04), dem später andere Gerichte folgten (ausdrücklich nach Prüfung: LG Halle, Urteil vom 27.07.2015, Az. 4 O 133/15; LG Frankfurt, Urteil vom 06.09.2006, Az. 2. 6 O 224/06; ohne Prüfung angenommen: LG Bochum, Urteil vom 03.03.2016, Az. I-8 O 294/15; LG Hannover, Urteil vom 21.07.2015, Az. 18 O 159/15). Ob dies auch gegenüber Verbrauchern gilt, ist offen.
Wer Open Source Software mit eigenem Quellcode ergänzt, schafft eine eigene Bearbeitung, die wie ein selbständiges Werk geschützt ist (§ 69c Nr. 2 S. 2 UrhG i.V.m. § 3 UrhG). Grundsätzlich kann der Bearbeiter einer Software also über das Produkt der Bearbeitung entscheiden wie über ein komplett selbständig erschaffenes Werk.
Hinweis: Die ursprüngliche Software bleibt weiterhin selbständig geschützt. Der Bearbeiter erwirbt durch die Bearbeitung keine Rechte an der Ursprungssoftware.
Wird hingegen Open Source Software mit anderen Komponenten zusammengefügt, entsteht ein Sammelwerk im Sinne von § 4 Abs. 1 UrhG (vgl. LG Berlin, Urteil vom 08.11.2011, Az. 16 O 255/10, wo der FRITZBox-Hersteller AVM die Firmware der Router aus zahlreichen einzelnen Dateien zusammengesetzt hatte; u.a. auch den unter GPL lizenzierten Linux Kernel). Wie Bearbeitungen sind auch Sammelwerke wie selbständige Werke geschützt (vgl. § 4 Abs. 1 UrhG).
Wenn, wie bei Open Source Projekten üblich, mehrere Programmierer an der Software arbeiten, entsteht im Ergebnis häufig Miturheberschaft an der bearbeiteten Software (§ 8 UrhG). Das ist der Fall, wenn jeder Entwickler einen (wenn auch nur geringen) schöpferischen Beitrag zu der Software leistet (vgl. BGH, Urteil vom 26.02.2009, Az. I ZR 142/06 – Kranhäuser) und sich die jeweiligen Anteile an der Software nicht gesondert verwerten lassen (§ 8 Abs. 1 UrhG).
Nicht erforderlich ist, dass die Beiträge gemeinsam oder gar gleichzeitig erbracht werden, solange sie sich in die gemeinsame Gesamtidee der Software einordnen (vgl. BGH, Urteil vom 03.03.2005, Az. I ZR 111/02 – Fash 2000). Lassen sich ausnahmsweise doch einzelne Softwareteile unabhängig vom Rest der Software verwerten, liegt keine Miturheberschaft vor. Der Programmierer hat hinsichtlich des Softwareteils das alleinige Urheberrecht und kann deshalb grundsätzlich nach Belieben mit ihm verfahren. Die Gesamtsoftware ist hingegen eine Werkverbindung im Sinne von § 9 UrhG. Die Entwickler sind dadurch Gesellschafter einer BGB-Gesellschaft im Sinne von §§ 705 ff. BGB geworden (vgl. Marly, Handbuch Softwarerecht, Rn. 925).
Grundsätzlich hat ein Urheber alle Freiheiten, mit seinem Werk zu verfahren, wie er will. Ihm steht die gesamte Rechtepalette der §§ 11 ff. UrhG zu. Bei Open Source Software besteht diese Freiheit faktisch nicht, zumindest nicht bei Open Source Lizenzen mit strengem Copyleft-Effekt. Hier regeln die Lizenzbedingungen der originalen Open Source Software, wie der Bearbeiter sein Urheberrecht ausüben darf. Er ist dahingehend also nicht vollständig frei. Verstößt er gegen die Nutzungsbedingungen, drohen ihm nachteilige Rechtsfolgen.
Ist man alleiniger Entwickler der Open Source Software, kann man auch allein Rechte aus der OSS durchsetzen. Alleinige Urheberschaft einer Einzelperson ist bei OSS aber selten.
Haben mehrere Personen an der Entwicklung der Software mitgewirkt, kommt es entscheidend darauf an, ob die verschiedenen Entwickler in Miturheberschaft ein gemeinsames Werk geschaffen (§ 8 UrhG) oder eigene Werke zu einer Werkverbindung (§ 9 UrhG) zusammengefügt haben.
Wenn mehrere Entwickler an einer Open Source Software gearbeitet haben, besteht in der Regel Miturheberschaft im Sinne von § 8 UrhG. Bei Miturheberschaft ist nach § 8 Abs. 2 Nr. 3 UrhG grundsätzlich jeder Miturheber berechtigt, gegen Verletzungen des gemeinsamen Urheberrechts vorzugehen. Allerdings kann eine Leistung nur an alle Miturheber verlangt werden.
Vor diesem Hintergrund kann ein einzelner Urheber nur Unterlassungsansprüche geltend machen. Auskunfts- und Schadensersatzansprüche können hingegen nur von allen Miturhebern gemeinsam geltend gemacht werden bzw. von einem einzelnen Miturheber, wenn er nachweisen kann, dass die restlichen Miturheber ihre Verwertungsrechte an ihn abgetreten haben. Hierzu ist die namentliche Nennung aller am Projekt Beteiligten erforderlich, was in der Praxis oftmals nahezu unmöglich ist (vgl. OLG Düsseldorf, Urteil vom 25.11.2008, Az. I-20 U 72/06).
– Was ist bei Werkverbindung zu beachten?
Falls keine Miturheberschaft vorliegt, sondern eine Werkverbindung gemäß § 9 UrhG, wird eine BGB-Gesellschaft unter den Entwicklern begründet. Sie können dann gemäß §§ 709, 714 BGB jegliche Ansprüche nur gemeinschaftlich geltend machen.
16. Was ist bei der Geltendmachung eines Unterlassungsanspruchs wegen Verstoßes gegen die Nutzungsbedingungen einer bearbeiteten Software zu beachten?
Für die Geltendmachung eines Unterlassungsanspruchs gelten die allgemeinen Ausführungen bei Verstößen gegen die Nutzungsbedingungen von Open Source Software sowie die allgemeinen Regeln für die Geltendmachung von Unterlassungsansprüchen. Ergänzend ist zu beachten:
Die Geltendmachung eines Unterlassungsanspruchs ist grundsätzlich bereits beim erstmaligen Verstoß gegen die Lizenzbedingungen möglich, weil dieser eine Wiederholungsgefahr indiziert (vgl. LG Halle, Urteil vom 27.07.2015, Az. 4 O 133/15).
Wer einen Unterlassungsanspruch geltend macht und sich dabei auf sein Bearbeiterurheberrecht stützt, muss hinreichend substantiiert darlegen, welche Teile der Software er umgearbeitet hat und dass gerade diese Teile durch die Handlung betroffen sind (LG Hamburg, Urteil vom 08.07.2016, AZ. 310 O 89/15).
18. Tabellarische Übersicht zu Rechtspflichten bei beliebten OSS Lizenzen
Darf der Quellcode (unverändert) vervielfältigt, bearbeitet und verbreitet werden? Ja Ja Ja Ja
Sieht die OSS-Lizenz einen viralen Effekt vor? Ja Eingeschränkt Nein Nein
Darf der Quellcode mit proprietärer Software verteilt werden (z.B. als Programmbibliothek)? Nein Ja Ja Ja
Müssen Modifikationen der Software offengelegt werden? Ja Ja Nein Nein
Ist ein Copyright-Vermerk erforderlich? Ja Ja Ja Ja
Müssen die OSS Lizenzbedingungen beigefügt bzw. auf sie verlinkt werden? Ja Ja Ja Ja
Nutzen Sie bei Rechtsfragen zu Open Source-Software unsere kostenlose und unverbindliche Ersteinschätzung.
Hinweis: Dieser Beitrag wurde unter Mitwirkung unseres juristischen Mitarbeiters Felix Wichert erstellt.
Zuletzt geändert am 5. Januar 2020 von Niklas Plutte in: IT-Recht · 0 Kommentare

References: § 5
 § 16
 EuGH 
 § 16
 § 16
 § 97
 § 435
 § 29
 § 32
 § 31
 § 31
 § 276
 § 307
 § 3
 § 4
 § 4
 § 9
 § 8
 § 8
 § 9