5 Open Source Software *

Transkript

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

2 130 5 Open Source Software * Merkmale 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). 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 Copyleft- Klausel. Dem Programmierer B gefällt das Programm sehr gut, jedoch sieht er Verbesserungsbedarf bei der Benut-

3 5.1 Besondere Merkmale ** 131 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 ( 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.«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 Zitat derivative work

4 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-Source- Lizenzen ** 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 5.2 Beispiele für Open-Source-Lizenzen ** 133 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 Copyleft- Prinzip 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 ( 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

6 134 5 Open Source Software * Literatur bleiben oder, wenn das Programm verändert wurde, angepasst werden. [Ifro05] GNU General Public License Version 3 Kein»Rosinenpicken«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. 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). 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.

7 5.2 Beispiele für Open-Source-Lizenzen ** 135 [JaMe08] GNU Lesser General Public License Vorwiegend für Softwarebibliotheken stellt die Free Software Foundation die GNU Lesser General Public License (LG- PL) bereit. Grundlage der derzeit aktuellen Version 3 der LG- PL 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: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]. Literatur Zitat Schwaches Copyleft 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 QuellcodesdesNetscapesNavigatorsentstandenist.Auchdiese Lizenz erlaubt eine Kombination mit anderen Lizenzen.

8 136 5 Open Source Software * Zitat Beispiele Gleichzeitiger Einsatz mehrerer Lizenzen (dual licensing) Daneben ermöglicht die MPL ausdrücklich ein sog. dual licensing:»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. 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

9 5.3 Rechtliche Besonderheiten *** 137 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 Open- Source-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«.

10 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-Source- Software 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.

11 5.3 Rechtliche Besonderheiten *** 139 Wie oben: Programmierer M verwendet grundlegenden Programmcode von»routerlib«, erweitert ihn jedoch wesentlich um neue Funktionen wie Firewall und Paketfilter. 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 2Satz3Halbsatz2UrhG). 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

12 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-Source- Software 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.

13 5.3 Rechtliche Besonderheiten *** 141 Das Fiduciary Licence Agreement (FLA) der FSF Euro- Beispiel pe, FSFEurope_FLA ( de.html) 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, dieeinestriktecopyleft-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: // 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

14 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 ( gab es ein weiteres Urteil hierzu vom Landgericht Frankfurt (siehe LG_Frankfurt_GPL ( 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 zum Download an.

15 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.]). Konsequenz hieraus ist insbesondere, dass Haftung des Schenkers des Herstellers der Open-Source-Software eingeschränkt ist. 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-Source- Software 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 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 Schenkung Haftung

16 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 Beispiel: Pflichten im E-Commerce Möglichkeit, Eingabefehler zu erkennen und zu berichtigen, Bereithalten der AGB, Informationspflichten. (Bestätigungs- ist nicht notwendig, wenn die Open- Source-Software unmittelbar zum Download zur Verfügung gestellt wird. Einzelheiten finden Sie im Kapitel»Fernabsatzverträge im elektronischen Geschäftsverkehr«, S 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.

17 5.3 Rechtliche Besonderheiten *** 145 Der Hersteller der Open-Source-Software bietet zusätzlich zu seiner Software gegen Entgelt Dienstleistungen wie etwa Beratung oder Support an. 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-Source- Software von einem Dritten (im Folgenden: Distributor) erwirbt? Angebot einer umfangreichen Sammlung von Open- Beispiele Source-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-

18 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 Open- Source-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 ( 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-Source- Lizenzbestimmungen 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:

19 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.) 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-Source- Software 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] Beispiel Literatur