IT-Recht: Musterkapitel

129
5
Open Source Software *
Ein besonderes Phänomen in der IT-Branche stellt Open
Source Software dar. Denn obwohl es kostenfrei ist, sie zu
nutzen, spielt Open Source Software auf vielen Softwaremärkten eine erhebliche Rolle. Ihren Ursprung hatte diese
Entwicklung in den Vereinigten Staaten. Vielen Open Source
Bestimmungen liegt daher ein amerikanisch geprägtes Verständnis zugrunde – was insbesondere bei der Bewertung
nach deutschem Recht zu Schwierigkeiten führen kann.
Doch bevor hierauf näher einzugehen ist, erfolgt eine Darstellung der besonderen Merkmale, die kennzeichnend sind
für Open Source Software, insbesondere des Copyleft-Prinzips:
»Besondere Merkmale«, S. 129
Einige Prototypen unterschiedlicher Open-Source-Lizenzen
stellt vor:
»Beispiele für Open-Source-Lizenzen«, S. 132
Schließlich werden einige praktisch besonders relevante
Aspekte wie die Durchsetzung des Copyleft-Prinzips, die
vertragsrechtliche Einordnung von Open Source Software
sowie die Haftung näher beleuchtet:
»Rechtliche Besonderheiten«, S. 137
5.1
Besondere Merkmale **
Open-Source-Software wird in vielfältiger Form in immer
mehr Gebieten eingesetzt. Entsprechend diesen unterschiedlichen Erscheinungsformen gibt es eine Reihe unterschiedlicher Open-Source-Lizenzbedingungen. Einige von
ihnen – darunter die populäre General Public License (GPL) –
schreiben die Einhaltung des sog. Copyleft-Prinzips vor,
nämlich, dass weiterverbreitete Exemplare den gleichen
Open-Source-Bedingungen zu unterstellen sind. Das soll
auch für »abgeleitete« ( derived) Fassungen der Software
gelten – in praktischer Hinsicht ist aber mitunter unklar, in
welchen Fällen Software als abgeleitet anzusehen ist und in
welchen nicht.
130
5 Open Source Software *
Die Bedeutung von Open Source Software ist beständig gestiegen. Nicht nur private Anwender, sondern gerade auch
Unternehmen setzen auf vielen unterschiedlichen Gebieten
Open Source Software ein. Die Palette der verwendeten Open
Source Software reicht dabei von Betriebssystemen (z. B. Linux; BSD) über Anwendungen (z. B. OpenOffice.org) bis hin
zur eingebetteten Software (FreeRTos).
Merkmale
Dabei gibt es keine allgemein verbindliche Definition für
Open Source Software. Es gibt jedoch eine Reihe von Merkmalen, die üblicherweise Open Source zugeschrieben werden, hierzu zählen unter anderem:
Die Software kann unbeschränkt weiter verbreitet werden.
Der Quelltext der Software ist frei zugänglich. Er wird zusammen mit dem Programm geliefert oder es wird eine
frei zugängliche Fundstelle (z. B. Downloadadresse) angegeben.
Für die Nutzung der Software darf kein Entgelt verlangt
werden.
Es ist erlaubt, die Software zu verändern und weiter zu
entwickeln.
Das Copyleft-Prinzip
Viele – längst nicht alle! – Open-Source-Lizenzbestimmungen enthalten darüber hinaus eine besondere Klausel, mit
der sichergestellt werden soll, dass auch weiter entwickelte und veränderte Open Source Software wiederum als Open
Source weiter verbreitet wird. Das soll dadurch erreicht werden, dass derjenige, der eine von Open Source Software »abgeleitete« Software weiter verbreiten möchte, diese »abgeleitete« Software wiederum unter die gleichen Open-Source-Lizenzbestimmungen stellen muss. Dieses Prinzip wird
als »Copyleft« bezeichnet (in Anlehnung an Copyright, dem
englischen Begriff für Urheberrecht).
Beispiel
Programmierer A hat eine Tabellenkalkulation entwickelt
und sie unter den Bedingungen der GNU General Public License (GPL) veröffentlicht. Die GPL enthält eine CopyleftKlausel. Dem Programmierer B gefällt das Programm sehr
gut, jedoch sieht er Verbesserungsbedarf bei der Benut-
131
5.1 Besondere Merkmale **
zeroberfläche. Kurzerhand implementiert er eine komplett neue Benutzeroberfläche. Will er diese umgearbeitete Programmversion veröffentlichen und weiter verbreiten, dann muss er das unter den Bedingungen der GPL
tun. Er muss also auch der neuen Programmversion die
GPL zugrunde legen. Nicht möglich wäre es ihm etwa, die
neue Version ausschließlich in kompilierter Form zu verbreiten oder für die Programmnutzung ein Entgelt zu verlangen, denn die GPL verbietet dieses.
Je nachdem, wie viel Spielraum dem Weiterentwickelnden eingeräumt wird, kann man strenge und weniger strenge Copyleft-Klauseln unterscheiden (siehe hierzu auch »Beispiele für Open-Source-Lizenzen«, S. 132).
Ein ebenso prominentes wie praktisch wichtiges Beispiel
für eine (strenge) Copyleft-Klausel hält die GNU General
Public License (GPL) (GPL_V2 (http://www.gnu.org/licenses/
old-licenses/gpl-2.0.html)) in Abschnitt 2.b bereit:
»You must cause any work that you distribute or publish, that
in whole or in part contains or is derived from the Program
or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License.«
Zitat
Wer also ein Programm, für das die GPL gilt, ganz oder
teilweise veröffentlichen oder verbreiten möchte, der muss
auch diesem veröffentlichten oder verbreiteten Exemplar
zwingend die GPL zugrunde legen – muss also insbesondere
jedermann ein Nutzungsrecht einräumen und darf hierfür
kein Entgelt verlangen.
Nach dem oben zitierten Abschnitt 2.b der GPL gilt das Gleiche, wenn ein Programm veröffentlicht oder verbreitet werden soll, das von einem solchen unter der GPL stehenden
Programm abgeleitet (derived) ist. Damit ist bereits eine
der zentralen, mit Open Source Software verbundenen rechtlichen Fragen angesprochen: Wann ist ein Programm abgeleitet von einer anderen Software, die unter der GPL veröffentlicht wurde? Die große praktische Bedeutung dieser Frage liegt darin, dass jedermann, der eine im Sinne der GPL
abgeleitete Fassung veröffentlichen und verbreiten möchte,
sich zwingend an die Vorgaben der GPL halten muss, unter anderem also die abgeleitete Software unentgeltlich zur
derivative work
132
5 Open Source Software *
Nutzung überlassen muss. Ein unmittelbar kommerzieller
Weitervertrieb einer solcher abgeleiteten Software ist mithin
nicht möglich.
Indes gibt es keine feststehenden Kriterien dafür, ob
und in welchen Fällen ein Computerprogramm abgeleitet (»derived«) ist oder nicht. Auch der Free Software
Foundation als Herausgeberin der GPL ist es nicht möglich,
in dieser Hinsicht eine exakte Definition zu geben. Nicht zuletzt hierin ist einer der wesentlichen Unsicherheitsfaktoren zu sehen, die mit der Verwendung der GPL (und ähnlichen Open-Source-Bedingungen) verbunden ist, schließlich
ist das Vorliegen eines abgeleiteten Werkes oftmals entscheidend dafür, ob die GPL (zwingend) anzuwenden ist oder
nicht.
Immerhin kann man Anhaltspunkte und Beispiele nennen.
Ein abgeleitetes Werk (das also unter die GPL fällt) liegt vor,
wenn folgender Sachverhalt vorliegt:
Unter GPL stehender Code wird geändert, ergänzt, fortgeschrieben;
Code kann nur gemeinsam mit unter GPL stehendem Code ausgeführt werden;
Eine Software-Bibliothek wird statisch eingebunden (siehe aber zur LGPL »Beispiele für Open-Source-Lizenzen«,
S. 132).
Kein Fall einer abgeleiteten Software, sondern eine eigenständige Software liegt vor:
Eine Software-Bibliothek wird dynamisch eingebunden;
Eine Anwendung ruft eine Systemfunktion eines unter
GPL stehenden Kernels auf;
Nutzung eines Editors oder Compilers, die unter GPL stehen (GNU Emacs, GCC).
5.2 Beispiele für Open-SourceLizenzen **
Es gibt viele unterschiedliche Open-Source-Lizenzbedingungen. Derzeit noch am häufigsten wird die Version 2
der GNU General Public License (GPL) verwendet. Daneben
wird die gründlich überarbeitete Version 3 der GPL immer
wichtiger. Beide Versionen sehen ein strenges Copyleft-
5.2 Beispiele für Open-Source-Lizenzen **
Prinzip vor. Weniger streng sind demgegenüber etwa die
GNU Lesser General Public License (LGPL) oder die Mozilla
Public License Version 1.1, die Ausnahmen vom CopyleftPrinzip zulassen. Zudem ist es möglich, die gleiche Software sowohl unter eine eigene (»proprietäre«) Lizenz als
auch unter eine Open-Source-Lizenz zu stellen (dual licensing).
Open Source ist nicht gleich Open Source. Open-Source-Lizenzbedingungen können sich nicht nur in Details, sondern
auch in ihrer grundlegenden Konzeption erheblich voneinander unterscheiden.
Daher ist – insbesondere für Unternehmen – besondere Vorsicht geboten:
Derjenige, der Open Source Software nutzen möchte,
muss sich vorher genau informieren, welche Rechte
und – vor allem – Pflichten die Bedingungen vorsehen,
die für die jeweilige Software gelten.
Derjenige, der selbst Software als Open Source vertreiben möchte, muss sich vorab Gedanken darüber machen,
welche der auf dem Markt angebotenen Open-Source-Bedingungen seinen Zwecken am ehesten gerecht wird.
GNU General Public License Version 2
Die Open-Source-Lizenbestimmung, die wohl – noch – am
häufigsten zum Einsatz kommt, sind die GNU General Public
License Version 2 (GPL V2, siehe GPL_V2 (http://www.gnu.org/
licenses/old-licenses/gpl-2.0.html)). Sie sieht insbesondere
ein striktes Copyleft-Prinzip vor (vgl. dazu das Kapitel »Besondere Merkmale«, S. 129). Zu den wichtigsten Pflichten
des Verwenders der GPL V2 (des Lizenznehmers) gehören:
Der Quellcode des Programms muss mindestens zugänglich sein.
Der Lizenztext der GPL V2 muss mitgeliefert werden.
Es muss ein Haftungsausschluss (disclaimer) verwendet
werden. (Mehr hierzu im folgenden Kapitel »Rechtliche
Besonderheiten«, S. 137.)
Urheber- und Lizenzvermerke (»(C) 2010 Sodtalbers
GmbH, author: Axel Sodtalbers«) müssen unverändert
133
134
5 Open Source Software *
bleiben oder, wenn das Programm verändert wurde, angepasst werden.
Literatur
[Ifro05]
GNU General Public License Version 3
Derzeit aktuell ist die Version 3 der GPL (GPL V3 (http:
Diese neue Fassung, über
die intensiv diskutiert wurde, bevor sie endgültig veröffentlicht wurde, gilt seit Juni 2007 (die Version 2 gibt es seit
1991). Sie wird allerdings noch nicht so häufig eingesetzt
wie beispielsweise ihr Vorgänger. Einerseits haben prominente Open-Source-Apologeten wie Linus Torvalds erklärt,
die GPL V3 vorerst nicht einsetzen zu wollen. Als Begründungen werden das fehlende Bedürfnis für die neu aufgenommenen Regelungen, aber auch der erheblich vergrößerte Umfang des Lizenztextes genannt. Andererseits sind bekannte und große Projekte wie das Typo3 Content Management System (seit Version 5) auf die GPL V3 umgeschwenkt.
//www.gnu.org/licenses/gpl.html)).
Die GPL V3 ist zunächst Ergebnis einer umfassenden Überarbeitung der Lizenzbestimmungen, die unter anderem
deswegen notwendig geworden war, weil die Verbreitung der
GPL enorm gestiegen ist. Nicht zuletzt bedingt durch das Internet beschränkt sich der Einsatz der GPL schon lange nicht
mehr auf den anglo-amerikanischen Raum. Die Autoren der
GPL haben versucht, den sich hieraus ergebenden Anforderungen mit der neuen Version 3 gerecht zu werden. Darüber
hinaus enthält die neue Version unter anderem
eine umfangreiche Regelung im Hinblick auf Softwarepatente (Abschnitt 11 GPL V3),
eine Bestimmung zu technischen Schutzmaßnamen
(Digital Rights Management, Abschnitt 3 GPL V3) (»Protecting Users’ Legal Rights From Anti-Circumvention
Law.«) und
eine Klausel, die die gemeinsame Verwendung der GPL
mit anderen Open-Source-Lizenzbestimmungen erleichtert (Abschnitt 7 GPL V3).
Kein »Rosinenpicken«
Es ist nicht möglich, Teile der GPL V2 und der GPL V3 gleichzeitig für eine Software zu verwenden: Ein Computerprogramm kann im Ganzen stets nur entweder unter die GPL
V2 oder unter die GPL V3 gestellt werden.
135
5.2 Beispiele für Open-Source-Lizenzen **
[JaMe08]
Literatur
GNU Lesser General Public License
Vorwiegend für Softwarebibliotheken stellt die Free Software Foundation die GNU Lesser General Public License (LGPL) bereit. Grundlage der derzeit aktuellen Version 3 der LGPL ist die GPL V3, die LGPL modifiziert diese aber. Durch
diese Modifikationen ist es insbesondere möglich, eine unter der LGPL veröffentlichte Softwarebibliothek in einem
Anwendungsprogramm zu benutzen, ohne dass auch das
Anwendungsprogramm zwingend die LGPL oder GPL nutzen muss. Hierzu hält die LGPL verschiedene Möglichkeiten und Voraussetzungen bereit, zum Beispiel muss nach
Abschnitt 4 Buchstabe a bei der Weitergabe eines aus Bibliothek und Anwendung kombinierten Werkes (»Combined
Works«) der Name der Bibliothek an prominenter Stelle angezeigt werden:
»You may convey a Combined Work under terms of your
choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:«
Zitat
»a) Give prominent notice with each copy of the Combined
Work that the Library is used in it and that the Library and
its use are covered by this License.«
Die Copyleft-Bedingungen sind hier also nicht so zwingend
ausgestaltet etwa die bei der GPL (schwaches Copyleft).
Die Free Software Foundation favorisiert indes ein strenges
Copyleft, um dem Open-Source-Prinzip zur größtmöglichen
Umsetzung zu verhelfen; sie appelliert deshalb an Programmierer, eher die GPL als die LGPL zu verwenden [FSF09].
Mozilla Public License Version 1.1
Ein weiteres Beispiel für Open-Source-Lizenzbestimmungen
mit einer »weichen« Copyleft-Klausel ist die Mozilla Public
License Version 1.1 (MPL), die nach Offenlegung des Quellcodes des Netscapes Navigators entstanden ist. Auch diese
Lizenz erlaubt eine Kombination mit anderen Lizenzen.
Schwaches
Copyleft
136
5 Open Source Software *
Gleichzeitiger Einsatz mehrerer Lizenzen (dual
licensing)
Daneben ermöglicht die MPL ausdrücklich ein sog. dual
licensing:
Zitat
»13. Multiple-licensed code
Initial Developer may designate portions of the Covered
Code as »Multiple-Licensed«. »Multiple-Licensed« means that
the Initial Developer permits you to utilize portions of the
Covered Code under Your choice of the MPL or the alternative
licenses, if any, specified by the Initial Developer in the file
described in Exhibit A.«
Damit kann eine Software unter verschiedene Lizenzen gestellt werden.
Beispiele
Die C++-Klassenbibliothek QT von Qt Software wird sowohl unter einer eigenen als auch unter GPL zur Verfügung gestellt. Ein weiteres bekanntes Open-Source-Projekt, das gleichzeitig unter zwei Lizenzen zur Verfügung
gestellt wird, ist das Datenbanksystem MySQL.
Gleichzeitig kann beim dual licensing auch der Nutzer der
Software auswählen, welche Lizenzvariante er wählt. Wer die
Open Source Software nur benutzen will, kann bedenkenlos Software mit einer Lizenz verwenden, die ein strenges
Copyleft vorsieht.
Beispiel 1a
Die Datenbanksoftware MySQL wird auch unter der GPL
angeboten. Wer MySQL lediglich nutzen will, kann ohne
Weiteres diese Variante verwenden.
Wer jedoch die Software zusammen mit eigenen Softwareentwicklungen weiter vertreiben will, muss sich zuvor überlegen, welche Variante der angebotenen Lizenzen er hierfür einsetzen will. Wählt er die Lizenz mit einem strengen
Copyleft-Prinzip, muss er auch seine selbst entwickelte Software unter diese Lizenz stellen, mithin unter anderem deren
Quelltext zur Verfügung stellen.
Beispiel 1b
Der Hersteller bietet MySQL auch unter einer kommerziellen Lizenz an. Wer eine Verletzung der GPL nicht riskieren
will (weil er etwa eigene Software zusammen mit MySQL
5.3 Rechtliche Besonderheiten ***
nicht im Quelltext weitergeben möchte), kann diese Variante nehmen.
5.3
Rechtliche Besonderheiten ***
Open-Source-Software weist viele Besonderheiten auf, deren rechtliche Beurteilung sich mitunter als recht schwierig
darstellt. Das fängt schon bei der Frage an, wer überhaupt
Urheber der Open-Source-Software ist, wenn viele unterschiedliche Personen unabhängig voneinander an ihrer Erstellung mitgewirkt haben. Die Antwort auf diese Frage ist
etwa bedeutsam, wenn es darum geht, wer eine Verletzung
der Open-Source-Lizenzbedingungen geltend machen und
gerichtlich verfolgen kann. Das kann etwa in Betracht kommen bei Verstößen gegen das Copyleft-Prinzip, das auch
nach deutschem Recht wirksam ist, wenn man davon ausgeht, dass dem Benutzer die Nutzungsrechte nur unter der
(vertraglichen) Bedingung eingeräumt werden, dass dieser
sich an das Copyleft-Prinzip hält. Im Hinblick auf die vertragsrechtlichen Konsequenzen bei der Nutzung von OpenSource-Software muss danach unterschieden werden, ob
die Open Source Software direkt von den Erstellern oder
von einem Dritten (Distributor) bezogen wird. Was sowohl
die Gewährleistungspflichten als auch die Haftung anbelangt, sind die Ersteller der Open-Source-Software im Ergebnis nur eingeschränkt verantwortlich.
Open-Source-Software ist wie jedes Computerprogramm urheberrechtlich geschützt (§§ 69a ff. UrhG, Einzelheiten im
Kapitel »Schutz durch das Urheberrecht«, S. 6). Soweit es um
den Schutz dieses Urheberrechts innerhalb Deutschlands
geht, sind die deutschen urheberrechtlichen Vorschriften
anwendbar. Tatsächlich hat der deutsche Gesetzgeber (im
Jahr 2002) Regelungen eigens im Hinblick auf »freie« Lizenzbestimmungen wie die GPL oder die Lizenzen der Creative
Commons in das UrhG aufgenommen. War es etwa vor dieser
Neuregelung nicht so einfach möglich, Nutzungsrechte unentgeltlich einzuräumen, heißt es jetzt ausdrücklich in § 32
Absatz 3 Satz 3 UrhG, der sog. Linux-Klausel: »Der Urheber
kann aber unentgeltlich ein einfaches Nutzungsrecht für jedermann einräumen«.
137
138
5 Open Source Software *
Urheber von Open-Source-Software
Recht problematisch kann indes die Frage sein, wer überhaupt Urheber der Open-Source-Software ist. Das ist wichtig, wenn es darum geht, Ansprüche wegen einer Verletzung
des Urheberrechts durchsetzen.
Beispiel 1a
Die Sneaky Hardware AG (S) vertreibt Router, als Betriebssoftware (firmware) für diesen Router verwendet S das
Programm »RouterLib«, für das die GPL (Version 2) gilt.
Die S liefert weder den Quellcode mit noch weist sie auf
eine Quelle hin, von der der Quellcode bezogen werden
kann. S verstößt damit gegen die Lizenzbedingungen der
GPL.
Ansprüche wegen einer Verletzung des Urheberrechts stehen dem Urheber zu. Das ist normalerweise der Schöpfer
des Werkes (§ 7 UrhG). Hat jemand »im Alleingang« eine
Open-Source-Software programmiert, ist er Schöpfer und damit Urheber dieses Computerprogramms.
Beispiel 1b
Basar-Methode
Beispiel 1c
Wie oben, Programmierer P hat die Software vollständig
selbst programmiert und dann unter der GPL veröffentlicht. Als Urheber kann er die Ansprüche wegen der Verletzung der GPL (zum Beispiel auf Unterlassung oder Schadensersatz) gegenüber S geltend machen.
Doch stellt sich der Entwicklungsprozess bei Open-SourceSoftware praktisch wesentlich komplexer dar. Sinn und
Zweck ist ja gerade, dass jedermann an der Software Änderungen und Verbesserungen vornehmen kann, sodass also ein Werk vieler unabhängig voneinander tätiger Programmierer entsteht.
Wie oben: Die Software »RouterLib« wurde jedoch gemeinsam erstellt von den vier begabten Programmierern A, B,
C und D, die sich zusammengetan haben, um ein Betriebsprogramm für Router zu entwickeln, das »endlich mal
richtig funktioniert«.
Ebenso kann jemand einen Teil der Software als Ausgangspunkt für eine neue Fassung mit neuen Möglichkeiten benutzen.
5.3 Rechtliche Besonderheiten ***
Wie oben: Programmierer M verwendet grundlegenden
Programmcode von »RouterLib«, erweitert ihn jedoch wesentlich um neue Funktionen wie Firewall und Paketfilter.
139
Beispiel 1d
In den letztgenannten Fällen (Beispiele 1c und 1d) stellt sich
die Frage, wer jeweils als Urheber anzusehen (und damit zur
Rechtsdurchsetzung berechtigt) ist. Diskutiert werden verschiedene Lösungen ([?, Rn. 143 ff., 165 ff.]):
Zunächst kann man die beteiligten Programmierer als Miturheber ansehen. Nach § 8 Absatz 1 UrhG gilt:
Haben mehrere ein Werk gemeinsam geschaffen, ohne
dass sich ihre Anteile gesondert verwerten lassen, so sind
sie Miturheber des Werkes.
Definition
Bei der Miturheberschaft arbeiten also mehrere Personen zusammen, um gemeinsam ein Werk zu schaffen; wer dabei
welchen Teil des gemeinsamen Werkes geschaffen hat, lässt
sich im Nachhinein nicht eindeutig feststellen. Aus § 8 Absatz 2 Satz 3 UrhG ergibt sich, dass jeder Miturheber Ansprüche aus Verletzungen des gemeinsamen Urheberrechts
geltend machen kann.
Im Beispiel 1c könnten sowohl A als auch B als Miturheber
Unterlassungsansprüche geltend machen.
Beispiel 1e
Geht es jedoch um eine Leistungsklage – wie zum Beispiel
bei einer Schadensersatzforderung –, dann kann ein Miturheber nur Leistung an alle Miturheber verlangen (§ 8 Absatz
2 Satz 3 Halbsatz 2 UrhG).
Im Beispiel 1c kann A zwar die S AG gerichtlich wegen
Schadensersatzes verklagen, dabei muss er jedoch geltend machen, dass S Schadensersatz an alle Miturheber
zahlt. Dazu muss er alle Miturheber namentlich benennen (hier: A, B, C und D). Das setzt voraus, dass ihm auch
alle Mitprogrammierer bekannt sind. Bei einer überschaubaren Anzahl von Mitprogrammierern ist das möglich. Es
kann aber erhebliche Schwierigkeiten bereiten, alle Miturheber zu benennen, wenn sehr viele unterschiedliche
Personen an dem Open-Source-Projekt beteiligt waren.
Beispiel 1f
140
5 Open Source Software *
Eine andere Variante besteht darin, die weiter entwickelten
Programmversionen als eine Bearbeitung anzusehen (vgl.
§§ 3, 23, 69c Nr. 2 UrhG). Vereinfacht dargestellt liegt eine
Bearbeitung im urheberrechtlichen Sinne vor, wenn auf der
Grundlage eines bereits vorhandenes Werk ein neues Werk
geschaffen wird.
Beispiele
Aus einem Roman (dem Originalwerk) wird ein Drehbuch
(1. Bearbeitung) erstellt, aus dem Drehbuch ein Film (2.
Bearbeitung). Klassisches und in § 3 Satz 1 UrhG ausdrücklich genanntes Beispiel für eine Bearbeitung ist die
Übersetzung eines vorhandenen Sprachwerkes.
Anders als bei der Miturheberschaft liegt bei einer Bearbeitung kein bewusst gemeinschaftliches Schaffen vor.
Der Bearbeiter kann seine Bearbeitung eines bereits vorhandenen Werkes verbreiten, wenn der Urheber des Ausgangswerks dieses gestattet hat. Ihm steht ein eigenes Bearbeiterurheberrecht zu, Ansprüche wegen Verletzungen dieses
Bearbeiterurheberrechts kann der Bearbeiter selbst geltend
machen. Das betrifft sowohl Unterlassungs- als auch Schadensersatzansprüche.
Beispiel 1g
Im Beispiel 1d könnte die Weiterentwicklung des Programmes durch M eine Bearbeitung des Ausgangsprogramms
darstellen. Dessen Programmierer gestattet die Verbreitung auch der Bearbeitungen, eine solche Gestattung ist
dem Open-Source-Software Prinzip immanent. Hat die S
AG die Variante des M unter Verletzung der GPL verwendet, kann M hieraus folgende Ansprüche gegen die S AG
selbst geltend machen.
Nicht selten treten bei der Entwicklung von Open-SourceSoftware beide Formen gleichzeitig auf, also Miturheberschaft und Bearbeitung.
Schließlich werden auch Treuhandmodelle praktiziert, innerhalb derer die beteiligten Programmierer vorab alle Rechte, die zur Durchsetzung der jeweiligen Open-Source-Lizenz
notwendig sind, an einen Treuhänder (z. B. eine gemeinnützige Organisation zur Unterstützung des Open-Source-Prinzips) ab.
141
5.3 Rechtliche Besonderheiten ***
Das Fiduciary Licence Agreement (FLA) der FSF Europe, FSFEurope_FLA (http://www.fsfe.org/projects/ftf/fla.
de.html)
Beispiel
Durchsetzung des Copyleft-Prinzips
Ein maßgebliches Prinzip vieler Open-Source-Software ist
das Copyleft-Prinzip (siehe das Kapitel »Besondere Merkmale«, S. 129). Dabei ist nicht endgültig geklärt, wie dem
Copyleft-Prinzip in rechtlicher Hinsicht zur Wirksamkeit verholfen werden kann. Die meisten Open-Source-Bedingungen, die eine strikte Copyleft-Klausel enthalten, sehen vor,
dass das Nutzungsrecht automatisch entfällt, wenn die Bedingungen nicht eingehalten werden. Beispielhaft ist hier
wiederum die GPL, Version 2, Abschnitt 4 (GPL_V2 (http:
//www.gnu.org/licenses/old-licenses/gpl-2.0.html), Hervorhebung nur hier):
»You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the
Program is void, and will automatically terminate your
rights under this License. However, parties who have received copies, or rights, from you under this License will not
have their licenses terminated so long as such parties remain
in full compliance..«
Dabei ist zu bedenken, dass viele dieser Open-Source-Bedingungen – und insbesondere die GPL – ihren Ursprung
im anglo-amerikanischen Rechtskreis haben. Dort aber
herrscht ein Urheberrechtsverständnis, das zum Teil erheblich vom Urheberrecht in Deutschland und Europa abweicht.
Dieses abweichende Begriffsverständnis ist bei der Auslegung von Open-Source-Bestimmungen zu berücksichtigen.
Aufgrund dieses unterschiedlichen Verständnisses gelingt
es nicht immer, Open-Source-Lizenzen mit den hiesigen Urheberrechtsgesetzen in Einklang zu bringen. So lässt sich
der skizzierte Rückfall der Nutzungsrechte im Falle einer Verletzung der Open-Source-Bedingungen mithilfe des
deutschen Urheberrechts, den Vorschriften des Urheberrechtsgesetzes, nach überwiegender Ansicht nicht erreichen. Man kommt aber zum gleichen Ergebnis mithilfe ei-
Zitat
142
5 Open Source Software *
ner vertragsrechtlichen Konstruktion. Danach werden dem
Lizenznehmer die Nutzungsrechte unter der auflösenden
Bedingung eingeräumt, dass der Lizenznehmer sich an die
Open-Source-Bestimmungen (z. B. die GPL) hält. Hält der Lizenznehmer das nicht ein – stellt er zum Beispiel den Quellcode nicht zur Verfügung –, entfällt sein Nutzungsrecht. Er
ist dann nicht mehr zur Nutzung der Software befugt.
Eine solche unbefugte Nutzung einer Open-Source-Software
kann durchaus auch auf gerichtlichem Wege verfolgt werden. Es gibt – mindestens – drei veröffentlichte Urteile
(wenn auch von unteren Instanzen), in denen wegen Verletzung der GPL Unterlassungs- und Schadensersatzansprüche durchgesetzt wurden. So hat etwa das Landgericht
München I im Jahr 2004 eines der weltweit ersten Urteile
zur Wirksamkeit der GPL erlassen (siehe LG_MünchenI_GPL
(http://www.beckmannundnorda.de/urteil_gpl.html)), 2006 gab
es ein weiteres Urteil hierzu vom Landgericht Frankfurt (siehe LG_Frankfurt_GPL (http://www.jurpc.de/rechtspr/20060126.
htm)).
Vertragsrecht
Kaum einfacher als die urheberrechtliche Situation ist die
Lage bei Open-Source-Software, wenn es um die vertragsrechtlichen Aspekte geht. Hier gilt es zunächst, genau zu
darauf zu achten, von wem die Software erworben wird,
mit wem also der Softwareüberlassungsvertrag geschlossen
wird. Der Abnehmer kann die Software erwerben
von einem Dritten, einem Distributor oder
von den Erstellern der Open-Source-Software selbst.
Erwerb von den Erstellern
Praktisch eher die Ausnahme ist ein Erwerb unmittelbar von
dem Hersteller der Open-Source-Software. Das ist etwa der
Fall, wenn die Programmierer ihre Open-Source-Software direkt auf ihrer Website zum Download anbieten.
Beispiel
Die Programmierer der Softwaresuite FluffyOffice.org bieten ihre Software auf www.fluffyoffice.org zum Download
an.
5.3 Rechtliche Besonderheiten ***
143
Hier kommt ein Vertrag über die Überlassung der Software direkt zwischen dem Abnehmer und dem Hersteller
der Open-Source-Software zustande. Dieser Vertrag ist als
Schenkungsvertrag zu qualifizieren ([Sodt06, Rn. 619],
[JaMe06, Rn. 205 ff.]).
Schenkung
Konsequenz hieraus ist insbesondere, dass Haftung des
Schenkers – des Herstellers der Open-Source-Software – eingeschränkt ist.
Haftung
Der Schenker hat nur Vorsatz und grobe Fahrlässigkeit
zu vertreten (§ 521 BGB). (Siehe zu den einzelnen Graden
des Verschuldens »Die Wirksamkeit von AGB«, S. 50.)
Diese Haftungserleichterung gilt auch im Deliktsrecht.
Werden also Dritte, die mit dem Schenker (Hersteller der
Open-Source-Software) nicht vertraglich verbunden sind,
geschädigt, kann sich der Hersteller der Open-SourceSoftware darauf berufen, dass er nur für Vorsatz und grobe Fahrlässigkeit haftet.
Für Sach- und Rechtsmängel haftet der Schenker nur,
wenn er solche Fehler arglistig verschwiegen hat (§ 523
Absatz 1, 524 Absatz 1 BGB). Ein arglistiges Verschweigen von Fehler wird bei Open-Source-Software kaum jemals in Betracht kommen.
Siehe hierzu auch das Kapitel »Sonderfall: Software ohne Gegenleistung«, S. 103.
Darüber hinaus kann in dieser Konstellation der Hersteller der Open-Source-Software auch die Lizenzbedingungen
unproblematisch in den Vertrag einbeziehen. Open-Source-Bedingungen sind Allgemeine Geschäftsbedingungen
(AGB). Denn sie sind für eine Vielzahl von Verträgen vorformulierte Vertragsbedingungen, die eine Vertragspartei (der
Hersteller der Open-Source-Software als Verwender) der anderen Vertragspartei (dem Abnehmer) bei Abschluss eines
Vertrags stellt.
Siehe hierzu und zu dem Folgenden auch das Kapitel »Allgemeine Geschäftsbedingungen«, S. 44.
Damit AGB wirksam Vertragsbestandteil werden, muss der
Verwender ausdrücklich auf sie hinweisen und dem anderen
Vertragspartner die Möglichkeit verschaffen, in zumutbarer
144
5 Open Source Software *
Weise Kenntnis von ihrem Inhalt zu nehmen. Diese Anforderungen einzuhalten ist etwa im Internet leicht möglich.
Beispiel
Vor dem Download erscheint ein Hinweis: »Die Software
XY unterliegt der GNU General Public License Version
3, die hier eingesehen und ausgedruckt werden kann.«
(Die unterstrichenen Textteile wären unmittelbare Verweise auf den Lizenztext.)
Sind die Open-Source-Bedingungen auf diese Weise wirksam
in den Vertrag einbezogen, ist der Abnehmer verpflichtet,
sie einzuhalten.
Bietet der Hersteller seine Open-Source-Software im Internet an und handelt er dabei als Unternehmer, dann muss er
daran denken, die Pflichten im Fernabsatz und im E-Commerce zu beachten.
Beispiel:
Pflichten im
Fernabsatz
Widerrufsrecht des Verbrauchers. Vorvertragliche und
nachvertragliche Informationspflichten. Dabei gehört es
zu den nachvertraglichen Informationspflichten, dem
Verbraucher die AGB – die Open-Source-Lizenzbestimmungen – in Textform zur Verfügung zu stellen. Einzelheiten finden Sie im Kapitel »Informationspflichten bei
Fernabsatzverträgen«, S. 167.
Beispiel:
Pflichten im
E-Commerce
Möglichkeit, Eingabefehler zu erkennen und zu berichtigen, Bereithalten der AGB, Informationspflichten. (Bestätigungs-E-Mail ist nicht notwendig, wenn die OpenSource-Software unmittelbar zum Download zur Verfügung gestellt wird. Einzelheiten finden Sie im Kapitel »Fernabsatzverträge im elektronischen Geschäftsverkehr«, S. 151.
Diese Pflichten sind wohlgemerkt nur einschlägig, wenn der
Hersteller der Open-Source-Software als Unternehmer, mithin in Ausübung seiner gewerblichen oder selbstständigen
beruflichen Tätigkeit handelt (§ 14 Absatz 1 BGB). Zwar ist
zu einem gewerblichen Handeln keine Gewinnerzielungsabsicht notwendig, wohl aber das Angebot entgeltlicher Leistungen. Das dürfte bei Anbietern von Open-Source-Software
eher die Ausnahme sein.
5.3 Rechtliche Besonderheiten ***
Der Hersteller der Open-Source-Software bietet zusätzlich
zu seiner Software gegen Entgelt Dienstleistungen wie etwa Beratung oder Support an.
145
Beispiel
Die Folgen von Verstößen gegen diese Pflichten sind für
den Hersteller der Open-Source-Software jedoch weitaus
weniger gravierend als für andere Anbieter im Fernabsatz
und/oder E-Commerce. Belehrt er nicht richtig über das
Widerrufsrecht, mag dieses zwar im Extremfall nicht erlöschen, das berührt den Open-Source-Ersteller jedoch nicht,
weil auch eine späte Rückabwicklung (so es denn ein Verbraucher überhaupt jemals wünscht) ihn kaum vor Probleme
stellt. Bedeutsam könnten diese Pflichten höchstens im Hinblick auf eine wettbewerbsrechtliche Abmahnung werden (vgl. »Wettbewerbsrecht«, S. 195).
Erwerb vom Distributor
Sie haben gesehen: Schließt der Abnehmer unmittelbar mit
dem Hersteller der Open-Source-Software einen Vertrag,
dann können die Open-Source-Lizenzbestimmungen ohne
Weiteres einbezogen und dem Abnehmer Pflichten (zum Beispiel zur Beachtung des Copyleft-Prinzips) auferlegt werden.
Wie aber ist die Lage, wenn der Abnehmer die Open-SourceSoftware von einem Dritten (im Folgenden: Distributor) erwirbt?
Angebot einer umfangreichen Sammlung von OpenSource-Software zum direkten Download im Rahmen eines Downloadportals im Internet. Zusammenstellung verschiedener Open-Source-Software zu einem umfangreichen Gesamtpaket (»Linux-Distribution«), wahlweise auf
einem Datenträger oder als Download.
Der Abnehmer schließt in dieser Konstellation jedenfalls
einen Vertrag mit dem Distributor ab. Es fragt sich, wie der
Abnehmer auch gegenüber dem Hersteller oder den Herstellern der Open-Source-Software (dem Urheber oder den Urhebern) verpflichtet werden kann, die Open-Source-Bedingungen einzuhalten. Die Frage ist ohne Bedeutung, solange es
nur um die bloße Nutzung der Software geht, denn dieses
gestatten die meisten Open-Source-Lizenzen ohnehin. Wich-
Beispiele
146
5 Open Source Software *
tig wird sie, wenn es um die weiter gehenden Rechte und
Pflichten wie etwa die Weiterentwicklung und -verbreitung
sowie die Einhaltung des Copyleft-Prinzips geht.
Hierzu wird vertreten, die Open-Source-Lizenzbestimmungen der Urheber, dessen Texte sich zumeist direkt an die
Abnehmer wendeten, enthielten ein Angebot an die Benutzer zum Abschluss eines Lizenzvertrages mit den Herstellern der Open-Source-Software als Lizenzgeber ([JaMe06,
Rn. 176]). Hierin läge auch der Grund, warum der OpenSource-Software stets auch der Lizenztext (mit dem Vertragsangebot der Hersteller der Open-Source-Software) mitgegeben werden müsse (vgl. GPL, Version 2, Abschnitt
1, GPL_V2 (http://www.gnu.org/licenses/old-licenses/gpl-2.0.
html)), schließlich müsse der Abnehmer das Angebot der
Hersteller der Open-Source-Software auf Abschluss des
(Lizenz-)Vertrages mit ihnen erhalten. Derjenige, der die
Open-Source-Software weiter entwickelt und dann weiter
gibt, nähme dieses Vertragsangebot an – und sei danach gegenüber den Herstellern der Open-Source-Software vertraglich verpflichtet, sich an deren Bedingungen zu halten. Demgegenüber sei es ein widersprüchliches Verhalten, die Software im Bewusstsein, dass es sich um Open-Source-Software
handelt, weiter zu entwickeln und weiter zu geben, ohne
sich an die Lizenzbedingungen zu halten.
Gewährleistung und Haftung
Schließlich ist noch einmal auf die Themen Gewährleistung
und Haftung zurück zu kommen. Die meisten Open-SourceLizenzbestimmungen sehen einen Ausschluss von Gewährleistungsansprüchen und der Haftung vor.
Beispiel
Die GPL, Version 2, in den Abschnitten 11 und 12, in der
Version 3 in den Abschnitten 15 und 16.
Nach deutschem Recht sind diese Ausschlüsse jedoch unwirksam. Sie benachteiligen den Vertragspartner unangemessen, schon weil sie nicht zu vereinbaren sind mit den
wesentlichen Grundgedanken der gesetzlichen Regelung,
von denen sie abweichen:
5.3 Rechtliche Besonderheiten ***
147
Der Verwender von AGB kann Gewährleistungsrechte gegenüber Verbrauchern gar nicht, gegenüber anderen nur
in geringem Maße einschränken – nicht aber vollständig.
Ebenso widerspricht ein vollständiger Haftungsausschluss der gesetzlichen Regelung, dass jedermann für
schuldhaft verursachte Schäden einstehen muss.
Ausführlich siehe hierzu das Kapitel »Die Wirksamkeit von
AGB«, S. 50.
Mitunter sehen die Bedingungen auch eine salvatorische
Klausel vor, derzufolge die Gewährleistung nur soweit eingeschränkt sein soll, wie es gesetzlich zulässig ist.
Die GPL, Version 2, bestimmt im Abschnitt 11: »Because
the program is licensed free of charge, there is no warranty for the program, to the extent permitted by applicable law.« (Hervorhebung nur hier.)
Beispiel
Auch solche salvatorischen Klauseln sind nach deutschem
Recht unwirksam, denn es ist für den Vertragspartner nicht
ersichtlich, in welchem Umfang denn nun die Einschränkung
der Haftung gelten soll. Über diesen Umfang (also darüber,
wie das inländische Recht den Ausschluss beurteilt) erst Informationen einzuholen, ist dem Vertragspartner nicht zuzumuten.
Der Befund, dass solche vertraglichen Ausschlüsse für Gewährleistung in Open-Source-Lizenzbestimmungen unwirksam sind, ist allerdings für die Hersteller von Open-SourceSoftware weit weniger gravierend, als man auf den ersten
Blick denken mag. Denn nach den einschlägigen gesetzlichen
Vorschriften ist – wie gesehen – sowohl die Gewährleistung
als auch die Haftung eingeschränkt:
Für Sach- und Rechtsmängel haften die Hersteller von
Open-Source-Software nur bei Arglist (§§ 523, 524 BGB;
im Übrigen haben sie nur Vorsatz und grobe Fahrlässigkeit zu vertreten (§ 521 BGB).
[Spin03]; [Ifro05]; [JaMe06]; [JaMe08]
Literatur