Open Source Software Recht: Große FAQ mit vielen Praxistipps

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:

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“.

nach oben

2. Was sind die wichtigsten Unterschiede bei Open Source Lizenzen?

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.

nach oben

3. Welche sind die bekanntesten und häufigsten OSS-Lizenzen?

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. Die MIT-Lizenzbedingungen erlauben eine uneingeschränkte Benutzung, Bearbeitung und Unterlizenzierung unter beliebig anderer Lizenz (OLG Karlsruhe, Urteil vom 27.01.2021, Az. 6 U 60/20). 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.

nach oben

4. Wie grenzt man OSS zu anderen „freien“ Lizenzarten ab?

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.

nach oben

5. Was bedeutet der Begriff „proprietäre Software“?

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.

nach oben

6. Kann man OSS in Software integrieren, ohne dass diese zu OSS wird?

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 Bearbeitung oder Vervielfältigung nur unter der Bedingung erfolgen, 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.

nach oben

7. Was ist der virale Effekt bei Lizenzen mit strengem Copyleft-Effekt?

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.

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).

nach oben

8. Wann greift der virale Effekt ausnahmsweise nicht?

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.

nach oben

9. Kann man den Copyleft-Effekt umgehen?

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.):

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.

nach oben

10. Kann man den Copyleft-Effekt durch Software as a Service (SaaS) umgehen?

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.

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.

nach oben

11. Welche Rechtsfolgen drohen bei Verstoß gegen die Nutzungsbedingungen?

– Welche Ansprüche hat der Rechteinhaber?

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).

nach oben

– Welche Ansprüche haben Anwender?

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.

nach oben

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.

nach oben

13. Können englische Lizenzbedingungen in Deutschland verwendet werden?

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.

nach oben

14. Welche Rechte stehen einem Weiterentwickler von OSS zu?

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).

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.

nach oben

15. Kann man allein Rechte aus einer OSS durchsetzen?

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.

– Was ist bei Miturheberschaft zu beachten?

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.

nach oben

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).

nach oben

18. Tabellarische Übersicht zu Rechtspflichten bei beliebten OSS Lizenzen

nach oben

Hinweis: Dieser Beitrag wurde unter Mitwirkung unseres juristischen Mitarbeiters Felix Wichert erstellt.