»Copyleft« im deutschen Urheberrecht: Implikationen von Open Source Software (OSS) im Urhebergesetz [1 ed.] 9783428523252, 9783428123254

Citation preview

Schriften zum Bürgerlichen Recht Band 367

„Copyleft“ im deutschen Urheberrecht Implikationen von Open Source Software (OSS) im Urhebergesetz Von Christian Teupen

Duncker & Humblot · Berlin

CHRISTIAN TEUPEN

„Copyleft“ im deutschen Urheberrecht

Schriften zum Bürgerlichen Recht Band 367

„Copyleft“ im deutschen Urheberrecht Implikationen von Open Source Software (OSS) im Urhebergesetz

Von Christian Teupen

asdfghjk Duncker & Humblot · Berlin

Der Fachbereich Rechtswissenschaft der FernUniversität – GH Hagen hat diese Arbeit im Jahre 2006 als Dissertation angenommen.

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Alle Rechte vorbehalten # 2007 Duncker & Humblot GmbH, Berlin Fremddatenübernahme: L101 Mediengestaltung, Berlin Druck: Berliner Buchdruckerei Union GmbH, Berlin Printed in Germany ISSN 0720-7387 ISBN 978-3-428-12325-4 Gedruckt auf alterungsbeständigem (säurefreiem) Papier ∞ entsprechend ISO 9706 *

Internet: http://www.duncker-humblot.de

Meinen Eltern Bernd und Elisabeth Teupen, geb. Steven zugeeignet

„Wer keinen Geist hat, glaubt nicht an Geister und somit auch nicht an geistiges Eigentum . . .“ Goethe im Gespräch mit Verleger Cotta und Kanzler v. Müller am 15.05.1823 (A 23 S. 260, in: Johann Wolfgang Goethe, Gedenkausgabe der Werke, Briefe und Gespräche in 24 Bänden, mit zusätzlichem Registerband, hrsg. von Ernst Beutler, Zürich und Stuttgart 1948–1971)

„Das Juristische trieb ich mit soviel Fleiß als nötig war, um die Promotion mit einigen Ehren zu absolvieren.“ (Johann Wolfgang Goethe, Dichtung und Wahrheit, 11. Buch [A 10 S. 494]).

Vorwort Der Begriff der „Informationsgesellschaft“ ist in aller Munde. Unabhängig von der berechtigten und spannenden Frage, ob es eine solche überhaupt gibt, spielt der Open Source-Gedanke in diesem Zusammenhang eine bedeutende Rolle. Zukunft und Entwicklung hängen von dem Zugang zu Wissen ab. Gleichzeitig ist der Schutz von Ideen, sei es durch das Urheberrecht, Patentrecht oder Gebrauchs- und Geschmacksmusterrecht, gerade in Ländern von wachsender Bedeutung, in denen immer weniger Güter produziert werden, aber zunehmend Ideen für neue Produkte oder für ihre Verbesserung entstehen. Die Anwendung des Prinzips „Copyleft“ im Bereich von Software zeigt, dass der freie Zugang zu Informationen eine Art Katalysator für die Entwicklung darstellen kann. In den vergangenen Jahren sind eine Vielzahl hochwertiger Computerprogramme entstanden, die als Open Source Software lizenziert sind. Anwender sind heute in der Lage, ihren PC mit frei zugänglicher und meist kostenloser Open Source Software auszustatten, ohne auf bestimmte Anwendungen verzichten zu müssen. Nicht nur Privatanwender, sondern auch Unternehmen sowie die öffentliche Hand setzten bereits Open Source Software ein. Aber gerade auch mit Blick auf die Entwicklungsländer kann Open Source ein entscheidender Zukunftsfaktor sein. Neue Lizenzierungs- und Entwicklungsmodelle führen aber immer auch zur Frage ihrer rechtlichen Bewertung und Einordnung in das jeweilige Rechtssystem. Die vorliegende Arbeit zeigt Ansätze und Lösungswege auf, wie Open Source Software vor dem Hintergrund des deutschen Urheberrechtssystems zu bewerten ist. Sie soll als Beitrag zur Vertiefung und Ergänzung der aktuellen Diskussionen in diesem Bereich verstanden werden. Die erfolgreiche Promotion und die vorliegende Arbeit als ihr Ergebnis ist ohne ständige Unterstützung verbunden mit Zuspruch und Anregungen des persönlichen Umfelds kaum denkbar. Zudem sind das Studium der Rechtswissenschaft sowie eine daran anschließende Promotion mit Kosten

10

Vorwort

verbunden. Ohne die großzügige Unterstützung meiner Mutter in all den Jahren wäre diese Arbeit nicht möglich gewesen. Herzlichen Dank dafür! Besonders möchte ich mich an dieser Stelle auch bei Frau Prof. Dr. Barbara Völzmann-Stickelbrock für das mir entgegengebrachte Vertrauen und die vorbildliche Betreuung dieser Arbeit bedanken. Ferner bedanke ich mich bei den Menschen, die mich während des Studiums und der Promotion begleitet und besonders unterstützt haben: Leo und Christel van der Giet, Prof. Dr. med. Markus van der Giet, Ursula und Jean-Pierre Champeau. Für die Unterstützung bei der Formatierung der Arbeit bedanke ich mich bei Herrn Johannes Schwall. Langenhorst im Oktober 2006

Christian Teupen

Inhaltsübersicht § 1 Grundlagen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Gang der Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Inhaltliche Beschränkung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV. Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V. Definition der Kernbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 21 28 30 31 31

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software . . I. Historische Entwicklung von Open Source Software . . . . . . . . . . . . . . . II. Ökonomische Bedeutung von Open Source Software. . . . . . . . . . . . . . .

36 36 43

§ 3 Urheberrecht und „Copyleft“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Inhalt und Bedeutung des Urheberrechts im Informationszeitalter . . . II. Der Open Source-Gedanke im Spannungsfeld von Urheberrechtsschutz und Informationsfreiheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 53 55

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland . . . . . . 65 I. Rechtsschutz von Computerprogrammen . . . . . . . . . . . . . . . . . . . . . . . . . . 65 II. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 III. Die urheberrechtliche Lizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 § 5 Open Source Software im deutschen Urheberrecht . . . . . . . . . . . . . . . . . . I. Open Source Software als Schutzgegenstand des UrhG. . . . . . . . . . . . . II. Open Source Software und Anwendbarkeit des UrhG/Internationales Urheberrecht und kollisionsrechtliche Einordnung von Freier Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Urheberschaft bei Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . .

118 118

§ 6 Open Source-Lizenzen und Verwertungsrechte . . . . . . . . . . . . . . . . . . . . . . I. Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Open Source Softwarelizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Verwertungsrechte in Open Source Softwarelizenzverträgen . . . . . . . .

166 166 167 168

§ 7 Rechtliche Dogmatik des Copyleft-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . I. Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Lösungsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

193 193 193 211

119 151

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz . . . . . . . . . . . . 213 I. Allgemeines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 II. Erschöpfungsgrundsatz im Rahmen der Verbreitung von Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

12

Inhaltsübersicht

§ 9 Vertragliche Einordnung der Softwareüberlassung bei Open Source Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Nicht durch Distributoren vertriebene Software. . . . . . . . . . . . . . . . . . . . II. Vertragliche Einordnung von Softwareüberlassung bei Vertrieb von Open Source Software durch Distributoren . . . . . . . . . . . . . . . . . . . . . . . . III. Die Ankunft des Open Source-Gedankens im UrhG. . . . . . . . . . . . . . . .

225 225 256 257

§ 10 Fazit und Ausblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Sachwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Inhaltsverzeichnis § 1 Grundlagen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Gang der Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Inhaltliche Beschränkung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV. Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V. Definition der Kernbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 21 28 30 31 31

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software . . I. Historische Entwicklung von Open Source Software . . . . . . . . . . . . . . . II. Ökonomische Bedeutung von Open Source Software. . . . . . . . . . . . . . . 1. Open Source Software in der Wirtschaft. . . . . . . . . . . . . . . . . . . . . . . a) Vorteile von Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . b) Nachteile von Open Source Software . . . . . . . . . . . . . . . . . . . . . . c) Betätigungsfelder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Open Source Software in der Öffentlichen Verwaltung. . . . . . . . . .

36 36 43 45 45 46 47 50

§ 3 Urheberrecht und „Copyleft“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Inhalt und Bedeutung des Urheberrechts im Informationszeitalter . . . II. Der Open Source-Gedanke im Spannungsfeld von Urheberrechtsschutz und Informationsfreiheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Das Copyleft-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Die Free Software-Definition/Open Source-Definition . . . . . . . . . . a) Free Software-Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Open Source-Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Motive für das Copyleft-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a) Altruistische Ideologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Open Source als Entwicklungsmethode. . . . . . . . . . . . . . . . . . . . . c) Gebrauch fremder Programmierergebnisse für eigene Softwareanwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d) Spaßfaktor und Reputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e) Schaffung eines unabhängigen Softwaresektors . . . . . . . . . . . . . f) Lerneffekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . g) Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 53

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland . . . . . . I. Rechtsschutz von Computerprogrammen . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Rechtslage in Deutschland vor dem Zweiten Änderungsgesetz zum Urheberrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65 65

55 56 57 58 58 60 60 62 62 63 63 64 64

66

14

Inhaltsverzeichnis 2. Europäische Entwicklung des Rechtsschutzes von Computerprogrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Rechtsentwicklung in Deutschland aufgrund der Richtlinie 91/250/EWG des Rates vom 14. Mai 1991 über den Rechtsschutz von Computerprogrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Überblick über den Rechtsschutz von Computerprogrammen in Deutschland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a) Schutz durch relative Rechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aa) Vertragsrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Wettbewerbsrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cc) Markenrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dd) Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Schutz durch absolute Rechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aa) Patentrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (1) Schutzvoraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . (2) Aktuelle Entwicklungen im Patentrecht . . . . . . . . . . . . (3) Open Source Software und Patentrecht. . . . . . . . . . . . . bb) Urheberrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (1) Computerprogramm als „Sprachwerk“ . . . . . . . . . . . . . (2) Schutzgegenstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (a) Entwurfsmaterial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (b) Schutz als Ausdrucksform. . . . . . . . . . . . . . . . . . . . . (c) Ideen und Grundsätze . . . . . . . . . . . . . . . . . . . . . . . . (3) Schutzvoraussetzungen gem. § 69 a III UrhG . . . . . . . (4) Urheberschaft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (a) Alleinurheberschaft. . . . . . . . . . . . . . . . . . . . . . . . . . . (b) Der angestellte Urheber. . . . . . . . . . . . . . . . . . . . . . . (c) Miturheberschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (d) Urheberschaft in Arbeits- und Dienstverhältnissen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (5) Verwertungsrechte an Computerprogrammen . . . . . . . (a) Die einzelnen Verwertungsrechte . . . . . . . . . . . . . . (b) Ausnahmen von den zustimmungsbedürftigen Handlungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (c) Dekompilierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (d) Rechtsverletzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . (e) Anwendung sonstiger Vorschriften . . . . . . . . . . . . . II. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Die urheberrechtliche Lizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

68 69 69 69 70 73 75 75 75 76 79 81 83 84 84 85 86 91 96 98 98 99 99 105 108 108 111 112 113 114 114 115

Inhaltsverzeichnis § 5 Open Source Software im deutschen Urheberrecht . . . . . . . . . . . . . . . . . . I. Open Source Software als Schutzgegenstand des UrhG. . . . . . . . . . . . . II. Open Source Software und Anwendbarkeit des UrhG/Internationales Urheberrecht und kollisionsrechtliche Einordnung von Freier Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Internationales Urheberrecht als Fremdenrecht . . . . . . . . . . . . . . . . . a) Entstehung, Inhaberschaft, Inhalt und Dauer des Urheberrechts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Internationales Urhebervertragsrecht . . . . . . . . . . . . . . . . . . . . . . . aa) Trennungsprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Verpflichtungsgeschäft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cc) Urheberrechtliches Verfügungsgeschäft. . . . . . . . . . . . . . . . . dd) Anzuwendendes Recht bei Open Source-Lizenzen . . . . . . (1) Vertragliche Rechtswahl gem. Art. 27 EGBGB . . . . . (2) Anknüpfung gem. Art. 28 EGBGB . . . . . . . . . . . . . . . . (3) Verbraucherkollisionsrecht gem. Art. 29 EGBGB . . . c) Persönlicher Anwendungsbereich des UrhG bei Sachverhalten mit Auslandsbezug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Zuständigkeit und prozessuale Gesichtspunkte bei Open Source Software/Internationales Zivilverfahrensrecht . . . . . . . . . . . . . . . . . . a) Zuständigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aa) Rechtsstreitigkeiten ohne Auslandsbezug . . . . . . . . . . . . . . . (1) Die Zuständigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (2) Gerichtsstandvereinbarung . . . . . . . . . . . . . . . . . . . . . . . . bb) Rechtsstreitigkeit mit Auslandsbezug . . . . . . . . . . . . . . . . . . (1) Zuständigkeit nach der EuGVO bzw. nach der LugÜ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (2) Besondere Gerichtsstände . . . . . . . . . . . . . . . . . . . . . . . . . (3) Gerichtsstandvereinbarung . . . . . . . . . . . . . . . . . . . . . . . . cc) Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dd) Rechtsstreitigkeiten mit Bezug zum amerikanischen Rechtsraum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ee) Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Anerkennung ausländischer Urteile . . . . . . . . . . . . . . . . . . . . . . . . III. Urheberschaft bei Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . 1. Einzelurheberschaft bei Open Source Software. . . . . . . . . . . . . . . . . a) Urheber gem. § 7 UrhG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Bearbeitung durch den Einzelurheber . . . . . . . . . . . . . . . . . . . . . . aa) Entstehen eines Bearbeiterurheberrechts . . . . . . . . . . . . . . . . (1) Verhältnis des Urhebers des Originalwerkes zu dem Urheber der Bearbeitung . . . . . . . . . . . . . . . . . . . . . (a) BGB-Gesellschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . (b) Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 118 118

119 120 120 124 125 125 126 127 127 129 134 139 140 141 141 141 142 144 144 146 147 148 148 149 149 151 152 152 153 153 154 154 154

16

Inhaltsverzeichnis (c) Entwicklergemeinschaft. . . . . . . . . . . . . . . . . . . . . . . (2) Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Entwicklungsgemeinschaften von Open Source Software. . . . . . . . a) Miturheberschaft an Open Source Software. . . . . . . . . . . . . . . . . aa) Gemeinsame Gesamtidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Aktivlegitimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Werkverbindung gem. § 9 UrhG. . . . . . . . . . . . . . . . . . . . . . . . . . . c) Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Open Source-Programmierer im Angestelltenverhältnis . . . . . . . . .

§ 6 Open Source-Lizenzen und Verwertungsrechte . . . . . . . . . . . . . . . . . . . . . . I. Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Open Source Softwarelizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Open Source Softwarelizenzen ohne Copyleft-Effekt . . . . . . . . . . . 2. Open Source Softwarelizenzen mit strengem Copyleft-Effekt. . . . 3. Open Source-Lizenzen mit beschränktem Copyleft-Effekt . . . . . . . 4. Verbreitung einzelner Open Source-Lizenzen . . . . . . . . . . . . . . . . . . III. Verwertungsrechte in Open Source Softwarelizenzverträgen . . . . . . . . 1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Verwertungsrechte in Open Source-Lizenzen. . . . . . . . . . . . . . . . . . . a) Einräumung von Nutzungsrechten an Open Source Software . aa) Schuldrechtliche Einwilligung in die Nutzung von Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Rechtseinräumung gem. § 31 UrhG. . . . . . . . . . . . . . . . . . . . (1) Ausschließliches Nutzungsrecht . . . . . . . . . . . . . . . . . . . (2) Einfaches Nutzungsrecht. . . . . . . . . . . . . . . . . . . . . . . . . . (a) Der Streit um das einfache Nutzungsrecht . . . . . . (b) Keine Verwertungsketten bei Open Source Softwarelizenzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Die einzelnen Verwertungsrechte . . . . . . . . . . . . . . . . . . . . . . . . . . aa) Das Vervielfältigungsrecht i. S. v. §§ 16, 69 c Nr. 1 UrhG (1) Befugnisse des Nutzers . . . . . . . . . . . . . . . . . . . . . . . . . . . (2) Pflichten und Bedingungen . . . . . . . . . . . . . . . . . . . . . . . bb) Das Verbreitungsrecht i. S. d. §§ 17, 69 c Nr. 3 UrhG . . . . (1) Befugnisse des Nutzers . . . . . . . . . . . . . . . . . . . . . . . . . . . (a) Problem der Online-Übermittlung. . . . . . . . . . . . . . (b) GPL und § 69 c Nr. 4 UhrG. . . . . . . . . . . . . . . . . . . (aa) Der Meinungsstand . . . . . . . . . . . . . . . . . . . . . . (bb) Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . (c) Open Source als bekannte Nutzungsart gem. § 31 IV UrhG . . . . . . . . . . . . . . . . . . . . . . . . . . .

155 156 157 157 158 158 160 164 165 165 166 166 167 167 167 168 168 168 168 169 169 169 170 170 171 171 173 174 174 174 176 177 177 178 179 179 180 180

Inhaltsverzeichnis (d) Einräumung des Nutzungsrechts gem. § 69 c Nr. 4 durch die GPL . . . . . . . . . . . . . . . . . . . . (e) Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (f) Vermietrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (aa) Meinungsstand . . . . . . . . . . . . . . . . . . . . . . . . . . (bb) Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . (g) Application Service Providing von Open Source Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (2) Pflichten und Bedingung. . . . . . . . . . . . . . . . . . . . . . . . . . (3) Problem der Erschöpfung bei der Verbreitung von Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . cc) Das Veränderungsrecht gem. §§ 69 c Nr. 2, 23 UrhG . . . . (1) Befugnisse des Nutzers . . . . . . . . . . . . . . . . . . . . . . . . . . . (2) Pflichten und Bedingungen . . . . . . . . . . . . . . . . . . . . . . . (3) Kollision der Veränderungsfreiheit mit Urheberpersönlichkeitsrechten . . . . . . . . . . . . . . . . . . . . . . . . . . . . § 7 Rechtliche Dogmatik des Copyleft-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . I. Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Lösungsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Schuldrechtliche Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Schenkung unter Auflage gem. §§ 516, 525 BGB . . . . . . . . . . . . . . 3. Open Source Software als eigene Nutzungsart . . . . . . . . . . . . . . . . . a) Herausbildung einer technisch-wirtschaftlichen Nutzungsart . . b) Verknüpfung von Rechten und Pflichten durch Einräumung eines inhaltlich beschränkten Nutzungsrechts bei Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aa) Technisch-wirtschaftliche Eigenständigkeit . . . . . . . . . . . . . bb) Kritik an der Annahme einer technisch-wirtschaftlichen Nutzungsart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (1) Fehlende technische Eigenständigkeit . . . . . . . . . . . . . . (2) Annahme einer wirtschaftlichen Eigenständigkeit . . . (3) Ziff. 4 GPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (4) LG München I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c) Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Dinglich wirkender Vorbehalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a) Meinungsstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III. Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 183 185 185 185 185 187 189 190 190 190 191 192 193 193 193 193 195 196 197

198 198 200 201 202 206 206 206 207 207 209 211

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz . . . . . . . . . . . . 213 I. Allgemeines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 II. Erschöpfungsgrundsatz im Rahmen der Verbreitung von Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 2 Teupen

18

Inhaltsverzeichnis 1. Anwendungsvoraussetzungen des § 69 c Nr. 3 UrhG bei Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Generelle Anwendbarkeit des § 69 c Nr. 3 UrhG auf Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Verhinderung der Erschöpfung bei Open Source Software. . . . . . . a) Anwendung des Erschöpfungsgrundsatzes bei Online-Verbreitung von Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Umgehung des Erschöpfungsgrundsatzes durch eine inhaltliche Beschränkung des Verbreitungsrechts . . . . . . . . . . . . aa) Erschöpfung beschränkter Verbreitungsrechte . . . . . . . . . . . bb) Inhaltlich beschränktes Verbreitungsrecht bei Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c) Umgehung einer Erschöpfungswirkung durch Ausschluss von Erwerbskette bei der Lizenzeinräumung . . . . . . . . . . . . . . . . . . . . aa) Beschränkte Bindungswirkung der GPL in der Vertriebskette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d) Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

§ 9 Vertragliche Einordnung der Softwareüberlassung bei Open Source Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Nicht durch Distributoren vertriebene Software. . . . . . . . . . . . . . . . . . . . 1. Vorbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Vertragsbeziehungen als BGB-Gesellschaft . . . . . . . . . . . . . . . . . . . . 3. „Open Source-Entwicklervertrag“ als Vertrag sui generis. . . . . . . . 4. Open Source Software-Überlassung als Kaufvertrag gem. § 433 I BGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Software-Download als Auftrag gem. § 662 BGB . . . . . . . . . . . . . . 6. Ausgestaltung des Grundgeschäfts als Leihe gem. §§ 598 ff. . . . . 7. Open Source Software-Überlassung als Schenkung gem. §§ 516 ff. BGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a) Zuwendung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Entreicherung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c) Bereicherung des Beschenkten . . . . . . . . . . . . . . . . . . . . . . . . . . . . d) Unentgeltlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e) Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Dingliche Verfügung ohne schuldrechtliches Grundgeschäft . . . . . 9. Eigene Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a) Schenkungsrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b) Open Source Software-Überlassung als dingliche Verfügung aufgrund eines Open Source-Vertrages gem. § 311 I BGB . . . aa) Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bb) Eigener Lösungsvorschlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . (1) Der Open Source-Vertrag . . . . . . . . . . . . . . . . . . . . . . . . .

215 216 217 217 217 217 218 220 220 221 224 225 225 226 226 228 229 230 231 232 232 233 234 234 235 235 236 236 240 240 241 242

Inhaltsverzeichnis

19

(2) Open Source-Lizenzen als AGB . . . . . . . . . . . . . . . . . . . (a) Anwendbarkeit der §§ 305 ff. BGB auf Open Source-Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (b) Open Source-Lizenzen als Allgemeine Geschäftsbedingungen . . . . . . . . . . . . . . . . . . . . . . . . (c) Wirksame Einbeziehung der AGB in den Lizenzvertrag gem. § 305 II BGB. . . . . . . . . . . . . . . . . . . . (d) Inhaltskontrolle der AGB hinsichtlich des generellen Gewährleistungs- und Haftungsausschlusses bei Open Source Software-Überlassung . . . . . (aa) Vorbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . (bb) Inhalt der Regelungen . . . . . . . . . . . . . . . . . . . (cc) Gewährleistungsausschluss Ziff. 11 GPL als Klauselverbot ohne Wertungsmöglichkeit gem. § 309 Nr. 8 b aa) BGB. . . . . . . . . . . . . . (dd) Gewährleistungsausschluss Ziff. 11 GPL als Klauselverbot ohne Wertungsmöglichkeit gem. § 309 Nr. 7 b BGB . . . . . . . . . . . . . . . . . (ee) Die vertragliche Gewährleistung von Open Source Verträgen . . . . . . . . . . . . . . . . . . . . . . . . (ff) Haftungsregelung Ziff. 12 GPL als Klauselverbot ohne Wertungsmöglichkeit gem. § 309 Nr. 7 a BGB . . . . . . . . . . . . . . . . . . . . . . (gg) Die vertragliche Haftung bei Open Source Verträgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (3) Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Ergebnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II. Vertragliche Einordnung von Softwareüberlassung bei Vertrieb von Open Source Software durch Distributoren . . . . . . . . . . . . . . . . . . . . . . . . 1. Einräumung urheberrechtlicher Nutzungsrechte am Computerprogramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Abschluss eines Distributorenvertrages . . . . . . . . . . . . . . . . . . . . . . . . III. Die Ankunft des Open Source-Gedankens im UrhG. . . . . . . . . . . . . . . .

242 242 243 244

247 248 249

250

251 252

254 255 255 256 256 256 256 257

§ 10 Fazit und Ausblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Sachwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

2*

§ 1 Grundlagen I. Einführung Das Recht an geistigen Gütern ist so alt, wie Möglichkeiten bestehen, geistige Schöpfungen in Form von körperlichen Werken auszudrücken. Ohne ein geeignetes Rechtsinstrumentarium zur Regelung der Rechte an geistigen Schöpfungen wäre der in ihnen liegende Vermögenswert wirtschaftlich kaum nutzbar. Neben Patent-, Marken-, Musterrecht ist das Urheberrecht wohl das zentrale Regulativ der Immaterialgüterrechte, um Geisteswerke umfassend zu schützen und die Interessen von Schöpfer, Werkverwertern und Gesellschaft auszugleichen. Es schafft durch seine rechtliche Konstruktion die Möglichkeit, immaterielle Waren und Dienstleistungen handelbar zu machen, und durch die Ausschließlichkeitsgarantie setzt das Urheberrecht zugleich den Anreiz, neue innovative Güter zu produzieren und zu verbreiten1. Beim Urheberrecht handelt sich es dabei keinesfalls um ein Rechtsgebiet, das aufgrund der Entwicklung von traditionellen Werkarten hin zu modernen digitalisierten Ausdrucksformen im Abseits der rechtwissenschaftlichen Betrachtungen steht. Die Bedeutung dieses Rechtsgebietes wird vielfach unterschätzt. Befürchtungen, das Urheberrecht werde mit der Zeit in Betracht der digitalen Entwicklung zunehmend an Bedeutung verlieren, haben sich als unzutreffend erwiesen. Gerade in unserer heutigen Wirtschaftsordnung, in der zunehmend Dienstleistungen und unkörperliche Produkte an die Stelle herkömmlicher industrieller Produktionstätigkeit treten, kommt dem Urheberrecht eine zentrale Rolle zu. Der Wandel der Industriegesellschaft zur sog. Informationsgesellschaft stellt zugleich hohe Anforderungen an das Urheberrecht. Die Möglichkeit der Digitalisierung von Informationen und der Einsatz elektronischer Kommunikationsmedien haben es möglich gemacht, Informationen vielfältiger zu nutzen. Die Bedeutung des Internets in diesem Zusammenhang und seine „katalysatorische“ Wirkung für die schnelle und unaufhaltbare Entwicklung der Informationsgesellschaft sind allgemein anerkannt. Erst das Internet hat es möglich gemacht, digitalisierte Informationen dezentral zu jedem Zeitpunkt und an jedem Ort der Welt zu nutzen und auszutauschen. Durch die technische Entwicklung werden die Möglichkeiten für das geistige Schaffen und die Verwertung der Werke vervielfacht und diversifiziert. Fragen des 1

Dreier, CR 2000, S. 45.

22

§ 1 Grundlagen

geistigen Eigentums und dessen wirksamen Schutzes sind nunmehr Themen nicht nur rechtspolitischer Diskussionen, sondern auch gesellschaftlicher Erörterungen. Die Aktualität dieses Rechtsgebietes zeigt sich auch darin, dass nicht nur die Veröffentlichungen juristischer Literatur zum Urheberrecht enorm zugenommen haben, sondern auch Publikationen in fachfremden Medien, etwa Computerfachzeitschriften oder Tageszeitung, zu diesen Themen Stellung nehmen. Das Urheberrecht hat somit infolge der Entwicklung seine „Nebenrolle“ aufgegeben und als „Hauptakteur“ breite Aufmerksamkeit erlangt2. Der amerikanische Rechtsgelehrte James Boyle bezeichnet das geistige Eigentum sogar als „die Rechtsform des Informationszeitalters“3. Doch auch andere sehen die Gefahr, dass im Informationszeitalter das Urheberrecht Gefahr läuft, mit Fragen und Problemen konfrontiert zu werden, deren Lösung es nicht bewältigen kann. So spricht Dreier4 von einer Krise des Urheberrechts und plädiert für eine „Informationseigentumsordnung“ als rechtlichen Ordnungsrahmen, der die Kriterien einer Zuordnungsund einer Verteilungsgerechtigkeit hinsichtlich der Nutzung und Weiterverarbeitung von Informationen bestimmt. Gerade die aktuellen Diskussionen um technische Schutzmöglichkeiten für die Inhaltindustrie außerhalb des Urheberrechts, wie das so genannte Digital-Rights-Management, zeigen, dass die Sanktionsmöglichkeiten des Urheberrechts für unzureichend gehalten werden und deshalb nach Möglichkeiten einer effektiven Rechtswahrnehmung außerhalb des Urheberrechts im technischen Bereich gesucht wird. Das Urheberecht muss sich diesen aktuellen sowie zukünftigen Entwicklungen mit dem Ziel stellen, einen angemessenen Ausgleich zwischen Urhebern, Verwertern und Nutzern durch normative Regeln zu erreichen. Auch der europäische Gesetzgeber hat auf die Entwicklung hin zur Informationsgesellschaft durch die Verabschiedung der sog. InfoSoc-RL5 reagiert. Die EU setzt mit dieser Richtlinie die Vorgaben der völkerrechtlichen Verträge, WIPO Copyright Treaty [WCT] und des WIPO Performers and Producers Rights Treaty [WPPRT] um. Die Mitgliedsstaaten werden mit dieser Richtlinie dazu angehalten, Bestimmungen des Urheberrechts und der verwandten Schutzrechte anzupassen und zu ergänzen, um den wirtschaftlichen Gegebenheiten und Veränderungen hinreichend Rechnung zu tragen. Die InfoSoc-RL kann als die gegenwärtig bedeutsamste Rechtsquelle zur Fortschreibung und Anpassung des Urheberrechts in den Staaten 2

So auch Lutterbeck, CR 2000, S. 58. Zitiert nach Grassmuck, S. 30. 4 Dreier, in: Büllesbach/Dreier, S. 109 f. 5 EU-RL 2001/29/EG zur Harmonisierung bestimmter Aspekte des Urheberrechts und der verwandten Schutzrechte in der Informationsgesellschaft vom 22. Mai 2001, Abl. EG Nr. L 167/10 vom 22. Juni 2001 (im Folgenden als InfoSoc-RL bezeichnet). 3

I. Einführung

23

der EU entsprechend den Herausforderungen der digitalen Welt bezeichnet werden6. Der deutsche Gesetzgeber hat nach den inhaltlichen Vorgaben der Richtlinie gehandelt und das Gesetz zur Regelung des Urheberrechts in der Informationsgesellschaft verabschiedet. Der Bundesrat hat in seiner Plenarsitzung vom 11.07.2003 die Beschlussempfehlung des Vermittlungsausschusses7 gebilligt und somit den Weg für den sog. „ersten Korb“ der Urheberrechtsreform frei gemacht8. Das Gesetz zur Regelung des Urheberrechts in der Informationsgesellschaft wurde am 12.09.2003 im Bundesgesetzblatt veröffentlicht9 und ist am 13.09.2003, mit siebenmonatiger Verspätung bezogen auf die Zeitvorgaben aus Brüssel, in Kraft getreten10. Mit Inkrafttreten der neuen Regelungen ist die Novellierung des UrhG keinesfalls abgeschlossen. Geplant ist die Umsetzung eines „zweiten Korbes“. Der Auftakt hierzu hat im Rahmen eines gemeinsam von Bundesjustizministerium und dem Institut für Urheber- und Medienrecht München veranstaltetem Symposions zum Thema „Urheberrecht in der Informationsgesellschaft – Auftakt zum zweiten Korb“ am 16. September 2003 stattgefunden. Dieser soll Lösungen für die Themen finden, für die keine zwingenden Vorgaben der EU bestehen11. In Folge der Diskussionen zum „zweiten Korb“ hat das Bundesministerium für Justiz den Referentenentwurf für ein zweites Gesetz zur Regelung des Urheberrechts in der Informationsgesellschaft am 01. Oktober 2004 veröffentlicht12. Für den Bereich des Softwarerechts sind die Ausführungen zu Inhalt und Umfang der Schrankenbestimmungen, die Durchsetzung der Privatkopie gegen technische Kopierschutzmaßnahmen sowie die Einschränkung der Nichtübertragbarkeit unbekannter Nutzungsarten von Bedeutung13. Es bleibt mit Spannung abzuwarten, inwiefern die Reformvorschläge des Referentenentwurfes letztlich gesetzlich umgesetzt werden. 6

Lehmann, CR 2003, S. 553. BT-Drucks. 15/1353. 8 MMR aktuell 8/2003, S. V; Frankfurter Allgemeine Zeitung, 12. Juli 2003. 9 BGBl. I (2003), S. 1774 ff. 10 Pressemitteilung des BMJ vom 12. September 2003; http://www.bmj.de/ger/ service/pressemitteilungen/10000787/. 11 MMR aktuell 8/2003, S. V; Schippan, ZUM 2003, 680; Mitteilung des Instituts für Urheberrecht [http://www.urheberrecht.org/news/?id=1444&w=&p=1]; Ankündigung der Bundesministerin für Justiz Frau Brigitte Zypries (SPD), FAZ vom 17. September 2003, S. 21. 12 Der Referentenentwurf ist abrufbar unter: http://www.kopien-brauchen-origi nale.de/enid/1cb1bd7c31d0647aec5b824d29a7573f,0/65.html. Das Portal „kopienbrauchen-originale“ wurde vom Bundesjustizministerium mit dem Ziel ins Leben gerufen, die urheberrechtlichen Neuerungen zu kommunizieren. Auf dem Portal sind auch alle der verschiedenen Interessengruppen abrufbar. Vgl. dazu auch eine erste Bewertung bei Hilty, MMR 2004, S. 713 f. 13 Zu den geplanten Reformen vgl. Flechsing, ZRP 2004, S. 249 ff. 7

24

§ 1 Grundlagen

Dass es sich bei der Diskussion über den „Wandel zur Informationsgesellschaft“ und die daraus resultierenden Anforderungen an das Urheberrecht nicht nur um eine rein theoretisch-wissenschaftliche Debatte handelt, zeigen auch die ökonomischen Daten für den Markt der Informationstechnologie. Der Markt der Informationstechnologie ist der wachstumsstärkste und dynamischste Sektor der Weltwirtschaft. Die Informationstechnologie trägt einen Betrag von ungefähr einer Trillion $ zur Weltwirtschaft bei14. Im Bereich der Informationstechnologie sind weltweit ca. 9 Millionen Menschen im oberen Einkommensbereich in mehr als 4.000 Unternehmen beschäftigt15. Die Anzahl der Arbeitsplätze ist in den Jahren zwischen 1996 und 2002 um 40% gewachsen, allein im Softwaresektor um 76%16. Softwareentwicklung ist in diesem Zusammenhang der Hauptfaktor für wirtschaftliches Wachstum. Das zeigt auch die Tatsache, dass mehr als 60% der Ausgaben im Bereich von Software und IT-Services17 getätigt wurden18. Investitionen im Bereich Software sind zwischen 1996 und 2001 um das Sechsfache schneller gestiegen als im Bereich Hardware19. Auch in Deutschland befindet sich der Informationstechnologiesektor im Aufwärtstrend. Allein in den Jahren von 1995 bis 2001 ist dieser Sektor um 4,4 Mrd. Euro gewachsen, und es sind mehr als 150.000 neue Arbeitsplätze entstanden20. Die Umsätze in der Informationstechnologie betrugen allein im Jahr 2002 ca. 61 Mrd. Euro, und für das Jahr 2006 wird mit einem Umsatz von ca. 80 Mrd. Euro gerechnet21. Der Sektor der Informationstechnologie ist für die Nutzung und Erzeugung von Gütern und digitalisierten Werken notwendigerweise auf Software 14 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 15 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 16 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 17 Der Begriff „IT-Services“ ist kein fester Terminus, sondern umfasst vielmehr alle Dienstleistungen, die im Zusammenhang mit Software stehen. Der Begriff ist nicht klar zu definieren, wird aber in der Studie verwendet und daher auch an dieser Stelle genannt. 18 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 19 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 20 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 21 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1.

I. Einführung

25

angewiesen. Ohne funktionierende Softwarelösungen könnte dieser Sektor nicht bestehen. Softwareanwendungen sind unabdingbar für wissenschaftliches Arbeiten, für Verwaltung und für den Ablauf wirtschaftliche Vorgänge in Unternehmen. Der Bereich Software und Softwareentwicklung durchzieht die gesamte deutsche Volkswirtschaft und wird zunehmend zum wettbewerbsbestimmenden Faktor. Allein für den Markt „Unternehmenssoftware“ in Deutschland wird bis zum Jahr 2005 mit zweistelligen Wachstumsraten gerechnet22. Es wird davon ausgegangen, dass der Markt in diesem Bereich auf ein Volumen von ca. 8,64 Mrd. Euro bis 2005 anwächst23. Die Tatsache, dass Software von herausragender Bedeutung für die ökonomische Entwicklung des deutschen Wirtschaftsstandorts ist und als geistiges Erzeugnis eines ausreichenden Schutzes bedarf, hat auch der Gesetzgeber schon frühzeitig zum Anlass genommen, um die Einführung eines speziellen Leistungsschutzes für Computerprogramme zu diskutieren24. Auch die Europäische Kommission forderte die Harmonisierung und die Stärkung des urheberrechtlichen Schutzes von Computerprogrammen als Beitrag zur Vollendung des Binnenmarktes und hielt dieses Ziel im „Grünbuch über Urheberrecht und die technologische Herausforderung – Urheberrechtsfragen und die technologische Herausforderungen“ fest25. Am Ende der Beratungen stand dann die Verabschiedung der Richtlinie über den Rechtsschutz von Computerprogrammen26 durch den Rat, um die Unsicherheiten über die Frage des urheberrechtlichen Schutzes von Computerprogrammen zu beenden und so Investitionen in diesem Bereich eine sichere gesetzliche Grundlage zu bieten. In Deutschland wurde diese Richtlinie mit dem zweiten Gesetz zur Änderung des Urheberrechtsgesetzes, welches 1993 in Kraft getreten ist, in nationales Recht umgesetzt und die §§ 69 a ff. in das Urhebergesetz eingefügt27. Die besonderen Bestimmungen für Computerprogramme in den §§ 69 a UrhG verdeutlichen, dass es sich bei Computerprogrammen um eine Werkart handelt, die aufgrund ihrer Besonderheit differenzierter Regelungen bedarf. Ein großes Hindernis für die ungestörte dynamische Entwicklung in diesem Bereich bleibt die Softwarepiraterie, d. h. die enorme Verbreitung von Raubkopien. Bei ca. 34% der in Deutschland eingesetzten Software handelt 22 Financial Times Deutschland, 21. März 2003 [http://www.ftd.de/tm/it/ 1048234716938.html]. 23 Financial Times Deutschland, 21. März 2003 [http://www.ftd.de/tm/it/ 1048234716938.html]. 24 BT-Drucks. XI/4929, S. 40 ff. 25 KOM (1988) 127 vom 23. August 1988, S. 170 ff. 26 EG-RL 91/250/EWG vom 14. Mai 1991, ABl L 122 vom 17. Mai 1991 (sog. Computerprogramm-Richtlinie, im Folgenden als solche bezeichnet). 27 Wandtke/Bullinger/Grützmacher, UrhG, Vor §§ 69 a UrhG Rn. 6.

26

§ 1 Grundlagen

es sich um Raubkopien28. Gerade auch diese Tatsache zeigt die Anforderungen an das Urheberrecht im Bereich von Computerprogrammen. Durch die Verwendungen von Raubkopien wird nicht nur das Recht am geistigen Eigentum ignoriert, sondern sie verursachen ökonomischen Schaden. Die IDC29-Studie geht davon aus, dass bei einer Reduzierung der Softwarepiraterie-Quote allein um 10% auf 24% die deutsche Softwarebranche ein Umsatzplus von 15 Mrd. Euro erwarten könnte30. Folge der Umsatzsteigerung wäre im Weiteren auch die Entstehung von ca. 40.000 Arbeitsplätzen im Bereich der Informationstechnologie, und das Wachstum würde bis 2006 um 9% steigen31. Auch der Staat würde von der Reduzierung von Raubkopien mit einem zusätzlichen Steuervolumen von 4,1 Mrd. Euro profitieren32. Eine wirksame Bekämpfung der Raubkopien könnte somit die momentane Stagnation des deutschen Marktes beenden und zur Belebung der Branche, verbunden mit Umsatzgewinnen, führen. Die Zahlen und Ergebnisse der Studie belegen die hohe Bedeutung des geistigen Eigentums im Bereich der Computerprogramme. „Open Source ist eine Technologie, die für Unruhe sorgt. Dieses Modell der kooperativen Software-Entwicklung führt zu Kostenvorteilen und Qualität wie sie traditionelle Software-Anbieter kaum erreichen können. Das ist gut für IT-Kunden, weil so mehr Innovation und Auswahl entsteht. Weil Open Source so stark in den Markt eingreift, gefährdet dieses Prinzip einige tief verwurzelte Interessen. Einige Interessenvertreter kämpfen dagegen mit den wagen Beschuldigungen, dass es bei Open Source-Technologien Risiken wegen des geistigen Eigentums gebe.“33

Parallel zu den „proprietären34“ Computerprogrammen ist in den vergangenen Jahren ein bedeutender Markt von Open Source Software35 oder Free 28

Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 29 International Data Corporation. 30 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 31 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 32 Studie der Business Software Alliance (IDC-Studie) vom 02. April 2003, Materialverzeichnis Nr. 1. 33 Jack Messman, CEO, Novell; Der Standard (Österreich) vom 13. Oktober 2004. 34 Das Adjektiv „proprietär“ wird verwendet, um auf das geistige Eigentum an einem Computerprogramm und den daraus folgenden Ausschließlichkeitsrechten hinzuweisen. Es dient allgemein als Abgrenzung zu Open Source Software. Die Bezeichnung eines Computerprogramms oder einer Software als „proprietär“ ist grundsätzlich irreführend, da auch an Open Source Software geistiges Eigentum (vgl. DiBona/Ockman/Stone/Perens, Opensources, S. 181) und daraus folgend Ausschließlichkeitsrechte bestehen. Insofern ist die Bezeichnung „proprietär“ als Unter-

I. Einführung

27

Software36 entstanden und hat sich inzwischen als echte Alternative am Markt etabliert. Gerade in den letzten Jahren hat dieser Bereich durch eine umfangreiche Berichterstattung in der Tages- und Fachpresse eine immer breitere öffentliche Aufmerksamkeit erlangt. Die Freie Software ist für viele Anwender zu einer echten Alternative für „proprietäre“ Software geworden. Kuhlen37 ist sogar der Meinung, dass in diesem freien Zugang zur Software kein Gegensatz zur Kommerzialisierung des Informationsaustausches liegt, sondern sieht darin sogar eine Reorganisation der Informationsgesellschaft. Aufgrund dieser Entwicklung hin zu Open Source Software stellen sich auch Fragen der urheberrechtlichen Besonderheiten von freier Software. Dabei sind viele Fragen zur rechtlichen Einordnung von Open Source Software noch nicht abschließend geklärt und bisher nur selten Gegenstand juristischer Analysen gewesen38. Auch hat sich bisher die Rechtsprechung noch nicht mit dem Phänomen Open Source Software auseinander setzen müssen. Die Diskussion hat vor allem durch das Gutachten39 von Prof. Dr. Spindler im Auftrag des Verbands der Softwareindustrie Deutschland (VSI) an Intensität zugenommen40. Der Auftraggeber des Gutachtens VSI kommt aufgrund der Studie zum Schluss, dass der Einsatz von Open Source Software rechtlich kritisch zu bewerten ist und zu Rechtsunsicherheiten führt41. Der Verband, der im wesentlichem die Interessen der „proprietären“ Softwareindustrie vertritt, hält Teile der Lizenzvereinbarungen, namentlich der General Public License (GPL) für unvereinbar mit dem deutschen Recht42. Die Debatte über das Gutachten hat auch dazu geführt, dass auf dem Linuxtag 2003 intensiv über die rechtlichen Rahmenbedingungen der freien Software diskutiert wurde43. scheidungskriterium inkorrekt. Da sie jedoch weitläufig verwendet wird, soll sie trotz der Widersprüchlichkeit im Folgenden verwendete werden. Vgl. zur dieser problematischen Terminologie auch Jaeger/Metzger, S. 3. 35 Der Versuch einer Definition sowie die Darstellung der Entwicklung der freien Software, sowie deren ökonomische Bedeutung werden noch ausführlich behandelt. 36 Zur Terminologie, vgl. § 1 IV., V. 37 Kuhlen, in: Büllesbach/Dreier, S. 4. 38 So auch Spindler, CR 2003, S. 873, mit weiteren Nachweisen. 39 Das Gutachten ist mittlerweile als Buch schienen: Gerald Spindler, Rechtsfragen bei Open Source Software, Köln 2004. 40 Die Computerzeitschrift ct titelte: „Rechtliches Minenfeld – Umstrittene Studie zur Rechtssicherheit von Open Source“ (Magazin für Computertechnik, 17. Juli 2003, S. 44); Die Frankfurter Allgemeine Zeitung berichtete unter dem Titel „Ein Juraprofessor schreckt die Linux-Welt auf“ über das umstrittene Gutachten. 41 VSI Mitteilung vom 01. Juli 2003, unter: www.vsi.de. 42 Ebd. 43 „Linuxtag 2003: Interesse an Rechtsfragen rund um Freie Software steigt“ (14. Juli 2003), www.ifross.de.

28

§ 1 Grundlagen

In den USA wird momentan in aller Schärfe eine rechtliche Auseinandersetzung zwischen den amerikanischen Unternehmen SCO und IBM geführt. Es geht bei diesem Rechtsstreit nach Meinung von SCO um die Zukunft des „Open-Source-Entwicklungsmodell“. In dem Rechtsstreit beschuldigt SCO44 das Unternehmen IBM, Teile des Quellcodes von Unix in ihre Linux-Version eingearbeitet zu haben und so die Rechte von SCO verletzt zu haben45. Gleichzeitig warnt SCO auch die Open-Source-Community46, sich systematisch über die „Copyrights“ von SCO hinwegzusetzen47. In Deutschland haben die Auswirkungen des Rechtsstreits bereits dazu geführt, dass gegen SCO ein Ordnungsgeld verhängt worden ist, da das Unternehmen auf seiner Internetseite behauptet hatte, dass Linux-Anwender für Schutzverletzungen des geistigen Eigentums von SCO haftbar gemacht werden könnten48. Die mitunter heftig geführten Debatten in der juristischen Fachwelt über die rechtliche Bewertung von Open Source Software sowie die Tatsache, dass bereits zahlreiche Unternehmen sowie auch die öffentliche Hand enorme Investitionen in die Entwicklung und Anwendungslösungen Freier Software getätigt haben, zeigen, dass eine intensive Beschäftigung mit urheberrechtlichen Fragen zur Lizenzierung in diesem Bereich berechtigt und notwendig ist49.

II. Gang der Darstellung Im Rahmen dieser Arbeit sollen die urheberrechtlichen Besonderheiten der Freien Software untersucht werden. Zu Beginn der Arbeit wird dargestellt, was Open Source Software oder Free Software ist und was sie von anderen Softwarearten unterscheidet. Es werden in diesem Zusammenhang auch die historische Entwicklung sowie die wirtschaftliche Bedeutung von freier Software behandelt (§ 2). Im Weiteren stellt sich die Frage, mit welcher Grundintention Software als Open Source Software oder Free Software zu Verfügung gestellt wird 44 SCO sieht sich als Rechtsnachfolger von AT&T, die Unix entwickelt haben und 1992 an Novell verkauft haben. 1995 hat SCO die Rechte an Unix von Novell erworben. Vgl. Magazin für Computertechnik, 02. Juni 2003, S. 66. 45 Vgl.: Inhalt der Klage SCO gegen IBM vom 06. März 2003, http://www.sco. com/scosource/complaint3.06.03.html. 46 Engl.: Gemeinde, Gemeinschaft – bezeichnet in diesem Zusammenhang die gut organisierte Open-Source-Entwicklergemeinde, die ihre Ideen, Methoden, Werkzeuge und Programmierergebnisse untereinander austauschen. 47 Offener Brief von Darl McBride, CEO der SCO Group vom 09. September 2003, www.sco.com/company/openletter. 48 Magazin für Computertechnik, 22. September 2003, S. 47. 49 So auch Junker, NJW 2003, 2793.

II. Gang der Darstellung

29

und wo die Unterschiede der urheberrechtlichen Grundintentionen zwischen Urhebern von Open Source Software bzw. Free Software einerseits und „proprietärer“ Software andererseits liegen (§ 3). Die Existenz sowie die Fortentwicklung Freier Software sind nur durch das Bestehen wirksamer Lizenzmodelle möglich. Ohne die Möglichkeit, durch Lizenzvereinbarungen Software als Freie Software zugänglich zu machen und die Rechte und Pflichten der Urheber sowie die der Nutzer konkret festzuschreiben, wäre die stetige Entwicklung in diesem Bereich nicht nur unmöglich gewesen, vielmehr gäbe es keine Open Source Software. Es hätte die Gefahr bestanden, dass Freie Softwareprojekte ohne die Verwendung von Lizenzen „proprietärer“ Interessen zum Opfer gefallen wären. Mit der Wirksamkeit der Lizenzmodelle steht oder fällt somit das „Projekt“ Freie Software. Aufgrund der zentralen Bedeutung der Lizenzen für Freie Software wird ihre rechtliche Beurteilung Kern der Untersuchung sein. Die Untersuchung urheberrechtlicher Fragen wird mit einer Darstellung der gesetzlichen Schutzinstrumentarien von Computerprogrammen eingeleitet (§ 4). Das Urheberrecht bildet hier den Schwerpunkt. Ausgehend hiervon erfolgt dann die eingehende Beschäftigung mit den urheberrechtlichen Fragen von freier Software (§ 5). Da es sich zur Zeit bei den Lizenzvereinbarungen im Bereich freier Software überwiegend, ja fast ausschließlich um Lizenzen aus dem amerikanischen Rechtsraum handelt, wird anfangs die Frage zu klären sein, welche Bedeutung das internationale Urheberrecht für die Open Source-Lizenzen hat. Dafür soll zunächst kurz der urheberrechtliche Schutz von Computerprogrammen durch internationales Recht dargestellt werden. Im Weiteren ist dann die Fragen zu klären, wie sich die Freie Software in den internationalen Rechtsrahmen einfügt. Nach Darstellung des internationalen Urheberrechts wird die Geltung der Lizenzen freier Software in Deutschland als einem europäischen Land behandelt. Im Mittelpunkt stehen hier die speziell für Open Source Software und Free Software verwendeten Lizenzen. Es werden die wesentlichen und diskussionswürdigen Regelungsinhalte der verschiedenen Lizenzen dargestellt und ihre Vereinbarkeit mit dem deutschen UrhG geprüft. Es stellen sich Fragen, inwiefern Open Source Software bzw. Free Software und deren Weiterentwicklungen, Schutzgegenstand urheberrechtlichen Schutzes sein kann. Der Frage, wer Urheber oder Miturheber ist, kommt bei freier Software besondere Bedeutung zu. Ein weiterer Schwerpunkt der rechtlichen Untersuchung der Open Source-Lizenzen ist die Frage nach Art und Umfang der Nutzungseinräumung (§ 6). In diesem Zusammenhang kommt der „Veränderungsfreiheit“ des Anwenders zentrale Bedeutung zu. Aus urheberrechtlicher Sicht sind auch die Pflichten für den Nutzer, wie sie sich aus

30

§ 1 Grundlagen

den Lizenzen ergeben, diskussionswürdig. In diesen Zusammenhängen stellt sich auch immer wieder die Frage nach den Auslegungskriterien der verwendeten Lizenzen. In § 7 wird sodann die rechtliche Dogmatik des Copyleft-Modells thematisiert. Dabei wird der Frage nach der rechtlichen Verknüpfung der Lizenzrechte mit den Lizenzpflichten nachgegangen. Im Anschluss daran folgen in § 8 die Ausführungen zu der bedeutenden Frage nach der Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz. Ein weiterer Abschnitt wird sich mit den Fragen des Urhebervertragsrechts und der rechtlichen Besonderheiten der Softwareüberlassung in diesem Bereich befassen (§ 9). Dabei geht es zunächst um die Frage, welches Rechtsgeschäft einer Überlassung von Open Source Software zugrunde liegt. In diesem Zusammenhang werden Fragen der wirksamen Vereinbarkeit der Lizenzen zwischen den Vertragsparteien behandelt. Danach schließt sich die Klärung der Fragen nach wirksamen Haftungs- und Gewährleistungsausschlüssen, wie sie laut Open Source-Lizenzen in vorformulierten Vertragsbedingungen zwingend zu vereinbaren sind an. Schließlich wird noch auf eventuelle Neuerungen des Urhebervertragsrechts eingegangen, soweit sie Einfluss auf das „Open Source“-Recht zu haben scheinen. Es folgen abschließende Anmerkungen und Einschätzungen zur künftigen Entwicklung in diesem Bereich (§ 10).

III. Inhaltliche Beschränkung der Arbeit Der Bereich Open Source Software bzw. Free Software bietet viele relevante rechtliche Aspekte, die ein hohes Erkenntnisbedürfnis beinhalten. Die Fülle von Rechtsfragen der freien Software macht es notwendig, das Erkenntnisinteresse der Arbeit auf einen bestimmten Bereich zu fokussieren. Wie bereits erläutert, werden im Rahmen dieser Arbeit lediglich urheberrechtliche Fragen behandelt. Im Bereich des internationalen Rechtsrahmens werden lediglich die wesentlichen Grundfragen behandelt, die sich auf den Geltungsbereich der verwendeten Lizenzen beschränken. Dabei werden offene Fragen und Rechtsprobleme des internationalen Privat- und Urheberrechts, die über die notwendige Darstellung hinausgehen, undiskutiert bleiben. Des Weiteren wird aufgrund einer sinnvollen Beschränkung des Umfangs der Untersuchung nicht ausführlich auf den durchaus interessanten Bereich des Gewerblichen Rechtsschutzes von Open Source Software bzw. Free Software eingegangen.

V. Definition der Kernbegriffe

31

IV. Terminologie Das Thema der Untersuchung hat zur Folge, dass nicht nur juristisch feststehende Begriffe verwendet werden, sondern auch solche aus der Informatik und Computertechnologie, die nicht immer einheitlich definiert sind. Freie Software wird beispielsweise als Open Source Software oder Free Software bezeichnet und umgekehrt. In der Untersuchung werden diese Begriffe synonym verwendet. Inwiefern sich die Begriffe Software und Computerprogramm in ihrer Bedeutung gleichen und wie sie verwendet werden, wird noch zu klären sein. Bei der Benutzung fachfremder Termini werden diese jeweils in der Fußnote erläutert.

V. Definition der Kernbegriffe Bevor im Folgenden auf die Besonderheiten von Open Source Software eingegangen wird, gilt es zunächst in der gebotenen Kürze einige grundlegende technische Begriffe und Abgrenzungsfragen zu klären. Bei der Darstellung und Definition der Begriffe ist zu beachten, dass aufgrund der fortschreitenden technischen Entwicklung eine exakte Erklärung des Begriffsinhalts auf diesem Gebiet nicht möglich ist. Eine Festlegung des Begriffsinhalts würde vielmehr die Gefahr bergen, dass unbeabsichtigte Schutzbereiche und -lücken entstehen50. Zunächst ist zu klären, was unter die Begriffe „Computerprogramm“ und „Software“ fällt. Beide Begriffe werden in der juristischen und in der fachfremden Literatur oft nebeneinander verwendet. Eine gesetzliche Definition existiert aus den oben angesprochenen Gründen nicht und ist folglich in den §§ 69 ff. UrhG nicht zu finden51. Da es sich bei der vorliegenden Arbeit um eine rechtswissenschaftliche Beurteilung von Software handelt, werden die Definitionen herangezogen, die sich bereits in der juristischen Praxis etabliert haben. Unter einem Computerprogramm versteht man eine Folge von Befehlen, die nach der Aufnahme in einen maschinenlesbaren Träger fähig sind zu bewirken, dass eine Maschine mit informationsverarbeitenden Fähigkeiten eine bestimmte Funktion oder Aufgabe oder ein bestimmtes Ereignis anzeigt, ausführt oder erzielt52. Diese Definition wird auch sinngemäß so in der Informatik verwendet, wonach ein Computerprogramm eine nach Re50

So auch Koch, § 1 Rn. 40. Gesetzesbegründung, BT-Drucks. 12/4022. 52 Vgl. § 1 Abs. 1 der Mustervorschriften für den urheberrechtlichen Schutz von Computersoftware der WIPO (World Intellectual Property Organisation) [im Folgenden: WIPO-Mustervorschriften]; vgl. GRUR Int. 1978, 568, 590; Koch, § 1 Rn. 42; 51

32

§ 1 Grundlagen

geln der Programmiersprache zusammengestellte Abfolge von Algorithmen ist, die den Zweck haben, mittels eines informationsverarbeitenden Geräts bestimmte Aufgaben zu erledigen53. Kern eines Computerprogramms ist der sog. Quellcode54. Der Quellcode ist eine mittels Programmiersprache verfasste, für den Fachmann lesbare Textdatei55. Aus diesem Quellenprogramm, das eine Beschreibung der zu verarbeitenden Daten und Verarbeitungsprozesse enthält, ist die Funktionsweise eines Computerprogramms für den Fachmann ersichtlich56. Der Quellcode ist jedoch noch kein ausführbares Programm, sondern eine Textdatei. Um aus dem Quellcode eine ausführbare Datei, d. h. ein ausführbares Computerprogramm zu bekommen, muss dieser Quellcode in ein Objektprogramm (in Maschinensprache) übersetzt werden57. Diese Übersetzung des Quellcodes wird mit Hilfe bestimmter Übersetzungsprogramme (sog. Compiler oder Interpreter58) vorgenommen. Der übersetzte Quellcode in Form des Objektprogramms ist dann ein lauffähiges Computerprogramm. Zentrales Ziel der Computerprogrammentwicklung ist somit das Schreiben eines Quellcodes in Programmiersprache, der die Programmstruktur festlegt. Er kann somit auch als „Bauplan“ eines Computerprogramms bezeichnet werden. Der Fachmann, der den Quellcode eines Computerprogramms kennt, ist in der Lage, die gesamte Programmierung exakt nachzuvollziehen und Änderungen vorzunehmen, d. h. durch Umprogrammierung des Quellcodes das Programm und dessen Funktionen zu verändern. Es ist daher verständlich, dass die Programmierer von „proprietäter“ Software den Quellcode der Programme weitgehend geheim halten und nicht veröffentlichen. Die alleinige Kenntnis des Quellcodes ermöglicht ihnen, ihre Software exklusiv zu vertreiben und gibt ihnen Investitionssicherheit in Weiterentwicklungen, die auf der Software aufbauen. auch der BGH hat sich diese Definition zu eigen gemacht, BGH NJW 1986, S. 192 (196). 53 Brockhaus (CIT), S. 729; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 7. 54 Engl.: source code – Quelltext, Quellprogramm. 55 Brockhaus (CIT), S. 729; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 7. 56 Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 9. 57 Brockhaus (CIT), S. 729; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 9. 58 Compiler oder Interpreter übersetzen den Quellcode in die Maschinensprache. Der Unterschied zwischen beiden liegt darin, dass der Compiler den Quellcode einmalig und dauerhaft übersetzt, wohingegen der Interpreter keine dauerhafte Übersetzung vornimmt, sondern einzelne Anweisungen des Quellcodes übersetzt und unmittelbar ausführt. Da bei der Benutzung eines Interpreters die übersetzten Anweisungen nicht gespeichert werden, muss bei jedem erneuten Ablauf eine Übersetzung erfolgen. In der Regel werden daher Compiler verwendet. (Brockhaus (CIT), S. 729, 182, 472).

V. Definition der Kernbegriffe

33

Unter dem Begriff Software59 oder Computersoftware versteht man hingegen die gesamte Programmausstattung, bestehend aus Computerprogramm, Begleitmaterial und Programmbeschreibung60. Unter einer Programmbeschreibung versteht man eine vollständig prozedurale Darstellung in sprachlicher, schematischer oder in anderer Form, deren Angaben ausreichend sind, um eine Folge von Befehlen festzulegen, die ein ihr entsprechendes Computerprogramm darstellen61. Das Begleitmaterial umfasst alle Unterlagen, die dazu bestimmt oder geeignet sind, das Verständnis oder die Anwendung eines Computerprogramms zu fördern62. Software wird somit eher als Oberbegriff verwendet, der das Computerprogramm als solches mit einschließt. Open Source Software oder Free Software unterscheidet sich technisch, d. h. von der Programmierung her nicht von anderer Software. Die Bezeichnung der Software als „Open Source“ bezieht sich somit nicht auf eine bestimmte Art der Softwareanwendung oder auf spezifische Einsatzbereiche63. Als Open Source Software oder Free Software bezeichnet man vielmehr eine Software, deren Quellcode frei und allgemein zugänglich ist und durch Verwendung bestimmter Lizenzvereinbarungen eine weitgehende Übertragung der Verwertungsrechte erfolgt. Damit haben Nutzer und Programmierer die Möglichkeit, das Programm zu kopieren, zu ändern, weiterzuentwickeln und Entwicklungen weiterzuverbreiten64. Durch das offene Lizenzmodell werden somit alle Akteure und Entwicklungszyklen eines SoftwareProduktes vernetzt. Dabei beziehen sich die Bezeichnungen „free“ und „open“ nicht in erster Linie auf den Preis, sondern meinen die Freiheit des Nutzers, die Software zu benutzen, zu kopieren, sie zu vertreiben, zu studieren, in Kenntnis des Quellcodes zu verändern und zu verbessern65. Die freie Software unterscheidet sich somit „nur“ in dem Umfang der eingeräumten Verwertungsrechte von „proprietärer“ Software. Die beiden unterschiedlichen Bezeichnungen „Open Source Software“ und „Free Software“ sind das Ergebnis einer inhaltlichen Auseinanderset59

Dt.: weiche Ware. Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 8; Koch, § 1 Rn. 45; § 1 Abs. 4 der WIPO-Mustervorschriften. 61 Koch, § 1 Rn. 43. 62 Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 8. 63 Koch, § 1 Rn. 49. 64 Brockhaus (CIT), S. 657; Beck EDV-Berater, Computerlexikon S. 617; Koch, § 1 Rn. 49; ders. in CR 2000, S. 273. 65 „Die Definition Freier Software“ der FSF abgerufen unter: http://www.gnu. org/philosophy/free-sw.de.html; „The Open Source-Definition“ der OSI abgerufen unter: http://www.opensource.org/docs/definition.php. 60

3 Teupen

34

§ 1 Grundlagen

zung zwischen verschiedenen Lagern der Programmierer Freier Software über die Beweggründe, Software als „Freie“ Software der Allgemeinheit zur Verfügung zu stellen. Die Bewegung teilt sich im Wesentlichen in zwei große Lager, die Open Source Initiative (OSI) und die Free Software Foundation (FSF)66. Die beitragsfreie, gemeinnützige FSF wurde 1985 mit dem Ziel gegründet, für Free Software zu werben und ihre Verwendung zu fördern67. Kern der Grundidee der FSF ist dabei der Begriff der „Freiheit“. Der Begriff „Freiheit“, dem nach Ansicht der FSF ethisch-philosophische, soziale und politische Bedeutung zukommt, bezeichnet die Freiheit des Nutzers, das Programm zu benutzen, in Kenntnis des Quellcodes dessen Funktionen zu verstehen und es anzupassen, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit zur Verfügung zu stellen. Die OSI wurde am 3. Februar 1998 im kalifornischen Palo Alto gegründet68. Die „non-profit-corporation“ OSI verfolgt das Ziel, ihre Open SourceDefinition im Interesse der Open Source-Bewegung zu verbreiten und weiter zu fördern69. Der Begriff „Open Source Software“ wurde offiziell auf der Gründungssitzung der Open Source-Initiative eingeführt. Die Grundidee hinter der Definition der OSI besteht darin, dass durch die weitgehenden Rechte des Nutzers die Entwicklung einer Software beschleunigt und vorangetrieben wird und somit wesentlich schneller als bei konventioneller Software verläuft, was letztlich auch zu einer besseren Software führt70. Es handelt bei „Open Source“ danach eher um eine besondere Entwicklungsmethode von Software. Die verschiedenen Bezeichnungen „Open Source Software“ und „Free Software“ sind somit alleine ein Resultat der Auseinandersetzung über die Begrifflichkeit und die damit verbundenen Grundintentionen in Bezug auf Freie Software71. Da die Definitionen inhaltlich im Wesentlichen übereinstimmen und somit die Anforderungen an Freie Software identisch sind, können die Begriffe „Open Source Software“ und „Free Software“ parallel verwendet werden72. Im Folgenden werden somit die Begriffe „Open Source Software“, „Free Software“ und „Freie Software“ gleichbedeutend gebraucht. 66 Jaeger/Metzger, S. 3 f.; Internetauftritt der Organisationen: www.opensource. org (OSI), www.fsf.org (FSF). 67 Stallman, S. 21. 68 Jaeger/Metzger, S. 4. 69 Vgl.: http://www.opensource.org. 70 Ebd. 71 Ausführliche Darstellung der Entwicklungen von FSF und OSI und Bedeutung der Terminologie: Grassmuck, S. 230 ff. 72 So auch Jaeger/Metzger, S. 4.

V. Definition der Kernbegriffe

35

Nicht zu verwechseln ist Freie Software mit Freeware oder Public Domain Software. Unter Freeware versteht man Software, die zwar kostenlos verbreitet wird, bei der der Quellcode aber nicht offen gelegt wird und somit keine weitergehenden Verwertungsrechte auf den Nutzer übertragen werden73. Ziel der Verbreitung von Software als Freeware ist meistens eine weite Verbreitung der Software zu erreichen, um entweder auf andere Produkte des Autors aufmerksam zumachen oder die eigene Marktposition zu stärken74. Bei Public Domain Software handelt es sich um ein Resultat des amerikanischen Rechtssystems, wonach die Entwicklung von Computerprogrammen, die mit Hilfe amerikanischen Steuermitteln finanziert wurden, unter der Bedingung zu erfolgen hatte, dass die fertigen Computerprogramme der Allgemeinheit als „public domain“75 zur Verfügung stehen76. Die Regelung zwingt Urheber zu einem vollständigen Verzicht auf ihre Urheberrechte, was dazu führt, dass auch als Resultat von Forschungsprojekten entwickelte Expertensysteme und anspruchsvolle Software von jedermann in beliebiger Form genutzt werden kann77. Eine entsprechende Regelung, die den vollständigen Verzicht auf die Urheberrechte vorsieht, wäre im deutschen Rechtsraum nicht möglich, da aus dem Grundsatz der Unübertragbarkeit des Urheberrechts gem. § 29 I UrhG auch die Unverzichtbarkeit abgeleitet wird78. Darüber hinaus bestehen weitere besondere Vertriebsformen von Software, wie z. B. Shareware oder Shared Source Software, deren Darstellung an dieser Stelle aufgrund der fehlenden Relevanz für die hier zu klärenden Rechtsfragen von Open Source Software nicht erfolgt79.

73 74 75 76 77 78 79 3*

Brockhaus (CIT), S. 370; Marly, Rn. 282. Brockhaus (CIT), S. 370; Jaeger/Metzger, S. 6. Dt.: öffentliches Eigentum. Marly, Rn. 284; Jaeger/Metzger, S. 5. Marly, Rn. 284; Jaeger/Metzger, S. 5. Wandtke/Bullinger/Block, § 29 Rn. 15. Vgl. hierzu die kurze Darstellung bei Jaeger/Metzger, S. 6 f.

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software I. Historische Entwicklung von Open Source Software An der Anzahl der Publikationen zum Thema „Freie Software“ in den Medien und an der öffentlichen Aufmerksamkeit gemessen, erscheint Freie Software als Phänomen, das sich erst in den 90er Jahren entwickelt hat.1 Man bekommt den Eindruck, dass es sich bei Freier Software um eine völlig neue Form von Softwarelizensierung und Softwareverbreitung handelt. Im Zusammenhang mit diesem Phänomen fällt zumeist das Schlagwort „Linux2“. Doch Linux ist lediglich das Ergebnis einer Entwicklung, deren Anfänge weit vor den 90er Jahren liegen. Mit dem Satz „Am Anfang war alle Software frei.“ beschreibt der der Präsident der FSF Europe Georg Greve3 die frühen Tage der Computerentwicklung. Mitte der 50er Jahren unterschied man nicht zwischen Hard- und Software. Die Computerindustrie setzte sich alleine aus Hardwareunternehmen (dominierend waren zu der Zeit IBM, DEC, HP und Data General) zusammen, die ihre Hardware nur mit implementierter Software anboten. Man erkannte zu diesem Zeitpunkt noch nicht den eigenen Wert von Software, sondern betrachtete deren „kostenlose“ und „freie“ Weitergabe als Notwendigkeit, um die teure Hardware überhaupt verkaufen zu können4. Kunden hatten nur die Möglichkeit, Hardware in einem Paket zu kaufen, das Peripheriegeräte und Software sowie die damit verbundene Wartung einschloss5. Software stellte zu diesem Zeitpunkt noch kein eigenständiges wirtschaftliches Gut dar6. Die Hersteller lieferten die Rechner mit umfangreichen Gebrauchsinformationen zur Software aus, damit die Kunden ihre Rechner nach Bedarf programmieren und ihren Bedürfnissen anpassen 1 Der Autor verzichtet bewusst auf eine ausführliche Darstellung aller Einzelheiten der historischen Entwicklung. Zur Erleichterung des Verständnisses des Phänomens der Freien Software werden die wichtigsten Ereignisse dargestellt. 2 Linux ist ein Unix-ähnliches Betriebssystem für Personalcomputer und Workstations und wurde von dem Finnen Linus Torvalds entwickelt. 3 Vorwort bei Grassmuck, S. 13. 4 Rosenberg, S. 4. 5 Grassmuck, S. 202. 6 Jaeger/Metzger, S. 8.

I. Historische Entwicklung von Open Source Software

37

konnten. Somit war die Software anfänglich „quelloffen“ und wurde frei ausgetauscht. Die Unternehmen selbst förderten sogar diese Anpassungsund Programmierprozesse dadurch, dass sie User-Groups7 gründeten und somit die Selbstorganisationen der Nutzer vorantrieben und koordinierten8. Die Quellcodes von Software zirkulierten uneingeschränkt in Fach- und Amateurzeitschriften. Softwareprogrammierer entwickelten die Software weiter und gaben ihre verbesserten Versionen an die Nutzergemeinde zurück. Zu dieser Zeit herrschte augenscheinlich ein Zustand, den sich heute Anhänger der Freien Software wohl zurückwünschen würden. Das Verbreiten von Hardware und quelloffener Software als Gesamtheit und die Unterstützung bei der Anpassung der Software an die Rechnersysteme der Nutzer durch die Marktführer hatte jedoch den vordringlichen Zweck, die Kunden an die Unternehmen und deren Produkte zu binden9. Da die Anpassung und Beherrschung der Software für die Kunden zeitaufwendig und mit Kosten verbunden war, war aus Sicht der Kunden ein Wechsel zu anderen Herstellern zu umständlich und zu teuer. Somit hatten die Hersteller die Möglichkeit, bei gewonnenen Kunden die Preise mit der Zeit deutlich zu erhöhen. Neukunden wurden dagegen mit Dumpingpreisen gelockt. Ziel der Verbreitung von Hard- und Software als Paket und die Mitlieferung der gewünschten Informationen war somit die Kundenbindung und die Möglichkeit, eine flexible Preispolitik zu betreiben10. Die Situation änderte sich erst, als amerikanische Behörden die Marktsituation kartellrechtlich überprüften. Ein vom amerikanischen Justizministerium eingeleitetes Kartellverfahren11 gegen IBM führte schließlich dazu, dass IBM 1969 „freiwillig“ die Bündelung von Hard- und Software aufgab und somit der Weg für einen separaten Softwaremarkt frei gemacht wurde12. Erst diese Entkopplungsmaßnahme von IBM machte es möglich, dass ein lukrativer Markt für Software entstehen konnte13. Sie war notwen7 Dt.: Benutzergruppe – ein Zusammenschluss von Personen aufgrund eines gemeinsamen Interesses an einem bestimmten Computersystem oder -programm, das dazu dient, Erfahrungen und Gedanken darüber auszutauschen sowie Neueinsteiger zu unterstützen. 8 IBM gründete beispielsweise 1955 eine solche Benutzergruppe, die noch heute unter: www.share.org aktiv ist. 9 Rosenberg, S. 9. 10 Mühlbauer, Die Resozialisierung des Giganten, Telepolis-Aufsatz: http://www. heise.de/tp/deutsch/inhalt/co/8778/1.html. 11 IBM mit einem damaligen Marktanteil von ungefähr 70 % und ca. 7 Mrd. Dollar Umsatz sollte nach Vorstellungen des Ministeriums in verschiedene Unternehmen aufgeteilt werden. Das Verfahren wurde unter der Regierung Reagan 1981 eingestellt. 12 Grassmuck, S. 203; Pres, S. 5; Jaeger/Metzger, S. 9, mit weiterem Nachweis. 13 Mühlbauer, ebd.; Grassmuck, S. 203.

38

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

dige Voraussetzung für das Entstehen der Softwareindustrie. Software wurde nunmehr als Ware gehandelt und „proprietär“ vermarktet. Ebenfalls in den 60er Jahren begann die Entwicklung von Unix14-Betriebssystemen15. Das Entstehen von Unix-Betriebssystemen und die Entwicklung Freier Software ist eng miteinander verbunden. Die erste UnixVersion wurde 1969 in den Bell Laboratorien der amerikanischen Telefongesellschaft AT&T von Ken Thompson entwickelt16. Diese Version entstand in Anlehnung an das Großrechnerbetriebssystem MULTICS17, das 1964 vom MIT18, General Electric und AT&T entwickelt worden war19. Damit dieses Betriebssystem auf andere Rechner portiert werden konnte, nutzte Thompson die zu diesem Zeitpunkt neue Computersprache C, um Unix damit neu zu schreiben20. Es gelang ihm und Dennis Ritchie 1973, die erste portierbare Unix-Version zu programmieren21. Unix wurde zum Standardbetriebssystem von AT&T. Da das Unternehmen auf dem amerikanischen staatlich regulierten Telefonmarkt eine Monopolstellung ausübte, war es dem Unternehmen durch ein Urteil untersagt, in anderen Wirtschaftsspaten und somit im Softwaremarkt tätig zu werden22. Dies hatte zur Folge, dass AT&T das Betriebssystem Unix nicht vermarkten konnte. Da AT&T an einer Weiterentwicklung des Betriebssystems für eigene Zwecke interessiert war, wurde Unix bis 1979 kostenlos an die Universitäten weitergeben23. Die Universitäten erhielten zudem den Quellcode mit dem Ziel, Weiterentwicklungen und Verbesserungen an dem Betriebssystem vornehmen zu können24. AT&T verlangte im Gegenzug, Ergebnisse der Weiterentwicklungen dem Unternehmen mitzuteilen und zur Verfügung zu stellen25. Folge dieser Maßnahme war die 14 Ursprünglich UNICS, Abk. für Uniplexed Information and Computing System, dt. „nicht multiplextes (vielseitiges) Informations- und Rechnersystem“. Unix ist ein multitasking- und multiuser-fähiges Betriebssystem für Rechenanlagen, das heute vielseitig auf Geräten vom Personalcomputer bis zu Großrechnern eingesetzt wird. Es gibt verschiedene nur teilweise kompatible Versionen des Betriebssystems (sog. Unix-Derivate), jedoch wird Unix in seiner Grundstruktur zunehmend zum Standard für Betriebssysteme. 15 Brockhaus (CIT), S. 924. 16 Jaeger/Metzger, S. 9; Grassmuck, S. 211; Brockhaus (CIT), S. 924. 17 Abk. für Multiplexed Information and Computing System, dt. „vielfaches Informations- und Rechnersystem“. 18 Massachusetts Institute of Technology. 19 Grassmuck, S. 211 f.; Brockhaus (CIT), S. 924. 20 Grassmuck, S. 212. 21 Brockhaus (CIT), S. 924. 22 Rosenberg, S. 30. 23 Brockhaus (CIT), S. 924. 24 Grassmuck, S. 212. 25 Brockhaus (CIT), S. 924.

I. Historische Entwicklung von Open Source Software

39

stetige Verbesserung des Betriebsystems Unix durch die freiwillige Entwicklungsarbeit der Benutzer an den Universitäten, was auch zu einer schnellen Verbreitung des Betriebssystems in Bereichen außerhalb der Universität geführt hat26. Es entstand eine Zusammenarbeit zwischen der „Unix-Community“ und den Forschern der Bell Laboratories, die ihr Wissen in Newsgroups gegenseitig austauschten. Die kalifornische Universität in Berkeley etablierte sich mit der Zeit zum akademischen Zentrum der Unix-Forschung. Am Ende vieler Neuerungen und Weiterentwicklungen stand schließlich 1977 die erste Berkeley Software Distribution (BSD), ein Derivat des Betriebssystems Unix27. Das Unternehmen AT&T wurde 1979 infolge eines Gerichtsurteils in mehrere Unternehmen aufgeteilt28. Es entstanden verschiedene Entwicklungszweige von Unix-Derivaten29. Auch kommerzielle Softwarehersteller (z. B. Microsoft, Sun Microsystems) begannen Unix-Derivate zu programmieren und zu verbreiten, was vor allem daran lag, dass die angestellten Programmierer bereits während ihres Universitätsstudiums viel Erfahrung mit dem Betriebssystem sammeln konnten30. Bei allen diesen Unix-Derivaten handelte es sich letztlich mehr oder minder um kommerzielle Verwertungen des markenrechtlich geschützten Unix. „Frei“ im Sinne der Free Software-Definition waren diese Unix-Versionen nicht. Vielmehr nahm dadurch, dass infolge der „Zerschlagung“ von AT&T keine kartellrechtlichen Hindernisse mehr bestanden, die Kommerzialisierung von Software mehr und mehr zu31. Die Entwicklung führte dazu, dass Anfang der 80er Jahre nahezu alle Software „proprietär“ war32. Freie Software hat ihren eigentlichen Ursprung in dem von Richard Stallman 1984 gegründetem GNU33-Projekt. Richard Stallman begann 1971 seine akademische Laufbahn am Labor für Künstliche Intelligenz des MIT34. In den 70er Jahren herrschten am MIT ideale Bedingungen für Programmierer wie Stallman. Der Tausch von geschriebenen Programmen sowie die gegenseitige Unterstützung bei der Programmierung machten die Beliebtheit des MIT bei jungen Programmierern aus35. Niemand kam dort 26

Brockhaus (CIT), S. 212. Grassmuck, S. 214. 28 Brockhaus (CIT), S. 924. 29 Grassmuck, S. 215; vgl. Einzelheiten der Entwicklung: Brockhaus (CIT), S. 924. 30 Brockhaus (CIT), S. 924. 31 Vgl. Einzelheiten der Entwicklung: Grassmuck, S. 214 ff.; Brockhaus (CIT), S. 924 f. 32 Grassmuck, S. 221. 33 GNU ist ein Akronym für „GNU is Not Unix“; vgl.: Stallman, S. 17. 34 Stallman, S. 15. 27

40

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

auf die Idee, seine Ergebnisse zu sichern und vor Kollegen geheim zu halten, sondern war an einer stetigen Weiterentwicklung auch eigener Ergebnisse durch andere Programmierer interessiert36. Software war für jedermann frei zugänglich. Dieser Zustand der „offenen Systeme“ hielt jedoch nicht dauerhaft an. Mit den Jahren wurden Rechnersysteme zunehmend mit Passwörtern versehen, was zur Behinderung des ungehinderten Datenflusses zwischen den Nutzern führte37. Der freie Informationsaustausch wurde zunehmend reglementiert. Programmierer wurden aus den Forschungsabteilungen von Unternehmen abgeworben und arbeiteten nunmehr an kommerzieller Software. Als Folge gingen auch Forschungseinrichtungen vermehrt zur Nutzung von kommerzieller Software über. Ein Schlüsselerlebnis38 mit der Benutzung „proprietärer“ Software war schließlich der Grund dafür, dass Richard Stallman das GNU-Projekt startete. Am MIT benutzte man zu der Zeit Xerox-Netzwerkdrucker. Bei der Benutzung traten jedoch regelmäßig Probleme auf, da aufgrund der installierten Druckertreiber39 der Druckerstatus am PC nicht direkt angezeigt wurde, was dazu führt, dass Probleme wie z. B. ein Papierstau oder fehlendes Papier erst sichtbar wurden, wenn man den Druckerraum betrat und das Problem am Drucker feststellen konnte. Stallman wollte das Problem dadurch beheben, dass er eine Datei in die Druckertreiber einfügte, die es möglich machte, sich den Druckerstatus am PC anzeigen zu lassen. Der dazu benötigte Quellcode der Druckertreiber wurde ihm auf seine Bitte hin jedoch von Xerox nicht zur Verfügung gestellt. Es war Stallman somit nicht möglich, die durchaus sinnvolle Veränderung der Software vorzunehmen. Im Vergleich zu früheren Zeiten, in denen dies problemlos möglich gewesen wäre, standen die Restriktionen der „proprietären“ Softwareindustrie dem nun entgegen40. Stallman wollte sich mit diesen Veränderungen hin zur „proprietärer“ Software nicht zufrieden geben und suchte nach einer Möglichkeit, die früheren Verhältnisse des freien Informationsflusses und der freien Verfügbarkeit von Software wieder herzustellen. Mit diesem Ziel vor Augen gründete er das GNU-Projekt. Stallman schrieb ein Betriebssystem, das kompatibel zu allen Unix Programmen sein sollte und keine Zeilen des „geschützten“ Unix-Betriebssystems enthalten durfte41. Daher ist auch die Bezeichnung als „GNU (= GNU 35

Grassmuck, S. 217 f. Rosenberg, S. 8. 37 Rosenberg, S. 8; Stallman, S. 15 f.; Grassmuck, S. 219 f. 38 Grassmuck, S. 222. 39 Treiber sind Dateien, die zur Steuerung eines Geräts (z. B. Drucker, Scanner) installiert werden, um das Betriebssystem an die Nutzung dieses Geräts anzupassen und die Kommunikation zwischen Gerät und dem Betriebssystem herzustellen. 40 Rosenberg, S. 8. 41 Stallman, S. 18 ff.; Grassmuck, S. 222. 36

I. Historische Entwicklung von Open Source Software

41

is Not Unix)“-Projekt zu erklären. Er kündigte sein Vorhaben in Unix-Usergroups an und bat um Mithilfe und Unterstützung für sein Vorhaben42. Mit steigender Nachfrage nach dem neuen Betriebssystem stiegen auch die Kosten für die Durchführung des Projekts, dem in der Zwischenzeit weitere Programmierer beigetreten waren43. Um auch in Zukunft die Finanzierung sicherzustellen, gründete man 1985 die FSF. Die Organisation übernahm die Distribution und den Verkauf von GNU-Software sowie Handbüchern und verwaltete Sach- und Geldspenden44. Aus den Einnahmen konnten dann die Programmierer des GNU-Projekts bezahlt werden45. Damit das GNU-Projekt und die zugrunde liegende Idee der Freien Software nicht der Gefahr der Kommerzialisierung ausgesetzt waren, bedurfte es eines geeigneten Instruments, das die freie Softwareverbreitung auch für die Zukunft sicherstellte und die Möglichkeit ausschloss, Freie Software zu „proprietärer“ Software zu machen46. Stallman entschied sich für die „Copyleft“-Methode. Er versteht unter „Copyleft“ eine Methode, die Möglichkeiten des Copyright-Law in der Form nutzt, dass sie im Wege von Lizenzvereinbarungen die (Nutzungs-)Rechte an Software freigibt und von den Nutzern verlangt, dass sie alle Modifikationen an der Freien Software wiederum als Freie Software unter den selben Bedingungen zur Verfügung stellen47. Auch Stallman sah, dass es verschiedene Möglichkeiten gab, das Grundmodell des „Copyleft“ lizenzrechtlich auszugestalten und dass eine Konkretisierung notwenig war48. Mit dem amerikanischen Rechtsprofessor Eben Moglen (Universität Columbia) entwickelte Stallman 1989 die GNU General Public License (GPL)49, die konkrete Regelungen über die Nutzung und Verbreitung Freier Software enthielt50. Damit gab es erstmals eine „vorformulierte“ Lizenz für Freie Software. Die Entwicklung des GNU-Systems war 1990 nahezu abgeschlossen51. Zur Vollständigkeit fehlte dem Betriebssystem zu diesem Zeitpunkt noch der Kernel52, dessen Programmierung Stallman zum Schluss vornehmen 42 43 44 45 46 47 48 49

Grassmuck, S. 223. Stallman, S. 21. Stallman, S. 21. Grassmuck, S. 223. Stallman, S. 20. Stallman, S. 20 f., 89 f. Stallman, S. 89. Die GPL und ihre Regelungen wird im Folgenden noch ausführlich bespro-

chen. 50

Stallman, S. 21, 89 f.; Rosenberg, S. 11; Grassmuck, S. 226. Stallman, S. 25. 52 Dt.: Kern – zentrale Teil eines Betriebssystems, in dem alle essentiellen Funktionen des Systems zusammengefasst sind. 51

42

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

wollte53. Stallman nannte den Kernel „Hurd“. Um den Hurd solide und vollständig zu programmieren, benötigten die GNU-Programmierer mehrer Jahre. Zur gleichen Zeit – Anfang der 90er Jahre – setzte die Universität Helsinki Unix als Betriebssystem ein. An der Universität studierte zu der Zeit der Finne Linus Torvalds54. Er war von dem Betriebssystem begeistert. Vor allem war er davon fasziniert, auf welche Weise Unix entwickelt wurde und wie sich die Masse der Unix-Anhänger für die „Freiheit“ des Systems einsetzte. Sein Interesse wurde durch ein Ereignis im Jahr 1991 verstärkt. Torvalds besuchte einen Vortrag an der Technischen Universität von Helsinki. Der Referent war Richard Stallman, der „Gott der freien Softwarebewegung“, wie Torvalds ihn bezeichnet. Stallman referierte über Unix, das GNU-Projekt sowie die Aufgabe und Ziele der FSF. Linus Torvalds installierte auf seinem Rechner das von dem Amsterdamer Professor Andrew Tanenbaum programmierte UNIX-Derivat namens Minix. Torvalds war es jedoch mit der Terminal-Emulation55 des MinixSystems nicht möglich, sich in den Universitätsrechner einzuloggen oder online zu arbeiten, so dass er sich entschied, selbst ein Terminal-Emulationsprogramm zu schreiben. Er fügte mit der Zeit immer mehr Zusatzfunktionen in sein System ein, sodass eine Plattform für ein Betriebssystem entstand. Torvalds sah sein Projekt nicht mehr als Terminal-Emulator, sondern ihm wurde klar, dass ein Betriebssystem entstand. Torvalds arbeitet nun daran, Minix durch sein System ersetzen zu können. Bei der Programmierung seines Betriebssystems orientierte er sich an den Eigenschaften des UnixSystems und nutzte zur Programmierung GNU-Softwarekomponenten56. Die Erste Version (0.01.) von Linux „veröffentlichte“ Torvalds am 17. September 1991. Es folgten stetige Verbesserungen des anfänglich noch unzuverlässigen Systems, an deren Ende die Veröffentlichungen der aktuellen Versionen standen. Er stellte die jeweils aktuellen Versionen und den dazugehörigen Quelltext ins Netz und lud die Nutzer zur Mitarbeit an seinem Projekt ein. Linus Torvalds wollte sein Linux keinesfalls zu „proprietärer“ Software machen, sondern seine Software der Nutzergemeinde kostenlos zur Verfügung stellen und somit auch die Möglichkeit nutzen, von 53

Rosenberg, S. 12. Ausführliche Darstellung der Linux-Entwicklungsgeschichte bei Torvalds, S. 67 ff. 55 Unter einer Terminal-Emulation versteht man die Nachbildung eines Terminals mithilfe von Software. Sie ermöglicht, einen Rechner als Terminal erscheinen zu lassen, mit dem dann auf einen Großrechner oder Mehrbenutzersystem (z. B. Mailbox) zugegriffen werden kann. Es wird somit Datenaustausch mit anderen Systemen ermöglicht. 56 Einzelheiten dazu bei Torvalds, S. 67 ff.; Rosenberg, S. 12. 54

II. Ökonomische Bedeutung von Open Source Software

43

Verbesserungen durch die Nutzer zu profitieren. Ein weitere wichtiger Grund, der Torvalds dazu bewogen hat, sein Linux als Freie Software zu verbreiten, war der Umstand, dass er für die Programmierung von Linux seinerseits Freie Softwarekomponenten nutzen konnte. Da er aber Einfluss auf die zukünftige Entwicklung von Linux nehmen und die Kontrolle über den Quellcode sowie über Veränderungen nicht aufgeben wollte, entschied sich Torvalds im Januar 1992 dafür, Linux unter die GPL zu stellen. Die Lizenzierung von Linux als Freie Software sicherte die hohe Dynamik bei der Verbreitung und Weiterentwicklung des Systems, da sich zahllose Programmierer weiter daran beteiligten und keine Möglichkeit bestand, das Projekt proprietär zu machen. Das war und ist wohl der entscheidende Faktor für den Erfolg von Linux. Wie bereits dargestellt, arbeiteten Stallman und seine GNU-Programmierer an Hurd, dem Kernel für das GNU-System. Als Linus Torvalds 1991 seinen Unix-kompatiblen Linux-Kernel veröffentlichte, kam er damit einer funktionstüchtigen Hurd-Version zuvor. Somit entschied sich Stallman 1992 für die Kombination des Linux-Kernels mit dem GNU System57. Durch diese Kombination entstand 1992 das erste vollständig funktionierende freie Betriebssystem mit der Bezeichnung GNU/Linux58. Heute gibt es schätzungsweise mehr als 30 Millionen Installationen von GNU/LinuxBetriebssystemen, sowohl im privaten Bereich wie auch in Verwaltung und Wirtschaft. Ausgehend von diesem Softwareprojekt, das erstmalig komplett als Freie Software lizenziert war, entwickelten sich weitere Projekte, die mit der Zeit alle wesentlichen Funktionen eines Rechnersystems durch die Verwendung Freier Software zugänglich machten59.

II. Ökonomische Bedeutung von Open Source Software „Open Source Software setzt sich mehr und mehr gegen proprietäre Software durch. Sie eröffnet die Möglichkeit, stabilere und den jeweiligen Bedürfnissen der Benutzer besser angepasste Produkte zu erhalten. Insbesondere aber kommt diesen in Fragen der IT-Sicherheit und der Interoperabilität vor allem in sicherheitsrelevanten Bereichen zunehmende Bedeutung zu.“

Dieses Zitat stammt nicht aus einem Werbeprospekt eines Open Source Software-Distributors, sondern ist eine Feststellung aus einem Antrag von Abgeordneten des Deutschen Bundestages, der sich mit der deutschen Wirt57 58 59

Stallman, S. 26. Stallman, S. 26; Rosenberg, S: 12 f.; Grassmuck, S. 226. Jaeger/Metzger, S. 13.

44

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

schaft in der Informationsgesellschaft befasst60. Und es ist wahr: Freie Software scheint in vielen Produktbereichen zu einer ernsthaften Konkurrenz von kommerzieller Software zu werden. So erwartet der CEO von Microsoft Steve Ballmer durch die rasante Zunahme von Linux kurz- und mittelfristig ernsthafte Herausforderungen für den Softwarekonzern und sein Betriebssystem61. Das zeigt, dass Open Source Software nicht nur von den Anwendern sondern auch von den großen Softwareunternehmen als ernste Alternative zu kommerziellen Softwarelösungen in Betracht gezogen wird. Das wird zum einen dazu führen, dass der Druck auf die kommerziellen Anbieter von Software weiter steigen wird, zum anderen bietet die Entwicklung auch für die Unternehmen eine Chance, sich am Markt neu auszurichten und neue Betätigungsfelder zu erschließen. Dies spiegelt sich auch in den wachsenden Marktanteilen von Open Source Software wider. Dabei soll in diesem Zusammenhang die Darstellung einiger Zahlen in Bezug auf die bekanntesten Open Source Projekte genügen62. Die bekanntesten Open Source Software-Projekte sind auf der Ebene der Betriebssysteme GNU/ Linux und im Bereich der Web-Server das Projekt Apache63. Das derzeit wohl erfolgreichste Open Source-Produkt ist Apache64. Seit 1996 dominiert Apache den Markt der Web-Server und hatte im September 2002 einen Marktanteil (bei über 10 Millionen Servern) von ca. 66%, wohingegen Microsoft einen Marktanteil von ca. 25% erzielt65. Bei Serversoftware liegt das Betriebssystem GNU/Linux immerhin mit einem Marktanteil von ca. 30% hinter Windows mit ca. 50%. Bei Computer-Betriebssystemen liegt Microsoft mit einem Marktanteil von ca. 93,8% dagegen deutlich vor Linux mit 2,8%66. Dies zeigt, dass Linux sich als alternative Desktopvariante auf dem Massenmarkt bisher noch nicht etablieren konnte67.

60

BT-Drucks. 14/5246. n-tv, 05. Juni 2003, www.n-tv.de/3164801.html. 62 Eine ausführliche Darstellung der Freien Software anhand von Zahlen findet sich bei Wheeler: „Why Open Source Software/Free Software? Look at the Numbers“! 63 Eine Auflistung der wichtigsten Open Source Produkte findet sich in der Floss-Studie 2003 (Teil 3), S. 16 und bei Nüttgens/Tesei, S. 10 ff. 64 Apache ist ein freier Webserver der Apache Software Foundation (www. apache.org). Der weltweit am meisten eingesetzte Web-Server läuft unter verschiedenen Betriebssystemen, so z. B. unter Unix oder Windows NT (Brockhaus [CIT], S. 59). 65 Wheeler, S. 3; Floss-Studie 2002 (Teil 3), S. 16; Köppen/Nüttgens, Open Source: Strategien für die Beratung, S. 1. 66 Berliner-Zeitung vom 09. Oktober 2003. 67 So auch Rosenberg, S. 71. 61

II. Ökonomische Bedeutung von Open Source Software

45

1. Open Source Software in der Wirtschaft a) Vorteile von Open Source Software Wirtschaftlich betrachtet bietet das Entwicklungs- und Lizenzierungsmodell der Freien Software für Unternehmen wie für den Kunden attraktive Betätigungsfelder. Für Unternehmen sind die Markteintrittsschranken in den Freien Softwaremarkt sehr gering. Zentrales Erfolgskriterium ist das Beschaffen von Wissen und Können von Programmierern, die Erfahrung in diesem Segment haben. Man findet ein Entwicklungsumfeld vor, in dem bereits eine Breite freier Softwarelösungen vorhanden ist und kann somit Investitionskosten geringer halten, indem man beispielsweise bei der Entwicklungsarbeit auf bestehende freie Softwarekomponenten zurückgreifen kann. Trotz geringerer Investitionskosten führen schnellere Produktentwicklungen im Open Source-Umfeld zu hohen Innovationsraten68. Auf der anderen Seite bietet Open Source Software auch für den Anwender Vorteile gegenüber kommerzieller Software. So ist die Open Source Software im Einsatz von höherer Stabilität und Sicherheit. Das liegt zum einen daran, dass durch die Offenlegung des Quellcodes frühzeitig Sicherheits- oder Funktionslücken erkennbar werden und beseitigt werden können. Aufgrund der großen Anzahl von Open Source-Programmierern und der vernetzten Art der Softwareentwicklung ist eine Freie Software automatisch einer höheren Kontrolle ausgesetzt, die dazu führt, dass Fehlfunktionen auf geringerem Niveau gehalten werden können69. Die intensive Kontrolle und Verbesserung der Software führt zu Qualitätssteigerung und Funktionserweiterung des einzelnen Produkts. Ein anderes zentrales Kriterium für den Einsatz Freier Software ist die Sicherheit. Die Transparenz des Quellcodes und die gute Vernetzung der Open Source-Programmierer führt dazu, dass Sicherheitsschwächen durch eine Umprogrammierung schnell beseitigt werden können. Die hohe oftmals „beschworene“ Stabilität von Open Source Software liegt aber sicherlich auch zum Teil daran, dass derzeit eher kommerzielle Software das Ziel von Attacken geübter Programmierer ist, die damit die Mängel kommerzieller Software aufzeigen wollen. Weiterhin kommt dem Anwender die transparente Entwicklungsweise von Open Source Software entgegen. Durch die Offenlegung der Entwicklungsergebnisse und der einzelnen Programmierschritte und die folgende Freigabe der Programmversionen sind Neuerungen und Folgeversionen schnell verfügbar. Auch hat der Anwender die Möglichkeit, selbst oder durch Dritte Änderungen an der Software vorzunehmen und sie so an seine Systemumgebung konkret anzupassen. Die offene Entwicklungsweise und die Anpassungsfähigkeit Freier 68 69

Floss-Studie 2002 (Teil 3), S. 37; Rosenberg, S. 42. Köppen/Nüttgens, Open Source: Strategien für die Beratung, S. 1.

46

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

Softwareprojekte erhöhen somit die Chance von Einzellösungen. Der vermehrte Einsatz von Open Source Software reduziert ferner die Abhängigkeit von großen Softwareunternehmen. Der Anwender kann sich vielmehr sein System aus den verschiedenen freien Softwarekomponenten individuell zusammenstellen. Einer der entscheidenden Vorteile von Open Source Software ist sicherlich der Kostenvorteil. Bei Open Source Software fallen keine Lizenzkosten an. Im Gegensatz zu kommerzieller Software ist die Einräumung der Verwertungsrechte bei Open Source Software kostenfrei. Laut einer Marktuntersuchung von IDC ist für Unternehmen die Nutzung des Betriebssystems Linux bis zu 95% günstiger als ein kommerzielles Betriebssystem70. Beispielsweise hat das Internet-Versandhandelsunternehmen Amazon dies zum Anlass genommen, seine Rechnersysteme auf Linux umzustellen, und infolgedessen seine Kosten für die technische Infrastruktur um 24% senken können71. b) Nachteile von Open Source Software Um den Eindruck einer Parteinahme zugunsten des Einsatzes von Open Source Software zu vermeiden, sollen mögliche Nachteile der Anwendung nicht verschwiegen werden. Aus unternehmerischer Sicht besteht der große Nachteil bei Open Source Software zunächst in der fehlenden Möglichkeit, Lizenzgebühren zu erheben. Mit dem Vertrieb der Software allein lässt sich kein Gewinn erziehlen. Um mit Open Source Software gewinnorientiert wirtschaften zu können, muss ein Unternehmen somit kostenpflichtige Dienstleistungen „rund um die Open Source Software“ anbieten. Die Frage, ob der Kunde diese Dienstleistungen nachfragt, ist teilweise noch schwieriger zu beantworten, als die Frage, ob er sich für die Software als solche entscheidet. Es bestehen viele Foren im Internet, in denen sich ein Nutzer über Funktion sowie Problembehandlung von Open Source-Computerprogrammen kostenlos informieren kann. Ferner stellt sich die geringe Verbreitungsdichte von Open Source Software zumindest derzeit noch als Absatzproblem dar. Zielt man als Anbieter von Open Source Software oder damit verbundenen Dienstleistungen auf den privaten Endverbraucher, so hat man es derzeit noch mit einem vergleichbar kleinen potentiellen Kundenkreis zu tun. Zusatzdienstleistungen dürften daher vorwiegend von Unternehmen nachgefragt werden. Ein weitere Nachteil in diesem Zusammenhang, der vornehmlich für Geschäftskunden von Open Source Software-Anbietern von Bedeutung sein wird, sind die hohen Schulungs- und Supportkosten, 70 71

FAZ vom 27. Oktober 2003. FAZ vom 27. Oktober 2003.

II. Ökonomische Bedeutung von Open Source Software

47

die infolge einer Umstellung auf Open Source Software entstehen können. Da Open Source Software wenig verbreitet ist, ist davon auszugehen, dass Mitarbeiter einer umfangreichen Umschulung auf das neue System bedürfen. Insofern sind höhere Supportkosten nicht unwahrscheinlich. Entwickelt ein Unternehmen Software, um diese als Open Source Software zu verbreiten, sind Mitbewerber in der Lage das Produkt aufgrund der Offenlegung des Quellcodes zu studieren. Sie können zudem von den Entwicklungsergebnissen des Mitbewerbers profitieren und seine Ergebnisse für eigene Produkte nutzen. Aufgrund der niedrigen Markteintrittshindernisse im Sektor Open Source Software ist bei einem Erfolg zudem mit einem schnellen Anstieg der Mitbewerber zu rechnen. Soweit es um die Sicherheit eines Software-Produktes geht, so bietet Open Source Software aufgrund seiner Transparenz und der damit verbundenen Sichtbarkeit von möglichen Sicherheitslücken eine „leichte“ Angriffsfläche. Hier besteht die Möglichkeit eine Software in Kenntnis des Quellcodes zu manipulieren und zu schädigen. Auch wenn derzeit keine großen „Hacker“-Angriffe auf Open Source Software bekannt geworden sind, darf dieses potentielle Sicherheitsrisiko bei einer neutralen Bewertung nicht unerwähnt bleiben. c) Betätigungsfelder In diesem Zusammenhang stellt sich nunmehr die Frage nach möglichen Geschäftsfeldern, in denen ein Unternehmen mit lizenzgebührenfreier Software profitabel wirtschaften und Gewinn erzielen kann. Im Bereich von Open Source Software haben sich mit der Zeit verschiedene Möglichkeiten herausgebildet, sich wirtschaftlich zu betätigen. Im Rahmen der Wertschöpfungskette von Freier Software gibt es verschiedene Betätigungsfelder72. Grundsätzlich kann man die Wertschöpfung in die Bereiche der Produktion, d. h. der Programmierung von Software und Dienstleistungen unterteilen. Die derzeit bedeutendsten Geschäftsfelder sind die Softwareentwicklung, der Bereich der Embedded Systeme73, der Distributorenmarkt und der Dienstleistungsbereich. Mittlerweile sind die großen IT-Unternehmen (z. B. IBM, Hewlett-Packard, Compaq, SAP, Sun Microsystems u. a.) im Bereich Open Source Soft72

Floss-Studie (Teil 3), S. 22 ff. Unter Embedded Systemen [dt. eingebettete (Information verarbeitende) Systeme] versteht man intelligente elektronische Systeme, die in eine Alltagsumgebung eingebettet sind und auf Veränderungen der Umgebung regieren können und Überwachungs-, Steuerungs- und Regulierungsfunktionen wahrnehmen können. Verwendet werden diese Systeme z. B. in der Medizintechnik (Herzschrittmacher), Kraftfahrzeugtechnik (Motorsteuerung). Durch den Einsatz lizenzkostenfreier Software lassen sich die Produktpreise erheblich reduzieren. 73

48

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

ware mit Milliardeninvestitionen tätig und unterhalten zum Teil eigene Entwicklungsabteilungen74. Studien zeigen, dass bereits ca. 30% der größten Softwareunternehmen aktiv in der Open Source Software Entwicklung tätig sind75. So startete IBM Anfang September 2003 eine Werbekampagne, um die Verbreitung des Betriebssystems Linux zu unterstützen76. IBM hat durch den Einsatz von Linux im Bereich von Servern im Jahr 2003 mit einem Anteil von mehr als 30% die Marktführerschaft errungen77. Und auch der Hewlett-Packard Konzern will die Vorteile von Open Source Software für seine Produkte nutzen, um auf die Kundenwünsche nach Open Source-Kompatibilität zu reagieren78. So ist Hewlett-Packard davon überzeugt, dass der Bedarf an Open Source Produkten weiter zunehmen wird und für Unternehmensstrategien immer wichtiger wird79. Das Hewlett-Packard im Geschäftsjahr 2002 allein mit Linux-basierten Lösungen einen Umsatz von rund 2 Milliarden US-Dollar erzielt hat, bestätigt das Engagement des Konzerns. Für Investitionen in den Bereich Open Source Software sprechen aus Sicht von Unternehmen verschiedene Gründe: Die bereits oben erläuterten Argumente wie Stabilität, Sicherheit, Transparenz und hohe Anpassungsfähigkeit wie auch der Kostenvorteil kommen auch im Unternehmensbereich zum Tragen. Darüber hinaus bestehen aber noch weitere Gesichtspunkte, die für eine unternehmerische Tätigkeit sprechen80. Zunächst ist darauf hinzuweisen, dass das Unternehmensziel, Gewinne zu erwirtschaften, sich nicht durch den reinen Vertrieb Freier Software ohne Zusatzleistungen erreichen lässt81. Vielmehr muss ein unternehmerisches Engagement darauf gerichtet sein, mit indirekten Effekten des Einsatzes von Open Source Software oder damit verbundener Dienstleistungen Profit zu erwirtschaften82. Im Bereich der Softwareentwicklung bietet sich für Unternehmen die Möglichkeit, ihre kommerzielle Software mit Open Source Software kompatibel zumachen83. Dadurch hat das Unternehmen den Vorteil, seine Produkte auch Kunden, die Open Source Software einsetzen, anbieten zu kön74

Vgl. Floss-Studie (Teil 2), S. 10 ff.; FAZ vom 27. Oktober 2003. Floss-Studie (Teil 2), S. 11; Eine detaillierte Beschreibung der Softwareaktivitäten der Großunternehmen findet sich ebenfalls in der Floss-Studie (Teil 2), S. 11 ff. 76 FAZ vom 13. September 2003. 77 FAZ vom 13. September 2003. 78 FAZ vom 27. Oktober 2003. 79 FAZ vom 27. Oktober 2003. 80 Ausführliche Darstellung in der Floss-Studie (Teil 2). 81 Floss-Studie (Teil 2), S. 17. 82 Floss-Studie (Teil 2), S. 17. 83 Floss-Studie (Teil 2), S. 20. 75

II. Ökonomische Bedeutung von Open Source Software

49

nen. Unternehmen sind somit in der Lage, sich neue Kundenkreise zu erschließen. Ferner bauen sie durch Open Source Software Entwicklungen ihren Produktbereich aus. Es sei auch erwähnt, dass Unternehmen gerade durch den Einsatz von Open Source Software Kundeneinbrüche kompensieren wollen, die durch Open Source Software selbst entstanden sind84. Aber auch strategische Überlegungen können zu der Entscheidung führen, dass ein Unternehmen eines ihrer kommerziellen Softwareprodukte als Open Source-Produkt „freigibt“85. Bekannte Beispiele sind der Browser von Netscape oder das Textverarbeitungsprogramm von Star Office. Durch die kostenlose Freigabe des Programms haben Nutzer die Möglichkeit, Software eines bestimmten Anbieters zu nutzen und die Vorzüge der Programmierung aus einem bestimmten Softwarehaus zu testen. Hierin liegt auch ein nicht zu unterschätzender Werbeeffekt für kommerzielle Softwareprodukte aus dem Unternehmen. Dies kann unter Umständen auch zu einem wichtigen Wettbewerbsvorteil gegenüber Konkurrenten werden, da man hierdurch die Kunden an seine Produktpalette binden kann. Ein Unternehmen, das sowohl kommerzielle Software wie auch Freie Software vertreibt, kann prinzipiell jedem Kunden eine geeignete Softwarelösung bieten. Die zunehmenden Aktivitäten der großen Softwareunternehmen scheinen die genannten Gründe zu belegen. Dabei sollte nicht die Gefahr übersehen werden, die entstehen kann, wenn ein Unternehmen parallel zu seiner kommerziellen Softwareproduktpalette auf Open Source Software setzt. Zum einen besteht die Möglichkeit, dass sich die Open Source Software zu einem Konkurrenzprodukt innerhalb der unternehmenseigenen Produktpalette entwickelt. Zum anderen riskiert ein Unternehmen, das ein Softwareprodukt als Open Source Software freigibt, die Entwicklungshoheit über ihr Produkt zu verlieren. Ein weiterer wichtiger Grund für Unternehmensaktivitäten im Bereich Open Software ist die zunehmende Standardisierung im Bereich Open Source Software86. Der Markt hat ein Interesse an einem freien funktionierenden Betriebssystem, das dauerhaft weiterentwickelt wird. In so einem einheitlichen System ist dann die einzelne Softwarelösung der Unternehmen integrierbar. Weder Unternehmen noch Nutzer müssen sich somit auf verschiedene Betriebssysteme einlassen, deren Zukunft nicht garantiert ist. Die zunehmende Standardisierung von Open Source Software, speziell von Linux, führt auch zu einer Verringerung des Investitionsrisikos. Ferner haben die Unternehmen die Möglichkeit spezielle Softwareprodukte für ihre Kunden zu entwickeln, anstatt sich mit der Programmierung von Grundfunktionen eines Betriebssystems zu beschäftigen, dessen Zukunft ungewiss ist87. 84 85 86

M.I.T. Technology Review, deutsche Ausgabe (Heft 10/Okt. 2004), S. 52. Floss-Studie (Teil 2), S. 19. Floss-Studie (Teil 2), S. 18.

4 Teupen

50

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

Im Bereich Open Source Software bietet der Dienstleistungs- und Supportmarkt enormes Potenzial für die wirtschaftliche Betätigung von Unternehmen88. Da sich mit dem Vertrieb der Open Source Software als solche aufgrund der fehlenden Möglichkeit, Lizenzkosten zu erheben, kein Gewinn erzielen lässt, haben sich Unternehmen darauf spezialisiert, die Open Source Software als Paket mit Zusatzdienstleistungen anzubieten. Zu den Dienstleistungen zählen beispielsweise das Erstellen von Benutzerhandbüchern, die Zusammenstellung von Zusatzsoftware, Supportleistungen und individuelle Anpassungsdienstleistungen. In diesem Segment haben sich im Laufe der letzten Jahre viele Distributoren wie beispielsweise SuSE, Red Hat und Caldera am Markt etabliert89. Das größte deutsche unabhängige Softwareunternehmen SuSE Linux AG mit Sitz in Nürnberg beschäftigt derzeit rund 400 Mitarbeiter90. Laut Mitteilung des Unternehmens ist allein in den Jahren 2001 und 2002 der Bereich Unternehmenssoftware um 180% gewachsen91. Dass das Distributorensegment auch bei großen Softwarehäusern im Fokus steht, zeigen auch die aktuellen Unternehmensentwicklungen in diesem Bereich. Die SuSE Linux AG ist von dem amerikanischen Anbieter für Unternehmenssoftware Novell für 250 Millionen US-Dollar übernommen worden92. Novell erklärt die Unternehmensentscheidung mit dem wachsenden Konkurrenzdruck durch das Betriebssystem Windows von Microsoft im Bereich von Netzwerklösungen93. In diesem Zusammenhang kündigte der weltgrößte Computerkonzern IBM an, 50 Millionen US-Dollar in Novell zu investieren94. Die Entwicklungen zeigen das enorme Potenzial von Distributoren Freier Software. Die dargestellten potenziellen Geschäftsfelder und wirtschaftlichen Möglichkeiten sowie die Entwicklungen im Segment Open Source Software verdeutlichen, dass Open Source Software auch als lizenzkostenfreie Software am Markt bestehen kann. 2. Open Source Software in der Öffentlichen Verwaltung Der Staat und für ihn handelnd die öffentliche Verwaltung benötigt eine geeignete Softwareinfrastruktur, um die Informationsbearbeitung innerhalb der Behörden zu gewährleisten. Auch der Austausch von Dienstleitungen 87 88 89 90 91 92 93 94

Floss-Studie (Teil 2), S. 18. Floss-Studie (Teil 2), S. 42 ff. Floss-Studie (Teil 2), S. 42. FAZ vom 05. November 2003. FAZ vom 05. November 2003. FAZ vom 05. November 2003. FAZ vom 05. November 2003. FAZ vom 05. November 2003.

II. Ökonomische Bedeutung von Open Source Software

51

über das Internet zwischen den Verwaltungseinheiten, aber auch zwischen der Verwaltung und Bürgern, Wirtschaft und Beschäftigten nimmt ständig zu95. Die öffentliche Verwaltung hat bei der Einrichtung ihrer Informationssysteme wichtige Kriterien zu beachten96. So muss der freie Zugang zu öffentlichen Informationen wie auch die dauerhafte Abrufbarkeit der Daten sichergestellt sein. Ferner muss, da es sich auch um Austausch und Abrufbarkeit sensibler Daten handelt, die Sicherheit des Angebots gewährleistet sein. Schließlich hat die öffentliche Verwaltung auf der Kostenseite darauf zu achten, dass die öffentlichen Ausgaben für die technische Infrastruktur – gerade in Zeiten, in denen die öffentliche Haushaltslage als kritisch zu beurteilen ist – möglichst gering bleiben. Ausgehend von diesen Anforderungen kann Open Source Software auch in der öffentlichen Verwaltung eine Alternative zu kommerzieller Software sein. Die oben bereits genannten Argumente wie Sicherheit, Stabilität, Transparenz, Unabhängigkeit, Kostenvorteil und Anpassungsfähigkeit der Freien Software kommen gerade im Hinblick auf die genannten Anforderungen zum Tragen97. Fragen des Einsatzes von Open Source Software im öffentlichen Bereich werden mittlerweile auf breiter Basis diskutiert. Die Verbreitung von Open Source Software hat auch hier bereits deutlich zugenommen. Der Schwerpunkt liegt derzeit noch bei den Serveranwendungen98. Da Open Source Software noch nicht allumfassend und flächenweit eingesetzt wird, besteht der Hauptgrund, Freie Software derzeit noch nicht einzusetzen, meist darin, dass Fragen der Kompatibilität noch ungeklärt sind und viele Anwender mit der Benutzung Freier Software nicht vertraut sind99. Die Öffentliche Verwaltung hat sich dennoch grundsätzlich für Open Source Software geöffnet100. Der Ältestenrat des Deutschen Bundestages hat nach langer Diskussion am 14. Mai 2002 entscheiden, das freie Betriebssystem Linux zukünftig auf den ca. 150 Servern des Bundestages einzusetzen, während die rund 5000 Arbeitsplatzrechner vorerst weiter unter der kommerziellen Windows-Software laufen sollen101. Mit dieser Entscheidung hat eine oberste Verwaltungsbehörde den Weg für den Einsatz von Open Source Software in der öffentlichen Verwaltung und der Reduzierung der Abhängigkeit von kom95

Büchner/Büllesbach-Schallbruch, S. 1. Floss-Studie (Teil 2 B) S. 26. 97 Floss-Studie (Teil 2 B) S. 4 ff. 98 Floss-Studie (Teil 2 B) S. 4 ff. 99 Floss-Studie (Teil 2 B) S. 4 ff. 100 FAZ vom 28. Februar 2002, CR 2001, S. 283. 101 Pressemitteilung des Bundesministers des Inneren vom 14. März 2002, http:// www.bmi.bund.de/dokumente/Pressemitteilung/ix_72530.htm. 96

4*

52

§ 2 Herkunft und ökonomische Grundlagen von Open Source Software

merziellen Anbietern vorgezeichnet. Mit dem Argument der Kostenvorteile von Open Source Software habe sich beispielsweise auch das Bundesland Niedersachsen und die bayrische Landeshauptstadt München für den partiellen Einsatz von Freien Software Linux entschieden102. Die Bundesregierung hat sich zur Aufgabe gemacht, den Einsatz von Freier Software in der öffentlichen Verwaltung zu fördern und zu unterstützen. Im Juni 2002 hat der Bundesinnenminister Otto Schily einen Kooperationsvertrag mit dem Unternehmen IBM geschlossen, in dem die Förderung von offenen Computerbetreibsystemen und Software in der öffentlichen Verwaltung mit dem Ziel vereinbart wurde, dass Bund, Länder und Kommunen die Möglichkeit haben, kostengünstige Open Source Software einzusetzen103. Bereits ein Jahr nach dem Abschluss des Kooperationsvertrages haben über 500 Behörden den Antrag gestellt, dem Rahmenvertrag beizutreten104. Dies zeigt, dass in Deutschland im öffentlichen Bereich zunehmend Open Source Software eingesetzt wird und dass Interessen an freien Softwarelösungen zunehmen. Dies unterstrich auch der Staatssekretär des Innenministeriums auf der Eröffnungsveranstaltung zur LinuxWorld 2003 in Frankfurt mit seiner Aussage, dass Kriterien wie Unabhängigkeit, Interoperabilität, Anpassungsmöglichkeiten sowie Transparenz den Einsatz von Open Source Software im Behördenumfeld attraktiv machen105. Auch im Ausland steht der Einsatz von Open Source Software in der Verwaltung zur Diskussion. Es ließen sich hier eine Fülle von ausländischen Regierungen aufzählen, die den Einsatz von Open Source Software beabsichtigen und aktiv fördern106. Beispielhaft sollen an dieser Stelle die Regierungen in Holland, Großbritannien, China, Südafrika, Südkorea, Japan, Vietnam, Mexiko und Indien genannt werden, die sich aktiv für die Nutzung und Verbreitung von Open Source Software auch außerhalb des staatlichen Verwaltungsapparates einsetzen. Es zeigt sich somit, dass Open Source Software – auch durch die aktive politische Unterstützung und Förderung – als zukunftsfähige Alternative zu kommerzieller Software gesehen wird. 102

Floss-Studie (Teil 2 B), S. 13. Eine ausführliche Darstellung über den Einsatz von Open Source in der öffentlichen Verwaltung findet sich auch auf der Webseite: www.bundestux.de, Internetauftritt einer Initiative für den Einsatz von Open Source Software in der öffentlichen Verwaltung. 103 FAZ vom 05. Juni 2002. 104 Pressemitteilung des Bundesministers des Inneren vom 23. Juni 2003, http:// www.bmi.bund.de/dokumente/Pressemitteilung/ix_92414.htm. 105 ct, 3. November 2003, S. 39. 106 Es soll an dieser Stelle keine detaillierte und ausführliche Darstellung der einzelnen Initiativen erfolgen. Eine Zusammenstellung und Übersicht findet sich bei: www.bundestux.de.

§ 3 Urheberrecht und „Copyleft“ Beschäftigt man sich mit dem Phänomen „Copyleft“ im Bereich von Software, ist es notwendig, sich die Grundintention zu verdeutlichen, auf denen die Lizenzmodelle aufbauen1. Für das Verständnis und die Klärung von Auslegungsfragen spielt die Motivation der Urheber, Software als Open Source Software zu lizenzieren, eine große Rolle. Die Intention der Urheber ist mit der Geschichte von Open Source Software eng verbunden. Viele Motive sind daher bereits mit Darstellung der geschichtlichen Entwicklung von Open Source Software erkennbar geworden. Die Motive bedingen die geschichtliche Entwicklung. Betrachtet man die Open Source Bewegung im Lichte des Urheberrechts, scheint sie sich mit ihren Lizenzmodellen diametral zu den Prämissen unseres Urheberrechtssystems zu verhalten.

I. Inhalt und Bedeutung des Urheberrechts im Informationszeitalter Das Urheberrecht regelt die Benutzung und Verwertung von geistigem Eigentum. Aufgrund seiner Interessenausgleichsfunktion hat das Urheberrecht die Aufgabe, die wirtschaftlichen Konflikte zwischen den Urhebern, den Verwertern und der Allgemeinheit mit rechtlichen Mitteln zu regulieren2. Im Mittelpunkt urheberrechtlicher Normen steht dabei der Urheber in seiner Beziehung zu seinem Werk, § 1 UrhG3. Gem. § 11 S. 1 UrhG ist es Zweck des Urheberrechts, den Urheber in seinen geistigen und persönlichen Beziehungen zu seinem Werk sowie seine Nutzungsmöglichkeiten an diesem zu schützen. Ferner bestimmt § 11 S. 2 UrhG, dass es Aufgabe des Urheberrechts ist, dem Urheber für die Nutzung seines Werkes eine angemessene Vergütung zu sichern. Das Urheberrecht unterliegt zum einen dem Eigentumsschutz des Art. 14 GG, zum anderen erfährt das Urheberpersön1 Es wird an dieser Stelle keine Darstellung der Urheberrechtsgeschichte stattfinden. Dies wäre aufgrund des Umfangs einer vollständigen Darstellung eher ein Thema für eine eigene Arbeit. Darstellungen zur Vorgeschichte und Entwicklung des Urheberrechts finden sich bei Delp (V, Rn. 1 ff.) sowie bei Rehbinder (§ 3). 2 Rigamonti, der dabei den Terminus des „geistigen Eigentums“ in den Mittelpunkt seiner Betrachtung stellt, S. 43. 3 Möhrung/Nicolini/Ahlberg, § 1 Rn. 1.

54

§ 3 Urheberrecht und „Copyleft“

lichkeitsrecht grundgesetzlichen Schutz durch Art. 1 und 2 I GG4. Darüber hinaus schützt das Urheberrecht auch die Personen, die die geistigen Schöpfungen verwerten, also die Werkverwerter. Eine wirtschaftlich erfolgreiche Verwertung von Werken erfordert hohe Investitionen, um eine geeignete Infrastruktur für die Verwertung zu schaffen und zu gewährleisten. Die Gewährleistung einer angemessenen Urhebervergütung impliziert daher auch einen entsprechenden Schutz der Verwerter durch das Urhebergesetz. Das Urheberrecht beschränkt sich jedoch nicht nur auf den Schutz des Werkes und seiner Urheber sowie der aufgrund von Lizenzvereinbarungen am Werk berechtigten Verwerter, sondern es hat darüber hinaus die Aufgabe, zum geistigen, kulturellen und kulturwirtschaftlichen Fortschritt der Gesellschaft beizutragen5. Es dient somit auch der Allgemeinheit, denn erst durch den Schutz des geistigen Eigentums und der Rechteinhaber ermöglicht und fördert das Urheberrecht die Schaffung und Verbreitung von geistigen Werken und garantiert die kulturelle Vielfalt der Gesellschaft6. Dies wird im Urhebergesetz durch die Schrankenregelungen deutlich, die, zurückgehend auf die Sozialpflichtigkeit des Eigentums gem. Art. 14 II GG, in gesetzlich bestimmten Fällen zu einer Einschränkung der Rechtsposition von Urheber und Verwerter führen können. Grundsätzlich wird in unserem Urheberrechtssystem davon ausgegangen, dass das Vorhandensein eines wirksamen gesetzlich normierten Schutzes von Urheberrechten den Urhebern als Motivation für geistige Schaffensprozesse dient7. Gerade im Zeitalter der Digitalisierung, in dem die Verwertungsrechte durch neue technische Vervielfältigungs-, Verbreitungs- und Wiedergabemöglichkeiten bedroht sind, verschafft ein wirksamer Urheberrechtsschutz den Rechteinhabern Investitionssicherheit und gewährleistet den Fortschritt kultureller Entwicklung8. Würde ein ausreichender Schutz des geistigen Eigentums fehlen, hätte dies gravierende Folgen für den kulturellen Wirtschaftssektor und würde zudem die kulturelle Vielfalt gefährden. Andererseits kann jedoch ein umfassender Schutz der Rechteinhaber dazu führen, dass Dritte und die Allgemeinheit die Werke nicht mehr in angemessener Weise nutzen können. Wenn z. B. technische Schutzmaßnahmen mit dem Ziel eines umfassenden Digital Rights Managements eingeführt werden, besteht die Gefahr, dass die Allgemeinheit ihre Rechte auf Teilhabe an den Geisteswerken nicht mehr sinnvoll wahrnehmen kann9. Dies zeigt sich bereits an der Einführung der Regelungen zum Schutz technischer Maßnahmen in den §§ 95 a UrhG; denn 4 5 6 7 8 9

BVerfGE 31, 229, 238 ff.; Loewenheim/Loewenheim, § 1 Rn. 4. Schricker/Schricker, Einleitung Rn. 13. Loewenheim/Loewenheim, § 1 Rn. 7, BVerfGE 42, 382 ff. Vgl. auch Davies, S. 4 ff. So auch Davies, S. 7. So auch Kröger, S. 8.

II. Der Open Source-Gedanke

55

ist ein Werk danach mit wirksamen technischen Maßnahmen geschützt, ist es dem Einzelnen nicht mehr möglich, eine rechtmäßige digitale Privatkopie gem. § 53 I UhrG herzustellen, es sei denn, der konkrete Sachverhalt fällt unter die Privilegierungen des § 95 b UrhG. Dies zeigt, dass die technische Entwicklung nicht nur hohe Anforderungen an einen wirksamen Schutz der Rechteinhaber stellt, sondern dass gerade auch die Interessen der Allgemeinheit angemessen zu berücksichtigen sind. In der heutigen Informationsgesellschaft ist folglich, gerade was die Interessenausgleichsfunktion des Urheberrechts betrifft, die Frage nach dem Informationszugang von besonderer Aktualität10. Im digitalen Zeitalter, in dem der universelle Zugang zu Informationen jederzeit und von jedem Ort möglich ist, wächst das Spannungsverhältnis zwischen dem Leistungs- und Innovationsschutz der Rechteinhaber auf der einen Seite sowie die Freiheit des Informationszugangs der Allgemeinheit auf der anderen Seite11. Dabei ist im Zusammenhang mit dem Interessenausgleich die Frage relevant, wie viel Schutz auch im Sinne der Innovation sinnvoll und notwendig ist, um eine optimale innovative Entwicklung zu gewährleisten12. Es besteht somit ein Spannungsverhältnis zwischen der grundrechtlich geschützten Position des Urhebers an seinem geistigen Eigentum und den Rechten der Allgemeinheit auf Informationsfreiheit sowie der Freiheit des geistigen Schaffens Dritter13.

II. Der Open Source-Gedanke im Spannungsfeld von Urheberrechtsschutz und Informationsfreiheit In diesem Zusammenhang stellt sich Open Source Software als ein Phänomen dar, das sich scheinbar von den bisherigen Urheberrechtstheorien loslöst14. Die Open Source-Bewegung hat sich von einer rein kommerziell orientierten Verwertung geistiger Schaffensergebnisse losgesagt und der Informationsfreiheit den Vorrang gegeben. Fraglich ist, was Urheber im Einzelnen dazu bewegt, sich für ein Open Source-Lizenzmodell zu entscheiden.

10

Vgl. hierzu Kröger, der sich ausführlich mit der Verteilung von Informationen zwischen dem geistigen Eigentum der Urheber und der Informationsfreiheit der Rezipienten auseinandersetzt. 11 Kur, S. 32. 12 So auch Dreier, S. 51 f. 13 Kröger, S. 21. 14 So auch Kröger, S. 22.

56

§ 3 Urheberrecht und „Copyleft“

1. Das Copyleft-Modell Die Motive und Ziele der Urheber von Open Source Software finden ihren lizenzrechtlichen Ausdruck im sog. Copyleft-Modell. „Copyleft“ kann im engeren Sinne als eine Methode begriffen werden, ein urheberrechtlich geschütztes Computerprogramm als freie Software unter der Bedingung zu lizenzieren, dass alle Modifizierungen und Änderungen an dem Programm ihrerseits wieder unter die „Ausgangs-Lizenz“ zu stellen sind, soweit sie für sich genommen urheberrechtlich geschützt sind15. Copyleft basiert auf der Annahme eines urheberrechtlichen Schutzes von Computerprogrammen und nutzt das Schutzsystem für die kontrollierte Rechtseinräumung. Mit der Verwendung von Copyleft-Lizenzen erkennen Urheber also die Geltung von Urheberrechten an und nutzen ihre Position der Rechtsinhaberschaft, um Software als Open Source Software zu lizenzieren. Hier wird deutlich, dass man im Zusammenhang mit Copyleft nicht von einem Verzicht auf Urheberrechte sprechen kann. Die Urheber von Open Source Software verzichten mit der Benutzung freier Lizenzmodelle gerade nicht auf ihr Urheberrecht16. Läge in der Verwendung von Open Source-Lizenzen ein Verzicht des Urhebers auf seine Urheberrechte, könnten die Lizenzen im Geltungsbereich des UrhG keine Rechtswirkung entfalten, da ein vollständiger Verzicht auf das Urheberrecht nach deutschem Recht aufgrund des persönlichkeitsrechtlichen Charakters des Urheberrechts nicht möglich ist. Dies folgt aus § 29 I UrhG17. Aber auch praktische Gründe sprechen gegen die Annahme eines Urheberrechtsverzichts. Vordergründiges Ziel des „Copyleft“-Modells war und ist es, mit Hilfe von Urheberrechten zu verhindern, dass Freie Software von Dritten wieder zu einem kommerziellen Projekt transformiert werden kann18. Ein Verzicht auf Schutzrechte würde hingegen bedeuten, dass der Urheber jeglichen Einfluss auf sein Werk verlieren würde. Das ein Computerprogramm „frei“ i. S. des Copyleft-Modells bleiben würde, wäre nicht mehr sicherzustellen. Jeder hätte die Möglichkeit, das Programm oder Programmteile einer kommerziellen Verwertung zuzuführen. Auch die Verwendung des Terminus „Lizenz“ spricht gegen einen generellen Verzicht19. Einer Lizenz bedarf es ja nicht, soweit auf Rechte 15 Stallman, S. 89; Grzeszick, MMR 2000, S. 415; Jaeger/Metzger, OSJ 2004, S. 301. 16 Perens, Opensources, S. 181; Rosenberg, S. 87; Auf die GPL bezogen: LG München I, CR 2004, S. 775; Spindler, in: Spindler, Abschn. C Rn. 6 f.; Jaeger/ Metzger, S. 31; Schiffner, S. 148 f.; Grzeszick, MMR 2000, S. 416 f.; Dreier, CR 2000, S. 45; Dreier/Schulze, § 69 a Rn. 11; Omsels, in: Festschrift für Paul W. Hertin, S. 144; Wiebe, CR 2004, S. 881; ders., in: Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 108; Marly, Rn. 332, 421. 17 Loewenheim/Nordemann, § 23 Rn. 8; Schricker/Schricker, § 29 Rn. 15. 18 Stallman, S. 20.

II. Der Open Source-Gedanke

57

gänzlich verzichtet wird. Auch die Formulierung in Ziff. 4 GPL, wonach unter bestimmten Voraussetzungen Rechte erlöschen können, unterstreicht die Annahme, dass gerade Rechtspositionen eingeräumt werden, statt dass auf sie verzichtet wird20. Ein Urheberrechtsverzicht schließt folglich ein funktionierendes CopyleftModell aus. An dieser Stelle sei eine Anmerkung zur Terminologie im rechtlichen Bereich von Open Source Software erlaubt. Aus der Tatsache, dass in dem Copyleft-Modell kein Verzicht auf das Urheberrecht liegt, folgt, dass die Unterscheidung zwischen Open Source Software und „proprietärer“ Software die Gefahr birgt, missverstanden zu werden. Versteht man unter „proprietär“, dass ein Computerprogramm urheberrechtlich geschützt ist, und dem Urheber daran dem Terminus (Proprietät, aus dem lat.: proprietas, Gen.: proprietatis: Eingetum[srecht]) entsprechend eine gem. Art. 14 GG schutzfähige Rechtsposition21 zukommt, ist grundsätzlich auch Open Source Software „proprietäre“ Software. Insofern ist der Terminus „proprietär“ unglücklich. Da diese Unterscheidung jedoch üblich ist und allgemein verwendet wird, wird sie auch im Folgenden beibehalten. 2. Die Free Software-Definition/Open Source-Definition Nach dem Copyleft-Modell setzt eine Freie Software bzw. eine Open Source Software voraus, dass dem Nutzer ein Mindestmaß an Verwertungsrechten unentgeltlich eingeräumt wird. Wann eine Software als Open Source Software bzw. als Freie Software einzuordnen ist, hängt davon ab, ob die verwendete Lizenz diese „Mindestrechte“ einräumt. Welche Mindestrechte oder bzw. Grundfreiheiten eine Open Source-Lizenz gewähren muss, ist in der Open Source-Definition und in der Free Software-Definition geregelt. Allen Open Source-Lizenzen gemeinsam ist, dass sie den Bedingungen der Open Source-Definition oder der Free Software-Definition entsprechen. Die jeweilige Definition ist für sich genommen noch keine Lizenz. Das Vorliegen der „Tatbestandsmerkmale“ der jeweiligen Definition ist jedoch der notwendige Kern einer jeden Open Source-Lizenz. Man kann auch sagen, dass die in den Definitionen formulierten Anforderungen die essentialia negotii einer Open Source-Softwarelizenz sind. Wie bereits dargelegt unterscheiden sich die beiden Definitionen der FSF und der OSI nicht we19

So auch Schiffner, S. 149. So auch Schiffner, S. 149. 21 Das Urheberrecht ist hinsichtlich seiner vermögenswerten Aspekte ein vermögenswertes Recht, das als Eigentum dem grundrechtlichem Schutz des Art. 14 GG unterliegt. Vgl.: BVerfGE 31, 229/239; 77, 263/270; 79, 1/25. 20

58

§ 3 Urheberrecht und „Copyleft“

sentlich im Inhalt, sondern sind in erster Linie eine Folge verschiedener Grundintentionen der jeweiligen Anhängerschaft. Aufgrund der inhaltlichen Übereinstimmung wird in einigen Darstellungen inhaltlich nur auf die Open Source-Definition eingegangen.

a) Free Software-Definition Die Freie Software Definition basiert auf der Grundthese, dass sich „Freie Software“ auf die freie Benutzbarkeit einer Software und nicht auf den Preis eines Softwareproduktes oder eine Lizenzgebühr bezieht. Dies wird auch durch die oft zitierte Aussage von Richard Stallman deutlich: „To understand the concept, you should think of „free“ as in „free speech“, not as in „free beer“. Unter Freiheit wird vielmehr die Freiheit des Nutzers verstanden, ein Computerprogramm auf seiner Arbeitsstation ablaufen zu lassen, es zu kopieren, zu verbreiten, in seiner Funktionsweise zu studieren, zu verändern und zu verbessern. Damit ein Nutzer diese Handlungen vornehmen kann, bedarf es nach der Free Software-Definition vier Grundfreiheiten, die in einer entsprechenden Lizenz enthalten sein müssen, um ein Computerprogramm als Freie Software bezeichnen zu können: 1. Die Freiheit, ein Computerprogramm für jeden Zweck nutzen zu können. 2. Die Freiheit, ein Computerprogramm auf seine Funktionsweise hin zu untersuchen und es an die eigenen Bedürfnisse anzupassen oder gegebenenfalls zu verbessern. Grundvoraussetzung hierzu ist der freie Zugang zum Quellcode des Programms. 3. Die Freiheit, Programmkopien zu verbreiten. 4. Die Freiheit, das Programm zu verbessern und die Verbesserungen an die Allgemeinheit weiterzugeben, damit sie davon profitieren kann. Grundvoraussetzung hierzu ist der freie Zugang zum Quellcode eines Programms. Erst wenn diese Voraussetzungen in Lizenzvereinbarungen erfüllt sind, ist ein Computerprogramm „frei“ im Sinne der Definition.

b) Open Source-Definition Auch nach der Open Source-Definition müssen dem Nutzer bestimmte Nutzungsbefugnisse eingeräumt werden, damit das Computerprogramm als Open Source Software einzuordnen ist. Folgende Voraussetzungen müssen kumulativ vorliegen:

II. Der Open Source-Gedanke

59

1. Die Lizenz muss die unbeschränkte Weitergabe und den Verkauf der Software als Komponente eines Softwarepaketes im Rahmen einer Distribution ermöglichen. Darüber hinaus darf für die Lizenz keine Lizenzgebühr noch sonstige Gebühren für einen derartigen Verkauf erhoben werden. 2. Die Software muss im Quellcode zugänglich sein und die Lizenz muss eine Verbreitung sowohl in Quellcodeformat als auch in kompilierter Form des Objektcodes erlauben. Für den Fall, dass eine Software ohne Quellcode verbreitet wird, muss sichergestellt werden, dass dieser über das Internet gebührenfrei abgerufen werden kann. Absichtlich in den Quellcode eingefügte Ungenauigkeiten sind nicht erlaubt. Auch nur vorübergehende Formen des Quellcodes sind nicht erlaubt; er muss in dauerhafter Form vorliegen. 3. Die Lizenz muss Modifizierungen der Software und Schaffung von ihr abgeleiteter Ergebnisse durch den Nutzer und deren Verbreitung unter denselben lizenzrechtlichen Bedingungen erlauben. Die auf der Open Source Software basierenden Werke sollen unter der gleichen Lizenz weiterverbreitet werden. Eine Pflicht, die Modifizierungen oder die neu entstandene Software unter dieselben Lizenzbedingungen wie die Ausgangssoftware zu stellen, besteht hingegen nicht. 4. Die Lizenz kann die Weiterverbreitung des Quellcode in modifizierter Form in Fällen verbieten, in denen die Lizenz die gesonderte Weitergabe von dem Quellcode mit sog. „patch files“ (Patchdateien) erlaubt. Damit soll dem möglichen Interesse von Programmautoren Rechnung getragen werden, den durch sie modifizierten Quellcode von dem fremden Code zu trennen, ohne dabei die Möglichkeit von Modifizierungen zu verhindern. Die Lizenz muss ausdrücklich erlauben, dass aus dem modifizierten Quellcode entstandene Software verbreitet werden darf. Darüber hinaus kann die Lizenz verlangen, dass die aus dem Quellcode neu entstandenen Programme mit einem anderen Namen oder einer anderen Versionsnummer als die Originalsoftware gekennzeichnet werden müssen. 5. Durch die Lizenz darf keine Person oder Personengruppe in Bezug auf die Programmnutzung diskriminiert werden. 6. Die Lizenz darf niemanden darin beschränken, die Software in einem bestimmten Entwicklungs- und Forschungsbereich einzusetzen. Beispielsweise darf die Nutzung des Programms nicht im Bereich der wirtschaftlichen Nutzung, (d. h. zu kommerziellen Zwecken) oder im Bereich der Genforschung lizenzrechtlich untersagt werden. 7. Die Lizenz an der Open Source Software muss für alle Nutzer des Programms rechtsverbindlich sein, an die es weitergegeben wird ohne Not-

60

§ 3 Urheberrecht und „Copyleft“

wendigkeit einer besonderen oder zusätzlichen Lizenzvereinbarung durch die jeweils am Weitergabevorgang beteiligten Personen („The license must be automatic, so signature is required.“) 8. Die aus der Lizenz folgenden Verwertungsrechte dürfen nicht davon abhängig gemacht werden, ob das Programm lediglich Teil einer Softwaredistribution ist. 9. Die Lizenz darf sich auch auf keine andere Software erstrecken, mit der die Open Source Software gemeinsam verbreitet wird. Es darf nicht verlangt werden, dass Software die zusammen mit Open Source Software auf einem Datenträger verbreitet wird, automatisch auch als Open Source Software zu lizenzieren ist. 3. Motive für das Copyleft-Modell Befasst man sich mit dem Copyleft-Modell stellt sich die Frage, welche ideologischen, ökonomischen oder persönlichen Motive die Urheber dazu bewegen, die Übertragung der wesentlichen Verwertungsrechte ohne die Erhebung von Lizenzgebühren jedem anzubieten, der die Open Source Software nutzen will. Bei der großen Anzahl von beteiligten Programmierern sind die Motive sicherlich vielschichtig, so dass an dieser Stelle nur Aussagen treffen lassen, die entweder auf durchgeführten Untersuchungen beruhen oder auch nur spekulativer Natur sind. a) Altruistische Ideologie Der freie Zugang zum Quellcode einer jeden Software durch jedermann und zu jeder Zeit ist die Grundintention von Stallman22 und den Anhängern des GNU-Projektes. Sein Ziel war es einen Zustand zu schaffen, in dem für den Nutzer qualitativ hochwertige und funktionsfähige Systemsoftware frei zur Verfügung steht „wie die Luft zum Atmen“. Einem jeden Nutzer sollen komplette Systeme zur freien Verfügung stehen, sodass der Nutzer selbst oder durch Dritte notwendige Anpassungen und Verbesserungen vornehmen kann. Die Nutzer wären somit nicht länger von kommerziellen Anbietern abhängig, die aufgrund des Quellcodes alleinig in der Lage wären, Veränderungen vorzunehmen. Nicht die Kosten für kommerzielle Software sind für Stallman ausschlaggebend23, sondern allein die Transparenz und Unabhängigkeit des Nutzers verbunden mit der Freiheit, jegliche Veränderungen an 22 23

Stallman, S. 34 ff. Stallman, S. 41: „Free Software is a matter of liberty, not price.“

II. Der Open Source-Gedanke

61

ihr vorzunehmen24. Anstatt für die Software als solche zu bezahlen, könnte der Nutzer mit dem Geld einen entsprechenden Support und erforderliche Änderungsprogrammierungen bezahlen. Damit tritt er zugleich dem Argument entgegen, man müsse Software allein schon deswegen kommerziell vertreiben, damit man den notwendigen Support anbieten könne. Stallman geht davon aus, dass allein Leistungen, die der Öffentlichkeit zugute kommen, eine Belohnung verdienen. Kreativität ist erst dann für die Allgemeinheit nutzbar und damit sozial, wenn die Ergebnisse der kreativen Tätigkeit für die Allgemeinheit frei zugänglich sind. Restriktionen von Software sind damit unsozial und verdienen auch keine Belohnung. Nicht die geldwerte Belohnung führt zu Kreativität und geistigen Schaffensergebnissen, sondern die freie Schaffenstätigkeit an sich beinhaltet Freude und ist schon Belohnung. Damit widerspricht Stallman der Theorie, wonach erst die wirtschaftliche Sicherheit durch angemessene Vergütung dazu führt, dass Urheber kreativ arbeiten. Er konstatiert, dass der Urheber, in diesem Fall der Programmierer, primär aus Freude an der kreativen Programmiertätigkeit Software schreibt und gerade in dieser Freiheit, Problemlösungen zu entwickeln, seine eigentliche Befriedigung liegt25. Nach seiner Ansicht hat das Konzept zudem den Vorteil, dass es auch, was die Funktionsweisen von Software anbelangt, klar an den Bedürfnissen der Allgemeinheit und der Nutzer ausgerichtet ist. Verbreitet man Software als Freie Software wird man den Bedürfnissen der Nutzer gerechter, da sie genau das bekommen, was sie im konkreten Fall gebrauchen. Sie habe alle notwendigen Informationen über das Produkt und können es auf ihre individuellen Bedürfnisse anpassen26. Stallman kritisiert, dass die Nutzer von kommerziellen Anbietern lediglich eine „black box“ erhalten, ohne zu wissen, was sie genau enthält. Gerade das jedoch widerspreche seiner Vorstellung einer freien Gesellschaft, in der Transparenz und Kooperation notwenig sind. Die altruistischen Motive von Stallman und den Anhängern des GNUProjekts sind folglich in erster Linie ideeller Natur27. Freier Zugang zu Software bedeutet nach dieser ideologischen Geisteshaltung einen Zuwachs an Gemeinwohl. Bei dieser sehr idealistischen Sichtweise darf man allerdings nicht die äußeren Umstände vergessen, unter denen Stallman und seine Kollegen Software entwickeln konnten. Ohne eigene wirtschaftliche Unabhängigkeit erfordert eine derartige Geisteshaltung zumindest einen wirtschaftlichen Rahmen, in dem man ungestört forschen kann. Am MIT waren die Bedin24 25 26 27

Stallman, S. 63. Stallman, S. 38: „Creativity is also fun, a reward in itself.“ Stallman, S. 47. So auch Luthiger, OSJ 2004, S. 96; Kharitoniouk/Stewin, OSJ 2004, S. 9.

62

§ 3 Urheberrecht und „Copyleft“

gungen und die Voraussetzungen für die Realisierbarkeit der Projekte sicherlich ideal. b) Open Source als Entwicklungsmethode Anhänger der Open Source-Initiative sehen in erster Linie Entwicklungsvorteile durch die Weitergabe des Quellcodes. Eric Raymond hat in seinem berühmten Aufsatz „The Cathedral und the Bazaar“ die Vorteile einer offenen und transparenten Entwicklung von Software dargestellt28. Eine weite Vernetzung unabhängiger Programmierer gewährleistet am ehesten das Entstehen von funktionstüchtiger Software. Dadurch, dass die Programmierer ihr Wissen untereinander frei austauschen, wird die Entwicklung einer funktionierenden Software beschleunigt29. Durch diese Art der vernetzten Arbeit unabhängiger Programmierer entstehen schneller neue Programme, die auf die konkreten Bedürfnisse der Nutzer zugeschnitten sind. Zudem ermöglicht eine breite Vernetzung der verschiedenen Programmierer, dass Fehler und Funktionslücken eher erkannt und schneller behoben werden, als dies bei kommerzieller Software der Fall ist. Es wird somit davon Ausgegangen, dass gerade der freie Zugang zum Quellcode zur Beschleunigung von Softwareentwicklungsprozessen führt und am Ende ein ausgereiftes funktionstüchtiges Produkt steht. Das deckt sich mit der Theorie, dass gerade die freie Weitergabe von Wissen zu mehr Innovation führt und Restriktionen der Wissensweitergabe die Gefahr der innovativen Stagnation birgt30. Es wird somit davon ausgegangen, dass die Dynamik der Softwareentwicklung umso größer ist, je freier der Zugang zum Quellcode ist. Die kommerzielle Monopolisierung des Wissens durch proprietäre Softwareanbieter lähmt die Entwicklung und verhindert das Entstehen eines breiten Marktes von Produkten. c) Gebrauch fremder Programmierergebnisse für eigene Softwareanwendungen Ein Grund für die Benutzung von Open Source Software und die Vornahme eigener Veränderungen an ihr ist, dass der Programmierer von seinen, auch auf Programmierergebnissen Dritter basierenden, Softwareanwendungen profitiert31. In den meisten Fällen wäre er nicht in der Lage, alleine 28 Der Beitrag kann auf der Homepage von Eric Raymond abgerufen werden, http://www.catb.org/~esr/writings/. Vgl. auch Raymond, The Cathedral & The Bazaar, Sebastopol 2001. 29 Perens, Opensources, S. 172. 30 Kuhlen, in: Büllesbach/Dreier, S. 4 f., 7.

II. Der Open Source-Gedanke

63

zu derartigen Programmergebnissen zu kommen. Er findet vielmehr ein Umfeld vor, in dem er auf der Arbeit anderer aufbauen kann und gleichzeitig seine persönlichen Programmierleistungen der Entwicklungsgemeinde zur Verfügung stellen. d) Spaßfaktor und Reputation Auch der Spaß32 an der Programmiertätigkeit und der Ehrgeiz, eigene Elemente eines Computerprogramms selbst beigesteuert zu haben, ist ein Grund für das Engagement vieler Programmierer. Die individuelle Interessiertheit des Einzelnen dient als Antriebskraft, ein nützliches Softwareprodukt zu schaffen33. Gerade Linus Torvalds zeigt durch seine Erzählungen, wie viel Freude ihm die Arbeit an Linux bereitet hat. Der gewählt Buchtitel „Just for Fun“ kann somit auch als Motto verstanden werden unter dem er Linux geschaffen hat. Daneben ist aber auch die Reputation für den Einzelprogrammierer von Bedeutung. Durch die Mitarbeit an einem Open SourceProjekt und die Nennung seines Beitrages durch die Offenlegung des Quellcodes mit dem Verweis auf die Einzelbeiträge und den beteiligten Programmierern, kann ein Programmierer Ansehen erlagen. Dies kann unter Umständen auch zu interessanten Arbeitsangeboten oder auch zu einem leichteren Zugang zu Risikokapital führen34. e) Schaffung eines unabhängigen Softwaresektors Ein weiteres Motiv fast aller Programmierer, Software als Freie Software oder Open Source Software zu verbreiten, ist die Schaffung eines unabhängigen Softwaresektors, dessen Ziel vorrangig die Nutzenmaximierung eines jeden Softwareproduktes ist. Dabei spielt die Situation des Softwaremarktes eine zentrale Rolle35. Auf dem Softwaremarkt gibt es wenig große Unternehmen, die eine Vielzahl von Software anbieten. Was beispielsweise Betriebssysteme angeht, kommen nur die wenigsten Nutzer um das Betriebssystem Windows von Microsoft herum. Das Unternehmen hat bekanntermaßen in diesem Bereich eine weltweite Monopolstellung. Für einen kommerziellen Softwareanbieter ist es unter ökonomischen Gesichtspunkten nahezu unmöglich, mit einem Konkurrenzprodukt in den Markt einzutreten, um mit Microsoft zu konkurrieren. Hier bietet Freie Software, die frei und 31 32 33 34 35

Luthiger, OSJ 2004, S. 95. Ausführlicher dazu vgl. Luthiger, OSJ 2004, S. 97, 99 ff. Meretz, S. 18 ff. So zumindest Luthiger, OSJ 2004, S. 95. So auch Sester, CR 2000, S. 798 f.

64

§ 3 Urheberrecht und „Copyleft“

über das Internet meist kostenlos zur Verfügung steht, eine ernstzunehmende Alternative. Mit der Verbreitung von Open Source Software ist es unter Umständen möglich, mit der Zeit die Vormachtstellung einiger Anbieter aufzubrechen und eine Alternative am Markt zu etablieren. Dieser Drang nach Unabhängigkeit ist eines der Grundmotive der Entwickler, Software als Open Source Software zu verbreiten. f) Lerneffekte Als weiterer Grund für das Engagement im Bereich Open Source Software wird auch die Möglichkeit genannt, durch die Programmiertätigkeit seine eigenen Fähigkeiten verbessern zu können36. Als Programmierer kann man dabei problemlos an die Programmierbeiträge anderer anknüpfen uns somit Können und Erfahrung im Bereich der Softwareentwicklung sammeln. g) Fazit Die vorgenommene Darstellung der Motive ist keinesfalls abschließend. Die Vielzahl der Programmierer von Open Source Software führt zu einer Vielzahl von Motiven37. Es ist deutlich geworden, dass in dem Copyleft-Modell kein Verzicht auf die urheberrechtliche Position liegt, sondern der urheberrechtliche Schutz dem Copyleft-Modell zugrunde liegt. Der urheberrechtliche Schutz wird im Bereich Open Source Software nicht zum Schutz von proprietären Interessen oder als Investitionssicherheit benötigt, sondern er stellt vielmehr sicher, dass ein Open Source-Programm nicht proprietären Interessen zum Opfer fällt. Open Source und die damit einhergehenden Lizenzmodelle zeigen das Urheberrecht somit von einer neuen Seite. Im Rampenlicht stehen der Schutz und die Gewährleistung eines freien Informationsflusses.

36 37

Luthiger, OSJ 2004, S. 96. So auch Schiffner, S. 69 f.

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland Um die Grundlagen für das Verständnis der urheberrechtlichen Besonderheiten von Open Source Software zu schaffen, erscheint es sinnvoll, sich zunächst die Instrumentarien zu vergegenwärtigen, durch die Computerprogramme in unserer Rechtsordnung Schutz erfahren.

I. Rechtsschutz von Computerprogrammen Computerprogramme als Ergebnis geistiger Leitung bedürfen des Schutzes vor unbefugter Nutzung und Missbrauch1. Das Entstehen und die Verbreitung von Computerprogrammen ist dauerhaft nur möglich, wenn die Arbeitsergebnisse der Programmiertätigkeit – also das Computerprogramm als solches – rechtlich geschützt sind. Die Gewährleistung und Sicherung der Verkehrsfähigkeit von Software erfordert einen verstärkten Schutz2. Der rechtliche Schutz ist aber nicht nur bei Computerprogrammen von hoher Bedeutung, die kommerziell verbreitet werden. Auch eine erfolgreiche Verbreitung von Open Source Software wäre ohne entsprechenden Schutz des Programmierergebnisses nicht möglich. Ohne wirksame Schutzrechte und die Möglichkeit einer wirksamen Ausgestaltung im konkreten Einzelfall bestände schließlich nicht die Möglichkeit, eine Software als Freie Software zu verbreiten ohne Gefahr zu laufen, dass sie irgendwann proprietär verbreitet wird. Die Schutzbedürftigkeit von Computerprogrammen führt zu der lange Zeit umstrittenen Frage des Immaterialgüterrechts, nach welchen gesetzlichen Vorschriften ein wirksamer Schutz von Computerprogrammen am besten zu erzielen sei3.

1

Vgl. auch Marly, Rn. 128. So auch Pres, S. 22. 3 Marly, Rn. 128; Möhring/Nicolini/Hoeren, Vor §§ 69 a Rn. 1; Ohly, CR 2001, S. 809; Wiebe, BB 1993, S. 1094 mit weiteren Nachweisen. 2

5 Teupen

66

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

1. Rechtslage in Deutschland vor dem Zweiten Änderungsgesetz zum Urheberrecht Erstmals hat sich die Europäische Gemeinschaft Mitte der achtziger Jahre mit der Notwendigkeit des Schutzes von Computerprogrammen befasst. Die Kommission beabsichtigte mit Blick auf die unterschiedlichen Schutzformen in den europäischen Ländern sowie im nichteuropäischen Ausland die Einführung eines Rechtsschutzes für Computerprogramme auf Basis des Urheberrechts4. Auch Deutschland reagierte auf die rechtspolitische Diskussion und nahm 1985 „Programme für Datenverarbeitung“ in den Katalog des § 2 I Nr. 1 a. F. auf5. Durch diese Novellierung des UrhG wurde die Urheberrechtsfähigkeit von Computerprogrammen erstmals ausdrücklich anerkannt6. Die Rechtsprechung legte die Frage nach der Schutzfähigkeit von Computerprogrammen jedoch sehr restriktiv raus7. Der BGH stellte die Schutzfähigkeit von Computerprogrammen zwar nicht grundsätzlich in Frage, verlangte für die Bejahung der Urheberrechtsfähigkeit aber ein zweistufiges Prüfungsverfahren8. Zum einem müsse ein Computerprogramm im Vergleich zu anderen Programmen schöpferische Eigenheiten aufweisen, die darüber hinaus das Können eines „Durchschnittsprogrammieres“ deutlich überragen9. Diese durch diese Rechtsprechung des BGH festgelegten Anforderungen an die den Urheberrechtsschutz von Computerprogrammen begründende schöpferische Eigentümlichkeit führten jedoch dazu, dass das Urheberrecht nur noch in Ausnahmefällen dem Programmierer als Schutzrecht zur Verfügung stand10. Nur ca. 5% aller Programme fielen seinerzeit unter den restriktiven Maßstab der Schutzvoraussetzungen und wurden somit durch das Urheberrecht geschützt11. Der Urheberechtsschutz für Computerprogramme war aufgrund der hohen Schutzanforderungen somit für 4 Weißbuch zur Vollendung des Binnenmarktes, KOM (1985) 320 vom 12.06.1985, S. 36; Lehmann/Dreier, S. 32; Wandtke/Bullinger/Grützmacher, Vor §§ 69 a ff. Rn. 3. 5 BGBl. I 1985, 1137; siehe auch BT-Drucks. 10/3360, 18; Lehmann/Haberstrumpf, S. 72. 6 Möhing/Nicolini/Hoeren, Vor §§ 69 a ff. Rn. 1. 7 Ebd. 8 Schricker/Loewenheim, Vor §§ 69 a ff. Rn. 2. 9 BGHZ NJW 1986, 192 ff. = Inkassoprogramm; auch in: BGH GRUR 1985, 1041; Erdemann, CR 1986, S. 249 ff.; Lehmann/Haberstrumpf, S. 73; Loewenheim/ Lehmann, § 9 Rn. 45; Marly, Rn. 120; Pres, S. 23; Schricker/Loewenheim, Vor §§ 69 a ff. Rn. 2; Sieber, CR 1986, S. 699 ff.; Wandtke/Bullinger/Grützmacher, Vor §§ 69 a ff. Rn. 2. 10 Lehmann/Haberstrumpf, S. 73. 11 Loewenheim/Lehmann, § 9 Rn. 45; Möhring/Nicolini/Hoeren, Vor §§ 69 a Rn. 1 mit weiterem Nachweis; Bauer, CR 1985, S. 5 ff.; Hoeren, Anmerkung zum BGH-Urteil (Buchhaltungsprogramm), CR 1993, S. 756.

I. Rechtsschutz von Computerprogrammen

67

die überwiegende Mehrzahl von Computerprogrammen nicht gewährleistet, was zu deutlicher Kritik in der Literatur führte12. Auch die Bundesregierung erkannte die problematische Entwicklung und merkte im Bericht über die Urheberrechtsnovelle 1985 und Fragen des Urheber- und Leistungsschutzrechts vom 07. Juni 1989 an, dass es nicht zu verkennen sei, dass der überwiegende Teil von Anwendungsprogrammen in der Praxis schutzlos sei oder der Schutz nicht durchgesetzt werden könne13. 2. Europäische Entwicklung des Rechtsschutzes von Computerprogrammen Die restriktive Handhabung des Urheberrechtsschutzes für Computerprogramme wie auch das Harmonisierungsinteresse nach einem europaweiten einheitlichen Rechtsschutz und die zunehmende Bedeutung des Urheberrechts für den europäischen Binnenmarkt haben dazu geführt, dass sich zum Ende der achtziger Jahre die EG-Kommission mit dem urheberrechtlichen Schutz von Computerprogrammen beschäftigte14. In dem Grünbuch sprach sich die Kommission in Übereinstimmung mit der allgemeinen Auffassung in den Mitgliedstaaten dafür aus, dass der Rechtsschutz für Computerprogramme grundsätzlich durch das Urheberrecht gewährleistet werden soll15. Die durch die unterschiedliche Handhabung des Rechtsschutzes für Computerprogramme entstandene Unsicherheit sollte behoben werden16. Die EG-Kommission legte am 05.01.1989 einen Vorschlag für eine Richtlinie des Rates über den Rechtsschutz von Computerprogrammen vor, der von den Interessenverbänden eingehend und kontrovers diskutiert wurde und daraufhin überarbeitet wurde17. Das EG-Parlament billigte den geänderten Entwurf der Richtlinie sodann im April 1991, so dass der Verabschiedung einer europäischen Richtlinie zum Schutz von Computerprogrammen nichts mehr im Wege stand18. Am 14.05.1991 wurde die EG-Richtlinie über den Rechtsschutz von Computerprogrammen19 vom EG-Ministerrat 12 Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 2 mit weiteren Nachweisen; Bauer, CR 1985, S. 5 ff. 13 BT-Drucks. 11/4929, S. 43. 14 Grünbuch über Urheberrecht und die technologische Herausforderung vom 23.08.1988, KOM (88) 172 endg. 15 Grünbuch über Urheberrecht und die technologische Herausforderung vom 23.08.1988, KOM (88) 172 endg. 16 Ebd., siehe auch Lehmann/Haberstrumpf, S. 75. 17 KOM (88) 816 endg.; Möhring/Nicoloni/Hoeren, Vor §§ 69 a Rn. 2; Lehmann/ Haberstrumpf, S. 75. 18 Möhring/Nicolini/Hoeren, Vor §§ 69 a Rn. 2. 19 Richtlinie 91/250/EWG des Rates vom 14. Mai 1991 über den Rechtschutz von Computerprogrammen, ABl L 122 vom 17.05.1991, 42 (= GRUR Int 1991, 5*

68

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

verabschiedet. Die EG-Richtlinie bestimmt in Art. 1, dass die Mitgliedsstaaten Computerprogramme als literarische Werke im Sinne der Berner Übereinkunft zum Schutze von Werken der Literatur und Kunst urheberrechtlich schützen ohne einen ergänzenden Rechtsschutz durch Patent-, Vertragsoder Wettbewerbsrecht auszuschließen20. Die fehlende exklusive Spezialität wird durch Art. 9 I der EG-Richtlinie ausdrücklich klargestellt21. Mit der Verabschiedung der EG-Richtlinie und der damit verbundenen Umsetzungspflicht der Mitgliedsstaaten ist die in den Mitgliedsstaaten seit den 60er Jahren geführte Diskussion nach der geeigneten Schutzform für Computerprogramme beendet worden, der Schutz von Computerprogrammen urheberrechtlich konzipiert und dadurch in das durch Konventionen international vereinbarte Urheberrechtssystem eingegliedert worden22. Die Verabschiedung der EG-Richtlinie machte auch eine Gesetzesänderung in Deutschland notwendig. 3. Rechtsentwicklung in Deutschland aufgrund der Richtlinie 91/250/EWG des Rates vom 14. Mai 1991 über den Rechtsschutz von Computerprogrammen Der deutsche Gesetzgeber hat die EG-Richtlinie zum Rechtsschutz von Computerprogrammen mit dem Zweiten Änderungsgesetz23 vom 09.06. 1993 in nationales Recht umgesetzt. Das zweite Gesetz zur Änderung des Urheberrechts ist am 24.06.1993 in Kraft getreten24. Der Gesetzgeber hat die Vorgaben aus der EG-Richtlinie in einem eigenen Abschnitt betreffend „Besondere Bestimmungen für Computerprogramme“ umgesetzt. Die §§ 69 a ff. UrhG sind somit das vorläufige Ergebnis einer langen europäischen Rechtsentwicklung25. 545). Zur Entstehungsgeschichte vgl. auch Walter, in: v. Lewinski/Walter/Blocher/ Dreier/Daum/Dillenz, Europäisches Urheberrecht Art. 1 Rn. 1 ff. Software-RL; Dreier, CR 1991, 577 ff.; Lesshaft/Ulmer, CR 1991, S. 519 ff. 20 Walter, in: v. Lewinski/Walter/Blocher/Dreier/Daum/Dillenz, Europäisches Urheberrecht Art. 1 Rn. 4 Software-RL. 21 Lehmann/Lehmann, S. 27. 22 Lehmann/Lehmann, S. 7; Walter, in: v. Lewinski/Walter/Blocher/Dreier/ Daum/Dillenz, Europäisches Urheberrecht Art. 1 Rn. 4 Software-RL; Wandtke/Bullinger/Grützmacher, Vor §§ 69 a ff. Rn. 5; zum internationalen Rechtsschutz von Computerprogrammen vgl. auch: Lehmann, CR 1996, S. 2 ff. 23 BGBl. I, 910; Möhring/Nicolini/Hoeren, Vor §§ 69 a Rn. 3; Lehmann/Haberstrumpf, S. 74; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 3. 24 Möhring/Nicolini/Hoeren, Vor §§ 69 a Rn. 3. 25 Ausführliche Darstellungen bei Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 54 Rn. 1 ff.; Lehmann/Haberstrumpf, S. 70 ff.; Loewenheim/Lehmann, § 9 Rn. 45 ff.; Schricker/Loewenheim, Vor §§ 69 a ff. Rn. 1 ff.; Wandtke/Bullinger/ Grützmacher, Vor §§ 69 a Rn. 1 ff.

I. Rechtsschutz von Computerprogrammen

69

4. Überblick über den Rechtsschutz von Computerprogrammen in Deutschland Basierend auf Art. 9 I der EG-Richtlinie bestimmt § 69 g I UrhG, dass durch die urheberrechtlichen Sondervorschriften des achten Abschnitts die Anwendung sonstiger Rechtsvorschriften auf Computerprogramme unberührt bleiben, insbesondere die über den Schutz von Erfindungen, Topographien von Halbleitererzeugnissen, Marken und den Schutz gegen den unlauteren Wettbewerb einschließlich des Schutzes von Geschäfts- und Betriebsgeheimnissen, sowie schuldrechtliche Vereinbarungen26. Dabei handelt es sich in § 69 g I UrhG keinesfalls um eine abschließende Aufzählung27. a) Schutz durch relative Rechte Computerprogramme können durch relative Rechte28 geschützt sein, ohne dass es hierbei bereits darauf ankommt, ob sie urheberrechtlich oder patentrechtlich geschützt sind. Der Schutz durch relative Rechte ist vielmehr völlig unabhängig von der Ausdrucksform oder der technischen Besonderheit eines Computerprogramms. aa) Vertragsrecht Das Vertragsrecht bietet die Möglichkeit, auch urheberrechtlich nicht geschützte Computerprogramme (auch in Fällen, in denen u. U. kein wettbewerbsrechtlicher Schutz gegeben ist) durch besondere Vereinbarungen zwischen den Parteien zu schützen, was jedoch nur zu einer schuldrechtlich zwischen den Vertragspartnern und somit relativen Wirkung führt29. Die rechtliche Gestaltung von Verträgen, insb. Softwareüberlassungsverträgen von Open Source Software wird noch im weiteren Verlauf dieser Arbeit zu besprechen sein.

26 Dreier/Schulze, § 69 g Rn. 1.; Schricker/Loewenheim, § 69 g Rn. 1; Wandtke/ Bullinger/Grützmacher, § 69 g Rn. 1. 27 Dreier/Schulze, § 69 g Rn. 1. 28 An dieser Stelle soll keine ausführliche Darstellung aller in Betracht kommenden Schutzvorschriften vorgenommen werden. Da der Schwerpunkt der Arbeit im Urheberrecht liegt, wird hier nur kurz auf einige wesentliche Punkte eingegangen. 29 Pres, S. 41, der in diesem Zusammenhang auch von Bedeutungsverlust der reinen vertraglichen Schutzlösung aufgrund der urheberrechtlichen Sondervorschriften spricht.

70

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

bb) Wettbewerbsrecht Ein weiteres Instrument für den Rechtsschutz von Computerprogrammen stellt das Wettbewerbsrecht30 dar. Art. 9 I EG-Richtlinie und der darauf basierende § 69 g I UrhG bestimmen ausdrücklich, dass der wettbewerbsrechtliche Schutz von Computerprogrammen durch die urheberrechtlichen Sonderbestimmungen nicht ausgeschlossen wird. Nach dem Kumulationsprinzip im Gewerblichen Rechtsschutz stehen vielmehr urheberrechtliche und wettbewerbsrechtliche Schutzvorschriften nebeneinander und überlagern oder ergänzen sich31. Neben einem urheberrechtlichen Schutz kann Computerprogrammen gerade auch ein wettbewerbsrechtlicher Schutz aus § 1 UWG zukommen32. Dabei schützt das Wettbewerbsrecht nicht die dem Computerprogramm zugrunde liegende Idee oder die konkrete Ausdrucksform als solche, sondern bewirkt einen mittelbaren Schutz dadurch, dass es das Ausbeuten fremder Leitungen zum Zwecke des Wettbewerbs durch den Wettbewerbsschutz gem. § 1 UWG sanktioniert33. Dem Rechteinhaber von Computerprogrammen steht in Fällen der Herkunftstäuschung durch Nachahmung und der unmittelbaren oder fast identischen Leistungsübernahme ein ergänzender wettbewerbsrechtlicher Schutz zu34. Dabei muss durch die Verletzungshandlung die wettbewerbliche Eigenart des Computerprogramms übernommen worden sein35. Jede unmittelbare identische oder nahezu identische Leistungsübernahme von fremden Arbeitsergebnissen, die für den Wettbewerb eigene Relevanz besitzen, stellt eine unlautere Wettbewerbshandlung dar, wenn kein oder kein nennenswerter eigener Aufwand zur Schaffung der Leistung erfolg ist36. Damit stellt jede unberechtigte Ver30 BGH CR 1996, S. 82; Ausführliche Darstellung bei Junker/Benecke, § 7 Rn. 109 ff.; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 57; Koch, § 11 Rn. 1 ff.; Lehmann/Lehmann, S. 383 ff.; Schneider, HER, Abschn. C Rn. 450 ff.; Walch, Ergänzender Leistungsschutz nach § 1 UWG, München 2002. 31 Lehmann/Lehmann, S. 383. 32 AmtlBegr. BT-Drucks. 12/4022, 15; Hubmann/Götting, § 50 Rn. 1.; Koch, § 11 Rn. 2. 33 Lehmann/Lehmann, S. 389. 34 OLG Hamburg, CR 1998, S. 332, 334 ff.; OLG München, CR 1991, S. 217, 219; OLG Celle, NJW-RR 1993, S. 109; LG München, CR 1986, S. 332 f.; LG Karlsruhe, CR 1990, S. 592, 594; Lehman/Lehmann, S. 388 ff.; Kilian/Heussen/ Harte-Bavendamm, CHB, Nr. 57 Rn. 7 ff.; Wandtke/Bullinger/Grützmacher, § 69g Rn. 19. 35 Wandtke/Bullinger/Grützmacher, § 69g Rn. 19. 36 BGH WRP 1976, S. 370; BGH GRUR 1986, S. 673; BGH, CR 1990, S. 188 f.; vgl. auch LG München, CR 1986, S. 332: „Ein solcher rein technischer Kopiervorgang ist als Schmarotzen an fremder Leistung jedenfalls im vorliegenden Fall unlauter i. S. v. § 1 UWG, da er ein mit wesentlichem Aufwand von der Klägerin geschaffenes Arbeitsergebnis sich in unlauterer Weise zunutze macht.“; Kilian/Heussen/

I. Rechtsschutz von Computerprogrammen

71

vielfältigung eines Computerprogramms und die Verbreitung der kopierten Version im geschäftlichen Verkehr eine Wettbewerbsverletzung dar37. Weiterhin wird auch die Beseitigung oder Umgehung von Programmsperren sowie das Anbieten oder die Verbreitung der dazu notwendigen technischen Vorrichtungen als Verstoß als unlautere Wettbewerbshandlung und somit als Verstoß gegen. § 1 UWG gesehen38. Auch kann schon der gewerbliche Vertrieb von Kopierprogrammen unlauter gem. § 1 UWG sein39. Ferner kommt ein Schutz von Geschäfts- und Betriebsgeheimnissen gem. § 17 UWG bezüglich nicht offenkundigen Informationen, wie die Konzeption, der Quellcode oder die zugrunde liegenden Algorithmen eines Computerprogramms sowie sonstige wichtige Programmdaten in Betracht40. Hat nur ein enger Personenkreis Kenntnis von Geheimnissen und besteht seitens des Herstellers ein entsprechender Geheimhaltungswille sowie ein wirtschaftliches Interesse an der Geheimhaltung macht sich ein Verletzer gem. § 17 II UWG strafbar und setzt sich darüber hinaus zivilrechtlichen Ansprüchen auf Unterlassung, Schadensersatz, Herausgabe/Beseitigung sowie gegebenenfalls Auskunft gem. §§ 1 UWG, 823 II BGB i. V. m. § 17 II UWG aus41. Das Wettbewerbsrecht schützt die Wettbewerbsordnung als solche und hat zum Ziel für potenzielle Gleichheit der Wettbewerbsbedingungen und das damit verbundene Vertrauen der Marktteilnehmer in einen funktionierenden Wettbewerb zu sorgen42. Voraussetzung jeglichen wettbewerbsrechtlichen Schutzes ist daher gem. der Generalklausel § 1 UWG grundsätzlich ein Handeln im geschäftlichen Verkehr zu Zwecken des Wettbewerbs43. Ausgehend vom Gesetzestext wird von der Rechtsprechung44 das Vorliegen Harte-Bavendamm, CHB, Nr. 57 Rn. 11 ff.; Koch, § 11 Rn. 6 ff.; Lehmann/Lehmann, S. 391; Schneider, HER, Abschn. C Rn. 462; Taeger, CR 1991, S. 450. 37 Raubenheimer, CR 1994, S. 264 mit weiteren Nachweisen. 38 BGH GRUR 1996, 78 [Umgehungsprogramm]; OLG Stuttgart, CR 1989, S. 685 mit zustimmender Anmerkung von Lehmann; OLG Düsseldorf, CR 1991, S. 352; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 57 Rn. 14; Raubenheimer, CR 1994, S. 264 ff. 39 OLG Stuttgart, CR 1989, S. 658 ff.; OLG Düsseldorf, GRUR 1990, S. 535. 40 OLG Celle, CR 1989, S. 1002 f.; OLG Frankfurt, GRUR 1989, S. 678 ff.; LG Stuttgart, NJW 1991, S. 441 f.; Raubenheimer, CR 1994, S. 266 ff.; ausführlich dazu auch Teager, CR 1991, S. 449 ff.; Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 57 Rn. 25 ff.; Schneider, HER, Abschn. C Rn. 481 ff.; Wandtke/Bullinger/ Grützmacher, § 69g Rn. 29 ff. 41 Raubenheimer, CR 1994, 264; Wandtke/Bullinger/Grützmacher, § 69g Rn. 29 ff. 42 Hubmann/Götting, § 50 Rn. 22. 43 Kilian/Heussen/Harte-Bavendamm, CHB, Nr. 57 Rn. 4. 44 BGHZ 93, 96, 97.

72

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

eines Wettbewerbsverhältnisses gefordert. Der BGH45 hat jedoch ausdrücklich festgestellt, dass an die Voraussetzung des Bestehens eines Wettbewerbsverhältnisses im „Interesse eines wirksamen wettbewerbsrechtlichen Individualschutzes“ keine hohen Anforderungen zu stellen sind. Damit werden grundsätzlich alle wettbewerbsbezogenen Verletzungshandlungen, die die wirtschaftliche Verwertung der Leistungsergebnisse angreifen sowie die Beschädigung des guten Rufes oder des Ansehens einer gewerblichen Leistung als Handlungen i. S. d. § 1 UWG zu qualifizieren sein. Anspruchsgegner für Ansprüche aus dem Wettbewerbsrecht ist somit jeder wettbewerbswidirg handelnde Störer46. Dies zeigt, dass das Wettbewerbsrecht gegenüber privaten Konsumenten, Endverbrauchern sowie betriebsinternen Handlungen grundsätzlich keine Schutzwirkung entfaltet47. Die Darstellung zum Wettbewerbsrecht könnte im Zusammenhang mit dem vorliegenden Thema Open Source Software zu der Annahme führen, dass Open Source Software aufgrund der Offenlegung und Zugänglichkeit des Quellcodes sowie der damit verbundenen bedingten Freigabe der Verwertungsrechte einem Schutz durch das Wettbewerbsrecht nicht zugänglich sei. Es sind jedoch Fallkonstellationen denkbar, in denen bestimmte Verwertungshandlungen von Open Source Software wettbewerbswidrig sein können48. Übernimmt beispielsweise jemand den Quellcode oder Teile des Quellcodes in ein eigenes Computerprogramm und tritt damit in den Wettbewerb zu Mitbewerbern, wird man von einer unlauteren Wettbewerbshandlung gem. § 1 UWG ausgehen können. Der Hersteller erwirbt einen Vorteil ohne hierfür eigene Leistungen aufgewendet zu haben. Die kommerzielle Verwertung des Quellcodes einer Open Source Software kann als fremde Leistungsübernahme somit wettbewerbswidrig sein. Auch kann die unberechtigte Verbreitung von Open Source Software als kommerzielles Computerprogramm wettbewerbswidirg sein. Auch hier liegt u. U. eine unlautere fremde Leistungsübernahme vor. Auch besteht die Möglichkeit, dass allein die Benutzeroberfläche eines Freien Computerprogramms übernommen wird. Besitzt die Benutzeroberfläche eine wettbewerbliche Eigenart, kann auch in diesen Fällen eine wettbewerbswidrige Handlung vorliegen. Ein weiteres Anwendungsgebiet des Wettbewerbsrechts im Bereich Open Source Software ist der öffentliche Bereich49. Nimmt beispielsweise die öffentliche Hand am privaten Wirtschaftsverkehr teil, muss auch sie ihr Verhalten am Wettbewerbsrecht messen lassen. Die öffentliche Hand trägt hierbei ein we45

BGH WRP 1985, 400, 401. Lehmann/Lehmann, S. 402. 47 Junker/Benecke, § 7 Rn. 109; Wandtke/Bullinger/Grützmacher, § 69g Rn. 25. 48 So auch Koch, § 11 Rn. 10; An dieser Stelle sollen mögliche Fallgruppen nur kurz angeschnitten werden. 49 Ausführlich dazu vgl. Jaeger/Metzger, S. 133 ff. 46

I. Rechtsschutz von Computerprogrammen

73

sentlich geringeres Risiko als der „freie Unternehmer“, das sie doch eine besondere Stellung innehat und über einer sichere Kapitalausstattung verfügt50. Die öffentliche Hand kann beispielsweise Eigenentwicklungen im Bereich von Computerprogrammen als Open Source Software verbreiten und tritt damit unmittelbar in Konkurrenz zu kommerziellen Anbietern. Propagiert die Behörde dabei die Vorzüge und Qualitäten ihrer Entwicklung kann ein Handeln zu Zwecken des Wettbewerbs vorliegen51. Ein Wettbewerbsverstoß kann dabei zum einen darin liegen, wenn die Behörde ihre Autorität und das Vertrauen der Bürger dazu missbraucht, das Programm am Markt zu platzieren und gegenüber kommerzieller Software zu etablieren, sowie in Fällen, in denen die öffentliche Hand außerhalb ihrer zugewiesenen Aufgaben handelt und ihr Verhalten einen funktionierenden Wettbewerb bedroht52. Ferner kommt ein Wettbewerbsverstoß in den Fällen in Frage, in denen beispielsweise kommunale Behörden Open Source Software verbreiten und dabei gegen gesetzliche Bestimmungen z. B. der Gemeindeordnung verstoßen, die ihre Wirtschaftstätigkeit gerade regeln53. Somit sind auch im Bereich Open Source Software Sachverhalte vorstellbar, in denen das Wettbewerbsrecht Anwendung findet. cc) Markenrecht Computerprogrammen kann auch ein eingeschränkter Rechtsschutz über das Markenrecht zukommen54. Durch das Inkrafttreten des MarkenG am 01.01.1995 wurde die wettbewerbsrechtliche Regelung des Titelschutzes gem. § 16 UWG a. F. durch markenrechtliche Vorschriften ersetzt55. Nach den markenrechtlichen Vorschriften kann ein Computerprogramm grundsätzlich als Marke zur Kennzeichnung der betrieblichen Herkunft eingetragen werden56. Darüber hinaus gibt das Markenrecht die Möglichkeit, ein Computerprogramm gem. §§ 5, 15 MarkenG als Werktitel zu schüt50

So auch Jaeger/Metzger, S. 133. BGH, WRP 1993, S. 917, 919; Jaeger/Metzger, S. 135. 52 Baumbach/Hefermehl, § 1 Rn. 938 mit weiteren Nachweisen; Jaeger/Metzger, S. 125. 53 Jaeger/Metzger, S. 136 mit weiterem Nachweis. 54 Ausführliche Darstellung bei: Junker/Benecke, § 9 Rn. 140 ff.; Kilian/Heussen/ Harte-Bavendamm, CHB, Nr. 56 Rn. 56 ff.; Koch, § 9 Rn. 534 ff.; Schneider, HER, Abschn. C Rn. 745 ff. 55 Vgl. Art. 25 Markenrechtsreformgesetz; Schneider, HER, Abschn. C Rn. 745; Zum Titelschutz von Computerprogrammen nach alter Rechtslage (§ 16 UWG a. F.) ausführlich Lehmann/Lehmann, S. 407 ff.; Lehmann, CR 1986, S. 373 ff. 56 BGH, GRUR 1985, S. 1055; Koch, § 9 Rn. 534; Wandtke/Bullinger/Grützmacher, § 69g Rn. 15. 51

74

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

zen57. Aus der Tatsache, dass die markenrechtlichen Neuregelungen keine Ergänzung zu Computerprogrammen in § 5 III MarkenG enthalten, ist aufgrund des erlaubten Rückgriffs auf die frühere Rechtsprechung nicht zu schließen, dass danach Computerprogramme vom Titelschutz ausgeschlossen wären58. Der Titelschutz beginnt grundsätzlich mit Verbreitung, ausnahmsweise Einführungswerbung oder Vorankündigung des Computerprogramms59. Voraussetzung für den Titelschutz eines Computerprogramms ist jedoch, dass der Werktitel des Programms Unterscheidungskraft besitzt oder diese durch Verkehrsdurchsetzung erlangt60. Das Markenrecht als Teil des Wettbewerbsrechts bezweckt die Regelung des wirtschaftlichen Wettbewerbs61. Daher setzt der markenrechtliche Schutz ein Handeln im geschäftlichen Verkehr durch den Verletzer voraus62. Das Markenrecht bezweckt einen Missbrauch einer Marke oder eines Werktitels im Geschäftsverkehr. Was den Schutz von Computerprogrammen angeht, schützt das Markenrecht somit nur die Kennzeichnung eines Computerprogramms und nicht die inhaltliche Konzeption an sich. Es vermag einem Computerprogramm ferner nur im Geschäftsverkehr gegen eine unlautere Nutzung der Kennzeichen des Programms zu schützen. Dem Markenrecht kommt mithin nur eine begrenzte Schutzfunktion in diesem Bereich zu. Da sich Open Source Software lediglich in der besonderen Lizenzierungsform von kommerzieller Software unterscheidet, ist das Markenrecht problemlos auf Open Source Software anwendbar.

57 BGH, CR 1998, S. 5; BGH, CR 1998, S. 6; BGH, GRUR 1998, S. 1010; OLG Hamburg, CR 1995, S. 335, 336, 338; OLG Hamburg, ZUM 2001, S. 514, 516; Lehmann, CR 1998, S. 2 ff.; Nach anderer Auffassung ist ein zusätzlicher Titelschutz neben dem markenrechtlichen Schutz abzulehnen (Betten, CR 1995, S. 383 ff.; Zahrnt, BB 1996, S. 1570 ff.). Der Streit, ob einem Computerprogramm neben dem markenrechtlichen Schutz auch ein Titelschutz zukommt, kann im Rahmen dieser Arbeit unentschieden bleiben. Mit der ganz herrschenden Meinung und stetiger höchstrichterlichen Rechtsprechung wird von einem Titelschutz von Computerprogrammen auszugehen sein, der auch für Open Source Software Anwendung finden dürfte. 58 OLG München, CR 1995, S. 599; Schneider, HER, Abschn. C Rn. 752; a. A. eben mit dieser Begründung Betten, CR 1995, S. 383 ff. 59 BGH, CR 1998, S. 5; BGH, CR 1998, S. 6; Koch, § 9 Rn. 536; Wandtke/Bullinger/Grützmacher, § 69g Rn. 17. 60 Schneider, HER, Abschn. C Rn. 746. 61 Hubmann/Götting, § 40 Rn. 4. 62 Hubmann/Götting, § 40 Rn. 4; Lehmann, CR 1995, S. 131.

I. Rechtsschutz von Computerprogrammen

75

dd) Zwischenergebnis Das Vertragsrecht, das Wettbewerbsrecht sowie das Markenrecht gewähren den Parteien somit nur relative Rechte, so dass der Schutz an dem Computerprogramm lediglich gegenüber den Vertragspartnern und/oder den Teilnehmern am Wettbewerbsverkehr durchsetzbar wäre63. b) Schutz durch absolute Rechte Der Schutz von Rechtspositionen durch relative Rechte hat nur eine begrenzte Wirkung und gewährt in vielen Fällen keinen hinreichenden Schutz des Rechteinhabers. Es galt daher den Rechtsschutz von Computerprogrammen durch Rechte auszugestalten, die einen absoluten und ausschließlichen Schutz gegenüber jedermann garantieren. Im Mittelpunkt der rechtspolitischen Diskussionen standen daher das Patent- und das Urheberrecht als mögliche Schutzsysteme64. Wie bereits erläutert ist die Frage, welches der beiden Regelungskomplexe für den Rechtsschutz von Computerprogrammen dogmatisch am besten geeignet ist, durch den europäischen und nationalen Gesetzgeber zugunsten des Urheberrechts entschieden worden. Die Entscheidung zugunsten des Urheberrechts bedeutet jedoch keineswegs, dass das Patentrecht für den Schutz von Computerprogrammen an Bedeutung abgenommen hat. aa) Patentrecht Das Patentrecht gewährt dem Erfinder ein ausschließliches absolutes Recht an dem Gegenstand seiner Erfindung (vgl. § 9 PatG). Im Vergleich zum Urheberrecht, dass gerade im Bereich von Computerprogrammen nicht die dem Programm zugrunde liegenden Ideen sondern die konkrete Ausdrucksform des Computerprogramms schützt, betrifft der patentrechtliche Schutz grundsätzlich die einer Erfindung innewohnende technische Lehre als solche65. Die Frage, ob Computerprogramme aufgrund ihrer Beschaffenheit überhaupt patentfähig sind, war lange Zeit heftig umstritten. 63

Lehmann/Haberstrumpf, S. 71. Lehmann/Haberstrumpf, S. 71; Eine ausführliche Diskussion, ob Computerprogramme sinnvoller patentrechtlich oder urheberrechtlich geschützt werden sollen, ist aufgrund der Entscheidung des europäischen sowie deutschen Gesetzgebers zugunsten des Urheberrechts an dieser Stelle nur noch von rein theoretischer Natur und soll nicht Gegenstand dieser Arbeit sein. 65 Kilian/Heussen/v. Falck/Plassmann, CHB, Nr. 52 Rn. 2. 64

76

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Die Möglichkeit eines Rechtsschutzes von Computerprogrammen durch das Patentrecht66 ist das Ergebnis einer langen Rechtsentwicklung, die durch umfangreiche Rechtsprechung begleitet wurde67. Der Gesetzgeber hat Computerprogrammen „als solche“ den patenrechtlichen Schutz gem. § 1 II Nr. 3, III PatG verwehrt. Danach sind Computerprogramme grundsätzlich nicht patentfähig68. Mit dieser 1980 eingeführten Regelung69 wurde die damalige Rechtsprechung70 wie auch der Meinungsstand der Literatur71 bestätigt, wonach ein patentrechtlicher Schutz für Computerprogramme nicht generell in Betracht kommen sollte72. Der Gesetzgeber ging davon aus, dass ein Computerprogramm alleine nicht als technisch eingestuft werden kann. (1) Schutzvoraussetzungen § 1 I PatG bestimmt, dass technische Erfindungen dann patentrechtlich geschützt werden können, wenn die Erfindung neu ist, auf einer erfinderischen Tätigkeit beruht und gewerblich anwendbar ist. Die Ausschlussregelung in § 1 II Nr. 3 PatG verwehrt jedoch „Programmen zur Datenverarbeitung“ ausdrücklich den patentrechtlichen Schutz73. Die Regelung entspricht Art. 52 II lit. C, III des europäischen Patentübereinkommens (EPÜ). Danach sind nur softwarebezogene Erfindungen patentierbar, soweit sie die weiteren Voraussetzungen des § 1 PatG erfüllen74. 66 Ausführlich zum patentrechtlichen Schutz von Computerprogrammen: Albrecht, CR 1998, S. 694 ff.; Kindermann, CR 1992, S. 577 ff., 658 ff.; Kilian/ Heussen/v. Falck/Plassmann, CHB, Nr. 52; Koch, § 9 Rn. 479 ff.; Lehmann/ Kraßer, S. 221 ff.; Ohly, CR 2001, S. 809 ff.; Raubenheimer, CR 1994, S. 328 ff.; Schneider, HER, Abschn. C Rn. 674 ff. 67 Der patentrechtliche Schutz von Computerprogrammen wird nicht ausführlich an dieser Stelle dargestellt. Insofern ist auf die angegeben Quellen zu verweisen. Auch die interessante Frage nach der Patentierbarkeit von Open Source Software ist Gegenstand einer eigenen Arbeit. 68 Koch, § 9 Rn. 485; Möhring/Nicolini/Hoeren, Vor §§ 69 a, Rn. 5. 69 Regelung vom 16.12.1980, BGBl. I, S. 1146. Die Vorschrift entspricht Art. 52 EPÜ vom 05.10.1973. 70 BGH GRUR 1977, S. 76. 71 Pres, S. 37 mit weiterem Nachweis. 72 Junker/Benecke, § 8 Rn. 134. 73 Die Auslegung und die Reichweite des Ausschlusstatbestandes sind noch nicht abschließend geklärt. Vgl. dazu Wiebe, in: Spindler, Abschn. F Rn. 23 ff. 74 Die Frage, inwieweit der Ausschlusstatbestand mit Art. 27 des Übereinkommens über handelsbezogene Aspekte der Rechte des geistigen Eigentums (TRIPS), der eine Ausnahme von Computerprogrammen nicht vorsieht, vereinbar ist, muss an dieser Stelle undiskutiert bleiben. Vergleiche dazu Betten, GRUR 2000, S. 1009 f. und ausführlich Schiuma, GRUR Int. 1998, S. 582 ff., die den Patentschutz von

I. Rechtsschutz von Computerprogrammen

77

Als Folge einer langen Rechtsentwicklung tendieren mittlerweile jedoch Rechtsprechung, Patentämter sowie auch die Literatur eher dazu, Computerprogramme unter bestimmten Voraussetzungen patentrechtlich zu schützen75. Trotz der deutlichen Einschränkung der Patentierbarkeit durch die Ausschlussregelung hat der Patentschutz von Computerprogrammen an Bedeutung zugenommen76. Allein im Jahr 2001 wurde in Deutschland Patentschutz für rund 500 softwarebezogene Erfindungen erteilt77. Vorteil eines patentrechtlichen Schutzes von Software ist der umfassendere Schutzbereich gegenüber dem Urheberrecht. Das Patentrecht schützt gegen jeglichen Gebrauch der der Erfindung zugrunde liegenden technischen Idee durch Dritte, wohingegen das Urheberrecht „lediglich“ die konkrete Ausdrucksform eines Werkes schützt78. Für den Bereich Software bedeutet dies, dass eine patentierte Software den Vorteil hat, dass auch das Entstehen ähnlicher Computerprogramme für den Fall verhindert werden können, dass sie auf der gleichen technischen Grundidee aufbauen. Der Urheberschutz dagegen kann nicht verhindern, dass ähnliche Programme mit lediglich unterschiedlicher Ausdrucksform hergestellt und vertrieben werden. Das Patentrecht ist somit eher dazu geeignet Wettbewerbsvorteile zu sichern. Auf der anderen Seite ist die Hürde eines patentrechtlichen Schutzes für Computerprogramme höher als die eines Urhebrechtlichen. Nicht nur, dass der Patentschutz nur aufgrund eines positiv beschiedenen Verfahrens vor dem Patentamt gem. §§ 34 ff. PatG erteilt wird, auch die materiellrechtlichen Anforderungen an die Beschaffenheit eines Computerprogramms sind relativ hoch. Kernfrage des patentrechtlichen Schutzes softwarebezogener Erfindungen ist die Frage nach dem technischen Charakter der Erfindung im konkreten Fall79. Jedes Computerprogramm ist im Einzelfall daraufhin zu überprüfen, ob es ein reines „Programm zur Datenverarbeitung“ darstellt oder als programmbezogene Erfindung die Anforderungen des § 1 PatG erfüllt und somit patentierbar ist. Die Patentfähigkeit setzt voraus, dass ein Computerprogramm der Lösung eines technischen Problems dient80. Die Frage, wann eine programmbezogene Erfindung einen technischen Charakter hat, ist Computerprogrammen „als solchen“ aufgrund von Art. 27 TRIPS ausdrücklich bejaht. 75 BGH, GRUR 2000, S. 1007; BGH, GRUR 2000, S. 498; BPatG, CR 2001, S. 155; EPA, GRUR Int. 1995, S. 909, 910 ff.; Esslinger, CR 2000, S. 502 f.; Gaster, CR 2000, S. 634 f.; Schöniger, CR 2000, S. 100 f.; Wandtke/Bullinger/Grützmacher, § 69g Rn. 9 mit weiteren Nachweisen; Wiebe, CR 2004, S. 883. 76 So auch Koch, § 9 Rn. 479. 77 Pressemitteilung des Deutschen Patent- und Markenamtes, 12. März 2002. 78 Kilian/Heussen/v. Falck/Plassmann, CHB, Nr. 52 Rn. 4. 79 BGHZ 52, 74 ff.; Junker/Benecke, § 8 Rn. 135; Koch, § 9 Rn. 492; Schneider, HER, Abschn. C Rn. 625. 80 Junker/Benecke, § 8 Rn. 137.

78

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

äußerst schwierig zu klären, da Computerprogramme ihrer „Natur“ nach immer technische Abläufe betreffen ohne das diese aber zwangsläufig mit einer Erfindung in Bezug stehen müssen81. Mit der Auslegung der Frage nach der „technischen Erfindung“ hat sich die Rechtsprechung ausführlich beschäftigt82. Die „frühe“ Rechtsprechung des BGH forderte für das Erfordernis des technischen Charakters, dass der Kern der Erfindung technischen Charakter haben muss (sog. Kerntheorie)83. Der BGH nahm in diesem Zusammenhang eine Beurteilung der einzelnen Merkmale der Erfindung vor und untersuchte sie daraufhin, ob deren Kern für sich betrachtet eine technische Lösung enthielt84. Nur wenn der Kern der Problemlösung technische Merkmale aufweise, sei ein technischer Charakter zu bejahen. Die Kerntheorie der Rechtsprechung hatte aufgrund dieser strengen Anforderungen zur Konsequenz, dass viele Computerprogramme nicht als patentfähig angesehen wurden85. Das EPA lehnte eine derartig zergliederte Beurteilung ab86. Es beurteilte die Frage nach der Technizität entsprechend ihrer Prüfungsrichtlinien anhand der Gesamtheit einer Erfindung87. Besteht eine Erfindung danach aus technischen sowie untechnischen Merkmalen, können die untechnischen Merkmale nicht dazu führen, dass die Erfindung ihrer Gesamtheit nach nicht als technisch angesehen wird88. Obwohl der BGH diese Rechtsauffassung lange nicht geteilt hat, hat er sich bei der Beantwortung der Frage nach der Technizität eines Computerprogramms schließlich auch auf die sog. „Theorie der Gesamtbetrachtung“ festgelegt89. Nach der „Gesamtbetrachtung“ sind Computerprogramme somit patentfähig, wenn der Gegenstand der Patentanmeldung insgesamt technischen Charakter hat90. Dieser Schritt hin zur Gesamtbetrachtung war wesentlich für die Ausweitung des Patentschutzes von Computerprogrammen91. 81

Koch, § 9 Rn. 492. Eine ausführliche Darstellung der Entwicklung der Rechtsprechung findet sich bei Koch, § 9 Rn. 492 ff.; Lehmann/Krasser, S. 238 ff.; Schneider, HER, Abschn. C Rn. 680 ff.; Zur Spruchpraxis des Europäischen Patentamts (EPA) ausführlich Schneider, HER, Abschn. C Rn. 693 ff. 83 BGH, GRUR 1977, S. 96 ff.; BGH, GRUR 1978, S. 102 ff.; BGH, GRUR 1981, S. 32 ff.; Koch, § 9 Rn. 496; Kotthoff, in: HK-UrhR, § 69g Rn. 3; Ohly, CR 2001, S. 811. 84 Kindermann, CR 1992, S. 662. 85 Koch, § 9 Rn. 497; zur Kritik an der Kerntheorie vgl. auch Ohly, CR 2001, S. 811. 86 EPA, CR 1986, S. 537 ff.; Kindermann, CR 1992, S. 663. 87 Kindermann, CR 1992, S. 663. 88 EPA, CR 1987, S. 671 ff. 89 BGH, CR 1992, S. 600 ff. mit Anmerkung Betten, CR 1992, S. 603; Albrecht, CR 1998, S. 694 ff.; Kindermann, CR 1992, S. 663; Koch, § 9 Rn. 498 mit weiteren Nachweisen; Ohly, CR 2001, S. 811 f.; Raubenheimer, CR 1994, S. 332 ff. 90 Kotthoff, in: HK-UrhR, § 69g Rn. 3. 82

I. Rechtsschutz von Computerprogrammen

79

(2) Aktuelle Entwicklungen im Patentrecht Auf europäischer Ebene ist die Frage nach patentrechtlichem Schutz von Computerprogrammen von besonderer Aktualität. Obwohl das EPA wie auch die nationalen Patentämter der Mitgliedsstaaten was die Erteilung von Patenten angeht, denselben Rechtsvorschriften unterliegen, wird die gegenwärtige Rechtslage in der Europäischen Union auf diesem Gebiet als unsicher beurteilt92. Die nationalen Patentämter sowie das EPA haben im Lichte der nationalen und europäischen Ausschlussregelung für Computerprogramme „als solche“ mittlerweile tausende von Patenten für computerimplementierte Erfindungen erteilt93. Trotzt vergleichbarer Rechtsvorschriften besteht zwischen den einzelnen Mitgliedsstaaten wie auch zwischen EPA und den Mitgliedsstaaten ein erheblicher Anwendungsunterschied in der Rechtspraxis, d. h. dass die genauen Bedingungen der Patentierbarkeit voneinander abweichen können94. Obwohl die EU-Mitgliedsstaaten als solche an das Europäische Patentübereinkommen (EPÜ) gebunden sind und folglich ihre Patentgesetze damit übereinstimmen müssen, besteht in der Praxis keine einheitliche bindende Struktur, so dass einzelne Aspekte des Patenrechts unterschiedlich ausgelegt werden95. Es besteht somit die Möglichkeit, dass bestimmte softwaregestützte Erfindungen in einem Mitgliedsstaat patentrechtlich geschützt werden, in anderen nicht. Da auch die europäische Kommission die hohe Bedeutung des Patentrechtes für die Softwareentwicklung und die Notwendigkeit einer Harmonisierung der Rechtsanwendung im Hinblick auf einen funktionierenden Binnenmarkt gesehen hat, hat sie im Februar 2002 auf der Grundlage von Art. 95 EGV einen Vorschlag für eine Richtlinie über die Patentierbarkeit computerimplementierter Erfindungen96 vorgelegt97. Ziel der Richtlinie ist es, für eine einheitliche Anwendung der Rechtsvorschriften in den Mitgliedsstaaten zu sorgen, um negative Auswirkungen auf Investitionsentscheidungen und damit auf die Freiheit des Wa91

So auch Koch, § 9 Rn. 498. Zur Frage nach der Patenfähigkeit einzelner Softwaretypen vgl. Koch, § 9 Rn. 514 ff. 92 Begründung des Vorschlags für eine Richtlinie über die Patentierbarkeit computerimplementierter Erfindungen, KOM (02) 92 endg., ABl C 151 E vom 25. Juni 2002. 93 Vgl. Begründung zum Richtlinienentwurf: KOM (2002) 92 endg.; Seit InKraft-Treten des EPÜ im Jahr 1978 sind über 30.000 softwarebezogene Patente vom Europäischen Patentamt und den nationalen Patentämtern erteilt (Röttinger, CR 2002, S. 616). 94 Ebd. 95 Vgl. auch Röttinger, CR 2002, S. 616. 96 Vorschlag für eine Richtlinie über die Patentierbarkeit computerimplementierter Erfindungen, KOM (02) 92 endg., ABl C 151 E vom 25. Juni 2002. 97 Ausführlich dazu Metzger, CR 2003, S. 313 ff.; Röttinger, CR 2002, S. 616 ff.

80

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

renverkehrs im Binnenmarkt aufgrund einer unterschiedlichen Rechtspraxis zu vermeiden98. Bei der Neuregelung des patentrechtlichen Schutzes computerimplementierter Erfindungen steht die Harmonisierung der Rechtsanwendung, nicht eine Ausweitung des der Patentierbarkeit von Computerprogrammen „als solche“ im Mittelpunkt99. Die Mitgliedsstaaten sind nach dem Richtlinienvorschlag verpflichtet durch entsprechende Normen sicherzustellen, dass eine computerimplementierte Erfindung patentierbar ist, „sofern sie gewerblich anwendbar und neu ist und auf einer erfinderischen Tätigkeit beruht“ (Art. 4 Nr. 1). Mit der Richtlinie hält die Kommission an der Schutzvorrausetzung eines „technischen Beitrag“ fest (Art. 4 Nr. 2), der in Art. 2 (b) als Beitrag „zum Stand der Technik auf einem Gebiet der Technik, der für eine fachkundige Person nicht nahe liegend ist“, definiert ist. Ferner ist nach Art. 4 Nr. 3 des Richtlinienvorschlags die Ermittlung des technischen Beitrages anhand einer Gesamtbetrachtung vorzunehmen, bei der zu prüfen ist, inwieweit sich „der Gegenstand des Patentanspruchs in seiner Gesamtheit, der sowohl technische als auch nichttechnische Merkmale aufweisen kann, vom Stand der Technik abhebt“. Die Kommission hat damit – ausgehend von der EPA-Spruchpraxis – die Theorie der Gesamtbetrachtung in dem Vorschlag der Richtlinie festgeschrieben. Ferner hat die Kommission in Art. 6 des Richtlinienvorschlags ausdrücklich bestimmt, dass die Regelungen der Richtlinie einen urheberrechtlichen Schutz von Computerprogrammen unberührt lassen. Der Vorschlag der Kommission und die Begründung des Vorhabens zeigen, dass es der Kommission nicht um die Ausweitung eines Patentschutzes für Software geht, sondern in erster Linie um die Festschreibung der Spruchpraxis des EPA100. Der Vorschlag für eine Richtlinie zum Schutz computerimplementierter Erfindungen ist ein notwendiger Schritt um Rechtssicherheit in der Frage der Patentfähigkeit von Computerprogrammen auf europaweit zu erreichen. Ob die geplanten Neuerungen zu der gewünschten Harmonisierung führen und ob sie eine Ausweitung oder Abnahme der Patentierung von Computerprogrammen nach sich ziehen bleibt abzuwarten und wird erst nach Umsetzung der Richtlinie in nationales Recht anhand der Spruchpraxis zu beurteilen sein. Jedenfalls ist zu begrüßen, dass die Kommission die Notwendigkeit sieht, die Wirkungen einer entsprechenden Richtlinie zu beobachten und dementsprechend dem Europäischen Parlament und dem Rat über die Auswirkungen einer entsprechenden Richtlinie zu berichten (Art. 7 und 8 des Richtlinienentwurfs).

98

Vgl. Begründung zum Richtlinienentwurf: KOM (2002) 92 endg., S. 2 ff. Vgl. Begründung zum Richtlinienentwurf: KOM (2002) 92 endg., S. 12. 100 So auch Metzger, CR 2003, S. 313. 99

I. Rechtsschutz von Computerprogrammen

81

(3) Open Source Software und Patentrecht Das Patentrecht und die Rechtsentwicklung auf diesem Gebiet betrifft auch Open Source Software101. Der Entwurf der Richtlinie über den patentrechtlichen Schutz computerimplementierter Erfindungen hat zu heftigen Diskussionen unter Open Source-Programmierern geführt102. Die Entwickler wie auch Unternehmen im Bereich Open Source Software sehen die Gefahr, dass mit der Verabschiedung einer entsprechenden Richtlinie die Patentpraxis von computerimplementierten Erfindungen zum Nachteil von Open Source Software erheblich ausgeweitet wird103. Angesichts des ausdrücklichen Hinweises der Kommission, den Patentschutz von Computerprogrammen durch eine Richtlinie nicht ausweiten zu wollen, erscheint der Protestlauf gegen Brüssel als überzogen. Durch die jetzige Rechtspraxis, um deren Festschreibung es in der Richtlinie geht, scheint die rasante Entwicklung von Open Source Projekten nicht behindert oder gefährdet zu sein. Vielmehr hat die Entwicklung von Open Source-Projekten parallel zu einer gleichzeitig wachsenden Zahl von Patentanmeldungen computerimplementierter Erfindungen stattgefunden. Die Wirkung eines Patentschutzes auf die Existenz und Entwicklung von Open Source Software ist daher differenziert zu beurteilen. So kann das Bestehen eines Patentschutzes von computerimplementierten Erfindungen zum einen die Existenz und das Fortbestehen von Open Source Software bedrohen, zum anderen kann der Patentschutz für das Bestehen von Open Source Software nützlich sein104. Eine Bedrohung kann sich beispielsweise daraus ergeben, dass durch die Patentierung kommerziell vertriebener Computerprogramme die Möglichkeit ausscheidet, technisch vergleichbare Programme als Open Source Software zu entwickeln und zu vertreiben. Damit bestünde die Möglichkeit, Open Source Software hinsichtlich bestimmter Softwarelösungen als Alternative zu kommerziellen Programmen zu verhindern. Die Möglichkeit einer Patentierung von Open Source Software-Lösungen kann sich andererseits als nützlich erweisen. Sie kann im konkreten Fall verhindern, dass kommerzielle Anbieter ein Konkurrenzprodukt auf den Markt bringen. Dies führt zu einem Vorsprung und bietet aufgrund der Alternativlosigkeit die Möglichkeit, Kunden an ein Open Source Produkt zu binden. Teilweise wird je101

Ausführlich dazu Wiebe, in: Spindler, Abschn. F Rn. 1 ff. Metzger, CR 2003, S. 312 f. 103 Ebd. 104 Für eine differenzierte Bertachtung vgl. auch ausführlich Wiebe, in: Spindler, Abschn. F Rn. 64. Wiebe kommt allerdings zu der Annahme, dass sich der Patentschutz von Software mit dem Open Source Entwicklungsmodell nicht verträgt und schlägt daher Lösungsmodelle für eine mögliche Koexistenz von Open Source Software und Patentrecht vor. (Abschn. F Rn. 75). 102

6 Teupen

82

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

doch behauptet, dass der „Open Source“-Ansatz gerade die Anmeldung von Patenten ausschließt105. Dass die Entwicklung von Open Source Software jedoch nicht diametral zum Patentrecht steht, geht unter anderem auch aus der weit verbreiteten GPL-Lizenz, die speziell für Open Source Software entwickelt wurde, hervor. Zwar spricht diese Lizenz in ihrer Präambel von einer Bedrohung von Open Source Software durch Softwarepatenten, ermöglicht aber andererseits patentrechtlichen Schutz auch für Open Source Software, wenn gewährleistet ist, dass das Patent für eine freie Nutzung lizenziert wird und somit eine freie Benutzbarkeit der Software durch Dritte gewährleistet ist106. Das zeigt, dass die Möglichkeit eines patentrechtlichen Schutzes von Open Source auch von den Initiatoren, die die GPL unterstützen, selbst gesehen worden ist und von ihnen grundsätzlich als Schutzform akzeptiert wird. Das Patentrecht kann gerade im Bereich von Open Source Software auch als ein rechtliches Instrument eingesetzt werden, dass ein Open Source Projekt weitgehend absichert. Da der Schutzumfang des Patentrechts weiter geht als der des Urheberrechts, ist es möglich, kommerzielle Produkte trotz anderen Ausdrucksformen in einem bestimmten Bereich zu verhindern, wenn sie auf einer vergleichbaren technischen Idee beruhen. Problematisch in diesem Zusammenhang ist allerdings, ob man bei einer kollektiven offenen Softwareentwicklung wie im Bereich der freien Software von Neuheit einer Erfindung gem. § 3 I PatG sprechen kann und ob eine notwendige Geheimhaltung bis zur Anmeldung bei einem nicht klar abgrenzbaren Entwicklungsbereich zu gewährleisten ist. Dabei sind die der Erfindung zugrunde liegenden technischen Lehren „neuheitsschädlich“, wenn sie zu irgendeinem Zeitpunkt vor dem maßgeblichen Tag der Patentanmeldung irgendwo in der Welt in irgendeiner Weise der Öffentlichkeit zugänglich gemacht worden sind107. Bei einem Projekt, an dem ein offener nicht abgrenzbarer Personenkreis beteiligt ist, wird man die Voraussetzung der Neuheit daher wohl nicht annehmen können. Bis ein Programmierergebnis vorliegt, ist davon auszugehen, dass gerade aufgrund der Nutzung der Kommunikationsmittel bei einer dezentralen offenen Entwicklung die zugrunde liegende technische Lehre einer breiten Fachwelt zugänglich gemacht worden ist. Andererseits kann Open Source Software auch in einem kleineren bestimmbaren Kreis von Programmierern entstehen, so dass das die technische Lehre nicht vor dem Anmeldetag einer Öffentlichkeit zu105

So Kilian/Heussen/v. Falck/Plassmann, CHB Nr. 52 Rn. 4. GPL-Preamble: „Finally any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all.“ 107 Hubmann/Götting, § 9 Rn. 1. 106

I. Rechtsschutz von Computerprogrammen

83

gänglich ist und somit die Voraussetzungen des § 3 I PatG zu erfüllen wären. Ferner haben Programmierer von Open Source Software die Möglichkeit durch die schnelle Veröffentlichung und Verbreitung ihrer Entwicklungsergebnisse eine Patentanmeldung einer neuen Erfindung gem. § 3 PatG zu verhindern108. Ein Versuch die Software nachträglich zu patentieren, würde an § 3 I PatG scheitern. Es bleiben somit erhebliche Zweifel, ob das bestehende Patentrecht wie auch die geplanten rechtspolitischen Neuerungen auf europäischer Ebene wirklich eine Bedrohung für Open Source Software darstellt. Da auch die geplante Richtlinie zum patentrechtlichen Schutz computerimplementierter Erfindungen augenscheinlich nicht zu einer Ausweitung des Patentschutzes von Computerprogrammen führen wird, ergibt sich auch für die Entwicklung von Open Source Software keine neue Situation. Das Patentrecht dürfte die Entwicklung von Open Source somit auch in Zukunft nicht mehr beeinträchtigen als es das in der Vergangenheit getan hat. Die Diskussion dreht sich letztlich wohl eher um die Frage, ob ein Gewerblicher Rechtsschutz (insb. das Patentrecht) insgesamt Innovationen und Entwicklungen behindert oder unmöglich macht. Diese interessante und nach wie vor aktuelle Frage wird hier und jetzt jedoch nicht abschließend zu klären sein109. Sie ist nicht in erster Linie rechtlicher Natur, sondern Thema einer sozialpolitisch orientierten Untersuchung. bb) Urheberrecht Mit der Einführung der „Besonderen Bestimmungen für Computerprogramme“ in den §§ 69 a UrhG ff. hat sich der deutsche Gesetzgeber ausgehend von der europäischen Rechtentwicklung dafür entschieden, das Urheberrecht zur zentralen Regelungsmaterie für den Rechtsschutz von Computerprogrammen zu machen110. Dass Computerprogramme urheberrechtlich schutzfähig sind, ist ausführlich diskutiert worden111 wird aber mittlerweile weder von Rechtsprechung noch von der Literatur in Abrede gestellt112. Das Urheberrecht ist allgemein als vorrangiges Schutzrecht für 108 So auch Wiebe, CR 2004, S. 886, der sich für die Einrichtung einer entsprechenden Dokumentationsstelle ausspricht. 109 Vgl. dazu aber beispielsweise verschiedene Beiträge bei Schricker/Dreier/ Kur, Geistiges Eigentum im Dienst der Innovation, Baden-Baden 2001. 110 Zur ausführlichen Darstellung des urheberrechtlichen Schutzes von Computerprogrammen vgl.: Lehmann/Haberstrumpf, S. 69 ff.; Junker/Benecke, Rn. 4 ff.; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 1 ff.; Koch, § 9 Rn. 1 ff. 111 Vgl. Pres, S. 22 mit ausführlichen Nachweisen. 112 Loewenheim/Lehmann, § 9 Rn. 46; Schricker/Loenwenheim, Vor. §§ 69 a ff. Rn. 7; Lehmann/Haberstrumpf, S. 85 ff.; Kilian/Heussen/Harte-Bavendamm, CHB, 6*

84

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Computerprogramme anerkannt. Der urheberrechtliche Schutz von Computerprogrammen bedarf zudem keines eindeutigen Entstehungsaktes, sondern er besteht mit Fertigstellung eines Computerprogramms. (1) Computerprogramm als „Sprachwerk“ Computerprogramme werden als Sprachwerke in § 2 I Nr. 1 UrhG ausdrücklich als urheberrechtlich geschützten Werktyp aufgeführt. Dabei stellt § 2 II UrhG klar, dass ein Schutz der in Abs. I genannten Werke nur dann in Betracht kommt, wenn es sich um eine persönliche geistige Schöpfung handelt. Der Urheberrechtsschutz knüpft somit an die Individualität eines Werkes an113. Die rechtliche Ausgestaltung des Urheberrechtsschutzes im Einzelnen ist korrespondierend zu § 2 I Nr. 1 UrhG im 8. Abschnitt des UrhG geregelt. (2) Schutzgegenstand In § 69 a UrhG wird der Schutzgegenstand und die Schutzhöhe von Computerprogrammen geregelt. Gem. §§ 2 II i. V. m. 69 a III, IV UrhG kommt einem Computerprogramm ein urheberrechtlicher Schutz zu, wenn es die vier Elemente des urheberrechtlichen Werkbegriffs in sich vereint, d. h. es muss sich um eine persönlich Schöpfung handeln, geistigen Inhalt in einer äußerlich wahrnehmbaren Formgebung ausdrücken und die Individualität des Autors kennzeichnen114. § 69 a III UrhG stellt zudem in Satz 2 ausdrücklich klar, dass zur Bestimmung der Schutzfähigkeit keine zusätzlichen qualitativen oder sonstige die Schutzanforderungen erhöhende Kriterien herangezogen werden dürfen. Wer im Rahmen des 8. Abschnitts des UrhG eine Definition von „Computerprogrammen“ vermutet, wird vom Gesetzgeber enttäuscht sein, andererseits aber verstehen, dass der Gesetzgeber klug beraten war, aufgrund des schnellen technischen Fortschritts gerade im Bereich der Informationstechnologie auf eine konkrete Definition im Gesetz zu verzichten115. Schutzgegenstand des Gesetzes sind gem. § 69 a I UrhG Computerprogramme „in jeder Gestalt“ einschließlich ihres Entwurfmaterials. Die geNr. 51; Koch, § 9 Rn. 4 ff.; Schack, Rn. 176 ff.; Marly, Rn. 127 ff.; Broy/Lehmann, GRUR 1992, S. 419 ff.; Lehmann, CR 1992, S. 324 ff. 113 Wandtke/Bullinger/Bullinger, § 2 Rn. 2. 114 Loewenheim/Lehmann, § 9 Rn. 50; Einzelheiten dazu bei Lehmann/Haberstrumpf, S. 88 ff. 115 BT-Drucks. 12/4022, S. 9.; Möhring/Nicolini/Hoeren, § 69 a Rn. 2; Zum Versuch einer Definition vgl. Abschnitt II dieser Arbeit.

I. Rechtsschutz von Computerprogrammen

85

wählte Formulierung sowie der bewusste Verzicht des Gesetzgebers auf eine Definition sprechen dafür, dass der Gesetzgeber mit dieser Vorschrift einen weiten und umfassenden Schutz von Computerprogrammen bezweckt116. Die Formulierung „in jeder Gestalt“ stellt klar, dass es bezüglich der Schutzfähigkeit nicht auf die Form des Programmträgers ankommt, sondern auf die äußere Gestalt des Programms117. Allein die konkrete Ausdrucksform kommt für die Beurteilung des urheberrechtlichen Schutzes von Computerprogrammen in Betracht118. Inhaltliche Gestaltungselemente werden nur insofern berücksichtigt, als dass sie in der äußerlichen Form zum Ausdruck kommen119. (a) Entwurfsmaterial Darüber hinaus wird nach § 69 a I UrhG auch das Entwurfsmaterial urheberrechtlich geschützt. Nach der Gesetzesbegründung ist unter „Entwurfsmaterial“ jedes Material zu verstehen, das aufgrund seiner konkreten Beschaffenheit zulässt, dass ein Computerprogramm entsteht120. Dabei ist das Entwurfsmaterial das Ergebnis der jeweiligen Arbeitsphasen der Programmentwicklung121. Unter Entwurfsmaterial i. S. d. § 69 a I UrhG lassen sich daher eine anfängliche Problemanalyse, ein vorhandener Datenflussplan122 oder Programmablaufplan fassen123. Nicht zu Verwechseln mit dem Entwurfsmaterial sind die Dokumentation, Handbücher oder sonstige Bedienungsanleitungen eines Computerprogramms. Da das reine Begleitmaterial i. d. R. nach abgeschlossener Programmprogrammierung erstellt wird, kann es schon aus diesem Grund kein Entwurfsmaterial sein124. Diesen Medien kann aber unter Umständen ein urheberrechtlicher Schutz als Sprachwerk gem. § 2 I Nr. 1 UrhG oder als wissenschaftliche oder technische Darstellung gem. § 2 I Nr. 7 UrhG zukommen125. In diesem Zusammenhang ist 116 So auch Junker/Benecke, Rn. 30; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 15. 117 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 15.; Junker/Benecke, Rn. 30; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 4. 118 BGH, CR 1985, S. 22 ff., 30; Loewenheim/Lehmann, § 9 Rn. 51. 119 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 15. 120 BT-Drucks. 12/4022, S. 9. 121 Zu den verschiedenen Phasen der Entwicklung eines Computerprogramms vgl. BGHZ 94, 267, 282 f. 122 Koch, § 9 Rn. 55. 123 BGHZ 94, 267, 282 f.; Möhring/Nicolini/Hoeren, § 69 a Rn. 4.; Kotthoff, in: HK-UrhR, § 69 a Rn. 14. 124 Koch, § 9 Rn. 57. 125 Kotthoff, in: HK-UrhR, § 69 a Rn. 15; Möhring/Nicolini/Hoeren, § 69 a Rn. 4; LG Köln, CR 1994, S. 227 f.

86

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

fraglich, ob auch ein Pflichtenheft als Entwurfsmaterial einzuordnen ist126. Ein Pflichtenheft dient der Darstellung von besonderen Funktionen eines Computerprogramms127. In der Regel wird es im Hinblick auf die Endbewertung eines fertig programmierten Programms erstellt und dient der Konkretisierung der Aufgabenstellung. Als Leistungsverzeichnis eines Computerprogramms dient es zugleich als Leistungsmaßstab, an dem sich ein Programmierer als Auftragsnehmer messen lassen muss128. Aufgabe eines Pflichtenheftes ist es zumeist, die Vereinbarungen von Parteien über die Soll-Beschaffenheit eines Computerprogramms festzuhalten, damit im Streitfall, gerade im Bereich von Verträgen über Individualsoftware Klarheit über die Vertragspflichten besteht. Das Pflichtenheft kann grundsätzlich auch nach Fertigstellung eines Computerprogramms erstellt werden. Dies wird i. d. R. jedoch im Interesse der Parteien nicht passieren. Jedenfalls ist ein Pflichtenheft grundsätzlich nicht so detailliert, dass es beispielsweise Problemanalyse und/oder einen Programmablaufplan enthält. Es ist daher im Normalfall nicht davon auszugehen, dass sich ein Pflichtenheft unter den Begriff „Entwurfsmaterial“ i. S. d. § 69 a I UrhG subsumieren lässt. Unberührt bleibt aber die Möglichkeit eines urheberrechtlichen Schutzes als Sprachwerk (§ 2 I Nr. 1 UrhG) oder als Darstellung wissenschaftlicher oder technischer Art (§ 2 I Nr. 7 UrhG). (b) Schutz als Ausdrucksform Der Umfang eines gewährten Urheberrechtsschutzes wird in § 69 a II UrhG konkretisiert. Im Gegensatz zu dem weit formulierten Schutzumfang des § 69 a I UrhG ist die Subsumtion einzelner Elemente unter den Abs. 2 mit größeren Abgrenzungsschwierigkeiten verbunden. Ob etwa ein Element eines Computerprogramms eher als eine gem. § 69 a II UrhG geschützte Ausdrucksform oder eine ungeschützte Idee oder Grundsatz einzuordnen ist, hat der Gesetzgeber bewusst nicht geregelt sondern behält die Lösung im Zweifelsfall der Rechtsprechung vor129. Gem. § 69 a II S. 1 UrhG gilt der urheberrechtliche Schutz für alle Ausdrucksformen eines Computerprogramms130. Die einem Computerprogramm zugrunde liegenden Ideen sollen gem. § 69 a II S. 2 UrhG hingegen nicht geschützt werden. 126 Für die Einordnung eines Pflichtenheftes als Entwurfsmaterial vgl. Junker/ Benecke, Rn. 31; Fromm/Nordemann/Vinck, § 69 a Rn. 4; a. A.: Koch, § 9 Rn. 58; Möhring/Nicolini/Hoeren, § 69 a Rn. 4; Lesshaft/Ulmer, CR 1993, S. 607, 609; Wantke/Bullinger/Grützmacher, § 69 a Rn. 9. 127 OLG Düsseldorf, CR 1994, S. 404. 128 Intveen/Lutz, CR 2003, S. 640. 129 BT-Drucks. 12/4022, S. 9; Koch, § 9 Rn. 27; Marly, Rn. 143.

I. Rechtsschutz von Computerprogrammen

87

Die wohl wesentlichste Ausdrucksform eines Computerprogramms ist die Form, in der der Code vorliegt. So werden Objektcode und der Quellcode (Sourcecode) als Ausdrucksform eines Computerprogramms wie auch mögliche Vorstufen der Programmierung gem. § 69 a II S. 1 UrhG geschützt131. Streitig ist die Frage, ob die Benutzeroberfläche132 eines Computerprogramms auch als Ausdrucksform gem. § 69 a II S. 1 UrhG urheberrechtlich geschützt sein kann oder sie eher gem. des Schwerpunktes der Gestaltung einer bestimmten Werkart zuzuordnen ist und somit ein eigenständiges Werk bildet133. Der Begriff der „Benutzeroberfläche“ kann als visuelle Informationsquelle bezüglich der Funktion und Bedienung eines Programms verstanden werden. Ausgehend von König hat die Rechtsprechung den Begriff der Benutzeroberfläche als „Art und Weise der Bedienung des Programms sowie die Art der Informationsausgabe bzw. -darstellung“ definiert134. Damit ist die Benutzeroberfläche eine Art Schnittstelle zwischen dem Programmbenutzer und dem eigentlichen Programm. Von der Benutzeroberfläche als solche sind die Displays zu unterscheiden, die erst in ihrer Gesamtheit eine zusammenhängende Benutzeroberfläche bilden135. § 69 a II UrhG dient der Abgrenzung der Ausdrucksform zu den Ideen und Grundsätzen, die einem Element eines Computerprogramms zugrunde liegen können. Der Gesetzgeber hat es jedoch unterlassen, hierfür genaue Abgrenzungskriterien zu entwickeln und in den Gesetzestext mit aufzunehmen. Vielmehr hat er der Rechtsprechung aufgetragen, die Frage nach der Abgrenzung zu lösen. Nach einem Teil der Literatur136 und der Rechtsprechung137 sind Benutzeroberflächen als Ausdrucksform eines Computerprogramms gem. § 69 a I, 130 Einen ausführlichen Überblick über die einzelnen Programmteile und -formen bietet Koch, § 9 Rn. 88 ff. An dieser Stelle sollen nur exemplarisch einige Beispiele besprochen werden. 131 BT-Drucks. 12/4022, S. 9; Dreier/Schulze, § 69 a Rn. 12; Kilian/Heussen/ Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 15; Koch, § 9 Rn. 28; Kotthoff, in: HKUrhR, § 69 a Rn. 17; Möhring/Nicolini/Hoeren, § 69 a Rn. 5; Wandtke/Bullinger/ Grützmacher, § 69 a Rn. 10, 11; Schricker/Loewenheim, § 69 a Rn. 10. 132 Engl.: user interface – in der Informatik auch als „Graphical User Interface“ bezeichnet. Man versteht darunter den Teil eines Betriebssystems oder eines Anwendungsprogramms, der dem Nutzer die Kommunikation mit dem Programm ermöglicht, also die Schnittstelle zwischen Mensch und Maschine. Synonym werden auch die aus dem amerikanischen Rechtskreis stammenden Begriffe wie „user interface“ und „look and feel“ benutzt; Vgl. auch Lehmann/Schlatter, S. 202. 133 Junker/Benecke, Rn. 36; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 32; ausführlich zu dieser Frage vgl. Koch, § 9 Rn. 40 ff.; ders., GRUR 1991, S. 180 ff. 134 LG Nürnberg-Fürth, jur-pc 1992, 1557, 1560. 135 Koch, GRUR 1991, S. 180.

88

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

II S. 1 UrhG urheberrechtlich geschützt. Nach dieser Auffassung ist ein Schutz sowohl als Ausdrucksform des generierten Computerprogramms gem. §§ 2 I Nr. 1, 3. Var, 69 a I, II S. 1 UrhG als auch als sonstige Werkart gem. § 2 I UrhG möglich138. Gerade in der Benutzeroberfläche eines Computerprogramms würde dieses zum Ausdruck gebracht und für den Benutzer wahrnehmbar139. Die Tatsache, dass der Gesetzgeber mit dem Verzicht auf eine Definition von „Computerprogrammen“ einen weiten Schutz bezweckt und die Erstreckung des Schutzes auf sämtliche Ausdrucksformen normiert habe, spreche dafür, auch die von Quellcode generierte Benutzeroberfläche als Ausdrucksform zu schützen. Die wohl überwiegende Meinung in der Literatur140 sowie ein Teil der Rechtsprechung141 lehnt die Anerkennung eines urheberrechtlichen Schutzes von Benutzeroberflächen als Ausdrucksform eines Computerprogramms ab. Nach dieser Ansicht wird die Benutzeroberfläche nicht schon durch das zugrunde liegende Pogramm sondern erst durch den Pogrammablauf erzeugt und sondern ist erst das Ergebnis des Pogrammablaufs142. Ausschlaggebend für die Ablehnung eines urheberrechtlichen Schutzes von Benutzeroberflächen als Ausdrucksform eines Computerprogramms ist nach dieser Ansicht vor allem die Tatsache, dass die Möglichkeit besteht, dieselbe Benutzeroberfläche mit verschiedenen Computerprogrammen darzustellen143. 136 Mit ausführlicher Begründung Koch, § 9 Rn. 40 ff.; Möhring/Nicolini/Hoeren, § 69 a Rn. 6; Fromm/Nordemann/Vinck, § 69 a Rn. 2. 137 OLG Karlsruhe, CR 1994, S. 607 ff. 138 Koch, § 9 Rn. 43. 139 Koch, § 9 Rn. 44. 140 Dreier/Schulze, § 69 a Rn. 16; Fromm/Nordemann/Vinck, § 69 a Rn. 3; Günther, CR 1994, S. 611 ff.; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 32; Kotthoff, in: HK-UrhR, § 69 a Rn. 9; Schricker/Loewenheim, § 69 a Rn. 26; Raubenheimer, CR 1994, S. 70 f.; Schack, Rn. 179; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 14; Lehmann/Haberstrumpf, S. 87 mit Verweis auf Lehmann/ Schlatter, S. 202 ff. 141 OLG Düsseldorf, CR 2000, S. 184 ff. Das Urteil des OLG Düsseldorf befasste sich mit der Zulässigkeit des sog. Framing. In der Entscheidung ging es um die urheberrechtliche Schutzfähigkeit von HTML-programmierten Internetseiten. Obwohl es sich zumindest bei HTML-programmierten Internetseiten schon um kein Computerprogramm i. S. d. §§ 69 a UrhG handelt, stellte das Gericht ohne zwingende Notwendigkeit fest, dass das durch ein Computerprgramm hervorgebrachte und auf dem Bildschirm sichtbare Arbeitsergebnis keine Ausdrucksform des Computerprogramms i. S. d. § 69 II S. 1 UrhG darstellt und ihm insofern kein urheberrechtlicher Schutz gem. §§ 2 Nr. 1, 3. Var, 69 a I, II S. 1 UrhG zukommt. 142 Wandtke/Bullinger/Grützmacher, § 69 a Nr. 14. 143 Ebd.; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 32; OLG Düsseldorf, CR 2000, S. 184; Raubenheimer, CR 1994, S. 69 f.; Günther, CR 1994, S. 611 f.; Lehmann/Schlatter, S. 171.

I. Rechtsschutz von Computerprogrammen

89

In § 69 a II UrhG ist der allgemein anerkannte urheberrechtliche Grundsatz normiert, dass die den Werken zugrunde liegenden Ideen, die Gedanken, die Methoden und Systeme der Erstellung als solche keinen Schutz über das Urheberrecht genießen, sondern allein die Form und der Ausdruck eines Werkes urheberrechtlich zu schützen ist. Der Regelung in § 69 a II UrhG, dass jede Ausdrucksform eines Computerprogramms urheberrechtlichen Schutz genießt, soll in Anlehnung an den allgemeinen Grundsatz klarstellen, dass es für die Schutzfähigkeit eines Computerprogramms nicht darauf ankommen kann, in welcher Form diese gerade vorliegt. Mit der Ausdrucksform sind wohl unstreitig zunächst die Formen gemeint, in denen ein Computerprogramm notwendigerweise Ausdruck findet, also im Quellcode und Objektcode, egal ob sie in elektronischer, analog ausgedruckter oder in einer sonstigen Darstellungsform vorliegen. Darüber hinaus erscheint zweifelhaft, ob auch in der Benutzeroberfläche eine Ausdrucksform eines Computerprogramms zu sehen ist, die urheberrechtlichen Schutz über § 69 a UrhG genießen soll. Es gibt verschiede Möglichkeiten, Benutzeroberflächen für Computerprogramme zu erzeugen144. Zum einen besteht die Möglichkeit, die Benutzeroberfläche direkt im Quellcode des Anwendungs- oder Systemprogramms durch entsprechende Programmierung festzulegen. Darüber hinaus kann eine Benutzeroberfläche auch durch eine vom jeweiligen Computerprogramm getrennte Programmierung erstellt werden. Der Benutzeroberfläche liegt in diesem Fall ein eigenständiges Programm zugrunde, das gänzlich unabhängig vom Quellcode des Anwender- oder Systemprogramms ist. Man kann nun beide Programme so aneinander binden, dass bei Start der Benutzeroberfläche auch das jeweilige Programm gestartet wird. Das ist beispielsweise dann der Fall, wenn ein Anwenderprogramm nicht auf der konkreten Arbeitsstation des Anwenders, sondern auf einem „externen“ Server installiert ist und dort abläuft (Client-Server-Prinzip). In diesen Fällen laufen das Programm betreffend die Benutzeroberfläche und das eigentliche Computerprogramm auf getrennten Stationen ab. Das der Benutzeroberfläche zugrunde liegende Programm enthält in einem Teil des Codes Informationen zum Anwenderprogramm, was die Interaktivität ermöglicht. Schließlich besteht auch die Möglichkeit eine Benutzeroberfläche aus vorgefertigten Programmierleistungen zusammenzustellen, die in bestimmten Bibliotheken enthalten sind. In diesem Fall findet keine Programmierleistung im engeren Sinn statt. Die genannten Beispiele zeigen deutlich, dass eine Benutzeroberfläche nicht notwendig mit dem jeweiligen Computerprogramm verbunden ist. Darüber hinaus lässt sich eine identische Benutzeroberfläche 144 An dieser Stelle erfolgt nur eine vereinfachte Darstellung einiger weniger Möglichkeiten. Ausführlich dazu vgl. Balzert, Software-Technik, Bd. I, S. 692 ff.

90

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

mit verschiedenen Programmen herstellen145. Die Ausführungen zeigen, dass man von einer Benutzeroberfläche nicht auf das jeweilige Anwenderoder Systemprogramm schließen kann. Die Struktur der Benutzeroberfläche ist gerade nicht notwendigerweise programmtechnisch in Quellcode des jeweiligen Computerprogramms vorgegeben146. Eine Benutzeroberfläche kann demnach nicht als Ausdrucksform eines Computerprogramms gesehen werden. Somit kommt der Benutzeroberfläche ein urheberrechtlicher Schutz jedenfalls nicht über § 69 a II UrhG zu. Hinweise, dass die Benutzeroberfläche als Ausdrucksform eines Computerprogramms geschützt sein soll ergeben sich auch nicht aus den Gesetzgebungsmaterialien oder aus der Software-RL147. Ein möglicher urheberrechtlicher Schutz der Bildschirmoberfläche als eigenständiges Werk entsprechend der in § 2 UrhG aufgeführten Werkarten bleibt davon unberührt, soweit ein Schutz nicht an einer fehlenden Eigentümlichkeit des Werkes scheitert148. Folglich sind Benutzeroberflächen nicht als Ausdrucksformen von Computerprogrammen anzusehen. Ähnlich wie der urheberrechtliche Schutz von Benutzeroberflächen ist auch die urheberrechtliche Einordnung von digitalisierten Computerschriften (sog. Fonts) vorzunehmen. Fonts, die durch Computerprogramme generiert werden, sind grundsätzlich nicht als Ausdrucksform eines Computerprogramms gem. den §§ 69 a ff. UrhG geschützt149. Neben einem rechtlichen Schutz durch das Geschmacksmustergesetz gem. Art. 2 I Schriftzeichengesetz kann ein urheberrechtlicher Schutz gem. § 2 I UrhG in Betracht kommen150. In den Fällen, in denen besondere Steuerungsbefehle in einen Font (individuelle einführen von sog. Hints) einprogrammiert sind, ist ein urheberrechtlicher Programmschutz gem. §§ 69 a ff. UrhG möglich151. Bei Computerspielen152 wird das dem Spiel zugrunde liegende Programm unproblematisch über die §§ 69 a ff. UrhG zu schützen sein, während die 145

Das Argument wird gerade von der herrschenden Auffassung dafür aufgeführt, dass die Benutzeroberfläche keine Ausdrucksform eines Computerprogramms i. S. d. § 69 a II UrhG ist; vgl. OLG Düsseldorf, CR 2000, S. 184; Wandtke/Bullinger/ Grützmacher, § 69 a Rn. 14; Kilian/Heussen/Harte-Bavendamm/Wiebe, Nr. 51 Rn. 32 mit weiteren Nachweisen. 146 So aber Wandtke/Bullinger/Hoeren, § 69 a Rn. 6. 147 So auch Wandtke/Bullinger/Grützmacher, § 69 a Rn. 14. 148 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 32; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 14. 149 Kotthoff, in: HK-UrhR, § 69 a Rn. 10.; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 15; a. A. LG Köln CR 2000, S. 431; ausführlich zum Rechtsschutz von Fonts vgl. Jaeger/Koglin, CR 2002, S. 169 ff. 150 Jaeger/Koglin, CR 2002, S. 171ff.; Kotthoff, in: HK-UrhR, § 69 a Rn. 10. 151 Ebd.

I. Rechtsschutz von Computerprogrammen

91

audio-visuelle Darstellung des Spiels im Falle einer persönlich geistigen Schöpfung als Filmwerk gem. § 2 I Nr. 6 UrhG oder auch als Laufbild gem. §§ 95, 94 UrhG geschützt sein kann153. Immer häufiger werden Programmbibliotheken oder Programmdatenbanken vertrieben. Dabei handelt es sich um Sammlungen und Zusammenstellungen einzelner Programmfunktionen oder -teile, auf die ein Anwendungsprogramm zugreifen kann oder die in andere Software je nach Bedarf eingearbeitet werden können. Computerprogramme als in Dateien abgespeicherte Daten können somit Elemente einer Datenbank sein154. Dabei ist zu beachten, dass die Programmbibliothek nicht mit der die Datenbank steuernden Software zu verwechseln ist155. Stellt die Anordnung oder Zusammenstellung dieser einzelnen Dateien eine eigene geistige Schöpfung dar, kommt ein urheberrechtlicher Schutz als Sammlung gem. § 4 I UrhG oder als Datenbankwerk gem. §§ 4 II, 55 a UrhG in Betracht156. Handelt es sich im Einzelfall um eine nicht-schöpferische Anordnung oder Zusammenstellung, wird diese gem. §§ 87 a ff. UrhG dann geschützt, wenn die Beschaffung, Überprüfung oder Darstellung eine nach Art und Umfang wesentliche Investition erfordert. (c) Ideen und Grundsätze Gem. § 69 a II S. 2 UrhG werden die Ideen und Grundsätze, auf denen ein Computerprogramm aufgebaut ist, nicht urheberrechtlich geschützt157. Dieser auch sonst das Urheberrecht durchziehende Grundsatz158, ist gerade im Bereich von Computerprogrammen von großer Bedeutung. Es soll auch gerade im Bereich der schnellen IT-Entwicklung verhindern, dass Ideen und allgemein bekannte Grundsätze monopolisiert werden und damit Entwicklungs- und Wettbewerbsnachteile einhergehen. Über Ideen und allgemeine Grundsätze (z. B. allg. Programmiergrundsätze) bleiben auch allgemeine Rechenregeln, mathematische Formeln sowie abstrakte Lehrsätze geschützt und allgemein zugänglich159. Die zum Allgemeingut gehörenden 152 Ausführlich zum Rechtsschutz von Computerspielen vgl. Lehmann/Schlatter, S. 172 ff. 153 Schricker/Loewenheim, § 69 a Rn. 25; Kotthoff, in: HK-UrhR, § 69 a Rn. 11; Dreier/Schulze, § 69 a Rn. 17; Möhring/Nicolini/Hoeren, § 69 a Rn. 8. 154 Loewenheim/Koch, § 77 Rn. 8. 155 Ebd. 156 Schiffner, S. 115. 157 Ausführlich zum Schutzausschluss von Gestaltungsvorhaben, Ideen und Grundsätzen vgl. Koch, § 9 Rn. 125 ff. Mit Verweisen auf das anglo-amerikanische Recht vgl. Wuermeling, CR 1993, S. 665 ff. 158 Schricker/Loewenheim, § 2 Rn. 50.

92

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Lehren verdienen schon deswegen keinen urheberrechtlichen Schutz, weil sie auf keine individuelle Schöpfung zurückgehen160. In diesem Zusammenhang stellt sich aber die Frage, ob Algorithmen161 einem urheberrechtlichen Schutz gem. §§ 69 a ff. UrhG zugänglich sind. In dieser Frage wird die juristische Diskussion vor allem dadurch erschwert, dass es an einer genauen technischen oder juristischen Definition von Algorithmen fehlt162. Algorithmen werden sowohl in der Mathematik wie auch in der Datenverarbeitung und Informatik eingesetzt. Was den Einsatz in der Informatik und Datenverarbeitung anbelangt, wird ein Algorithmus wie folgt definiert: „Eine Methode beschreibt eine systematische Vorgehensweise zur Lösung eines Problems. Ist diese Verfahrensvorschrift exakt und vollständig formuliert, so handelt es sich um einen Algorithmus. Er gibt an, wie Inputgrößen bei einem gegebenen Zielsystem in Outputgrößen umzuwandeln sind.“163 Ein Algorithmus ist also „. . . any well-defined computational procedure that takes some value, or set of values, as input and produces some value, or set of values, as output. An algorithm is thus a sequence of computational steps that transform the input into the output. We can also view an algorithm as a tool for solving a well-specified computational problem“164. Man kann einen Algorithmus einfach als Verarbeitungsvorschrift verstehen, die aufgrund ihrer präzisen Formulierung von elektronisch oder mechanisch arbeitenden Geräten ausgeführt werden kann165. Aus urheberrechtlicher Sicht stellt sich die Frage, inwieweit Algorithmen als Grundlage von Computerprogrammen über die §§ 69 a ff. UrhG geschützt sind. Völlig unstreitig besteht die Möglichkeit eines urheberrechtlichen Schutzes für Algorithmen für die „Art und Weise der Implementierung und Zuordnung zueinander“ bezogen auf ein Computerprogramm166. Geschützt 159 BGHZ 112, 264, 277; OLG Celle, CR 1994, S. 749 f.; Lehmann/Lehmann, S. 8; Möhring/Nicolini/Hoeren, § 69 a Rn. 12; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 28. Eine abweichende Meinung dazu vertritt Haberstrumpf, der auch wissenschaftlichem und technischem Gedankengut Urheberrechtsschutz zukommen lassen will; Lehmann/Haberstrumpf, S. 107 ff. 160 Dreier/Schulze, § 69 a Rn. 20. 161 Zum Begriff Algorithmus vgl. Marly, Rn. 29 ff. 162 So auch Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, NR. 51 Nr. 16; Marly, Rn. 29. 163 Hansen, S. 270. 164 Cormen, Introduction to Algorithms, S. 15. 165 So auch Schricker/Loewenheim, § 69 a Rn. 12. 166 BGH, CR 1991, S. 85; OLG Frankfurt, CR 1986, S. 13 ff.; Dreier/Schulze, § 69 a Rn. 22; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 17; Koch, § 9 Rn. 133; Kotthoff, in: HK-UrhR, § 69 a Rn. 19; Junker/Benecke, Rn. 34; Möhring/Nicolini/Hoeren, § 69 a Rn. 12; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 28; Lehmann, CR 1996, S. 3; Haberstrumpf, Rn. 124.

I. Rechtsschutz von Computerprogrammen

93

wird danach die individuelle Zusammenstellung von Algorithmen zu einem konkreten Computerprogramm. Diese konkrete Anordnung von Algorithmen ist als Ausdrucksform eines Computerprogramms gem. §§ 69 a ff. UrhG einem urheberrechtlichem Schutz zugänglich. Darüber hinaus ist die Frage umstritten, inwieweit auch dem Algorithmus „als solchem“ ein urheberrechtlicher Schutz über § 69 a II UrhG zukommt. Dabei dürfte auch in diesem Zusammenhang Einigkeit darüber bestehen, dass die dem einzelnen Algorithmus zugrunde liegenden mathematischen Lehren, abstrakte Ideen und Grundsätze nicht schutzfähig sind sondern als allgemeines Wissen grundsätzlich schutzfrei sind. Abstrakten Grundsätzen und Problemlösungen, die sich in keiner hinreichenden Individualität niederschlagen, kommt kein Urheberrechtsschutz zu167. Ausgehend von diesen Grundsätzen lehnen die Rechtsprechung und die überwiegende Literatur einen urheberrechtlichen Schutz des Algorithmus „als solchen“ ab168. Nach der Meinung von Haberstrumpf ist es gerade geboten, Erkenntnisse und Lehren zur Begründung der Individualität wissenschaftlicher oder technischer Werke heranzuziehen und für schutzfähig zu erachten169. Nach seiner Ansicht ist auch der individuelle Algorithmus „als solcher“ schutzfähig, egal, ob er als generelle Problemlösung das eigentliche Programmwerk darstellt, im Grobentwurf präsentiert oder in noch allgemeiner Form in einem Lehrbuch der Informatik dargestellt wird170. Es bleibt jedoch zu beachten, dass Haberstrumpf von dieser (ursprünglichen) Haltung in der Form Abstand genommen hat, als das er den „allgemeinen“ Algorithmus grundsätzlich als zugrunde liegende Idee oder Grundsatz im Sinne von § 69 a II S. 2 UrhG vom urheberrechtlichen Schutz eines Computerprogramms ausnehmen will171. Grundsätzlich geht es um die Frage, ob der Algorithmus als Ausdrucksform eines Computerprogramms einem urheberrechtlichem Schutz gem. § 69 a II S. 1 UrhG zugänglich ist, oder als Idee oder Grundsatz, die einem Element eines Computerprogramms zugrunde liegt, nicht schutzfähig ist. Die Frage sollte differenziert betrachtet werden172. 167

Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 17. BGH, CR 1991, S. 85; OLG Frankfurt, CR 1986, S. 13 ff.; Dreier/Schulze, § 69 a Rn. 22; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 17; Koch, § 9 Rn. 133; Kotthoff, in: HK-UrhR, § 69 a Rn. 19; Junker/Benecke, Rn. 34; Möhring/Nicolini/Hoeren, § 69 a Rn. 12; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 28. 169 Lehmann/Haberstrumpf, S. 107 ff., 110, mit ausführlicher Begründung zur Unbegründbarkeit der These von der Freiheit wissenschaftlicher oder technischer Lehren und Erkenntnisse. 170 Lehmann/Haberstrumpf, S. 111; mit ähnlicher Begründung auch Pres, S. 31 f. 171 Haberstrumpf, Rn. 124. 168

94

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Ein Algorithmus, verstanden als Verarbeitungsvorschrift, wird in vielen Fällen über einen längeren Zeitraum entwickelt. Es gibt keinen festen, endlichen Bestand von Algorithmen. Vielmehr werden je nach Art einer Problemlösung Algorithmen entwickelt. Darüber hinaus gibt es eine Anzahl von Elemtaralgorithmen, denen schon aufgrund der fehlenden Individualität kein urheberrechtlicher Schutz zukommen kann. Ein bekanntes Beispiel für einen entwickelten Algorithmus ist die Suchmaschine Google173. Die Suchmaschine Google hat sich in den letzten Jahren weltweit zur meist benutzen Suchmaschine entwickelt. Grund für den Erfolg war vor allem die überlegene Qualität der Suchergebnisse. Diese Qualität beruht wesentlich auf dem PageRank-Verfahren. Das Verfahren aber ist nichts anderes als ein Algorithmus der von den Google-Gründern Lawrence Page und Sergey Brin während ihrer Zeit als Graduiertenstudenten an der Stanford University entwickelt wurde174. Die Anwendung dieses Algorithmus führt vereinfacht ausgedrückt dazu, dass Internetseiten nicht ihrer Gesamtheit nach bewertet werden, sondern die Beziehung von Internetweiten zueinander im Mittelpunkt der Bewertung stehen175. Die Darstellung und Erläuterungen dieses Verfahren zeigen deutlich, dass es sich hierbei um eine eigenständige und aufwendige Entwicklung handelt. Das genannte Beispiel zeigt auch deutlich, dass ein Algorithmus den eigentlichen Wert eines Computerprogramms bilden kann. Dies spricht auch für ein grundsätzliches Bedürfnis, einen entwickelten Algorithmus rechtlich schützen zu können. Grundvoraussetzung für einen urheberrechtlichen Schutz, ist in jedem Fall, dass ein Algorithmus in seiner konkreten Ausgestaltung Individualität besitzt. Was den urheberrechtlichen Schutz eines Algorithmus über die §§ 69 a ff. UrhG anbelangt, sind die dem Algorithmus zugrunde liegenden Ideen und mathematischen Grundsätze nicht schutzfähig. Das bestreitet auch Haberstrumpf nicht. Darüber hinaus besteht wie dargelegt Einigkeit, dass bei Computerprogrammen die Implementierung und Zuordnung der Algorithmen zueinander über § 69 a II UrhG urheberrechtlich geschützt sein kann. Liegen einem Computerprogramm mehrere Algorithmen zugrunde, was in der Regel der Fall ist, kann aber dem einzelnen Algorithmus gem. § 69 a II S. 1 UrhG schon deshalb kein urheberrechtlicher Schutz zu172 Haberstrumpf und hierauf beziehend Pres unterscheiden hierbei den nicht zu schützenden Elementaralgorithmus und den Entwurfsalgorithmus. 173 www.google.de. 174 Er hat die folgende Form: PRÈAê ã È1  dê þ dÈPRÈT1ê=CÈT1ê þ . . . þ PRÈTnê=CÈTnêê. 175 Zur Funktionsweise des PageRank-Verfahren vgl.: http://pr.efactory.de/.

I. Rechtsschutz von Computerprogrammen

95

kommen, weil er für sich allein gesehen schon keine Ausdrucksform des jeweiligen Programms darstellt. In diesen Fällen schafft erst die Verknüpfung mit anderen Algorithmen die Basis für die Funktionsfähigkeit eines Computerprogramms. Der einzelne Algorithmus ist hier nicht Ausdrucksform eines Computerprogramms geschützt. Wer in diesen Sachlangen darüber hinaus den Algorithmus „als solchen“ urheberrechtlich schützen will, findet dafür in den §§ 69 a ff. UrhG keine Stütze. Da ein Computerprogramm aber nichts anderes ist als die Umsetzung von Algorithmen in einen Form, die von Computern verarbeitet werden kann, sind auch Computerprogramme vorstellbar, die nur aus einem Algorithmus bestehen. Hier stellt sich dann die Frage, ob dem einzelnen Algorithmus nicht doch ein urheberrechtlicher Schutz als Ausdrucksform des Computerprogramms zukommt. In diesen Fällen ist der einzelne Algorithmus die alleinige Basis des Programms, d. h. dass der Quellcode nur aus diesem Algorithmus besteht. Damit ist der entwickelte Algorithmus in diesen Fällen auch Ausdrucksform des Computerprogramms. Dem Algorithmus „als solchem“ kann mithin in diesen Fällen urheberrechtlicher Schutz gem. § 69 a II S. 1 UrhG zukommen. Folglich ist die Frage nach dem urheberrechtlichen Schutz von Algorithmen differenziert nach der jeweiligen Sachlage zu beantworten. Ein Schutz des Algorithmus „als solchem“ ist somit nicht grundsätzlich ausgeschlossen176. Eine entsprechende Differenzierung betreffend die Frage nach einem urheberrechtlichen Schutz über die §§ 69 a ff. UrhG ist bei Schnittstellen vorzunehmen. Schnittstellen (sog. Interfaces) sind Verbindungs- oder Berührungspunkte von Systemen, die miteinander kommunizieren bzw. die zusammenarbeiten. Es handelt sich um Informationen als Teil eines Programms, die die Interaktion des Programms mit der Hardware oder anderen Softwarekomponenten ermöglichen177. Gem. § 69 a II S. 2 UrhG sind die den Schnittstellen zugrunde liegenden Ideen und Grundsätze nicht urheberrechtlich geschützt. Im Umkehrschluss ist daraus – ähnlich wie bei den Algorithmen – zu schließen, dass die konkrete Implementierung einer Schnittstelle in ein Programm durch Anwendung der Regeln und Methoden der Schnittstellenspezifikation, d. h. der die Schnittstellen umsetzende Code urheberrechtlich schutzfähig sein kann178. Auch hier wird nur die konkrete 176

So auch Pres, S. 31. BT-Drucks. 12/4022, S. 9. 178 Dreier/Schulze, § 69 a Rn. 23; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 19; Lehmann/Lehmann, S. 9; Lehmann/Haberstrumpf, S. 87; Möhring/Nicolini/Hoeren, § 69 a Rn. 11; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 31; Schricker/Loewenheim, § 69 a Rn. 13. 177

96

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Implementierung durch den Computercode geschützt, wohingegen vor allem die Schnittstellenspezifikationen als zugrunde liegende Ideen schutzfrei bleiben179. (3) Schutzvoraussetzungen gem. § 69 a III UrhG Computerprogramme sind gem. § 69 a III S. 1 UrhG schutzfähig, wenn sie eine individuelle geistige Schöpfung des Urhebers sind. Vor Einführung der besonderen Bestimmungen für Computerprogramme in das UrhG richtete sich die erforderliche Schutzhöhe von Computerprogrammen nach der allgemeinen Schutzvoraussetzung des § 2 II UrhG180. Danach war eine persönliche geistige Schöpfung Voraussetzung für die Schutzhöhe. Beide Vorschriften unterscheiden sich kaum vom Wortlaut. Die mit § 69 a III S. 1 UrhG eingeführte Formulierung von der „eigenen geistigen Schöpfung“ entspricht Art. 1 III der Computer-RL. Eine geistige Schöpfung kann nur das Ergebnis menschlichen Handelns sein181. Damit wird ausdrücklich klargestellt, dass das Werk einen geistigen Gehalt haben muss und daher maschinell hergestellte oder gar Zufallsprodukte nicht zum Schutz erfasst werden182. Eine eigene geistige Schöpfung liegt vor, wenn das Computerprogramm ein Mindestmaß an Individualität aufweist, d. h. es muss sich bei der Sammlung, Anordnung und Einteilung der Informationen und Anweisungen von anderen Computerprogrammen unterscheiden183. Problematisch zu beurteilen ist die Fallgruppe der computerunterstützten Softwareentwicklung (sog. Computer Aided Software Engineering, CASE; Computer-generated programs). Wesentliche Softwareentwicklungsvorgänge werden hier von einem speziellen Computerprogramm selbst vorgenommen. Daher entspricht diese Fallgruppe regelmäßig nicht dem Schöpferprinzip des § 69 a III UrhG184. Auch wenn ein entsprechend hergestelltes Programm einen geistigen Gehalt aufweist, so fehlt es doch an der notwendigen Individualität des Programms185. 179

Wandtke/Bullinger/Grützmacher, § 69 a Rn. 31. Kotthoff, in: HK-UrhR, § 69 a Rn. 20. 181 Wandtke/Bullinger/Grützmacher, § 69 a Rn. 32. Schricker/Loewenheim, § 2 Rn. 12. 182 Schricker/Loewenheim, § 2 Rn. 13; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 32. 183 Kotthoff, in: HK-UrhR, § 69 a Rn. 21. 184 Möhring/Nicolini/Hoeren, § 69 a Rn. 14; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 32. 185 Wandtke/Bullinger/Grützmacher, § 69 a Rn. 32. 180

I. Rechtsschutz von Computerprogrammen

97

Der Gesetzgeber hat bei der Einführung des 8. Abschnitts in § 69 a III S. 2 ausdrücklich klargestellt, dass zur Bestimmung der Schutzfähigkeit von Computerprogrammen keine über S. 1 hinausgehenden Kriterien herangezogen werden dürfen, insbesondere keine qualitativen oder ästhetischen186. Diese Regelung hat im Vergleich zur früheren Rechtsprechung zu einer Herabsetzung der Schutzanforderungen geführt187. Folge der Gesetzesänderung war, dass nunmehr zur Beurteilung der Schutzhöhe weder das Erfordernis eines „ästhetischen Gehalts“ noch das Erfordernis einer deutlich überdurchschnittlichen Gestaltung heranzuziehen war188. Vielmehr führt die Neuregelung dazu, dass auch der Grundsatz der sog. „kleinen Münze“ für die Beurteilung des urheberrechtlichen Schutzes von Computerprogrammen herangezogen wurde189. Aber auch der Teil der Rechtsprechung, der nicht ausdrücklich von Schutz der „kleinen Münze“ spricht, hat infolge der Neuregelung die Schutzanforderungen bei Computerprogrammen heruntergesetzt190. Das frühere Merkmal einer besonderen Schöpfungs- bzw. Gestaltungshöhe wurde somit auch von der Rechtsprechung aufgegeben191. Das Herabsetzen der Schutzhöhe als Folge der Gesetzesänderung führt jedoch nicht dazu, dass jedes beliebe Computerprogramm über § 69 a III UrhG dem urheberrechtlichen Schutz zugänglich ist oder auf die Prüfung der Schutzhöhe gänzlich verzichtet wird192. Auch wenn, wie dargestellt ein Minimum an Individualität für die erforderliche Schutzhöhe ausreicht, führt das Erfordernis der Individualität doch dazu, dass nicht jedes banale oder triviale Programmierergebnis urheberrechtlich geschützt werden kann193. Um die erforderliche Schutzhöhe zu erreichen, muss die Programmierleistung zumindest das Durchschnittskönnen eines Programmierers übersteigen und Ausdruck von individuellen analytisch-konzeptionellen Fähigkeiten, Geschick, Einfallsreichtum und planerisch-konstruktiven Denken sein194. Damit ist sichergestellt, dass das Kriterium der Schutzhöhe bei 186

Möhring/Nicolini/Hoeren, § 69 a Rn. 13. BGHZ 123, 208, 211; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 33; Möhring/Nicolini/Hoeren, § 69 a Rn. 15. 188 Möhring/Nicolini/Hoeren, § 69 a Rn. 15. 189 BT-Drucks. 12/4022, S. 9; BGHZ 123, 208 ff.; OLG Karlsruhe, GRUR 1994, S. 726, 729; OLG Hamburg, CR 1998, S. 332 f.; Dreier, CR 1991, S. 577 f.; Ullmann, CR 1992, S. 641 ff.; Loewenheim/Lehmann, § 76 Rn. 3; Wandtke/Bullinger/ Grützmacher, § 69 a Rn. 33; Schricker/Loewenheim, § 69 a Rn. 20. 190 BGH, NJW 2000, S. 3571 f.; BGH, GRUR 2000, S. 866 ff.; OLG Celle, CR 1994, S. 748; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 33 mit weiteren Nachweisen. 191 Möhring/Nicolini/Grützmacher, § 69 a Rn. 33. 192 OLG Düsseldorf, CR 1997, S. 337. 193 OLG Düsseldorf, CR 1997, S. 337 f.; Schricker/Loewenheim, § 69 a Rn. 20; Möhring/Nicolini/Hoeren, § 69 a Rn. 16. 187

7 Teupen

98

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

der Beurteilung von Computerprogrammen auch nach Einführung der §§ 69 a ff. UrhG zu beachten ist und ein uferloser Schutz jeglicher Programmierleistung unterbleibt. (4) Urheberschaft Die Urheberschaft an einem Computerprogramm entsteht in dem Zeitpunkt, wenn eine sinnlich wahrnehmbare Formgestaltung vorliegt, die Individualität erkennen lässt, d. h. die Werkschöpfung vorliegt195. Das Entstehen des Urheberrechts setzt somit den Realakt der Werkschöpfung notwendigerweise voraus. (a) Alleinurheberschaft Die Urheberschaft an einem Computerprogramm richtet sich nach den allgemeinen Vorschriften der §§ 7 ff. UrhG. Das Urheberrecht an einem Computerprogramm steht gem. § 7 UrhG dem Schöpfer des Programms zu. Die Zuweisung der Urheberschaft an den Schöpfer ist logische Konsequenz des Werkbegriffs aus § 2 II UrhG. Danach sind nur diejenigen Personen als Urheber anzusehen, deren Beiträge zur Erstellung des Werkes eine persönliche geistige Schöpfung i. S. d. § 2 II UrhG darstellen196. Der in § 7 UrhG normierte originäre Rechtserwerb der Urheberschaft knüpft somit an das tatsächliche Handeln einer Person an. Da die Werkschöpfung ein menschlich geistiges Handeln verlang, ist es folgerichtig ausgeschlossen, dass juristische Personen oder Personenmehrheiten Inhaber einer Urheberschaft sein können197. Ihnen bleibt aber ungenommen, Inhaber abgeleiteter Urheberrechte zu sein198. In diesem Kontext ist auch § 69 b UrhG als lex speziales zu § 43 UrhG sehen. Ausgehend von dem Grundsatz, dass bei Computerprogrammen die Urheberschaft immer beim menschlichen Programmschöpfer liegt, dient die Vorschrift der Stärkung der Rechtsposition von Arbeitund Dienstgeber. Die Vorschrift ändert jedoch nichts an der Urheberschaft eines Computerprogramms, sondern regelt, vorbehaltlich abweichender vertraglicher Vereinbarungen, die vermögensrechtlichen Befugnisse199 an Computerprogrammen, die ein angestellter Programmierer in Erfüllung seines 194 OLG München, CR 2000, S. 429 f.; Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 23; Wandtke/Bullinger/Grützmacher, § 69 a Rn. 34; Schricker/Loewenheim, § 69 a Rn. 20. 195 Lehmann/Haberstrumpf, S. 124. 196 Wandtke/Bullinger/Thum, § 7 Rn. 3. 197 Lehmann/Haberstrumpf, S. 125. 198 Wandtke/Bullinger/Thum, § 7 Rn. 4. 199 BT-Drucks. 12/4022, S. 10.

I. Rechtsschutz von Computerprogrammen

99

Arbeits- oder Dienstverhältnisses schafft200. Man kann hier von einer gesetzlichen vertragsdispositiven Einräumung aller Verwertungsrechte und eine Abtretung der Vergütungsansprüche sprechen201. Die Vorschrift lässt die Zuweisung der Urheberschaft damit aber unberührt202. (b) Der angestellte Urheber Computerprogramme sind in der Regel Ergebnisse komplexer Programmiertätigkeit an der regelmäßig eine Vielzahl von Programmierern beteiligt ist. Arbeiten die Programmierer innerhalb eines bestehenden Arbeits- oder Dienstverhältnisses zusammen, ist die praktische Handhabung der Urheberrechte an den von ihnen gemeinsam programmierten Computerprogrammen durch die Anwendung von § 69 b UrhG unproblematisch. Die urheberrechtlichen Befugnisse an dem Computerprogramm gehen gemäß der Vorschrift auf den Arbeitgeber oder Dienstherren über203. Es bleibt natürlich auch in dieser Fallkonstellation die Frage zu klären, wem Urheberpersönlichkeitsrechte zustehen. Die Frage nach einer Urheberschaft bei mehreren Schöpfern stellt sich aber vielmehr in den Fällen, in denen keinerlei vertraglicher Bindungen zwischen Ihnen bestehen und sie nicht in einem Angestelltenoder Dienstverhältnis sind. So wird Software häufig von selbstständigen Entwicklern geschrieben, wobei der einzelne Entwickler oft nur einzelne Programmteile programmiert. Darüber hinaus werden an Hochschulen oder in anderen unabhängigen Forschungsinstituten Computerprogramme von mehreren Beteiligten entwickelt. Aber auch gerade im Bereich der Open Source Software wirkt oft – aber nicht notwendigerweise – eine Vielzahl von Programmierern bei der Entstehung eines Computerprogramms zusammen204. (c) Miturheberschaft Haben mehrere Personen an der Entstehung eines Computerprogramms mitgewirkt, sind sie gem. § 8 I UrhG Miturheber des Computerprogramms, sofern sich ihre Anteile nicht gesondert verwerten lassen und sie eigene schöpferische Beiträge innerhalb einer gemeinsamen partnerschaftlichen Ar200

Dreier/Schulze, § 69 b Rn. 2. Lehmann, CR 1992, S. 325. 202 BT-Drucks. 12/4022, S. 10; Dreier/Schulze, § 69 b Rn. 3. 203 Lehmann/Haberstrumpf, S. 125. 204 Auf die Problematik der Urheberschaft bei einer Mehrheit von Beteiligten im Bereich Open Source Software wird im Folgenden noch ausführlich eingegangen. An dieser Stelle sollen zunächst die Grundlagen der Miturheberschaft kurz erläutert werden. 201

7*

100

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

beit an einem einheitlichen Werk eingebracht haben205. Die Miturheberschaft setzt voraus, dass sich die einzelnen Urheber einer Gesamtidee unterordnen206. Die Miturheberschaft ist somit nichts anderes als das Ergebnis eines gewollten Zusammenwirkens zur Schaffung eines einheitlichen Werkes. Da die Herstellung von Software regelmäßig von mehreren Programmierern im Wege der Aufgabenteilung derart vorgenommen wird, dass sich die Programmierer an einem vorgegebenen Ziel orientieren und sie innerhalb der Vorgaben die einzelnen Module selbstständig programmieren, reicht es in diesem Zusammenhang für eine Miturheberschaft aus, wenn der Einzelbeitrag auch im Vorstadium als unselbstständiger Beitrag zu dem einheitlichen Werk erfolgt207. Sind die Beiträge der mitwirkenden Urheber gesondert verwertbar liegt i. d. R. eine Werkverbindung gem. § 9 UrhG vor. Gesondert verwertbar sind Beiträge dann, wenn sie sich aus dem Werk herauslösen und anderweitig verwerten lassen, ohne dass die Beiträge für sich betrachtet unvollständig oder ergänzungsbedürftig sind208. Sie bleiben selbstständig verwertbar209. Für die Annahme einer Miturheberschaft dürfen die Einzelbeiträge somit keine eigene Verkehrsfähigkeit besitzen210. Für die Begründung einer Miturheberschaft kommt es nicht auf die Größe und den Umfang eines Beitrages an, so dass auch ein geringfügiger Beitrag ausreichen kann211. Die Frage, von welcher schöpferischen Qualität der einzelne Beitrag sein muss, ist umstritten. Nach allgemeiner Auffassung212 muss dem einzelnen Beitrag selbst Werkqualität zukommen. Die Miturheberschaft setzt danach voraus, dass jeder Beitrag eines am Schaffensprozess Beteiligten den Anforderungen des § 2 II UrhG genügt und somit seinerseits eine persönlich geistige Schöpfung darstellt. Die Gegenauffassung213 verneint die Notwendig205

BGH, GRUR 2003, S. 231, 234; BGH, NJW 1993, S. 3136; Kilian/Heussen/ Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 47; Wandtke/Bullinger/Thum, § 7 Rn. 7, § 8 Rn. 1; Schack, Rn. 278. 206 Dreier/Schulze, § 8 Rn. 2.; Rehbinder, Rn. 168. 207 Loewenheim/Loewenheim, § 11 Rn. 2; Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 47. 208 Kotthoff, in: HK-UrhR, § 8 Rn. 6. 209 Dreier/Schulze, § 9 Rn. 2. 210 Rehbinder, Rn. 168. 211 BGH, NJW 1993, S. 3136, 3138; OLG Karlsruhe, GRUR 1984, S. 812 f.; Schricker/Loewenheim, § 8 Rn. 4; Wandtke/Bullinger/Thum, § 8 Rn. 3; Kotthoff, in: HK-UrhR, § 8 Rn. 14. 212 BGH, GRUR 1963, S. 40 f.; BGH, GRUR 1994, S. 39 f.; BGH, ZUM 1995, S. 482; OLG Hamburg, GRUR-RR 2000, S. 6; Wandtke/Bullinger/Thum, § 8 Rn. 3; Kotthoff, in: HK-UrhR, § 8 Rn. 15; Dreier/Schulze, § 8 Rn. 6; Loewenheim/Loewenheim, § 11 Rn. 2; Rehbinder, Rn. 169. 213 Möhring/Nicolini/Ahlberg, § 8 Rn. 9.

I. Rechtsschutz von Computerprogrammen

101

keit einer persönlichen geistigen Schöpfung des Einzelbeitrages zur Begründung der Miturheberschaft. Hiernach ist die schöpferische Leistung eines Miturhebers nicht daran zu messen, welchen Teil eines Werkes er ausführt, sondern daran, ob er das Gesamtwerk als solches schöpferisch mitgestaltet. Nicht nur sein eigener Beitrag ist danach Ausdruck seiner Individualität, sondern gerade auch die Beiträge der anderen Miturheber spiegeln seine Individualität wider. Ahlberg kritisiert, dass die gegenteilige Auffassung dazu führen würde, dass eine Miturheberschaft in Fällen ausgeschlossen wäre, in denen Einzelbeiträge, die keine persönliche geistige Schöpfung darstellen, zu einem Gesamtwerk zusammengesetzt werden214. Dies würde letztendlich dazu führen, dass ein Werk ohne Urheber entstehe215. Die Regelung des § 8 I UrhG dient unter anderem dazu, zwischen den Urhebern eines Werkes und denjenigen abzugrenzen, die den Schöpfungsprozess lediglich unterstützend begleiten, selbst aber keine schöpferischen Gestaltungshandlungen vornehmen, wie z. B. Ideenanreger, Auftraggeber, Produzenten sowie Arbeitgeber216. Auch Gehilfen, die normalerweise nur Anordnungen folge leisten, scheiden als Miturheber aus217. Grundsätzlich sind Fälle vorstellbar, in denen ein Gesamtwerk aus Einzelbeiträgen zusammengesetzt ist, die für sich genommen keine Werkeigenschaft besitzen, also keine schöpferischen Beiträge für sich gesehen sind. Dem daraus entstehenden Gesamtwerk kann dennoch urheberrechtlicher Schutz zukommen, wenn gerade die konkrete Anordnung und Zusammenführung der Komponenten eine persönliche geistige Schöpfung darstellt. Urheber eines solchen Gesamtwerkes sind dann nicht diejenigen, die die Einzelbeiträge geleistet haben, sondern diejenigen, die die konkrete kompositorische Zuordnung und Einfügung der Beiträge in schöpferischer Weise vorgenommen haben218. Das widerlegt die Bedenken, dass in diesen Fällen ein Werk ohne Urheber entstehen könnte. Es bestehen auch keinerlei Bedenken einem Gesamtwerk die urheberrechtliche Werkeigenschaft zuzusprechen, wenn die Einzelbeiträge für sich keine geistigen Schöpfungen darstellen. Kernstreitpunkt ist die Frage, ob auch die Notwendigkeit besteht, die Schöpfer der Einzelbeiträge als Urheber am Gesamtwerk anzusehen. Entsteht ein Gesamtwerk aufgrund einer schöpferischen Verknüpfung von Einzelbeiträgen liegt eine Urheberschaft vor. Es ist hier aber deutlich zwischen nichtschöpferischen und schöpferischen Beiträgen abzugrenzen. Da das Urheberrecht das Recht am geistigen Schaffensergebnis ist, kann jemanden der „nur“ einen nichtschöpferi214 215 216 217 218

Ebd. Ebd. Dreier/Schulze, § 8 Rn. 7 Ebd. So auch Wandtke/Bullinger/Thum, § 8 Rn. 4; vgl. z. B. BGHZ 24, 55, 65.

102

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

schen Beitrag leistet auch am Gesamtwerk kein Urheberrecht zukommen219. Eine gegenteilige Beurteilung würde den Wertungen des Urheberrechts zuwiderlaufen. Da er keinen schöpferischen Beitrag geleistet hat, bedarf er keines besonderen Schutzes durch das Urheberrecht. Zur Begründung der Miturheberschaft bedarf es somit einer eigenen schöpferischen Mitgestaltungshandlung oder eines Beitrages, dem Werkqualität zukommt220. Als Rechtfolge der Miturheberschaft entsteht eine Verwertungsgemeinschaft gem. § 8 I UrhG, die betreffend der Veröffentlichungs- und Verwertungsrechte als Gesamthandgemeinschaft ausgestaltet ist und auf die die Vorschriften der BGB-Gesellschaft §§ 705 ff. BGB ergänzend Anwendung finden, wenn die urheberrechtliche Interessenlage eine solche Anwendung nicht ausschließt221. Man kann somit sagen, dass es sich hier um eine urheberrechtlich modifizierte Gesamthandsgemeinschaft handelt222. Fraglich ist hierbei, wie sich die gesamthänderische Bindung gem. § 8 II S. 1 UrhG auf die Urheberpersönlichkeitsrechte auswirkt. Ob die urheberpersönlichkeitsrechtlichen Befugnisse der gesamthänderischen Bindung unterliegen, ist umstritten. Eine breite Mehrheit der Literatur223 lehnt eine gesamthänderische Bindung der urheberpersönlichkeitsrechtlichen Befugnisse ab. Dieser Ansicht zufolge bleiben die Urheberpersönlichkeitsrechte beim einzelnen Urheber, soweit § 8 II UrhG nichts Gegenteiliges anordnet224. Die urheberpersönlichkeitsrechlichen Befugnisse unterliegen somit nicht grundsätzlich der gesamthänderischen Bindung, so dass die allgemeinen Regelungen zu den Urheberpersönlichkeitsrechten anzuwenden sind. Nur eine derartige Beurteilung spiegle die höchstpersönliche Natur des Urheberrechts wider, in der jeder Urheber seine ideellen Rechte selbstständig wahrnehmen kann225. Der gesamthänderischen Bindung unterliegen allein die in § 8 II UrhG genannten Rechtspositionen, wie Veröffentlichungs-, Verwertungs- und Änderungsrechte226. 219

Schack, Rn. 282. So auch Rehbinder, Rn. 169. 221 OLG Hamburg, OLGZ 207, S. 7; Schricker/Loewenheim, § 8 Rn. 10; Loewenheim/Loewenheim, § 11 Rn. 5; Wandtke/Bullinger/Thum, § 8 Rn. 22, 24; Dreier/ Schulze, § 8 Rn. 12; Kotthoff, in: HK-UrhR, § 8 Rn. 20; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Nr. 48; Rehbinder, Rn. 171. 222 Schricker/Loewenheim, § 8 Rn. 1; Schack, Rn. 283. 223 Dreier/Schulz, § 8 Rn. 12; Schricker/Loewenheim, § 8 Rn. 10; Loewenheim/ Loewenheim, § 11 Rn. 5; Kotthoff, in: HK-UrhR, § 8 Rn. 28; Wandtke/Bullinger/ Thum, § 8 Rn. 26; Rehbinder, Rn. 171; Schack, Rn. 283. 224 Schricker/Loewenheim, § 8 Rn. 10; Wandtke/Bullinger/Thum, § 8 Rn. 26. 225 Wandtke/Bullinger/Thum, § 8 Rn. 26. 226 Schricker/Loewenheim, § 8 Rn. 10; Dreier/Schulze, § 8 Rn. 13. 220

I. Rechtsschutz von Computerprogrammen

103

Nach gegenteiliger Auffassung227 sind sämtliche Persönlichkeitsrechte Gegenstand der Gesamthandsgemeinschaft. Teilweise wird auch davon ausgegangen, dass zunächst das Urheberrecht in der Person eines jeden Miturhebers erwächst, die Ausübung seiner Rechtsposition aber durch die gesamthänderische Bindung beschränkt ist228. Das Miturheberrecht wird als ein „einziges Recht“ gesehen, dass „nicht auf die einzelnen Miturheber“ aufgeteilt ist229. Mit der im Urheberrecht geltenden monistischen Theorie, nach der das Urheberrecht aus Persönlichkeits- und Vermögensrechten besteht, die untrennbar miteinander verbunden sind230, wäre es nach dieser Auffassung unvereinbar, wenn die Vermögensrechte und urheberpersönlichkeitsrechtlichen Befugnisse bei einem originären Rechterwerb unterschiedlichen Rechtssubjekten zukommen würden231. Würden die Urheberpersönlichkeitsrechte nicht der gesamten Hand zustehen, würde die Anwendung von Regelungen wie beispielsweise §§ 13, 14, 23 UrhG oder auch § 25 UrhG zu völlig unpraktikablen Ergebnissen führen. Jeder Miturheber könnte beispielsweise bezogen auf die genannten Regelungen Entscheidungen aufgrund seines ihm zustehenden Urheberpersönlichkeitsrechts treffen, die zu Lasten der urheberpersönlichkeitsrechtlichen Befugnisse der anderen Miturheber gehen würden. Diese Ansicht sieht allerdings die der Gesamthand zustehenden Persönlichkeitsrechte als die Summe der Urheberpersönlichkeitsrechte eines jeden Miturhebers232. Es wird in diesem Zusammenhang zwischen Innen- und Außenverhältnis unterschieden. Im Innenverhältnis stehen jedem Urheber seine Urheberpersönlichkeitsrechte gegenüber der Gesamthand zu während im Außenverhältnis diese Persönlichkeitsrechte bei der Gesamthand liegen233. Die Vorschriften über die Miturheberschaft dienen dazu, einen angemessenen Ausgleich unter mehreren Urhebern zu erzielen, die miteinander ein Gesamtwerk geschaffen haben und deren Einzelbeiträge für sich genommen nicht gesondert verwertbar sind. Ziel ist es somit, alle Miturheber angemessen an den Früchten ihres gemeinsamen Schaffensergebnisses teilhaben zu lassen. § 8 II S. 1 UrhG bestimmt dabei ausdrücklich, welche Rechtspositionen den Miturhebern zur gesamten Hand zustehen. Danach fallen das Vervielfältigungs- und das Verwertungsrecht der Gesamthand der Miturheber zu. Darüber hinaus sind Veränderungen am Werk nur mit Einwilligung aller Miturheber zulässig. Ausgehend vom Wortlaut dieser Vorschrift er227 228 229 230 231 232 233

Möhring/Nicolini/Ahlberg, § 8 Rn. 28.; Sonntag, S. 29 ff. v. Gamm, § 8 Rn. 12, 15. Möhring/Nicolini/Ahlberg, § 8 Rn. 28. Vgl. u. a. BGH, GRUR 1955, S. 201, 204; Dreier/Schulze, § 11 Rn. 2. Ebd. Möhring/Nicolini/Ahlberg, § 8 Rn. 33. Ebd.

104

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

scheint zunächst zweifelhaft, ob man grundsätzlich alle Urheberpersönlichkeitsrechte unter die gesamthänderische Bindung stellen sollte. Das Wesen einer Gesamthandsgemeinschaft besteht darin, dass die jeweiligen Rechte den Gesamthändern jeweils im vollen Umfang zustehen. Gem. § 11 UrhG wird der Urheber in seiner persönlichen Beziehung zu seinem Werk geschützt. Diese Norm steht für die herausragende Stellung der persönlichen Interessen des Urhebers im Normsystem des geistigen Eigentums. In den §§ 12 ff. UrhG sind die eigentlichen sedes materiae des Urheberpersönlichkeitsrecht aufgeführt234. Die Urheberpersönlichkeitsrechte sind notwendig an den jeweiligen Urheber gebunden. Dies macht vor allem § 29 I UrhG deutlich, der eine Unübertragbarkeit ja sogar eine Unverzichtbarkeit des Urheberrechts normiert235. Das spricht dafür, dass auch innerhalb einer Miturhebergemeinschaft die Urheberpersönlichkeitsrechte beim einzelnen Miturheber verbleiben. Dies wird auch von der Mindermeinung konstatiert, die sich insofern widerspricht, wenn sie einerseits sämtliche Persönlichkeitsrechte als Gegenstand der Gesamthand sieht, andererseits aber zugesteht, dass es sich hierbei doch eher um die Summe der Persönlichkeitsrechte des Einzelnen handelt. Nun geht die Mindermeinung richtigerweise davon aus, dass eine klare Abgrenzung zwischen Persönlichkeitsrechten und Vermögensrechten im Urheberrecht nicht möglich ist. Richtig ist es, dass die in §§ 15 ff. UrhG aufgeführten Verwertungsrechte auch die Funktion haben, geistige und persönliche Interessen der Urheber zu berücksichtigen. Sie können funktional als „Urheberpersönlichkeitsrecht im weiteren Sinn“ verstanden werden236. Die monistische Betrachtung des Urheberrechts als einheitliches Stammrecht führt somit dazu, dass sich eine eindeutige Unterscheidung von geistigen und persönlichen Interessen (Urheberpersönlichkeitsrecht) auf der einen Seite und wirtschaftliche sowie finanzielle Interessen auf der anderen Seite nicht durchhalten lässt237. Das führt notwendigerweise auch dazu, dass gem. § 8 II UrhG auch persönliche Interessen der Miturheber von der Gesamthand ausgeübt werden. Bei der Frage nach dem „Verbleib“ der Persönlichkeitsrechte ist es daher sinnvoll, zwischen Innen- und Außenverhältnis zu unterscheiden. Grundsätzlich verbleiben die Urheberpersönlichkeitsrechte beim einzelnen Miturheber. Er kann seine urheberrechtlichen Befugnisse grundsätzlich selbstständig in dem Umfang geltend machen, in dem die Interessen der anderen Miturheber nicht beeinträchtigt werden. Dies wird auch durch § 8 II S. 3 UrhG bestätigt. Ein Miturheber kann danach z. B. sein Recht auf Anerkennung der Miturheberschaft (§ 13 UrhG) außerhalb der Miturhebergemeinschaft gegenüber jedem 234 235 236 237

Loewenheim/Dietz, Loewenheim/Dietz, Loewenheim/Dietz, Loewenheim/Dietz,

§ § § §

15 15 15 15

Rn. Rn. Rn. Rn.

2. 17. 2. 4; Dreier/Schulze, § 8 Rn. 12.

I. Rechtsschutz von Computerprogrammen

105

Dritten alleine geltend machen. Begehrt er dieses Recht jedoch im Innenverhältnis, muss er gegebenenfalls sämtliche Miturheber im Wege einer Gesamthandklage auf Mitbenennung verklagen238. Die Grenzen der Geltendmachung der urheberpersönlichkeitsrechtlichen Befugnisse durch den einzelnen Miturheber liegen somit im Interesse der Gesamthandsgemeinschaft am Gesamtwerk239. Die Urheberpersönlichkeitsrechte verbleiben somit beim Miturheber sind in ihrer Ausübung unter Umständen durch die Gesamthand gebunden240. Eine Übertragung der Persönlichkeitsrechte auf die Gesamthand findet somit nicht statt. Die Verwaltung der Miturhebergemeinschaft erfolgt unter Zustimmung jedes Miturhebers und somit gemeinschaftlich gem. §§ 709, 714 BGB241. Ausgenommen von der Zustimmung aller Miturheber ist das Notverwaltungsrecht gem. § 744 II UrhG, wonach die zur Erhaltung des Werkes notwendigen Maßnahmen auch von einzelnen Miturhebern ohne die Zustimmung der anderen vorgenommen werden können242. Bei Urheberrechtsverletzungen ist gem. § 8 II S. 3 UrhG jeder Urheber befugt, die Rechte ohne Einholung der Einwilligung aller Miturheber geltend zu machen, wobei im Rahmen von Leistungsansprüchen die Leistung nur an alle Miturheber verlangt werden darf. Die Verwendung und Verteilung der Erträgnisse des Werkes richtet sich nach Vereinbarungen, die die Miturheber miteinander vereinbart haben. Fehlen besondere Vereinbarungen so richtet sich die Verteilung gem. § 8 III UrhG nach dem jeweiligen Mitwirkungsbeitrag des einzelnen Miturhebers. Ein jeder Miturheber kann gem. § 8 IV UrhG kann durch Erklärung gegenüber den anderen Miturhebern auf seinen Anteil verzichten. Als Folge einer Verzichtserklärung fällt sein Anteil den anderen Miturhebern zu. (d) Urheberschaft in Arbeits- und Dienstverhältnissen Die Vorschrift § 69 b UrhG trägt dem Normalfall Rechnung, dass ein Programmierer im Rahmen eines Arbeits- oder Dienstverhältnisses bei einem Softwarehersteller Computerprogramme (mit-)entwickelt. Sie bewirkt eine Übertragung aller nach dem Schöpferprinzip beim Programmierer liegenden vermögensrechtlichen Befugnisse auf den Arbeitgeber243. § 69 b UrhG als lex spezialis zu § 43 UrhG244 bewirkt, dass die Rechte am Com238 239 240 241 242 243

OLG Karlsruhe, GRUR 1984, S. 812 f.; Dreier/Schulze, § 8 Rn. 13. So auch Wandtke/Bullinger/Thum, § 8 Rn. 27. So auch Dreier/Schulze, § 8 Rn. 13. Loewenheim/Loewenheim, § 11 Rn. 5. Ebd. Wandtke/Bullinger/Grützmacher, § 69 b Rn. 1.

106

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

puterprogramm kraft Gesetz im Wege einer gesetzlichen Lizenz auf den Arbeitgeber übergehen245. Er erhält damit ein aus dem Urheberrecht des Arbeitnehmers ausschließliches Nutzungsrecht am Computerprogramm246. Aufgrund der Spezialität ist an dieser Stelle kein Raum für die allgemeine Zweckübertragungsregel247. Der Arbeitnehmer bleibt indes der Urheber seines Programmierergebnisses. Fehlen besondere vertragliche Vereinbarungen zwischen Arbeitgeber und Arbeitnehmer, ist davon auszugehen, dass der Arbeitnehmer dem Arbeitgeber zumindest stillschweigend alle zur Erreichung des Vertragszwecks erforderlichen Verwertungsrechte am Werk einräumt, solange er keinen ausdrücklichen Vorbehalt erklärt hat248. Die Vorschrift setzt aber laut ihrem Wortlaut in Abs. 1 voraus, dass der Arbeitnehmer das Computerprogramm in Wahrnehmung seiner Aufgaben oder nach Anweisung des Arbeitgebers geschaffen hat. Die Übertragung der Nutzungsrechte an den Arbeitgeber gem. § 69 b UrhG erfordert somit einen engen Zusammenhang zwischen der Programmerstellung und Ausübung der arbeitsvertraglichen Verpflichtungen249. Von der Regelung des § 69 b UrhG nicht erfasst sind die Urheberpersönlichkeitsrechte250. In Betracht kommt allerdings eine eingeschränkte Ausübbarkeit von Urheberpersönlichkeitsrechten, die sich aus den Interessen des Arbeitgebers oder Dienstherren im konkreten Fall ergeben kann251. Die Ausübung der urheberpersönlichkeitsrechtlichen Befugnisse tritt somit hinter den Vertragszweck zurück. Nicht unter die Regelung des § 69 b UrhG fallen grundsätzlich Programmentwicklungen, die Arbeitnehmer außerhalb seines Arbeits- oder Dienstverhältnisses, also außervertraglich bzw. außerdienstlich mit den ihm „privat“ zustehenden Mitteln herstellt252. Richtigerweise werden von der Vorschrift auch keine Arbeitsergebnisse umfasst, die der Arbeitnehmer vor Beginn seines Arbeitsverhältnisses erbracht hat253. An den Eigenentwick244

BT-Drucks. 12/4022, S. 10. BT-Drucks. 12/4022, S. 10; BGH, CR 2001, S. 223; BGH, GRUR 2002, S. 149, 151; Koch, § 9 Rn. 216; Schricker/Loewenheim, § 69 b Rn. 11. 246 Schricker/Loewenheim, § 69 b Rn. 11. 247 Dreier/Schulze, § 69 b Rn. 9. 248 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 50; BGH, GRUR 1984, S. 429. 249 Schricker/Loewenheim, § 69 b Rn. 6; Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 50. 250 BT-Drucks. 12/4022, S. 10; Dreier/Schulze, § 69 b Rn. 3; Lehmann, Haberstrumpf, S. 127. 251 Vgl. dazu Dreier/Schulze, § 69 b Rn. 3. 252 Koch, § 9 Rn. 229. 253 Ebd. 245

I. Rechtsschutz von Computerprogrammen

107

lungen des Arbeitnehmers stehen dem Arbeitgeber somit keine vermögensrechtlichen Befugnisse zu. Eine Verletzung der arbeitsrechtlichen Verpflichtungen kommt allerdings dann in Betracht, wenn der Arbeitnehmer mit seinen „privaten“ Programmentwicklungen in Konkurrenz zu seinem Arbeitgeber tritt254. Problematisch können hingegen Konstellationen sein, in denen der Arbeitnehmer zur privaten und damit außervertraglichen Herstellung von Computerprogrammen, Mittel und Ressourcen des Arbeitgebers nutzt. So ist es möglich, dass der Arbeitnehmer erst aufgrund seines im Arbeits- oder im Dienstverhältnis erworbenen Wissens oder durch Nutzung der technischen Infrastruktur des Arbeitgebers in der Lage war, ein Computerprogramm außerhalb seines eigentlichen Arbeits- oder Dienstverhältnisses herzustellen. In Anlehnung an das Arbeitnehmererfinderrecht wurde in derartigen Sachverhalten unter entsprechender Anwendung des ArbnErfG255 ein Übergang der Vermögensrechte auf den Arbeitgeber gem. § 69 b UrhG bejaht256. Es erscheint jedoch sehr fragwürdig, die im Arbeitnehmererfinderrecht statuierte Überlassungspflicht auf das „Arbeitnehmerurheberrecht“ zu übertragen257. Das ArbnErfG gilt gem. § 2 des Gesetzes nur für Erfindungen, die patent- oder gebrauchsmusterfähig sind. Bei der Schaffung des § 69 b UrhG war dem Gesetzgeber die unterschiedlichen Interessen von Arbeitnehmer und Arbeitgeber bekannt. Es erscheint daher auch als zu weit hergeholt, in vorliegenden Fällen von einer Gesetzeslücke auszugehen und die Vorschriften des ArbnErfG analog anzuwenden. Ausgehend von der urheberrechtlichen Regelung, die gerade einen engen Zusammenhang zwischen dem vertraglichen Aufgabenkreis oder einer Weisung des Arbeitgebers und dem jeweiligen Programmergebnis verlangt, kann somit nicht auf eine grundsätzliche Überlassung der Entwicklungsergebnisse in den Fällen ausgegangen werden, in denen der Arbeitnehmer „lediglich“ technische Infrastruktur oder am Arbeitsplatz erworbenes Wissen für eine private Programmierleistung nutzt. Der Wortlaut des § 69 b UrhG spricht gerade nicht von der Nutzung technischer Mittel des Arbeitgebers, sondern knüpft an den Inhalt der durch den Arbeitnehmer zu erfüllenden Arbeitspflicht. Somit unterfallen Schaffensergebnisse, die in der Freizeit und losgelöst von arbeitsvertraglichen Aufgaben erzielt worden sind, nicht unter die Regelung des § 69 b UrhG. Bezogen auf Computerergebnisse kann jedoch dann das ArbnErfG 254

Koch, § 9 Rn. 231. Gesetz über Arbeitnehmererfindungen. 256 LG München, CR 1997, S. 351 ff. [aufgehoben durch OLG München, NJW-RR 2000, S. 1211]. 257 So auch Schricker/Loewenheim, § 69 b Rn. 9; Koch, § 9 Rn. 232. 255

108

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Anwendung finden, wenn der Arbeitnehmer technische Lösungen entwickelt, die sich als computerimplementierte Erfindungen schützen lassen. Auf die Konsequenzen der Vorschrift § 69 b UrhG für den Bereich Open Source Software wird noch im Folgenden eingegangen258. (5) Verwertungsrechte an Computerprogrammen Die Verwertungsrechte an Computerprogrammen oder vielmehr deren Freigabe an die Nutzer stehen im Regelungsmittelpunkt von Open SourceLizenzvereinbarungen. Bevor im Folgenden die Freigabe urheberrechtlicher Positionen erörtert wird, sollen zunächst die Grundzüge der Verwertungsrechte an Computerprogrammen Gegenstand der Darstellung sein. Der Inhalt der Rechte zur Verwertung von Computerprogrammen259 ergibt sich aus dem Zusammenspiel der Regelung über die Ausschließlichkeitsrechte des Urhebers gem. § 69 c UrhG und der Schrankenregelungen des § 69 d UrhG und § 69 e UrhG. Die besonderen Regelungen des achten Abschnitts des Urheberrechts überschneiden sich in vielen Fällen mit den allgemeinen Vorschriften über die Verwertungsrechte der §§ 15 ff. UrhG260. Die Spezialvorschriften für geschützte Computerprogramme §§ 69 c bis 69 f. UrhG gehen den allgemeinen Vorschriften jedoch insoweit vor, als dass sie sich mit ihnen überschneiden und abweichende Regelungen enthalten261. Die Vorschrift des § 69 c UrhG präzisiert die ausschließlichen Nutzungsrechte für Computerprogramme und macht die Rechtmäßigkeit von Vervielfältigungen, Bearbeitungen, jede Form der Verbreitung sowie die öffentliche Wiedergabe einschließlich der öffentlichen Zugänglichmachung von der Zustimmung des Rechteinhabers abhängig. (a) Die einzelnen Verwertungsrechte Das in § 69 c Nr. 1 UrhG normierte Vervielfältigungsrecht geht auf die allgemeine Vervielfältigungsvorschrift in § 16 UrhG zurück, der der weite Vervielfältigungsbegriff zugrunde liegt262. Vom Vervielfältigungsbegriff erfasst wird jede Übertragung eines Computerprogramms auf einen anderen 258

Vgl. § 5 III Nr. 3. Ausführliche Darstellung bei Lehmann/Haberstrumpf, S. 131 ff.; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 51 ff.; Koch, § 9 Rn. 252 ff.; Pres, S. 109 ff. 260 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 51. 261 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 51. 259

I. Rechtsschutz von Computerprogrammen

109

Datenträger, wenn es dann in selbstständiger, verkehrsfähiger und maschinenlesbarer Form vorliegt. Spezifisch für Computerprogramme hat der Gesetzgeber auch das Laden, Anzeigen, Ablaufen, Übertragen oder das Speichern eines Computerprogramms für die Fälle zustimmungspflichtig gemacht, in denen hierfür eine Vervielfältigung erforderlich ist. Die eindeutige Formulierung der Vorschrift spricht dafür, dass auch schon das Laden eines Computerprogramms in den Arbeitsspeicher eine Vervielfältigungshandlung i. S. d. §§ 69 c Nr. 1, 16 I UrhG ist263. Die Frage, ob der Ablauf eines Computerprogramms eine Vervielfältigungshandlung darstellt wird unterschiedlich beantwortet264. Wenn man hier überhaupt eine Vervielfältigungshandlung annimmt, ist sie gemäß der Schrankenregelung des § 44 a Nr. 2 UrhG in der Regel zustimmungsfrei und damit rechtmäßig, da der bloße Programmablauf eines rechtmäßig erworbenen Computerprogramms keine eigenständige wirtschaftliche Bedeutung hat. Das dem Rechteinhaber zustehende Bearbeitungsrecht265 ist in § 69 c Nr. 2 UrhG normiert. Im Gegensatz zu § 23 UrhG, der nur die Veröffentlichung oder Verwertung von Bearbeitungen und Umgestaltungen regelt, untersagt § 69 c Nr. 2 lex specialis bereits die Bearbeitung oder Umarbeitung als solche266. So bedarf jede Änderung, Bearbeitung und Übersetzung eines Computerprogramms die Zustimmung des Rechteinhabers. Unter Bearbeitungen fallen beispielsweise die Erstellung des Quellcodes auf Basis der Programmbeschreibung, die Übersetzung des Quellcodes in den Objektcode, die Übertragung des Objektcodes in eine andere Programmiersprache sowie jegliche Anpassungen des Computerprogramms an andere Programme sowie Hardware267. In § 69 c Nr. 3 UrhG ist das ausschließliche Verbreitungsrecht des Rechteinhabers, einschließlich des Vermietungsrechts, geregelt. Dabei geht § 69 c Nr. 3 UrhG auf den Verbreitungsbegriff des § 17 I UrhG zurück, der Verbreitung als Recht definiert, das Originalwerkstück oder Vervielfältigungsstücke hiervon der Öffentlichkeit anzubieten oder in Verkehr zu bringen. 262 Begründung des Regierungsentwurfes, BR-Drucks. 684/02, S. 39; Marly, Rn. 164; Schricker/Loewenheim, § 69 c Rn. 6; Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 53; Dreier/Schulze, § 69 c Rn. 6. 263 Die Frage, ob das Laden eines Computerprogramms in den Arbeitsspeicher eines Computer als Vervielfältigung i. S. d. §§ 69 c Nr. 1, 16 I UrhG einzuordnen ist, ist umstritten. Die wohl überwiegende Auffassung geht bei dieser Frage allerdings von einer zustimmungsbedürftigen Vervielfältigungshandlung aus. Ausführlich zum Meinungsstand vgl. Marly, Rn. 158 ff. 264 Ausführlich dazu Marly, Rn. 188 ff. 265 Zur Terminologie vgl. Pres, S. 112 f. 266 BT-Drucks. 12/4022, S. 11; Schricker/Loewenheim, § 69 c Rn. 11. 267 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 72.

110

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Ausgehend von § 15 I UrhG, der von der Verwertung der Werke in körperlicher Form ausgeht, umfasst auch das Verbreitungsrecht in § 69 c Nr. 3 UrhG nur die Verbreitung in körperlicher Form268. Damit wird nach richtiger und überwiegender Auffassung eine Übermittlung eines Computerprogramms durch Datenfernübertragung über das Internet nicht als Verbreitung i. S. d. § 69 c Nr. 3 UrhG eingestuft269. Obwohl diese Art von Übermittlung dank der Entwicklung des Internets zu einer üblichen Vertriebsform von Software geworden ist und sich diese Art von Verbreitung mit der Weitergabe von auf einem Datenträger gespeicherter Software wirtschaftlich nicht unterscheidet, unterfällt die Übermittlungsform nicht § 69 c Nr. 3 UrhG. Der Rechteinhaber wird durch diese Einschränkung jedoch in seinem Schutzinteresse nicht beeinträchtigt, da eine derartige Onlineübermittlung eines Computerprogramms als ein unter § 15 II UrhG zu subsumierendes unbenanntes Recht der öffentlichen Wiedergabe ausschließlich dem Rechteinhaber zusteht270. Die Grenze des ausschließlichen Verbreitungsrechts liegt in dem Erschöpfungsgrundsatz, der in § 69 c Nr. 3 UrhG ausdrücklich normiert ist. Gem. § 69 c Nr. 3 UrhG steht auch die entgeltliche und zeitlich befristete körperliche Gebrauchsüberlassung von Computerprogrammen, das Vermietrecht, ausschließlich dem Rechteinhaber zu. Das Vermietrecht ist richtigerweise gem. § 69 c Nr. 3 UrhG vom Erschöpfungsgrundsatz ausgenommen. Auch im Bereich des Vermietrechts stellt sich die Frage, ob nur die körperliche Überlassung von der Vorschrift erfasst ist. Diese Frage ist in Anbetracht der aktuellen Entwicklung im Softwaresektor von besonderer Bedeutung. Die Nachfrageseite geht zunehmend dazu über, Computerprogramme extern auf Servern Dritter (Rechenzentrumsdienstleistungen, Outsourcing, Application Service Providing) zu nutzen, um so Lizenz- und Supportkosten sowie Update- und Upgradekosten einzusparen. Dabei werden Installation, Funktionsablauf und die Wartung von einem Dritten Dienstanbieter übernommen. Teilweise wird argumentiert, dass der zeitlich begrenzte Zugriff auf diese externen Leistungsangebote für eine Qualifizierung als Vermietung spricht271. Der urheberrechtliche Begriff des Vermietens ist in § 17 III S. 1 UrhG als zeitlich begrenzte, unmittelbar oder mittelbar Erwerbszwecken dienende Gebrauchsüberlassung definiert. Das Vermietrecht ist als eine Form des Verbreitens auf die Gebrauchsüberlassung körperlicher Exemplare beschränkt272. Daher ist es auch an dieser Stelle 268 Diese Frage ist umstritten. Vgl. zum Streitstand Schricker/Loewenheim, § 69 c Rn. 25 mit weiteren Nachweisen. 269 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51Rn. 60; Wandtke/Bullinger/Grützmacher, § 69 c Rn. 29; Schricker/Loewenheim, § 69 c Rn. 25; A. A. Möhring/Nicolini/Hoeren, § 69 c Rn. 12. 270 Schricker/Loewenheim, § 69 c Rn. 25. 271 Bartsch, CR 1994, S. 667, 671.

I. Rechtsschutz von Computerprogrammen

111

nur folgerichtig, die Fälle der unkörperlichen Gebrauchsüberlassung nicht unter das Vermietrecht zu subsumieren273. Das Recht der öffentlichen Wiedergabe in § 69 c Nr. 4 UrhG ist 2003 aufgrund der EU-Richtlinie zum Rechtsschutz von Computerprogrammen im Rahmen des Gesetzes zu Regelung des Urheberrechts in der Informationsgesellschaft274 in § 69 c UrhG eingefügt worden275. Vor Einführung dieser Regelung wurde die gegenüber der Öffentlichkeit erfolgende OnlineÜbermittlung und -Bereithaltung als Form der öffentlichen Wiedergabe qualifiziert, die als unbenanntes Verwertungsrecht über § 15 UrhG eingeordnet wurde276. Die Neuregelung stellt ausdrücklich klar, dass OnlineÜbertragungen Teil des Rechts der öffentlichen Wiedergabe sind und nicht etwa dem Verbreitungsrecht unterfallen277. Erfasst sind alle Formen der öffentlichen Wiedergabe i. S. d. §§ 15 II, 19 ff. UrhG, ob drahtlos oder drahtgebunden, unter ausdrücklicher Nennung des Rechts der öffentlichen Zugänglichmachung nach § 19 a UrhG278, wodurch auch die interaktive Übertragung von Computerprogrammen auf Abruf erfasst wird279. Dadurch wird ein hinreichender Schutz von Computerprogrammen dahingehend gewährleistet, dass bereits das unerlaubte Bereithalten bzw. das unerlaubte Angebot zum Download als Eingriff in das Ausschließlichkeitsrecht des Urhebers darstellt. Die Formulierung des § 69 c Nr. 4 UrhG stellt darüber hinaus klar, dass eine „sukzessive Öffentlichkeit“ für die Anwendung des Tatbestandes ausreicht. Das entspricht im Übrigen auch den Tatbestandsvoraussetzungen des § 19 a UrhG. Der Erschöpfungsgrundsatz ist hingegen in diesem Zusammenhang nicht anwendbar, was sich auch aus Art. 3 I InfoSoc-RL ergibt. (b) Ausnahmen von den zustimmungsbedürftigen Handlungen Die Schrankenbestimmungen der §§ 44 a ff. UrhG sind auf Computerprogramme nicht anwendbar280. § 69 d UrhG enthält jedoch Ausnahmen vom Zustimmungserfordernis des Rechteinhabers, die, soweit keine besonderen vertraglichen Bestimmungen vorliegen, das ausschließliche Vervielfälti272

Dreier/Schulze, § 69 c Rn. 36. So auch Wandtke/Bullinger/Grützmacher, § 69 c Rn. 44; Bettinger/Scheffelt, CR 2001, S. 729, 734. 274 BGBl. I S. 1774. 275 Ausführlich dazu Wandtke/Bullinger/Grützmacher, ErgBd., § 69 c Rn. 1 ff. 276 Wandtke/Bullinger/Grützmacher, ErgBd., § 69 c Rn. 1. 277 Wandtke/Bullinger/Grützmacher, ErgBd., § 69 c Rn. 2. 278 Dreier/Schulze, § 69 c Rn. 28. 279 Wandtke/Bullinger/Grützmacher, ErgBd., § 69 c Rn. 4. 280 Lehmann/Haberstrumpf, S. 149. 273

112

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

gungs- und Bearbeitungsrecht des Rechteinhabers in bestimmten Fällen einschränken281. Die Formulierung von § 69 d UrhG macht deutlich, dass es einen zwingenden Kern von Rechten des berechtigten Nutzers eines Computerprogramms gibt, die auch durch besondere vertragliche Vereinbarungen nicht ausgeschlossen werden können282. Vom Anwendungsbereich des § 69 c Nr. 1 und 2 UrhG werden gem. 69 d UrhG Handlungen zur bestimmungsgemäßen Benutzung (Abs. 1), die Anfertigung einer Sicherungskopie (Abs. 2) sowie das Beobachten, Untersuchen und Testen der Funktionsweise eines Computerprogramms zur Ermittlung die einem Programmelement zugrunde liegenden Ideen und Grundsätze (Abs. 3) ausgenommen. Die Vorschrift dient dazu, die bestimmungsgemäße Benutzung von Computerprogrammen zu ermöglichen und erlaubt die dafür notwendigen urheberrechtlich relevanten Handlungen jenseits von vertraglichen Vereinbarungen. Eventuelle vertragliche Vereinbarungen sind gem. § 134 BGB nichtig, sollten sie eine bestimmungsgemäße Nutzung untersagen283. Was die Herstellung einer Sicherungskopie durch den Nutzungsberechtigten angeht, ist zu beachten, dass die Erforderlichkeit der Herstellung einer Sicherungskopie entfällt, wenn der Rechteinhaber dem Nutzungsberechtigten eine Sicherungskopie zur Verfügung stellt284. Die Norm des § 69 d UrhG privilegiert jedoch nur denjenigen, der zur Nutzung eines Computerprogramms berechtigt ist285. Das führt dazu, dass es grundsätzlich im Entscheidungsbereich des Urhebers und Rechteinhabers liegt, ob ein Dritter Handlungen vornehmen kann die durch die Schranken des § 69 d UrhG legitimiert sind. (c) Dekompilierung Unter einer Dekompilierung versteht man den Vorgang, bei dem mittels eines Hilfsprogramms (Recompiler) ein ablauffähiges Computerprogramm in den Quellcode zurückverwandelt wird. Durch einen Dekompilierungsvorgang erhält man Informationen über Schnittstellen eines Computerprogramms. Die Schnittstellen (= Interfaces) eines Computerprogramms sind die Verbindungs- oder Berührungspunkte, die eine Verbindung und Interaktion mit anderen Programmen und Systemen ermöglichen. Über die Schnittstelle erfolgt der Austausch von Daten oder Steuerungssignalen zwi281 Zur Frage des Normcharakter der Vorschrift vgl. Pres, S. 120 ff. mit weiteren Nachweisen. 282 Schricker/Loewenheim, § 69 d Rn. 12. 283 Schmid/Wirth, HK-UrhG, § 69 d Rn. 2. 284 Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 79. 285 Dreier/Schulze, § 69 d Rn. 2.; Schricker/Loewenheim, § 69 d Rn. 4.

I. Rechtsschutz von Computerprogrammen

113

schen den Systemen, die miteinander kommunizieren müssen286. Informationen über die Schnittstellen von Computerprogrammen sind daher notwendig um Kompatibilität zwischen ihnen herstellen zu können. Von der Dekompilierung eines Computerprogramms ist i. d. R. das Vervielfältigungsrecht aus § 69 c Rn. 1 UrhG sowie das Übersetzungsrecht aus § 69 c Rn. 2 UrhG tangiert, was auch der Wortlaut des § 69 e I UrhG deutlich macht. § 69 e UrhG macht die Zustimmung des Rechteinhabers für Vervielfältigungshandlungen und Übersetzungshandlungen dann entbehrlich, wenn entsprechende Handlungen unerlässlich sind, um die für eine Herstellung der Interoperabilität notwendigen Informationen gewinnen zu können. Der Zweck der Handlungen ist also auf den Zweck der Schaffung von Interoperabilität mit anderen Programmen beschränkt. Die engen Voraussetzungen der Ausnahmeregelung des § 69 e UrhG sind in Abs. 1 Nr. 1–3 sind klar normiert und müssen kumulativ vorliegen. Die Dekompilierung darf nur vom Lizenznehmer, sonstigen Nutzungsberechtigten sowie von Dritten, wenn sie hierzu von den Berechtigten ermächtigt sind (Nr. 1). Eine Dekompilierung ist nicht von § 69 e UrhG gedeckt, wenn die notwendigen Informationen den Nutzern bereits zugänglich sind (Nr. 2). Darüber hinaus ist die Dekompilierung lediglich auf die Teile eines Computerprogramms beschränkt, die zur Herstellung der Interoperabilität notwendig sind (Nr. 3). In § 69 e II UrhG hat der Gesetzgeber zudem dezidiert festgelegt, wie mit den gewonnenen Informationen umzugehen ist. Sie dürfen nicht zu Zwecken verwendet werden, die über die Schaffung der Interoperabilität hinausgehen (§ 69 e II Nr. 1 UrhG). Auch ist eine Weitergabe der gewonnenen Informationen an Dritte grundsätzlich untersagt und wird nur im Fall von § 69 e II Nr. 2 UrhG gestattet. Dass es sich bei der Regelung des § 69 e UrhG um eine Vorschrift handelt, die in hohem Maße in die Interessen der Rechteinhaber eingreift, zeigt die Auslegungsregel in § 69 e III UrhG, wonach die Interessen der Rechteinhaber einerseits angemessen zu berücksichtigen sind und ein normale Auswertung des Werkes andererseits nicht beeinträchtigt werden darf. (d) Rechtsverletzungen Die Regelung des § 69 f. UrhG enthält besondere Ansprüche des Rechteinhabers in Fällen, in denen ein Verstoß gegen seine Ausschließlichkeitsrechte aus § 69 c UrhG vorliegt und keine Ausnahme gem. §§ 69 d, e UrhG besteht. So dehnt die Vorschrift die Ansprüche des Rechteinhabers im Vergleich zu § 98 UrhG dahingehend aus, dass dem Rechteinhaber ein Ver286

Lehmann/Haberstrumpf, S. 161 f.

8 Teupen

114

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

nichtungsanspruch gegen Besitzer und Eigentümer von Vervielfältigungsstücken zusteht, und zwar auch in den Fällen, in denen diese keine Urheberrechtsverletzung begangen haben (Abs. 1). Dieser Vernichtungsanspruch wird gem. § 69 f. II UrhG entsprechend auf Mittel zur Umgehung technischer Programmschutzmaßnahmen angewendet. (e) Anwendung sonstiger Vorschriften Abschließend zu den urheberrechtlichen Sonderregelungen stellt § 69 g UrhG klar, dass sonstige Rechtsvorschriften, insbesondere Patent-, Markenund Wettbewerbsrecht sowie schuldrechtliche Vereinbarungen von den besonderen Vorschriften unberührt bleiben. Gem. § 69 g II UrhG sind vertragliche Bestimmungen jedoch nichtig, wenn sie im Widerspruch § 69 d II, III UrhG und § 69 e UrhG stehen. Diese Regelungen sind somit unabdingbar.

II. Fazit Der Schwerpunkt des Rechtsschutzes von Computerprogrammen liegt im Urheberrecht. Der Gesetzgeber hat dies durch die Einführung des „Sonderurheberrechts für Computerprogramme“287 im 8. Abschnitt des UrhG unterstrichen. Sogleich lässt er ergänzenden Rechtsschutz durch Vorschriften außerhalb des Urheberrechts gem. § 69 g I UrhG ausdrücklich zu. Dem Rechteinhaber stehen damit verschiedene Schutzsysteme zur Verfügung, um sein Computerprogramm wirksam zu schützen. Das Urheberrecht und das Patentrecht stellen jedoch den Kern des Schutzes von Computerprogrammen dar. Ein Computerprogramm kann aufgrund der unterschiedlichen „Schutzrichtungen“ von Patent- und Urheberrecht vielmehr komplementär durch beide Systeme geschützt werden. Es besteht somit ein kumulativer Rechtsschutz von Computerprogrammen durch beide Systeme. Obwohl Computerprogramme unter bestimmten und eng gefassten Voraussetzungen ein patentrechtlicher Schutz zukommen kann, besteht allerdings der Nachteil im Patentrecht, dass zur Erlangung des Patents ein gesetzlich normiertes Erteilungsverfahren gem. §§ 34 ff. PatG notwendig ist. Ferner hat ein Patentverfahren nicht nur den Nachteil, dass es unter Umständen sehr kostenintensiv werden kann auch dauert es normalerweise mehrere Jahre, teilweise sogar Jahre vom Zeitpunkt der Einreichung der notwendigen Anmeldeunterlagen bis zur Erteilung des Patents288. Dieses lange Zeitfenster ist mitunter bei Computerprogrammen für die Rechteinhaber inakzeptabel, da die rasante Entwicklung nur ein zeitlich schmales 287 288

Pres, S. 145. Koch, Rn. 481.

III. Die urheberrechtliche Lizenz

115

Vermarktungsfenster zulässt. Andererseits bietet das Patentrecht als Schutzrecht auch Vorteile. Im Gegensatz zum Urheberrecht schützt das Patentrecht auch gegen Nachahmungen und vor ähnlichen funktionsgleichen Entwicklungen. Es ist aufgrund seiner einfachen Übertragbarkeit (es gibt keine „Patentpersönlichkeitsrechte“) auch im Wirtschaftsverkehr leicht verwertbar. Der Vorteil eines Urheberschutzes liegt hingegen eindeutig darin, dass er automatisch mit Schaffung des Werkes ohne besondere Verfahrensvoraussetzungen entsteht. Gerade dieser Vorteil führt dazu, dass das Urheberrecht im Bereich von Open Source Software von größerer Bedeutung ist als das Patentrecht. In den seltensten Fällen streben Entwickler von Open Source Software einen patenrechtlichen Schutz ihrer Produkte an. Die Anzahl patentrechtlich geschützter Computerprogramme dürfte sehr gering sein. Da Open Source-Programmierer an einer wirtschaftlichen Entwicklung ihrer Programme nicht interessiert sind, macht es auch keinen Sinn, ein kostspieliges Patentverfahren durchzuführen. Somit bleiben sie dem Urheberrecht als Schutzrecht notwendigerweise verbunden, da ihre Ergebnisse bei Vorliegen der Schutzvoraussetzungen automatisch geschützt sind. Aus dem rechtlichen Blickwinkel geht es den Open Source-Entwickler jedoch nicht um die Frage eines ausreichenden Schutzes ihrer Ergebnisse, sondern darum, wie sie ihre Rechte an den Computerprogrammen weitgehend freigeben können, ohne jedoch den Einfluss auf ihr Werk zu verlieren. Das Urheberrecht ist somit das zentrale Schutzsystem von Open Source Software und bildet somit berechtigterweise den Schwerpunkt dieser Arbeit.

III. Die urheberrechtliche Lizenz Es wurde bereits dargelegt, dass sich Open Source Software in der Art und Weise seiner Programmierung nicht von kommerziellen Computerprogrammen unterscheidet. Open Source ist mithin keine Frage der Herstellungsweise oder Programmierung von Computerprogrammen sondern eine Frage ihrer Lizenzierung. Die Vereinbarungen, die die Überlassung und Benutzung von Open Source Software durch den Softwareanwender regeln, werden in der Regel ausdrücklich als „Lizenzen“ bezeichnet. Das hängt maßgeblich damit zusammen, dass die Open Source-Lizenzen aus dem amerikanischen Rechtsraum stammen und dort der Terminus „License“ für die Rechtseinräumung gewerblicher Schutzrechte üblicherweise verwendet wird. Damit stellt sich zunächst die Frage, was man unter dem Terminus „Lizenz“ versteht und sie rechtlich einzuordnen ist289. 289 Rechtsfragen zu Softwareüberlassungsverträgen von Open Source Software werden im Folgenden noch ausführlich dargestellt. 8*

116

§ 4 Rechtlicher Schutz von Computerprogrammen in Deutschland

Das deutsche UrhG kennt den Begriff „Lizenz“ nicht, was dazu führt, dass er teilweise auf Ablehnung stößt.290. Doch mittlerweile hat sich der Terminus „Lizenz“ oder auch „Softwarelizenzvertrag“ in Literatur und Rechtsprechung etabliert291. Man kann eine Lizenz grundsätzlich als Befugnis verstehen, das Immaterialgüterrecht eines anderen zu benutzen292. Mit einer Lizenzerteilung wird der Gebrauch eines nichtkörperlichen geistigen Gutes in dem Umfang gewährt, wie er in der Lizenz selbst festgelegt worden ist. In einem Lizenzvertrag verpflichtet sich demnach der Lizenzgeber dazu, einem Lizenznehmer den Gebrauch eines geistigen immateriellen Gutes zu gestatten und dem Lizenznehmer die Rechte entsprechend des vereinbarten Umfangs einzuräumen293. Der Lizenznehmer verpflichtet sich in der Regel eine dem Umfang der Rechtseinräumung entsprechende Lizenzgebühr an den Lizenzgeber zu entrichten. Eine Lizenz regelt somit allein Fragen der Einräumung, Übertragung oder auch Umfang urheberrechtlicher Nutzungsrechte, sowie eine mögliche Vergütung. Sowohl Rechtsprechung als auch Literatur sehen den Lizenzvertrag, der als Vertragstyp nicht gesetzlich geregelt ist, als Vertrag sui generis an, der je nach Einzelfall auch Elemente gesetzlich geregelter Vertragstypen (Kauf-, Werk-, Miet- oder Pachtvertrag) enthalten kann294. Der Lizenzvertrag ist die Grundlage für die Einräumung von Nutzungsrechten. Gem. § 29 II UrhG ist die Einräumung von Nutzungsrechten (§ 31 UrhG) ausdrücklich vorgesehen. Die beim Lizenznehmer entstehenden Nutzungsrechte sind gegenständliche dingliche Rechte, was auch für das einfache Nutzungsrecht gilt, dass aber kein negatives Verbotsrecht gewährt295. Gem. § 31 I S. 2 UrhG können Nutzungsrechte zeitlich, räumlich oder auch inhaltlich beschränkt eingeräumt werden. Die Einräumung von Nutzungsrechten erfolgt der Lizenz entsprechend gem. §§ 398, 413 BGB296. Der Li290 Hoeren, Anm. zu LG München I, CR 2004, S. 777. Hoeren geht von einem Rechtekauf bzw. einer Rechtspacht aus. „Lizenz ist Nebel, in dessen Irrungen sich schon mancher verlaufen hat“. 291 Marly, Rn. 78; BGH CR 2003, S. 323; Hilty, MMR 2003, S. 8; Metzger, Anm. zu LG München I, CR 2004, S. 779. 292 Marly, Rn. 79 mit weiterem Nachweis; Dreier/Schulze, § 31 Rn. 4; Wandtke/ Bullinger/Wandtke/Grunert, § 31 Rn. 2. 293 Marly, Rn. 79; Bartsch, CR 1992, S. 394; Dreier/Schulze, § 31 Rn. 4; Koglin/ Metzger, S. 289. 294 BGH, NJW 1989, S. 456; Marly, Rn. 80 mit weiterem Nachweis. 295 Lehmann/Haberstrumpf, S. 150; Schricker/Schricker, Vor §§ 28 ff. Rn. 49; Rehbinder, Rn. 306; Schack, Rn. 540; Loewenheim/Loewenheim/Jan Bernd Nordemann, § 25 Rn. 1, 7; Pres, S. 149. Einer anderen Auffassung zur Folge hat die Einräumung eines einfachen Nutzungsrechts lediglich schuldrechtlichen Charakter (Fromm/Nordemann/Hertin, §§ 31/32 Rn. 2; Möhring/Nicolini/Spautz, § 31 Rn. 39).

III. Die urheberrechtliche Lizenz

117

zenzvertrag bedarf grundsätzlich keiner Schriftform und kann mündlich oder auch konkludent geschlossen werden. Inwieweit dem Lizenznehmer Nutzungsrechte übertragen werden, bestimmt sich nach dem zwischen beiden Parteien geschlossenen Vertrag297. Haben Lizenzgeber und Lizenznehmer die einzelnen Nutzungsrechte bei Abschluss des Vertrages nicht ausdrücklich bezeichnet, so bestimmt sich der Umfang der eingeräumten Nutzungsrechte nach der in § 31 V UrhG normierten Zweckübertragungsregel nach dem Vertragszweck. Ein gutgläubiger Erwerb von Nutzungsrechten scheidet aufgrund eines fehlenden Publizitäts- und Rechtsscheintatbestandes im Urheberrecht aus298. In der Praxis bezweckt die Softwareindustrie mit dem Abschluss von Lizenzvereinbarungen im Regelfall, die Rechtposition des Softwarenutzers zu beschränken299. Der Nutzer kommerzieller Software soll nur eine eingeschränkte Rechtsposition erhalten (z. B.: CPU-Klauseln)300. Die Benutzung von Beschränkungsmöglichkeiten durch den Lizenzgeber findet ihre Grenze in den Sondervorschriften der §§ 69 a ff. UrhG. Außerhalb des Urheberrechts bleibt für den Lizenzgeber zudem die Möglichkeit, schuldrechtliche Nutzungsbeschränkungen zu vereinbaren. Im Gegensatz zur kommerziellen Software, wo regelmäßig die Nutzungsbeschränkung im Mittelpunkt der Lizenzgestaltung steht, geht es bei der Lizenzierung von Open Source Software um eine weitgehende Freigabe von Nutzungsrechten.

296

Lehmann/Haberstrumpf, S. 150; Palandt/Heinrichs, § 413 Rn. 3; HK-BGB/ Schulze, § 413 Rn. 1; Dreier/Schulze, § 31 Rn. 15. 297 Bartsch, CR 1992, S. 394. 298 BGH, GRUR 1959, S. 200, 203. 299 Lehmann/Köhler/Fritsche, S. 534. 300 Ebd.; Zu den typischen „Beschränkungsklauseln“ mit Endanwendern vgl. Moritz, CR 1993, S. 263 ff.

§ 5 Open Source Software im deutschen Urheberrecht I. Open Source Software als Schutzgegenstand des UrhG Open Source Software unterscheidet sich hinsichtlich ihrer Entstehung, d. h. ihrer Programmierung nicht von „proprietären“ Computerprogrammen. Daher fällt auch Software, die mit dem Ziel sie als Open Source Software zu verbreiten, programmiert wird, grundsätzlich unter den Schutz des UrhG, wenn sie die notwendigen Schutzanforderungen des § 69 a UrhG erfüllt. Auch der englischsprachige Terminus „Open Source Software“ ändert nichts an einem möglichen Schutz über das UrhG, da eine Programmierung einer Freien Software im Geltungsbereich des UrhG ohne weiteres möglich ist1. Wie bereits erläutert, steht ein Schutz nach dem UrhG den Intentionen der Programmierer Freier Software nicht entgegen. Zumal tritt der urheberrechtliche Schutz bei Vorliegen der gesetzlichen Voraussetzungen automatisch ein. Auch bei Open Source Software ist daher das Computerprogramm gem. § 69 a III S. 1 UrhG urheberrechtlich geschützt, wenn es sich um eine individuelle geistige Schöpfung des Urhebers handelt. Jedes Open Source-Computerprogramm unterfällt damit dem Schutz des UrhG, wenn seine Programmierung das Durchschnittskönnen eines Programmierers übersteigt und Ausdruck seines individuellen Programmiererdenkens ist. Seitdem die Herabsetzung der Anforderungen an den urheberrechtlichen Schutz von Computerprogrammen durch das Inkrafttreten der Urheberrechtsnovelle 1993 festgeschrieben worden sind und auch die „kleine Münze“ urheberrechtlichen Schutz erfährt, ist somit grundsätzlich auch Open Source Software durch das UrhG geschützt soweit es sich im Einzelfall nicht bloß um ein Banalprogramm handelt2. Gerade im Bereich Open Source Software, in dem massenweise Änderung-, Anpassungs- und Verbesserungsprogrammierungen von professionellen Programmierern wie auch von Freizeitprogrammierern vorgenommen werden, ist das Programmierergebnis im Einzellfall sorgfältig daraufhin zu untersuchen, ob es sich nur um ein „Können eines Durchschnittsprogrammierers“ handelt oder ob das Ergebnis bereits als „Kleine Münze“ urheberrechtlich zu schützen ist. Vom Schutz mitumfasst 1 Davon ist zweifelsohne die Frage nach der Wirksamkeit der englischsprachigen Open Source-Lizenzen und deren Vereinbarkeit mit dem UrhG zu unterscheiden. Hierauf wird im Folgenden noch eingegangen. 2 Marly, Rn. 404.

II. Open Source Software und Anwendbarkeit des UrhG

119

sind regelmäßig das Entwurfsmaterial gem. § 69 a I UrhG. Auch der Quellcode, der im Bereich Open Source Software im Mittelpunkt des Interesses steht3, fällt als Ausdrucksform des Computerprogramms gem. § 69 a II UrhG unter den urheberrechtlichen Schutz. Soweit also ergeben sich keine Unterschiede zum Schutz „proprietärer“ Programme.

II. Open Source Software und Anwendbarkeit des UrhG/Internationales Urheberrecht und kollisionsrechtliche Einordnung von Freier Software Open Source Software und Freie Software als eine besondere Form der Softwarelizenzierung haben ihren Ursprung im amerikanischen Rechtsraum. Durch die besondere rechtliche Konstruktion der weit verbreiteten General Public License4 wurden dort erstmals die Möglichkeiten des Urheberrechtsschutzes dahingehend genutzt, die Rechte an der Werknutzung weitgehend freizugeben und so Computerprogramme als Open Source Software zu verbreiten. Aufgrund dieser Historie stammen derzeit – man muss sagen: „noch“ – nahezu die meisten Open Source-Softwareprodukte und die damit verbundenen Lizenzverträge im Bereich Open Source Software aus dem amerikanischen Rechtsraum. Auch wenn mit der „Bremer Lizenz für freie Softwarebibliotheken“ die erste Open Source Software Lizenz speziell für den deutschen Rechtsraum geschaffen wurde5, sind die namhaften Open Source-Softwareprojekte (z. B. Linux oder Open Office) amerikanischen Lizenzen unterstellt, die allenfalls in einer deutschen aber inoffiziellen Übersetzung vorliegen. An der Entwicklung von Open Source Software ist zudem meistens eine Vielzahl von Programmieren beteiligt, die ihren Sitz in unterschiedlichen Staaten haben. Die Entwicklung findet vielfach grenzüberschreitend unter Nutzung des Internets statt. Viele Softwareprojekte sind somit oft das Ergebnis von Programmierbeiträgen, die von Program3

So auch Marly, Rn. 404. Im Weiteren als GPL bezeichnet. 5 Die „Bremer Lizenz für freie Softwarebibliotheken“ ermöglicht der Verwaltung und ihren Fachverfahrenshersteller auf einfache und günstige Weise, Anwendungen des Kommunikationsstandards OSCI-Transport 1.2 zu implementieren. Dieser Kommunikationsstandard ermöglicht Interoperabilität der technischen Lösungen und sichert so die rechtsverbindliche und sichere Transaktion unter Einbeziehung elektronischer Signaturen. Entwickelt wurde die Lizenz von Till Kreutzer vom Institut für Rechtsfragen der freien und Open Source Software (ifrOSS) im Auftrag der OSCILeitstelle. Die Lizenz ist unter der Adresse: www.osci.de abrufbar. Vgl. dazu die Pressemitteilung der Freien Hansestadt Bremen vom 19.03.2004, abrufbar unter: www.bund.de/Anlage117838/pdf_datei.pdf. 4

120

§ 5 Open Source Software im deutschen Urheberrecht

mierern mit Wohnsitz in unterschiedlichen Ländern stammen. Darüber hinaus ist die Softwareverbreitung durch die digitalisierte Online-Übertragung grenzenlos. Unabhängig vom Wohnort kann jedermann Open Source Software ohne größeren Aufwand beziehen, sofern er über einen Zugang zum Internet verfügt. Open Source Software führt somit häufig zu Sachverhalten mit Auslandsberührung! Bevor auf die Wirksamkeit und den Inhalt der Open Source-Lizenzen und die damit übertragenden Verwertungsrechte eingegangen werden kann, stellt sich daher zunächst die Frage, ob die aus ausländischen Staaten stammende Open Source Software durch das UrhG Schutz erfahren kann. Im folgenden ist zu klären, wie die genannten Auslandsbezüge im Hinblick auf den Schutzbereich des UrhG rechtlich zu bewerten sind, d. h. nach welchem Urheberrecht ein Open Source-Computerprogramm bzw. das Gesamtwerk geschützt wird, welchem Recht Überlassungsverträge von Open Source Software grundsätzlich unterliegen und welche Gerichte im Streitfall zuständig. 1. Internationales Urheberrecht als Fremdenrecht In den §§ 120 ff. UrhG finden sich Bestimmungen zur Anwendung des Urhebergesetzes auch gegenüber ausländischen Staatsangehörigen. Diese Regelungen regeln aber lediglich die Rechtsfrage nach dem persönlichen Anwendungsbereich des Gesetzes. Nicht von den §§ 120 ff. UrhG erfasst sind die kollisionsrechtlichen Fragen des Urheberrechts6. Bevor man die Frage prüfen kann, ob sich jemand nach den Vorschriften der §§ 120 ff. UrhG auf den urheberrechtlichen Schutz des UrhG berufen kann, ist der Frage nachzugehen, ob das UrhG auf den Sachverhalt überhaupt anzuwenden ist. Bei Beurteilungen von Sachverhalten mit Auslandsberührung sind daher grundsätzlich drei Prüfungsschritte erforderlich: Nach welchem nationalen Urheberrecht richtet sich im Einzelfall die Frage nach Entstehung, Inhaberschaft, Inhalt und Dauer des Urheberrechts? Welchem nationalen Recht unterliegt der jeweilige Urheberrechtsvertrag? Für wen gelten bei Anwendbarkeit des UrhG die fremdenrechtlichen Anwendungsregelungen der §§ 120 ff. UrhG? a) Entstehung, Inhaberschaft, Inhalt und Dauer des Urheberrechts Obwohl gerade im „Zeitalter“ der Digitalisierung und des Internet eine grenzenlose, zeitlich unbegrenzte und gleichzeitige Werknutzung möglich 6

Kotthoff, in: HK-UrhR, § 120 Rn. 1.

II. Open Source Software und Anwendbarkeit des UrhG

121

und üblich ist, gibt es, trotz Harmonisierungsbestrebungen in diesem Bereich, weder ein international einheitliches Urheberrecht noch ein Gemeinschaftsurheberrecht der EU7. Vielmehr bestehen die nationalen Urheberrechtsordnungen nebeneinander und werden durch multilaterale Urheberechtsabkommen und völkerrechtliche Verträge ergänzt. Ein nationales Urheberrecht entfaltet also seine rechtliche Wirkung nur für das Gebiet desjenigen Staates, dessen Gesetzgeber das jeweilige Urhebergesetz erlassen hat8. Das deutsche UrhG gilt folglich nur im Hoheitsgebiet der Bundesrepublik Deutschland, d. h. es ist nur auf solche Sachverhalte anwendbar, die in diesem Hoheitsgebiet lokalisiert werden können9. Bei Sachverhalten mit Auslandsbezug entscheidet das internationale Urheberrecht über die Frage, welches Staates Urheberrecht im konkreten Sachverhalt zu prüfen ist, ob einer ausländischen Person ein Urheberrecht oder Leistungsschutzrecht am Werk zusteht und nach welchem Recht sich unter Umständen bestehende Abwehransprüche richten10. Das internationale Urheberrecht dient somit dazu, die immaterialgüterrechtlichen Fragen in einem konkreten Fall einer bestimmten Rechtsordnung zuzuordnen11. Von besonderer Bedeutung ist hier die Revidierte Berner Übereinkunft (RBÜ)12, der mittlerweile alle bedeutenden Staaten beigetreten sind. Durch die RBÜ als Völkerrechtsvertrag wird in allen wesentlichen urheberrechtlichen Fragen ein einheitliches Schutzniveau gewährleistet13. Die RBÜ stellt sicher, dass ein literarisches Werk, wozu auch Computerprogramme gezählt werden14, nicht nur in EUMitgliedstaaten sondern darüber hinaus auch in Ländern wie den USA, Japan oder China geschützt ist15. Dem internationalen Urheberrecht liegt das sog. Territorialitätsprinzip zugrunde16. Danach bleibt das nationale Urheberrecht in seiner Geltung auf 7

So auch Dreier/Dreier, Vor §§ 120 ff., Rn. 1. Dreier/Dreier, Vor §§ 120 ff., Rn. 1. 9 Rehbinder, Rn. 472. 10 Möhring/Nicolini/Hartmann, Vor §§ 120 ff. Rn. 1. 11 Schack, Rn. 793. 12 Revidierte Berner Übereinkunft zum Schutz von Werken der Literatur und Kunst vom 09.09.1886, rev. Pariser Fassung vom 24.07.1971 (BGBl 1973 II 1071); geändert durch Beschluss vom 02.10.1979 (BGBl 1985 II 81). 13 Koch, § 9 Rn. 474. 14 Troller, CR 1987, S. 352; Lehmann/Haberstrumpf, S. 86; Kilian/Heussen/ Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 142. 15 Koch, § 9 Rn. 474. 16 Dreier/Dreier, Vor §§ 120 ff. Rn. 28; Haberstrumpf, Rn. 576; Hoeren/Sieber/ Lütje/Paul, Abschn. 7.2 Rn. 240; Jaeger/Metzger, S. 89; Loewenheim/Walter/Katzenberger, § 58 Rn. 20; Möhring/Nicolini/Hartmann, Vor §§ 120 ff. Rn. 2; Schricker/Katzenberger, Vor §§ 120 ff. Rn. 120; Spindler, in: Spindler, Abschn. C Rn. 135; Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 5; Rehbinder, Rn. 472; 8

122

§ 5 Open Source Software im deutschen Urheberrecht

das Territorium desjenigen Staates beschränkt, der es bei Vorliegen der entsprechenden gesetzlichen Voraussetzungen anerkennt17. Das Prinzip hat zwingenden Charakter und entzieht sich jeglicher Disposition durch Urhebervertragsparteien18. Dem Urheber steht somit nur ein Bündel nationaler, je nach Staatsgebiet unterschiedlicher Urheberrechtssysteme gegenüber19. Aus diesem auch internationaler Konventionen (Art. 5 II S. 2 RBÜ) zugrunde liegenden Rechtsprinzip folgt, dass sich die Frage des Entstehens eines Urheberechts oder eines verwandten Schutzrechts, die Rechtsinhaberschaft, die Aktivlegitimation des Erwerbers eines Nutzungsrechts, Inhalt und Umfang des Rechts, die Übertragbarkeit des Urheberrechts, die Schutzdauer20 sowie Fragen des Gutglaubenserwerbs nach der Rechtsordnung desjenigen Staates richtet, für dessen Staatsgebiet der Schutz eines solchen Urheberrechts in Anspruch genommen wird21 (sog. Schutzlandprinzip22). Diesem Prinzip folgend wird auch die Beurteilung von Urheberrechtsverletzungen nach dem Recht desjenigen Staates beurteilt, für dessen Gebiet der Immaterialgüterschutz beansprucht wird23. Der urheberrechtliche Schutz im Schutzland ist grundsätzlich unabhängig von dem des Ursprungslands24. Das Schutzlandprinzip folgt hier aus dem Territorialitätsprinzip25. Die genannten Grundsätze stehen auch nicht zur Disposition der Parteien und können somit nicht im Wege einer Parteivereinbarung ausgeschlossen werden26. Auch ist in diesem Zusammenhang eine Anknüpfung an das Deliktsstatut ausgeschlossen, da Art. 40 EGBGB bei Verletzung urheberrechtlicher Befugnisse keine Anwendung findet27. BGH GRUR 1992, 697, 698; A. A. Schack, Rn. 806, der dem Universalitätsprinzip folgt, wonach das Urheberrecht unbeschadet seiner unterschiedlichen Ausgestaltung in den nationalen Rechtsordnungen als einheitliches Ganzes anzuerkennen ist. 17 Dreier/Dreier, Vor §§ 120 ff. Rn. 28; BGHZ 126, 252, 256. 18 BGH GRUR 1992, S. 698. 19 BGH ZUM-RD 1997, S. 548; Schricker/Katzenberger, Vor §§ 120 ff. Rn. 121. 20 Zur Schutzdauer des Urheberrechts enthält Art. 7 VIII RBÜ eine Einschränkung dahingehend, dass sich die Frage nach der Schutzdauer zwar nach dem Recht des Schutzlandes richtet, sie aber die im Ursprungsland des Werkes festgesetzte Dauer nicht übersteigen darf. 21 Loewenheim/Walter/Katzenberger, § 58 Rn. 20; Haberstrumpf, Rn. 576; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 140; Marly, Rn. 403. 22 Im Bereich des Urheberrechts ist die Maßgeblichkeit des Schutzlandprinzips zur Ermittlung des anzuwendenden Rechts unbestritten. Vgl. Kotthoff, in: HK-UrhR, § 120 Rn. 7. 23 BGH ZUM 2003, S. 225 f. 24 Schricker/Katzenberger, Vor §§ 120 ff. Rn. 132 f. 25 Kotthoff, in: HK-UrhR, § 120 Rn. 5. 26 BGH GRUR 1999, 152, 153. 27 Kotthoff, in: HK-UrhR, § 120 Rn. 7; Dreier/Dreier, Vor §§ 120 Rn. 28; Haberstrumpf, Rn. 577.

II. Open Source Software und Anwendbarkeit des UrhG

123

Für den Bereich von Open Source Software, in dem viele Lizenzmodelle amerikanischer Herkunft sind, ist hier nochmals ausdrücklich darauf hinzuweisen, dass auch die USA im Jahr 1989 der RBÜ beigetreten sind28 und das Territorialitätsprinzip somit auch dort Anerkennung gefunden hat. Alle urheberrechtlichen Fragen bezogen auf ein Open Source Softwareprodukt sind somit ausschließlich nach den Rechtsnormen des Landes zu beurteilen, für dessen Gebiet der Schutz beansprucht wird. Nimmt jemand also in Deutschland urheberrechtlichen Schutz für sein Werk in Anspruch, so sind alle für den Sachverhalt notwenigen Rechtsfragen nach deutschem Urheberrecht zu klären29. Das deutsche UrhG findet Anwendung, wenn dem Rechteinhaber vorbehaltene Verwertungshandlungen mindestens teilweise auf deutschem Territorium vorgenommen werden, d. h. Verletzungshandlungen auf deutschem Territorium stattgefunden haben und er sich dieser Handlungen urheberrechtlich erwehren will30. Nimmt beispielsweise ein amerikanischer Rechteinhaber einen in Deutschland wohnhaften Lizenznehmer wegen einer in Deutschland begangenen Urheberrechtsverletzung an einem Open Source-Computerprogramm in Anspruch, kann er sich nicht auf sein bestehendes US-Copyright berufen, sondern muss nachweisen, dass er nach deutschem Urheberrecht als Rechteinhaber anzusehen ist und ein Verstoß gegen das UrhG durch seinen Lizenznehmer vorliegt31. Ebenfalls kann sich beispielsweise ein deutscher Anwender einer aus dem amerikanischen Rechtsraum stammenden Open Source Software nicht auf einen nach USamerikanischen Copyright möglichen Verzicht des Urheberrechts berufen, da das UrhG einen Verzicht auf das Urheberrecht nicht zulässt32. Somit besteht die Möglichkeit, dass ein ursprünglich nach ausländischem Urheberrecht geschütztes Open Source-Computerprogramm nach deutschem Urheberrecht zu beurteilen ist, sofern der ausländische Rechteinhaber urheberrechtlichen Schutz innerhalb Deutschland begehrt. Bei der Klärung der Rechtsfragen von Open Source-Computerprogrammen, die aus dem ausländischem Rechtsraum stammen, ist folglich das deutsche UrhG insoweit heranzuziehen, als dass sich die Frage nach dem urheberrechtlichen Schutz des jeweiligen Programms für den deutschen Rechtsraum stellt. Im Zusammenhang mit dem vorwiegend auf Internetkommunikation basierenden Verbreitungsmodell Open Source stellt sich auch die Frage nach der rechtlichen Beurteilung grenzüberschreitender Handlungen. Im Bereich von Open Source Software ist die Produktverbreitung durch das Internet die 28 29 30 31 32

Loewenheim/v. Lewinski, § 57 Rn. 19. Kotthoff, in: HK-UrhR, § 120 Rn. 7. BGH GRUR 1994, S. 799; Haberstrumpf, Rn. 578; Jaeger/Metzger, S. 90. Vgl. auch Hoeren, CR 1993, S. 131; Jaeger/Metzger, S. 90. Spindler, in: Spindler, Abschn. C Rn. 136.

124

§ 5 Open Source Software im deutschen Urheberrecht

Regel. Nahezu alle Open Source-Computerprogramme stehen (auch im Einzelhandel vertriebene Open Source Software) zum Download auf Servern bereit. Da in vielen Fällen die Software auf Servern gespeichert ist, die sich im Ausland befinden, stellt sich die Frage nach der kollisionsrechtlichen Einordnung. Bei diesen grenzüberschreitenden Handlungen stellt sich die Frage nach dem anzuwendenden Recht. Hierbei ist darauf abzustellen, auf wessen Territorium die urheberrechtlich relevante Handlung stattgefunden hat33. Es besteht hier also das Problem der Lokalisierung des Eingriffs34. Das deutsche Urheberrecht ist jedenfalls immer dann anwendbar, wenn eine dem Urheber oder Leistungsschutzberechtigten vorbehaltende Handlung zumindest teilweise auf deutschem Territorium vorgenommen wird35. Werden Verletzungshandlungen an einer urheberrechtlich geschützten Open Source Software auch nur teilweise auf deutschem Bundesgebiet vorgenommen, ist das UrhG für die Klärung von Rechtsfragen maßgeblich. Für die OnlineÜbermittlung von Open Source Software heißt das zudem, dass die urheberrechtlichen Normen aller Länder relevant werden können, in denen das Angebot abgerufen werden kann36. Es bleibt somit festzuhalten, dass es einem Urheber oder Leistungsschutzberechtigten mit Sitz im Ausland nicht möglich ist, sich auf sein ausländisches Urheberrecht zu berufen, soweit er Schutz in der Bundesrepublik Deutschland nachsucht. Alle urheberrechtlichen Fragen richten sich hier nach dem UrhG. b) Internationales Urhebervertragsrecht Die Übertragung urheberrechtlicher Befugnisse erfolgt grundsätzlich aufgrund einer vertraglichen Parteivereinbarung. Verträge, die Auslandsbezug aufweisen, sind bezüglich der Frage des anzuwendenden Rechts gem. Art. 3 I EGBGB anhand des internationalen Urhebervertragsrechts zu überprüfen37. Dabei liegt eine Auslandsberührung regelmäßig in Fällen vor, in denen eine Vertragspartei als Angehörige eines ausländischen Staates ihren Wohnsitz im Ausland hat, der Gegenstand der Vertrages sich zumindest auch auf das Recht eines ausländischen Staates bezieht oder die Anwendung ausländischen Rechts zwischen den Vertragsparteien vereinbart wurde38. Auch urheberrechtliche Verträge unterfallen Art. 3 EGBGB. 33

Jaeger/Metzger, S. 91. Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 15; Dreier/Dreier, Vor §§ 120 ff. Rn. 31. 35 BGH GRUR 1994, S. 799; Haberstrumpf, Rn. 578; Jaeger/Metzger, S. 91 f. 36 Haberstrumpf, Rn. 578; Jaeger/Metzger, S. 93. 37 Schricker/Katzenberger, Vor §§ 120 ff. Rn. 147. 38 Haberstrumpf, Rn. 579; Schricker/Katzenberger, Vor §§ 120 ff. Rn. 147. 34

II. Open Source Software und Anwendbarkeit des UrhG

125

aa) Trennungsprinzip Bei der Beurteilung von Urheberrechtsverträgen anhand des internationalen Privatrechts ist die Trennung von Verpflichtungs- und Verfügungsgeschäft zu berücksichtigen. Ein urheberrechtlicher Vertrag besteht zunächst aus einem schuldrechtlichen Verpflichtungsgeschäft, das die einzelnen Konditionen festlegt, zu denen die Nutzungsrechte jeweils eingeräumt werden und das somit regelmäßig Grundlage der Rechtseinräumung ist39. Die aufgrund des schuldrechtlichen Verpflichtungsgeschäftes folgende Übertragung der vereinbarten Rechtspositionen erfolgt durch ein Verfügungsgeschäft für das ergänzend zu den urheberrechtlichen Vorschriften die §§ 398 ff. BGB Anwendung finden40. bb) Verpflichtungsgeschäft Das Verpflichtungsgeschäft unterliegt grundsätzlich dem Vertragsstatut41. Bei Verpflichtungsgeschäften mit Auslandsberührung gilt zunächst gem. Art. 27 I EGBGB der Grundsatz der freien Rechtswahl, wonach der Vertrag grundsätzlich dem von den Parteien gewählten Recht unterliegt42. Die Möglichkeit einer freien Rechtswahl gilt dabei auch für Urheberrechtsverträge43. Die Regelung als Ausdruck der Parteiautonomie verlangt einen übereinstimmenden Willen beider Vertragspartner dahingehend, welchem nationalen Recht der Vertrag unterliegen soll44. Sie haben sogar die Möglichkeit, den Vertrag einer Rechtsordnung zu unterstellen, zu der er keinen Bezug aufweist45. Auch kann die Rechtswahl gem. Art. 27 I S. 3 EGBGB nur auf einen bestimmten Teil des Vertrages beschränkt werden. Die Parteivereinbarung über die Rechtswahl kann ausdrücklich oder auch konkludent erfolgen46. Es ist nicht notwendig, dass die Vereinbarung bereits bei Vertragsschluss getroffen wird, so dass auch nachträgliche Rechtwahl zulässig ist47. 39

Dreier/Schulze, § 31 Rn. 15; Loewenheim/Loewenheim/Nordemann, § 26 Rn. 4. Loewenheim/Loewenheim/Nordemann, § 28 Rn. 3; Schack, Rn. 524.; Dreier/ Schulze, § 31 Rn. 15; Schricker/Schricker, Vor §§ 28 ff. Rn. 58. 41 Deike, CR 2003, S. 11. 42 Schricker/Katzenberger, Vor §§ 120 ff. Rn. 153; Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 21; Möhring/Nicolini/Hartmann, Vor §§ 120 f. Rn. 39; Haberstrumpf, Rn. 580; Jaeger/Metzger, S. 92; Spindler, in: Spindler, Abschn. C Rn. 139. 43 Loewenheim/Walter, § 57 Rn. 147. 44 Palandt, IPR, EGBGB 27 Rn. 3; v. Bar/Mankowski, IPR, Bd. I, § 7 Rn. 79. 45 Ebd. 46 Palandt, IPR, EGBGB 27 Rn. 5. 47 Palandt, IPR, EGBGB 27 Rn. 10 40

126

§ 5 Open Source Software im deutschen Urheberrecht

Einschränkungen erfährt der Grundsatz der Freiheit der Rechtswahl allerdings durch die Schutzvorschriften des internationalen Privatrechts über Verbraucher- (Art. 29 EGBGB) und Arbeitsverträge (Art. 30 EGBGB)48. Haben die Parteien weder ausdrücklich noch konkludent eine Rechtswahl getroffen und einigen sie sich auch zu keinem dem Vertragsschluss folgenden Zeitpunkt über die auf den Vertrag anzuwendende Rechtsordnung, so bestimmt Art. 28 EGBGB über das mangels Rechtswahl anzuwendende Recht. In Fällen fehlender Rechtswahl unterliegt ein Vertrag nach dem in Art. 28 I EGBGB festgeschriebenen Prinzip der objektiven Anknüpfung grundsätzlich dem Recht des Staates, mit dem der Vertrag die engsten Verbindungen aufweist49. cc) Urheberrechtliches Verfügungsgeschäft Fraglich ist die rechtliche Beurteilung von Verfügungen bei Verträgen mit Auslandsbezug. Die kollisionsrechtliche Beurteilung von urheberrechtlichen Verfügungsgeschäften ist umstritten50. Unterschiedlich beurteilt wird die Frage, ob das Vertragsstatut nicht nur für das Verpflichtungsgeschäft sondern auch für das Verfügungsgeschäft maßgeblich sein soll. Eine Mehrheit des internationalprivatrechtlichen Schrifttums51 und ein Teil der Rechtsprechung52 folgt der sog. Spaltungstheorie, wonach das Verpflichtungsgeschäft dem Vertragsstatut untersteht und das Verfügungsgeschäft dem Recht des Schutzlandes. Dagegen bekennen sich die Mehrheit der urheberrechtlichen Literatur53 und die überwiegende Rechtsprechung54 zur sog. Einheitstheorie, wonach Verpflichtungs- und Verfügungsgeschäft einheitlich dem Vertragstatut unterliegen. Die Befürworter der Einheitstheorie machen allerdings eine Einschränkung dahingehend, dass sich Fragen nach Rechtmäßig48

Palandt, IPR, EGBGB 27 Rn. 3. Palandt, IPR, EGBGB 28 Rn. 2. 50 Ausführlich dazu vgl. Schricker/Katzenberger, Vor §§ 120 ff. Rn. 147 ff.; Möhring/Nicolini/Hartmann, Vor §§ 120 ff. Rn. 42 ff.; Wandtke/Bullinger/v. Welser, Vor §§ 129 ff. Rn. 22; Loewenheim/Walter, § 57 Rn. 190 ff.; Dreier/Dreier, Vor §§ 120 Rn. 50. 51 Schack, Rn. 914, 1147; Hoeren, CR 1993, S. 133; Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 22; Weitere Nachweise auch bei Schricker/Katzenberger, Vor §§ 120 ff. Rn. 148. 52 OLG Hamburg, GRUR Int. 1959, S. 211; OLG München GRUR Int. 1960, S. 75; OLG München, ZUM 1999, S. 653. 53 Dreier/Dreier, Vor §§ 120 ff. Rn. 50; Schricker/Katzenberger, Vor §§ 120 ff. Rn. 149; Möhring/Nicolini/Hartmann, Vor §§ 120 ff. Rn. 42; Loewenheim/Walter, § 57 Rn. 190 mit weiteren Nachweisen. 54 BGH GRUR 1959, S. 331, 333; OLG München GRUR 1953, S. 302; OLG Frankfurt GRUR 1998, S. 141 f.; OLG Hamburg UFITA 1958, S. 344, 350; Schricker/Katzenberger, Vor §§ 120 ff. Rn. 149 mit weiteren Nachweisen. 49

II. Open Source Software und Anwendbarkeit des UrhG

127

keit und Zulässigkeit bezogen auf Übertragungen oder Teilübertragungen des Urheberrechts als solches oder einzelner urheberrechtlicher Befugnisse wie auch die Einräumung oder Übertragung einfacher oder ausschließlicher Nutzungsrechte stets nach dem Schutzlandprinzip richten55. Somit bleibt es bei der Frage nach Inhalt und Schutz von Urheberrechten die aufgrund von Open Source-Lizenzen mit Auslandsberührung übertragen werden bei der Anwendung des Rechts desjenigen Staates für den urheberrechtlicher Schutz nachgesucht wird56. dd) Anzuwendendes Recht bei Open Source-Lizenzen Bezogen auf die Frage nach dem anzuwendenden Recht ist im Bereich von Open Source Software im Zusammenhang mit der Verwendung ausländischer Lizenzen somit allein die Beurteilung des Verpflichtungsgeschäfts klärungsbedürftig. Wie im Folgenden noch dargestellt wird, unterliegen die Mehrzahl von Open Source-Computerprogrammen der General Public License (GPL). Sie soll hier als Beispiel dienen. (1) Vertragliche Rechtswahl gem. Art. 27 EGBGB Die GPL als eine in englischer Sprache verfasste, speziell auf die Bedürfnisse von Open Source Software zugeschnittene Lizenz, ist vor dem Hintergrund US-amerikanischen Rechts entstanden57. Nun stellt sich für das Verpflichtungsgeschäft die Frage, ob die GPL automatisch zur Anwendung ausländischen Rechts führt. Wie alle bekannten Open Source-Lizenzen58 enthält auch die GPL keine ausdrückliche Regelung zur Frage der Rechtswahl59. Natürlich haben Parteien die Möglichkeit, eine Zusatzvereinbarung zu treffen, in der sie das auf die GPL anzuwendende Recht festlegen. Wenn jedoch eine solche Vereinbarung fehlt, ist in einem zweiten Schritt zu prüfen, ob eine konkludente Rechtswahl vorliegt. Denkbar wäre es zunächst, dass bereits die Verwendung der aus dem amerikanischen Rechtsraum stammenden, in englischer Sprache abgefassten GPL ein Indiz für die Wahl USamerikanischen Rechts ist. So kann grundsätzlich die Wahl einer bestimmten Sprache ein Indiz für eine konkludente Rechtswahl sein60. Ob man al55

BGH GRUR 1988, S. 296, 298; BGHZ 136, 380; Schricker/Katzenberger, Vor §§ 120 ff. Rn. 150; a. A. aber Loewenheim/Walter, § 57 Rn. 193. 56 So auch: Jaeger/Metzger, S. 93; Schiffner, S. 110; Spindler, in: Spindler, Abschn. C Rn. 140; Deike, CR 2003, S. 11. 57 Deike, CR 2003, S. 11. 58 Jaeger/Metzger, S. 147. 59 So schon Sester, CR 2000, S. 802.

128

§ 5 Open Source Software im deutschen Urheberrecht

lerdings aus der Verwendung der GPL schon auf eine konkludente Rechtswahl schließen kann, erscheint sehr zweifelhaft. Zunächst ist die Verwendung von in englischer Sprache abgefassten Lizenzen in der Softwarebranche nahezu die Regel. Darüber hinaus steht im Bereich Open Source Software eine konkludente Rechtswahl dem realen Willen der Lizenzgeber mit hinreichender Sicherheit entgegen. Als Hauptziel der GPL und ihrer Verwender kann man wohl die Sicherstellung von freiem Zugang zu Software mit der Gewährung der dazu notwendigen Rechte sehen61. Da gerade das Konzept der Open Source Software von einer schnellen Weiterverbreitung, auch über nationale Grenzen hinaus, lebt und diese durchaus bezweckt wird, ist davon auszugehen, dass die Initiatoren der GPL eine Auslegung im Einzelfall dahingehend intendieren, die ihren Zielen am ehesten Rechnung trägt. Die Auslegung steht somit unter der Prämisse, dass die Open Source-Lizenz zum gewünschten Erfolg führt. Wäre mit der Verwendung der englischsprachigen GPL automatisch die Anwendung US-amerikanischen Urheberrechts verbunden, könnte das unter Umständen zu einer Behinderung der Verbreitung führen, da potenzielle Lizenznehmer von der Geltung US-amerikanischen Rechts abgeschreckt wären und auf die Nutzung eines Open Source-Computerprogramms verzichten würden. Damit wäre das Ziel einer schnellen Verbreitung torpediert. Darüber hinaus lässt sich aber auch noch ein weiteres Argument gegen eine Festlegung auf eine bestimmte Rechtsordnung anführen. Sicherlich war auch den Initiatoren der GPL bei der Konstruktion der Lizenz bekannt, dass urheberrechtliche Werke durch die nationalen Gesetze unterschiedlichen Schutz erfahren und es aufgrund des im Urheberrecht geltenden Schutzlandprinzips somit zu unterschiedlichen Schutzniveaus kommen kann. Um den problematischen Fall zu verhindern, dass eben das Verpflichtungsgeschäft und das urheberrechtliche Verfügungsgeschäft unter unterschiedliche Rechtordnungen fallen und somit das Risiko entstehen kann, dass die urheberrechtlichen Freiheiten, deren Gewährleistung mit der Verwendung von Open Source-Lizenzen bezweckt werden, gefährdet werden, soll dem Willen der Verwender entsprechend eine Rechtwahl durch eine Vorfestlegung verhindert werden. Danach können alle Rechtordnungen auf die Open Source-Lizenz Anwendung finden. Vor diesem Hintergrund enthalten auch die Regelungen in Ziffer 11 und 12 der GPL einen klaren Hinweis zu der Frage des anzuwendenden Rechts. Die genannten Regelungen beziehen sich auf die Frage der Gewährleistung und setzen nach ihrem Wortlaut die Klausel über die Gewährleistung in den Zusammenhang mit dem „applicable law“. In der deutschen Übersetzung der GPL, die im Auftrag der SuSe LINUX AG62 erstellt 60

Palandt, EGBGB 27 (IPR) Rn. 5. So heißt es in der Präambel der GPL: „the GNU General Public License is intended to guarantee your freedom th share and change free software . . .“. 61

II. Open Source Software und Anwendbarkeit des UrhG

129

wurde, wird die englische Formulierung mit „soweit dies gesetzlich zulässig ist“ und „durch geltendes Recht“ übersetzt. „Applicable law“ ist „anzuwendendes Recht“. Es steht eben gerade nicht in der GPL „permitted by american copyright law“, sondern es wird die oben genannte neutrale Formulierung benutzt. Auch die deutsche Übersetzung enthält eine neutrale Formulierung und spricht vom (jeweils) geltenden Recht. Die Formulierungen in der GPL enthalten somit keine Festlegung auf eine bestimmte Rechtsordnung sondern einen Vorbehalt zugunsten des anwendbaren Rechts63. Richtigerweise wird daher auch allein aus der Verwendung der GPL nicht auf eine damit verbundene Rechtswahl geschlossen64. Die GPL, wie auch andere Open Source-Lizenzen sind folgerichtig als Lizenzmodelle zu sehen, die jeder Rechtsordnung zugänglich sein sollen und im konkreten Einzelfall so auszulegen sind, dass sie mit der jeweiligen Rechtsordnung kompatibel sind und den verfolgten Zweck erreichen65. Vor diesem Hintergrund scheidet eine ausdrückliche wie auch konkludente Wahl einer bestimmten Rechtsordnung aus. Damit ist die kollisionsrechtliche Frage bezüglich des Verpflichtungsgeschäftes aber keinesfalls beantwortet. (2) Anknüpfung gem. Art. 28 EGBGB Fehlt eine konkrete Rechtswahl und lässt sich diese auch nicht aus dem Vertrag entnehmen, ist gem. Art. 28 I EGBGB der Vertrag dem Recht des Staates zu unterstellen, zu dem er die engsten Verbindungen aufweist. Anknüpfungspunkt dafür ist grundsätzlich die Erbringung der charakteristischen Leistung, d. h. die Leistung, die dem Vertragstyp seine Eigenart verleiht66. Im Rahmen von Urheberrechtsverträgen wird die charakteristische Leistung, nämlich die Rechtseinräumung, regelmäßig vom Urheber erbracht67. Dies wird jedenfalls in Fällen angenommen, in denen den Lizenznehmer lediglich eine Geldleistungspflicht trifft68. Eine Abweichung hiervon wird allerdings in Fällen angenommen, in denen den Lizenznehmer eine Verwertungs- oder Ausübungslast trifft69. Ist dies der Fall, wird angenom62 Bei Jaeger/Metzger noch als SuSe GmbH aufgeführt. Das Unternehmen gehört mittlerweile zu Novel und fimiert unter SuSe LINUX AG. 63 So auch Deike, CR 2003, S. 11. 64 Spindler, in: Spindler, Abschn. C Rn. 141; Deike, CR 2003, S. 11; Schiffner, S. 109, 175; Sester, CR 2000, S. 802. 65 So auch Sester, CR 2000, S. 802; Schiffner, S. 175. 66 Palandt, EGBGB 28 (IPR) Rn. 3. 67 Schricker/Katzenberger, Vor §§ 120 ff. Rn. 156. 68 Ebd. 69 Ebd. 9 Teupen

130

§ 5 Open Source Software im deutschen Urheberrecht

men, dass der Lizenznehmer die charakteristische Leistung erbringt und somit sein Wohn- oder Geschäftssitz für die Frage des anzuwendenden Rechts maßgeblich ist70. Auch bei Open Source-Lizenzen ist die charakteristische Leistung regelmäßig die Einräumung von Nutzungsrechten71. Steht somit die charakteristische Leistung fest, vermutet Art. 28 II EGBGB, dass der Vertrag die engste Verbindung mit der Rechtsordnung des Staates aufweist, dem der Schuldner dieser Leistung im Zeitpunkt des Vertragsabschlusses unterworfen ist72. Bei einer natürlichen Person ist das der Ort ihres gewöhnlichen Aufenthaltsortes, bei einer Gesellschaft oder einer juristischen Person regelmäßig der Sitz der Hauptverwaltung73. Die oben genannte Ausnahme im Fall von Verwertungs- und Ausübungspflichten des Lizenznehmers greift hier nicht, da Open Source-Lizenzverträgen derartige Verpflichtungen nicht zu entnehmen sind74. Sie würden zudem den gewährten Nutzungsfreiheiten des Open Source Anwenders widersprechen. Auch bei Open Source-Lizenzen ist daher folgerichtig auf den Aufenthaltsort des Anbieters der Software abzustellen75. Dabei ist hier wichtig den Begriff des „Anbieters“ nicht falsch zu verstehen. „Anbieter“ meint hier den Erbringer der charakteristischen Leistung und damit den Urheber, da nur er Nutzungsrechte übertragen kann. Selbst wenn also ein Anwender die Open Source Software von einem Distributor erlangt, erhält er die Nutzungsrechte nicht von diesem, sondern vom ursprünglichem Urheber, denn der Distributor darf im Regelfall das Programm nur unter der Benutzung der ursprünglichen Lizenz in der Form weitergeben, dass ein Anwender letztendlich mit dem Urheber direkt den Open Source-Lizenzvertrag schließt und der Distributor allenfalls als Bote auftritt76. Die Anknüpfung an den Wohnsitz des Urhebers führt jedoch gerade im Bereich Open Source Software zu Problemen, da Open Source-Programme in vielen Fällen gemeinschaftlich oder sukzessiv entwickelt werden. Hier sind häufig mehrere Urheber an der Werkschöpfung beteiligt, deren Wohnsitze nicht identisch sind. Hier stellt sich dann die Frage, an welchen Wohnsitz überhaupt angeknüpft werden kann. Deike schließt aus der Involvierung mehrerer Urheber auf die Anwendbarkeit mehrerer Rechtsordnungen77. Seiner Meinung nach entstehen in die70

Ebd. Spindler, in: Spindler, Abschn. C Rn. 142. 72 Palandt, EGBGB 28 (IPR) Rn. 4; Jaeger/Metzger, S. 147; Spindler, in: Spindler, Abschn. C Rn. 142; Deike, 2003, S. 11. 73 Palandt, EGBGB 28 (IPR) Rn. 4. 74 So auch Deike, CR 2003, S. 12. 75 Spindler, in: Spindler, Abschn. C Rn. 142; Jaeger/Metzger, S. 147. 76 So auch Spindler, in: Spindler, Abschn.C Rn. 143; Vgl. z. B. Ziff. 6 GPL, abgedruckt bei Jaeger/Metzger, S. 177 ff.; Ziff. 3.1 Mozilla Public License, abgedruckt bei Jaeger/Metzger, S. 195 ff. 71

II. Open Source Software und Anwendbarkeit des UrhG

131

sem Fall „schwierige Gemengelagen aus unterschiedlichen Rechtsordnungen, die auf den äußerlich einheitlichen Vorgang der Lizenzeinräumung anzuwenden sind“78. Will Deike so verstanden werden, dass auf das Verpflichtungsgeschäft, hier die Open Source-Lizenz, für den Fall der Miturheberschaft bestehend aus mehrerer Urhebern mit Wohnsitz in unterschiedlichen Staaten (so ja häufig der Fall), unterschiedliche Rechtsordnungen gleichzeitig anzuwenden wären, so muss ihm zumindest für den Fall der Miturheberschaft deutlich widersprochen werden. Ein Verpflichtungsgeschäft kann nicht gleichzeitig verschiedenen Rechtsordnungen unterliegen. Es ist geradezu undenkbar, dass eine Open Source-Lizenz (sofern der Verwender beispielsweise Unternehmer ist) gleichzeitig spanischem, italienischem und amerikanischen Recht unterliegen soll, wenn an der Erstellung des Programms jeweils ein Programmierer mit Wohnsitz in Spanien, Italien und Amerika beteiligt ist. Ein solches Verständnis würde eine rechtliche Klärung des Verpflichtungsgeschäftes unmöglich machen und ist daher auch abzulehnen. Aufgabe des IPR ist es ja gerade, ein Rechtsgeschäft mit internationalen Berührungspunkten einer bestimmten Rechtsordnung zuzuordnen79. Aber auch wenn anstatt einer Miturheberschaft eine Werkverbindung i. S. d. § 9 UrhG vorliegt, kann dies zu keiner anderen Beurteilung führen, da zwischen den Urhebern der verbundenen Werke eine urheberrechtliche Verwertungsgemeinschaft in Form einer BGB-Gesellschaft80 besteht. Die Anknüpfungsprobleme sind hier identisch. Fraglich ist, welche Anknüpfungspunkte man hier zu Grunde legt, um zu einer tragfähigen Lösung zu kommen. Liegt bezogen auf ein Open Source-Computerprogramm eine Gesamthandsgemeinschaft zwischen Urhebern vor, richtet sich die Anknüpfung zunächst nach dem Sitz der Verwaltung. Ist eine Miturhebergemeinschaft oder eine derartige Projektgemeinschaft satzungsmäßig verfasst und in der Satzung ein Verwaltungssitz festgelegt, so ist dieser maßgeblich. In vielen Fällen fehlt aber auch ein derartiger Anknüpfungspunkt. Im Bereich Open Source Software arbeiten die einzelnen Programmierer oft, das gemeinsame Ziel vor Augen, selbstständig nebeneinander, ohne dass sie durch eine feste Organisationsstruktur verbunden wären. Vielfach stehen sie nur mittels Fernkommunikationsmitteln (häufig E-Mail) in Kontakt. Bei Miturhebern, bei denen aber eine Organisationsstruktur gänzlich fehlt, hilft auch die Anknüpfung am Verwaltungssitz nicht weiter. Daneben gibt es auch Open Source Projekte, bei denen eine Dachorganisation Entwicklungsprozesse 77 78 79 80 9*

Deike, CR 2003, S. 12. Deike, CR 2003, S. 13. v. Bar/Mankowski, IPR, Bd. 1, § 1 Rn. 4. Dreier/Schulze, § 9 Rn. 7.

132

§ 5 Open Source Software im deutschen Urheberrecht

steuert und das jeweilige Softwareprojekt begleitet. Über die Einbindung von Neuerungen, die von verschiedenen Entwicklern vorgenommen wurden und in das Projekt implementiert werden sollen, entscheidet dann eine Art Gremium, das an der Spitze des Projektes steht. Es legt fest, welche Änderungen jeweils in die neue Version eines Projektes aufgenommen werden (so ist z. B. bei Linux Linus Torvalds regelmäßig an der Entscheidung über Neuerungen in der offiziellen Version beteiligt). Die neue Version wird dann auf der offiziellen Seite des Projektes zum Download angeboten. Nun könnte man an den tatsächlichen Verwaltungssitz dieses Entscheidungsgremiums anschließen. Wahrscheinlich ist aber, dass auch das häufig problematisch sein wird, da ein solcher fester Verwaltungssitz des Entscheidungsgremiums nicht unbedingt vorhanden sein muss. Somit ist in Fällen der Miturheberschaft sowie der sukzessiven Softwareentwicklung eine Anknüpfung schwierig zu konstruieren. Art. 28 II EGBGB enthält dem Wortlaut nach aber lediglich eine Vermutungsregel. Das spricht für die Zulässigkeit anderer Anknüpfungspunkte, wenn man mit den Vermutungsregelungen zu keinem sinnvollen Ergebnis kommt. Für eine praktische Lösung plädiert Spindler, der an den gewöhnlichen Aufenthaltsort des Betreibers des Servers anknüpft und so den Verwaltungssitz der BGB-Gesellschaft bzw. der Gesamthand am Aufenthaltsort des Serverbetreibers fixiert81. Er argumentiert, dass die verschiedenen Softwarestücke eines Open Source-Computerprogramms dort gemeinsam entwickelt und in den Verkehr gegeben würden82. Zweifelhaft ist aber, ob dieser Lösungsansatz in der Praxis wirklich überzeugen kann. Der Aufenthaltsort des Betreibers eines Servers ist zunächst identisch mit dem Serverstandort als solchem. Kein Server funktioniert einwandfrei ohne ständige Betreuung, mithin ist kein Sachverhalt denkbar, in dem Serverstandort und Aufenthaltsort des Betreibers nicht identisch sind. Die Frage nach dem Standort des Servers ist rein technisch-organisatorischer Natur und richtet sich nach rein wirtschaftlichen und praktischen Gesichtspunkten. Spindler ist insofern zu widersprechen, als dass der Serverstandort nicht notwendig der Ort ist, an dem die verschiedenen Softwarestücke gemeinsam entwickelt werden. Das kann durchaus an einem anderen Ort geschehen und kann daher nicht als Argument überzeugen. Richtig ist, dass bei einer reinen Online-Verbreitung der Serverstandort der Ort ist, an dem das Computerprogramm in den Verkehr gebracht wird. Das aber mit der Festlegung eines bestimmten Standortes zugleich ein Anknüpfungspunkt für eine bestimmte Rechtsordnung geschaffen wird, dürfte bei den Urhebern wohl unberücksichtigt und nicht bedacht worden sein. Der Standort des Servers muss ja auch in keiner 81 82

Spindler, in: Spindler, Abschn. C Rn. 143. Spindler, in: Spindler, Abschn. C Rn. 143.

II. Open Source Software und Anwendbarkeit des UrhG

133

Beziehung zum gewöhnlichen Aufenthaltsort der Urheber als Leistungserbringer stehen. Er kann auch in einem „Drittstaat“ stehen, d. h. einem Staat, zu dem eigentlich keine persönlichen Anknüpfungspunkte der beiden Vertragsparteien bestehen. Theoretisch wäre sogar denkbar, dass der Betreiber seinen Server auf einem Schiff betreibt, dass sich vorwiegend in internationalem Gewässer befindet. In einer solchen, zugegebenermaßen sehr unwahrscheinlichen Sachverhaltskonstellation, käme man mit der Anknüpfung an den Serverstandort zu keinem brauchbaren Ergebnis. Gegen die Anknüpfung am Serverstandort oder am Aufenthaltsort desjenigen, der die Software durch das Inverkehrbringen letztendlich der Öffentlichkeit zugänglich macht, spricht zudem, dass dies nicht die Partei sein muss, welche die charakteristische Leistung, also die Übertragung der Nutzungsrechte erbringt. Der Serverbetreiber oder derjenige, der die Software in Verkehr bringt, muss nicht notwendig Urheber oder Rechteinhaber sein. Die Anknüpfung am Serverstandort vermag somit nicht zu überzeugen, da diese Lösungsvariante bei problematischen Sachverhalten zu keiner interessengerechten Lösung führt. Bei der Frage nach der anzuwendenden Rechtsordnung ist aufgrund der hier geschilderten problematischen Konstellationen daher grundsätzlich am gewöhnlichen Aufenthaltsort des Lizenznehmers anzuknüpfen. Wie dargelegt handelt es sich bei Art. 28 II EGBGB lediglich um eine Vermutungsregelung. Darauf bezogen stellt Art. 28 V EGBGB fest, dass die Vermutungsregelungen der vorstehenden Absätze nicht gelten, wenn sich aus der Gesamtheit der Umstände ergibt, das der Vertrag engere Verbindungen mit einem anderen Staat aufweist. Diesem Rechtsgedanken und der Tatsache, dass die Open Source-Lizenzen international kompatibel sind, folgend, ist davon auszugehen, dass der Open Source-Lizenzvertrag die engere Verbindung mit dem Staat aufweist, in dem der Lizenznehmer als Softwareanwender seinen gewöhnlichen Aufenthaltsort hat. Dafür sprechen mehrere Gründe. Die Urheber von Open Source Software verzichten mit der Benutzung von Open Source-Lizenzen ausdrücklich auf eine Rechtswahl. Damit manifestieren sie gleichzeitig, dass sie der Wahl des anzuwendenden Rechts eine untergeordnete Rolle zumessen. Den Urhebern ist bewusst, dass sie mit der Möglichkeit des Internet-Downloads von Open Source Software Sachverhalte mit Auslandsberührung schaffen. Trotzdem haben sie sich nicht in den von ihnen verwendeten Lizenzen auf eine bestimmte nationale Rechtsordnung festgelegt. Die Verwender der GPL beispielsweise unterstellen sich gerade dem jeweiligen „applicable law“. Diese Formulierung der GPL kann sich eigentlich nur auf die Rechtsordnung am Aufenthaltsort des Nutzers beziehen, da man anderenfalls das anzuwendende Recht hätte festlegen können. Die Formulierung verdeutlicht, dass es für die Rechteinhaber

134

§ 5 Open Source Software im deutschen Urheberrecht

gar nicht vorhersehbar ist, welcher Nutzer aus welchem Land ihre Open Source Software benutzt und infolge dessen die erforderlichen Rechte erhält. Somit beziehen sie sich mit der Formulierung gerade auf die Rechtsordnung des Landes, an dem der Lizenznehmer seinen gewöhnlichen Aufenthaltsort hat. Aber auch die Art und Weise, wie der Lizenzvertrag im Bereich von Open Source Software zwischen den Parteien zustande kommt, spricht für die Anknüpfung an den gewöhnlichen Aufenthaltsort des Lizenznehmers. Erst zu dem Zeitpunkt, in dem der Softwareanwender die Software von einem Server auf seine Arbeitsstation herunterlädt und durch Ausübung der Nutzugrechte die „mitgelieferte“ Lizenzvereinbarung annimmt, kommt der Open Source Software-Überlassungsvertrag zwischen Urheber und Lizenznehmer zustande83. Somit hat der Vertragsabschluss, d. h. die Übertragung der Nutzungsrechte eine engere Beziehung zum Aufenthaltsort des Lizenznehmers. Denn die Nutzungsrechte werden ja nicht schon mit Bereitstellen der Open Source Software übertragen sondern erst bei Vornahme einer lizenzgemäßen Benutzung durch den Anwender. Darüber hinaus lässt sich für diese Auffassung anführen, dass sie die oben dargestellten Anknüpfungsprobleme vermeidet. Der Lizenznehmer, ob als natürliche oder juristische Person, ist grundsätzlich identifizierbar und sein gewöhnlicher Aufenthaltsort oder der Verwaltungssitz einfach zu ermitteln. Somit bietet sein gewöhnlicher Aufenthaltsort den erfolgversprechendsten Anknüpfungspunkt für das auf das Verpflichtungsgeschäft anzuwendende Recht im Rahmen der Überlassung von Open Source Software. Das Verpflichtungsgeschäft unterliegt folglich dem Recht des Staates, in dem der Lizenznehmer seinen gewöhnlichen Aufenthaltsort hat. (3) Verbraucherkollisionsrecht gem. Art. 29 EGBGB Open Source Software wird auf verschiedene Weise verbreitet. Praktisch alle Open Source-Computerprogramme werden auch im Internet zum Download angeboten. Das Angebot besteht somit nicht nur gegenüber Unternehmern oder Gewerbetreibenden sondern gegenüber jedem, der das jeweilige Programm in den Grenzen der Open Source-Lizenz nutzen will84. Somit richten sich solche Open Source Software Angebote auch an Verbraucher85. Bei Verbraucherverträgen mit Auslandsberührung ist die kollisionsrechtliche Regelung des Art. 29 EGBGB zu beachten86. Art. 29 83 Die genauen Umstände des Vertragsschlusses werden im Folgenden noch besprochen. 84 Palandt, EGBGB 29 (IPR) Rn. 5. 85 Ebd. 86 Moritz/Dreier/Terlau, E-Commerce, Abschn. C Rn. 248.

II. Open Source Software und Anwendbarkeit des UrhG

135

EGBGB ist zwingendes Verbraucherschutzrecht und schränkt den Grundsatz der freien Rechtswahl gem. Art. 27 EGBGB ein. Die Vorschrift verhindert, dass dem Verbraucher bei Verträgen über die Lieferung beweglicher Sachen oder Dienstleistungen zu einem Zweck, der nicht der beruflichen oder gewerblichen Tätigkeit des Verbrauchers zugerechnet werden kann, durch eine Rechtswahl der Parteien der ihm durch zwingende Bestimmungen an seinem gewöhnlichen Aufenthaltsort gewährte Schutz entzogen wird87. Darüber hinaus ist im Gegensatz zu Art. 28 II EGBGB bei Verbraucherverträgen in Fällen fehlender Rechtswahl gem. Art. 29 II EGBGB stets an die Rechtsordnung am gewöhnlichen Aufenthaltsort des Verbrauchers anzuknüpfen88. Diese Regelung ist im Bereich Open Source Software von großer Relevanz, da gerade Open Source Software in vielen Fällen von Verbrauchern aus dem Internet heruntergeladen wird, die die Software zu privaten Zwecken nutzen, also weder gewerblich noch zu beruflichen Zwecken handeln. Anwendungsvoraussetzung des Art. 29 I Nr. 1 EGBGB ist ein dem Vertragsschluss vorausgehendes ausdrückliches Angebot oder eine Werbung im Aufenthaltsstaates des Verbrauchers, das auf der Initiative des Vertragspartners, also des „Anbieters“, beruht89. Ein Internetauftritt, auf dem ein Produkt beworben und angeboten wird, reicht regelmäßig hierfür aus90. Open Source Software Angebote im Internet sind regelmäßig auch nicht auf bestimmte Länder beschränkt und werden zudem mit dem Willen betrieben, dass die Seiten in Deutschland abgerufen werden91. Die Angebote auf Internetseiten richten sich aufgrund der weltweiten Abrufbarkeit auch an den Aufenthaltsstaat des Verbrauchers92. Es liegt mithin ein ausdrückliches Angebot in Deutschland i. S. d. Art. 29 Nr. 1 EGBGB vor93. Lizenzgebührenfreie Open Source Software soll gerade auch unter Verbrauchern eine weite Verbreitung finden und steht daher jedermann zum Download zur Verfügung, was für eine Inlandsgeschäftstätigkeit der Anbieter spricht. Auch werden bei dem Download von Open Source Software die von Art. 29 Nr. 1 EGBGB geforderten zum Vertragsschluss führenden Rechtshandlungen in Deutschland vorgenommen. Der Nutzer nimmt den Lizenzvertrag durch Nutzung der 87

Palandt, EGBGB, 29 (IPR) Rn. 4. Moritz/Dreier/Terlau, E-Commerce, Abschn. C Rn. 253; Palandt, EGBGB 29 (IPR) Rn. 7. 89 Palandt, EGBGB, 29 (IPR) Rn. 5. 90 Hoeren/Sieber/Mehrings, 13.2, Rn. 57; Palandt, EGBGB, 29 (IPR) Rn. 5. 91 Somit kann die Streitfrage hier ungeklärt bleiben, ob für die Anwendung des Art. 29 I Nr. 1 EGBGB allein die Möglichkeit eines Abrufes der Werbung oder des Angebotes ausreicht oder ob es erforderlich ist, dass das Angebot oder die Werbung bestimmungsgemäß in Deutschland abgerufen werden soll. Vgl. dazu: Hoeren/ Sieber/Mehrings, 13.1, Rn. 58. 92 Ebd. 93 Deike, CR 2003, S. 12. 88

136

§ 5 Open Source Software im deutschen Urheberrecht

ihm durch die Open Source-Lizenz gewährten Rechts an. Somit sind bei Open Source Angeboten im Internet die Voraussetzungen des Art. 29 Nr. 1 EGBGB erfüllt94. Fraglich erscheint an dieser Stelle aber, ob das Angebot zum Download von Open Source Software als Lieferung beweglicher Sachen oder als Erbringung von Dienstleistungen i. S. v. Art. 29 I EGBGB eingeordnet werden kann. Um die Frage nach der Sachqualität von Software wird seit jeher unter „Softwarerechtlern“ heftig gestritten95. In gerichtlichen Auseinandersetzungen betreffend die Sachqualität von Software ging es meistens um Anwendung kaufrechtlicher Gewährleistungsvorschriften. Der BGH hat in früheren Entscheidungen die Regelungen über die kaufrechtliche Gewährleistung „zumindest analog“ für anwendbar erklärt96. Das Gericht hat sich mittlerweile dahingehend festgelegt, ein Computerprogramm grundsätzlich als Sache i. S. d. § 90 BGB einzuordnen, wenn das Programm auf einem Datenträger verkörpert ist97. Bezogen auf Open Source Software und die Anwendung von Art. 29 EGBGB ist hier allerdings zu differenzieren. Open Source Software wird nur selten auf einem körperlichen Datenträger verbreitet. Der häufigere Fall ist die unkörperliche Internet-Verbreitung. Fraglich ist, wie die Formulierung „Lieferung beweglicher Sachen“ in Art. 29 I EGBGB auszulegen ist. Schiffner sieht in diesem Zusammenhang den „Warenkauf“ als typischen Anwendungsfall und fasst „auch alle Verträge über eine dauerhafte Überlassung von Softwareprodukten“ darunter98. Nach seiner Auffassung ist Art. 29 I EGBGB unproblematisch auf Open Source Software-Überlassungsverträge anzuwenden. Auch Jaeger/Metzger verweisen in diesem Zusammenhang auf die BGH-Rechtsprechung und die darauf folgenden analoge Anwendung der „Regelungen über bewegliche Sachen“99. Ihrer Meinung nach kann nicht allein die Vertriebsform (körperlicher Datenträger oder unkörperliche Internetverbreitung) über die Anwendbarkeit des Art. 29 EGBGB entscheiden, da dies zu einer Schlechterstellung desjenigen führen würde, der das Programm aus dem Internet herunterläd, was mit den verbraucherschützenden Zielen des Art. 29 EGBGB unvereinbar wäre. Spindler begründet die Anwendbarkeit des Art. 29 I EGBGB mit dem Hinweis auf den „weiten Warenbegriff“ des UN-Kauf94 Jaeger/Metzger, S. 146; Schiffner, S. 178; Spindler, in: Spindler, Abschn. C Rn. 145. 95 Schneider, HER, Abschn. D, Rn. 275 ff.; Kilian/Heussen/Moritz, CHB, Nr. 31 Rn. 16 ff.; Marly, Rn. 69 ff. 96 BGH, CR 1988, S. 124, 127; bestätigt in BGH NJW 1990, S. 320 f.; BGH, CR 1997, S. 473; Jaeger/Metzger, S. 147. 97 BGH NJW 1993, S. 2438; Marly, Rn. 106. 98 Schiffner, S. 178. 99 Jaeger/Metzger, S. 146 f.

II. Open Source Software und Anwendbarkeit des UrhG

137

rechts100. Art. 1 I CISG101 enthält seiner Meinung einen weiten Warenbegriff. Waren sind danach alle beweglichen Gegenstände, die typischerweise Gegenstand eines Handelskaufs bilden und „ihrem Sinn und Zweck nach nicht auf körperliche Sachen zu beschränken sind“102. Mitumfasst sei folglich auch Software, die als immaterielles Gut im Internet übertragen wird103. Richtigerweise weist Spindler im Rahmen der Argumentation darauf hin, dass die Vorschriften des CISG lediglich für Kaufverträge Anwendung finden, was Art. 1 I und Art. 4 I CSIG ausdrücklich festlegen und darüber hinaus Verbraucherkäufe gem. Art. 2 lit. A CISG von den Regelungen des Übereinkommens ausgenommen sind104. Wie sich im Rahmen dieser Arbeit noch zeigen wird, liegt den Verträgen über die Überlassung von Open Source Software aber nach einhelliger Ansicht jedenfalls kein Kaufvertrag zugrunde105. Zudem erfolgt die Überlassung von Open Source Software gerade auch gegenüber Verbrauchern, die Open Source Software rein zum persönlichen Gebrauch einsetzen. Dem Einwand, er argumentiere mit Regelungen eines Übereinkommens, dass auf diese Fallkonstellationen gar keine Anwendung findet, beugt Spindler damit vor, dass er lediglich den weiten Warenbegriff des CISG verwendet106. Die dargestellten Meinungen kommen somit zu dem Ergebnis, dass es sich bei der Überlassung von Open Source Software, auch für den Fall der Online-Übermittlung, um einen Vertrag über die Lieferung beweglicher Sachen i. S. d. Art. 29 I EGBGB handelt. Art. 29 EGBGB dient dem Verbraucherschutz. Der Nutzer, der ein Produkt zu seinem privaten Gebrauch erwirbt, soll bei Verträgen mit Auslandsberührung nicht dem Risiko ausgesetzt sein, durch einem ihm vom meist verhandlungsstärkeren Anbieter „aufgezwungene“ Rechtswahl, die ihm durch die Rechtsordnung seines Aufenthaltsstaates grundsätzlich gewährten Schutzrechte zu verlieren. Die Auslegung der Anwendungsvoraussetzung „Lieferung beweglicher Sachen“ ist dem Regelungszweck entsprechend auszulegen. Dem Verweis auf den weiten Warenbegriff des CSIG in Zusammenhang mit Art. 29 EGBGB ist zuzustimmen. Das CISG ist in Fällen des internationalen Privatrechts gem. Art. 1 lit. A und B anzuwenden107 100

Spindler, in: Spindler, Abschn. C Rn. 146. Übereinkommen der Vereinten Nationen über Verträge über den internationalen Warenkauf, BGBl. II S. 1477. 102 Spindler, in: Spindler, Abschn. C Rn. 146 mit weiteren Nachweisen. 103 Brandi-Dohrn, CR 1991, S. 708; Spindler, in: Spindler, Abschn. C Rn. 146 mit weiteren Nachweisen. 104 Ebd. 105 Vgl. § 9 I. Nr. 4. 106 Ebd. 107 Hoeren/Sieber/Mehrings, Nr. 13.1 Rn. 13. 101

138

§ 5 Open Source Software im deutschen Urheberrecht

und führt mit seinem weiten Warenbegriff richtigerweise auch zur Einbeziehung von Standardsoftware, die in unkörperlicher Form durch das Internet übertragen wird108. Aber auch ohne die Auslegungshilfe des CISG in Anspruch zu nehmen kommt man zur Einbeziehung online übertragener Software in den Anwendungsbereich des Art. 29 EGBGB. Es kann keinen Sinn machen, bei der Einordnung von Standardsoftware danach zu unterscheiden, ob sie auf einem körperlichen Träger übergeben wird oder zum Download im Internet angeboten wird. Es handelt sich hierbei nur um unterschiedliche Vertriebsformen. Würde man die Einordnung aber verschieden vornehmen, so könnte allein der Anbieter durch die Festlegung eines bestimmten Vertriebsweges die Anwendung der Schutzvorschrift des Art. 29 EGBGB ausschließen. Der mit der Vorschrift bezweckte Verbraucherschutz würde allein der Disposition des Anbieters unterfallen109. Diese Sichtweise würde dem verbraucherschützenden Zweck der Vorschrift widersprechen. Darüber hinaus erscheint auch zweifelhaft, ob Software, die online übertragen wird, als unkörperlich einzuordnen ist. Damit Software überhaupt eine Funktion erfüllen kann, muss sie auf einem Speichermedium festgehalten sein. Das Speichermedium kann eine CD-ROM, eine DVD, ein USBStick sowie ein Server oder eine Festplatte sein. Alle diese Speichermedien sind aber körperliche Gegenstände. Wenn Software über das Internet übertragen wird, wird sie in der Regel von Server zu Server oder von Server zu Festplatte einer Arbeitsstation übertragen. Beim Nutzer auf der Arbeitsstation angekommen, ist die Software also wieder auf einem körperlichen Datenträger gespeichert. Es sind somit keine Sachverhalte denkbar, in denen Software ohne Speicherung auf einem körperlichen Datenträger überhaupt einsetzbar wäre. Somit muss auch die online auf ein neues Speichermedium übertragene Software als bewegliche Sache i. S. d. Art. 29 EGBGB eingeordnet werden. Aus dem Gesagten folgt, dass auch die im Internet angebotene Open Source Software in den Anwendungsbereich des Art. 29 EGBGB fällt. Im Bereich von Open Source Software führt das grenzüberschreitende Angebot von Software gegenüber Verbrauchern bei für den Verbraucher nachteiligen Rechtswahlklauseln sowie in Fällen fehlender Rechtswahl aufgrund der kollisionsrechtlichen Regelung des Art. 29 I, II EGBGB zur Anwendung des Rechts des Staates, in dem der Verbraucher seinen gewöhnlichen Aufenthaltsort hat. 108 So auch: Hoeren/Sieber/Mehrings, Nr. 13.1 Rn. 19; Staudinger/Magnus, Art. 1 CISG Rn. 44; OLG Koblenz, RIW 1993, S. 934; OLG Köln, RIW 1994, S. 970 f. 109 So auch Spindler, in: Spindler, Abschn. C Rn. 147.

II. Open Source Software und Anwendbarkeit des UrhG

139

c) Persönlicher Anwendungsbereich des UrhG bei Sachverhalten mit Auslandsbezug Die grenzüberschreitende Entwicklungsweise wirft neben den kollisionsrechtlichen Fragen auch die Frage nach dem persönlichen Anwendungsbereich des UrhG auf. Beide Fragestellungen sind deutlich voneinander zu trennen. Das in den §§ 120 ff. UrhG geregelte Fremdenrecht bestimmt, wer durch das UrhG geschützt wird und ob auch Ausländer im Inland urheberrechtlichen Schutz genießen, wohingegen das Kollisionsrecht dann im Einzelfall bestimmt nach welcher Rechtsordnung sich der Schutz richtet110. Grundsätzlich genießen deutsche Staatsangehörige gem. § 120 I S. 1 UrhG den Schutz des UrhG für ihre Werke. Dabei spielt es keine Rolle, ob und wo ihre Werke erschienen sind oder sie erstmalig im Ausland oder im Inland erschienen sind111. Im Fall der Miturheberschaft reicht es gem. § 120 I S. 2 UrhG aus, wenn ein Miturheber die deutsche Staatsangehörigkeit hat. Sobald also an der Programmierung eines Open Source Softwareprogramms nur ein Programmierer mit deutscher Staatsangehörigkeit beteiligt ist, ist der persönliche Anwendungsbereich für die Gesamthand eröffnet. Auch für die ausländischen Miturheber besteht dann der Schutz nach dem UrhG112. Die Vorschrift des § 120 II UrhG verweist auf Art. 116 I GG, und stellt damit Flüchtlinge oder Vertriebene deutscher Volkszugehörigkeit unter den dort genannten Voraussetzungen des deutschen Staatsangehörigen gleich113. Staatenlose und Flüchtlinge müssen allerdings gem. §§ 122, 123 UrhG ihren gewöhnlichen Aufenthaltsort in Deutschland haben, damit ihnen der Schutz des UrhG gewährt wird. Als Reaktion auf die EuGH Entscheidung vom 20.10.1993 (sog. Phil-Collins-Entscheidung), in der der EuGH eine Diskriminierung aufgrund der Staatsangehörigkeit als unvereinbar mit dem im EGV verankerten Diskriminierungsverbot ansah, wurde der persönliche Anwendungsbereich des UrhG durch das dritte UrhGÄndG vom 23.06.1995 auch auf Staatsangehörige eines Mitgliedstaates der EU und des EWR ausgedehnt (§ 120 II Nr. 2)114. Ist deutsches Urheberrecht auf einen Sachverhalt anwendbar, so regelt § 121 UrhG die Entstehung von Urheberrechten an Werken von Urhebern 110

Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 2. Schricker/Katzenberger, § 120 Rn. 2; Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 138. 112 Schricker/Katzenberger, § 120 Rn. 11. 113 Wandtke/Bullinger/v. Welser, § 120 Rn. 2. 114 Haberstrumpf, Rn. 583; Wandtke/Bullinger/v. Welser, § 120 Rn. 3. 111

140

§ 5 Open Source Software im deutschen Urheberrecht

mit ausländischer Staatsangehörigkeit115. Gem. § 121 VI UrhG steht dem ausländischem Urheber ein Mindestschutz an seinen Urheberpersönlichkeitsrechten (§§ 12–14 UrhG) zu. Dieser besteht im Geltungsbereich des UrhG für alle Ausländer116. Darüber hinaus erhalten sie uneingeschränkt den deutschen Urheberrechtsschutz für solche Werke, die auf deutschem Territorium erschienen sind und nicht früher als 30 Tage vor dem Erscheinen in der Bundesrepublik Deutschland außerhalb des Bundesgebietes erschienen sind (§ 121 I UrhG)117. Erscheint ein Open Source-Computerprogramm eines ausländischen Urhebers also erstmalig in Deutschland, so ist er als Urheber durch das UrhG geschützt. Im Übrigen richtet sich ein Schutz ausländischer Urheber gem. § 121 IV UrhG nach dem Inhalt der Staatsverträge. Die für den Bereich Open Source Software urheberrechtlich relevanteste Reglung ist § 120 I S. 2 UrhG. Gerade durch die gemeinschaftliche und grenzüberschreitende Entwicklungsweise sind viele Fallkonstellationen denkbar, in denen ein ausländischer Urheber durch das UrhG Schutz erfährt, sofern nur einer seiner Miturheber die deutsche Staatsangehörigkeit hat. 2. Zuständigkeit und prozessuale Gesichtspunkte bei Open Source Software/Internationales Zivilverfahrensrecht Am 19.05.2004 hatte Open Source Software in Deutschland vor dem Landgericht München I große „Premierenfeier“. Das Landgericht München I118 setzte sich als erstes deutsches Gericht mit Rechtsfragen der GPL auseinander119. Erstmals waren Regelungen der GPL Gegenstand eines gerichtlichen Verfahrens in Deutschland. Bei den vielen ungeklärten und teilweise umstrittenen Rechtsfragen in diesem Bereich ist damit zu rechnen, dass auch aufgrund des zunehmenden Einsatzes von Open Source Software, weitere Entscheidungen auf diesem Gebiet folgen werden. Das wirft die Frage auf, in welchen Fällen sich deutsche Gerichte mit Rechtsfragen von Open Source Software auseinander setzen müssen, da gerade die Möglichkeit einer Auslandsberührung der streitigen Sachverhalte sehr hoch ist.

115 116 117 118 119

Möhring/Nicolini/Hartmann, § 121 Rn. 1. Möhring/Nicolini/Hartmann, § 121 Rn. 2. Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 139. Urteil vom 19.05.2004, AZ.: 21 O 6123/04. Das Urteil wird noch ausführlich gewürdigt.

II. Open Source Software und Anwendbarkeit des UrhG

141

a) Zuständigkeit Zunächst stellt sich die Frage, welche Gerichte im Falle einer gerichtlichen Auseinandersetzung über Urheberrechte mit Auslandsbezug zuständig sind. Unter Urheberrechtsstreitigkeiten kann man in diesem Zusammenhang alle Rechtsstreitigkeiten fassen, durch die ein Anspruch aus einem im UrhG geregelten Rechtsverhältnis geltend gemacht wird120. aa) Rechtsstreitigkeiten ohne Auslandsbezug (1) Die Zuständigkeiten Die Zuständigkeit deutscher Gerichte bei Streitigkeiten im Zusammenhang mit Open Source Software ohne Auslandsbezug richtet sich ausschließlich nach den Vorschriften der Zivilprozessordnung121 und ist in der Regel unproblematisch. In Fällen, in denen zwischen den Parteien keine Gerichtsstandvereinbarung getroffen wurde, gilt für Urheberrechtsstreitigkeiten der allgemeine Gerichtsstand (§ 12 ZPO) des Schuldners122. Die möglichen allgemeinen Gerichtsstände einer Person sind je nach konkreter Sachlage verschieden und finden sich in den §§ 13 ff. ZPO. Bei Klagen aufgrund von Urheberrechtsverletzungen gem. §§ 97 ff. UrhG kommt hingegen regelmäßig der Gerichtstand der unerlaubten Handlung gem. § 32 UrhG in Betracht, da eine Verletzung der Urheber- und Leistungsschutzrechte regelmäßig einen Sonderfall der unerlaubten Handlung darstellt123. Das Urheberrecht als Immaterialgüterrecht ist Eigentum i. S. d. § 823 BGB und unterliegt somit seinem Schutz.124 Im Falle von unerlaubten Handlungen in Form von Urheberrechtsverletzungen ist nach § 32 UrhG das Gericht zuständig, in dessen Bezirk die Handlung begangen wurde. Damit ist jeder Ort gemeint, an dem zumindest eines der Tatbestandsmerkmale der unerlaubten Handlung verwirklicht worden ist125. Der Ort des Schadenseintritts ist dabei so lange irrelevant, wie der Schadenseintritt nicht erst die Vollendung der Rechtverletzung darstellt126. Bezogen auf Urheberrechtsverletzungen ist also der Ort relevant, an dem die Leistungsschutzrechte verletzt wurden. Wird demnach in der Bundesrepublik Deutschland durch Verletzungshandlungen an Leistungsschutzrechten gegen wirksam vereinbarte 120 121 122 123 124 125 126

Möhring/Nicolini/Lütje, § 105 Rn. 4. Im Weiteren als ZPO abgekürzt. Lüke, Rn. 86. Möhring/Nicolini/Lütje, § 105 Rn. 6. Palandt/Thomas, § 823 Rn. 15; HK-BGB/Staudinger, § 823 Rn. 39. BGHZ 21, 266, 270; Möhring/Nicolini/Lütje, § 105 Rn. 6. Möhring/Nicolini/Lütje, § 105 Rn. 6.

142

§ 5 Open Source Software im deutschen Urheberrecht

Open Source-Lizenzvereinbarungen verstoßen, sind deutsche Gerichte zuständig127. Örtlich ist dann das Gericht zuständig, in dessen Bezirk die Verletzungshandlung vorgenommen wurde. (2) Gerichtsstandvereinbarung Darüber hinaus besteht unter bestimmten Voraussetzungen die Möglichkeit, dass ein im ersten Rechtszug an sich unzuständiges Gericht im Wege einer wirksamen Gerichtsstandsvereinbarung die Zuständigkeit in einem Rechtsstreit erhält. Gem. § 38 I ZPO ist eine derartige Gerichtsstandsvereinbarung zulässig, wenn es sich bei den Vertragsparteien um Kaufleute, um juristische Personen des öffentlichen Rechts oder um öffentlich-rechtliche Sondervermögen handelt128. Die Gerichtsstandvereinbarungen zwischen Parteien aus den genannten Personenkreisen sind formfrei möglich und können daher ausdrücklich wie auch stillschweigend sogar in Fällen vereinbart werden, in denen die Prorogation für beide Parteien kein Handelsgeschäft ist129. Gerade im Bereich Open Source Software erfolgen, wie sich noch zeigen wird, in der Regel keine schriftlichen Vertragsvereinbarungen. Die Lizenzen werden regelmäßig nicht von den Vertragsparteien unterschrieben. In solchen Fällen wäre aber eine wirksame Gerichtsstandvereinbarung zwischen den genannten Personengruppen grundsätzlich möglich, da für eine Gerichtsstandsvereinbarung i. S. d. § 38 I ZPO keine Formerfordernisse bestehen. Ein Problem kann sich aber daraus ergeben, dass Open Source-Lizenzen ihrem Inhalt nach grundsätzlich nicht verändert werden dürfen. Dennoch ist es möglich, eine Gerichtsstandvereinbarung etwa als besondere schuldrechtliche Vertragsvereinbarung, außerhalb der eigentlichen Open Source-Lizenz oder auch als Nebenabrede zur Open Source-Lizenz zu vereinbaren130. Die urheberrechtliche Zweckbestimmung wird hierdurch nicht angetastet. Daneben besteht die Möglichkeit, Gerichtsstandvereinbarungen in Fällen mit Auslandsbezug zu schließen, sog. „internationale“ Prorogation131. Die Vorschrift ist im Zusammenhang mit internationalen Verfahrensvorschriften wie Art. 17 EuGVÜ und Art. 23 EUGVO zu sehen132. Wenn eine der beiden Vertragsparteien keinen allgemeinen Gerichtsstand im Inland hat, besteht gem. § 38 II S. 1 ZPO die Möglichkeit, die Zuständigkeit eines 127 128 129 130 131 132

So auch Jaeger/Metzger, S. 88. Zu den Einzelheiten vgl. Zöller/Vollkommer, § 38 Rn. 18. Zöller/Vollkommer, § 38 Rn. 20. Vgl. auch Zöller/Vollkommer, § 38 Rn. 20. Zöller/Vollkommer, § 38 Rn. 23. Ebd.

II. Open Source Software und Anwendbarkeit des UrhG

143

eigentlich im ersten Rechtszug nicht zuständigen Gerichts durch eine entsprechende Gerichtsstandsvereinbarung zu begründen. Nach dem „Domizilprinzip“ ist der alleinige Anknüpfungspunkt der vorstehenden Regelung der Wohnsitz der vertragsschließenden Parteien133. Weder die Staatsangehörigkeit noch die Kaufmannseigenschaft spielen hier eine Rolle, so dass auch für Nichtkaufleute grundsätzlich die Möglichkeit besteht, eine Gerichtsstandvereinbarung gem. § 38 II ZPO zu treffen134. Voraussetzung ist lediglich, dass mindestens eine Partei im Zeitpunkt des Vertragsschlusses im Inland keinen allgemeinen Gerichtstand hat135. Wirksamkeitsvoraussetzung der Gerichtsstandvereinbarung ist gem. § 38 II S. 2 ZPO jedoch, dass die Vereinbarung schriftlich geschlossen wird oder dass eine mündliche Vereinbarung schriftlich bestätigt wird. Dieses den Anforderungen genügende Formerfordernis wird auch als „halbe Schriftlichkeit“ bezeichnet136. Mit der Schriftform ist nicht die des § 126 BGB gemeint137. Danach reicht für das Formerfordernis ein Schriftwechsel i. S. d. § 127 S. 2 BGB aus138. Auch eine Gerichtsstandvereinbarung in diesen Fällen durch die Verwendung von AGB ist nicht ausgeschlossen, wenn der Vertragstext eine ausdrückliche Bezugnahme auf die AGB enthält139. Ein Stillschweigen genügt regelmäßig nicht140. Eine wirksame schriftliche Bestätigung i. S. d. § 38 II S. 2 ZPO erfordert eine inhaltliche Bezugnahme auf eine bereits zu einem früheren Zeitpunkt getroffene mündliche Gerichtsstandvereinbarung, die der anderen Partei zeitnah zugehen muss und von ihr unwidersprochen bleibt141. Ein Schweigen auf eine erstmalig in der Auftragsbestätigung enthaltene Gerichtsvereinbarung reicht auch hier nicht aus142. Fraglich ist, ob eine internationale Prorogation mit den erforderlichen Formerfordernissen im Bereich Open Source Software praktisch vorstellbar ist. Wie bereits festgestellt, werden Open Source-Lizenzen grundsätzlich nicht schriftlich vereinbart, da eine regelmäßig schriftliche Vereinbarung die schnelle unkomplizierte Ver133 Zöller/Vollkommer, § 38 Rn. 26; Zum Streit, ob die in § 38 I genannten Personenkreise die Formvoraussetzungen des Abs. II auch erfüllen müssen und es sich somit bei Abs. II nicht um eine abschließende Sonderregelung für die internationale Zuständigkeit handelt vgl. Zöller/Vollkommer, § 38 Rn. 25. 134 Ebd. 135 Ebd. 136 Zöller/Vollkommer, § 38 Rn. 27. 137 Zöller/Vollkommer, § 38 Rn. 27; Da Abs. II dem Art. 17 EuGVÜ nachgebildet ist vgl. zum Schriftformerfordernis auch: BGH NJW 2001, 1731 zu Art. 17 EuGVÜ/LugÜ. 138 Ebd. 139 Zöller/Vollkommer, § 38 Rn. 27. 140 Ebd. 141 Zöller/Vollkommer, § 38 Rn. 28. 142 Ebd.

144

§ 5 Open Source Software im deutschen Urheberrecht

breitung, die ja im Bereich Open Source regelmäßig gewünscht ist, behindern würde. Das kann zu der Annahme führen, dass eine Gerichtsvereinbarung mit Auslandsbezug somit nicht vereinbart werden kann. Jaeger/ Metzger sind dementsprechend der Auffassung, dass Gerichtsstandvereinbarungen nur bei Kaufleuten unter den Voraussetzungen des § 38 I ZPO wirksam sind. Es ist aber dennoch vorstellbar, dass auch im Bereich Open Source Software eine Gerichtsstandvereinbarung gem. § 38 II ZPO wirksam getroffen werden kann. Hat beispielsweise ein ausländischer Programmierer ohne einen allgemeinen Gerichtstand im Inland eine von ihm programmierte Software als Urheber unter eine Open Source-Lizenz gestellt, hat er selbstverständlich die Möglichkeit, mit einem deutschen Lizenznehmer im Wege einer schriftlichen Vereinbarung oder eines Schriftwechsels einen deutschen Gerichtstand zu vereinbaren. Demnach sind durchaus Fälle denkbar, in denen es auch im Bereich von Open Source Software zu einer Gerichtsstandvereinbarung gem. § 38 I ZPO kommt. Insofern erscheint die Einschätzung bei Jaeger/Metzger als zu pauschal. bb) Rechtsstreitigkeit mit Auslandsbezug Gerade im Bereich von Open Source Software ist aufgrund der möglichen internationalen Bezüge möglich, dass Urheberrechtsstreitigkeiten mit Auslandsberührung auftreten. Aufgrund der besonderen, meist grenzüberschreitenden Entwicklungsweise von Open Source Software ist eine solche Konstellation in der Regel wahrscheinlich. Daher ist die Befassung mit der Frage nach der internationalen Zuständigkeit an dieser Stelle geboten. Zu klären ist hier, wann ein deutsches Gericht in Fällen mit Auslandsbezug entscheidet. Die internationale deutsche Zuständigkeit bestimmt, ob ein deutsches Gericht einen Fall mit Auslandsberührung zur Entscheidung annehmen muss143. Die Möglichkeit der inländischen Prorogation nach den Vorschriften der ZPO ist oben bereits dargelegt worden. (1) Zuständigkeit nach der EuGVO bzw. nach der LugÜ Die internationale deutsche Zuständigkeit richtet sich nur in den seltensten Fällen nach der ZPO. Im Regelfall bestimmt sich die gerichtliche Zuständigkeit in Fällen mit Auslandsberührung nach den Vorschriften der Verordnung über die gerichtliche Zuständigkeit und die Anerkennung und Vollstreckung von Entscheidungen in Zivil- und Handelssachen (EuGVO144) bzw. nach 143

Jaeger/Metzger, S. 87. Die EuGVO [auch als EuGVVO abgekürzt] ersetzt in ihrem Anwendungsbereich das EWG-Übereinkommen über die gerichtliche Zuständigkeit und die Voll144

II. Open Source Software und Anwendbarkeit des UrhG

145

der LugÜ145. Die EuGVO als Ergebnis europäischer Harmonisierungsbestrebungen und das LugÜ gehen als Spezialregelungen deutschem Recht vor146, so dass autonomes deutsches Recht nicht herangezogen werden darf, sollte der Anwendungsbereich der EuGVO und des LugÜ eröffnet sein147. Die Frage, ob ein streitiger Sachverhalt einen derartigen Inlandsbezug aufweist, dass dies die Zuständigkeit eines inländischen beispielsweise deutschen Gerichtes begründet, ist Regelungsgegenstand der EuGVO148. Mit der EuGVO wird die gerichtliche Zuständigkeit zwischen verschiedenen Staaten abgrenzt149. Sie gilt gem. Art. 66, 76 i. V. m. 68 EuGVO für alle Klagen oder Anträge, die nach dem 28.02.2002 bei Gericht eingereicht wurden und ist vom sachlichen Anwendungsbericht her gem. Art. 1 EuGVO auf Zivil- und Handelssachen beschränkt. Die Regelungen der EuGVO sind regelmäßig anwendbar, wenn ein Beklagter einer Streitsache seinen Wohnsitz in einem der Mitgliedsstaaten der EuGVO hat. Der räumlich-persönliche Anwendungsbereich bestimmt sich gem. Art. 2 EuGVO nach dem Wohnsitz des Beklagten. Nicht unter die Zuständigkeitsordnung fällt die Konstellation, dass der Beklagte seinen Wohnsitz außerhalb des mitgliedschaftlichen Hoheitsgebietes wie z. B. in den USA hat. Innerhalb seines Anwendungsbereiches ersetzt die EuGVO das autonome nationale Recht150. Grundsätzlich sind gem. Art 2 I EuGVO Personen, die ihren Wohnsitz im Hoheitsgebiet eines Mitgliedstaates haben ohne Rücksicht auf ihre Staatsangehörigkeit vor den Gerichten in diesem Mitgliedsstaat zu verklagen. Insofern ist auch hier grundsätzlich der allgemeine Gerichtstand des Beklagten maßgeblich151. streckung von gerichtlichen Entscheidungen in Zivil- und Handelssachen (EuGVÜ). Die EuGVO ist am 01.03.2002 In-Kraft-Getreten. Abgedruckt in Jayme/Hausmann, Ordnungs-Nr.: 160; Vgl. dazu auch v. Bar/Mankowski, IPR, Bd. I, § 5 Rn. 6; Schack, Internationales Zivilverfahrensrecht, Rn. 106 a ff. Zur Geltung der EuGVO in Dänemark vgl. v. Bar/Mankowski, IPR, Bd. I, § 5 Rn. 11. Zur Internationalen Zuständigkeit vgl. auch: Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 26 ff.; Dreier/Dreier, Vor §§ 120 ff., Rn. 58 ff. 145 Luganer Übereinkommen über die gerichtliche Zuständigkeit und die Vollstreckung gerichtlicher Entscheidungen in Zivil- und Handelssachen vom 16.09.1988. Das Übereinkommen gilt für bestimmte Länder (EFTA-Staaten – z. B. Norwegen, Schweiz und Island, die mangels EU-Mitgliedschaft dem EuGVÜ nicht beitreten konnten), für die die EuGVO keine Rechtwirkungen entfaltet. Abgedruckt in Jayme/ Hausmann, Ordnungs-Nr. 152; Vgl. dazu auch Piltz, NJW 2002, S. 791; v. Bar/ Mankowski, IPR, Bd. I, § 5 Rn. 13. 146 BGHZ 82, 114 f.; Zöller/Vollkommer, § 38 Rn. 24. 147 EuGH, NJW 1992, S. 1029. 148 Ebd.; vgl. auch: Wandtke/Bullinger/v. Welser, Vor §§ 120 ff. Rn. 26. 149 Ebd. 150 Piltz, NJW 2002, S. 791. 151 Wandtke/Bullinger/v. Wesel, Vor §§ 120 ff. Rn. 29. 10 Teupen

146

§ 5 Open Source Software im deutschen Urheberrecht

(2) Besondere Gerichtsstände Interessanter in Bezug auf urheberrechtliche Rechtsstreitigkeiten im Bereich Open Source Software ist auch im Rahmen des internationalen Verfahrensrechts die Frage nach den besonderen Gerichtsständen. Die besonderen Gerichtsstände sind in Art. 5 und 6 EuGVO geregelt, die sowohl die internationale wie auch die örtliche Zuständigkeit des Gerichts umfassen. Nach diesen Vorschriften wird jedoch nur ein Gerichtstand begründet, wenn die in den Vorschriften enthaltenen Anknüpfungspunkte in dem Gebiet eines Mitgliedsstaates liegen. Soweit ein Vertrag oder Ansprüche daraus Gegenstand des Verfahrens bilden, ist für die Frage der Gerichtszuständigkeit gem. Art. 5 Nr. 1 EuGVO auf den Erfüllungsort abzustellen152. Geht es bei einem urheberrechtlichen Vertrag, also beispielsweise einer Open Source-Lizenz in einem konkreten Fall um Fragen nach der Wirksamkeit, nach dem Inhalt oder nach der Auslegung sowie um Fragen von Vertragsverletzungen153, ist folglich auf den Erfüllungsort abzustellen. Im Rahmen von vertraglichen Ansprüchen ist darüber hinaus die Zuständigkeitsregelung bei Verbrauchersachen gem. Art. 15 ff. EuGVO zu beachten. Unter den dort genannten Voraussetzungen hat der Verbraucher ein Wahlrecht, ob er die Klage gegen einen Vertragspartner vor dem Gericht des Mitgliedstaates erhebt, in dem der Vertragspartner seinen Wohnsitz hat, oder vor dem Gericht des Ortes, an dem der Verbraucher selbst seinen Wohnsitz hat. Hingegen kann gegen den Verbraucher nach diesen verbraucherschützenden Vorschriften regelmäßig nur vor Gerichten des Mitgliedstaates Klage erhoben werden, in dessen Hoheitsgebiet der Verbraucher seinen Wohnsitz hat. Da auch Privatleute als Verbraucher i. S. d. Gesetzes Open Source Software einsetzen, besteht die Möglichkeit, dass ein deutsches Gericht über eine urhebervertragsrechtliche Streitigkeit mit Auslandbezug zu entscheiden hat, sofern beispielsweise der Verbraucher mit einem im Ausland ansässigen Unternehmen einen Lizenzvertrag über Open Source Software abgeschlossen hat. Art. 5 EuGVO regelt in Ziffer 3 den besonderen Gerichtstand der unerlaubten Handlung. Danach kann im Falle einer unerlaubten Handlung der Verletzer, der seinen Wohnsitz im Hoheitsgebiet eines Mitgliedstaates hat in einem anderen Mitgliedsstaat vor dem Gericht des Ortes verklagt werden, an dem der Schädigungserfolg eingetreten ist oder einzutreten droht. Diese Formulierung stellt klar, dass der Gerichtstand bereits eröffnet ist, wenn auch nur eine Rechtsverletzung droht154. Bezogen auf Open Source Soft152

Vgl. auch Schack, Internationales Zivilverfahrensrecht, Rn. 259 ff. Zur Frage der Abgrenzung vertraglicher zu nichtvertraglichen Ansprüchen vgl. Schack, Internationales Zivilverfahrensrecht, Rn. 261 ff. 153

II. Open Source Software und Anwendbarkeit des UrhG

147

ware und damit mögliche Verletzungshandlungen von Urheberrechten bedeutet das, dass ein Verletzer mit Wohnsitz in Frankreich und französischer Nationalität vor einem deutschen Gericht verklagt werden kann, wenn der Erfolg seiner Verletzungshandlung auf deutschem Hoheitsgebiet eingetreten ist oder hier einzutreten droht. Verbreitet er beispielsweise ein Open Source Produkt über das Internet nicht unter der ursprünglichen Open Source-Lizenz sondern als „proprietäre“ Software ohne hierzu berechtigt zu sein und kann die Software in Deutschland heruntergeladen werden, besteht die Möglichkeit, ihn vor einem deutschen Gericht zu verklagen155. Des Weiteren regelt Art. 5 Nr. 4 EuGVO die Konstellation, dass ein Schadensersatzanspruch geltend gemacht oder eine Klage auf Wiederherstellung eingereicht wird. Wird eine derartiges Begehren auf eine mit Strafe bewähre Handlung gestützt, ist nach dieser Verfahrensvorschrift das Strafgericht zuständig, bei dem die öffentliche Klage erhoben worden ist. Die Zuständigkeit erfordert jedoch, dass das Gericht nach seinem Recht über zivilrechtliche Ansprüche erkennen kann. Auch nach dieser besonderen Zuständigkeitsregelung ist ein Zivilprozess, dem eine gem. den §§ 106 ff. StGB strafbewährte Urheberrechtsverletzung zu Grunde liegt, vor einem deutschen Gericht selbst dann möglich, wenn der Verletzer in einem anderen Mitgliedsstaat wohnhaft ist. (3) Gerichtsstandvereinbarung Ferner bieten auch die Vorschriften der EuGVO über das internationale Verfahrensrecht die Möglichkeit, eine Vereinbarung über den Gerichtsstand zu treffen. In Fällen, in denen keine exklusive Zuständigkeit gem. Art. 22 EuGVO besteht und eine Gerichtsstandvereinbarung nicht den Art. 13, 17 und 21 zuwiderläuft (vgl. Art. 23 V EuGVO), besteht für Parteien, von denen mindestens eine ihren Wohnsitz im Hoheitsgebiet eines Mitgliedstaates hat, die Möglichkeit unter den Voraussetzungen des Art. 23 I EuGVO eine auf ein bestimmtes Rechtverhältnis bezogene Gerichtsstandvereinbarung zu treffen. Dabei macht Art. 23 EuGVO grundsätzlich keinen Unterschied zwischen Kaufleuten und Nichtkaufleuten, solange die Regelung des Art. 23 V EuGVO beachtet wird, wonach gewisse Einschränkungen für Versicherungs- und Verbrauchersachen sowie für Arbeitsverträge gelten. Nach der Regelung des Art. 23 EuGVO kann beispielsweise auch ein Rechteinhaber mit Wohnsitz in Frankreich mit seinem Lizenznehmer wohnhaft in Italien die Zuständigkeit eines deutschen Gerichts vereinbaren. Voraussetzung für 154

Schack, Internationales Zivilverfahrensrecht, Rn. 292. Jaeger/Metzger, S. 88; Zu Einzelfragen bzgl. Handlungs- und Erfolgsort sowie Schadensort vgl. Schack, Internationales Zivilverfahrensrecht, Rn. 293 ff. 155

10*

148

§ 5 Open Source Software im deutschen Urheberrecht

die Wirksamkeit einer Vereinbarung gem. § 23 EuGVO ist allerdings, dass sie entweder schriftlich oder mündlich mit schriftlicher Bestätigung geschlossen wird, in einer der zwischen den Parteien entstandenen Gepflogenheiten entsprechenden Form abgefasst wird oder in Fällen des internationalen Handels in einer den Handelsbräuchen entsprechenden Form, soweit diese den Parteien bekannt sind oder sie sie kennen mussten. Dabei besteht gem. Art. 23 II EuGVO die Möglichkeit, die Vereinbarung auf elektronische Weise zu schließen, soweit die elektronische Übermittlung eine dauerhafte Aufzeichnung ermöglicht. Schließlich kann gem. Art. 24 EuGVO die Zuständigkeit eines deutschen Gerichts auch dadurch begründet werden, dass sich ein Beklagter auf ein Verfahren vor diesem Gericht einlässt. cc) Zwischenergebnis Es bestehen somit auch bei Sachverhalten mit Auslandsberührung sowohl nach den Vorschriften der ZPO als auch nach den Regelungen der EuGVO unterschiedliche Möglichkeiten, dass ein deutsches Gericht über urheberrechtliche Streitigkeiten mit Auslandsbezug zu entscheiden hat. dd) Rechtsstreitigkeiten mit Bezug zum amerikanischen Rechtsraum Die Verfahrensvorschriften der EuGVO gelten für das Hoheitsgebiet der EU-Mitgliedsländer. Ein Großteil der Open Source Software stammt derzeit noch aus den USA und wird unter Lizenzen verbreitet, die entsprechend dem amerikanischen Urheberrecht ausgestaltet sind. Es stellt sich die Frage, ob auch hier Fallkonstellationen denkbar sind, die zu einer Zuständigkeit eines deutschen Gerichts führen. Auch in diesem Zusammenhang gelten im Wesentlichen die oben genannten Möglichkeiten der ZPO, die zu der Zuständigkeit eines deutschen Gerichts führen können. Schließt beispielsweise ein in USA ansässiges Unternehmen mit einem in Deutschland ansässigen Unternehmen einen amerikanischen Lizenzvertrag über die Nutzung von Open Source Software kann die Zuständigkeit eines deutschen Gerichts gem. § 38 II ZPO vereinbart werden. Auch in diesen Fallkonstellationen kann somit eine Gerichtsstandvereinbarung dazu führen, dass sich ein deutsches Gericht mit ausländischen Lizenzverträgen befassen muss. Bei Verletzungen von Urheberrechten auf deutschem Hoheitsgebiet richtet sich die Zuständigkeit auch in Fällen, in denen die man die Rechte eines Urhebers mit Wohnsitz in den USA verletzt, nach § 32 ZPO (Art. 5 EuGVO für Fälle, in denen eine Rechtsverletzung in einem EU-Mitgliedsstaat stattfin-

II. Open Source Software und Anwendbarkeit des UrhG

149

det). Auch hier ist wieder auf den Ort abzustellen, an dem die streitige Verwertungshandlung vorgenommen wurde156. ee) Fazit Abschließend lässt sich somit festhalten, dass im Bereich Open Source Software zahlreiche Fallkonstellationen denkbar sind, in denen ein deutsches Gericht in Streitfragen mit Auslandsbezug zuständig sein kann. Fragen des internationalen Privat- und Urheberrechts sind zukünftig wohl in erster Linie in Rechtsstreitigkeiten zu erwarten, die den Einsatz und die damit verbundene „Funktionssnotwendigkeit“ und Zuverlässigkeit von Open Source Software im Unternehmensbereich zum Gegenstand haben. b) Anerkennung ausländischer Urteile Da Open Source ein globales Phänomen ist, ist damit zu rechnen, dass sich im Laufe der Zeit und bei zunehmendem Einsatz von Open Source Software auch ausländische Gerichte mit Rechtsfragen von Open Source Software zu befassen haben. Es stellt sich die Frage, ob auch Gerichtsentscheidungen aus dem Ausland auf deutschem Hoheitsgebiet Rechtswirkungen entfalten. Ausländische Gerichtsentscheidungen haben grundsätzlich in Deutschland keinerlei Bedeutung, da sie als Hoheitsakte nicht über die Grenzen des Urteilstaates hinweg wirken können157. Ein Staat hat jedoch die Möglichkeit, Urteile und Gerichtsentscheidungen ausländischer Staaten anzuerkennen und ihnen somit zu einer Rechtswirkung zu verhelfen158. Eine völkerrechtliche Pflicht hierzu besteht allerdings nicht. Durch eine Anerkennung von ausländischen Gerichtsentscheidungen greift ein Staat zudem nicht in die ausländische Gerichtsgewalt ein159. Es bleibt mithin ihm selbst überlassen, dies zu tun. Deutschland hat sich im Wege von Staatsverträgen, als auch in multiund bilateralen Verträgen dafür entschieden, ausländische Gerichtsurteile unter bestimmten Voraussetzungen anzuerkennen. Der Gesetzgeber hat mit den §§ 328, 722 f. ZPO allgemeine Regelungen für ein nationales Anerkennungsrecht in die ZPO eingeführt. Für den Bereich der EuGVO regelt Art. 33 EuGVO die Frage nach der Anerkennung. Grundsätzlich anerkennungsfähig sind ausländische Entscheidungen die einen Rechtstreit im Wege eines „justizförmigen“ Verfahrens beendet ha156 157 158 159

Spindler, in: Spindler, Absch. C Rn. 150. Schack, Internationales Zivilverfahrensrecht, Rn. 775. Ebd. BGHZ 112, 127, 133.

150

§ 5 Open Source Software im deutschen Urheberrecht

ben160. Entscheidend dabei ist, dass es sich um eine Entscheidung eines staatlichen Gerichts handelt161, die nach dem Verfahrensrecht des jeweiligen Fremdstaates rechtskräftig geworden ist162. Die Anerkennung bezieht sich lediglich auf Zivil- und Handelssachen163, worunter das Urheberrecht zu subsumieren ist. Ausgeschlossen von der Anerkennung sind Zwischenentscheidungen eines Gerichts mit innerprozessualer Bedeutung, notarielle Urkunden sowie Prozessvergleiche164. § 328 ZPO regelt explizit, unter welchen Voraussetzungen die Anerkennung eines ausländischen Urteils im Einzelfall ausgeschlossen ist. Eine Anerkennung ist beispielsweise gem. § 328 Nr. 4 ZPO ausgeschlossen, wenn gegen verfahrensrechtliche Grundsätze verstoßen wurde und die Entscheidung mit den Grundprinzipien des deutschen Rechts und der damit zusammenhängenden objektiven Werteordnung nicht vereinbar wäre oder es in Bezug auf den Fremdstaat an der Verbürgung der Gegenseitigkeit fehlt. In verfahrensrechtlicher Hinsicht gilt, dass die ausländischen Entscheidungen im deutschen Recht grundsätzlich automatisch anerkennt werden, ohne dass hierfür ein formelles gerichtliches Anerkennungsverfahren erforderlich wäre165. Das führt dazu, dass die Urteilswirkungen im selben Zeitpunkt wie im Anerkennungsstaat eintreten, soweit das Urteil eines ausländischen Gerichts die Anerkennungsvoraussetzungen erfüllt166. Die Parteien haben aber die Möglichkeit, im Anerkennungsstaat im Wege der Feststellungsklage auf Feststellung klagen, ob die ausländische Entscheidung anzuerkennen oder nicht anzuerkennen ist167. Sie sind einer Anerkennung somit nicht rechtlich schutzlos ausgesetzt. Es gilt daher die Rechtsprechung zu Open Source Software auch im Ausland zu verfolgen. In einem Rechtsstreit vor einem deutschen Gericht ist eine genaue Prüfung der Rechtslage in Bezug auf eine Anerkennung ausländischer Urteile geboten. Je nach Rechtslage bleibt die Möglichkeit einer Feststellungsklage, um mögliche nachteilige Rechtswirkungen für den eigenen Rechtsstreit zu vermeiden.

160 161 162 163 164 165 166 167

Schack, Internationales Zivilverfahrensrecht, Rn. 810; RGZ 16, 427 f. Schack, Internationales Zivilverfahrensrecht, Rn. 813. BGHZ 141, 286, 294. Schack, Internationales Zivilverfahrensrecht, Rn. 817. Schack, Internationales Zivilverfahrensrecht, Rn. 811, 816. Schack, Internationales Zivilverfahrensrecht, Rn. 879. So auch Schack, Internationales Zivilverfahrensrecht, Rn. 880. Schack, Internationales Zivilverfahrensrecht, Rn. 885.

III. Urheberschaft bei Open Source Software

151

III. Urheberschaft bei Open Source Software Bevor im Besonderen auf die Inhalte und Rechtswirkungen der Open Source-Lizenzen und damit auf die Frage nach der Einräumung von Nutzungsrechten eingegangen wird, ist zunächst die Frage nach der Urheberschaft an Open Source Software zu klären. Wer ist im Einzelfall überhaupt zur Einräumung der Rechte berechtigt? „Proprietäre“ Software wird regelmäßig von einem Einzelprogrammierer oder von einer Gruppe von Programmierern programmiert, die durch Arbeitsvertrag an einen Arbeitgeber gebunden sind oder als freie Mitarbeiter in den Entwicklungsprozess eingebunden sind. Schiffner hält die Open Source Software Entwicklungsweise grundsätzlich für divergent mit der der „proprietären“ Software168. Für ihn ist der Entwicklungsprozess von Open Source Software regelmäßig dezentral und erfolgt durch eine ungebundene Entwicklungsgemeinschaft169. Das erscheint allerdings als zu pauschal. Es gibt Open Source Projekte, die hinsichtlich der Entwicklungsweise und Zusammenarbeit der beteiligten Programmierer nicht von „proprietärer“ Software divergieren170. Open Source Software unterscheidet sich erst im Zeitpunkt der Lizenzierung, d. h. der Entscheidung der Urheber für eine bestimmte Open Source-Lizenz von „proprietärer“ Software. Zugestandenermaßen ist eine offene Entwicklungsweise bei „proprietären“ Computerprogrammen aufgrund der rechtlichen Probleme die damit einhergehen würden, nicht vorstellbar. Die Entwicklungsweise allein ist aber nicht der entscheidende Unterschied. Verwiesen wird in diesem Zusammenhang richtigerweise auf Projekte wie den Netscape Browser oder auch Star Office, die erst nach der Fertigstellung als Freie Software lizenziert wurden, aber in einer herkömmlichen Entwicklungsumgebung geschaffen wurden171. Zuzustimmen ist Schiffner aber insofern, als die Vielzahl von Freien Programmen durch eine offene Entwicklungsgemeinschaft geschaffen wird. Diese breite Zusammenarbeit und Beteiligung unabhängiger Programmierer wird gerade als ein Qualitätsmerkmal der Freien Computerprogramme gesehen. Die an den meisten Open Source Software Projekten mitarbeitenden Programmierer sind weder durch Anstellungsverträge noch durch sonstige rechtliche Vereinbarungen miteinander verbunden172. Sie können in ganz unterschiedlichen Entwicklungs- und Weiterentwicklungsphasen eines Open Source Projekts beteiligt sein173. So ist es möglich, dass mehrere Entwick168 169 170 171 172

Schiffner, S. 117. Ebd. So auch Marly, Rn. 413; Jaeger/Metzger, S. 26. Jaeger/Metzger, S. 26, Fn. 101. Koch, CR 2000, S. 276.

152

§ 5 Open Source Software im deutschen Urheberrecht

ler aufgrund eines gemeinsamen Konzeptes ein Projekt vollständig zusammen programmieren. Ferner besteht die Möglichkeit, dass während einer Projektentwicklung die beteiligten Programmierer in den verschiedenen Entwicklungsphasen wechseln. Den meisten Open Source Software Projekten ist gemeinsam, dass ein bereits erstelltes Projekt, d. h. eine fertige Software von einzelnen Programmierern oder Programmiergruppen weiterentwickelt wird, die oft nur einzelne Teile eines Programms programmieren oder neue Funktionen in ein bestehendes Programm einfügen oder auch nur unwesentliche Weiterentwicklungen vornehmen. Bei diesen Entwicklungsprozessen ist es häufig der Fall, dass die Beteiligten in keinerlei Beziehung zueinander stehen und oft nicht einmal unmittelbaren Kontakt zueinander haben174. Fraglich ist in diesem Fallkonstellationen der offenen und ungebundenen Entwicklungsgemeinschaften, wer Urheber ist und ob die Arbeitsergebnisse im Einzelfall und der Schutz des § 69 a UrhG fallen. Darüber hinaus ist die Entwicklung von Open Source Software wie bereits erwähnt nicht „grenzgebunden“. Vielmehr findet in vielen Fällen eine Entwicklungszusammenarbeit zwischen Programmierern statt, die ihren Wohnsitz in verschiedenen Ländern haben. Aufgrund der freien Verfügbarkeit des Quellcodes und der Internetkommunikation sind gerade an Open Source Projekten oftmals Entwickler aus dem europäischen wie nicht-europäischem Ausland beteiligt. In diesen Fällen gilt es zudem zu klären, ob ihre Beiträge unter den Schutz des UrhG fallen175. Der Frage nach der Urheberschaft und dem Schutz von Arbeitsergebnissen kommt also im Bereich von Open Source Software eine besondere Rolle zu. 1. Einzelurheberschaft bei Open Source Software a) Urheber gem. § 7 UrhG Entwickelt jemand alleine ein Computerprogramm, das unter den Schutz des § 69 a UrhG fällt, ist er gem. § 7 Urheber des Computerprogramms. In diesem Fall sind die Urheberpersönlichkeitsrechte und die Ausschließlichkeitsrechte in einer einzelnen Person verbunden. Es liegt in seinem alleinigen Entscheidungsbereich, das Programm als Open Source Software zu lizenzieren. 173

Schiffner, S. 146. Jaeger/Metzger, S. 26, Fn. 101. 175 Die Frage nach der Anwendbarkeit des UrhG sowie nach dem persönlichen Anwendungsbereich des UrhG bei Sachverhalten mit Auslandsberührung wurde bereits ausführlich diskutiert. 174

III. Urheberschaft bei Open Source Software

153

b) Bearbeitung durch den Einzelurheber In den häufigeren Fällen nutzt ein Anwender eines Open Source-Computerprogramms die Lizenzrechte dazu, das Programm zu verändern. Verändert ein Einzelprogrammierer ein bereits bestehendes Open Source-Computerprogramm im Rahmen der lizenzrechtlichen Befugnis, kann eine Bearbeitung gem. §§ 3, 23, 69 c Nr. 2 UrhG vorliegen, die als selbstständiges Werk gem. § 3 S. 1 UrhG selbständigen Schutz erfährt176. Es entsteht ein eigenständiges gegenüber jedermann durchsetzbares Urheberrecht177. Das Programmierergebnis muss allerdings gem. § 3 UrhG eine individuelle geistige Schöpfung darstellen und das Ausgangswerk noch erkennen lassen178. Diese an der Ausgangssoftware vom Programmierer vorgenommenen Umarbeitungen werden dann wie ein selbstständiges Werk geschützt179. aa) Entstehen eines Bearbeiterurheberrechts Folge einer Bearbeitung ist die Entstehung zweier selbstständiger Rechte, nämlich das Urheberrecht am Originalwerk und das Urheberrecht an der Bearbeitung180. Der Programmierer erhält also ein eigenes Bearbeiterurheberrecht181, das allerdings immer im rechtlichen Zusammenhang mit dem Ursprungswerk zu sehen ist182. Das Bearbeiterurheberrecht ist ein vom Ursprungswerk abhängiges Urheberrecht, d. h. dass der Bearbeiter zur Verwertung des bearbeiteten Werkes die Zustimmung des Urhebers des Originalwerkes gebraucht183. Ein Dritter, der das überarbeitete Werk wiederum bearbeiten möchte, braucht die Zustimmung des Urhebers des Originalwerkes sowie die Zustimmung des Erstbearbeiters184. Die Frage nach der Einwilligung bei Bearbeiterketten ist in Fällen von Bearbeitungen an Open Source Software regelmäßig unproblematisch, da der Urheber des Originalwerkes mit Verwendung einer Open Source-Lizenz eine Bearbeitung seines Werkes gem. § 23 UrhG erlaubt und auch der Erstbearbeiter sich mit Vornahme der Bearbeitung regelmäßig verpflichtet, seine Bearbeitung wieder 176

Schiffner, S. 146; Schricker/Loewenheim, § 3 Rn. 22; Lehmann/Haberstrumpf, S. 145. 177 BGHZ 15, 347. 178 Dreier/Schulze, § 3 Rn. 7. 179 Marly, Rn. 417. 180 Dreier/Schulze, § 3 Rn. 50. 181 Schiffner, S. 146; Spindler, in: Spindler, Abschn. C Rn. 15; Koch, § 9 Rn. 449. 182 Schricker/Loewenheim, § 3 Rn. 34 ff. 183 Schricker/Loewenheim, § 3 Rn. 35. 184 Schricker/Loewenheim, § 3 Rn. 35; Spindler, in: Spindler, Abschn. C Rn. 15.

154

§ 5 Open Source Software im deutschen Urheberrecht

unter die Open Source-Lizenz des Ursprungwerkes zu stellen185. Bei Open Source Software kommt es während der Entwicklung zu ganzen Bearbeitungsketten. (1) Verhältnis des Urhebers des Originalwerkes zu dem Urheber der Bearbeitung Fraglich ist, wie das Verhältnis des Urhebers des Originalwerkes zu den Urhebern der Bearbeitungen ausgestaltet ist. Dies ist im Bereich Open Source Software umstritten. § 3 UrhG enthält hierzu keine ausdrückliche Regelung. (a) BGB-Gesellschaft Eine Ansicht führt Gründe für eine BGB-Gesellschaft als Rechtsverhältnis auf, unter das alle Beziehungen im urheberrechtlichen Zusammenhang zu fassen sein können186. Seiner Ansicht nach liegt der gemeinsame Zweck der BGB-Gesellschaft in der ständigen Verbesserung und Verbreitung von Open Source Software187 was dann auch dazu führt, dass zwischen den Bearbeitern eine BGB-Gesellschaft besteht188. Einer BGB-Gesellschaft liegt regelmäßig ein Gesellschaftsvertrag zugrunde in dem sich gem. der Begriffsbestimmung des § 705 BGB mehrere Personen gegenseitig verpflichten, einen gemeinsamen Zweck durch gegenseitige Förderungsbeiträge zu erreichen189. Die Verpflichtung zur Vornahme der Förderungsbeiträge ist damit auch wesentlicher Inhalt des Gesellschaftsvertrages190. Der Gesellschaftszweck kann jeder Zweck sein, sofern mit ihm eine Förderung durch vermögenswerte Leistung verbunden ist191. (b) Stellungnahme Zweifelhaft erscheint, ob sich zwischen den Bearbeitern untereinander und ihrer Beziehung zum Urheber des Originalwerkes ein derartiger Gesellschaftszweck konstruieren lässt. Würde man dieser Auffassung folgen, würden Verbreitung und Verbesserung der Open Source Software den Gesell185 186 187 188 189 190 191

Schiffner, S. 146. Sester, CR 2000, S. 801. Ebd. Gleiche Interpretation: Spindler, in: Spindler, Abschn. C Rn. 16. Saenger, in: HK-BGB, § 705 Rn. 2. Saenger, in: HK-BGB, § 705 Rn. 2. BGHZ 135, 387, 389.

III. Urheberschaft bei Open Source Software

155

schaftszweck darstellen auf dessen Hinblick die Gesellschafter ihre Förderungsbeiträge vorzunehmen hätten. Gemeinsam kann aber nur ein Gesellschaftszweck der BGB-Gesellschaft sein, wenn die Gesamthand von jedem Gesellschafter auch die Vornahme des Förderbeitrages verlangen kann192. Open Source Software Lizenzen basieren aber grundsätzlich auf der Freiheit, dass ein Nutzer weder eine Verbesserung in Form einer Bearbeitung vorzunehmen hat, noch die Verbreitung aktiv betreiben müsste. Er kann die Nutzungsrechte aus der Open Source-Lizenz nutzen, es besteht aber keine Verpflichtung für ihn. Viele Nutzer wären schon aufgrund mangelnder Programmierkompetenz nicht in der Lage, eine eigenständige Bearbeitung vorzunehmen, d. h. von ihnen würde etwas verlangt, was sie nicht erfüllen könnten. Allenfalls kann es eine beispielsweise in der GPL formulierte (§§ 1, 2 GPL) Verpflichtung geben, die Programmverbreitungen oder Programmveränderungen wiederum unter die Open Source-Lizenz des Ausgangsprogramms zu stellen. Aber auch hierin kann man nicht wirklich einen Gesellschaftszweck sehen193 da eine Förderungspflicht dahingehen schon gar nicht durch Mitgesellschafter einklagbar wäre. Vielmehr soll (z. B.) nach der GPL derjenige, der Programmänderungen nicht ebenfalls unter die Open Source-Lizenz stellt, die Nutzungsrechte rückwirkend verlieren (GPL Ziff. 4). Durch die vielen Änderung-, Verbesserungs- und Anpassungsprogrammierungen die an einer Open Source Software in der Regel vorgenommen werden, ist es schon schwierig den Gesellschaftszweck auf eine bestimmte Software festzulegen, da sie laufend Änderungen unterworfen ist und die bearbeitete Software urheberrechtlich eigenständig von der Originalsoftware ist194. Es erscheint daher wenig überzeugend hier von einer BGB-Gesellschaft auszugehen, da es einerseits an einem eindeutigen Gesellschaftszweck fehlt und auch keine Pflichtbeiträge der Beteiligten ersichtlich sind195. (c) Entwicklergemeinschaft Jaeger/Metzger lehnen ebenfalls eine BGB-Gesellschaft ab und sehen jeden Programmierer, der ein Open Source-Computerprogramm bearbeitet als „Teil einer Entwicklergesellschaft mit dem Ziel einer gemeinsamen Verbreitung und Fortentwicklung der Software“196. Vom Gedanken einer bestehenden Gesellschaft ausgehend wenden sie § 8 II S. 3 UrhG in diesen Fallkonstellationen entsprechend an. Dies hätte dann zur Folge, dass Rechtsverlet192 193 194 195 196

BGH WM 65, 795. So auch Spindler, in: Spindler, Abschn. C Rn. 16. So auch Spindler, in: Spindler, Abschn. C Rn. 16. Vgl. auch Jaeger/Metzger, S. 29; Spindler, in: Spindler, Abschn. C Rn. 16. Jaeger/Metzger, S. 29.

156

§ 5 Open Source Software im deutschen Urheberrecht

zungen und Lizenzverletzungen auch von einem Bearbeiter im Namen aller anderen Entwickler verfolgt werden können197. (2) Stellungnahme Auch gegen diese Lösung sind die oben genannten Kritikpunkte anzuführen198. Die Annahme einer Gesellschaft erscheint nicht überzeugend. Zudem erfordert eine analoge Anwendung einer Vorschrift zunächst eine planwidrige Regelungslücke. Diese besteht hier aber nicht. Rechtsfolge einer Bearbeitung ist das Entstehen des Bearbeiterurheberrechts mit den daraus folgenden oben genannten Rechtspositionen. Der Gesetzgeber hat keine dem § 8 II S. 3 UrhG entsprechende Regelung in § 3 UrhG aufgenommen. Es besteht auch gar keine Notwendigkeit für die Annahme einer BGB-Gesellschaft oder eine analoge Anwendung des § 8 II S. 3 UrhG. Auch im Bereich Open Source Software, wo es im Hinblick auf § 3 UrhG zu langen unüberschaubaren Bearbeiterketten kommen kann, bleibt es bei Rechtsfolgen wie sie sich aus §§ 3, 23 UrhG ergeben. Es bestehen zweiseitige Rechtsgeschäfte zwischen den jeweiligen Bearbeitern und dem Urheber des Ursprungswerkes, sowie zwischen den Bearbeitern selbst199. Bei Rechtsverletzungen oder bei Lizenzverstößen ist bezogen auf die Frage der Aktivlegitimation genau danach zu differenzieren, ob die Verletzungshandlung am Originalwerk oder einer Bearbeitungsversion des Computerprogramms vorgenommen wurde. Bei Verletzungshandlungen am Originalwerk ist dessen Urheber aktivlegitimiert. Betrifft die Verletzungshandlung eine bestimmte Bearbeitungsversion, so ist der Inhaber des Bearbeiterurheberrechts aktivlegitimiert. Um den jeweiligen Rechteinhaber bestimmten zu können, ist eine vollständige Dokumentation der Programmentwicklung und der beteiligten Entwickler und ihrer jeweiligen Beiträge unerlässlich. In programmtechnischer Hinsicht ist die Bearbeitung gem. § 3 UrhG gerade im Bereich Open Source Software von der Schaffung eines selbstständigen Werkes zu unterscheiden, das unabhängig von einem anderen Werk geschaffen wurde und lediglich mit ihm zu einer Werkverbindung gem. § 9 UrhG zusammengefügt wird. Eine Werkverbindung setzt die Schaffung eines einheitlichen Werkes voraus, bei dem jedoch die Selbstständigkeit der Einzelwerke bestehen bleibt200. Hinzu kommt, dass die Werkverbindung nicht zur Aufhebung der gesonderten Verwertbarkeit führen darf201. Bei 197 198 199 200 201

Jaeger/Metzger, S. 29. Vgl. § 5 III. 1. (b). Spindler, in: Spindler, Abschn. C Rn. 16. Schricker/Loewenheim, § 9 Rn. 1. Schricker/Loewenheim, § 9 Rn. 4; Möhring/Nicolini/Ahlberg, § 8 Rn. 10.

III. Urheberschaft bei Open Source Software

157

Software ist hier danach zu differenzieren, ob die einzelnen Softwareelemente für sich genommen lauffähig sind und eine eigene geistige Schöpfung darstellen, die die Schutzanforderungen der §§ 69 a UrhG erfüllen202. Ist ein Programmmodul lediglich eine Verbesserung oder Veränderung eines bestehenden Computerprogramms, ohne für sich selbst genommen lauffähig zu sein, kommt die Einordnung als Bearbeitung i. S. d. § 3 UrhG in Betracht, wohingegen ein Programmelement was als solches selbständig lauffähig ist für den Fall einer Verknüpfung mit einem anderen Computerprogramm eher als Werkverbindung gem. § 9 UrhG einzuordnen wäre. bb) Fazit Die Einzelurheberschaft kann bei Schaffung einer eigenständig programmierten schutzfähigen Software, wie auch im Fall einer Bearbeitung i. S. d. § 3 UrhG vorliegen. Im Bereich Open Source Software ist die Einzelurheberschaft gerade in Bezug auf § 3 UrhG gar nicht so selten, wie man zunächst vermuten würde. Ein Großteil von Veränderungen und Anpassungen werden von Einzelprogrammierern vorgenommen. Bei Bearbeitungen ist zwischen dem Originalwerk und der schutzfähigen Bearbeitung genau zu differenzieren. Für die Geltendmachung von Ansprüchen ist hinsichtlich der Frage der Aktiv- bzw. Passivlegitimation festzustellen, wer Urheber des Originalwerkes und Urheber der Bearbeitung ist. Fehlt eine Dokumentation, kann es im Einzelfall unmöglich sein, den jeweiligen Urheber zu bestimmen. Das führt dazu, dass eine Geltendmachung von Ansprüchen aufgrund einer nicht nachzuweisenden materiellen Berechtigung oder Verpflichtung nicht möglich ist. 2. Entwicklungsgemeinschaften von Open Source Software Die „Zusammenarbeit“ bei der Erstellung von Open Source Software kann gleichzeitig zwischen mehreren Beteiligten erfolgen, d. h. mehrere Programmierer schaffen ein Computerprogramm durch Verknüpfung ihrer Einzelbeiträge. Derartige Gemeinschaften von Programmierern können zum einen als Miturheber gem. § 8 UrhG verbunden sein, zum anderen kann bezogen auf die Zusammenfügung einzelner Programmierergebnisse eine Werkverbindung gem. § 9 UrhG vorliegen. Im Bereich der Open Source Software ergeben sich gerade im Bereich von Entwicklungsgemeinschaften auch Besonderheiten für die Verfügungsund Klagebefugnisse. 202

So auch Spindler, in: Spindler, Abschn. C Rn. 13.

158

§ 5 Open Source Software im deutschen Urheberrecht

a) Miturheberschaft an Open Source Software Wie „proprietäre“ Software so kann auch Open Source Software das Ergebnis gemeinschaftlichen Zusammenwirkens mehrerer Programmierer sein. Erfolgt die Zusammenarbeit derart, dass sich die Beteiligten auf ein gemeinsames Ziel verständigt haben und ihre Beiträge unter die Gesamtidee unterordnen, liegt eine Miturheberschaft i. S. d. § 8 UrhG vor, solange sich die Programmierergebnisse des Einzelnen nicht gesondert verwerten lassen. Die Einzelbeiträge sind technisch daraufhin zu untersuchen, ob die Einzelbeiträge der mitwirkenden Programmierer nicht für sich genommen voll lauffähig sind und sich somit zu gesonderter Verwertung eignen. An dieser Stelle ist die Abgrenzung zur Werkverbindung i. S. d. § 9 UrhG vorzunehmen. Bei Computerprogrammen ist anerkannt, dass die Einzelbeiträge in unterschiedlichen Entwicklungsstadien der Software geleistet werden können, also im Wege einer vertikalen Arbeitsteilung203. Die Programmierer können somit nacheinander tätig werden und die nachgelagerten Beteiligungsbeiträge können auch auf den Vorarbeiten anderer aufbauen204. Im Bereich Open Source Software ist aber im Hinblick auf § 8 I UrhG fraglich, ob man hinsichtlich der oft großen Anzahl von beteiligten Programmierern, die ja oft nicht gleichzeitig an dem Programm arbeiten, überhaupt von einer gewollten schöpferischen Zusammenarbeit sprechen kann. aa) Gemeinsame Gesamtidee Grundsätzlich gibt es bei Miturheberschaft keine gesetzliche Beschränkung der Miturheberanzahl. Es muss allerdings eine gemeinsame Gesamtidee, bezogen auf Computerprogramme könnte man von einem gemeinsamen Programmierziel sprechen, unter den Programmierern herrschen. Die eigene Arbeit des Einzelprogrammierers, sein Teilbeitrag zum Gesamtwerk, muss im Blick auf das gemeinsame Schaffen erfolgen. Der Gesamtidee können sich die Open Source-Programmierer, die oft über gar keinen direkten Kontakt zueinander verfügen, derart unterstellen, dass sie sich zu Beginn des Projektes über das zu erreichende Ziel abstimmen. Diese Abstimmung kann in direktem Kontakt, per Fernkommunikationsmittel oder auch im Wege von Forenbeiträgen vorgenommen werden. Es gilt dabei, sich über das Ziel der Programmierung zu einigen, die eigene Bereitschaft Bei203 BGH GRUR 1994, 39 f.; Wandtke/Bullinger/Thum, § 8 Rn. 17; Dreier/ Schulze, § 8 Rn. 3; Loewenheim/Loewenheim, § 11 Rn. 2; Dreyer, in: HK-UrhR, § 8 Rn. 5. 204 So auch Lehmann/Haberstrumpf, S. 126.

III. Urheberschaft bei Open Source Software

159

träge zu leisten kundzutun sowie die Einzelbeiträge aufeinander abzustimmen205. Auch bei einer Vielzahl von Beteiligten Programmierer ist eine solche Abstimmung grundsätzlich möglich. Im Bereich Open Source Software findet oft die Koordination eines Projektes in Foren oder auf speziell dafür eingerichteten Internetseiten statt. Auch ein Wechsel der Programmierer während eines Projektes steht der Annahme einer Miturheberschaft prinzipiell nicht entgegen, da sich auch neue Programmierer nach Beginn der Erstellung der Gesamtkonzeption unterordnen können und in Abstimmung mit den anderen Beteiligten ihre Beiträge leisten können206. Der in den Entwicklungsprozess eintretende Programmierer muss natürlich einen Einfluss bei der weiteren Abstimmung der Softwareentwicklung haben, d. h. eine reine Gehilfentätigkeit reicht für die Miturheberschaft nicht aus. Rechtsfolge der Miturheberschaft gem. § 8 I UrhG ist das Entstehen einer Gesamthandsgemeinschaft (§ 8 II S. 1 UrhG) auf die die Regeln der BGBGesellschaft entsprechend Anwendung finden. Dabei sind zunächst auch hier die urheberrechtlichen Besonderheiten zu beachten, durch die die §§ 705 ff. BGB modifiziert werden. Einem Miturheber eines Open SourceComputerprogramms steht danach kein Kündigungsrecht gem. § 723 BGB zu, da dies durch die urheberrechtliche Schutzdauer eines Werkes von 70 Jahren ausgeschlossen ist207. Die Programmierer eines Open Source-Computerprogramms verwalten das am Computerprogramm bestehende Urheberrecht gemeinsam. Entscheidungen über die Ausübung positiver Benutzungsrechte wie Veröffentlichung, Verwertung oder Veränderungen erfordern gem. § 8 II S. 1 UrhG und dem Rechtsgedanken des § 709 BGB folgend den einstimmigen Beschluss aller Miturheber208. Abweichende Vereinbarung können in diesem Zusammenhang zwar erfolgen, bedürfen aber einer ausdrücklichen Regelung im Gesellschaftsvertrag. Handelt es sich um ein Open Source Projekt, bei dem die Anzahl der Miturheber unüberschaubar ist, erscheint es in der Praxis nahezu unmöglich, nach Fertigstellung des Werkes gemeinsame Entscheidungen unter den Miturhebern zu treffen. Oft dürfte es gar nicht möglich sein, die Zustimmung eines jeden Miturhebers einzuholen, da nicht unbedingt jeder Urheber namentlich bekannt ist209. Das könnte dafür sprechen, dass die Regelungen der gemeinschaftlichen Verwaltung einer BGB-Gesellschaft gar nicht auf die Entwicklungsgemeinschaft der Open Source Miturheber anwendbar sind. So wird auch teilweise 205

Lehmann/Haberstrumpf, S. 126. Zum Wechsel von Miturhebern während des Schaffensprozesses vgl. auch Lehmann/Haberstrumpf, S. 126; Schiffner, S. 119. 207 Wandtke/Bullinger/Thum, § 8 Rn. 51. 208 Möhring/Nicolini/Ahlberg, § 8 Rn. 34; Spindler, in: Spindler, Abschn. C Rn. 18. 209 So auch Spindler, in: Spindler, Abschn. C Rn. 19. 206

160

§ 5 Open Source Software im deutschen Urheberrecht

zur Vorsicht geraten, wenn es beispielsweise um den Erwerb von Nutzungsrechten an einer Open Source Software geht210. Diese Bedenken sind jedoch gerade im Fall der Miturheberschaft an einem Open Source-Computerprogramm nicht berechtigt. Bei „proprietärer“ Software ist die Lizenzierungsfrage von untergeordneter Bedeutung. Es ist Ziel, ein erfolgreiches Produkt zu schaffen, das sich aufgrund hoher Nachfrage und des Urheberschutzes profitabel vermarkten lässt. Details der lizenzrechtlichen Ausgestaltung stehen hier meistens am Ende des Entwicklungsprozesses. Bei Open Source Software hingegen kommt der Lizenzierungsfrage neben dem Entwicklungsziel eine entscheidende Bedeutung zu. Ein Open Source Projekt wird gerade mit dem Ziel gestartet, eine Software unter eine entsprechende Lizenz zu stellen und sie als freie Software zu veröffentlichen und zu verbreiten211. Der Zeitpunkt von Entscheidungen bezüglich der Verwertungsfrage liegt somit gleich am Anfang des Projektes, sozusagen vor Aufnahme der Programmiertätigkeiten. Für viele Programmierer ist die Lizenzfrage ein zentraler Motivationsaspekt, um eigene Programmierbeiträge mit Blick auf das Ziel vorzunehmen. Da die Open Source-Lizenzen regelmäßig die wesentlichen Verwertungsfragen bezüglich der Software enthalten, besteht mit der Veröffentlichung des Werkes auch keine Notwendigkeit mehr, Entscheidungen hierzu zu treffen. Die gemeinsame Verwaltungsentscheidung bzgl. der Verwertung ist bereits mit Aufnahme des Projektes einstimmig dadurch ergangen, dass die Verwertungsfrage Inhalt der Gesamtidee ist, der sich die Programmierer bei Eintritt in das Projekt unterstellen. Auch die gemeinschaftliche Entscheidung über den Zeitpunkt der Veröffentlichung dürfte bei Open Source Projekten direkt zu Anfang getroffen werden. Klar ist regelmäßig, dass eine Veröffentlichung dann erfolgt, wenn eine lauffähige Version vorliegt, die dann auch zur weiteren Bearbeitung an eine breite Open Source Gemeinde weitergegeben werden kann. Der einzelne Miturheber willigt mit seinem „Beitritt“ in die Entwicklungsgemeinschaft in die gemeinsamen Entscheidungen über die in § 8 II S. 1 UrhG aufgeführten Punkte ein. Die Vorfestlegung auf die Verwaltungsentscheidungen i. S. d. § 8 II S. 1 UrhG im Rahmen der Gesamtidee erübrigt nachträgliche, aufgrund einer möglichen hohen Miturheberdichte komplizierte oder unmögliche Entscheidungsprozesse. bb) Aktivlegitimation Problematisch im Fall der Miturheberschaft bei Open Source-Computerprogrammen ist allerdings die Frage der Aktivlegitimation i. S. d. § 8 II S. 3 210 211

Plaß, GRUR 2002, S. 672. Vgl. auch Jaeger/Metzger, S. 27.

III. Urheberschaft bei Open Source Software

161

UrhG212. In Fällen von Urheberrechtsverletzungen kann zwar der einzelne Miturheber gem. § 8 II S. 3 UrhG die Ansprüche aus der Verletzung des gemeinsamen Urheberrechts alleine geltend machen, er kann aber nur die Leistung an alle Miturheber verlangen213. Hierin liegt ein Fall der gesetzlichen Prozessstandschaft214. Bei Unterlassungs- sowie Beseitigungsansprüchen kann der einzelne Miturheber aktiv werden, ohne dass er die Leistung an alle verlangen muss215. Sobald er also auf Leistung (z. B. Schadensersatz infolge einer Urheberrechtsverletzung) klagt, muss er auf Leistung an alle Miturheber klagen216, wozu die namentliche Nennung aller Miturheber notwendig ist217. Die Parteien in einem Prozess müssen individuell bestimmt sein. Es besteht keine Möglichkeit eine Klage gegen „unbekannt“ oder „wen es angeht“ erfolgreich anzustrengen218. Die Nennung aller Miturheber erscheint jedoch bei Projekten mit einer hohen Anzahl von Miturhebern, die sich dezentral an der Entwicklung beteiligen, nicht möglich, da es regelmäßig an einer Dokumentation der Einzelbeiträge und der jeweiligen Miturheber fehlen dürfte219. Daraus wird teilweise gefolgert, dass sich dies positiv auf den Urheberrechtsverletzer auswirke, da eine hohe Wahrscheinlichkeit bestünde, dass der Kläger nicht alle Miturheber benennen könne, wodurch einer derartige Klage nur geringe Erfolgsaussichten eingeräumt werden220. Die Prozessstandschaft des einzelnen Miturhebers scheitert in diesen Fällen an den mit einer breiten Entwicklungsgemeinschaft verbundenen Schwierigkeiten221. Fraglich ist, ob dieses Risiko notwenig bestehen muss und ob Möglichkeiten ersichtlich sind, auch in Fällen der Miturheberschaft bei Open Source Software zu Lösungen zu kommen, um erfolgreiche Verletzungsklagen zu ermöglichen. In diesen problematischen Sachverhaltskonstellationen kann möglicherweise die in § 10 I UrhG normierte gesetzliche Urheberschaftsvermutung weiterhelfen222. Rechtsfolge einer Vermutung der Urheberschaft ist eine 212

So auch Omsels, in: Festschrift für Paul W. Hertin, S. 163. Möhring/Nicolini/Ahlberg, § 8 Rn. 40; Dreier/Schulze, § 8 Rn. 20. 214 Dreier/Schulze, § 8 Rn. 21. 215 Wandtke/Bullinger/Thum, § 8 Rn. 41; Möhring/Nicolini/Ahlberg, § 8 Rn. 42; Marly, Rn. 419; Spindler, in: Spindler, Abschn. C Rn. 20. 216 BGH GRUR 1994, 39, 41; Koch, CR 2000, S. 276; Haberstrumpf, Rn. 182; Dreier/Schulze, § 8 Rn. 21; Omsels, in: Festschrift für Paul W. Hertin, S. 167. 217 Marly, Rn. 419; Jaeger/Metzger, S. 28; Koch, § 9 Rn. 447; Spindler, in: Spindler, Abschn. C Rn. 20; Omsels, in: Festschrift für Paul W. Hertin, S. 168. 218 Musielak/Werth, ZPO, § 49 Rn. 7. 219 So auch Omsels, in: Festschrift für Paul W. Hertin, S. 167. 220 Plaß, GRUR 2002, S. 672. 221 Jaeger/Metzger, S. 29. 222 Omsels, in: Festschrift für Paul W. Hertin, S. 168. 213

11 Teupen

162

§ 5 Open Source Software im deutschen Urheberrecht

Beweislastumkehr dahingehend, dass nunmehr derjenige, der die Urheberschaft bestreitet, den vollen Gegenbeweis dafür antreten muss, dass der als Urheber bezeichnete nicht der eigentliche Werkschöpfer ist223. Bei der Urheberschaftsvermutung handelt es sich um eine zu einer Beweislastumkehr führende gesetzliche Tatsachenvermutung i. S. v. § 292 ZPO224. Die Vermutung der Urheberschaft gilt dabei auch unter Miturhebern wie auch im Verhältnis der Miturheber zu Dritten225. Nun kann gerade die Regelung des § 10 I UrhG bei Miturhebern von Open Source Software in der Frage nach der Aktivlegitimation weiterhelfen. Verpflichtet eine Open Source-Lizenz den Nutzer für den Fall, dass er Änderungen an dem Computerprogramm vornimmt und diese dann weiterverbreiten will, dazu, einen Vermerk über seine Änderungen und seine Identität in das Computerprogramm einzufügen226, schafft die Lizenz die Voraussetzung für eine Urheberschaftsvermutung gem. § 10 I UrhG und führt bei der Frage nach der Aktivlegitimation zu einer Umkehr der Beweislast227. Eine derartige Pflicht führt im Rahmen einer Leistungsklage dann dazu, dass der vom Urheber Inanspruchgenommene nachweisen muss, dass die entsprechenden Vermerke fehlerhaft sind. Dies dürfte wiederum dem Prozessgegner angesichts der Unüberschaubarkeit von Entwicklungsgemeinschaften im Bereich Open Source Software unmöglich sein228. Die Nennung der Urheber sowie die Bezeichnung ihrer Programmierbeiträge kann also das Problem der Aktivlegitimation beheben. In Fällen, in denen eine Organisation (wie beispielweise die FSF) über ein Softwareprojekt wacht und offizielle Versionen freigibt sowie über die Aufnahme von Änderungen in die offizielle Version entscheidet, erscheint es fraglich, ob nicht die Regelung der gesetzlichen Prozessstandschaft gem. § 10 II S. 1 UrhG eingreift. Die Anwendung dieser Regelung würde im Einzelfall dazu führen, dass vermutet wird, dass der jeweilige Herausgeber oder Verleger dazu ermächtigt ist, die Rechte der Urheber im eigenen Namen geltend zu machen229. Die Ermächtigungsvermutung des Abs. II tritt allerdings nur in Fällen ein, in denen der Urheber nicht bezeichnet wird, 223

Wandtke/Bullinger/Thum, § 10 Rn. 1; Dreier/Schulze, § 10 Rn. 1. BGH, GRUR 1991, S. 456 ff.; OLG Koblenz, GRUR 1987, S. 435 f.; a. A. Loewenheim, der bei der Urheberschaftsvermutung nicht nur von einer Tatsachenvermutung ausgeht, sondern auch von einer Rechtsvermutung i. S. d. § 292 ZPO; vgl. Schricker/Loewenheim, § 10 Rn. 1. 225 Wandtke/Bullinger/Thum, § 10 Rn. 25 f. 226 Vgl. beispielsweise § 2 a GPL, der die Pflicht normiert, die veränderten Daten mit einem „auffälligen“ Vermerk zu versehen. 227 Omsels, in: Festschrift für Paul W. Hertin, S. 168. 228 Gleiche Einschätzung bei Omsels, in: Festschrift für Paul W. Hertin, S. 169. 229 Dreier/Schulze, § 10 Rn. 28; Wandtke/Bullinger/Thum, § 10 Rn. 35, 38. 224

III. Urheberschaft bei Open Source Software

163

der Herausgeber hingegen als solcher bezeichnet ist230. In praktischer Hinsicht dürfen diese Voraussetzungen nicht vorliegen, da in den meisten Fällen von Open Source Software kein bestimmter Herausgeber bestimmt ist und sich zudem Urheber des Werkes feststellen lassen, da sie oft gerade nicht anonym bleiben wollen231. Fraglich bleibt in diesen Fällen aber, ob die jeweilige Organisation nicht als Verleger angesehen werden kann und die Vermutung in § 10 II S. 2 UrhG greift. Im Gegensatz zum Herausgeber muss der Verleger gem. § 10 II S. 2 UrhG nicht auf den Werkstücken angegeben sein232. Der Verleger muss allerdings den vollen Beweis seiner verlegerischen Tätigkeit im konkreten Fall erbringen233. Die Anwendung des § 10 II S. 2 UrhG dürfte in diesem Zusammenhang schon daran scheitern, dass eine Organisation, wie oben beschrieben nicht als Verleger i. S. d. VerlG anzusehen ist. Weder ist sie zu einer Vervielfältigung oder Verbreitung gem. § 1 S. 2 VerlG vertraglich verpflichtet234 noch lässt sich das „offene“ Beziehungsgeflecht zwischen Urhebern und Open Source Organisationen im Bereich Open Source Software insgesamt in das enge rechtliche Korsett eines Verlagsvertrages eingliedern. Eine Anwendung des § 10 II UrhG scheidet somit regelmäßig aus. Man könnte darüber hinaus daran denken, Listen von Miturhebern zu erstellen und beispielsweise auf den Internetseiten des jeweiligen Projektes zur Verfügung zu stellen. Das kann aber nur dann zu einer praktikablen Lösung führen, wenn die Listen vollständig und inhaltlich richtig sind. Sobald auch nur ein Miturheber fehlt, hat die Leistungsklage keine Aussicht auf Erfolg. Sind in Fällen einer Urheberrechtsverletzung an einem Open Source-Computerprogramm nicht alle Miturheber namentlich bekannt, ist eine Leistungsklage regelmäßig unbegründet, da die Aktivlegitimation fehlt. Es bleibt hier festzuhalten, dass eine einwandfreie Dokumentation der Urheber und Miturheber, idealerweise als Pflicht in der jeweiligen Lizenz normiert, am ehesten geeignet ist, die Frage der Aktivlegitimation eindeutig zu beantworten. Das Problem der Aktivlegitimation bei einer Vielzahl von Miturhebern hat auch die Free Software Foundation erkannt. Im Jahr 2002 hat sie mit der Erstellung eines treuhänderischen Lizenzvertrages (für den deutschen 230

Dreier/Schulze, § 10 Rn. 29; Wandtke/Bullinger/Thum, § 10 Rn. 32. Omsels sieht die Vermutung schon regelmäßig mit der Vorlage der GPL wiederlegt. Vgl. Omsels, in: Festschrift für Paul W. Hertin, S. 169. 232 Wandtke/Bullinger/Thum, § 10 Rn. 34; Möhring/Nicolini/Ahlberg, § 10 Rn. 27. 233 Wandtke/Bullinger/Thum, § 10 Rn. 34. 234 Es müssten dann Verlagsverträge mit allen Urhebern geschlossen sein, woran es in der Praxis wohl scheitern würde. 231

11*

164

§ 5 Open Source Software im deutschen Urheberrecht

Rechtsraum in deutscher Sprache verfasst) auch auf diese Problematik reagiert235. Sie bietet den Urhebern und Miturhebern von Open Source Software an, ihr die ausschließlichen Rechte an der Software gegen Rückübertragung einfacher Nutzungsrechte zu übertragen. Damit kann die Free Software Foundation die Interessen der Urheber bündeln und in Fällen von Rechtsstreitigkeiten vor Gericht wahren. Mit dieser Lösung ist eine einheitliche Vertretung und Geltendmachung der Urheberrechte auch in Fällen der Miturheberschaft möglich, in denen die Identität der Miturheber kaum eindeutig zu klären ist236. b) Werkverbindung gem. § 9 UrhG Bei der Entwicklung von Open Source Software sind auch Fälle denkbar, in denen Programmierer selbstständige, eigenständig gem. §§ 69 a ff. UrhG schutzfähige Programme oder Programmfunktionen aufgrund einer vertraglichen Vereinigung zwecks gemeinsamer Verwertung zu einem gemeinsamen Computerwerk miteinander verbinden. Im Unterschied zur Miturheberschaft ist hier bezüglich der von den einzelnen Programmierern erstellten Programme oder Programmteile genau zu überprüfen, ob sie für sich genommen, also vom Gesamtwerk gesondert verwertbar sind. Die Einzelprogramme oder Module sind dahingehend zu überprüfen, ob sie für sich lauffähig sind und als Computerprogramm schutzfähig sind. Da eine dem § 8 II S. 3 UrhG vergleichbare Regelung in § 9 UrhG fehlt, entsteht mit einer Werkverbindung keine Gesamthandsgemeinschaft237. Die vertragliche Vereinbarung zwischen den Urhebern ist als Vertrag über die Gründung einer BGB-Gesellschaft gem. den §§ 705 ff. BGB einzuordnen238, der gerade im Bereich Open Source Software regelmäßig durch schlüssiges Verhalten geschlossen werden dürfte. Auch hier ist wieder die Verbreitung und Verbesserung des Computerprogramms der Gesellschaftszweck, der den Vereinbarungen zugrunde liegt239. Kommen bei einer Werkverbindung die Regelungen über die BGB-Gesellschaft zur Anwendung, stößt man auch hier wieder auf das oben geschilderte Problem der Aktivlegitimation. Auch hier bestehen die genannten Lösungsmöglichkeiten240. 235

http://www.germany.fsfeurope.org/projects/fla/fla.de.html. So auch Marly, Rn. 419. 237 Dreyer, in: HK-UrhR, § 9 Rn. 3; Marly, Rn. 420. 238 Haberstrumpf, Rn. 186; Spindler, in: Spindler, Abschn. C Rn. 13; Marly, Rn. 420. 239 Marly, Rn. 420; Jaeger/Metzger, S. 27. 240 Vgl. § 5 III. 2. bb). 236

III. Urheberschaft bei Open Source Software

165

c) Fazit Wird ein Computerprogramm von einer Entwicklungsgemeinschaft mit dem Ziel einer Open Source-Lizenzierung erstellt, so muss man dazu raten, eine detaillierte Dokumentation betreffend der beteiligten Programmierer und ihrer Beiträge zu erstellen und zu führen oder gegebenenfalls die Möglichkeit des Abschlusses eines Treuhandvertrages in Betracht zu ziehen, um prozessuale Probleme und Risiken zu vermeiden. Dies gilt aber nur in Fällen, in denen die Entwicklungsgemeinschaft so groß ist, dass eine Identifizierung der beteiligten Urheber unmöglich erscheint. 3. Open Source-Programmierer im Angestelltenverhältnis Sind Softwareprogrammierer durch ein Arbeits- oder Dienstverhältnis an einen Arbeitgeber gebunden findet § 69 b UrhG Anwendung. Dem Arbeitgeber steht insofern die Entscheidung zu, ob er das entstandene Computerprogramm unter eine Open Source-Lizenz stellt. Insofern bestehen an dieser Stelle keine rechtlichen Besonderheiten.

§ 6 Open Source-Lizenzen und Verwertungsrechte I. Einleitung Die Open Source Gemeinde ist kein Gegner geistigen Eigentums und insbesondere des Urheberrechts. Vielmehr nutzt man das Urheberrecht gerade dazu, die Ziele der Open Source Bewegung durch Lizenzvereinbarungen abzusichern1. Es gilt im Folgenden zu untersuchen, wie die Lizenzierung von Open Source Software erfolgt, welchen Inhalt sie hat und inwiefern das Copyleft-Lizenzmodell mit dem UrhG im Einklang steht. Befasst man sich mit der Lizenzierung von Open Source Software, hat man es mit einer Vielzahl verschiedener Lizenzmodelle zu tun. Da die Entscheidung, eine Software als Open Source Software zu verbreiten, regelmäßig beim Urheber liegt und gerade im Bereich von Open Source Software eine Vielzahl von unabhängigen Programmierern parallel tätig sind, darf man nicht auf einen Numerus clausus von Open Source-Lizenzen hoffen. Im Laufe der Open Source Entwicklung sind vielmehr eine Vielzahl verschiedener Open Source-Lizenzen entwickelt worden, die den jeweiligen Bedürfnissen der Urheber angepasst sind2. Eine abschließende Aufzählung ist daher kaum machbar. Eine Open Source-Lizenz „als solche“ gibt es somit nicht! Im Folgenden werden deshalb nicht alle Lizenzen ausführlich besprochen, da dies im Rahmen der vorliegenden Arbeit ein unmögliches und auch nicht zielführendes Unterfangen wäre. Da die Lizenzen schon aufgrund der Open Source-Definition sowie Free Software-Definition in wesentlichen urheberrechtlichen Fragen inhaltlich übereinstimmen, werden die Rechtsfragen von Freier Software am Beispiel einzelner bedeutender Lizenzen dargestellt, wobei die GPL, auch als „Grundtypus eines Großteils der Open Source-Lizenzen“ bezeichnet3, im Mittelpunkt steht.

1

So auch Spindler, in: Spindler, Abschn. A Rn. 2.; Moglen, Interview über die Zukunft der GPL, http://www.golem.de/0406/31795.html. 2 Eine umfangreiche Aufzählung von Open Source-Lizenzen (die auch gleichzeitig abrufbar sind) findet sich u. a. auf der Internetseite des Instituts für Rechtsfragen der Freien und Open Source Software (ifrOSS) unter der Rubrik „Lizenzen“, www.ifross.de; Darstellung einzelner Lizenzen auch bei Grassmuck, S. 275 ff. und Schiffner, S. 83 ff. 3 Jaeger/Metzger, S. 31.

II. Open Source Softwarelizenzen

167

II. Open Source Softwarelizenzen Man kann die Open Source-Lizenzen, die zur Zeit verwendet werden, grundsätzlich in drei Kategorien einteilen: GPL(-artige) Lizenzen, BSD(-artige) Lizenzen (BSD = Berkeley Software Distribution) und MPL(-artige) Lizenzen (MPL = Mozilla Public License)4. Dabei unterscheiden sich die Lizenzgruppen in der Intensität ihres Copyleft-Effekts. 1. Open Source Softwarelizenzen ohne Copyleft-Effekt Lizenzvereinbarungen im Bereich Open Source Software können grundsätzlich auch dahingehend getroffen werden, dass einem Nutzer alle Nutzungsfreiheiten gewährt werden, ohne dass die Pflicht statuiert wird, etwaige Veränderungen, Verbesserungen oder Anpassungsprogrammierungen unter der ursprünglichen Open Source-Lizenz weiterzuverbreiten. Hier bestehen bezüglich der geänderten Versionen keine Bedingungen hinsichtlich der zu verwendenden Lizenz. Dem Nutzer ist es daher möglich, Open Source Software nach deren Änderung in proprietäre Software zu überführen. Zu diesen Lizenzen ohne Copyleft-Wirkung gehören die BSDartigen Lizenzen, z. B. die Apache Software License 1.15. 2. Open Source Softwarelizenzen mit strengem Copyleft-Effekt Open Source-Lizenzen mit strengem Copyleft-Effekt gewähren die Nutzungsfreiheiten nur unter der Bedingung, dass auch Veränderungen oder Verbesserungen unter die Ausgangslizenz gestellt werden und somit frei zugänglich sind. Die bekannteste Open Source Softwarelizenz ist die GPL6.

4 Das ifrOSS-Institut unterscheidet nach dem Grad des Copyleft-Effektes: Lizenzen ohne Copyleft-Effekt (BSD-artige Lizenzen), Lizenzen mit strengem CopyleftEffekt (GPL-artige Lizenzen) und Lizenzen mit beschränktem Copyleft-Effekt (MPL-artige Lizenzen). 5 Vgl.: http://www.apache.org/License-1.1. Eine ausführliche Auflistung von Lizenzen ohne Copyleft-Effekt findet sich unter: http://ifross.de/ifross_html/lizenz center.html. 6 Eine ausführliche Auflistung von Lizenzen mit strengem Copyleft-Effekt findet sich unter: http://ifross.de/ifross_html/lizenzcenter.html.

168

§ 6 Open Source-Lizenzen und Verwertungsrechte

3. Open Source-Lizenzen mit beschränktem Copyleft-Effekt Open Source-Lizenzen mit beschränkten Copyleft-Effekt ermöglichen eine Kombination von verschiedenen Lizenzmodellen und ermöglichen auch einen proprietären Vertrieb von Dateien, wenn in diesen Modifikationen realisiert worden sind. So ist es dann auch Möglich vorgenommene Veränderungen unter eine eigene Lizenz zu stellen. Bekanntestes Beispiel einer solchen Open Source-Lizenz ist die Mozilla Public License7. 4. Verbreitung einzelner Open Source-Lizenzen Zu den wichtigsten Open Source-Lizenzen kann man grundsätzlich die GNU General Public License, die GNU Lesser General Public License, die BSD License, die Apache Software License sowie die Mozilla Public License zählen. Die bedeutendste und meist verwendete Lizenz ist die GNU General Public License (GPL)8. Über 70% der Open Source Projekte werden unter der GPL verbreitet. Die 1989 maßgeblich von dem amerikanischen Juristen Eben Moglen entwickelte GPL war die erste Lizenz, die die urheberrechtlichen Besonderheiten Freier Software regelte und war und ist Ausgangspunkt für die Formulierung und Ausgestaltung nahezu aller Open SourceLizenzen9. Das rechtfertigt auch, ihr bei der der Klärung urheberrechtlicher Fragen von Open Source Software besondere Beachtung zu schenken.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen 1. Einleitung Das Copyleft-Modell enthält keinen Verzicht auf Urheberrechte. Um die in der Open Source-Definition und Free Software-Definition festgelegten Lizenzierungsziele im Geltungsbereich des UrhG zu erreichen, müssen die Lizenzen mit dem deutschen UrhG kompatibel sein. 7

http://www.mozilla.org/MPL/MPL-1.1.html. Eine ausführliche Auflistung von Lizenzen mit beschränktem Copyleft-Effekt findet sich unter: http://ifross.de/ ifross_html/lizenzcenter.html. 8 Der Text der GNU General Public License, Version 2 (im Weiteren als „GPL“ bezeichnet) kann unter: http://www.gnu.org/licenses/gpl.txt abgerufen werden. Er ist ferner abgedruckt bei Schiffner, S. 273 ff. und Jaeger/Metzger, S. 177 ff. (deutsche Übersetzung, S. 181 ff.). 9 So auch Spindler, in: Spindler, Abschn. B Rn. 1.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

169

Open Source-Lizenzen beinhalten regelmäßig die Einräumung von Verwertungsrechten, Festlegung von Pflichten und Regelungen zur Gewährleistung und Haftungsfragen. Diese Grundsäulen des Copyleft-Modells finden sich in nahezu allen Open Source-Lizenzmodellen. An dieser Stelle stellt sich nun die Frage nach der rechtlichen Ausgestaltung und der Vereinbarkeit des Copyleft-Modells mit dem UrhG. Bevor auf die dogmatischen Fragen der Verknüpfung von Rechten und Pflichten in Open Source-Softwareverträgen eingegangen wird, erfolgt zunächst die Darstellung von Nutzungsrechten und der Verpflichtungen des Lizenznehmers. Die Frage von Gewährleistungs- und Haftungsregeln wird im Anschluss unter urhebervertragsrechtlichen Gesichtspunkten behandelt. 2. Verwertungsrechte in Open Source-Lizenzen a) Einräumung von Nutzungsrechten an Open Source Software Open Source-Lizenzen gewähren dem Nutzer weitgehende Verwertungsfreiheiten an einem Computerprogramm. Der Urheber hat grundsätzlich verschiedene rechtliche Möglichkeiten, einem Anwender die Nutzung und Verwertung seines Computerprogramms zu gewähren. § 29 II UrhG stellt auf unterschiedliche Arten von Rechtsgeschäften ab, die es einem Urheber ermöglichen, sein Werk zu verwerten. Der Urheber hat die Möglichkeit der Einräumung von Nutzungsrechten in Form einer Rechtsübertragung (§ 31 UrhG), sowie schuldrechtliche Einwilligungen und Vereinbarungen in Bezug auf Nutzungen zu treffen. Darüber hinaus kann er die in § 39 UrhG geregelten Rechtsgeschäfte über Urheberpersönlichkeitsrechte vornehmen10, wobei diese Möglichkeit bei Open Source-Lizenzen keine Rolle spielt. Bei der Einräumung von Nutzungsrechten kann der Urheber darüber hinaus entscheiden ob er ausschließliche oder einfache Nutzungsrechte einräumen will. aa) Schuldrechtliche Einwilligung in die Nutzung von Open Source Software Grundsätzlich denkbar wäre es, dass die Open Source Softwarelizenz lediglich eine schuldrechtliche Einwilligung dahingehend enthält, dass der Nutzer die für die Open Source Nutzung notwendigen Handlungen vornehmen darf. Eine schuldrechtliche Befugnis ein geschütztes Werk zu nutzen, gilt jedoch lediglich zwischen zwei Vertragsparteien, nicht gegenüber Drit10

Kotthoff, in: HK-UrhR, § 29 Rn. 11.

170

§ 6 Open Source-Lizenzen und Verwertungsrechte

ten11. Das Open Source-Lizenzvereinbarungen einem Nutzer lediglich eine Einigung über eine schuldrechtliche Einwilligung anbieten, erscheint jedoch sehr zweifelhaft. Der Nutzer soll das Computerprogramm vervielfältigen, verbreiten und bearbeiten dürfen. Dies sind klassische Verwertungsrechte, die sich so auch in urheberrechtlichen Vorschriften wiederfinden und gem. § 31 UrhG eingeräumt werden. Die Einräumung dieser Nutzungsbefugnisse geht weit über eine reine Einwilligung hinaus. Die Open Source Entwicklungsmethode sowie die Vorstellung vom freien Zugang auch zu Softwareprodukten bedingen gerade die Einräumung einer umfassenden Rechtsposition dahingehend, das der Anwender nicht nur gegenüber seinem Vertragspartner zu Nutzung befugt ist, sondern auch gegenüber jedem Dritten seine Ansprüche auf Vornahme von Verwertungshandlungen durchsetzen kann. Die Rechte, die der Anwender vom Urheber erhält sollen gegenüber Dritten wirken, so dass die Verwertungsrechte an einem Open Source-Computerprogramm als gegenständlich, dingliche Rechte eingeräumt werden sollen. Als Indiz für eine Einräumung von Verwertungsrechten gem. § 31 I UrhG kann auch die Verwendung des Terminus „License“ angeführt werden. Durch Lizenzen werden somit Nutzungs- und Verwertungsrechte gem. § 31 UrhG eingeräumt. Die Open Source-Lizenzen enthalten folglich keine schuldrechtliche Einwilligung des Urhebers12. bb) Rechtseinräumung gem. § 31 UrhG Im Rahmen von Open Source-Lizenzen werden regelmäßig Verwertungsrechte gem. § 31 UrhG eingeräumt. Dabei besteht gem. § 31 I S. 2 UrhG grundsätzlich die Möglichkeit, dass der Urheber dem Nutzer ein ausschließliches oder ein einfaches Nutzungsrecht einräumt. Beide Möglichkeiten unterscheiden sich darin, dass das ausschließliche Nutzungsrecht gem. § 31 III S. 1 UrhG den Inhaber dazu berechtigt, das Werk unter Ausschluss aller anderen Personen auf die ihm erlaubte Weise zu nutzen. Ob ein einfaches oder ein ausschließliches Nutzungsrecht eingeräumt werden soll unterliegt grundsätzlich der Parteivereinbarung und ist durch Auslegung zu ermitteln. Die Auslegung richtet sich hier nach dem Inhalt der Open Source-Lizenzen und dem damit verbundenen Willen der Urheber. (1) Ausschließliches Nutzungsrecht Ausgehend vom Sinn und Zweck von Open Source-Lizenzverträgen wird klar, dass hier grundsätzlich kein ausschließliches Nutzungsrecht gem. § 31 11 12

Dreier/Schulze, § 31 Rn. 7. So auch Omsels, in: Festschrift für Paul W. Hertin, S. 155.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

171

I, III S. 1 UrhG eingeräumt wird13. Würde dem Anwender ein ausschließliches Nutzungsrecht eingeräumt, könnte er das Werk unter Ausschluss jedes Dritten einschließlich des Urhebers auf die in der Lizenz festgelegte Art benutzen14. Es wäre somit nicht mehr möglich, dass diese Nutzungen auch rechtmäßig von anderen vorgenommen würden. Die gewünschten Parallellizenzierungen bei Open Source-Computerprogrammen wären bei Einräumung von ausschließlichen Nutzungsrechten rechtlich unmöglich. (2) Einfaches Nutzungsrecht Richtigerweise wird übereinstimmend davon ausgegangen, dass im Rahmen von Open Source Softwarelizenzverträgen den Softwarenutzer einfache Nutzungsrechte gem. § 31 I, II UrhG eingeräumt werden15. Das einfache Nutzungsrecht berechtigt den Inhaber das Werk neben dem Urheber oder anderen Berechtigten auf die ihm erlaubte Art zu nutzen16. Eine Parallelnutzung bleibt so möglich, da bei einfachen Nutzungsrechten gem. § 31 II UrhG Dritte von der Nutzung nicht per se ausgeschlossen sind. (a) Der Streit um das einfache Nutzungsrecht An dieser Stelle soll nicht unerwähnt bleiben, dass seit langem Streit darüber besteht, ob einfache Nutzungsrechte eine rein schuldrechtliche Gestattung der Nutzung beinhalten oder ob ihnen ein dinglicher Charakter mit Ausschließlichkeitswirkung zukommt17. Einigkeit besteht jedenfalls dahingehend, dass Nutzungsrechte durch Verfügungen begründet werden18. Der Streit ist in Fallgestaltungen von Relevanz, in dem der Inhaber eines einfachen Nutzungsrechts gegen Dritte vorgehen will. Nach einer Ansicht kommt dem einfachen Nutzungsrecht nur schuldrechtlicher Charakter zu19. Das wird damit begründet, dass dem Inhaber eines einfachen Nutzungs13 So auch Omsels, in: Festschrift für Paul W. Hertin, S. 155; Dreier/Schulze, § 69 a Rn. 11. 14 Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 27. 15 Jaeger/Metzger, S. 31; Koch, § 9 Rn. 451, ders. CR 2000, S. 333; Schiffner, S. 154; Omsels, in: Festschrift für Paul W. Hertin, S. 155; Dreier/Schulze, § 69 a Rn. 11; LG München I, CR 2004, S. 775. 16 Haberstrumpf, Rn. 389. 17 Haberstrumpf, Rn. 389. 18 Loewenheim/Loewenheim/Jan Bernd Nordemann, § 25 Rn. 1. 19 Möhring/Nicolini/Spautz, § 31 Rn. 39; Fromm/Nordemann/Hertin, §§ 31/32 Rn. 2; BGH GRUR 1959, S. 201 f.; wohl auch Hoeren, Urteilsanmerkung zu LG München I, CR 2004, S. 777. Weitere Nachweise bei Schricker/Schricker, Vor §§ 28 ff. Rn. 49.

172

§ 6 Open Source-Lizenzen und Verwertungsrechte

rechts kein Abwehrrecht zusteht und somit auch nicht von einer dinglichen Wirkung gesprochen werden kann. Die inzwischen herrschende Meinung ordnet das einfache Nutzungsrecht aufgrund der Vergleichbarkeit mit beschränkt dinglichen Rechten als quasi-dingliches und somit gegenständliches Recht mit dinglicher Wirkung ein20. Beide Auffassungen sind darüber einig, dass der Inhaber eines einfachen Nutzungsrechts keine Abwehrrechte gegenüber dem Urheber oder Dritten hat, er allenfalls in Prozessstandschaft Rechte geltend machen kann21. Die herrschende Auffassung verweist allerdings auf die Regelung des § 33 UrhG. Der Bestand des einfachen Nutzungsrechts ist auch dann geschützt, wenn der Urheber gleichzeitig oder nachträglich einem Dritten das gleiche Nutzungsrecht einräumt22. Dieser Sukzessionsschutz spricht der herrschenden Meinung nach aber gerade für die Annahme eines gegenständlichen Rechts mit dinglicher Wirkung. Obwohl im Zusammenhang mit diesem Theorienstreit von Vertretern beider Auffassungen immer wieder darauf hingewiesen wird, dass die Auseinandersetzung für die Praxis von keiner Relevanz ist23, ist die herrschende Meinung überzeugend und im Hinblick auf § 33 UrhG konsequent. Einfache Nutzungsrechte sind gegenständliche Rechte und begründen eine Rechtsposition, die gegenüber jedermann abgesichert ist. Sie reichen somit weiter als eine rein schuldrechtliche Beziehung zwischen zwei Vertragsparteien. Hiergegen wird angeführt, dass sich der BGH24 in seiner Entscheidung für eine schuldrechtliche Wirkung einfacher Nutzungsrechte eintritt25. Dabei muss aber heraus gestellt werden, dass das besagte Urteil aus dem Jahr 1959 stammt. Den § 33 UrhG in der heutigen Fassung gab es derzeit nicht. Gerade in diesem Kontext kann die Neufassung des § 33 UrhG26 für eine dingliche Wirkung herangezogen werden. Der Gesetzgeber hat in dem Wissen um die Streitigkeiten den Sukzessionsschutz in der Regelung festgeschrieben. In der Wirkung gegenüber später eingeräumten Nutzungsrechten werden einfaches und ausschließliches Nutzungsrecht gleichgesetzt. Auch in der Einräumung eines einfachen Nutzungsrechts liegt somit eine 20 Dreier/Schulze, § 31 Rn. 52; Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 31; Schricker/Schricker, Vor §§ 28 ff. Rn. 49; Rehbinder, Rn. 306; Schack, Rn. 540; Lehmann/Haberstrumpf, S. 150; Haberstrumpf, Rn. 389; Kotthoff, in: HKUrhR, § 31 Rn. 16; Loewenheim/Loewenheim/Jan Bernd Nordemann, § 25 Rn. 1; LG München I, CR 2004, S. 775. 21 Schricker/Schricker, Vor §§ 28 ff. Rn. 49. 22 Dreier/Schulze, § 31 Nr. 52. 23 Schricker/Schricker, Vor §§ 28 ff. Rn. 49; Möhring/Nicolini/Spautz, § 31 Rn. 39. 24 BGH GRUR 1959, S. 201 f. 25 So beispielsweise Hoeren, Urteilsanmerkung zu LG München I, CR 2004, S. 777. 26 Neugefasst mWv 01.07.2002 durch Art. 1 G v. 22.03.2002, BGBl. I S. 1155.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

173

Verfügung, da der Urheber sowie auch ein späterer Inhaber des ausschließlichen Nutzungsrechts an einem Vorgehen gegen den Inhaber des einfachen Nutzungsrechts gehindert sind. Eine lediglich schuldrechtliche Wirkung des einfachen Nutzungsrechts würde diese Wirkung nicht gewährleisten. Die Einräumung einfacher Nutzungsrechte aufgrund Open Source-Lizenzen ist somit dinglicher Natur27. (b) Keine Verwertungsketten bei Open Source Softwarelizenzen Open Source Software wird zunächst vom Urheber als solche lizenziert und dann an Dritte verbreitet. Jeder, ob Distributor, Softwareunternehmen oder einfacher Softwareendanwender kann die Software wiederum weiterverbreiten. Damit stellt sich die Frage, wie sich der Gang der Rechtsübertragung vollzieht. Im Zusammenhang mit der Übertragung einfacher Nutzungsrechte im Rahmen von Open Source-Lizenzverträgen ist anzumerken, dass es nicht zum Entstehen von Verwertungsketten kommt, die Nutzungsrechte mithin nicht in einer Art Schneeballsystem übertragen werden28. Die GPL bestimmt in § 6 GPL, dass bei jeder Redistribution, also jeder Weitergabe der Software der potenzielle Anwender die lizenzrechtlichen Befugnisse (somit die Nutzungsrechte) automatisch vom Urheber des Originalcomputerprogramms übertragen erhält29. Der Erwerber einfacher Nutzungsrechte erhält jedoch keine Befugnisse, selbst Rechte am Originalcomputerprogramm an Dritte einzuräumen. Erst- sowie Folgeerwerb einfacher Nutzungsrechte erfolgt direkt durch den Urheber als Inhaber aller ausschließlichen Nutzungsrechte an dem Open Source-Computerprogramm. In diesem Zusammenhang tritt derjenige, der das Programm einschließlich der Lizenz weiterverbreitet, lediglich als Bote des Urhebers auf. Das Angebot des Urhebers, der sein Computerprogramm oder seine urheberrechtlich geschützten Programmkomponenten unter ein Open Source-Lizenz stellt, richtet sich zwar ad incertas personas. Es handelt sich aber nicht, wie man zunächst vermuten könnte, um eine invitatio ad offerendum, da der Inhalt des Angebotes mit der Entscheidung für ein bestimmtes Open Source-Lizenzmodell feststeht. Verhandlungen kommen grundsätzlich nicht in Betracht und ein Verhandlungs27

Koch, CR 2000, S. 333; Jaeger/Metzger, S. 32; Schiffner, S. 154. Omsels, in: Festschrift für Paul W. Hertin, S. 159 f.; Spindler, in: Spindler, Abschn. C Rn. 23; Jaeger/Metzger, S. 32; Plaß, GRUR 2002, S. 676 f.; Schiffner, S. 168. 29 Vgl. § 6 GPL: „Each time you redistribute the Program (or any work based on the Program), the recipient automatically receive a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.“ 28

174

§ 6 Open Source-Lizenzen und Verwertungsrechte

spielraum ist auch vom Urheber regelmäßig nicht vorgesehen. Ferner kommt es den Urhebern auch nicht darauf an, sich den einzelnen Lizenznehmer auszusuchen. Der Urheber schließt vielmehr mit jedem, der den Inhalt der jeweiligen Open Source-Lizenz akzeptiert und die Software nutzen will, eine Lizenzvereinbarung ab. Dem Urheber ist es egal, wer sein Lizenznehmer wird. Mit der Verwendung einer Open Source-Lizenz verzichtet er daher auch wirksam auf den Zugang der Annahmeerklärung gem. § 151 S. 1 BGB30. b) Die einzelnen Verwertungsrechte Damit ein Nutzer von Open Source Software die in den Definitionen zugrunde gelegten Freiheiten ausüben kann, müssen ihm die dazu nötigen Nutzungsrechte übertragen werden. Dabei werden dem Nutzer regelmäßig drei wesentliche Nutzungsrechte an dem Computerprogramm ausdrücklich eingeräumt: das Vervielfältigungsrecht, das Recht zur Bearbeitung und das Verbreitungsrecht. Die GPL beispielsweise weist bereits in der Präambel auf diese drei zentralen Nutzungsbefugnisse hin31 und stellt zugleich in § 0 GPL klar, dass Handlungen darüber hinaus nicht vom der lizenzrechtlichen Befugnis mitumfasst sind32. Die GPL beschränkt in § 0 GPL die Rechtseinräumung auf Programme und jede anderen Werke, bei denen ein Copyright-Vermerk des Urhebers auf die Geltung der GPL hinweist33. aa) Das Vervielfältigungsrecht i. S. v. §§ 16, 69 c Nr. 1 UrhG (1) Befugnisse des Nutzers Durch Verwendung von Open Source-Lizenzbestimmungen räumt der Urheber dem Nutzer ein umfassendes Vervielfältigungsrecht i. S. d. §§ 16, 69 c Nr. 1 UrhG ein. Bezogen auf Vervielfältigungen unterscheidet die GPL zwischen Quellcode, Objektcode und der lauffähigen Form eines Computerprogramms. Dem Anwender wird gem. § 1 GPL zunächst unter Einhaltung bestimmter Bedingungen gestattet, unveränderte Kopien des Quellcodes auf 30

So auch Omsels, in: Festschrift für Paul W. Hertin, S. 159; Schiffner, S. 169. „. . . offer you this license which gives you legal permission to copy, distribute and/or modify the software“. 32 § 0 GPL: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.“ 33 „This license applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License“. 31

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

175

beliebigen Medien („. . . in any medium“) zu machen. § 3 GPL gestattet darüber hinaus die Vervielfältigung des Computerprogramms soweit es als Objektcode oder als lauffähige Form vorliegt. Auch hier gelten dann neben den zusätzlichen Anforderungen des § 3 GPL die schon in §§ 1, 2 GPL zugrunde gelegten Bedingungen. Der Anwender ist somit dazu berechtigt, das Computerprogramm in welcher Form es auch immer vorliegt, dauerhaft sowie vorübergehend mit jedem Mittel und in jeder Form in beliebiger Anzahl zu vervielfältigen34. Darunter fällt auch die wirtschaftlich bedeutende Nutzung der Software für Emedded-Systeme35 Die oben genannten Vervielfältigungsrechte beziehen sich zunächst nur auf das Originalwerk in unveränderter Form. Sobald das Computerprogramm verändert wird, räumt die GPL gem. § 2 GPL auch für die Veränderungen ein Vervielfältigungsrecht ein, soweit die dort genannten Bedingungen eingehalten werden. Auch im Bereich Open Source Software kommt man im Zusammenhang mit der Frage, welche Vervielfältigungsrechte dem Nutzer einräumt werden zu dem Streitpunkt, ob das Laden eines Computerprogramms in den Arbeitsspeicher und das Ausführen des Computerprogramms eine zustimmungsbedürftige Vervielfältigungshandlung ist36. Gerade im Bereich Open Source Software ist dieser Streitpunkt weder von theoretischer noch praktischer Relevanz. Soweit die Ausführung des Computerprogramms auf einer Arbeitsstation eine urheberrechtlich relevante Vervielfältigungshandlung darstellt37, stellt § 0 GPL klar, das insoweit die GPL keine Beschränkung enthält. Deike will dies aber so verstanden wissen, dass insoweit kein Nutzungsrecht eingeräumt wird38. Diese Auslegung erscheint zu restriktiv und unvereinbar mit der Intention des Lizenzgebers39. Der Hinweis in § 0 GPL dürfte vielmehr lediglich klarstellender Natur sein. Auch die Programmaus34

Schiffner, S. 133; Marly, Rn. 430 f.; Koch, § 9 Rn. 459. Jaeger/Metzger, S. 34. Embedded Systeme sind eingebettete (Computer-)Systeme, die ihre Funktion in einer Vielzahl von Anwendungsbereichen und Geräten vollziehen, wie z. B. in Flugzeugen, Autos, Kühlschränken, Fernsehern, DVD-Playern oder allgemein Geräten der Unterhaltungselektronik. 36 Ausführlich dazu Schiffner, S. 125 ff. 37 Vgl. dazu Marly, Rn. 188, der danach differenziert, ob das Computerprogramm zum Zweck der Ausführung neu in den Arbeitsspeicher hineingeladen werden muss (dann liegt mit der h.M. eine zustimmungspflichtige Vervielfältigungshandlung vor) oder ob das Programm bereits im Hauptspeicher vorhanden ist und somit die Weitere Abarbeitung allein durch den Mikroprozessor erfolgt, wobei im Mikroprozessor zu keiner Zeit ein körperliche Festlegung in der Form vorhanden ist, die für die menschlichen Sinne wahrnehmbar wäre (dann liegt in dieser Abarbeitung keine urheberrechtliche Verwertungshandlung im Sinne einer Vervielfältigung). Ausführlich dazu auch Schiffner, S. 125 ff. 38 Deike, CR 2003, S. 10. 39 So auch Spindler, in: Spindler, Abschn. C Rn. 75. 35

176

§ 6 Open Source-Lizenzen und Verwertungsrechte

führung ist für den Fall, dass man von einer urheberrechtlichen Verwertungshandlung ausgeht, von der Einräumung eines einfachen Nutzungsrechts mitumfasst40. Wäre der reine Programmablauf nicht von der Rechtseinräumung der Open Source-Lizenz miterfasst, wäre eine Lizenzierung eines Computerprogramms als Open Source Software obsolet, da eine Benutzung ausgeschlossen wäre. Dürfte man ein Open Source-Computerprogramm auf der Arbeitsstation nicht ausführen, wären auch Bearbeitungsoder Verbreitungshandlungen nutzlos und widersinnig. Mit dem Computerprogramm wäre nichts anzufangen. Da dies offensichtlich nicht gewollt ist, ist richtigerweise davon auszugehen, dass dem Anwender auch einfache Nutzungsrechte für das Laden sowie den Programmablauf eingeräumt werden. Mitumfasst vom eingeräumten Vervielfältigungsrecht sind alle Handlungen, die für den Gebrauch des Computerprogramms im Rahmen der lizenzrechtlichen Befugnisse notwendig sind. Insofern bedarf es auch nicht der Heranziehung des § 69 d I UrhG, da dem Nutzer die Rechte durch die Lizenz eingeräumt sind und somit schon die Anwendungsvoraussetzungen nicht gegeben sind41. Somit sind das Laden, Anzeigen, Ablaufen, Übertragen sowie das Speichern von der lizenzrechtlichen Befugnis zur Vervielfältigung mitumfasst. Folglich sind die in § 69 c UrhG aufgeführten Vervielfältigungen von der GPL gedeckt. (2) Pflichten und Bedingungen Das Vervielfältigungsrecht des Anwenders ist bei Open Source-Lizenzen an die Einhaltung bestimmter Bedingungen geknüpft. Die Bedingungen unterscheiden sich dahingehend, ob das Originalwerk oder das Werk in veränderter Form vervielfältigt wird. Gem. § 1 GPL dürfen Kopien des Quellcodes des Originalprogramms nur dann angefertigt werden, wenn mit jeder Kopie ein entsprechender Copyright-Vermerk sowie der Hinweis auf den Haftungsausschluss veröffentlicht wird. Diese Anforderung dürfte jedoch nur im Zusammenhang mit einer gleichzeitigen Verbreitung des Programms bestehen. Wird das Programm nur für interne Zwecke ohne Verbreitungsabsicht vervielfältigt, ist daher ein entsprechender Vermerk oder Hinweis entbehrlich. Für das Originalprogramm, sei es in der Form als Objektcode oder als Maschinencode, legt sodann § 3 GPL für den Fall einer Vervielfältigung spezielle Bedingungen fest, die aber auch nur dann einzuhalten sind, wenn das Pro40 41

So auch Spindler, in: Spindler, Abschn. C Rn. 75. So auch Schiffner, S. 132.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

177

gramm an Dritte weitergegeben werden sollte. Diese Bedingungen werden im Zusammenhang mit dem Verbreitungsrecht erörtert42. Die veränderte Form eines Computerprogramms darf vervielfältigt werden, soweit die Anforderungen gem. § 2 GPL erfüllt werden. Die Vervielfältigungsstücke müssen gem. § 2 a GPL mit einem auffälligen Vermerk versehen werden, der auf die Art der Veränderung hinweist und das Datum der Änderung festhält. Gem. § 2 b GPL darf das Vervielfältigungsstück für den Fall der Weitergabe an Dritte nur unter den Bedingungen der GPL und ohne die Erhebung von Lizenzgebühren erfolgen. Dabei ist an dieser Stelle deutlich zu machen, dass für den reinen Kopiervorgang sehr wohl eine Gebühr genommen werden darf. § 1 GPL erlaubt über diese Gebühr hinaus auch die Erhebung eines Entgeltes, sofern hierfür eine Garantie für das Programm angeboten wird. bb) Das Verbreitungsrecht i. S. d. §§ 17, 69 c Nr. 3 UrhG (1) Befugnisse des Nutzers Damit die Anforderungen der Open Source-Definition sowie der Free Software-Definition erfüllt werden, muss der Urheber von Open Source Software dem Anwender ferner Verbreitungsrechte einräumen. Eine unkomplizierte, schnelle und weite Verbreitung ist ein zentrales Ziel des Open Source Konzeptes. Demzufolge gewähren Open Source-Lizenzen dem Nutzer neben Vervielfältigungsrechten auch ein umfassendes Verbreitungsrecht. Hierin liegt der entscheidende Unterschied zur kommerziell vertriebenen Software, bei der das Verbreitungsrecht ausschließlich beim Urheber bzw. Rechteinhaber bleibt43. Nur so kann er nämlich kontrollieren, wie viel Lizenzeinheiten im Umlauf sind und wer sein Programm rechtmäßig nutzt. Die Entgeltlichkeit des kommerziellen Softwarevertriebs setzt eine derartige Kontrollmöglichkeit voraus. Dieser Kontrollmöglichkeit bedarf es bei Open Source Software gerade nicht. Die GPL berechtigt den Nutzer dazu, sowohl das Originalcomputerprogramm als auch veränderte Programmversionen zu verbreiten. Zunächst ermächtigt § 1 GPL den Nutzer dazu den Quelltext des Programms, so wie er es erhalten hat weiterzuverbreiten. Verändert er das Programm innerhalb seiner lizenzrechtlichen Befugnisse, so räumt ihm § 2 GPL für die veränderte Version ein Verbreitungsrecht ein. § 3 GPL räumt dem Nutzer auch ein Verbreitungsrecht für das Computerprogramm als Ob42 43

Vgl. § 6 III. 2. b) bb). So auch Schiffner, S. 133; Marly, Rn. 434.

12 Teupen

178

§ 6 Open Source-Lizenzen und Verwertungsrechte

jektcode oder in ausführbarer Form ein. Dabei umfasst das Verbreitungsrecht auch hier grundsätzlich das Inverkehrbringen sowie das Anbieten gegenüber der Öffentlichkeit. Der Öffentlichkeitsbegriff des § 15 III UrhG ist hier maßgeblich. Es stellt sich hier die Frage nach dem Umfang des eingeräumten Verbreitungsrechts. (a) Problem der Online-Übermittlung Open Source Software wird hautsächlich über das Internet verbreitet. Fraglich, ob auch die Online-Übermittlung eines Computerprogramms als Verbreitung i. S. v. §§ 69 c Nr. 3, 17 I UrhG einzuordnen ist und sie somit auch von der Rechtseinräumung durch die GPL gedeckt ist. Bei der OnlineÜbertragung handelt es sich um eine Übertragung des Werkes in unkörperlicher Form. Umstritten ist, ob auch die unkörperliche, elektronische Weitergabe des Werkes unter den Verbreitungsbegriff des § 17 I UrhG fällt. Die wohl überwiegende Ansicht hat den Anwendungsbereich von § 17 I UrhG auf die Verbreitung von Werkstücken in körperlicher Form beschränkt und demzufolge auch die Online-Übermittlung als Wiedergabe in unkörperlicher Form angesehen44. Nach dieser Meinung wurde dann ein unter § 15 II UrhG fallendes unbenanntes Recht der öffentlichen Wiedergabe angenommen45. Andere wollen den Fall der Online-Übertragung mit der analogen Anwendung des § 69 c Nr. 3 UrhG lösen46. Mit der Einführung des § 19 a UrhG und der damit im Zusammenhang stehenden Spezialvorschrift des § 69 c Nr. 4 UrhG dürfte dieser Streit jedoch praktisch keine Bedeutung mehr haben47. Mit § 19 a UrhG hat der Gesetzgeber im Rahmen des Gesetzes zur Regelung des Urheberrechts in der Informationsgesellschaft ein neues Verwertungsrecht eingeführt, welches Urhebern das ausschließliche Recht gibt, Werke in digitalen Netzen zum Abruf bereitzuhalten und zu übermitteln48. Dieses neue Verwertungsrecht regelt gerade den Anwendungsbereich der Nutzung von urheberrechtlich geschützten Werken in elektronischen Netzen. Speziell für Computerprogramme wurde in § 69 c Nr. 4 UrhG das Recht der öffentlichen Wiedergabe kodifiziert. Mit Einführung dieser Regelung konstatiert auch der Gesetz44

Kilian/Heussen/Hoeren, CHB Nr. 141 Rn. 12; Dreier/Schulze, § 69 c Rn. 20; Schricker/Loewenheim, § 69 c Rn. 25 mit weiteren Nachweisen. 45 Spindler, in: Spindler, Abschn. C Rn. 76; Schricker/Loewenheim, § 69 c Rn. 25 mit weiteren Nachweisen. 46 So Schiffner, S. 134 für Open Source Software. 47 So auch Kilian/Heussen/Hoeren, CHB Nr. 141 Rn. 13; Dreier/Schulze, § 69 c Rn. 20. 48 Wandtke/Bullinger/Bullinger, Ergänzungsband zum Praxiskommentar Urheberrecht, § 19 a Rn. 1.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

179

geber, dass er davon ausgeht, das in der Online-Übertragung keine Verbreitung i. S. v. § 17 I UrhG liegt49. (b) GPL und § 69 c Nr. 4 UhrG Somit ist zu prüfen, ob auch das Recht des Urhebers auf öffentliche Wiedergabe gem. § 69 c Nr. 4 UrhG von der Rechtseinräumung von Open Source-Lizenzen insbesondere der GPL mitumfasst ist. Die Frage, ob die GPL dem Nutzer das Recht auf öffentliche Wiedergabe des Computerprogramms via Internet gem. § 69 c Nr. 4 einräumt, ist umstritten. (aa) Der Meinungsstand Nach einer Ansicht umfasst das mittels der GPL eingeräumte Verbreitungsrecht auch das Recht auf öffentliche Wiedergabe des Computerprogramms im Internet50. Das wird damit begründet, dass die Übertragung von Computerprogrammen, insbesondere im Open Source Bereich, durch elektronische Netze üblich ist und dies bei Erstellung der ersten sowie zweiten Fassung der GPL bekannt war51. Weiter wird angeführt, dass auch der Sinn und Zweck der Open Source-Lizenz für diese Annahme spricht, da das Open Source Modell gerade eine schnelle und problemlose Verbreitung der Software bezweckt, was gerade online ohne kostspielige Vertriebsstruktur möglich ist52. Darüber hinaus spreche auch die Verwendung des Begriffs „distibute“ in dem amerikanischen Lizenztext der GPL dafür, von einer Rechtseinräumung i. S. d. § 69 c Nr. 4 UrhG auszugehen, da dieser Begriff im amerikanischen Copyright Act (§ 106 Abs. 3 CA 1976) eben auch die unkörperliche Verbreitung einschließt53. Die Gegenansicht widerspricht dem und will das in § 69 c Nr. 4 normierte Verwertungsrecht nicht von der Rechtseinräumung der GPL mitumfasst wissen54. Bei § 69 c Nr. 4 handle es sich um ein eigenständiges Verwertungsrecht, das nicht explizit in der GPL eingeräumt werde und nur eine extensive Auslegung des Begriffs „distribute“ zu einem andern Ergebnis führen könnte55. Auch spreche § 31 IV UrhG für diese Sichtweise, da 49

Begr. RegE BR-Drucks. 684/02, 51. Omsels, in: Festschrift für Paul W. Hertin, S. 158; Jaeger/Metzger, S. 33; Deike, CR 2003, S. 16; Marly, Rn. 436. 51 Omsels, in: Festschrift für Paul W. Hertin, S. 158. 52 Omsels, in: Festschrift für Paul W. Hertin, S. 158; Jaeger/Metzger, S. 33. 53 Jaeger/Metzger, S. 33; Omsels, in: Festschrift für Paul W. Hertin, S. 158. 54 Spindler, in: Spindler, Abschn. C Rn. 84; Wandtke/Bullinger/Grützmacher, § 69 c Rn. 61; Koch, § 9.1 Rn. 467; ders., CR 2000, S. 336; 55 Spindler, in: Spindler, Abschn. C Rn. 76. 50

12*

180

§ 6 Open Source-Lizenzen und Verwertungsrechte

die neue Nutzungsart des „making available to the public“ weiten Verkehrskreisen zur Zeit der Formulierung der GPL noch nicht bekannt war56. (bb) Stellungnahme Richtig ist, das die GPL in § 0 GPL ausdrücklich sagt, dass andere Verwertungshandlungen als, vervielfältigen, verbreiten und verändern nicht von der Rechtseinräumung erfasst sind. Das kann zunächst dafür sprechen, dass der Anwender auch kein Recht erhält, das Originalprogramm sowie daran vorgenommene Änderungen, zur öffentlichen Wiedergabe im Internet bereitzustellen. Betrachtet man im Internet die unzähligen Angebote von Open Source Software, ob in der Originalversion oder in veränderter Version, die zum Download angeboten werden, kommt man sehr in Zweifel, ob die letztgenannte Ansicht zu überzeugen vermag. Würde man dieser Ansicht folgen, wonach diese Anbieter nicht über das Verwertungsrecht gem. § 69 c Nr. 4 UrhG verfügen, läge eine Masse von Verstößen gegen die GPL, also Urheberrechtsverletzungen vor. Urheber sowie Rechteinhaber scheinen dies jedoch mit großer Gelassenheit zu verfolgen, ja sie reagieren gar nicht darauf. Nun muss zugestanden werden, dass dies allein kein überzeugendes Argument ist, denn natürlich beurteilt sich eine Urheberrechtsverletzung nicht danach, ob der Rechteinhaber sie ahndet oder nicht. (c) Open Source als bekannte Nutzungsart gem. § 31 IV UrhG Bei dem Recht der öffentlichen Wiedergabe gem. § 69 c Nr. 4 UrhG handelt es sich um ein neues Nutzungsrecht, das erst im Jahr 2003 in den urheberrechtlichen Regelungskomplex für Computerprogramme eingeführt worden ist. Nutzungsrechte, die im Zeitpunkt der Lizenzvereinbarung noch nicht bekannt sind, können gem. § 31 IV UrhG nicht wirksam eingeräumt werden57. Fraglich ist, ob dieses gesetzliche Verbot58 in diesem Zusammenhang angeführt werden kann. Zunächst bleibt anzumerken, dass die Regelung des § 13 IV UrhG Ausdruck des urheberrechtlichen Beteiligungs56

Spindler, in: Spindler, Abschn. C Rn. 76. Die Regelung des § 31 IV UrhG ist jedoch gem. §§ 132 I S. 1, 143 I UrhG nur auf Verträge anwendbar die nach dem 01. Januar 1996 abgeschlossen worden sind. Das gleiche Ergebnis wurde jedoch schon zuvor durch Anwendung des urheberrechtlichen Beteiligungsgrundsatzes, der Zweckübertragungslehre oder einer engen Vertragsauslegung hergeleitet. Vgl. dazu Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 39. 58 Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 38. 57

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

181

grundsatzes ist, wonach der Urheber angemessen an den wirtschaftlichen Früchten der Verwertung seines Werkes zu beteiligen ist59. Sinn und Zweck ist also die wirtschaftliche Partizipation des Urhebers an seiner Werkverwertung. Open Source Software wird jedoch gerade ohne die Erhebung einer Lizenzgebühr verbreitet. Der Urheber, der sich für die Verwendung einer Open Source-Lizenz entscheidet, verzichtet gerade auf eine unmittelbare wirtschaftliche Partizipation an der Werkverwertung. Trotzdem macht die Regelung des § 31 IV UrhG grundsätzlich auch im Bereich Open Source Software Sinn. Es ist durchaus vorstellbar, dass sich im Wege des technischen Fortschritts neue Verwertungsmöglichkeiten entwickeln, die aus Sicht von Urhebern für das Open Source Modell nicht zielführend sind, vielleicht sogar zu einer Gefahr des Open Source Modells werden können. In dieser Situation behalten sie ausreichend Einfluss und können im Rahmen einer Lizenzreform entscheiden, inwieweit sie auch Rechte in Bezug auf eine neue Verwertungsmöglichkeit übertragen. Insofern erscheint es verfehlt, die Regelung des § 31 IV UrhG im Bereich Open Source Software für unanwendbar zu erklären. Zu klären ist die Frage, ob die Online-Übertragung von Software oder Softwarekomponenten als Nutzungsart eingestuft werden kann, die schon im Zeitpunkt der Lizenzformulierung der GPL unbekannt war. Es könnten dann keine Nutzungsrechte wirksam eingeräumt werden, sollte die GPL in diesem Punkt nicht neu formuliert werden60. Die Entwicklung von Open Source Software ist eng mit der Entwicklung des Internets verbunden. Das Open Source Modell ist gerade im Bereich Software auf das Internet angewiesen um das Ziel der offenen und parallelen Entwicklungsweise sowie der schnellen Verbreitung erreichen zu können. Nun ist aber doch zweifelhaft, ob bei der Online-Übertragung überhaupt eine Nutzungsart vorliegt, die bei Formulierung der GPL unbekannt war. Eine Nutzungsart ist nicht bekannt, wenn sie als klar abgrenzbare, wirtschaftlich-technische Verwendungsform zum Zeitpunkt des Abschlusses des Vertrages über die Einräumung von Nutzungsrechten von einem durchschnittlichen Teilnehmerkreis der einschlägigen Fachkreise nicht erkannt werden musste61. Das Internet ist unstreitig als eine eigene neue Nutzungsart i. S. d. Vorschrift einzuordnen62. Die Frage der „Bekanntheit“ einer 59

Loewenheim/Loewenheim/Jan Bernd Nordemann, § 26 Rn. 43. Spindler hält wohl eine Neuformulierung für geboten. Vgl. Spindler, in: Spindler, Abschn. C Rn. 79. 61 BGH, GRUR 1997, S. 464 f.; BGH, GRUR 1995, S. 212, 213 f.; Kotthoff, in: HK-UrhR, § 31 Rn. 109. 62 Dreier/Schulze, § 31 Rn. 100; Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 59; Möhring/Nicolini/Spautz, § 31 Rn. 45; Schack, Rn. 551. 60

182

§ 6 Open Source-Lizenzen und Verwertungsrechte

neuen Nutzungsart ist aus Sicht des durchschnittlichen Urhebers zu beantworten, da § 31 IV UrhG seinem Schutz dient63. Es kommt auf Bekanntheit der Nutzungsart in den einschlägigen Urheber- und Fachkreisen an64. Spindler will den Bekanntheitsgrad einer Nutzungsart hingegen an der Kenntnis breiter Verkehrskreise ausmachen65. Diese Auslegung erscheint angesichts des Sinn und Zweck der Vorschrift als zu extensiv und unbestimmt. Richtig ist es, auf einschlägige Fachkreise abzustellen, in denen die Nutzung einer bestimmten Verwertungsart oft wesentlich eher bekannt und üblich ist als in breiten Verkehrskreisen. Es gilt, die Urheber in diesen Fachkreisen vor Verwertungshandlungen der Anwender dieser Fachkreise zu schützen. In der Literatur und Rechtsprechung wird im Zusammenhang mit der Internetnutzung immer auf das Jahr 1995 als den Zeitpunkt hingewiesen, ab dem sie als bekannt gelten kann66. Zweifelhaft ist, ob auch in diesem Zusammenhang auf das Jahr 1995 bzw. 199767 abgestellt werden kann. Die GPL als wohl erste Open Source-Lizenz wurde erstmals 1989 formuliert. Das Gründungsdatum des Internets wird auf 1973 datiert68. Das ARPANET, das als erstes Netz eine relativ hohe Ausdehnung erreichte69, wurde bereits Ende der 70er bis Mitte der 80er Jahre in Kreisen der ersten Open Source Softwareentwickler genutzt70. Die Open Source Urheber tauschten ihre Arbeitsergebnisse schon zu diesem frühen Zeitpunkt über digitale Netze aus. Die Entwicklung von Open Source Software verlief insofern parallel mit der Entwicklung des Internets. Den Urhebern und den einschlägigen Fachkreisen von Anwendern von Open Source Software war also schon zu einem Zeitpunkt vor 1989 der Austausch von Software über das Internet bekannt. Somit kann man die Online-Nutzung und die damit verbundene öffentliche Wieder- sowie Weitergabe von Software gerade in Bezug auf den Urheberkreis der Open Source Entwickler nicht als unbekannte Nutzungsart 63 OLG Hamburg, GRUR 2000, S. 45; Fromm/Nordemann/Hertin, §§ 31/32 Rn. 10; Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 42. 64 Möhring/Nicolini/Spautz, § 31 Rn. 42; Loewenheim/Loewenheim/Jan Bernd Nordemann, § 26 Rn. 42; Haberstrumpf, Rn. 406; Schricker/Schricker, §§ 31/32 Rn. 17. 65 Spindler, in: Spindler, Abschn. C Fn. 212. 66 OLG Hamburg, ZUM 2000, S. 870; LG München I, ZUM 2003, S. 64 ff., das die Bekanntheit des Internets zumindest für 1982 ablehnt; Wandtke/Bullinger/ Wandtke/Grunert, § 31 Rn. 60; Schack, Rn. 551; Hoeren, CR 1995, S. 713 f. 67 So Spindler, in: Spindler, Abschn. C Rn. 78. 68 Brockhaus (CIT), S. 467. 69 Brockhaus (CIT), S. 467. 70 Ausführlich dazu Weber, S. 33 ff.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

183

qualifizieren. Folglich wäre eine Einräumung eines Nutzungsrechts bezüglich der öffentlichen Wiedergabe eines Computerprogramms i. S. d. § 69 c Nr. 4 UrhG auch nicht gem. § 31 IV UrhG unwirksam. (d) Einräumung des Nutzungsrechts gem. § 69 c Nr. 4 durch die GPL Ausdrücklich ist das Recht der öffentlichen Wiedergabe eines Open Source-Computerprogramms im Internet nicht in den Open Source-Lizenzen geregelt. Die überwiegende Zahl der Open Source-Lizenzen stammen aus dem amerikanischen Rechtraum und sind folglich in englischer Sprache verfasst. Verlässt man den Bereich Software, so gibt es mittlerweile auch Open Content Lizenzen, die vor dem Hintergrund der deutschen Rechtsordnung formuliert worden sind. Als erstes wäre hier die „Lizenz für freie Inhalte“ des Kompetenznetzwerks Universitätsverbund MultiMedia NRW zu nennen71. In dem deutschsprachigen Lizenztext in der Version 1.0 vom Mai 2003 erhält der Nutzer beispielweise in Ziffer 2 a/b ausdrücklich das Recht zur öffentlichen Wiedergabe in elektronischen Netzen. Nun hilft das bei der hier zu behandelnden Frage nicht weiter. Der GPL-Lizenztext gibt eine ausdrückliche Rechtseinräumung nicht her. Die GPL wie auch andere Open Source-Lizenzen, sprechen, soweit sie aus dem amerikanischsprachigen Rechtsraum stammen, im Zusammenhang mit dem Verbreitungsrecht von „distribution“. Im amerikanischen Copyright Act wird der Begriff „distribute“ weit ausgelegt und umfasst die Verbreitung körperlicher sowie unkörperlicher Vervielfältigungsstücke72. Spindler weist jedoch darauf hin, dass aufgrund des Schutzlandprinzips nicht „allein“ auf ein amerikanisches Verständnis des Begriffs abgestellt werden kann73. Dem ist zuzustimmen, denn es geht ja um das UrhG und nicht um den Copyright Act. Selbst wenn man aber den Begriff „distribute“ vor dem Hintergrund des deutschen Urheberrechts übersetzt (distribute= etw. verteilen; verbreiten) kommt man nicht zu einem ausdrücklichen Recht der Online-Wiedergabe von Open Source Software. Die von Omsels angeführte Tatsache, dass der Begriff keine Beschränkung auf die Verbreitung von Software auf Datenträger enthält, kann nicht einfach in die ausdrückliche Einräumung eines Rechts gem. § 69 c Nr. 4 UrhG umgedeutet werden. Die Formulierung der GPL reicht somit nicht aus, um von einer ausdrücklichen Rechtseinräumung sprechen zu können. 71

Die Lizenz ist abrufbar unter: http://www.uvm.nrw.de/kunden/uvm/www.nsf/ 0/3740C87933C28B42C1256D36004A96A9?OpenDocument&knotenid=K0400. Das Kompetenznetzwerk Universitätsverbund MultiMedia NRW ist mittlerweile das CeC Centrum für eCompetence in Hochschulen NRW. 72 Jaeger/Metzger, S. 33. 73 Spindler, in: Spindler, Abschn. C Rn. 76.

184

§ 6 Open Source-Lizenzen und Verwertungsrechte

Es kommt aber eine Einräumung eines entsprechenden Nutzungsrechts gemäß der in § 31 V UrhG formulierten Zweckübertragungsregel in Betracht. § 31 I UrhG enthält eine Auslegungsregel dahingehend, dass sich die Frage des Umfangs der Rechtseinräumung nach dem von den Parteien zugrunde gelegten Vertragszweck bestimmen, sofern die Nutzungsrechte nicht ausdrücklich bezeichnet sind. Ergänzend dazu sind die allgemein privatrechtlichen Auslegungsregeln der §§ 133, 157 BGB heranzuziehen74. Im Rahmen von § 31 I UrhG ist jedoch hinsichtlich der Auslegung zu beachten, dass diese restriktiv vorzunehmen ist und im Zweifel die Rechte beim Urheber verbleiben75. Schweigt also der Nutzungsvertrag, in diesem Fall die GPL, zu der Frage, ob das eingeräumte Verbreitungsrecht auch das Recht der öffentlichen Wiedergabe umfasst, so kann nach dieser Auslegungsregel davon ausgegangen werden, dass dem Anwender diejenigen Nutzungsarten eingeräumt werden, welche zur Erreichung des Vertragszwecks nötig sind76. Urheber, die ihre schutzfähigen Programmierergebnisse unter eine Open Source-Lizenz stellen, bezwecken eine schnelle und weite Verbreitung des Programms verbunden mit der Animation gegenüber anderen Programmierern die Qualität und Funktionsweise des Programms durch das hinzufügen eigener Verbesserungsprogrammierungen zu verbessern. Damit verbunden ist auch der eigene Nutzen sowie der Nutzen der Open Source Entwicklungsgemeinde von den gegenseitigen Verbesserungen und Optimierungen selbst profitieren zu können. Vertragszweck ist aber auch, dass für die breite Öffentlichkeit ein umfangreiches Angebot von Open Source Software neben proprietären Computerprogrammen ohne kostspielige Vertriebswege für den Anwender entsteht. Das Entwicklungs-, sowie Verbreitungsziel lässt sich nur dann optimal erreichen, wenn auch eine Verbreitung in unkörperlicher Form via Internet von der Rechtseinräumung mitumfasst ist. Denn erst die Nutzung des Internets macht das Open Source Modell attraktiv und voll funktionsfähig. In diesem Zusammenhang bedarf es auch keines besonderen Schutzes des Urhebers durch eine zu restriktive Auslegung. Es ist richtigerweise von einer weiten Nutzungsrechtseinräumung auszugehen. Der Urheber will ja gerade die schnelle Verbreitung. Zu seinem Schutz hat er das Verbreitungsrecht mit Bedingungen und Verpflichtungen versehen. Es ist somit auch gar nicht vorstellbar, was der Urheber gegen eine Einräumung des Rechts auf öffentliche Wiedergabe vorbringen könnte. Die Auslegung im Lichte des Open Source Modells und der zugrunde liegenden Definitionen führt dazu, von der Einräumung eines Nutzungsrechts gem. § 69 c Nr. 4 UrhG auszugehen. Der Anwender erhält auf74

Dreier/Schulze, § 31 Rn. 107. Dreier/Schulze, § 31 Rn. 114. 76 Vgl. auch BGH, GRUR 1974, S. 480, 483; BGH, GRUR 1981, S. 196, 197; BGHZ 24, 55, 70 ff. 75

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

185

grund der Zweckübertragungsregel damit auch das Recht, das Originalprogramm sowie veränderte Versionen via Internet öffentlich wiederzugeben. (e) Zwischenergebnis Der Umfang des in der GPL eingeräumten Verbreitungsrechts umfasst demnach auch das Recht auf öffentliche Wiedergabe gem. § 69 c Nr. 4 UrhG. (f) Vermietrecht Im Zusammenhang mit dem Verbreitungsrecht stellt sich die Frage, ob dem Anwender regelmäßig auch das Vermietrecht gem. §§ 17 III, 69 c Nr. 3 UrhG eingeräumt wird. Auch diese Frage ist im Bereich der Open Source Software umstritten. (aa) Meinungsstand Einer Meinung nach, umfasst die Einräumung des Verbreitungsrechts auch das Vermietrecht77. Dabei wird auch in diesem Zusammenhang das weite Verständnis des Begriffs „distribution“ in der GPL angeführt. Darüber hinaus wird argumentiert, dass die GPL eine einfache und weitgehende Verbreitung des jeweiligen Computerprogramms bezweckt und somit auch das Vermietrecht vom Umfang des Verbreitungsrechts gedeckt sei. Die Gegenauffassung lehnt die Einräumung eines Vermietrechts durch die GPL ab78. Hiernach stellt das Vermietrecht nach allgemeinen urheberrechtlichen Grundsätzen eine eigenständige Nutzungsart dar, die jedoch nicht ausdrücklich durch die GPL eingeräumt wird. Die Einräumung eines Verbreitungsrechts umfasse nicht automatisch auch die Einräumung eines Vermietrechts. Ferner schließe die GPL eine entgeltliche Programmüberlassung aus, was aber gerade bei der Vermietung der Fall wäre. (bb) Stellungnahme Wie bereits in den oben gemachten Ausführungen erwähnt, ist es richtig, dass die GPL in § 0 GPL den Umfang der Rechtseinräumung dahingehend ausdrücklich festlegt, dass die Vornahme anderer Handlungen als vervielfäl77

Jaeger/Metzger, S. 33; Marly, Rn. 483. Spindler, in: Spindler, Abschn. C Rn. 80 f.; Koch, § 9.1 Rn. 464; ders., CR 2000, S. 335; Wandtke/Bullinger/Grützmacher, § 69 c UrhG Rn. 61. 78

186

§ 6 Open Source-Lizenzen und Verwertungsrechte

tigen, verbreiten oder verändern nicht von der Rechtseinräumung erfasst sind. Ein sprachlicher Hinweis, dass auch die Vermietung mitumfasst sein soll, findet sich nicht unmittelbar. Es ist aber fraglich, ob nicht der Begriff „distribute“ im Wege der Auslegung zu der Einräumung des Vermietrechts führt. Dass es sich bei dem Vermietrecht um ein selbstständiges Verwertungsrecht handle und somit auch nicht vom Verbreitungsrecht mitumfasst sei, ist dogmatisch nicht begründbar. Das Vermietrecht ist vielmehr Teil des Verbreitungsrechts. Die Vermietung ist eine Verbreitung im Sinne einer vorübergehenden Besitzüberlassung79. Für das Verbreiten reicht jede Besitzüberlassung aus, insbesondere auch die Vermietung80. Ist das Vermietrecht aber Teil des Verbreitungsrechts stellt sich die Frage, ob nicht auch die GPL die Vermietung des Open Source-Computerprogramms erlaubt. Vermietung ist die zeitweilige Gewährung des Gebrauchs einer Sache durch Vertrag gegen Entgelt81. Dass die Vermietung eine entgeltliche Gebrauchsüberlassung ist, die zudem zeitlich begrenzt ist, wirkt auf den ersten Blick unvereinbar mit der GPL. Die GPL untersagt in § 2 b GPL ja gerade ausdrücklich die Verbreitung gegen Entgelt, soweit das Entgelt eine Lizenzgebühr darstellt. Die Unentgeltlichkeit der Lizenz ist das Wesensmerkmal von Open Source Software. Deshalb lehnen einige auch die Einräumung des Vermietrechts durch die GPL ab82. Übersehen wird hierbei jedoch die Tatsache, dass sich die Unentgeltlichkeit allein auf die Rechtseinräumung bezieht. Die GPL erlaubt ja auch, für reine Kopiervorgänge oder das Angebot einer Kopie ein Entgelt zu nehmen. Sie stellt somit klar, dass sehr wohl für Zusatzdienstleistungen rund um die kostenfreie Lizenzerteilung gegen Entgelt erbracht werden dürfen. Nichts anderes stellt aber doch die Vermietung von Open Source Software dar. Praktisch gesehen erscheint zunächst die Vermietung von Open Source Software als wirtschaftlich aussichtsloses Unterfangen, besteht doch für den Anwender regelmäßig die Möglichkeit, die Programme zumindest kostenlos über das Internet zu beziehen. Genauer betrachtet bietet aber auch die Vermietung eine Möglichkeit, Open Source Software zu kommerziellen Zwecken einzusetzen. So besteht die Möglichkeit, dass ein Anbieter die jeweilig aktuellsten Versionen eines Open Source-Computerprogramm zur Vermietung anbietet und das Angebot mit Zusatzleistungen wie kompatibler Sekundärsoftware, laufenden Aktualisierungen, Support etc. anbietet. Der Anwender zahlt hier für Zusatzdienstleistungen und nicht für die rein lizenzrechtliche Nutzung des Open Source79 Wandtke/Bullinger/Heerma, § 17 Rn. 20; Dreier/Schulze, § 17 Rn. 41; Schricker/Loewenheim, § 17 Rn. 17; Marly, Rn. 438. 80 BGH, GRUR 1987, S. 37 f.; BGH, GRUR 1986, S. 736. 81 Eckert in HK-BGB, Vor §§ 535–580 a Rn. 2. 82 Spindler, in: Spindler, Abschn. C Rn. 80 f.; Koch, § 9.1 Rn. 464; ders., CR 2000, S. 335; Wandtke/Bullinger/Grützmacher, § 69 c UrhG Rn. 61.

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

187

Programms83. Dies steht nicht im Widerspruch zur kostenlosen Nutzungsrechtseinräumung durch die GPL. Vielmehr entspricht es dem Sinn und Zweck des Open Source-Modells, wenn auch die Vermietung von der Rechtseinräumung erfasst wird. So ergibt sich beispielsweise für neue Interessenten die Möglichkeit, das Open Source-Computerprogramm zu nutzen und eventuelle Risiken wie Funktionsstörungen des Programms, fehlende Betreuung oder andere Risiken durch den Abschluss eines Mietvertrages abzudecken. Ein sicherer Einstieg in die Open Source-Softwarenutzung kann so ermöglicht werden. Hierdurch wird auch die gewünschte Verbreitung der Software gefördert. So mehr Geschäftsmodelle die GPL ermöglicht, umso interessanter wird das Open Source-Modell. Folglich ist auch das Vermietrecht durch die Einräumung des Verbreitungsrechts eingeschlossen. (g) Application Service Providing von Open Source Software Unter dem Begriff „Application Service Providing84“ (kurz: ASP) versteht man das Zur-Verfügung-Stellen von Anwendungsprogrammen über das Internet oder ein unternehmensgebundenes Intranet, wobei das Programm als solches nicht direkt auf der Arbeitsstation des Anwenders abläuft, sondern auf einem Zentralserver85. Innerhalb dieses IT-Outsourcing-Modells wird das Programm im Wege des sog. Remote Access genutzt. Der ASP-Anbieter veräußert die Software also nicht an den Kunden, sondern pflegt die Zugriffsmöglichkeit und die IT-Infrastruktur rund um die Software. Dafür enthält er i. d. R. eine monatliche Pauschale, die abhängig von der Nutzungsintensität ist. Nutzt ein Anwender die Software im Wege des ASP, läuft lediglich die Benutzeroberfläche auf seiner Arbeitsstation ab, wohingegen das Programm als solches auf einem externen Server abläuft. Die Software wird insofern nicht als Ganzes auf einer Arbeitsstation genutzt. Fraglich ist, ob die dafür notwendige Rechtseinräumung von der GPL gedeckt ist. Aus urheberrechtlicher Sicht ist umstritten, ob es sich bei ASP um eine Vermietung i. S. d. § 69 c Nr. 3 UrhG handelt oder ob eine Verwertungsart gem. §§ 69 c Nr. 4, 19 a UrhG anzunehmen ist86. Das Vermietrecht sowie das Recht gem. § 69 c Nr. 4 UrhG sind grundsätzlich von der Rechtseinräumung der GPL gedeckt. Das könnte zunächst 83

So auch Marly, Rn. 439. Dt. = Bereitstellung für Anwendungsprogramme. 85 Ausführlich dazu Schneider, HER, Abschn. M Rn. 25 ff.; Moritz/Dreier/Wächter, E-Commerce, Abschn. D Rn. 751; Kilian/Heussen/Moritz, CHB, Nr. 31 Rn. 182; Bettinger/Scheffelt, CR 2001, S. 729 ff. 86 Spindler, in: Spindler, Abschn. C Rn. 84; Jaeger/Metzger, S. 34. 84

188

§ 6 Open Source-Lizenzen und Verwertungsrechte

dafür sprechen, dass die ASP-Nutzung als eine Art Kombination von Vermietung und öffentlicher Wiedergabe folglich auch von der Rechtseinräumung gedeckt ist. Hier muss aber bedacht werden, dass ASP eine völlig neue Form der Softwarenutzung darstellt. Ob die oben erwähnte „geteilte“ Programmnutzung von der GPL gedeckt ist, erscheint somit zweifelhaft. Wenn es sich bei ASP um eine unbekannte Nutzungsart gem. § 31 IV UrhG handelt, umfasst die Rechtseinräumung, unabhängig ihrer urheberrechtlichen Qualifizierung, jedenfalls keine Nutzung der Software im Rahmen von ASP. Dann ist auch der Meinungsstreit um die rechtliche Qualifizierung ohne Belang. Die Nutzung von Software in Form von ASP kann als neue Nutzungsart angesehen werden, die sich erst in den letzten Jahren etabliert hat (Mitte bis Ende der 90er Jahre)87. Jedenfalls war diese Nutzungsart bei Formulierung der GPL noch nicht bekannt. Das führt dazu, dass bei Verwendung der GPL die interaktive Nutzung von Software innerhalb von Computernetzwerken sowie ASP-Angeboten gem. § 31 IV UrhG nicht von der Rechtseinräumung gedeckt ist88. Jaeger/Metzger wollen die fehlende Rechtseinräumung auf Software beschränken, die vor dem Zeitpunkt des Bekanntwerdens der neuen Nutzungsart unter der GPL lizenziert worden ist89. Aber auch diese Sichtweise erscheint angesichts der Lizenzentwicklung im Bereich Open Source Software zweifelhaft. Gegen diese Auffassung spricht die Affero General Public License (AGPL)90. Diese relativ neue Lizenz aus dem Jahr 2002 ist eine modifizierte Version der GPL und ist zu dem Zweck formuliert worden, die Nutzung von Open Source Software über Computernetzwerke zu regeln91. Aufbau und Inhalt der Lizenz sind mit dem der GPL nahezu identisch. Nur ist sie speziell für die interaktive Programmnutzung innerhalb von Computernetzwerken und ASP-Angeboten gemacht worden und enthält in § 2 d AGPL die entsprechende Regelung für die interaktive Nutzung. Diese Entwicklung zeigt deutlich, dass eine ASP-Nutzung von Open Source Software unter der GPL unabhängig vom Zeitpunkt der Lizenzierung als urheberrechtlich problematisch angesehen wurde. Vielmehr sah man aufgrund der Entwicklung dieses neuen Anwendungsfeldes die Notwendigkeit einer neuen Lizenz, die genau diese neue Nutzungsart berücksichtig. 87

Spindler, in: Spindler, Abschn. C Rn. 85. Spindler, in: Spindler, Abschn. C Rn. 85. 89 Jaeger/Metzger, S. 34. 90 Version 1 von März 2002, http://www.affero.org/oagpl.html. 91 Vgl. auch die Pressemitteilung der FSF vom 19. März 2002: http://www.fsf. org/press/2002-03-19-Affero.txt. 88

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

189

Die GPL räumt dem Anwender folglich kein Recht auf Nutzung des jeweiligen Computerprogramms im Wege des ASP ein. Will ein Urheber diese Nutzungsmöglichkeit einräumen, gibt ihm jedoch mittlerweile die AGPL die entsprechende Möglichkeit.

(2) Pflichten und Bedingung Auch die Einräumung des Verbreitungsrechts ist mit der Befolgung von Pflichten und der Einhaltung bestimmter Bedingungen verbunden. Die Bedingungen richten sich grundsätzlich danach, ob das Programm in unveränderter oder veränderter Form verbreitet wird. Der Anwender darf gem. § 1 GPL das unveränderte Programm in Form des Quellcodes verbreiten, soweit er das Programm mit einem unübersehbaren und angemessenen Hinweis auf das bestehende Urheberrecht und den Garantie- und Haftungsausschluss versieht. Darüber hinaus muss er alle bereits bestehenden Vermerke dieser Art unverändert lassen. Verbreitet er das Programm, muss er den Empfängern gem. § 1 GPL eine Kopie dieser Lizenz zukommen lassen. Verändert der Anwender das Computerprogramm, so darf er dies nur unter den Voraussetzungen des § 2 GPL verbreiten. Er muss gem. § 2 a GPL die veränderte Version mit einem Vermerk versehen, die auf die von ihm vorgenommene Modifizierung und das Datum einer jeden Änderung hinweist. Ferner, so bestimmt § 2 b GPL, muss er dafür Sorge tragen, dass die Verbreitungsversion dem Dritten als Ganzes unter den Bedingungen der GPL und ohne die Erhebung von Lizenzgebühren zur Verfügung gestellt wird. Bearbeitungen müssen also zum Zweck der Weiterverbreitung wieder unter die GPL gestellt werden. Wird ein Computerprogramm verbreitet, das bei der Ausführung interaktiv Kommandos einliest, muss dafür Sorge getragen werden, dass bei Start eine Meldung ausgibt oder ausdruckt, die einen Hinweis auf das Urheberrecht und den Haftungs- und Garantieausschluss enthält. Auch muss ein Hinweis auf das Recht erfolgen, dass die Benutzer das Programm unter den Bedingungen der GPL weiterverbreiten dürfen. Die Frage, wann eine Bearbeitung eines Computerprogramms vorliegt, ist hier genau zu untersuchen. Es gelten hier die bereits dargestellten urheberrechtlichen Grundsätze. Das Programm in Form des Objektcodes oder in ausführbarer Form darf unter den Voraussetzungen von §§ 1, 2 GPL verbreitet werden, wenn die Anforderungen gem. § 3 GPL erfüllt sind. § 3 GPL erhält zusätzlich die Anforderung, dem Dritten den vollständigen maschinenlesbaren Quelltext des Computerprogramms in einer der dort genannten Alternativen zur Ver-

190

§ 6 Open Source-Lizenzen und Verwertungsrechte

fügung zu stellen. Dies ist allein schon deshalb wichtig, da ein Dritter nur bei Kenntnis des Quelltextes die Funktionsweise eines Programms verstehen und Veränderungen vornehmen kann. Da ihm die GPL dieses Veränderungsrecht einräumt, muss er auch Zugang zum Quelltext haben. Abschließend bleibt festzuhalten, dass die normierte Verpflichtung zur unentgeltlichen Weiterverbreitung die wohl bedeutendste Einschränkung des Verbreitungsrechts darstellt. (3) Problem der Erschöpfung bei der Verbreitung von Open Source Software Das ausschließliche Verbreitungsrecht des Urhebers findet seine Beschränkung in dem Erschöpfungsgrundsatz, der in § 17 II UrhG und speziell für Computerprogramm in § 69 c Nr. 3 UrhG normiert ist. An dieser Stelle soll allerdings noch nicht auf die urheberrechtlichen Auswirkungen des gesetzlich verankerten Erschöpfungsgrundsatzes für die Verbreitung von Open Source Software eingegangen werden. Hierfür ist es sinnvoll, zuvor die Fragen nach der dogmatischen Verknüpfung von Rechtseinräumung und den lizenzrechtlichen Bedingungen und Nutzerpflichten zu behandeln. Somit folgen die Ausführungen zum Erschöpfungsgrundsatz in Kapitel H. cc) Das Veränderungsrecht gem. §§ 69 c Nr. 2, 23 UrhG (1) Befugnisse des Nutzers Die GPL räumt dem Anwender gem. § 2 GPL ein umfassendes Bearbeitungsrecht ein92. Der Anwender darf seine Programmkopie oder Teile davon in beliebiger Weise verändern. Das Bearbeitungsrecht umfasst dabei das Programm im Quellcode sowie Objektcode. Insofern erhält der Anwender das Nutzungsrecht aus § 69 c Nr. 2 UrhG93. Soweit er die Bearbeitungen verbreiten will, muss er die oben genannten Bedingungen erfüllen.

92

Schiffner, S. 142 ff. § 69 c Nr. 2 UrhG ist lex spezialis zu § 23 UrhG und insofern strenger, als bereits für die Vornahme der Bearbeitung als solcher die Zustimmung des Rechtsinhabers notwendig ist. § 23 UrhG verlangt die Zustimmung erst, wenn die Bearbeitung veröffentlicht oder anderweitig verwertet wird. 93

III. Verwertungsrechte in Open Source Softwarelizenzverträgen

191

(2) Pflichten und Bedingungen Der Nutzer darf das Programm grundsätzlich bearbeiten und verändern, ohne dafür bestimmte Bedingungen zu erfüllen. Solange er das Programm allein nutzt und Bearbeitungen nicht an Dritte weitergegeben werden, würde die Einhaltung von Bedingungen und Pflichten auch keinen Sinn machen. Erst wenn er seine Bearbeitung, also seine veränderte Programmversion oder geänderte Programmteile verbreiten möchte, hat er die in Verbindung mit dem Verbreitungsrecht angesprochenen Bedingungen gem. § 2 a–c GPL einzuhalten. Wichtig ist zunächst, dass der Nutzer, der die Software verändert gem. § 2 a GPL, einen auffälligen Vermerk erstellt, der die vorgenommen Änderungen und Modifizierungen protokolliert und das Datum der Änderung festhält. Die für das Copyleft-Modell wohl bedeutendste Regelung findet sich im Zusammenhang mit der Programmbearbeitung in § 2 b GPL. Der Nutzer wird dazu verpflichtet, jedes durch ihn veröffentlichte oder verbreitete Programmierergebnis, das ganz oder teilweise von dem Open Source Ursprungsprogramm stammt, Dritten gegenüber nur unter den Bedingungen der GPL und unentgeltlich zur Verfügung zu stellen. Diese „Grundregel“ des Copyleft-Modells94 stellt sicher, dass auch Veränderungen, die auf einer Open Source Software aufbauen und erst durch das Vorhandensein der offenen Programmversion ermöglicht wurden, selbst frei im Sinne des Open Source Verwertungsmodells bleiben. Die veränderte Version muss darüber hinaus gem. § 2 c GPL bei Ablauf auf einer Arbeitsstation eine Meldung ausgeben, die einen entsprechenden Copyright-Vermerk enthält und auf den Gewährleistungs- und Haftungsausschluss hinweist. Die Pflichten im Rahmen einer Veränderung treffen den Nutzer nur in den Fällen, in denen er die Veränderungen veröffentlicht oder verbreitet. Hier ist im Einzelfall genau zu untersuchen, wann eine Veröffentlichung oder eine Verbreitung im urheberrechtlichen Sinne vorliegt. Die GPL enthält hiezu keine Legaldefinitionen95. Somit sind die Regelungen des UrhG (§§ 15 II, 17 I UrhG) für die Klärung der entsprechenden Rechtsfragen heranzuziehen.

94 95

So Jaeger/Metzger, S. 37. Jaeger/Metzger, S. 39.

192

§ 6 Open Source-Lizenzen und Verwertungsrechte

(3) Kollision der Veränderungsfreiheit mit Urheberpersönlichkeitsrechten Im Rahmen der Veränderungsfreiheit kann es, wie auch in Fällen außerhalb des Softwarerechts, zu Kollision mit Urheberpersönlichkeitsrechten kommen. Eine Veränderung kann grundsätzlich zu einer Entstellung des Werkes führen. Der Urheber erfährt in diesen Fällen Schutz durch das in § 14 UrhG verankertes Recht, eine etwaige Entstellung oder Beeinträchtigung des Werkes zu verbieten. Dieses Recht schützt den Bestand einer konkreten Form des Werkes und des darin zum Ausdruck kommenden geistigästhetischen Gesamteindrucks96. Dieses Urheberpersönlichkeitsrecht gilt auch für urheberrechtlich geschützte Computerprogramme. Auf Urheberpersönlichkeitsrechte kann nicht verzichtet werden, sie unterliegen somit auch nicht der Disposition von Vertragsparteien. Gerade Urheber von Open Source Software haben grundsätzlich ein Interesse auf Anerkennung ihrer Programmierergebnisse. Sie wollen grundsätzlich verhindern, dass ihr Grundwerk durch etwaige Änderungsprogrammierungen, die technisch in irgendeiner Form abträglich sind, in Verruf kommt97. Somit haben auch sie ein Interesse am Schutz des Werkes durch § 14 UrhG. Die Veränderungsfreiheit ist somit nicht grenzenlos. Die Urheber von Open Source Software behalten neben der Einräumung eines umfassenden Bearbeitungsrechts eine Einflussmöglichkeit. Sie können folglich trotz Geltung der GPL gem. § 14 UrhG Bearbeitungen an einem Computerprogramm verbieten, sofern ihr Urheberpersönlichkeitsrecht verletzt ist. Einer möglichen Gefährdung der Reputation eines Softwareprojektes durch unzulängliche und nachteilige Veränderungsprogrammierungen wird oft dadurch vorgebeugt, dass im Bereich Open Source Software offiziell freigegebene Programmversionen durch bestimmte Open Source Organisationen freigegeben werden. So gibt es in Organisationen wie der Free Software Foundation-Gremien, die über die Aufnahme von Erweiterungs- und Veränderungsprogrammierungen in deren offizielle Version beraten und schließlich entscheiden. Auf diesem Weg lässt sich die Gefahr eines Reputationsverlustes zumindest deutlich begrenzen. Die GPL bannt die Gefahr von möglichen Persönlichkeitsverletzungen durch die Verbreitung „qualitativ abträglicher Versionen“ durch die Regelung in § 2 a GPL, wonach Veränderungen deutlich als solche zu kennzeichnen und zu dokumentieren sind. Somit sind letztlich nur sehr seltene Fallgestaltungen denkbar, in denen die Veränderungsfreiheit eine Begrenzung durch § 14 UrhG erfährt. 96 97

Dreier/Schulze, § 14 Rn. 1. So auch Jaeger/Metzger, S. 35.

§ 7 Rechtliche Dogmatik des Copyleft-Modells I. Einleitung Das Copyleft-Modell baut auf der Einräumung von Nutzungsrechten auf, die gleichzeitig an die Einhaltung bestimmter Pflichten und Bedingungen geknüpft sind. Das Open Source-Modell kann nur dann bestehen, wenn rechtlich gewährleistet werden kann, dass auch die mit der Rechtseinräumung einhergehenden Verpflichtungen des Lizenznehmers eingehalten werden. Hier stellt sich die zentrale Frage nach der dogmatischen Verknüpfung zwischen den Rechten und Pflichten des Lizenznehmers. Die deutsche Rechtsordnung bietet mehrere Lösungsansätze für eine Verknüpfung von Rechten und Pflichten in Lizenzverträgen.

II. Lösungsmodelle 1. Schuldrechtliche Lösung Eine Verknüpfung von Rechten und Pflichten in Open Source-Lizenzen lässt sich zunächst rein schuldrechtlich konstruieren. Im Vergleich zu der Einräumung von Nutzungsrechten bietet das Schuldrecht vielfältige Möglichkeiten, vertragliche Bedingungen zu formulieren und so dem Willen der Parteien am ehesten nachzukommen. Danach ist daran zu denken, dass die Einhaltung von Pflichten und Bedingungen lediglich schuldrechtlich zwischen Lizenzgeber und Lizenznehmer vereinbart wird. Omsels geht davon aus, dass eine Verletzung von den in der GPL aufgeführten Bedingungen nicht zu einer Verletzung des Ausschließlichkeitsrechts des Rechteinhabers führt. Die Verletzung von Pflichten und Bedingungen der GPL sei vielmehr rein schuldrechtlicher Natur1. Eine Verletzung dieser Bedingungen führt seiner Meinung nach allein zu vertraglichen, nicht aber zu gesetzlichen Ansprüchen2. Fraglich ist, ob die schuldrechtliche Qualifizierung der Verknüpfung von Rechten und Pflichten in der GPL überzeugen kann. 1 2

Omsels, in: Festschrift für Paul W. Hertin, S. 156. Omsels, in: Festschrift für Paul W. Hertin, S. 156.

13 Teupen

194

§ 7 Rechtliche Dogmatik des Copyleft-Modells

Als Argument hiergegen wird oft angeführt, dass es bei Open Source Software im Rahmen der Verbreitung nicht zu Verwertungsketten kommt und es bei der schuldrechtlichen Lösung zu einem unübersehbaren Vertragsgeflecht kommen würde3. Dem ist insofern zuzustimmen, als dass der Urheber bei zunehmender Verbreitung seine vertraglichen Beziehungen nicht mehr überblicken könnte und er im Falle einer Vertragsverletzung praktisch nicht mehr in der Lage wäre, entsprechende Ansprüche gegen den jeweiligen Vertragspartner geltend zu machen. Da es im Bereich von Open Source Software in der Regel zu keinem persönlichen Kontakt zwischen Rechteinhaber und Nutzer kommt, kennt der Rechteinhaber seine Vertragspartner in der Regel nicht. Damit würde eine rein schuldrechtliche Lösung bereits an praktischen Schwierigkeiten scheitern. Nun besteht trotz dieser praktischen Bedenken die Möglichkeit, dass die Parteien die Einhaltung bestimmter Pflichten schuldrechtlich miteinander vereinbaren und in Fällen einen Rückfall der Rechte an den Lizenzgeber festlegen4. Hier tritt aber ein rechtliches Problem in den Mittelpunkt der Betrachtung. Die Verletzung schuldrechtlicher Beschränkungen ist grundsätzlich urheberrechtlich nicht relevant. Es liegt bei einem Verstoß keine Urheberrechtsverletzung vor5. Die Nichteinhaltung schuldrechtlicher Beschränkungen berührt demnach nicht die eingeräumten Nutzungsrechte, sondern stellt eine Vertragsverletzung dar, die nicht gegenüber Dritten wirkt6. Schuldrechtliche Einschränkungen binden eben nur den jeweiligen Vertragspartner. Im Rahmen von Open Source-Lizenzen wird jedoch gerade eine dingliche Wirkung der Verknüpfung von Rechten und Pflichten dahingehend bewirkt, dass bei Verstoß gegen die statuierten Pflichten die durch die Lizenz eingeräumten Rechte automatisch an den Urheber zurückfallen7. Für dieses Verständnis spricht auch der klare Wortlaut des Ziff. 4 GPL, der von einem automatischen Rückfall der Rechte spricht, sofern die Pflichten oder Bedingungen nicht eingehalten werden. Der Nutzer soll hier gerade jegliche Verfügungsmöglichkeit über die Software verlieren. Nicht zivilrechtliche Ansprüche, sondern der Verlust aller zuvor eingeräumten Verwertungsrechte sollen Folge eines Verstoßes sein. Dem Verletzer soll keine Verfügungsmöglichkeit verbleiben. Dies spricht gegen eine rein schuldrechtliche Qualifizierung der Verknüpfung. 3

Schiffner, S. 153. BGH, CR 2000, S. 653; Spindler, in: Spindler, Abschn. C Rn. 28 mit weiteren Nachweisen. 5 Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 7, 33. 6 BGH, GRUR 1992, S. 310 f.; Wandtke/Bullinger/Wandtke/Grunert, § 31 Rn. 7. 7 Schiffner, S. 152; Spindler, in: Spindler, Abschn. C Rn. 29; Jaeger/Metzger, S. 38. 4

II. Lösungsmodelle

195

Eine schuldrechtliche Lösung der Frage nach der Verknüpfung von Rechten und Pflichten in Open Source-Lizenzen ist daher zu Recht abzulehnen8. 2. Schenkung unter Auflage gem. §§ 516, 525 BGB Bei der Frage nach einem Lösungsmodell für die Verknüpfung von Rechten und Pflichten innerhalb von Open Source-Lizenzen könnte man auch von einer Schenkung unter Auflage ausgehen. Wie sich noch im Zusammenhang mit der vertraglichen Einordnung von Open Source-Lizenzen zeigen wird, wird die vertragliche Beziehung zwischen Rechteinhaber und Nutzer von Teilen der Literatur als Schenkung gem. § 516 BGB qualifiziert. Gem. § 525 I BGB kann der Schenker bei einer Schenkung unter Auflage dann die Vollziehung der Auflage verlangen, wenn er seinerseits geleistet hat. Es erscheint fraglich, ob dieser Lösungsweg geeignet ist, eine Verknüpfung von Rechten und Pflichten bei Open Source-Lizenzen zu erreichen. Die Frage, ob der Einräumung von Nutzungsrechten eine Schenkung gem. § 516 BGB zugrunde liegt, kann zumindest in diesem Zusammenhang unbeantwortet bleiben, wenn schon andere Anhaltspunkte gegen eine solche Lösung sprechen. Der Annahme, dass man die Pflichten und Bedingungen in der GPL grundsätzlich als Auflage i. S. d. § 525 I BGB einordnen kann, steht nichts entgegen. Eine Auflage ist die einer Schenkung hinzugefügte Bestimmung, dass der Empfänger zu einem Tun oder Unterlassen verpflichtet sein soll, die aus dem Verfügungsgegenstand selbst zu entnehmen ist9. Dies ist auch dahingehend möglich, dass der Versprechensempfänger lediglich in der freien Verfügung über den Gegenstand beschwert werden soll10. Inhalt der Auflage kann jede Leistung in der Form eines Tun oder Unterlassens sein11. So verhält es sich aber gerade mit den Pflichten und Bedingungen, wie sie in der GPL festgelegt sind. Es handelt sich um Bestimmungen, die den Lizenznehmer zu bestimmten Handlungen oder Unterlassungen anhalten, will er die Software rechtmäßig, d. h. den Lizenzbetstimmungen entsprechend benutzen. Hinsichtlich der freien Nutzung des Computerprogramms durch die GPL ist er insofern beschwert. Er wird sowohl zum Unterlassen bestimmter Handlungen (z. B. der Weitergabe der Software gegen Lizenzgebühren) sowie zur Vornahme bestimmter Handlungen (z. B. zur Weitergabe der Software nur in Verbindung mit der entsprechenden Open Source8 Schiffner, S. 153; Spindler, in: Spindler: Abschn. C Rn. 28; Spindler/Wiebe, CR 2003, S. 874; Jaeger/Metzger, S. 38. 9 Palandt/Weidenkaff, § 525 Rn. 1. 10 Palandt/Weidenkaff, § 525 Rn. 1. 11 Palandt/Weidenkaff, § 525 Rn. 1. 13*

196

§ 7 Rechtliche Dogmatik des Copyleft-Modells

Lizenz) angehalten. Die Pflichten sowie Bedingungen können somit als Auflage i. S. v. § 525 BGB qualifiziert werden. Die Einordnung als Schenkung unter Auflage scheitert allerdings unter einem anderen Gesichtspunkt. Die Intention der Rechteinhaber ist gem. Ziff. 4 GPL ein automatischer Rechterückfall für den Fall eines Lizenzverstoßes. Dies kann allerdings ein Lösungsweg über die Schenkung unter Auflage nicht realisieren. § 527 BGB macht deutlich, dass der Schenker nach Erbringung seiner Leistung einen Anspruch auf Vollziehung der Auflage hat, die an die Schenkung geknüpft wurde12. Wird die Auflage nicht vollzogen, stehen dem Schenker Ansprüche gem. § 527 BGB zu. Dabei muss der Schenker diese Ansprüche aber selbst geltend machen und gegebenenfalls gerichtlich durchsetzen. Der Rechteinhaber einer Open Source Software müsste daher den Umgang der Nutzer mit seinem Produkt und die damit verbundene Einhaltung der Lizenzbestimmungen kontrollieren können. Dies kann er nicht. Zudem spricht Ziff. 4 GPL von einem Automatismus, der sich über die Regelungen der Schenkung unter Auflage nicht erzielen lässt. Der Rechteinhaber müsste als Schenker die Vollziehung der Auflagen überwachen und im Fall der Nichtvollziehung seinen Anspruch durchsetzen. Eine derartige Lösung entspricht somit nicht der Intention der Rechteinhaber und ist auch in der Praxis nicht durchzuhalten13. Der Lösungsweg über eine Schenkung unter Auflage ist somit nicht geeignet, eine Verknüpfung von Rechten und Pflichten i. S. v. Ziff. 4 GPL zu realisieren. 3. Open Source Software als eigene Nutzungsart Grundsätzlich besteht die Möglichkeit, die dingliche Wirkung einer Verknüpfung von Rechten und Pflichten in urheberrechtlichen Lizenzen durch die Einräumung von inhaltlich beschränkten Nutzungsrechten herbeizuführen. Wie dargelegt, vermittelt die Einräumung von Nutzungsrechten gem. § 31 UrhG eine dingliche Rechtsposition. Bei Software kann ein Nutzungsrecht auch inhaltlich beschränkt eingeräumt werden. Damit aber eine dingliche Beschränkung eines Nutzungsrechts überhaupt möglich ist, muss § 31 I S. 2 UrhG neben § 69 c Nr. 3 UrhG anwendbar sein. Nun kann an dieser Stelle nicht unerwähnt bleiben, dass ein Teil der Rechtsprechung § 69 c Nr. 3 UrhG gegenüber § 31 I S. 2 UrhG als abschließende Spezialregelung begreift und eine dingliche Auf12

HK-BGB/Saenger, § 527 Rn. 1. Im Ergebnis auch Jaeger/Metzger, S. 144; Spindler, in: Spindler, Abschn. D Rn. 10, die im Rahmen der Frage nach der vertraglichen Einordnung eine Schenkung unter Auflage ablehnen. 13

II. Lösungsmodelle

197

spaltung somit ausschließt14. Diese Ansicht wird allerdings von der überwiegenden Rechtsprechung richtigerweise verworfen15, sodass die urheberrechtliche Bewertung bei Computerprogrammen im Ergebnis zu keinem anderen Ergebnis führt als die Bewertung für sonstige Werke16. a) Herausbildung einer technisch-wirtschaftlichen Nutzungsart Die Aufspaltung von Nutzungsrechten durch die Einräumung beschränkter Nutzungsrechte ist im Bereich Softwarevertrieb keine neue Rechtsanwendungsform. Gerade beim Vertrieb von Massensoftware versucht eine Vielzahl von Anbietern diese Möglichkeit zu nutzen, die Verbreitung zu kontrollieren. Neben der Möglichkeit, eine gewisse Kontrolle durch eine schuldrechtliche Bindung des Vertragspartners zu erreichen, sind die Hersteller in erster Linie bemüht, eine dingliche Wirkung gegenüber jedem Dritten zu begründen17. Der Vorteil einer dinglichen Wirkung liegt vor allem darin, dass die Einschränkungen eines Nutzungsrechts auch im Falle einer Vertragsverletzung greifen. Die dingliche Beschränkung wirkt im Vergleich zu einer rein schuldrechtlichen Lösung erga omnes und kann daher nicht umgangen werden18. Softwarehersteller haben mit verschiedenen Lizenzmodellen versucht, eine entsprechende dingliche Wirkung herbeizuführen19. Das wohl bedeutendste Beispiel20 für den Versuch, ein Verbreitungsrecht aufzuspalten, ist OEM21-Software. Dabei handelt es sich um eine besondere Vertriebsform von Software, bei der die Benutzung der Software nur demjenigen gestattet wird, der gleichzeitig die Hardware erwirbt, auf der die Software installiert ist. Die Software ist somit an die Hardware gebunden und darf nur mit ihr zusammen weiterverbreitet werden. Ziel dieser Verbreitungsform ist die langfristige Kundenbindung. Dabei versorgt man den Kunden mit einer vergleichsweise kostengünstigen OEM-Version mit der Erwartung, dass der Kunde dann auch dauerhaft diese Software, einschließ14

OLG Frankfurt, CR 1999, S. 7, 8; OLG München, CR 1998, S. 266, 267. BGH, CR 2000, 651, 652; OLG Frankfurt, CR 2000, S. 581, 582; KG, GRUR 1996, S. 974, 975. 16 Wandtke/Bullinger/Grützmacher, § 69 c Rn. 70; Marly, Rn. 549. 17 Marly, Rn. 546. 18 Witte, CR 1999, S. 65. 19 Ausführlich dazu Witte, CR 1999, S. 65 ff. 20 Bedeutend auch deshalb, da sich der BGH mit dieser Vertriebsform beschäftigt hat, die noch heute von vielen Softwareherstellern genutzt wird; BGH CR 2000, S. 651 ff. 21 OEM = Original Equipment Manufacturer. 15

198

§ 7 Rechtliche Dogmatik des Copyleft-Modells

lich des Erwerbs von teueren Folgeversionen, nutzen wird. Der BGH hat in seiner viel beachteten Entscheidung zu OEM-Software eine dingliche Wirkung der OEM-Klausel abgelehnt22. Dabei hat der BGH aber ausdrücklich offen gelassen, ob es sich in diesen Fällen um eine sog. eigene urheberrechtliche Nutzungsart handelt23. Das Gericht hat lediglich festgestellt, dass die formulierte Beschränkung des Verbreitungsrechts nicht gegenüber Dritten wirksam ist, sondern nur inter partes wirkt24. Bei der Verwendung entsprechender Klauseln in Softwarelizenzverträgen steht somit die Frage im Mittelpunkt, ob es sich jeweils um eine wirksame inhaltliche Beschränkung des Verbreitungsrechts handelt. Eine dinglich wirkende Aufspaltung des Verbreitungsrechts kommt nach Rechtsprechung und Literatur nur dann in Betracht, wenn es sich um übliche, technisch und wirtschaftlich eigenständige und damit klar abgrenzbare Nutzungsformen handelt25. Es muss also eine Verwertungsform vorliegen, die nach Verkehrsauffassung gegenüber anderen Formen der Verbreitung in technischer und wirtschaftlicher Hinsicht klar abgrenzbar ist26. Maßgeblich ist die Erscheinungsform der überlassenen Nutzungsart für die betreffenden Verkehrskreise27. b) Verknüpfung von Rechten und Pflichten durch Einräumung eines inhaltlich beschränkten Nutzungsrechts bei Open Source Software aa) Technisch-wirtschaftliche Eigenständigkeit In der juristischen Literatur zu Open Source Software wird unter anderem die Ansicht vertreten, dass die Nutzungsrechte durch die GPL regelmäßig inhaltlich beschränkt eingeräumt werden und Open Source Software als eigenständige Nutzungsart angesehen werden kann28. Eine derartige Beschränkung sei in der grundsätzlichen Vergütungsfreiheit jeder Weitergabe zu sehen, so, wie sie in der GPL festgeschrieben sei. Koch weist darauf hin, dass das Open Source Modell nur dann tragfähig sei, wenn Open Source Software nach der Verkehrsauffassung der beteiligten Kreise als 22

BGH, CR 2000, S. 653. Schneider, HER, Abschn. C Rn. 216; Schiffner, S. 138. 24 BGH, CR 2000, S. 653. 25 BGH, CR 2000, S. 652; BGH, GRUR 1959, S. 202; BGH, GRUR 1986, S. 737; BGH, GRUR 1992, S. 311; Schack, Rn. 545; Kotthoff, in: HK-UrhR, § 69 c Rn. 28; Metzger/Jaeger, GRURInt 1999, S. 843. 26 Marly, Rn. 549. 27 BGH, MDR 1992, S. 361. 28 Koch, Rn. 462; ders., CR 2000, S. 334 f.; Schiffner, S. 157 f.; Marly, Rn. 425. 23

II. Lösungsmodelle

199

wirtschaftlich eigenständige Nutzungsart angesehen wird, auf die dann eine inhaltlich-beschränkte Aufspaltung des Verbreitungsrechts aufbauen kann29. Ausreichend sei die Ausbildung einer technisch und wirtschaftlich eigenständigen Nutzungsform von Software. Nach dieser Ansicht soll zumindest für Linux und linuxbasierte Applikationsprogramme von einer eigenständigen Nutzungsart auszugehen sein30. Linux und darauf aufbauende Applikationsprogramme stellen danach einen eigenständigen Markt dar. Schiffner will die Annahme einer eigenständigen Nutzungsart nicht auf Linux und linuxbasierte Applikationssoftware beschränken. Jede unter einer Open Source-Lizenz wie der GPL lizenzierte Software lässt sich nach seiner Meinung in urheberrechtlicher Hinsicht technisch wie wirtschaftlich als eigenständige Nutzungsart einordnen. Eine technisch eigenständige Nutzungsart ergebe sich in Folge der weitgehenden Rechteeinräumung durch die GPL. In der Einräumung einer umfassenden Verwendungsfreiheit sieht diese Auffassung einen Unterschied technischer Natur, der auch nach allgemeiner Verkehrsauffassung eine wesentliche Eigenständigkeit erfülle31. Im Gegensatz zu proprietär vertriebener Software erhielte der Nutzer von Open Source Software vielfältigere Nutzungsmöglichkeiten. Das Einsatzgebiet und die Anwendungsmöglichkeiten seien infolge dieser weit gehenden Nutzungsmöglichkeiten für den Anwender wesentlich weitreichender als bei einem kommerziellen Softwareprodukt32. Darüber hinaus kann Open Source Software nach dieser Auffassung als wirtschaftlich eigenständige Nutzungsart angesehen werden33. Hierfür werden im Wesentlichen zwei Gründe angeführt. Die faktische Kostenfreiheit der Open Source-Entwicklungen für den Anwender grenze den Markt gegenüber kommerzieller Software klar ab. Zudem sei mittlerweile ein eigener Markt für Open Source Software entstanden, der auch für den allgemeinen Rechtsverkehr klar zu erkennen sei und von ihm in Bezug auf den kommerziellen Softwaremarkt klar unterschieden wird34. Nach dieser Ansicht würde man sich der Wirklichkeit verschließen, würde man bei Open Source Software eine eigene Nutzungsart ablehnen35. Vielmehr liege eine derartig gefestigte Verkehrsanschauung vor, dass für jedwede Software, die unter einer anerkannten Open Source-Lizenz vertrieben wird, eine eigene Nutzungsart angenommen werden müsse. 29 30 31 32 33 34 35

Koch, Rn. 462. Koch, Rn. 462, ders., CR 2000, S. 334. Schiffner, S. 157. Schiffner, S. 157 f. Schiffner, S. 158. Schiffner, S. 158. Schiffner, S. 158.

200

§ 7 Rechtliche Dogmatik des Copyleft-Modells

Auch Marly ist der Ansicht, dass die Nutzungsrechte inhaltlich beschränkt eingeräumt werden, da es sich bei Open Source Software um eine wirtschaftlich-technische eigenständige Nutzungsart handelt, die klar abgrenzbar ist36. Die weite Verbreitung des Open Source-Gedankens habe gerade dazu geführt, dass schon seit einigen Jahren nach allgemeiner Verkehrsauffassung von einer klar abgrenzbaren, selbstständigen Nutzungsart ausgegangen werden kann, die nicht auf Linux- bzw. Apache-Programme eingegrenzt werden kann. Spätestens seit Ende der neunziger Jahre kann seiner Meinung nach von einer derartigen gefestigten Verkehrsauffassung bezüglich einer eigenständigen Nutzungsart bei Open Source Software ausgegangen werden. Ausgehend von der Frage nach der Bedeutung des Erschöpfungsgrundsatzes für das Open Source-Vertriebsmodell und ohne direkt auf die dogmatische Problematik der dinglichen Verknüpfung von Rechten und Pflichten einzugehen, kommt auch Heussen dazu, Open Source Software als eigenständige Nutzungsart einzuordnen, die gegenüber anderen Softwaremodellen klar abgrenzbar ist und dies auch für den Markt erkennbar ist37. Eine Abspaltung des Marktes Open Source Software werde gerade durch Ziff. 3 GPL erreicht, der ein „besonderes Leistungsbündel vollkommen eigener Art“ schnüre. Dies mache gerade den Unterschied zu kommerziell vertriebener Software aus. Das Open Source Modell sei in erster Linie ein Entwicklungsmodell mit dem Ziel, eine bestimmte Software am Markt zu etablieren, während es bei dem kommerziellen Vertriebsmodell in erster Linie um den Verkauf möglichst vieler Programmkopien gehe. bb) Kritik an der Annahme einer technisch-wirtschaftlichen Nutzungsart Fraglich ist, ob die Ansicht, Open Source Software lasse sich als wirtschaftlich-technisch eigenständige Nutzungsart begreifen, überzeugen kann. Nur wenn eine Abspaltbarkeit und Unterscheidbarkeit in technisch-wirtschaftlicher Hinsicht für einen allgemeinen Verkehrskreis sichtbar ist, kann ein dinglich beschränktes Nutzungsrecht mit der Folge einer dinglichen Verknüpfung von Rechten und Pflichten eingeräumt werden. In den letzten Jahren ist ein eigener großer Markt freier Software entstanden. Das könnte auf den ersten Blick dazu führen, von einem eigenständigen Markt zu sprechen und in der Konsequenz eine eigenständige Nutzungsart anzunehmen. Um aber von einer eigenständigen Nutzungsart spre36 37

Marly, Rn. 425. Heussen, MMR 2004, S. 450.

II. Lösungsmodelle

201

chen zu können, ist eine genaue Differenzierung hinsichtlich der technischen wie wirtschaftlichen Eigenständigkeit notwendig. Dabei sollte nicht vergessen werden, dass die Rechtsprechung gerade im Bereich Software das Vorliegen einer eigenständigen Nutzungsart nur sehr selten annimmt. (1) Fehlende technische Eigenständigkeit Im Bereich Open Source Software bestehen vielfältige Nutzungs- und Anwendungsmöglichkeiten der Computerprogramme. Zweifelhaft ist jedoch schon, ob eine technische Nutzungsart vorliegt, die nach allgemeiner Verkehrsauffassung als selbstständig und eigenständig erscheint. Schon mehrfach wurde erwähnt, dass sich Open Source Software programmtechnisch nicht von proprietärer Software unterscheidet. In technischer Hinsicht unterscheiden sich die potenziellen Nutzungs- und Anwendungsmöglichkeiten nicht von denen bei kommerziell vertriebener Software. Auch besteht kein tatsächlicher Unterschied zwischen den Trägermedien, auf denen die Software verbreitet wird. Sowohl Open Source Software als auch proprietäre Software wird online, auf CD-ROM, auf DVD sowie im Wege des ASP angeboten. Der zentrale Unterschied zu kommerziell vertriebenen Softwareprodukten liegt bei Open Source Software allein darin, dass für die Lizenzeinräumung kein Entgelt erhoben wird und zugleich eine umfassende Rechtseinräumung erfolgt. Die Argumentation, dass eine weitgehende Rechtseinräumung bei Open Source Software ausreicht, eine technische Eigenständigkeit hinsichtlich einer eigenen Nutzungsart anzunehmen, kann nicht überzeugen. Auch der Hinweis auf ein eigenständiges Entwicklungsmodell vermag nicht zu überzeugen. Nun ist es richtig, dass eine weitgehende Rechtseinräumung zu der Möglichkeit führt, dass der Nutzer Veränderungen, Verbesserungen und Anpassungen an der Software vornehmen kann. Es kann auch nicht bestritten werden, dass diese weitgehende Rechtseinräumung oder auch „Bündelung“ von eingeräumten Rechten Grundlage für ein wie auch immer zu fassendes besonderes Softwareentwicklungsmodell ist. Aber allein eine umfassende Rechtseinräumung bringt noch keine technisch eigenständige Nutzungsart i. S. d. § 31 I S. 2 UrhG. Im Mittelpunkt steht die Auslegung des § 31 I S. 2 UrhG. Es geht um die klare Abgrenzungsfrage, wann die Nutzung eines Werkes aus Sicht der Verkehrskreise als technisch eigenständig eingeordnet werden kann. Befasst man sich mit der urheberrechtlichen Literatur sowie Rechtsprechung zu diesem Thema findet man verschiedene Beispiele, bei denen sich eine neue technisch eigenständige Nutzungsart herausgebildet hat38. In den meisten Fällen wurden dabei Werke auf neuen Trägermedien vertrieben (z. B. Ausgabe von 38

Aufführung von Beispielen bei Kotthoff, in: HK-UrhR, § 31 Rn. 113 ff.

202

§ 7 Rechtliche Dogmatik des Copyleft-Modells

Jahrgängen einer Zeitschrift auf CD-ROM39) oder neue Vertriebswege erschlossen (Angebot von Verlagserzeugnissen über das Internet40). Mit diesen Fallgruppen lässt sich die vorliegende Sachfrage nicht beantworten, da keine Vergleichbarkeit gegeben ist. Fraglich ist hier allein, ob weitgehende Verwendungsfreiheiten zu einer technisch eigenständigen Nutzungsart führen, die einen parallelen Vertrieb als proprietär-lizensierte Software zulässt. Zu fordern ist also eine gegenseitige Ausschließlichkeit der verschiedenen Nutzungsarten, die aus einer Abspaltung entstehen. Hinsichtlich einer derartigen gegenseitigen Ausschließlichkeit bestehen allerdings große Bedenken. Auch kommerziell vertriebene Software kann ja derart lizenziert werden, dass der Nutzer vielfältige Veränderungs- und Nutzungsbefugnisse erhält. Die Lizenzgebühren dürften in derartigen Fällen ihrer Höhe nach entsprechend den eingeräumten Rechten zwar angepasst werden, in technischer Hinsicht würde sich die Softwarenutzung aber nicht mehr von der Open Source Software-Nutzung unterscheiden. Es ist somit denkbar, dass sich die Nutzung sowie die Entwicklungs- und Weiterentwicklungsmöglichkeiten in technischer Hinsicht gar nicht unterscheiden, mithin keine gegenseitige Ausschließlichkeit gegeben ist. Rein tatsächlich unterscheiden sich Computerprogramme, ob als Open Source-Lizenziert oder kommerziell vertrieben, nicht voneinander. Schaut man sich exemplarisch den Vergleich mit einem anderen Werk wie dem herkömmlichen Buch an, wo das E-Book als neue Nutzungsart angesehen wird, kann man entsprechende Vergleiche hier nicht anstellen. Ein E-Book bietet in technischer Hinsicht ganz andere Anwendungsmöglichkeiten als ein herkömmliches Buch. In dieser Frage kann es mithin nicht um eine rechtliche Bewertung der technischen Eigenständigkeit einer Werksnutzung gehen, sondern darum, ob eine Werknutzung tatsächlich auch nach Verkehrsanschauung technisch eigenständig ist. Kommerziell vertriebene Software und Open Source Software unterscheiden sich aber lediglich in einer Lizenzierungsfrage, nicht in der tatsächlichen Möglichkeit einer bestimmten technischen Anwendung. Open Source Software hat in rein tatsächlicher Natur keine Anwendungsmöglichkeiten, die kommerziell vertriebene Software nicht bieten kann. (2) Annahme einer wirtschaftlichen Eigenständigkeit In wirtschaftlicher Hinsicht kann man zunächst zu einem anderen Ergebnis kommen. Gegen eine wirtschaftliche Eigenständigkeit wird zunächst konstatiert, dass sich beide Nutzungsarten gerade deshalb gegenseitig ausschließen, da die Verbreitung eines Softwareproduktes auf kommerziellem 39 40

BGH GRUR 2002, S. 248, 251. Kotthoff, in: HK-UrhR, § 31 Rn. 113.

II. Lösungsmodelle

203

Wege und gleichzeitig als Open Source Software schon wirtschaftlich keinen Sinn mache41. Dies überzeugt nicht. Spindler ist zunächst dahingehend zuzustimmen, dass in diesem Zusammenhang angebotene Zusatzleistungen wie Support, Handbücher, Beratungen oder auch Schulungen eine eigene Nutzungsart nicht begründen können. Einer der Hauptgründe für die Kostenfreiheit der Lizenzeinräumung ist neben der Grundidee des freien Zugangs zu Software auch das zugrunde liegende Entwicklungskonzept. Ohne die Kostenfreiheit der Lizenzeinräumung würde ein jedes Open Source-Entwicklungsmodell scheitern. Ein wichtiger Hauptgrund dafür ist sicherlich auch der mit der Kostenfreiheit verbundene generelle Haftungs- und Gewährleistungsausschluss. Würde man ein Entgelt verlangen, würde man den Nutzern einerseits den Anreiz einer freiwilligen Entwicklungshilfe nehmen, andererseits würde man sich durch die Erhebung eines Entgelts leichter Haftungs- und Gewährleistungsansprüchen aussetzen, da man zu vertraglichen Einordnungen (wie z. B. einen Kaufvertrag) mit der Folge kommen kann, dass ein entsprechender Haftungs- und Gewährleistungsausschluss dann zulässig nicht mehr vereinbart werden kann. Nun ist es meiner Meinung nach aber gerade der Gesichtspunkt des generellen Gewährleistungsund Haftungsausschlusses, der als Anknüpfungspunkt für eine wirtschaftliche Eigenständigkeit der Nutzung von Open Source Software herangezogen werden kann. An dieser Stelle ist eine gegenseitige Ausschließlichkeit von Software, die unter der GPL lizenziert ist, und kommerziell vertriebener Software gegeben. Es kann eben doch wirtschaftlich sinnvoll sein, ein Computerprogramm gleichzeitig als Open Source Software oder in kommerzieller Form zu verbreiten. Die Open Source-Variante bietet man jedermann unentgeltlich zur Weiterbearbeitung und Nutzung an. Der Nutzer erhält keine Gewährleistungsrechte und hat auch keine Regressansprüche in Haftungsfällen gegen den Softwareanbieter. Das gleiche Computerprogramm kann aber auch kommerziell und entgeltlich verbreitet werden. Hier hat dann der Nutzer hinsichtlich einer bestimmten Programmversion regelmäßig Gewährleistungsrechte sowie Regressansprüche in Haftungsfällen. Für diese Absicherungen entrichtet er u. a. sein Entgelt. Am Markt befinden dann sich zwei unterschiedlich lizenzierte Versionen eines Computerprogramms. Eines zur Weiterentwicklung durch Dritte und eines für die rein kommerzielle Verwertung. Von wirtschaftlicher Unsinnigkeit kann somit keinesfalls gesprochen werden. Metzger/Jaeger gehen sogar davon aus, dass der „proprietäre Vertrieb“ von Open Source Software gerade ausgeschlossen werden solle42. Dies erscheint als zu pauschal angesichts der Tatsache, dass einige Open Source-Lizenzen einen eingeschränkten Copyleft dahingehend enthalten, dass die jeweilige Software mit einem kommer41 42

Deike, CR 2003, S. 16; Metzger/Jaeger, GRUR 1999, S. 843. Metzger/Jaeger, GRUR 1999, S. 843.

204

§ 7 Rechtliche Dogmatik des Copyleft-Modells

ziellen Softwareprodukt verbunden und proprietär vertrieben werden darf43. Jaeger/Metzger gestehen selbst zu, dass man hier auch zu einer Wandlung der Verkehrsanschauung kommen kann, wenn das sog. Dual Licensing zunimmt44. Die Tatsache, dass ein gebündelter Vertrieb von freien und rein proprietären Softwareelementen im Wege des Dual Licensing aufgrund einiger Open Source-Lizenzen ermöglicht wird, spricht aber gerade für die Möglichkeit und wirtschaftliche Sinnigkeit eines Parallelvertriebs. Eine gegenseitige Ausschließlichkeit lässt sich hinsichtlich der wirtschaftlichen Eingenständigkeit von Open Source Software somit begründen. Es muss aber berücksichtigt werden, dass die Annahme einer wirtschaftlichen Eigenständigkeit allein nicht ausreichend, um eine eigenständige Nutzungsart anzunehmen. Die Rechtsprechung lässt eine wirtschaftliche Eigenständigkeit allein nicht ausreichen, sondern fordert auch die technische Eigenständigkeit der jeweiligen Nutzungsart. Eine technische Eigenständigkeit wird aber mit oben aufgeführter Begründung abgelehnt. Das Argument, dass sich mittlerweile nach Verkehrsauffassung ein eigenständiger Markt von Open Source Software entwickelt habe, ist nicht überzeugend und reicht für die wirtschaftliche Eigenständigkeit nicht aus. Der Softwaremarkt lässt sich tatsächlich nicht einfach in Open Source Software und proprietäre Software unterteilen. An vielen Stellen überschneiden und ergänzen sich beide Märkte und deren Produkte, sie profitieren voneinander. Koch will das Bestehen einer „Plattform“, die einen eigenen Markt bildet, genügen lassen und bejaht das Vorliegen einer trennbaren und damit technisch wie wirtschaftlich eigenständigen Nutzungsart, die seiner Meinung nach allerdings nur für Linux und linuxbasierte Applikationsprogramme gegeben sein45. Allein schon die Tatsache, dass Koch den eigenständigen Markt auf Linux und linuxbasierte Applikationsprogramme beschränkt, spricht gegen die Annahme einer wirtschaftlichen Eigenständigkeit von Open Source Software. Diese Einschränkung lässt vielmehr vermuten, dass auch Koch indirekt davon ausgeht, dass es eben keine klare überzeugende Abgrenzungsmöglichkeit gibt. Es ist nicht nachvollziehbar, weshalb er das Angebot von Open Source Software spaltet und die eigenständige Nutzungsart nur für linuxbasierte Computerprogramme annehmen will. Die Frage, ob eine eigenständige Nutzungsart vorliegt, kann schon gar 43 Die BSD-artigen Lizenzen lassen einen proprietären Vertrieb von Software, in die auch die jeweilige Open Source Software eingefügt wurde zu. Wenn man die BSD-Lizenzen grundsätzlich auch als Open Source-Lizenzen einordnet ist die Aussage von Metzger/Jaeger zumindest widersprüchlich. Vgl. dazu Jaeger/Metzger, S. 5, die dort sehr wohl von der Möglichkeit eines proprietären Vertriebs ausgehen. 44 Jaeger/Metzger, S. 39 Fn. 159. 45 Koch, § 9 Rn. 462.

II. Lösungsmodelle

205

nicht danach zu beantworten sein, wie bekannt oder wie weit verbreitet ein Open Source-Programm ist. Darüber hinaus muss gerade im Bereich Open Source Software von einer Verkehrsauffassung ausgegangen werden, die Linux und linuxbasierte Software nur als einen kleinen Teil der verfügbaren Computerprogramme sieht. Es besteht ja gerade eine Vielfalt von Open Source Software-Anwendungen. Der Eingrenzungsversuch von Koch zeigt letztlich, dass eben keine klaren Kriterien vorhanden sind, die eine klare Abspaltung in technisch-wirtschaftlicher Hinsicht zulassen. Schiffner46 führt das Argument an, dass eine Aufspaltbarkeit deshalb wirtschaftlich Sinn macht, weil dem Programmhersteller als Urheber so die Möglichkeit erhalten bleibt, ein Open Source-Programm auch noch kommerziell verwerten zu können. Dem Rechteinhaber verbliebe so die Möglichkeit, das Programm aus der Open Source-Verwertung zu nehmen und kommerziell zu verbreiten. Um ihm dieses Recht zu kommerziellen Verwertung zu belassen, sei eine Aufspaltung des Nutzungsrechts geboten. Dem ist insofern zuzustimmen, als dass es dem Rechteinhaber schon aus den oben genannten Gründen unbenommen bleibt, eine Open Source Software zugleich oder auch im Nachhinein kommerziell zu verwerten. Als Argument für eine wirtschaftliche Eigenständigkeit kann dieses Argument hingegen nicht überzeugen. Es können nur Nutzungsrechte inhaltlich beschränkt eingeräumt werden, die nach der Verkehrsauffassung als solche hinreichend klar abgrenzbar sind. Diese Ansicht argumentiert hier aber allein aus der Perspektive des Rechteinhabers. Maßgeblich ist jedoch die allgemeine Verkehrsauffassung. Aber noch ein weiterer Gesichtspunkt spricht gegen dieses Argument. Würde man dieser Auffassung hier zustimmen, würde man die Möglichkeit zu einer Aufspaltung des Nutzungsrecht zum Selbstzweck erklären47. Die Frage nach einer eigenständigen Nutzungsart bestimmt sich jedoch in erster Linie nach den oben genannten objektiven Kriterien der technisch-wirtschaftlichen Eigenständigkeit. Insofern vermag das Argument des Rechtsvorteils des Urhebers letztlich nicht zu überzeugen. Darüber hinaus ist auch das Argument, eine Aufspaltung der Nutzungsrechte gewährleiste und sichere die Freiheit der Programme, da im Wege einer Aufspaltung das Recht der unentgeltlichen Verbreitung beim Rechteinhaber verbliebe48, nicht überzeugend. Auch diese Argumentation ist in erster Linie zweckorientiert und aus Sicht des Rechteinhabers. Unbeachtet bleibt, dass sich die Frage nach einer wirtschaftlich-technisch eigenständigen Nutzungsart nach objektiven Kriterien sowie nach Verkehrsauffassung richtet. Zudem ist eine Aufspaltung der Nutzungsrechte nicht notwendigerweise ge46 47 48

Schiffner, S. 160. So auch Spindler, in: Spindler, Abschn. C Rn. 33. Schiffner, S. 160.

206

§ 7 Rechtliche Dogmatik des Copyleft-Modells

boten, um die Programmfreiheit zu gewährleisten. Wie sich noch zeigen wird, bestehen andere rechtliche Lösungswege, um zu einem vergleichbaren Ergebnis zu kommen, sodass es nicht notwendigerweise einer Konstruktion über die Einräumung eines inhaltlich beschränkten Nutzungsrechts bedarf. (3) Ziff. 4 GPL Als Hauptargument gegen die Annahme einer eigenständigen Nutzungsart bei Open Source Software kann die Regelung des Ziff. 4 GPL selbst herangezogen werden. Die Regelung, auf die noch näher einzugehen ist49, spricht von einer automatischen Beendung der durch die GPL eingeräumten Rechte für den Fall eines Lizenzverstoßes. Das spricht aber dafür, dass die Verwender dieser Lizenz gerade nicht von der Einräumung eines inhaltlich beschränkten Nutzungsrecht ausgehen, da es bei inhaltlich beschränkten Nutzungsrechten nicht zu einem Rechterückfall kommt. Ein dem Ziff. 4 GPL vergleichbares Regelungsziel ließe sich somit mit der Einräumung inhaltlich beschränkter Nutzungsrechte nicht vereinbaren. (4) LG München I Das deutschlandweit erste Urteil, dass sich mit der GPL beschäftigt, beantwortet die vorliegende Frage leider nur am Rande und setzt sich nicht inhaltlich mit ihr auseinander.50 Ausgehend von der BGH-Rechtsprechung zur OEM-Version stellt das Gericht lediglich fest, dass die GPL die Anforderungen an eine selbstständige klar abgrenzbare Nutzungsart nicht erfüllt, und verweist auf die entsprechende urheberrechtliche Literatur. Dabei werden jedenfalls die Befürworter der Einräumung eines inhaltlich beschränkten Nutzungsrechts schlichtweg nicht berücksichtigt. Eine ausführlichere Auseinandersetzung mit der Problematik wäre hier sicherlich wünschenswert gewesen. Das es hierzu nicht kam, kann damit zusammenhängen, dass es sich nicht um ein Urteil im Hauptsacheverfahren, sondern in einem einstweiligen Verfügungsverfahren handelt. c) Zwischenergebnis Somit bleibt festzuhalten, dass es sich bei Open Source Software jedenfalls in technischer Hinsicht nicht um eine eigenständige, klar abgrenzbare Nutzungsart handelt und demzufolge kein inhaltlich beschränktes Nutzungsrecht an ihr eingeräumt werden kann. 49 50

Vgl. § 7 II. 4. CR 2004, S. 774 ff.

II. Lösungsmodelle

207

Im Rahmen der Open Source-Lizenzierung wird somit kein inhaltlich beschränktes Nutzungsrecht gem. § 31 I S. 2 UrhG eingeräumt, das eine Erschöpfung der Verbreitung verhindern würde.

4. Dinglich wirkender Vorbehalt Eine rein schuldrechtliche Lösung sowie die Annahme inhaltlich beschränkter Nutzungsrechte scheiden zur Lösung der dogmatischen Frage nach der Verknüpfung von Rechtseinräumung und Lizenzplichten aus. Die GPL als zentrale Open Source-Lizenz enthält in der schon oben erwähnten Ziff. 4 GPL eine klare Rechtsfolgenregelung für den Fall, dass gegen Lizenzbestimmungen verstoßen wird. Diese Regelung steht daher im Mittelpunkt der dogmatischen Betrachtung, da sie die Zielvorgabe für ein dogmatisches Lösungsmodell enthält51. Fraglich ist jedoch, welche rechtliche Konstruktion geeignet ist, dieser Zielvorstellung im deutschen Recht zum Erfolg zu verhelfen. a) Meinungsstand Ausgehend von der Regelung der Ziff. 4 GPL und ihrer Formulierung „will automatically terminate your rights“ geht ein großer Teil der Literatur52 sowie das LG München I53 von einem dinglich wirkenden Vorbehalt aus. Die Regelung wird dabei als „eine Art Eigentumsvorbehalt“ verstanden54. Die Nutzungsrechte werden danach durch die GPL unter einer auflösenden Bedingung gem. § 158 II BGB dahingehend eingeräumt, dass die Bedingungen und Pflichten der Lizenz eingehalten werden. Die Rechtseinräumung steht also unter der auflösenden Bedingung, dass der Nutzer seinen Pflichten aus der GPL nachkommt. Verletzt der Lizenznehmer seine Pflichten oder Bedingungen, wie sie sich aus der Lizenz ergeben, so verliert er durch den Bedingungseintritt jegliche Rechte an dem Computerprogramm. Der Bedingungseintritt führt dieser Ansicht nach zu einem Rechtsrückfall (ex nunc). Es handelt sich um eine auflösend bedingte Einigung, die zu einem automatischen Rechterückfall bei Bedingungseintritt führt. Diese Lösung sei auch deshalb unproblematisch, weil auch dingliche Rechtsgeschäfte grundsätzlich nicht bedingungsfeindlich sind. Eine der51

So auch Jaeger/Metzger, S. 38. Jaeger/Metzger, S. 38; Spindler, in: Spindler, Abschn. C Rn. 35; Spindler/ Wiebe, CR 2003, S. 876; Deike, CR 2003, S. 16; Grzeszick, MMR 2000, S. 412, 415; Stickelbrock, ZGS 2003, S. 369. 53 LG München I, CR 2004, S. 775. 54 Spindler, in: Spindler, Abschn. C Rn. 35. 52

208

§ 7 Rechtliche Dogmatik des Copyleft-Modells

artige Verknüpfung gem. der Regelung § 158 II BGB wirkt nach dieser Ansicht somit quasi-dinglich. Einerseits wird zwar zustimmenderweise festgestellt, dass der Wortlaut der Ziff. 4 GPL für einen Lösungsweg über § 158 II BGB spricht, andererseits werden aber praktische Bedenken gegen diesen Lösungsweg angeführt. Ein Gegenargument ist der Umstand des Zustandekommens der Lizenzvereinbarung im Bereich Open Source-Lizenzen. Die Annahme der Lizenzbedingungen durch einen Nutzer erfordert eine Willenserklärung des Lizenznehmers, auf deren Zugang gem. § 151 BGB verzichtet wird55. Potenzielle Lizenznehmer können somit jederzeit schnell die Lizenzbedingungen annehmen und die Software benutzen. Dieser Lösungsweg ist schon aufgrund des Ziel einer schnellen Softwareverbreitung geboten. Der Rechteinhaber verzichtet aber auch auf die Kenntnis seines Vertragspartners. Jeder Nutzer kann das Programm also jederzeit in Betrieb nehmen und folglich die Lizenz mehrmals annehmen. Nun schafft diese Abschlussregelung auch die Möglichkeit, dass ein Nutzer trotz eines Lizenzverstoßes die Lizenz erneut annehmen kann. Gerade dies hat in der Literatur auch Kritik hervorgerufen56. Es wird die Ansicht vertreten, dass die Möglichkeit des vertragsbrüchigen Lizenznehmers, sich die automatisch verlorengegangenen Rechte durch eine erneute Annahme wieder zu beschaffen, die Wirkung einer Lösung über § 158 II BGB konterkariert. Der Verlust der Verwertungsrechte sei für einen Nutzer somit nicht gravierend. Aber auch von anderer Seite wird der Lösung über § 158 II BGB mit scharfer Kritik begegnet. Hoeren ist der Meinung, dass diese Lösung weder aus dem Wortlaut der GPL hergeleitet werden kann noch in der Praxis mit den damit verbundenen Konsequenzen gewollt sein kann57. Zunächst konstatiert er, dass der Terminus „conditions“, der in Ziff. 2 GPL verwendet wird, nicht mit einer auflösenden Bedingung i. S. d. § 158 II BGB gleichgesetzt werden könne. Weiter gibt Hoeren zu bedenken, dass eine Lösung über § 158 II BGB die Hersteller proprietärer Software sehr freuen würde, da sie über die Möglichkeit einer auflösenden Bedingung beispielsweise CPU-Klauseln oder auch Schutzhüllenverträge ohne Probleme vereinbaren könnten.

55

Auf das urheberrechtliche Vertragrecht bei Open Source Software wird noch eingegangen. An dieser Stelle sollen zunächst kurze Ausführungen ausreichen. 56 Omsels, in: Festschrift für Paul W. Hertin, S. 157. 57 Hoeren, Anmerkung zum Urteil des LG München I, CR 2004, S. 777. Mit auflösenden Bedingungen zu operieren ist seiner Meinung nach „beating the devil with the devil“.

II. Lösungsmodelle

209

b) Stellungnahme Zweifelhaft ist, ob diese Einwände überzeugend gegen eine Lösung über § 158 II BGB angeführt werden können. Hier ist eine genaue Differenzierung geboten. Verletzt ein Softwareanwender die Lizenz, kann er natürlich jederzeit die Lizenzbedingungen erneut annehmen, d. h. wirksam mit dem Recheinhaber vereinbaren. Beispielsweise kann er die Software infolge eines Lizenzverstoßes wieder vertragsgemäß (weiter-) nutzen. Darüber hinaus kann er aber beispielsweise auch das entsprechende Computerprogramm über das Internet erneut herunterladen und die Lizenz ein weiteres Mal annehmen. In diesen Fällen schließt der Nutzer eine neue Lizenzvereinbarung mit dem Rechteinhaber. Dies ändert aber nichts an der Tatsache, dass er zuvor eine Lizenzverletzung begangen hat. Die durch den Lizenzverstoß begangene Urheberrechtsverletzung hingegen bleibt bestehen und kann nicht durch eine erneute Lizenzannahme geheilt werden. Die Rechtsverletzung wirkt fort und kann vom Rechteinhaber gem. der §§ 97 ff. UrhG verfolgt werden. Die Möglichkeit einer rückwirkenden Lizenzvereinbarung besteht auch nach der GPL nicht. Trotz der Möglichkeit einer erneuten Annahme der Lizenz setzt sich der Anwender bei Verletzungshandlungen also möglichen Ansprüchen des Rechtsinhabers gem. §§ 97 ff. UhrG aus. Aus diesem Grund überzeugen die Bedenken von Omsels nicht. Aber auch die Kritik von Hoeren überzeugt letztlich nicht. Zunächst ist anzumerken, dass die terminologische Kritik nicht nachvollziehbar ist58. Auch wenn in Ziff. 2 der GPL von „conditions“ spricht und an der Stelle nicht den Begriff der „conditions subsequences“ verwendet, schließt das einen Lösungsweg über § 158 BGB nicht grundsätzlich aus. Ziff. 2 GPL steht in diesem Zusammenhang gar nicht im Zentrum der Betrachtung. Hier geht es allein um Ziff. 4 GPL. Diese Regelung stellt zunächst klar, dass die urheberrechtlich relevanten Handlungen nur für den Fall vorgenommen werden dürfen, dass sie von der Lizenz ausdrücklich erlaubt werden59. Daran wird sodann der Rechtsfolgenhinweis geknüpft, dass jeder anderweitige, über die lizenzrechtlichen Befugnisse hinausgehende Versuch automatisch zur Beendigung der eingeräumten Rechte führt60. Diese Regelung spricht aber gerade für eine Lösung über § 158 II BGB. Ausdrücklich soll die rechtmäßige Softwarenutzung von der Einhaltung der Lizenzbedingungen 58 „Condition“ ist in der Rechtswissenschaft als „Bedingung“ zu übersetzen. „Auflösende Bedingung“ wäre eine „condition subsequent“. Vgl. Pons, Großwörterbuch für Experten und Universität, Stuttgart 2001. 59 „You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this license.“ 60 „Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.“ 14 Teupen

210

§ 7 Rechtliche Dogmatik des Copyleft-Modells

abhängig gemacht werden. Sobald dagegen verstoßen wird, folgt ein automatischer Rechterückfall. Dies kann eigentlich nur als Bedingung verstanden werden, die dann wegfällt, sobald ein Nutzer Verletzungshandlungen begeht. Im Blickpunkt steht hier also die Frage, wie sich ein automatischer Rechterückfall, wie er ausdrücklich von der GPL gewollt ist, im deutschen Recht verwirklichen lässt. Die GPL muss gerade vor dem Hintergrund ausgelegt werden, dass eine schnelle und unkomplizierte Verbreitung von Open Source Software auch über Grenzen hinweg bezweckt wird. Die Regelung über § 158 II BGB bietet aber hier die einzig praktikable und auch rechtlich sauber zu begründende Möglichkeit, einen automatischen Rechterückfall herbeizuführen. Interessant wäre daher gewesen, wie Hoeren die GPL ausgelegt hätte und zu welcher praktischen Rechtslösung er gekommen wäre. Leider hat er den interessierten Leser im Rahmen seiner Urteilsanmerkung über seinen Lösungsansatz im Unklaren gelassen. Auch sein Einwand, dass mit diesem Lösungsweg Weitergabeverbote, CPU-Klauseln oder auch Schutzhüllenverträge ermöglicht und fokussiert würden, geht fehl. Der Hinweis auf Weitergabeverbote wird, soweit sich der Terminus auf die Problematik hinsichtlich des Erschöpfungsgrundsatzes bezieht, im Zusammenhang mit den Ausführungen zum Erschöpfungsgrundsatz erläutert. Der Hinweis auf die Problematik von CPU-Klauseln kann an dieser Stelle nicht überzeugen. Zunächst ist darauf hinzuweisen, dass die höchstrichterliche Rechtsprechung die Wirksamkeit von CPU-Klauseln in Softwareüberlassungsverträgen bei Vorliegen bestimmter Voraussetzungen bejaht61. Es bleiben Fallkonstellationen denkbar, in denen eine Verwendung von CPUKlauseln regelmäßig dann als problematisch zu beurteilen sein, wenn eine entgeltliche Softwareüberlassung in Form eines Kaufvertrages oder einer mietrechtlich ausgestalteten Softwareüberlassung vorliegt62. Abzuwägen ist dann zwischen dem Interesse des Lizenznehmers an einer entsprechenden Verfügungsmöglichkeit und dem Interesse des Urhebers an einer angemessenen Beteiligung an der wirtschaftlichen Verwertung seines Programms. Bezogen auf die jeweilige Softwareüberlassung ist also auch danach zu differenzieren, aufgrund welcher schuldrechtlichen Vereinbarung die Software überlassen wird. Jedenfalls ist die Lösung über § 158 II BGB im Bereich Open Source Software in diesem Zusammenhang unproblematisch. Abge61 BGH, CR 2003, S. 323, 325 ff.: „Eine Klausel in einem Softwarelizenzvertrag, die die Verwendung einer auf begrenzte Zeit überlassenen Software auf einem im Vergleich zum vertraglich vereinbarten Rechner leistungsstärkeren Rechner oder auf weiteren Rechnern von der Vereinbarung über die Zahlung einer zusätzlichen Vergütung abhängig macht, benachteiligt den Vertragspartner nicht unangemessen [Leitsatz, Ziff. 1]. 62 Vgl. dazu auch: Wandtke/Bullinger/Grützmacher, § 69 d Rn. 37, 38.

III. Ergebnis

211

sehen davon, dass im Bereich Open Source Software CPU-Klauseln regelmäßig nicht vereinbart werden, werden die Nutzungsrechte hier unentgeltlich übertragen. Der Rechteinhaber hat kein Bestreben, angemessen an der wirtschaftlichen Verwertung der Software teilzuhaben. Im Bereich Open Source Software wird es somit regelmäßig nicht zu einer Einführung von CPU-Klauseln kommen. Aber auch die wohl eigentliche Befürchtung von Hoeren, dass ein Lösungsmodell über § 158 II BGB bei dem proprietären Softwarevertrieb zur Einführung von Klauseln verwendet werden kann, die einen Nutzer unangemessen benachteiligen, ist unbegründet. Grundsätzlich können die allgemeinen Vorschriften des BGB auch bei einer Vertragsgestaltung angewendet werden. Auch § 158 II BGB kann somit in Softwareüberlassungsverträgen Anwendung finden. Etwaige Klauseln, die mit einer auflösenden Bedingung arbeiten, müssen sich aber an den Vorschriften der allgemeinen Gesetze messen lassen, sodass ein Verbraucherschutz gewährleistet bleibt. Dem Lizenznehmer darf eine Softwarenutzung nicht praktisch unzumutbar gemacht werden. Der Rechteinhaber wird mit der Regelung des § 158 II BGB weder urheberrechtliche Schrankenregelungen noch andere materiellen Schutzvorschriften umgehen können. Die Vereinbarkeit und Angemessenheit kann regelmäßig im konkreten Einzelfall gerichtlich überprüft werden. Insofern würde eine etwaige Freude der kommerziellen Softwarehersteller über die Anwendungsmöglichkeit des § 158 II BGB nicht lange anhalten. Auch was die Problematik von Schutzhüllenverträgen angeht, greift Hoerens Kritik ebenfalls aus den oben genannten Gründen nicht. Hier müssen sich die Lizenzbedingungen und Umstände des Vertragsschlusses an den §§ 305 ff. BGB und den allgemeinen schuldrechtlichen Vorschriften messen lassen. Auch hier würde eine Lösung über § 158 II BGB wohl zu keinen anderen rechtlichen Bewertungen führen. Die Einwände sind somit für den Bereich der unentgeltlichen Rechtseinräumung bei Open Source Software nicht überzeugend.

III. Ergebnis Eine Verknüpfung von eingeräumten Nutzungsrechten und den in der GPL festgelegten Nutzerpflichten gem. Ziff. 4 GPL erfolgt im deutschen Recht somit am überzeugendsten über die Vereinbarung einer auflösenden Bedingung gem. § 158 II BGB. Die dingliche Besicherung einer schuldrechtlichen Pflicht über § 158 II BGB ist auch praktisch der erfolgversprechendste Weg, eine Einhaltung der Lizenzbedingungen zu gewährleisten. Richtigerweise ist auch das Landgericht München I diesem Lösungsweg gefolgt, wobei man sich sicherlich eine ausführlichere Begründung gewünscht 14*

212

§ 7 Rechtliche Dogmatik des Copyleft-Modells

hätte. Jedenfalls hat das Gericht festgehalten, dass der dinglich wirkende Vorbehalt auch mit § 31 I UrhG vereinbar ist63. Ein Lizenzvertrag, der die GPL zugrunde legt, steht somit unter der auflösenden Bedingung der Einhaltung der Lizenzbedingungen.

63

LG München I, CR 2004, S. 775.

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz Im Zusammenhang mit der dogmatischen Frage nach der Verknüpfung von Rechten und Pflichten der GPL stellt sich im Weiteren die Frage nach der Wirkung des Erschöpfungsgrundsatzes für die Verbreitung von Open Source Software. Etwaige Lösungswege hängen, wie sich zeigen wird, unter anderem mit der oben vorgenommenen dogmatischen Einordnung dieser Verknüpfung zusammen.

I. Allgemeines Das ausschließliche Verbreitungsrecht des Urhebers findet seine Einschränkung durch den in § 17 II UrhG normierten Erschöpfungsgrundsatz. Ist sein Werk oder Vervielfältigungsstücke hiervon mit seiner Zustimmung im Gebiet der europäischen Union oder eines anderen Vertragsstaates des Abkommens über den europäischen Wirtschaftsraum im Wege der Veräußerung in Verkehr gebracht worden, so erschöpft sich sein Verbreitungsrecht derart, dass die Weiterverbreitung mit Ausnahme der Vermietung ohne seine Einwilligung zulässig ist. Mit der Veräußerung gibt der Urheber somit die Herrschaft über das konkrete Werkstück auf1. Der Erschöpfungsgrundsatz will die übermäße Belastung eines Werkes vermeiden und dient seiner Verkehrsfähigkeit. Dem Interesse des Urhebers oder des Rechteinhabers ist damit genüge getan, dass er sein Partizipationsinteresse bereits bei der Erstverbreitung befriedigen kann2. Er kann eine Weiterverbreitung nicht verhindern, hat er das Werkstück erst einmal im Wege der Veräußerung in Verkehr gebracht. Veräußert ist ein Werk i. S. d. Vorschrift, wenn der Urheber oder Rechteinhaber seine Verfügungsmöglichkeit an dem Werkstück im Wege eines Rechtsgeschäfts endgültig aufgibt3. Gemeint ist eine endgültige Übertragung auf den Erwerber4. Allgemein anerkannt ist, dass eine nur vorüber1

Wandtke/Bullinger/Heerma, § 17 Rn. 12. Wandtke/Bullinger/Heerma, § 17 Rn. 12; Rehbinder, Rn. 206. 3 BGH, GRUR 1985, S. 131, 132; Wandtke/Bullinger/Heerma, § 17 Rn. 13; Dreier/Schulze, § 17 Rn. 25. 4 Loewenheim/Lehmann, § 76 Rn. 12. 2

214

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz

gehende Besitzüberlassung wie eine Vermietung oder eine Leihe keine Veräußerung i. S. d. Vorschrift ist5. Für Computerprogramme ist § 69 c Nr. 3 S. 2 UrhG lex specialis zu § 17 II UrhG. Im Zusammenhang hiermit wird die Ansicht vertreten, dass sich der Erschöpfungsgrundsatz nicht auf die Online-Übertragung von Software erstreckt6. Die Online-Übertragung von Computerprogrammen ist mittlerweile eine fest etablierte Vertriebsform geworden. Eine Vielzahl von Programmen lassen sich, häufig für ein geringeres Entgelt als die körperliche Programmversion, von den Herstellerportalen auf die Arbeitsstation des Nutzers herunterladen. Die Online-Übertragung eines Computerprogramms unterscheidet sich auch in technischer sowie wirtschaftlicher Hinsicht nicht von einer herkömmlichen körperlichen Verbreitung. Der Download von Software ist im Internetzeitalter richtigerweise als „funktionales Äquivalent“ zur körperlichen Verbreitung zu sehen7. Die Programmkopie wird lediglich digital transferiert und dann auf einem körperlichen Datenträger gespeichert. Die dem Erschöpfungsgrundsatz zugrunde liegende Interessenlage ist hier die gleiche. Vom Sinn und Zweck des Erschöpfungsgrundsatzes ausgehend, kann es somit nicht überzeugen, die Online-Übertragung von dem Anwendungsbereich auszuklammern8. Folge des Erschöpfungsgrundsatzes ist, dass der Urheber oder Rechteinhaber sein Verbreitungsrecht nicht mehr ausüben kann und jedermann das konkrete Werkstück nunmehr frei veräußern kann. Schließlich ist der Erschöpfungsgrundsatz zwingender Natur und kann somit auch nicht im Wege einer Vertragsvereinbarung abbedungen werden9.

5

Amtl. Begr. BT-Drucks. 4/270, S. 48; Schricker/Loewenheim, § 17 Rn. 39; Loewenheim/Lehmann, § 76 Rn. 12; Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 63. 6 So Schricker/Loewenheim, § 69 c Rn. 25; Kilian/Heussen/Harte-Bavendamm/ Wiebe, CHB, Nr. 51 Rn. 108; Ausführlich hierzu: Kotthoff, in: HK-UrhR, § 69 c Rn. 22 f.; Die Nichtanwendung des Erschöpfungsgrundsatzes auf die unkörperliche Verbreitung wird auch mit der InfoSoc-Richtlinie begründet. Vgl. Spindler, in: Spindler, Abschn. C Rn. 100. 7 Überzeugend Hoeren, MMR 2000, S. 517. 8 Möhring/Nicolini/Hoeren, § 69 c Rn. 16; Wandtke/Bullinger/Grützmacher, § 69 c Rn. 36; Dreier/Schulze, § 69 c Rn. 24. 9 Loewenheim/Lehmann, § 76 Rn. 15; Lehmann/Haberstrumpf, S. 139; Schricker/ Loewenheim, § 69 c Rn. 32.

II. Erschöpfungsgrundsatz

215

II. Erschöpfungsgrundsatz im Rahmen der Verbreitung von Open Source Software Ein wesentliches Merkmal von Open Source Software ist zweifelsohne die Kostenfreiheit der Lizenzeinräumung. Für die Einräumung der Nutzungsrechte dürfen keine Lizenzgebühren erhoben werden. Allein für den Kopiervorgang sowie für Zusatzdienstleistungen jeglicher Art können Entgelte erhoben werden. Open Source-Lizenzen mit strengem Copyleft-Effekt, insbesondere die GPL, schließen somit eine kommerzielle Verwertung der Lizenzrechte an einem Computerprogramm grundsätzlich von vornherein aus. Nun ergibt sich an dieser Stelle die Schwierigkeit, wie sich der in §§ 69 c Nr. 3, 17 II UrhG normierte Erschöpfungsgrundsatz hierauf auswirkt. Die Anwendung des Erschöpfungsgrundsatzes schafft unter Umständen die Möglichkeit, Lizenzgebühren im Rahmen einer Weiterverbreitung zu erheben10. Tritt volle Erschöpfung ein, kann ein Lizenznehmer die Open Source Software gegen Entgelt und ohne Quellcode weiterveräußern. Der Erschöpfungsgrundsatz wäre somit geeignet, die Gewährleistung der Kostenfreiheit von Open Source Software zu gefährden. Die in der Lizenz normierten Bedingungen und Pflichten hinsichtlich einer Kostenfreiheit wären im Zusammenhang mit einer Weiterverbreitung gegenstandslos. Das Open Source-Verbreitungsmodell wäre aufgrund des im nationalen Urheberrecht normierten Erschöpfungsgrundsatzes in seiner Existenz sowie in seiner Zukunftsfähigkeit gefährdet. Schlägt der Erschöpfungsgrundsatz bei Open Source Software voll durch, fällt damit die Aufrechterhaltung der Kostenfreiheit hinsichtlich der Rechtseinräumungen bei der Weitergabe des Computerprogramms. 1. Anwendungsvoraussetzungen des § 69 c Nr. 3 UrhG bei Open Source Software Damit aber der Erschöpfungsgrundsatz bei Open Source Software überhaupt von Belang sein kann, müssen im Rahmen von Open Source-Softwareüberlassungsverträgen zunächst die Anwendungsvoraussetzungen des § 69 c Nr. 3 UrhG vorliegen. Bei Open Source Software handelt es sich grundsätzlich um eine dauerhafte Überlassung des Computerprogramms. Insofern kann weder das Vorliegen eines Miet- oder Leihvertrages angenommen werden, was eine An10 Bedenken auch bei Plaß, GRUR 2002, S. 679; Spindler, in: Spindler, Abschn. C Rn. 93 ff.; Schiffner, S. 136 ff.

216

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz

wendung des Erschöpfungsgrundsatzes ausschließen würde. Die Frage, ob und welches Kausalgeschäft der Rechtseinräumung bei Open Source Software zugrunde liegt, kann hier noch offen bleiben11. Der Urheber von Open Source Software gibt jedenfalls die jeweilige Programmkopie mit der Erstverbreitung in körperlicher oder unkörperlicher Form endgültig in den Rechtsverkehr und verliert so jede Verfügungsmöglichkeit über das Werkstück. Er will insofern keine konkrete Kontrolle über die einzelne Programmversion mehr ausüben. Zudem muss die Erstveräußerung im Gebiet der Europäischen Union oder eines Vertragsstaates des Abkommens über den europäischen Wirtschaftsraum EWR erfolgen. Die grundsätzlichen Anwendungsvoraussetzungen liegen mithin vor. 2. Generelle Anwendbarkeit des § 69 c Nr. 3 UrhG auf Open Source Software Fraglich ist nun, ob die festgelegten Einschränkungen des in Open Source-Lizenzmodellen gewährten Verbreitungsrechts am Erschöpfungsgrundsatz scheitern. Aufgrund der lizenzrechtlichen Besonderheiten bei Open Source Software könnte man grundsätzlich auf die Idee kommen, die Anwendung des Erschöpfungsgrundsatzes auf Open Source Software generell abzulehnen12. Dieser Gedanke liegt gar nicht so fern, wurde doch lange Zeit darüber gestritten, ob sich der Erschöpfungsgrundsatz überhaupt auf Softwareverträge erstreckt13. Die eindeutige Normierung des Erschöpfungsgrundsatzes in § 69 c Nr. 3 UrhG spricht aber für die Anwendbarkeit auf Computerprogramme. Für Open Source Software kann im Ergebnis für die grundsätzliche Frage nach der Erschöpfungswirkung nichts anderes gelten. Auch wenn hier im Vergleich zum kommerziellen Softwarevertrieb ein wirtschaftliches Partizipationsinteresse des Urhebers regelmäßig nicht anzunehmen ist, so muss die Verkehrsfähigkeit des Open Source-Computerprogramms dennoch gewährleistet bleiben. Die Interessenlage ist hier nicht grundsätzlich anders. Die grundsätzliche Anwendbarkeit des Erschöpfungsgrundsatzes kann sich zudem nicht danach richten, unter welcher Lizenz (Open Source-Lizenz oder kommerzielle Verwertungslizenz) das jeweilige Programm verbreitet wird. Auch Open Source Software muss sich also zunächst an den Anforderungen des § 69 c Nr. 3 UrhG messen lassen14. 11 12 13 14

Vgl. hierzu § 9. So auch Spindler, in: Spindler, Abschn. C Rn. 97. Hinweis bei Möhring/Nicolini/Hoeren, § 69 c Rn. 14. So auch Spindler, in: Spindler, Abschn. C Rn. 97.

II. Erschöpfungsgrundsatz

217

3. Verhinderung der Erschöpfung bei Open Source Software Nun ist hier aber fraglich, ob die Rechteinhaber von Open Source Software durch Verwendung bestimmter Lizenzbestimmungen eine Erschöpfung verhindern können. Hier wurden verschiedene Lösungswege vorgeschlagen. a) Anwendung des Erschöpfungsgrundsatzes bei Online-Verbreitung von Open Source Software Eine Ansicht in der Literatur schließt grundsätzlich eine Anwendung des Erschöpfungsgrundsatzes bei Onlineverbreitungshandlungen aus15. Da Open Source Software regelmäßig über das Internet verbreitet wird, trete in diesen Fällen auch keine Erschöpfung ein. Hier stellen sich dieser Ansicht nach somit auch die oben dargestellten Probleme nicht. Diese Auffassung kann, wie schon oben dargestellt, nicht überzeugen. Der Erschöpfungsgrundsatz ist vielmehr auch auf Onlineverbreitungshandlungen, also auf die unkörperliche Verbreitung von Software anzuwenden. Daraus folgt, dass sich im Bereich Open Source Software keine Besonderheiten ergeben. Hier bleibt noch einmal ausdrücklich anzumerken, dass die Onlineübertragung mittlerweile auch keine Besonderheit mehr von Open Source Software ist. Würde Software nur noch über Datennetze vertrieben, würde die Vorschrift § 69 c Nr. 3 UrhG völlig bedeutungslos werden. Die Hersteller und Rechteinhaber hätten es allein mit der Entscheidung über den Vertriebsweg in der Hand, die Erschöpfungswirkung auszuschließen. Dies kann letztlich auch nicht im Sinne eines gerechten Interessenausgleichs sein. Eine Anwendung des Erschöpfungsgrundsatzes ist somit auch bei Online-Übermittlung der Software gegeben16 und kann auch nicht abbedungen werden17. b) Umgehung des Erschöpfungsgrundsatzes durch eine inhaltliche Beschränkung des Verbreitungsrechts aa) Erschöpfung beschränkter Verbreitungsrechte Eine Einräumung eines beschränkten Verbreitungsrechts ist grundsätzlich gem. § 31 I S. 2 UrhG möglich. Das Inverkehrbringen von Werkstücken, 15

Kilian/Heussen/Harte-Bavendamm/Wiebe, CHB, Nr. 51 Rn. 108; Spindler, in: Spindler, Abschn. C Rn. 100. 16 So auch Schiffner, S. 135; Möhring/Nicolini/Hoeren, § 69 c Rn. 16. 17 Schricker/Loewenheim, § 69 c Rn. 32.

218

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz

soweit es sich im Rahmen der beschränkt eingeräumten Verbreitungsberechtigung hält, führt dazu, dass die Erschöpfung nur hinsichtlich des beschränkt eingeräumten Teils des Verbreitungsrechts eintritt, nicht hinsichtlich der mittels der Beschränkung von der Rechtseinräumung ausgenommenen Teile18. Eine dinglich wirkende Begrenzung des Nutzungsrechts hat somit auch eine Beschränkung der Erschöpfung zur Folge. Wählt der Lizenznehmer für die Weitergabe einen anderen als den zugelassenen Absatzweg, liegt keine Zustimmung des Rechteinhabers vor. Mangels dieser Zustimmung kann dann auch keine Erschöpfung des Verbreitungsrechts eintreten. Jedoch muss hier beachtet bleiben, dass sich eine dingliche Beschränkung des Nutzungsrechts nicht derart auswirkt, dass der Rechteinhaber nach einem einmal mit seiner Zustimmung erfolgten Inverkehrbringen alle weiteren Verbreitungshandlungen kontrollieren könnte19. Durch seine willentlich vorgenommene Veräußerung gibt er die Herrschaft über das Werkstück auf, und es wird für jede Weiterveräußerung frei20. Die Einräumung eines inhaltlich beschränkten Nutzungsrechts führt folglich nicht dazu, dass die Erschöpfung in der Weise beschränkt wird, dass der Rechteinhaber auf den weiteren, der Erstverbreitung folgenden Absatzweg Einfluss nehmen könnte21. bb) Inhaltlich beschränktes Verbreitungsrecht bei Open Source Software Trotz der oben dargelegten Grundsätze wird ein Lösungsansatz zur Vermeidung einer Erschöpfung des Verbreitungsrechts in der Weisevertreten, dass Open Source Software als eigenständige Nutzungsart einzuordnen ist und eine Erschöpfung nur beschränkt stattfindet. Koch, der jedenfalls für Linux und linuxbasierte Applikationsprogramme von einer eigenständigen Nutzungsart ausgeht, sieht in der Teilung der Verwertung auch eine wirksame Beschränkung des Erschöpfungsgrundsatzes22. Nach seiner Ansicht wird durch die GPL das Verbreitungsrecht derart beschränkt, dass eine Erschöpfung nur für die kostenfreie Verbreitung eintritt und eine etwaige Verbreitung gegen Erhebung eines Entgelts von der Erschöpfung ausgeschlossen ist23. Ein Lizenznehmer darf nach dieser Lösung keine Vergütung für die Weitergabe der Software verlangen. Koch gesteht selbst zu, dass diese 18 BGH, GRUR 1986, S. 736 f.; BGH, GRUR 1959, S. 202 f.; OLG Karlsruhe, GRUR 1984, S. 198 f.; Schricker/Loewenheim, § 17 Rn. 49. 19 BGH, CR 2000, S. 652. 20 BGH, CR 2000, S. 652. 21 BGH, CR 2000, S. 652; Wandtke/Bullinger/Heerma, § 17 Rn. 19. 22 Koch, § 9 Rn. 462; ders., CR 2000, S. 335. 23 Koch, § 9 Rn. 462.

II. Erschöpfungsgrundsatz

219

Auffassung aufgrund der OEM-Entscheidung des BGH nicht unproblematisch ist24. In der Tat sprechen gewichtige Gründe gegen die hier vertretene Ansicht. Es wurde bereits ausführlich darauf eingegangen, warum Open Source Software nicht als eigenständige Nutzungsart anzusehen ist25. Es fehlt jedenfalls an einer technisch eigenständigen Nutzungsart. Insofern wird auf die vorgehenden Ausführungen verwiesen. Lehnt man eine technisch-wirtschaftlich eigenständige Nutzungsart bei unter GPL lizenzierter Software ab, kann auch hinsichtlich der Kostenfreiheit der Rechtseinräumung nicht von einem beschränkten Nutzungsrecht ausgegangen werden. Insofern scheitert dieser Lösungsweg schon an der Annahme einer eigenständigen Nutzungsart. Selbst für den Fall der Annahme einer dinglich wirkenden Begrenzung des Nutzungsrecht durch die Einräumung eines inhaltlich beschränkten Nutzungsrechts gelangt man in der Frage der Erschöpfung zu keinem anderen Ergebnis. Die OEM-Entscheidung des BGH26 ist an dieser Stelle von besonderer Bedeutung. Den in der Rechtsprechung aufgezeigten Lösungswegen muss natürlich nicht notwendigerweise gefolgt werden, da auch eine höchstrichterliche Rechtsprechung einer wissenschaftlichen Auseinandersetzung zugänglich ist. Nun beschäftigt sich diese Arbeit jedoch mit der Umsetzung der GPL in deutsches Recht. Dabei soll der GPL und der damit verbundenen Regelungsinhalte vor dem Hintergrund des UrhG „zum Erfolg“ verholfen werden. Richtigerweise gesteht daher auch Koch zu, dass man seinen Lösungsweg vor dem Hintergrund der Rechtsprechung als unzulässig ansehen kann. Der BGH stellt in seiner Entscheidung ausdrücklich fest, dass eine dingliche Begrenzung eines Nutzungsrechts zwar grundsätzlich auch die Begrenzung der Erschöpfung zur Folge hat, diese Wirkung aber auf die Erstveräußerungshandlung beschränkt bleibt27. Im Rahmen von Zweit- oder Drittveräußerungen kann der Rechteinhaber die Einhaltung seiner ursprünglich vorgenommenen inhaltlichen Beschränkung des Nutzungsrechts nicht mehr kontrollieren, da eine Erschöpfung eingetreten ist. Somit hilft in diesem Zusammenhang selbst die Einordnung von Open Source Software als eigenständige Nutzungsart nicht weiter. Die Erschöpfung lässt sich bei auf die Erstverbreitung folgenden Veräußerungshandlungen nicht wirksam beschränken. Vor diesem Hintergrund ist die von Koch vertretene Lösung zur Vermeidung einer Erschöpfung abzulehnen28. 24 25 26 27 28

Koch, § 9 Rn. 462. Vgl. § 7 II. 3. BGH, CR 2000, S. 651 ff. BGH, CR 2000, S. 652. So auch Schiffner, S. 138 ff.

220

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz

c) Umgehung einer Erschöpfungswirkung durch Ausschluss von Erwerbskette bei der Lizenzeinräumung Es wurde an früherer Stelle bereits besprochen, dass die Rechte an einem Open Source-Programm nicht im Wege von Verwertungsketten eingeräumt werden. So bestimmt § 6 GPL, dass ein Programmnutzer seine lizenzrechtlichen Befugnisse unmittelbar vom Urheber erhält. Das bedeutet, dass auch bei einer Weitergabe der Software keine Unterlizenz eingeräumt wird, sondern regelmäßig ein neuer Lizenzvertrag zwischen dem Urheber und dem neuen Nutzer geschlossen wird29. Fraglich ist, ob diese Konstruktion geeignet ist, die Erschöpfung im Zusammenhang mit der Verbreitung zu umgehen. aa) Beschränkte Bindungswirkung der GPL in der Vertriebskette Nach einer Ansicht30 werden die dinglichen Bindungswirkungen der GPL ab der ersten Vertriebsstufe aufgehoben, soweit die Voraussetzungen der Erschöpfung gem. § 69 c Nr. 3 UrhG vorliegen. Die jeweilige Open Source Software kann dann ohne weitere Beschränkungen hinsichtlich der Erhebung von Lizenzgebühren weiterveräußert werden. Die auf die eingetretene Erschöpfung folgende Weiterverbreitung kann urheberrechtlich-dinglich nicht mehr eingeschränkt werden. Einem Zweiterwerber stehen mangels wirksamer Vereinbarung der GPL lediglich die Rechte aus § 69 d UrhG zu, was zur Folge hat, dass er jedenfalls zur Veränderung der Software nicht berechtigt ist. Der Zweiterwerber kann dieser Ansicht nach die Rechte der GPL nur dann in Anspruch nehmen, wenn er seinerseits die GPL mit einem Folgeerwerber vereinbart. Diese Ansicht kommt zu dem Ergebnis, dass der Zweiterwerber einer Open Source Software keinen urheberrechtlich-dinglich wirkenden Beschränkungen bei der Weiterveräußerung unterliegt, da sich das Verbreitungsrecht mit der Inverkehrgabe durch den Ersterwerber erschöpft hat31. Der Zweiterwerber kann die Software somit auch unter Verletzung der GPL an Dritte weiterveräußern, da die ursprüngliche Beschränkung des Verbreitungsrechts ihm gegenüber nicht greift32. Verstößt hingegen der Ersterwerber gegen die GPL, greift der Erschöpfungsgrundsatz nicht ein, da keine Inverkehrgabe mit Zustimmung des Urhebers vorliegt33. Ein Verstoß gegen die GPL führt hiernach zu einem 29 30 31 32 33

Spindler/Wiebe, Spindler/Wiebe, Spindler/Wiebe, Spindler/Wiebe, Spindler/Wiebe,

CR CR CR CR CR

2003, 2003, 2003, 2003, 2003,

S. S. S. S. S.

873. 878; Spindler, in: Spindler, Abschn. C Rn. 93 ff. 877. 877. 878.

II. Erschöpfungsgrundsatz

221

Rechtewegfall, der wiederum auch die Zustimmung des Rechteinhabers gem. § 17 II UrhG entfallen lässt. Es ist in diesen Fällen somit keine Erschöpfung des Verbreitungsrechts eingetreten und der Nutzer ist weiterhin an seine Pflichten der GPL gebunden. Aufgrund der Regelung des § 4 GPL entfallen infolge eines Lizenzverstoßes durch den Veräußerer alle seine Rechte, sodass es dann auch zu keiner weiteren Nutzungsrechtseinräumung oder zu einem Vertragsschluss kommen kann. Zur Begründung dieser Ansicht wird auf die OEM-Entscheidung34 des BGH verwiesen. Spindler/Wiebe stellen heraus, dass das Gericht in seiner Entscheidung eine Absicherung einer schuldrechtlichen Pflicht durch das Verbreitungsrecht abgelehnt hat35. Die Verkehrsfähigkeit des Werkstückes muss grundsätzlich erhalten bleiben. Die angeführte Entscheidung weise darauf hin, dass eine Beschränkung der Erschöpfung dahin führe, dass vertragliche Bindungen auch gegenüber jedem Dritten wirken würden. Eine derartige Verdinglichung schuldrechtlicher Verpflichtungen sei dem deutschen Recht fremd. Das führe dazu, dass der dinglich wirkende Vorhalt der GPL gegenstandslos sei. Wenn der Ersterwerber die Software rechtmäßig erworben habe, müsse er für die Weitergabe an Dritte das Verbreitungsrecht in Anspruch nehmen, welches sich aber gem. der OEM-Entscheidung36 des BGH erschöpft habe. Dann unterliege aber auch der Zweiterwerber einer Open Source Software keinen urheberrechtlich-dinglich wirkenden Beschränkungen bei einer Weiterveräußerung, da das Verbreitungsrecht mit der Erstverbreitung erschöpft sei. Er bedürfe keines Verbreitungsrechtes mehr und sei urheberrechtlich frei. Der Zweiterwerber könne die Software auch gegen Entgelt weiterveräußern. Auch spreche die Regelung der Ziff. 6 GPL und die damit verbundene Konstruktion des Direkterwerbs nicht gegen dieses Ergebnis. Der Zweiterwerber erhalte vielmehr ein Wahlrecht dahingehend, dass er einerseits die Rechte gem. § 69 d UrhG wahrnehmen könne, andererseits aber auch die Möglichkeit behält, die GPL als Lizenznehmer anzunehmen. bb) Stellungnahme Die oben dargestellte Ansicht vermag bei genauerer Betrachtung des Vorgangs der Lizenzvergabe bei Open Source Software nicht zu überzeugen. Die in Ziff. 6 GPL normierte Konstruktion des Direkterwerbs vermag entgegen der Auffassung von Spindler/Wiebe sehr wohl eine Erschöpfung des Verbreitungsrechts vermeiden37. Gerade die Annahme eines regelmäßigen 34 35 36

BGH, CR 2000, S. 651 ff. Spindler/Wiebe, CR 2003, S. 877. BGH, CR 2000, S. 651 ff.

222

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz

Direkterwerbs der lizenzrechtlichen Befugnisse durch einen Softwarenutzer i. S. d. Ziff. 6 GPL im Zusammenspiel mit der Regelung Ziff. 4 GPL führt dazu, dass eine rechtmäßige Weitergabe einer Open Source Software gegen Entgelt unmöglich ist. Dazu ist es notwendig, sich den Vorgang der Rechtsübertragung durch Erst-, Zweit- oder Dritterwerber in Verbindung mit Ziff. 4 GPL zu verdeutlichen. Wie bereits oben dargestellt, erfolgt die Rechtseinräumung gem. Ziff. 4 GPL unter der auflösenden Bedingung der Einhaltung der Lizenzbedingungen. Gibt der Urheber oder Rechteinhaber die Software an einen Nutzer weiter, so kann der Nutzer die GPL annehmen und das Computerprogramm entsprechend den Lizenzbedingungen benutzen. Er kann es auf seiner Arbeitsstation ablaufen lassen, verändern, kopieren und an einen Dritten weitergeben. Wird die Software von einem Nutzer an jemand Dritten weitergegeben, regelt Ziff. 6 GPL, dass der neue „Erwerber“ die Lizenzrechte direkt vom Urheber erhält. Bezogen auf die urheberrechtlichen Nutzungsrechte ist jeder Erwerb ein „Ersterwerb“38.Will der Ersterwerber, also derjenige, der das Computerprogramm vom Rechteinhaber erhält und die Nutzungsrechte infolge der Annahme der GPL von ihm eingeräumt bekommen hat, das Programm nun gegen Entgelt39 an einen Dritte weiterveräußern, verliert er in dem Moment gem. Ziff. 4 GPL alle seine lizenzrechtlichen Befugnisse, in dem er das Programm dem Dritten gegen Entgelt anbietet. Er ist zu dieser Weitergabe des Computerprogramms somit nicht berechtigt. Vielmehr liegt darin schon eine Urheberrechtsverletzung, die entsprechend den §§ 97 ff. UrhG verfolgt werden kann. Die reine Rechtseinräumung urheberrechtlicher Nutzungsrechte erfolgt grundsätzlich gem. 398 BGB, der die urheberrechtlichen Vorschriften an dieser Stelle ergänzt40. Ist jemand aber zur Rechtsübertragung nicht berechtigt, kommt auch kein gutgläubiger Erwerb von Nutzungsrechten durch einen Dritten in Betracht41. Das Urheberrecht kennt keinen Gutglaubenserwerb von Nutzungsrechten. Auf Open Source Software bezogen muss man hier allerdings genau differenzieren. Ein Erwerb vom Nichtberechtigten kommt hier aufgrund der Ziff. 6 GPL gar nicht in 37

So auch LG München I, CR 2004, S. 776; Schiffner, S. 142; Jaeger/Metzger, S. 32 Fn. 126. 38 Jaeger/Metzger, S. 32 Fn. 126. 39 Dabei ist die Erhebung von Lizenzgebühren gemeint und nicht die Erstattung etwaiger Kopierkosten. 40 Schricker/Schricker, Vor §§ 28 ff. Rn. 45; Dreier/Schulze, § 31 Rn. 15; Für eine jedenfalls analoge Anwendung der §§ 398 ff. BGB: Wandtke/Bullinger/ Wandtke/Grunert, Vor §§ 31 ff. Rn. 18; Schack, Rn. 536. 41 BGH, GRUR 1952, S. 530; BGH, GRUR 1959, S. 200, 203; Loewenheim/Jan Bernd Nordemann, § 26 Rn. 9; Schricker/Schricker, Vor §§ 28 ff. Rn. 63 mit weiteren Nachweisen.

II. Erschöpfungsgrundsatz

223

Frage, da ein Nutzer die Rechte immer vom Urheber erhält. Die Regelung der Ziff. 4 GPL hat hier aber eine andere Funktion. Der Erstverbreiter verliert durch die Weitergabe der Software gegen Entgelt seine Lizenzrechte und infolge dessen auch seine Botenstellung, die ihm durch die GPL im Rahmen einer Weitergabe grundsätzlich zuteil wird. Ein Dritter kann somit vom Ersterwerber, der das Open Source-Computerprogramm gegen Erhebung von Lizenzgebühren an diesen weitergibt, auch nicht gutgläubig Lizenzrechte erwerben, da der Weitergebende im Zeitpunkt der Entgeltforderung seine Lizenzrechte gem. § 158 II BGB verliert und nun Nichtberechtigter mit der Folge des Verlustes seiner Botenstellung ist. Der Dritte behält in dieser Situation „lediglich“ die Möglichkeit, die Rechte der GPL vom Rechteinhaber selbst anzunehmen, womit er dann aber wieder an die normierte Kostenfreiheit der Verbreitung gebunden wäre. Nimmt er die Rechte nicht an, ist es ihm gem. Ziff. 5 GPL verboten, das Programm zu benutzen42. Hat nun ein Zweiterwerber das Computerprogramm vom Ersterwerber erhalten und will dieses nun seinerseits gegen Entgelt an einen Dritten weitergeben, ändert auch dies im Hinblick auf eine mögliche Erschöpfung nichts. Der Zweiterwerber muss, um überhaupt eine urheberrechtlich relevante Handlung rechtmäßig vornehmen zu können, die GPL gem. Ziff. 6 GPL vom Rechteinhaber annehmen. Damit unterliegt aber auch jeder Zweiterwerber den lizenzrechtlichen Bindungen der GPL. Will also der Zweiterwerber für die Rechtseinräumung an einen Dritten seinerseits wieder ein Entgelt verlangen, gilt das oben Gesagte entsprechend. Der Zweiterwerber verstößt gegen die GPL und verliert sämtliche Lizenzrechte. Dem Dritten steht auch in diesem Fall ein Nichtberechtigter ohne Botenstellung gegenüber, von dem er auch nicht gutgläubig die Nutzungsrechte erwerben kann. Er kann die Rechte ja regelmäßig nur vom Urheber eingeräumt bekommen. Verdeutlicht man sich aber diesen rechtlich ausgestalteten Verbreitungsweg, dann kommt es auch zu keiner Erschöpfung. Die Lizenzbedingungen greifen somit auch dann durch, wenn die Software nicht direkt vom Urheber übermittelt wird43. Das OEM-Urteil steht dieser Lösung auch nicht entgegen. Derjenige, der im Rahmen der Verbreitung von Open Source Software ein Entgelt erheben will, verliert sämtliche Rechte. Er kann das Verbreitungsrecht gar nicht mehr rechtmäßig in Anspruch nehmen. Insofern gibt es keine Weiterverbreitung i. S. d. § 17 UrhG. Der Entscheidung des BGH liegt somit ein anderer Sachverhalt zugrunde. Die OEM-Entscheidung geht nämlich von einem 42 Ziff. 5 GPL: „You are not required to accept this License, since you have not signed it. However nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License . . .“. 43 So auch Jaeger/Metzger, S. 32 Fn. 126.

224

§ 8 Vereinbarkeit der GPL mit dem Erschöpfungsgrundsatz

„normalen“ Verbreitungsvorgang gem. § 17 UrhG aus. Dieser liegt aber bei Open Source Software nicht vor, da erklärtermaßen in jeder Weitergabe ein Ersterwerb liegt. Auch die Einräumung eines etwaigen Wahlrechts, wie oben dargestellt, ist abzulehnen. § 69 d UrhG, der von Spindler/Wiebe angeführt wird, privilegiert regelmäßig nur denjenigen, der zur Verwendung des urheberrechtlich geschützten Programms berechtigt ist44. Die Regelung hat den Zweck, fehlende ausdrücklich vereinbarte vertragliche Regelungen zu ergänzen und somit einen bereits bestehenden Vertrag zu ergänzen45. Derjenige aber, der das Programm von einem Dritten erwirbt, ohne die GPL anzunehmen, ist kein berechtigter Besitzer. Es besteht in diesen Fällen überhaupt keine vertragliche Beziehung zum Rechteinhaber, die es zu ergänzen gäbe. Der Nutzer darf in diesen Fällen das Programm nicht benutzen und kann somit auch nicht die Rechte nach § 69 d UrhG ausüben. Folglich kann auch diese Vorschrift hier nicht herangezogen werden. Bei Open Source Software, soweit sie jedenfalls unter der GPL lizenziert ist, kommt es folglich zu keiner Erschöpfung des Verbreitungsrecht, da regelmäßig ein Ersterwerb lizenzrechtlicher Befugnisse vorliegt46. Selbst wenn man aber die Konstruktion des Ersterwerbs ablehnt, hilft Ziff. 4 GPL insofern weiter, als dass derjenige, der gegen die Bedingung der Kostenfreiheit bei der Weitergabe verstößt, sämtliche Lizenzrechte verliert und somit Nichtberechtigter ist. Wie dargelegt können Lizenzrechte von einem Nichtberechtigten auch nicht gutgläubig erworben werden. In jedem Fall kann also die Kostenfreiheit der Rechtseinräumung nicht rechtmäßig im Rahmen einer Weiterverbreitung aufgehoben werden. d) Ergebnis Wie sich gezeigt hat, stellt der Erschöpfungsgrundsatz des UrhG kein Problem für das Verbreitungsmodell Open Source Software dar. Die Aufrechterhaltung der Kostenfreiheit kann aufgrund der besonderen Lizenzgestaltung auch in Verbreitungsketten gewährleistet werden. Es ist demnach nicht möglich, auf rechtmäßigem Wege Lizenzkosten für Open Source Software zu erheben, vorausgesetzt, die Lizenzen enthalten den Ziff. 4, 6 GPL entsprechende Formulierungen.

44 45 46

Dreier/Schulze, § 69 d Rn. 2. Wandtke/Bullinger/Grützmacher, § 69 d Rn. 6. So auch Heussen, MMR 2004, S. 449.

§ 9 Vertragliche Einordnung der Softwareüberlassung bei Open Source Software Bei Open Source Software spielen urhebervertragliche Aspekte eine bedeutende Rolle. Bereits in den vorausgegangenen Abschnitten wurde auf Aspekte des Urhebervertragsrechts eingegangen. So wurde bereits dargestellt, welche Rechte regelmäßig eingeräumt werden und wie sie mit den Bedingungen und Verpflichtungen dogmatisch verknüpft sind. Im Folgenden geht es nun um die rein vertragsrechtlichen Fragen von Open Source Software, um Fragen der vertragliche Qualifizierung von Open Source Software, AGB-rechtliche Fragen, Fragen des Vertragsschlusses und um die Gewährleistungs- und Haftungsproblematik.

I. Nicht durch Distributoren vertriebene Software Die Frage nach der rechtlichen Einordnung von Softwareüberlassungsverträgen erhebt sich nicht nur bei „proprietärer“ Software. Auch bei Open Source Software stellt sich die Frage, aufgrund welchen vertraglichen Grundgeschäfts die Nutzungsrechte übertragen werden. Die vertragsrechtliche Einordnung ist schon bei der Überlassung von proprietärer Software problematisch und teilweise umstritten. Auch bei Open Source Software hat das Schrifttum verschiedene Möglichkeiten diskutiert. Das erste Urteil zum Thema Open Source Software1 enthält keine Ausführungen zur vertragsrechtlichen Einordnung der Überlassung von Open Source Software, sondern geht lediglich auf die Frage ein, inwieweit die Lizenzbedingungen unter AGB-Vorschriften zu subsumieren sind. Insoweit bleibt die Frage der vertraglichen Einordnung von großem Interesse und kann, wie sich im Folgenden zeigen wird, keinesfalls als geklärt angesehen werden. Es gibt einige Stimmen in der Literatur, die ihre rechtliche Beurteilung dahingehend differenzieren, ob die Software über einen Distributor vertreiben wird oder aber die Anwender sich das Programm direkt über das Internet oder von Dritten beschaffen. Der Übersichtlichkeit halber soll diese Differenzierung daher auch hier erfolgen. Zum Teil wird auch noch danach differenziert, wie die einzelnen unterschiedlichen Übertragungswege der Software vertraglich einzuordnen sind2. Im Folgenden wird zunächst davon 1

LG München I, CR 2004, S. 775.

15 Teupen

226

§ 9 Vertragliche Einordnung der Softwareüberlassung

ausgegangen, dass sich der Anwender das Programm jedenfalls nicht gegen Zahlung eines Entgeltes von einem Distributor beschafft. 1. Vorbemerkung Am Verbreitungsvorgang als solchen anzuknüpfen ist wenig überzeugend und hat mit der Frage nach der vertraglichen Qualifizierung der Nutzungsrechtseinräumung wenig zu tun. Wie ein unter einer Open Source-Lizenz freigegebenes Computerprogramm verbreitet wird, entscheiden Rechteinhaber und Anwender. Das Programm wird in der Regel im Internet zum Download angeboten, die Anwender tauschen es per E-Mail aus, tauschen körperliche Datenträger (gegen Entgelt oder kostenlos) untereinander aus, oder das Programm wird durch einen Distributor gegen Entgelt professionell in Online-Shops oder im Einzelhandel angeboten. Für die Frage der vertraglichen Einordnung kann es aber nicht auf den Verbreitungsvorgang als solchen ankommen. Die Frage, welcher Typ Überlassungsvertrag einer Open Source-Lizenz zugrunde liegt, kann sich nur nach der Konzeption der Lizenz richten und nicht danach, welche Verbreitungswege die Nutzergemeinde letztendlich wählt. Natürlich ist es denkbar, dass Nutzer miteinander Kaufverträge bezüglich der Datenträger oder Gefälligkeitsverträge miteinander schließen. Insofern lassen sich die Rechtsgeschäfte im Umfeld von Open Source Software keinesfalls einheitlich typisieren3. Um diese Geschäfte im Umfeld geht es aber eben nicht. Diese können nicht maßgeblich für die Frage sein, wie Open Source Software an sich vertragsrechtlich zu beurteilen ist. Es geht hier allein um die abstrakte Frage, aufgrund welchen Vertragstypus die Nutzungsrechte vom Rechteinhaber übertragen werden, nicht darum, wie die Nutzer eine etwaige Weitergabe der Software vertraglich ausgestalten. Das liegt im Rahmen ihrer Entscheidung und ist lediglich bezüglich einer Vereinbarkeit mit der jeweiligen Open Source-Lizenz zu überprüfen. Im Folgenden ist daher allein das Grundgeschäft zu beurteilen, das der Einräumung der Nutzungsrechte durch den Rechteinhaber zugrunde liegt. 2. Vertragsbeziehungen als BGB-Gesellschaft Eine Möglichkeit der rechtlichen Ausgestaltung der vertraglichen Grundlage der Nutzungsrechtseinräumung könnte die Annahme einer BGB-Gesellschaft sein4. Dafür müsste das Open Source Modell unter die Anwendungs2 3 4

Schiffner, S. 222. Schiffner, S. 238. Dazu Sester, CR 2000, S. 801 ff.

I. Nicht durch Distributoren vertriebene Software

227

voraussetzungen der Vorschriften der BGB-Gesellschaft §§ 705 ff. BGB zu subsumieren sein. Voraussetzung einer BGB-Gesellschaft ist der Abschluss eines Gesellschaftsvertrages, der auf die Erreichung eines gemeinsamen Zweckes gerichtet ist. Dabei kann der Zweck ein wirtschaftlicher, kultureller oder auch ideeller sein. Ein Open Source-Softwareprojekt, das die gemeinschaftliche Programmierung, die ständige Verbesserung und kontinuierliche Verbreitung durch die Nutzer zum Zwecke hat, soll sich nach einer Ansicht grundsätzlich als Gesellschaftszweck einordnen lassen5. Diese Sichtweise ist abzulehnen. Bereits bei der Frage nach dem rechtlichen Verhältnis der Urheber der Originalsoftware zu den Urhebern von Bearbeitungen ist darauf eingegangen worden, dass ein klarer Gesellschaftszweck bei Open Source-Projekten regelmäßig nicht anzunehmen ist6. Auch bestehen keine Förderungspflichten. Die Entscheidung, was ein Nutzer mit dem Computerprogramm macht, liegt bei ihm selbst. Die Pflichten der GPL kann man schwer als Förderungspflichten aus einem Gesellschaftsvertrag einordnen, da sie im Einzelfall aufgrund der Unmöglichkeit der Individualisierung des Anspruchsgegners auch nicht einklagbar wären. Kommt ein Nutzer, der ein Programm bearbeitet, seinen Lizenzpflichten nicht nach, verliert er „lediglich“ seine Lizenzrechte. Rechteinhaber sowie andere Programmierer können ihn aber nicht zur Vornahme der Pflichten anhalten. Zudem ist weder ein gemeinsames Haftungskapital gegeben, noch werden Vertretungsbefugnisse übertragen und zwischen den Beteiligten liegt auch keine Haftungsgemeinschaft vor7. Eine der Gesellschaftsformen entsprechende dauerhafte personelle Organisiertheit fehlt grundsätzlich vollständig. Nach vermittelnder Ansicht sollen die Grundsätze der BGB-Gesellschaft nur für den (Lizenz-) Bereich angewendet werden, in denen der Anwender von seinem Veränderungsrecht Gebrauch macht und die Software im Anschluss weiterverbreitet8. Da eine beiderseitige Verpflichtung notwendig sei, könnten Auftrag wie Schenkung aufgrund des Gegenseitigkeitserfordernis nicht weiterhelfen. Dies ist ebenfalls nicht überzeugend. Was den für eine BGB-Gesellschaft erforderlichen Gesellschaftszweck und die Frage nach Förderungsbeiträgen angeht, kann zunächst auf die oben gemachten Ausführungen verwiesen werden9. Aber noch ein weiterer Grund spricht gegen die Annahme einer BGBGesellschaft. Das jederzeitige Kündigungsrecht eines Gesellschafters gem. 5 6 7 8 9 15*

Sester, CR 2000, S. 801. Vgl. § 5 III. 1. b). Dies erkennt Sester zutreffend: Sester, CR 2000, S. 801. Schiffner, S. 232 ff. Vgl. § 5 III. 1. b).

228

§ 9 Vertragliche Einordnung der Softwareüberlassung

§ 723 I BGB erscheint in diesem Zusammenhang problematisch. Hat ein Programmierer das Open Source-Softwareprogramm erst einmal verändert, bleibt er ja an die Lizenzbedingungen gebunden. Er kann nicht einfach kündigen und damit seine Bindungen umgehen. Nun kann man entgegnen, dass aufgrund der lizenzrechtlichen Besonderheiten an dieser Stelle eine abweichende Vereinbarung im Gesellschaftsvertrag getroffen wird. Dies wäre jedoch gem. § 723 III BGB unzulässig. Das Kündigungsrecht ist nach dieser Vorschrift keiner Beschränkung zugänglich. Letztlich ist noch anzuführen, dass die Differenzierung dieser Literaturmeinung indem sie bezüglich der Veränderung und Weiterverbreitung gesondert das Vorliegen ein BGB-Gesellschaft für möglich hält, dazu führt, dass man die Open Source Software-Überlassung in Bezug auf das Grundgeschäft in verschiedene Vertragsarten aufspaltet. Das würde dazu führen, dass einer einheitlichen Softwareüberlassung mehrere Grundgeschäfte zugrunde liegen. Das überzeugt letztlich nicht. Vielmehr sollte man hier das Ziel haben, ein einheitliches Rechtsgeschäft als Grundgeschäft auszumachen. Jenseits der verbleibenden Möglichkeit, dass in einem konkreten Einzelfall tatsächlich vom Vorliegen einer BGB-Gesellschaft gesprochen werden kann, ist im Regelfall davon auszugehen, dass die Überlassung von Open Source Software nicht aufgrund gesellschaftsrechtlicher Vereinbarungen erfolgt. Im Ergebnis muss daher das Vorliegen einer BGB-Gesellschaft abgelehnt werden10. 3. „Open Source-Entwicklervertrag“ als Vertrag sui generis Ausgehend von den Überlegungen zum Vorliegen einer BGB-Gesellschaft sieht ein Teil der Literatur im Zusammenhang mit Entwicklergemeinschaften auch die grundsätzliche Möglichkeit, das Vorliegen eines Vertrages sui generis gem. §§ 311, 241 BGB anzunehmen11. Dieser Ansicht nach hat das den Vorteil, dass der Inhalt des Vertrags frei nach den Interessen der Beteiligten zu bestimmen ist und ein gesetzliches Vertragskorsett in diesem Fall entbehrlich wäre. Die einzelnen Vertragspflichten ergeben sich dabei aus der entsprechenden Open Source-Lizenz. Im Ergebnis zieht Schiffner aber die Lösung über die BGB-Gesellschaft vor, da normierte Regelungen seiner Meinung nach eine überzeugendere Lösung seien. Dieser Lösungsweg ist richtigerweise abzulehnen. Auch hier würde bei der Frage nach dem Grundgeschäft der Open Source Software-Überlassung 10 So im Ergebnis auch Jaeger/Metzger, S. 144 f.; Spindler, in: Spindler, Abschn. D Rn. 10. 11 Schiffner, S. 237 f.

I. Nicht durch Distributoren vertriebene Software

229

ein einheitlicher Sachverhalt rechtlich aufgespalten und danach differenziert, ob jemand selbst Veränderungen vornimmt oder „nur“ reiner Softwarenutzer ist. Dies kann aber nicht überzeugen. Vielmehr gilt es ein Grundgeschäft zu finden, dass alle Konstellationen einheitlich beantwortet. Eine vertragliche Lösung jedenfalls, die je nach eingeräumten Nutzungsrecht unterschiedlich ausfällt, ist abzulehnen. 4. Open Source Software-Überlassung als Kaufvertrag gem. § 433 I BGB Eine Literaturmeinung geht auf die vertragliche Einordnung des Grundgeschäftes nur am Rande ein12. In den Fällen zumindest, in denen für den Erwerb der Software ein Entgelt zu entrichten ist, „dass für die Tätigkeit des Vervielfältigens und das Vervielfältigungsmaterials genommen werden darf“, nimmt Omsels das Vorliegen eines Kaufvertrages mit den einschlägigen Gewährleistungspflichten vor13. Auch hier gilt es wieder anzumerken, dass nicht der Weitergabevorgang im Zentrum der Vertragseinordnung steht, sondern die Frage der reinen Rechtseinräumung. Die Software kann auf verschiedenen Wegen weitergegeben werden, die Rechte an ihr werden aber immer in der gleichen Art und Weise eingeräumt. Insofern stellt auch Omsels auf „nur“ auf den Weitergabevorgang ab. Diese Einordnung bietet die Möglichkeit, sich nochmals die Konsequenz dieser vertraglichen Einordnung zu vergegenwärtigen. Die GPL räumt den Anwendern gem. Ziff. 1 GPL zwar durchaus die Möglichkeit ein, für den reinen Kopiervorgang oder für die Gewährung einer Garantie ein Entgelt zu verlangen. Es handelt sich aber nicht um ein Entgelt für die Rechtseinräumung an der Open Source Software. Denn dies ist nach der GPL nicht erlaubt. Die reine Softwareüberlassung lässt sich damit aber auch dann nicht dem Kaufrecht unterwerfen. Würde man dem Lösungsweg dennoch folgen, käme man aufgrund der kaufrechtlichen Gewährleistungsregelungen zu großen Wertungswidersprüchen. Würde man nämlich jede Weitergabe gegen Erhebung eines Entgeltes für Kopier- und Datenträgerkosten unter das Kaufrecht stellen, so haftet der „Verbreiter“ regelmäßig nach kaufrechtlichen Gewährleistungsregeln. Gibt beispielsweise eine Privatperson ein Programm gegen Entgelt an ein mittelständisches Unternehmen weiter, würde sie nach kaufrechtlichen Gewährleistungsregeln haften, sollte es durch einen Programmfehler zu Schäden im Unternehmen kommen. Dies kann nicht wirklich gewollt sein. Diese Wertung würde das Open Source-Verbreitungsmodell zu einem hohen Risiko für jeden Anwender machen. Die Regelung, dass ein Entgelt 12 13

Omsels, in: Festschrift für Paul W. Hertin, S. 151, Fn. 24. Omsels, in: Festschrift für Paul W. Hertin, S. 151, Fn. 24.

230

§ 9 Vertragliche Einordnung der Softwareüberlassung

für Verbreitungskosten erhoben werden darf, will lediglich klar stellen, dass sich die Kostenfreiheit auf die Softwareüberlassung bezieht, nicht aber die Erhebung von „Begleitkosten“, die mit einer Verbreitung notwendig einhergehen können. Der Verbreitungsvorgang kann hier nicht mit der Rechtseinräumung gleichgesetzt werden. Für diese darf kein Entgelt erhoben werden. Es wäre dann aber auch nicht überzeugend, einem Nutzer sämtliche Gewährleistungsrechte aufzubürden, wenn er die allein für den reinen Verbreitungsvorgang entstehenden Kosten an den Empfänger weitergibt, für die Rechtseinräumung als solche aber kein Entgelt erheben darf. Im Ergebnis muss auch hier wieder kritisiert werden, dass auf den Verbreitungsweg und nicht auf die Rechtseinräumung abgestellt wird. Die Anwendung kaufrechtlicher Vorschriften ist jedenfalls bei nicht-distributiver Weiterverbreitung abzulehnen. 5. Software-Download als Auftrag gem. § 662 BGB Eine Ansicht qualifiziert die Bereitstellung der Software zum kostenlosen Download von einem Server als Auftrag i. S. d. § 622 BGB14. Richtigerweise ist die Anwendung des Auftragsrecht auf die Open Source SoftwareÜberlassung jedoch abzulehnen. Es erscheint hier schon fraglich, ob überhaupt von einem wirksamen Auftragsverhältnis gesprochen werden kann. Das der Beauftrage das Geschäft unentgeltlich besorgt, kann für sich noch kein hinreichender Grund sein, ein Auftragsverhältnis anzunehmen. Wer soll hier als Auftraggeber, wer als Auftragnehmer fungieren? Derjenige, der ein Open Source-Programm zum Download auf einem Server bereithält, müsste regelmäßig Beauftragter i. S. d. § 662 BGB sein. Dann müsste ihm aber ein Rechtsgeschäft übertragen worden sein mit der Pflicht, diese für einen anderen unentgeltlich zu besorgen. Nun ist niemand verpflichtet, ein Open Source-Programm über eine Serverdownload-Möglichkeit bereitzuhalten. Die GPL und andere Open Source-Lizenzen geben keinen Anhaltspunkt dafür her, noch begründen sie eine Pflicht dahingehend. Derjenige, der einen solchen „Dienst“ anbietet, bietet ihn regelmäßig aus Eigeninteresse an. Ein weiteres wichtiges Argument, ein Auftragsverhältnis abzulehnen, liegt jedoch im Haftungsmaßstab des Auftragsrechts. Der Beauftragte haftet bei Nicht- oder Schlechterfüllung gem. § 276 I BGB für Vorsatz und Fahrlässigkeit15. Dies ist aber im Hinblick auf die in Open Source-Lizenzen regelmäßig vereinbarten Haftungsausschlüsse problematisch. Der Haftungsmaßstab des § 662 BGB ist wesentlich strenger als der Open Source-Haftungsmaßstab allgemein formuliert ist. Würde man dieser Ansicht im Falle 14 15

Marly, Rn. 427. Palandt/Sprau, § 662 Rn. 11.

I. Nicht durch Distributoren vertriebene Software

231

der Downloadmöglichkeit folgen und Auftragsrecht anwenden, würde das zu einer unbilligen Haftung desjenigen führen, der ein Open Source-Programm kostenlos zum Download online anbietet. Regelmäßig will er sich einer entsprechenden Haftung nicht unterwerfen und einem Nutzer dürfte dies aufgrund der Kostenfreiheit auch klar sein. Ein anderes Ergebnis an dieser Stelle würde eine Open Source-Verbreitung, die ja vorwiegend über das Internet vonstatten geht mit zu hohen rechtlichen Risiken versehen und praktisch zum Erliegen bringen. Daher erscheint das Auftragsrecht in diesem Zusammenhang als kein rechtlich sinnvolles Grundgerüst16. 6. Ausgestaltung des Grundgeschäfts als Leihe gem. §§ 598 ff. Die Einordnung einer Open Source Software-Überlassung als Miete gem. §§ 535 ff. BGB kommt aufgrund der gesetzlichen Pflichten Mietvertragsparteien nicht in Betracht. Die Miete als entgeltliche Gebrauchüberlassung auf Zeit ist das Gegenteil einer kostenfreien Rechtseinräumung bei Open Source Software. Die gegenseitigen Vertragspflichtungen wie auch die Haftungsfolgen eines Mietrechtsverhältnisses stehen dem Zweck einer Open Source Software-Überlassung offensichtlich entgegen. Man könnte jedoch auf die Idee kommen, das Grundgeschäft als Leihe zu qualifizieren. Grundsätzlich ist es denkbar, Software zu verleihen17. Wesen des Leihvertrags ist die unentgeltliche Gebrauchsüberlassung. Als Folge der Unentgeltlichkeit und der damit verbundenen Uneigennützigkeit des Verleihers normiert § 599 BGB lediglich eine Haftung für Vorsatz und grobe Fahrlässigkeit. Auf den ersten Blick scheint auch der Haftungsmaßstab für das Open Source Konzept „wie gemacht“18. Allerdings handelt es sich bei der Leihe auch um eine zeitliche Gebrauchsüberlassung. Die Leihe kann zeitlich befristet sein (§ 604 I BGB), aber auch unbefristet (§ 604 II, III BGB). Der Ausleiher hat also in jedem Fall eine Rückgabepflicht. Diese wird entweder mit Ablauf der vereinbarten Zeit fällig oder mit Forderung des Ausleihers, die Sache zurückzugeben. An diesem Punkt aber wird deutlich, dass auch die Leihe kein Grundgeschäft einer Open Source SoftwareÜberlassung sein kann. Die Nutzungsrechte an Open Source Software werden grundsätzlich nicht zeitlich beschränkt eingeräumt. Benutzt jemand das 16 I. E. auch Jaeger/Metzger, S. 139 mit weiterem Nachweis, Spindler, in: Spindler, Abschn. D Rn. 4. 17 Hier soll zunächst die Frage nach dem ökonomischen Sinn eines derartigen Vorgehens vernachlässigt werden. Denkbar wäre es beispielsweise, dass jemand, der Hardware absetzten will, diese mit Software ausstattet, ohne sie aber zu verkaufen (u. U. spricht der Haftungsmaßstab der Leihe für ein derartiges Vorgehen). 18 Auf den generellen Haftungs- und Gewährleistungsausschluss in Open SourceLizenzen wird im Folgenden noch genauer eingegangen.

232

§ 9 Vertragliche Einordnung der Softwareüberlassung

Programm entsprechend der GPL, findet weder ein Rechterückfall aufgrund Zeitablaufs statt, noch kann der Rechteinhaber die Nutzungsrechte aufheben und die Software zurückfordern. Ein Rechterückfall findet allein aufgrund eines Lizenzverstoßes durch den Anwender statt. Befolgt er Anwender jedoch die Lizenz, kann er die Software zeitlich unbeschränkt nutzen. Hier liegt der Hauptgrund zur zeitlich befristeten Leihe. Daher kann ein Leihvertrag als Grundgeschäft der Überlassung von Open Source Software rechtlich nicht überzeugen. 7. Open Source Software-Überlassung als Schenkung gem. §§ 516 ff. BGB Die überwiegende Literaturmeinung vertritt die Ansicht, dass das der Softwareüberlassung zugrunde liegende Rechtsgeschäft als Schenkung gem. §§ 516 ff. BGB zu qualifizieren ist, die Schenkungsvorschriften zumindest entsprechend anzuwenden sind19. In den Fällen, in denen eine Open Source Software im nicht-kommerziell-distributiven Wege weitergeben wird, sei grundsätzlich das Schenkungsrecht anzuwenden. Bei der Überlassung von Open Source Software liege der Schwerpunkt hiernach in der unentgeltlichen Einräumung von Nutzungsrechten an einem Computerprogramm. Nach dieser Ansicht kommt hier nur einer der gesetzlich geregelten „Veräußerungsverträge in Betracht20. Da es sich aber um eine unentgeltliche Übertragung handelt, liegt eine Schenkung gem. 516 ff. BGB nahe. Auch hinsichtlich der Voraussetzungen einer Schenkung werden keine Schwierigkeiten gesehen. a) Zuwendung Eine Schenkung gem. § 516 I BGB setzt nach dem Wortlaut eine Zuwendung voraus, durch die jemand aus seinem Vermögen einen anderen bereichert und beide einig sind, dass die Zuwendung unentgeltlich erfolgt. Eine Zuwendung i. S. d. Schenkungsrechts lässt sich bejahen. Mit der BGH Rechtsprechung21 wird davon ausgegangen, dass Standardsoftware als Sache übertragen werden kann. Daraus leitet diese Ansicht ab, dass Software dann auch Gegenstand einer Zuwendung sein kann. Zudem wird darauf hin19 Jaeger/Metzger, S. 139 ff.; Spindler, in: Spindler, Abschn. D Rn. 6 ff.; Marly, Rn. 427, der allerdings das Schenkungsrecht lediglich auf den Sachverhalt angewendet wissen will, soweit die Software auf einem Datenträger weitergegeben wird; Schiffner, S. 225 ff., der ebenfalls nur die private Weitergabe unter das Schenkungsrecht fasst; Deike, CR 2003, S. 14 ff.; Stickelbrock, ZGS 2003, S. 371. 20 Jaeger/Metzger, S. 140. 21 BGH, NJW 1990, S. 320 f.

I. Nicht durch Distributoren vertriebene Software

233

gewiesen, dass in Folge der großen Schuldrechtsreform gem. § 453 I BGB der Rechtskauf dem Sachkauf rechtlich gleichgestellt wurde und § 453 I BGB im Schenkungsrecht gem. § 523 II S. 2 BGB entsprechend anzuwenden ist22. Dies aber erübrigt eine Abgrenzung zwischen Sach- und Rechtkauf im vorliegenden Fall. Hinsichtlich der Software sowie der Nutzungsrechte finden somit Zuwendungen statt. b) Entreicherung Darüber hinaus ist allgemein anerkannt, dass in Folge der Zuwendung eine Vermögensminderung bei dem Zuwendenden eintreten muss23. Eine schenkende Zuwendung erfordert also eine Entreicherung des Schenkers. Auch diese, im Zusammenhang mit der Übertragung von Nutzungsrechten nicht unproblematisch erscheinende Voraussetzung, wird hier bejaht. Da Open Source Software beliebig vervielfältigt werden kann und selbst bei einer Weitergabe regelmäßig die Software beim Verbreiter verbleibt, kann man Zweifel haben, ob es wirklich zu einer Entreicherung des Schenkers kommt24. Ein physischer Abgang bei Software, dessen eigentlicher Wert immateriell ist, kann nicht festgestellt werden25. Dennoch wird hier ein Vermögensverlust des Schenkers bejaht. Bei der Weitergabe von Open Source Software werden Nutzungsrechte an den Beschenkten übertragen. Maßgeblich ist, wie der Erwerber mit der Software verfahren kann. Derjenige Rechteinhaber, der sein Computerprogramm unter eine Open Source-Softwarelizenz stellt, „verliert dauerhaft einen urheberrechtlichen Vermögensbestandteil“26. Er vergibt sein bestehendes Recht an der Software27. Die Rechte an der Software sind der Vermögensgegenstand, der dadurch geschmälert wird, dass sich der Rechteinhaber für eine Open Source-Lizenz entscheidet und Dritten Nutzungsrechte an dem Computerprogramm einräumt. Er eröffnet die Möglichkeit, die Nutzungsrechte lizenzgebührenfrei zu erwerben. Jede später erfolgende Einräumung von ausschließlichen Nutzungsrechten gem. § 33 UrhG sei mit dem einfachen Nutzungsrecht an jedermann belastet28. Der Wert des Open Source-Softwarevertrages liege daher nicht in der Verschaffung einer Sache, etwa als auf einem Datenträger gebundene Datei, sondern vielmehr in der Übertragung der unkörperlichen 22

Spindler, in: Spindler, Abschn. D Rn. 6. Palandt/Weidenkaff, § 516 Rn. 5. 24 Eine fehlende Entreicherung bejahend: Sester, CR 2000, S. 799 f.; Koch, Rn. 453; ders., CR 2000, S. 333. 25 Spindler, in: Spindler, Abschn. D Rn. 7. 26 Jaeger/Metzger, S. 141. 27 Spindler, in: Spindler, Abschn. D Rn. 7. 28 Jaeger/Metzger, S. 141. 23

234

§ 9 Vertragliche Einordnung der Softwareüberlassung

Daten mit den entsprechenden Rechten an diesen29. Somit liegt auch eine Entreicherung bei dem Rechteinhaber vor, wenn er seine Software als Open Source Software „verschenkt“. c) Bereicherung des Beschenkten Der Beschenkte ist durch die Rechtseinräumung auch bereichert30. Er kann die ihm eingeräumten Rechte frei nutzen. d) Unentgeltlichkeit Ferner muss die Zuwendung unentgeltlich erfolgt sein. Aber auch diese für eine Schenkung notwendige Voraussetzung ist nach der hier vertretenen Auffassung als erfüllt anzusehen. Die Unentgeltlichkeit einer Schenkung ist stets nach der objektiven Sachlage zu beurteilen, muss aber von der Vertragspartei als unentgeltlich gewollt sein31. Unentgeltlich ist eine Zuwendung dann, wenn sie unabhängig von einer Gegenleistung erfolgt32. Problematisiert wird in diesem Zusammenhang die Frage, wie die mit der Überlassung von Open Source Software verbundenen Pflichten, einzuordnen sind. Dabei kann daran gedacht werden, dass die weitergehenden Pflichten als Gegenleistung anzusehen sind, so dass keine Unentgeltlichkeit anzunehmen ist33. Diese Auslegung ist hiernach jedoch abzulehnen. Die Erfüllung der Lizenzpflichten stellen keine synallagmatische Verpflichtung dar. Der Erwerber von Open Source Software ist zu keiner Gegenleistung verpflichtet. Die Lizenzbedingungen haben eben „keinen finalen Charakter im Sinne einer Wirksamkeitsbedingung“34, d. h. der Softwareanwender erhält die Nutzungsrechte unmittelbar mit Vertragsschluss, ohne dass er dafür Verpflichtungen erfüllen muss. Ihm werden mithin keine Verpflichtungen auferlegt, die als Gegenleistung den Erwerb unter einem materiellen Gesichtspunkt ausgleichen. Die Verpflichtungen, wie sie in Open Source-Lizenzen festgelegt sind, beschränken lediglich den Gegenstand der Schenkung35. Da sie erst eingreifen, wenn der Nutzer die Software auf bestimmte Weise nutzt 29

Spindler, in: Spindler, Abschn. D Rn. 7 mit weiteren Nachweisen. Jaeger/Metzger, S. 142. 31 Palandt/Weidenkaff, § 516 Rn. 8; OLG Hamm, NJW-RR 1993, S. 1412 mit weiteren Nachweisen. 32 BGH, NJW 1982, S. 436. 33 Problematisierend: Jaeger/Metzger, S. 142 f.; Metzger/Jaeger, GRURInt 1999, S. 839 ff.; Spindler, in: Spindler, Abschn. D Rn. 8; Bejahend: Koch, § 9 Rn. 453; ders. CR 2000, S. 335; Sester, CR 2000, S. 800. 34 Jaeger/Metzger, S. 143. 35 Jaeger/Metzger, S. 143. 30

I. Nicht durch Distributoren vertriebene Software

235

(z. B. verändert, vervielfältigt), wird auch von „nachhängenden Verpflichtungen“36 gesprochen, um zu verdeutlichen, dass sie jedenfalls keine Gegenleistung für die Rechtseinräumung darstellen37. Im Ergebnis wird daher die Unentgeltlichkeit der Zuwendung bejaht. e) Ergebnis Die herrschende Meinung subsumiert die Rechtseinräumung bei Open Source Software-Überlassungsverträgen unter das Schenkungsrecht subsumieren. Jedenfalls seien die Vorschriften aufgrund der vergleichbaren Interessenlage entsprechend anwendbar. 8. Dingliche Verfügung ohne schuldrechtliches Grundgeschäft Eine andere Ansicht will sich von den bisher dargestellten Lösungsmodellen“ distanzieren und die Weitergabe von Rechten in der Lizenzkette als rein dingliche Verfügungen ohne schuldrechtliches Grundgeschäft behandeln38. Ausgehend von dem Begriff der „Lizenz“ ist die Rechtseinräumung bei der Softwareüberlassung stets ein „Verfügungsgeschäft, hinter dem üblicherweise ein schuldrechtlicher Austauschvertrag steckt, der die Basis der Verfügung bildet“. Dieser Austauschvertrag regelt auch alle Ansprüche, die dem Lizenzgeber gegenüber dem Lizenznehmer zustehen. Die GPL begründet solche im Austauschverhältnis bestehenden Verpflichtungen nicht, das sie nur Bedingungen beschreibt, „unter denen die Verfügung wirksam werden soll“. Die Bedingungen knüpfen dieser Ansicht nach aber „kein schuldrechtliches Band“ zwischen den Lizenzpartnern sondern beschreiben lediglich die Grenzen der Rechtseinräumung39. Die GPL stellt eine dingliche Verfügung dar, da sie die eingeräumten Rechte eindeutig abgrenzt, durch ihre Eindeutigkeit die Rechtszuständigkeit erkennen lässt und vom Rechteinhaber ausgeht. Die Lizenzen ist unmittelbar darauf gerichtet, ein bestehendes Recht zu übertragen. Darüber hinhaus beschreibt die GPL nur den Umfang und Zeitdauer der Rechtseinräumung, begründet aber keine schuldrechtliche Vereinbarung zwischen den Parteien. Nach dieser Ansicht fehlt es somit generell an einem schuldrechtlichen Grundgeschäft bei der Open Source Software-Überlassung, soweit sie jedenfalls aufgrund der GPL erfolgt. 36 37 38 39

Jaeger/Metzger, S. 143. Spindler, in: Spindler, Abschn. D Rn. 9. Heussen, MMR 2004, S. 447. Heussen, MMR 2004, S. 448.

236

§ 9 Vertragliche Einordnung der Softwareüberlassung

Diese rechtliche Qualifizierung hat dann auch zur Folge, dass die Haftungs- und Gewährleistungsklauseln in Open Source-Verträgen keine Bedeutung haben, da es „ohne Vertrag auch keine Gewährleistung oder sonstige vertragliche Haftung“ geben kann.

9. Eigene Stellungnahme Die Frage nach der rechtlichen Qualifizierung eines schuldrechtlichen Verpflichtungsgeschäftes, das Rechtsgrund der Open Source Software-Überlassung ist, ist ein Kernproblem des Open Source Rechts. Einer der wesentlichen Gründe dafür ist, dass damit die noch im Nachfolgenden zu beantwortende Frage nach der Wirksamkeit der in Open Source-Lizenzen formulierten Haftungs- und Gewährleistungsklauseln untrennbar verbunden ist. Das Bürgerliche Gesetzbuch regelt eine Vielzahl von Vertragstypen. Jedenfalls kennt es – noch – keinen Open Source-Vertrag. Dies macht es für diejenigen, die zumindest ein schuldrechtliches Grundgeschäft annehmen wollen, notwendig, sich mit der Frage auseinander zu setzen, unter welchen im BGB geregelten Vertragstyp die Open Source Software-Überlassung am sinnvollsten zu subsumieren ist. Wie sich oben gezeigt hat, werden unterschiedliche Lösungswege favorisiert. Einige der oben vorgeschlagenen Lösungswege sind dort bereits diskutiert und abgelehnt worden. a) Schenkungsrecht Meines Erachtens ist auch das Schenkungsrecht keine überzeugende Lösung. Die vorgenommenen Subsumtionen unter die Voraussetzungen einer Schenkung gem. 516 I BGB wirken letztlich nicht überzeugend. Zunächst gilt es nochmals, sich die Überlassung von Open Source Software und die dahinterstehenden Ziele zu verdeutlichen. Die Rechteinhaber geben eine Software gegenüber einer unbestimmten Zahl von potenziellen Anwendern zur Nutzung frei. Sie räumen ihnen vielfältige Nutzungsrechte ein, die jeweils an bestimmte Bedingungen gebunden sind. Dadurch erhoffen sie sich regelmäßig eine schnelle Verbreitung, stete Verbesserung und die Gewähr, dass die Software „frei“ bleibt. Zweifelhaft ist, ob man diesen Sachverhalt als Schenkung i. S. d. § 516 I BGB klassifizieren kann. Eine Vertragschenkung gem. § 518 I BGB scheidet jedenfalls regelmäßig wegen der fehlenden notariellen Beurkundung aus. Bei der Handschenkung muss es sich, wie gesagt, um eine Zuwendung handeln, und die Parteien müssen einig sein, dass sie unentgeltlich erfolgt. Richtig ist, dass bereits das Merkmal der Zuwendung Schwierigkeiten be-

I. Nicht durch Distributoren vertriebene Software

237

reitet. Große Zweifel bestehen, ob eine dafür notwendige Vermögensminderung, d. h. eine Entreicherung des Schenkers und eine Bereicherung des Beschenkten angenommen werden kann. Richtig ist der Hinweis, dass ein physischer Abgang bei immateriellen Wirtschaftsgütern wie Software nicht festgestellt werden kann. Die oben dargestellte Meinung40 geht indes davon aus, dass die Vermögensminderung in der Einräumung einfacher Nutzungsrechte an Dritte durch das Verbreiten der Software unter der GPL liegt. Der Rechteinhaber verliere einen urheberrechtlichen Bestandteil seiner Software. Nach gesetzlicher Wertung fehlt es dann an einer Vermögensminderung, wenn dem Vertragspartner nur solche Leistungen gewährt werden, die entweder einen bloßen Gebrauch des Vermögens oder der Arbeitskraft des Leistenden ermöglichen41. Fraglich ist also, ob man bei Open Source Software nicht hiervon ausgehen muss. Es stellt sich nämlich die Frage, ob die Nutzung einer Open Source Software lediglich ein Gebrauch fremden Vermögens oder der Arbeitskraft des Leistenden darstellt oder ob ein wirklicher „Vermögenszufluss“ beim Anwender stattfindet, der mit einem entsprechenden „Vermögesabfluss“ des Schenkers korrespondiert. Der Rechteinhaber, der sein Computerprogramm unter der GPL lizenziert, räumt einfache Nutzungsrecht ad incertas personas ein. Dadurch verliert er dauerhaft einen urheberrechtlichen Vermögensbestandteil. Der Urheber aber, der seine Software unter einer Open Source-Lizenz verbreitet, bleibt auch nach Einräumung von Nutzungsrechten Rechteinhaber. Nach einer Weitergabe seiner Software kann er diese vollumfänglich nutzen. Richtig ist, dass der Rechteinhaber an dem konkret in Umlauf gebrachten Computerprogramm kein ausschließliches Nutzungsrecht mehr einräumen kann, da es durch die Einräumung der einfachen Nutzungsrechte ad incertas personas belastet ist. Insofern ist der oben dargestellten Ansicht in diesem Punkt zuzustimmen. Auch ist es richtig, dass der Erwerber ein Softwareprogramm ohne Zahlung von Lizenzgebühren nutzen kann. Eine Vermögensminderung mag hiernach vorliegen. Es muss aber auch zu einer Bereicherung des Beschenkten kommen. Spätestens an diesem Punkt bestehen Zweifel. Der Nutzer kann die erworbene Software gebrauchen (anwenden, kopieren, verändern, verbreiten). Die Nutzung ist aber zugleich an vielfältige Bedingungen gebunden. Ein „freier“ Gebrauch der Software ist ihm nicht möglich. Darüber hinaus besteht auch keine „Veräußerungsmöglichkeit“ der eingeräumten Rechte. Entscheidend ist auch die Tatsache, dass er die Software zwar verändern darf, er die veränderte Software aber wiederum unter Originallizenz stellen muss. Eine eventuelle Wertsteigerung des Zuwendungsgegenstandes verbleibt mithin 40 41

Vgl. § 9 I. 7. Brox/Walker, § 9 Rn. 7.

238

§ 9 Vertragliche Einordnung der Softwareüberlassung

nicht bei ihm. Es lässt sich somit sagen, dass er die Software zwar unentgeltlich in den Grenzen der Lizenzbedingungen nutzen darf, ihm der vollständige Wert der Software indes nicht zufließt. Hier liegt doch ein elementarer Unterschied zu einer Schenkung. Open Source Software wird dem Nutzer überlassen, damit er sie nutzt, verbreitet und im besten Falle noch durch eigene Verbesserungen optimiert. Eine Bereicherung des Softwareanwenders ist nicht primäres Ziel, sondern eher Mittel zum Zweck. Das Entwicklungs- und Verbreitungsmodell Open Source ist auf den Anwender angewiesen. Es hat eben keinen rein altruistischen Charakter42. Es braucht den Anwender als notwendige Existenzvoraussetzung. Damit der Anwender aber die von ihm erwarteten Nutzungshandlungen vornehmen kann, müssen ihm bei einem urheberrechtlich geschützten Werk aber die entsprechenden Nutzungsrechte eingeräumt werden. Nun kann man argumentieren, dass die Intention, die hinter einer Schenkung steht, keinen Einfluss auf die rechtliche Würdigung hat. Warum ein Schenker schenkt, ist irrelevant. Das ist richtig. Die hier angeführten Gesichtspunkte sprechen aber doch eher für eine zweckgerichtete Gebrauchsüberlassung als für eine reine Schenkung. Derjenige, der eine Software als Open Source Software verbreiten will, ist gerade auf den Anwender angewiesen und räumt ihm zweckgerichtet die Nutzungsrechte ein. Folglich bestehen auch erhebliche Bedenken hinsichtlich der Bereicherung des Softwarenutzers. Schließlich bestehen gewichtige Zweifel, ob die Softwareüberlassung unentgeltlich im Sinne des Schenkungsrecht ist. Eine Schenkung erfordert zunächst eine Parteivereinbarung über die Unentgeltlichkeit der Zuwendung43. Eine solche Vereinbarung könnte jedenfalls konkludent geschlossen worden sein. Unentgeltlichkeit i. S. d. Schenkungsrechts liegt allerdings nur dann vor, wenn der Zuwendung kein Gegenwert gegenübersteht44. Dagegen liegt eine Entgeltlichkeit dann vor, wenn die Schenkung an Bedingungen in Form einer Gegenleistung geknüpft ist, d. h. eine Unentgeltlichkeit entfällt, wenn die Leistung zu dem erkennbaren Zweck erfolgt, den Leistungsempfänger zu einem bestimmten Verhalten zu veranlassen45. Eine derartige kausale Verknüpfung liegt bei der Überlassung von Open Source Software aber doch gerade vor. Wie oben gesagt, erfolgt die Überlassung von Open Source Software unter klar formulierten Bedingungen, die den Nutzer zu einem bestimmten Verhalten verpflichten. Er soll die Software nutzen, er bekommt das Verbreitungsrecht, damit er die Software verbreiten kann, und er darf die Software verändern, damit er dies tut und somit die Entwicklung 42 43 44 45

Sester, CR 2000, S. 799. Brox/Walker, § 9 Rn. 9. Brox/Walker, § 9 Rn. 9. Brox/Walker, § 9 Rn. 10.

I. Nicht durch Distributoren vertriebene Software

239

voranbringt. Die Lizenz schafft somit eine kausale Verknüpfung dahingehend, dass der Nutzer zwar kein Entgelt bezahlt, aber Handlungen vornimmt, die der Lizenzgeber mit der kostenlose Nutzungsrechtseinräumung bezweckt. Somit kann auch das Merkmal der Unentgeltlichkeit mit guten Gründen abgelehnt werden. Es muss berücksichtigt werden, dass der Rechteinhaber deswegen kein Entgelt für die Rechtseinräumung fordert, weil er sich ein entsprechendes Verhalten durch den Softwareanwender verspricht. Dazu gehört schon die Nutzung der Software. Insofern ist keine Aufteilung der eingeräumten Rechte in „einfache“ und „weitergehende Rechte“ angesagt. Rein altruistisch darf die Rechtseinräumung somit nicht qualifiziert werden. In den überwiegenden Fällen wird Open Source Software als solche lizenziert, um die Software durch den Anwender zu etablieren, zu verbreiten und zu verbessern. Insofern kann schon von einer finalen Bindung gesprochen werden. Des Weiteren soll nicht unerwähnt bleiben, dass unter Umständen Fallkonstellationen denkbar sind, in denen die Open Source Software-Überlassung zu steuerlichen Problemen des Anwenders führen kann. Möglich wäre es, dass er durch die Entgegennahme einer Software schenkungssteuerpflichtig wird. Die steuerlichen Aspekte sollen jedoch an dieser Stelle nicht weiter vertieft werden. Es hat sich gezeigt, dass zumindest erhebliche Zweifel bestehen, ob ein etwaig vorliegendes Grundgeschäft der Open Source Software-Überlassung unter das Schenkungsrecht subsumiert werden kann. Auch die Befürworter der Gegenansicht wollen die Vorschriften des Schenkungsrechts nur analog anwenden. Eine analoge Anwendung der Vorschriften des BGB auf gesetzlich nicht geregelte Fallgestaltungen erfordert jedoch sowohl eine gesetzliche Regelungslücke wie auch eine vergleichbare Interessenslage. Schon eine gesetzliche Regelungslücke liegt nicht vor. Wie sich im Folgenden noch zeigen wird, bedarf es auch keiner analogen Anwendung. Aber der Hinweis auf die analoge Anwendbarkeit offenbart noch einen weiteren Mangel für dieser Lösung. Die Vertreter dieser Auffassung gehen rein ergebnisorientiert vor. Ausgehend von den in Open Source Softwarelizenzen formulierten generellen Haftungs- und Gewährleistungsausschlusses wird ein Vertrag gesucht, der eine entsprechende Haftungsregelung zulässt46. Gem. §§ 521, 523, 524 BGB haftet der Schenker bei Leistungsstörungen nur für Vorsatz und grobe Fahrlässigkeit. Dies scheint zunächst gut zu der Haftung und Gewährleistung bei der Open Source Software-Überlassung zu passen. Allein vom Ergebnis her lässt sich jedoch nicht argumentieren. Zumal dann nicht, wenn sich die oben genannten Zweifel hinsicht46

So auch kritisch Sester, CR 2000, S. 799.

240

§ 9 Vertragliche Einordnung der Softwareüberlassung

lich des Vorliegens der Anwendungsvoraussetzungen gem. § 516 I BGB ergeben. So recht passt das Schenkungsrecht eben nicht zur Open Source Software-Überlassung. Der Annahme einer Schenkung bedarf es auch dann nicht notwendigerweise, wenn sich das gewünschte Ergebnis auf andere Weise mit weniger Argumentationsaufwand erreichen lässt. b) Open Source Software-Überlassung als dingliche Verfügung aufgrund eines Open Source-Vertrages gem. § 311 I BGB aa) Einleitung Die Überlassung von Open Source Software ist eine dingliche Verfügung, der ein Open Source-Vertrag gem. § 311 I BGB zugrunde liegt und der durch AGB in Form der Lizenzbedingungen näher ausgestaltet ist47. Die Einräumung von Nutzungsrechten ist eine Verfügung. Ergänzend zu den urheberrechtlichen Vorschriften gelten die §§ 398 ff. BGB48. Gem. § 413 BGB finden die Abtretungsvorschriften auf die Übertragung anderer Rechte entsprechend Anwendung, soweit keine gesetzlichen Regelungen vorhanden sind. Dies gilt auch für Nutzungsrechte an Urheberrechten49. Eine Forderungsabtretung gem. § 398 I BGB aber erfolgt „durch Vertrag“. Eine Abtretung erfordert also einen Rechtsgrund. Hier taucht das Problem bei der Ansicht auf, die gar kein Grundgeschäft in Form eines schuldrechtlichen Austauschvertrages annehmen will. Dieser Auffassung nach liegt eine rein dingliche Verfügung vor, deren Umfang durch die GPL begrenzt ist. Dies kann aber so nicht überzeugen. Auch die Übertragung urheberrechtlicher Nutzungsrechte folgt in Erfüllung eines Vertrages. Das Gesetz spricht beispielsweise in der Überschrift von § 37 UrhG sowie auch in § 40 UrhG davon, dass Nutzungsrechte durch Verträge eingeräumt werden. Auch bei der Einräumung von Nutzungsrechten ist anerkannt, dass zwischen Verfügungsgeschäft- und Verpflichtungsgeschäft zu trennen ist50. Das Abstraktionsprinzip findet hier volle Anwendung. Dass die Übertragung von Nutzungsrechten aufgrund eines Grundgeschäftes erfolgt, zeigt zum einen das Urheberrecht selbst wie auch die allgemeine Überzeugung, dass auf die Rechtsübertragung gem. § 413 BGB die §§ 398 ff. BGB anzuwenden sind. Würde man der oben dargestellten 47 48 49 50

Vgl. auch Heussen, MMR 2004, S. 445 ff. Dreier/Schulze, § 31 Rn. 15; Schricker/Schricker, Vor §§ 28 ff. Rn. 45. Palandt/Heinrichs, § 413 Rn. 3. Loewenheim/Loewenheim/Jan Bernd Nordemann, § 28 Rn. 4.

I. Nicht durch Distributoren vertriebene Software

241

Auffassung folgen, läge eine Verfügung vor, aber keine Verpflichtung. Der Lösungsansatz indes geht in die richtige Richtung. Bei der Suche nach der rechtlichen Qualifizierung des Grundgeschäfts für die Überlassung von Open Source Software ist es nicht hilfreich, alleine vom gewünschten Ergebnis her zu argumentieren. Ferner erscheint es auch nicht allzu überzeugend, das Grundgeschäft zwanghaft unter einen der im Gesetz ausdrücklich geregelten Vertragstypen fassen zu wollen. Sämtliche Vertragstypen des BGB sind ungeeignet, die Open Source Software-Überlassung rechtlich vollumfänglich abzudecken. Wie sich gezeigt hat, ist auch das Schenkungsrecht keine Ideallösung. Das Open Source Konzept hat den Softwaresektor längst verlassen. Es gibt Open Source-Bücher, Open Source-Musik und sogar Open SourceBier51 hat mittlerweile von sich reden gemacht. Es liegt daher nahe, über einen Open Source-Vertrag als Vertrag sui generis nachzudenken. bb) Eigener Lösungsvorschlag Das BGB gewährt Vertragspartnern grundsätzlich die Freiheit, ihre vertraglichen Bezeihungen selbstständig und ohne Rücksicht auf die gesetzlich normierten Vertragstypen zu regeln. Aufgrund der Bedürfnisse des Rechtsverkehrs haben sich neben den normierten Verträgen über die Jahre weitere verkehrstypische Verträge52 herausgebildet und werden auch durch die Rechtsprechung anerkannt. Ausgehend hiervon ist daran zu denken, Open Source als atypischen Vertragstyp in die Praxis einzuführen. Ein atypischer Vertrag liegt in Fällen vor, in denen ein Vertrag wegen seiner individuellen Prägung weder einem gesetzlich normierten Vertragstyp noch einem verkehrstypischen Vertrag zugeordnet werden kann. Dieses ist hier der Fall. Wird eine Software unter die GPL gestellt und als Open Source Software verbreitet, erfolgt die Übertragung der Nutzungsrechte jeweils gem. §§ 398, 413 BGB durch Vertrag. Das erforderliche Grundgeschäft, aufgrund dessen die Nutzungsrechte eingeräumt werden, ist ein Open Source-Lizenzvertrag gem. § 311 I BGB. Dieser Open Source-Lizenzvertrag wird durch die Verwendung von AGB in Form der jeweiligen Open Source-Lizenz inhaltlich ausgestaltet.

51 Spiegel Online vom 20. Juli 2005 [http://www.spiegel.de/netzwelt/netzkultur/ 0,1518,365818,00.html]. 52 Beispielsweise: Franchisevertrag, Provider-Verträge, Energieversorgungsverträge. Für weitere verkehrstypische Verträge vgl. Palandt/Heinrichs, Überbl v § 311 Rn. 12 f. 16 Teupen

242

§ 9 Vertragliche Einordnung der Softwareüberlassung

(1) Der Open Source-Vertrag Aufgrund seiner eigenständigen Struktur kommt „Open Source“ als atypischer Vertragstyp in Betracht. Dabei bilden die Open Source-Freiheiten“, wie sie sich auch aus der Open Source-Definition ergeben, die wesentlichen Vertragsmerkmale. Obwohl sie erstmals aus dem Bereich der Software stammen, haben sich die Autoren anderer Open Source-Lizenzen in anderen Bereichen an diesen Grundsätzen orientiert. Sie sind Grundlage für alle Open Source-Lizenzen und enthalten die notwendigen Wesensmerkmale. Durch die Verwendung von AGB in Form der Lizenz erfolgt die jeweilige Ausgestaltung des konkreten Überlassungsvertrages. Ausgehend von den bereits dargestellten Grundfreiheiten ist ein Open Source-Vertrag demnach ein Vertrag, bei dem ein Rechteinhaber sein immaterielles Gut oder sein Wissen, das im Einzelfall klar zu definieren sein muss, unentgeltlich einer unbestimmten Vielzahl von Personen zur Verfügung stellt und ihnen eine freie Benutzbarkeit bis hin zur Vornahme von Änderungs- und Weiterentwicklungsmaßnahmen einräumt, begrenzt durch die Pflicht die Ergebnisse derartiger Maßnahmen wiederum ad incertas personas zugänglich zu machen. Was den Abschluss eines Open Source-Vertrages betrifft, werden allgemein keine besonderen Probleme gesehen. Hier führen die allgemeien Regeln des BGB über den Vertragsschluss im Einzelfall zu angemessenen Ergebnissen. (2) Open Source-Lizenzen als AGB Derjenige, der sich dafür entscheidet, sein immaterielles Gut oder sein Wissen im Wege eines Open Source-Vertrages der „Öffentlichkeit“ zugänglich zu machen, muss ausgehend von der Art seines immateriellen Gutes (Software, Buch, Musikstück . . .) entscheiden, wie er das Rechtsverhältnis im konkreten Fall ausgestalten will. Bei Software kann er auf die vorhandenen Open Source-Lizenzen zurückgreifen, oder auch eine eigene Lizenz entwickeln, die sich an den Grundfreiheiten orientiert. Die „Autoren“ von Computersoftware, die sich für eine Open Source-Verbreitung entscheiden, greifen regelmäßig auf die vorhandenen Lizenzen zurück. (a) Anwendbarkeit der §§ 305 ff. BGB auf Open Source-Lizenzen Bereits im Abschnitt über die Anwendbarkeit des UrhG auf die GPL nach kollisionsrechtlichen Regeln wurde herausgearbeitet, dass auch Lizen-

I. Nicht durch Distributoren vertriebene Software

243

zen, die aus dem amerikanischen Rechtsraum stammen, im deutschen Rechtsgebiet Wirkung entfalten. Das deutsche Vertragsrecht findet in bestimmten oben beschriebenen Konstellationen auf diese Lizenzen uneingeschränkt Anwendung53. Dazu gehören auch die Regelungen der §§ 305 ff. BGB über die Allgemeinen Geschäftsbedingungen. (b) Open Source-Lizenzen als Allgemeine Geschäftsbedingungen Das Wesen von Open Source-Lizenzbedingungen ist es gerade, dass sie für eine Vielzahl von Verträge vorformuliert sind. Die verschiedenen Lizenzen stehen der „Community“ zur Verfügung. Die überwiegende Zahl der Open Source Softwarelizenzen ist „einzelfallunabhängig“ und kann von jedermann für seine eigene Software benutzt werden. Sie erfüllen daher unproblematisch die Vorraussetzungen des § 305 I BGB54. Steller der AGB ist regelmäßig derjenige, der als Rechteinhaber sein Computerprogramm einer bestimmten Lizenz unterstellt und mit dieser erstmalig dem Rechtsverkehr zugänglich macht. Wie oben gezeigt, erhält der Nutzer auch bei einem Kettenerwerb die Rechte regelmäßig vom Rechteinhaber55. Die Weitergebenden treten allenfalls als Boten auf. Hat ein Nutzer am Computerprogramm Änderungen vorgenommen, verpflichtet ihn die Open Source-Lizenz dazu, das geänderte Computerprogramm selbst wieder unter die Ursprungslizenz zu stellen. In diesem Fall ist dieser dann derjenige, der die AGB stellt56. Eine Ansicht problematisiert in diesem Zusammenhang, dass bei einer Weitergabe einer bearbeiteten Version innerhalb der Verbreitungsketten ein Dritter anstatt des Rechteinhabers als Bearbeiter die Software weitergibt, die Lizenz als AGB also nicht vom Vertragspartner, sondern von einem Dritten gestellt würde, dies aber nicht der Voraussetzung von § 305 I BGB entspräche57. Der Bearbeiter stelle die bearbeitete Software selbst unter die Ursprungslizenz. Dieser Einwand überzeugt jedoch nicht. Dabei muss man sich verdeutlichen, was der Gesetzeswortlaut damit meint, dass „eine Ver53

Vgl. dazu § 5 II. LG München I, CR 2004, S. 775; Allgemeine Ansicht auch in der Literatur, vgl. u. a. Jaeger/Metzger, S. 147; Schiffner, S. 174; Deike, CR 2003, S. 9, 13; Omsels, in: Festschrift für Paul W. Hertin, S. 147; Koch, CR 2000, S. 338; Spindler, in: Spindler, Abschn. C Rn. 45; Stickelbrock, ZGS 2003, S. 370; Marly, Rn. 429, 440. 55 Vgl. dazu § 6 III. bb). 56 Schiffner, S. 183 f. 57 Koch, CR 2000, S. 338. 54

16*

244

§ 9 Vertragliche Einordnung der Softwareüberlassung

tragspartei der anderen Vertragspartei die AGB stellt“. Sinn und Zweck dieses Tatbestandsmerkmals ist, sicherzustellen, dass kein Dritter in die Vertragsgestaltung eingreift. So kann beispielsweise ein Notar nicht von sich aus die Verwendung bestimmter AGB vorschlagen58. Anders ist die Situation bereits dann, wenn der Notar eines Vertragspartners die AGB entwirft. Zudem erfordert das Tatbestandsmerkmal „stellen“ nach dem Schutzzweck der §§ 305 ff. BGB, dass der Verwender selbst oder durch seine Hilfsperson unter Ausschluss des anderen Teils einseitig rechtsgeschäftliche Gestaltungsmacht in Anspruch nimmt59. So liegt der Fall bei der Weiterverbreitung der Open Source Software durch den Bearbeiter. Auch an dieser Stelle muss wieder deutlich gemacht werden, dass der Abschluss des Lizenzvertrages als Grundlage der Rechteeinräumung regelmäßig zwischen dem Rechteinhaber und dem neuen Nutzer erfolgt. Was die Stellung des Bearbeiters angeht, muss im Einzelfall herausgearbeitet werden, ob und inwiefern er Urheber bzw. Miturheber der Software geworden ist. Insofern kann auf die oben gemachten Ausführungen zur Urheberschaft von Open Source Software verwiesen werden60. Wenn der Bearbeiter Urheber oder Miturheber geworden ist, ist er Vertragspartei und „Steller“ der AGB. Ist er kein Rechteinhaber- oder Mitinhaber geworden, tritt er im Rahmen einer Weitergabe regelmäßig als Bote des Rechteinhabers auf, d. h. das der Rechteinhaber als Vertragspartner regelmäßig die AGB stellt61. In jedem Fall ist folglich die Voraussetzung, dass nur der Vertragspartner und nicht ein Dritter die AGB stellt, erfüllt. (c) Wirksame Einbeziehung der AGB in den Lizenzvertrag gem. § 305 II BGB Die Lizenzbedingungen müssen im Einzelfall wirksam in den Open Source-Vertrag einbezogen werden. Für Unternehmer gelten die engen Anforderungen des § 305 II BGB gem. § 310 I BGB nicht. Zwar müssen auch gegenüber Unternehmen die AGB wirksam in den Vertrag einbezogen werden, die Anforderungen hieran sind jedoch wesentlich geringer. Da Verbraucher schutzwürdiger als Unternehmer sind, schreibt § 305 II BGB vor, dass AGB nur dann Bestandteil des Vertrages werden, wenn bei 58

BGH 118, 229 ff.; Palandt/Heinrichs, § 305 Rn. 11. Palandt/Heinrichs, § 305 Rn. 11. 60 Vgl. dazu § 5 III. 61 Vgl. Ziff. 6 GPL: „Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.“ 59

I. Nicht durch Distributoren vertriebene Software

245

Vertragsschluss ausdrücklich auf sie hingewiesen wird, der anderen Vertragspartei die Möglichkeit der zumutbaren Kenntnisnahme geschaffen wird und diese mit den AGB einverstanden ist. Im Bereich von Softwareüberlassungsverträgen bestehen schon aufgrund der technischen Eigenart der Verbreitung Besonderheiten hinsichtlich der korrekten Einbeziehung62. Was die ordnungsgemäße Einbeziehung von AGB bei Abschluss von Open Source Software-Überlassungsverträgen anbelangt, bestehen grundsätzlich keine anderen Besonderheiten als bei kommerziell vertriebener Software63. Bezogen auf Open Source Software sollen an dieser Stelle nur einzelne Fragen angesprochen werden, da hier im wesentlichen keine Probleme gesehen werden64. Die GPL weist bereits in Ziff. 0 GPL daraufhin, dass die Lizenz dann Anwendung findet, wenn das jeweilige Programm einen Hinweis enthält, dass die Software nur unter dieser Lizenz verbreitet werden darf. Ziff. 1 GPL fordert jeden Nutzer zudem auf, jede Kopie mit einem entsprechendem Hinweis auf die Geltung der GPL für den Fall einer Weitergabe zu versehen und bei einer Weitergabe dem Empfänger eine Lizenz zukommen zu lassen. Für ein bearbeitetes Programm enthält Ziff. 2 c GPL eine Pflicht dahingehend, dass bei interaktiver Benutzung des Programms im Einlesevorgang ein Meldung ausgegeben oder ausgedruckt wird, die einen entsprechenden Copyright-Vermerk enthält und Hinweise u. a. zur Gewährleistung enthält65. Diese Lizenzbedingungen regeln bereits, wie auf die GPL hinzuweisen ist. Ob die AGB wirksam einbezogen worden sind, bleibt Frage des konkreten Einzelfalls. Die meisten Lösungswege für die korrekte Einbeziehung der AGB sind unumstritten und lehnen sich an die Lösungswege bei kommerziell vertriebener Software an. Neben der rein „technischen“ Frage, wie die AGB in konkreten Fall einbezogen werden, muss dem Vertragspartner die Möglichkeit geschaffen werden, die AGB in zumutbarer Weise zur Kenntnis zu nehmen. Eine zumutbare Kenntnisnahme setzt aufgrund des im AGB-Recht geltenden Trans62 An dieser Stelle sollen jedoch nicht alle Fallkonstellationen mit ihren Problemen abgehandelt werden. Zur Problematik vgl. Schneider, HER, Abschn. D Rn. 701 ff. mit weiteren Nachweisen. 63 Vgl. dazu u. a. Schumacher, CR 2000, S. 641 ff. mit weiteren Nachweisen. 64 Zur Frage der Einbeziehung bzw. Zumutbarkeit der Kenntnisnahme von AGB bei Open Source Softwareüberlassungsverträgen vgl. u. a. Jaeger/Metzger, S. 147 ff.; Schiffner, S. 184 ff.; Spindler, in: Spindler, Abschn. C Rn. 47; Koch, CR S. 338 f. 65 Ziff. 2 c GPL: „If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License.“

246

§ 9 Vertragliche Einordnung der Softwareüberlassung

parenzgebotes die Verständlichkeit der AGB voraus66. Fraglich ist, ob auch fremdsprachige AGB eine zumutbare Kenntnisnahme ermöglichen. Aufgrund der Tatsache, dass die Open Source Softwarelizenzen ihren Ursprung im amerikanischen Rechtsraum haben, ist die überwiegende Anzahl der Open Source Softwarelizenzen in englischer Sprache abgefasst. Zwar sind mittlerweile auch in deutscher Sprache Übersetzungen erhältlich, überwiegend handelt es sich aber inoffizielle Übersetzungen. Diesen inoffiziellen Versionen kann man allenfalls erläuternden Charakter zusprechen, für Klärung rechtlicher Frage bleibt die Originalversion der Lizenz entscheidend67. Zudem muss berücksichtigt werden, dass sich ausländische Rechtsbegriffe mitunter schlecht in eine andere Sprache übersetzen lassen. Oft mangelt es an korrespondierenden Termini. Fraglich ist, wie sich die Verwendung englischsprachiger Lizenzen auf die Vertragsgestaltung bei Open Source Verträgen auswirkt, wenn ein „deutschsprachiger“ Nutzer das Programm nutzen will. Nach einer Ansicht liegt hier schon ein Verstoß gegen das Erfordernis der zumutbaren Kenntnisnahme68. Da eine deutsche Übersetzung vielfach nicht angeboten wird, kann der deutsche Vertragspartner die englischsprachigen AGB nicht zumutbar zur Kenntnis nehmen. Es wird die Meinung vertreten, dass die GPL den grundsätzlichen Anforderungen an die Einbeziehung von AGB in das Vertragsverhältnis nicht genügt. Dieses Problem wird dieser Auffassung nach erst dadurch behoben, dass dem potenziellen Anwender eine offizielle deutsche Übersetzung der Lizenz vorgelegt wird. Da dies nicht der Fall sei, wird die GPL nicht Vertragsgegenstand. Diese Sichtweise ist jedoch richtigerweise abzulehnen69. Zu Recht wird die englische Sprache als „lingua franca der Software-Welt“, die zudem im Internet domininiert bezeichnet70. Die potenziellen Verbraucherkreise für Software, insbesondere Open Source Software sind an die englische Sprache gewohnt und verfügen über entsprechende Sprachkenntnisse. Schon dieser „branchenspezifische“ Umstand spricht eher für eine zumutbare Kenntnisnahme. Allein der Umstand, dass für einen deutschen Nutzer das Verständnis englischsprachiger AGB mit Schwierigkeiten verbunden ist, rechtfertigt noch kein Erfordernis einer „offiziellen“ deutschen Übersetzung71. Ausschlaggebend ist vielmehr, welcher Sprache sich die Vertragsparteien im Rahmen ihrer rechtsgeschäftlichen Beziehungen bedienen72. Interessiert sich jemand 66

Palandt/Heinrichs, § 305 Rn. 41. So auch Schiffner, S. 185. 68 Omsels, in: Festschrift für Paul W. Hertin, S. 149; Plaß, GRUR 2002, S. 678; teilweise zustimmend: Spindler, in: Spindler, Abschn. C Rn. 53. 69 Schiffner, S. 185; Sester, CR 2000, S. 805; Jaeger/Metzger, S. 149 f. 70 Sester, CR 2000, S. 805. 71 In Anlehnung an BGHZ 87, 112 ff. 72 In Anlehnung an BGHZ 87, 112 ff. mit weiteren Nachweisen. 67

I. Nicht durch Distributoren vertriebene Software

247

für die Nutzung eines Open Source-Computerprogramms, weiß er, dass die Lizenzen in englischer Sprache abgefasst sind. Es ist ihm auch zumutbar, sich über den Inhalt zu informieren und sich gegebenenfalls vor Vertragsabschluss eine deutsche Übersetzung zu besorgen. Nutzt er dennoch die Software und schließt somit mit dem Vertragspartner konkludent einen Vertrag, muss er auch die nicht zur Kenntnis genommenen AGB gegen sich gelten lassen73. Würde man diese Frage der Einbeziehung an der Sprachfrage scheitern lassen, würde sich der Schutzzweck ins Gegenteil verkehren. Der Nutzer würde keine Nutzungsrechte erhalten und könnte die Open Source Software gar nicht rechtmäßig nutzen74. Im Ergebnis kann davon ausgegangen werden, dass auch in praktischer Hinsicht keine Probleme entstehen, da die Zielgruppe der Open Source Softwareverbreitung wohl über die Fähigkeiten verfügt, sich in zumutbarer Weise Kenntnis zu verschaffen. Sie nutzen Open Source Software ja gerade aufgrund der lizenzrechtlichen Besonderheiten. Wer Open Source Software also nutzt, wird sich auch praktisch schlecht auf die nicht wirksame Einbeziehung der AGB berufen können75. Somit bestehen für die Frage der wirksamen Einbeziehung Lizenzen in Open Source Verträge grundsätzlich keine spezifischen Besonderheiten. (d) Inhaltskontrolle der AGB hinsichtlich des generellen Gewährleistungs- und Haftungsausschlusses bei Open Source Software-Überlassung Geht es um die Verwendung von AGB, steht die Frage der Inhaltskontrolle im Mittelpunkt der rechtlichen Auseinandersetzung. Die einzelnen Lizenzbedingungen müssen sich hinsichtlich ihrer inhaltlichen Wirksamkeit an den §§ 307 ff. BGB messen lassen. Was Open Source-Lizenzen anbelangt, beschränkt sich die Problematik im Wesentlichen auf die Frage der Wirksamkeit des beispielsweise in Ziff. 11/12 GPL stehenden generellen Gewährleistungs- und Haftungsausschlusses, der wie folgt lautet: No Warranty 11. Because the program is licensed free of charge, there is no warranty for the program, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holders and/or other parties provide the program „as is“ without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. 73 74 75

BGHZ 87, S. 112 ff. Kreutzer, Anmerkung zu LG München I, MMR 2004, S. 697. LG München I, CR 2004, S. 775; Jaeger/Metzger, S. 149 f.

248

§ 9 Vertragliche Einordnung der Softwareüberlassung

The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction. 12. In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or redistribute the program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages.

Andere Bedingungen werden allgemein als unproblematisch angesehen76. Dies ist insofern nachzuvollziehbar, als die übrigen Lizenzbedingungen dem Nutzer Rechte einräumen. Eine Inhaltskontrolle im Bereich der Softwareüberlassung erfolgt aber immer in Fällen, in denen die AGB den Vertragspartner in der Nutzung des Computerprogramms sehr stark einschränken wollen. Es sind daher bei der Open Source Software-Überlassung die Gewährleistungs- und Haftungsregelungen, die am meisten Konfliktpotenzial bergen77. (aa) Vorbemerkung Was die Gewährleistungs- und Haftungsregelungen in Open Source-Softwareverträgen angeht, muss auch hier verdeutlicht werden, dass sich diese Regelung allein auf das Computerprogramm bezieht. Es geht mithin nicht um Sachverhalte, in denen jemand beispielsweise eine Open Source Software von einem Distributor kauft und die Datenträger mangelhaft sind oder Anleitungsbücher fehlen. Es geht um das Programm als solches und um Schäden, die infolge eines Programmmangels entstehen können. Eine Ansicht bezieht die Gewährleistungs- und Haftungsregelung auf jede denkbare Weitergabekonstellation und stellt auf das konkrete „Weitergabegeschäft“ ab78. Dies geht zu weit. Abzustellen ist auf die Nutzungsrechtseinräumung. Die Regelungen betreffend der Gewährleistung und Haftung bei Open Source-Softwareverträgen beziehen sich allein auf die eingeräumten Rechte an dem Programm. Sie sollen nicht auch die zugrunde liegenden Rechtsgeschäfte aller denkbaren Weitergabevorgänge betreffen. Dies ist Angelegenheit der jeweiligen Vertragsparteien und von ihnen zu regeln. 76

Schiffner, S. 186 f. Gesichtspunkte der außervertraglichen Haftung (ProdHG, Haftung nach den Grundsätzen der Produzentenhaftung) sollen an dieser Stelle nicht problematisiert werden. 78 Schiffner, S. 243 ff. 77

I. Nicht durch Distributoren vertriebene Software

249

(bb) Inhalt der Regelungen Alle Open Source-Lizenzen enthalten einen generellen Gewährleistungsund Haftungsausschluss. Stellvertretend soll hier auf die Ziff. 11 und 12 GPL eingegangen werden. Betrachtet man das Open Source Konzept erscheinen die Regelungen logisch und selbstverständlich. Bereits der erste Satz von Ziff. 11 GPL liefert die entscheidende Begründung mit. Weil eben keinerlei Lizenzgebühren erhoben werden, besteht keine Gewährleistung für das Computerprogramm, soweit dies gesetzlich zulässig ist. Diese Einleitung und die Verbindung zu diesem „Grundsatz“ ist der Grund dafür, dass die Open Source SoftwareÜberlassung von einigen unter das Schenkungsrecht subsumiert wird. Darüber hinaus stellt die Regelung klar, dass das Computerprogramm von den Rechteinhabern „AS IS“ zur Verfügung gestellt wird und hieraus keine ausdrücklichen oder konkludenten Gewährleistungsrechte herzuleiten sind. Die Formulierung: „The entire risk as to the quality and performance of the program is with you“ kann mit „Benutzen auf eigene Gefahr“ übersetzt werden. Zudem weist die Regelung darauf hin, dass auch Kosten für notwendigen Service, Reparatur sowie Korrekturen von dem Anwender zu tragen sind. Ziff. 11 GPL schließt an einen möglichen Programmmangel an und will die Gewährleistung modifizieren. Ziff. 12 GPL führt weiter aus, dass kein Rechteinhaber oder Dritte, die das Programm in modifizierter Form weitergeben, für keine unmittelbaren und mittelbaren Schäden (Folgeschäden) haften, die aus der Benutzung des Programms in irgendeiner Form resultieren. Dies soll nur insofern gelten, als dass dies gesetzlich zulässig ist und darüber hinaus soll der Haftungsausschluss selbst dann gelten, wenn ein Rechteinhaber oder Dritter über die Möglichkeit solcher Schäden unterrichtet war. Fraglich ist nun, ob diese Regelungen, wie sie auch in anderen Open Source Softwarelizenzen gebraucht werden, vor dem Hintergrund des deutschen Urheber- und Vertragsrechts bestehen können. Die Frage ist von zentraler Bedeutung für das „Überleben“ von Open Source. Würden diese Gewährleistungs- und Haftungsregelungen nicht durchgreifen, wäre das Risiko, eine Software als Open Source Software zu verbreiten, nicht mehr kalkulierbar. Ziff. 12 GPL enthält eine generelle Haftungsregelung, die alle möglichen Ansprüche auszuschließen versucht.

250

§ 9 Vertragliche Einordnung der Softwareüberlassung

(cc) Gewährleistungsausschluss Ziff. 11 GPL als Klauselverbot ohne Wertungsmöglichkeit gem. § 309 Nr. 8 b aa) BGB Eine Inhaltskontrolle der Lizenzbedingungen anhand der §§ 308, 309 BGB setzt voraus, dass der Erwerber der Software Verbraucher gem. § 13 BGB ist. Gem. § 310 I BGB finden die §§ 308, 309 BGB keine Anwendung auf AGB, die gegenüber einem Unternehmer, einer juristischen Person des öffentlichen Rechts oder einem öffentlich-rechtlichzem Sondervermögen verwendet werden. In diesen Fällen gilt allein § 307 I, II mit der Maßgabe des § 310 I S. 2 BGB. Ist der Anwender Verbraucher gem. § 13 BGB kann die Regelung Ziff. 11 GPL gegen § 309 Nr. 8 b aa) BGB verstoßen. Danach sind AGB unwirksam, soweit sie Bestimmungen enthalten, durch die bei Verträgen über Lieferung neu hergestellter Sachen die Ansprüche gegen den Verwender der AGB wegen eines Mangels insgesamt oder bezüglich einzelner Teile ausgeschlossen werden. Dass Software auch als Sache eingestuft werden kann, wurde bereits dargestellt. Hieraus folgend wird allgemein vertreten, dass die Regelung hinsichtlich des Gewährleitungsausschlusses in Open SourceLizenzen gegen § 309 Nr. 8 b aa) verstößt79. Nun erscheint jedoch zweifelhaft, ob es hier um Verträge über die Lieferung einer neu hergestellten Sache geht. Da sich die gesetzliche Regelung des § 309 Nr. 8 BGB auf den „Mangel“ und folglich auf die Gewährleistungsrechte bezieht, können mit der Formulierung „Lieferungen neu hergestellter Sachen“ nur Verträge gemeint sein, die Gewährleistungsrechte vorsehen80. Anwendungsbereiche des Klauselverbotes sind somit richtigerweise nur Kauf- und Werkvertragsrecht81. Die Stimmen, die einen Verstoß gegen § 309 Nr. 8 BGB sehen, nehmen aber Schenkungsrecht als Grundgeschäft an82. Richtigerweise gehören Schenkungen aber nicht zum Kreis der von § 309 Nr. 8 BGB erfassten Lieferverträge83. Insofern kann das Klauselverbot von § 309 Nr. 8 BGB hier nicht herangezogen werden, da es sich weder um Kauf- noch um Werkvertragsrecht handelt.

79

Omsels, in: Festschrift für Paul W. Hertin, S. 150 f.; Jaeger/Metzger, S. 151; Deike, CR 2003, S. 14; Spindler, in: Spindler, Abschn. D Rn. 17; Schiffner, S. 243; Stickelbrock, ZGS 2003, S. 371; Bzgl. einer gebildeten Fallgruppe bejahend: Sester, CR 2000, S. 806. 80 So zutreffend Koch, CR 2000, S. 340. 81 Palandt/Heinrichs, § 309 Rn. 53. 82 Jaeger/Metzger, S. 139 ff.; Spindler, in: Spindler, ABschn. D Rn. 6 ff.; Schiffner, S. 225 ff.; Deike, CR 2003, S. 14 ff.; Stickelbrock, ZGS 2003, S. 371. 83 So auch Marly, Rn. 440.

I. Nicht durch Distributoren vertriebene Software

251

(dd) Gewährleistungsausschluss Ziff. 11 GPL als Klauselverbot ohne Wertungsmöglichkeit gem. § 309 Nr. 7 b BGB Fraglich ist, ob Ziff. 11 GPL einer Inhaltskontrolle am Maßstab des § 309 Nr. 7 b BGB standhält. Mit Verweis auf die Kostenfreiheit will Ziff. 11 GPL jegliche Haftung für Mängel ausschließen, soweit dies gesetzlich zulässig ist. Aufgrund der Kostenfreiheit der Lizenzeinräumung muss der Anwender damit rechnen, dass ein modifizierter Haftungsmaßstab gilt. Das Risiko, eine Open Source Software zu nutzen, liegt grundsätzlich bei ihm. Dennoch kann der Rechteinhaber seine Haftung im Zusammenhang mit der Gewährleistung nicht gänzlich ausschließen. Für die Frage nach Schadensersatzansprüchen infolge eines mangelhaften Computerprogramms kann die Klausel dahingehend ausgelegt werden, dass der Rechteinhaber nicht für Mängel und die daraus resultierenden Schäden haften will, soweit dies nach dem geltenden Recht möglich ist. Fraglich ist, ob dies rechtlich möglich ist. Kaufrechtliche Aspekte könne schon aufgrund der vertraglichen Einordnung nicht herangezogen werden. Zwischen Rechteinhaber und dem Anwender besteht aber ein Schuldverhältnis in Form eines Open Source-Vertrages. Gem. § 309 Nr. 7 b BGB sind im Verbraucherverkehr solche AGB unwirksam, die die Haftung für Schäden ausschließen oder begrenzen, die nicht Leben, Körper oder Gesundheit betreffen und auf einer groben fahrlässigen Pflichtverletzung des Klauselverwenders oder auf einer vorsätzlichen oder grob fahrlässigen Pflichtverletzung eines gesetzlichen Vertreters oder Erfüllungsgehilfen beruhen. Der Vorsatz wird hier nicht besonders erwähnt, da insoweit § 276 III BGB gilt, wonach einem Schuldner (hier: dem Rechteinhaber) die Haftung wegen Vorsatzes nicht im Voraus erlassen werden kann. Die vorsätzliche Haftung kann mithin generell nicht wirksam ausgeschlossen werden. Ein genereller Gewährleistungsausschluss, der jegliche Haftung infolge eines Mangels ausschließt, verstößt gegen § 309 Nr. 7 b BGB. Auch die Formulierung „To the extent permitted by applicable law“ als salvatorische Klausel hilft hier nicht weiter. Derartige Klauseln sind in Fällen unzulässig, in denen die Rechtslage eindeutig ist und dies auch in den AGB verständlich dargestellt werden könnte84. Der Vertragspartner kann sich hier nicht erschließen, welcher Haftungsmaßstab letztendlich greifen soll. Eine zumutbare Kenntnisnahme ist daher nicht möglich. Der Verstoß gegen das Transparenzgebot verstößt gegen. § 305 II Nr. 2 BGB85. 84 BGH NJW 1991, S. 2632; BGH NJW 1981, S. 11106 ff.; Spindler, in: Spindler, Abschn. D Rn. 18 mit weiteren Nachweisen. 85 So auch Jaeger/Metzger, S. 150; Omsels, in: Festschrift für Paul W. Hertin, S. 150; Deike, CR 2003, S. 14.

252

§ 9 Vertragliche Einordnung der Softwareüberlassung

Sester86 argumentiert hingegen, die salvatorische Klausel regele keine geltungserhaltene Reduktion, sondern sei vielmehr eine Verweisung auf das nationale Recht mit der Folge, dass die Ziffern 11 und 12 GPL in ihrem lokalen Zusammenhang auszulegen seien. Auch Koch87 und Schiffner88 sehen ebenfalls mit Rücksicht auf Besonderheiten bei der Verbreitung von Open Source Software die salvatorische Klausel als wirksamen Verweis auf das jeweils nationale Recht an, da es dem Rechteinhaber bei einer weltweiten Verbreitung nicht zuzumuten sei, alle nationalen Rechtsordnungen bei der Formulierung der AGB zu berücksichtigen. Diese Sichtweise überzeugt nicht. Denn auch bei Prüfung dieser Regelungen in ihrem lokalen Zusammenhang kommt man zu keinem anderen Ergebnis. Der Anwender kann sich den konkreten Haftungsmaßstab eben nicht erschließen, obwohl eine klarstellende Regelung möglich wäre. Alleine der Verweis auf die nationale Rechtslage reicht für eine zumutbare Kenntnisnahme nicht aus. Der Lizenznehmer wäre so gehalten, sich die Haftung des Rechteinhabers selbst zu erschließen. Dies widerspräche aber gerade dem verbraucherschützenden Charakter der §§ 305 ff. BGB. Auch ergibt sich aus dem Verbreitungsmodell der Open Source Software kein Argument für eine Rechtfertigung dieser Sichtweise. Beinahe jede Software wird weltweit vertrieben. Wer in einem Land unter bestimmten Bedingungen verbreiten will, muss sich bei der Formulierung von AGB auch an die nationalen Regelungen halten. Softwareunternehmen, die ihre Produkte grenzüberschreitend vertreiben, richten sich bei der Abfassung ihrer AGB auch regelmäßig an die nationalen Rechtsvorschriften. Allein der Umstand, dass hinter einem Open Source Produkt oftmals keine Organisation steckt, die über entsprechende Resourcen für eine genaue Überprüfung ihrer AGB anhand der nationalen Gesetze verfügt, rechtfertigt keine derartige Privilegierung. Demzufolge ist die Regelung der Ziff. 11 GPL unwirksam. (ee) Die vertragliche Gewährleistung von Open Source Verträgen Aufgrund der Unwirksamkeit von Ziff. 11 GPL richtet sich der Frage der Gewährleistung und des damit verbundenen Haftungsmaßstabs nach den gesetzlichen Vorschriften. Wie oben dargestellt89, wird hier der Standpunkt vertreten, dass ein Open Source-Vertrag gem. § 311 I BGB Rechtsgrund für die Überlassung von Open Source Software ist. Fraglich ist nun, wie die Haftung bezogen auf Gewährleistungsfragen hier zu beantworten ist. Dieje86 87 88 89

Sester, CR 2000, S. 805. Koch, CR 2000, S. 340. Schiffner, S. 242. § 9 I. Nr. 9 b) bb).

I. Nicht durch Distributoren vertriebene Software

253

nigen, die grundsätzlich oder teilweise eine Schenkung als Grundgeschäft annehmen, führen die §§ 523, 524 BGB für die Haftungsfrage im Zusammenhang mit Mängeln an90. Diejenigen, die auf das Kaufrecht abstellen, entnehmen den Haftungsmaßstab den kaufrechtlichen Gewährleistungsregelungen91. Diese Regelungen helfen hier aber nicht weiter, da sowohl die kaufrechtliche wie auch die schenkungsrechtliche Lösung abgelehnt wird. Insofern wäre es auch inkonsequent, die oben genannten Regelungen entsprechend heranzuziehen. Dies ist aber auch nicht nötig, um zu einer interessengerechten Lösung zu kommen. Die Haftung für Mängel der Software richtet sich nach dem Vertrag zwischen Rechteinhaber und dem Anwender, also den Parteien der Softwareüberlassung. Welche Haftung den Rechteinhaber tritt, der ein Computerprogramm als Open Source Software Verbreitet, beantwortet das BGB nicht konkret. Der Open Source-Vertrag ist ein atypischer Vertrag, der explizit nicht im BGB geregelt ist. Ist ein Vertrag nicht ausdrücklich geregelt, gelten die allgemeinen Vorschriften. Die §§ 276, 278 BGB regeln grundsätzlich, was der Schuldner zu vertreten hat. Schuldner ist hier der Rechteinhaber, der dem Anwender entsprechend der Lizenzvereinbarung die Software zu überlassen hat. Gem. § 276 I BGB hat der Schuldner Vorsatz und Fahrlässigkeit zu vertreten, wenn eine strengere Haftung oder mildere Haftung weder bestimmt noch aus dem sonstigen Inhalt des Schuldverhältnisses zu entnehmen ist. Wie bereits zuvor erwähnt, kann der Vorsatz gem. § 276 III BGB nicht im Voraus ausgeschlossen werden. Die Vorsatzhaftung bleibt somit voll bestehen. Wer vorsätzlich ein fehlerhaftes Computerprogramm als Open Source Software verbreitet, haftet für die infolge des Mangels entstehenden Schäden. Im Übrigen sind Haftungsbeschränkungen grundsätzlich zulässig. Bei der Überlassung von Open Source Software ergibt sich eine Haftungsbeschränkung aus dem Inhalt der Open Source-Lizenzen. Die Nutzungsrechte an der Software werden ohne die Erhebung von Lizenzgebühren eingeräumt. Zudem enthalten die Lizenzbedingungen eine, wenn auch unzulässige Regelung zu einem generellen Haftungsausschluss, was Mängel angeht. Dies ist zumindest ein Anhaltspunkt, der auch für die Frage der Natur des Vertrags heranzuziehen ist. Aus der Natur eines Open Source-Vertrags ergibt sich also eine Haftungsbeschränkung derart, dass in einem Umfang keine Haftung übernommen 90 Jaeger/Metzger, S. 151 f.; Schiffner, S. 254 f.; Spindler, in: Spindler, Abschn. D Rn. 21 ff. 91 So beispielsweise Schiffner, S. 243 ff.

254

§ 9 Vertragliche Einordnung der Softwareüberlassung

werden soll, soweit dies nach dem jeweils anzuwenden Recht zulässig ist. Dies ist auch aufgrund der Unentgeltlichkeit der Nutzungsrechtseinräumung verständlich und interessengerecht. Hier kommt ein Ausschluss der Haftung für fahrlässiges Handeln in Betracht. Nun unterscheidet das Gesetz jedoch drei Stufen von Fahrlässigkeit: einfache (leichte) Fahrlässigkeit, grobe Fahrlässigkeit und die Verletzung der Sorgfalt in eigenen Angelegenheiten92. Dabei stellt § 277 BGB klar, dass derjenige, der nur für die eigenübliche Sorgfalt einzustehen hat, welcher er in eigenen Angelegenheiten anzuwenden pflegt,von der Haftung wegen grober Fahrlässigkeit nicht befreit ist. Im Interesse eines Rechteinhabers ist es, den Haftungsmaßstab mindestens auf grobe Fahrlässigkeit und Vorsatz zu beschränken, mithin die Haftung für leichte Fahrlässigkeit auszuschließen. Der Ausschluss der Haftung für leicht fahrlässiges Handeln ist grundsätzlich möglich. Dies ist auch durchaus interessengerecht. Vom objektiven Empfängerhorizont aus betrachtet, ist jedem Anwender klar, dass im Fall einer kostenlosen Nutzungsrechtseinräumung auch ein reduzierter Haftungsmaßstab gelten muss. Aufgrund der Unentgeltlichkeit der Softwareüberlassung lässt sich aus dem Inhalte eines jeden Open Source-Vertrags entnehmen, dass der Rechteinhaber keinesfalls für leichte Fahrlässigkeit einstehen will. Dies ist auch für jeden Lizenznehmer schon aus dem Umstand der Unentgeltlichkeit erkennbar. Im Ergebnis haftet der Recheinhaber also nur wegen Vorsatz und grober Fahrlässigkeit. (ff) Haftungsregelung Ziff. 12 GPL als Klauselverbot ohne Wertungsmöglichkeit gem. § 309 Nr. 7 a BGB Die überwiegende Anzahl von Open Source-Lizenzen enthalten, meist als letzte Lizenzbedingung, einen allgemeinen Haftungsausschluss. Dementsprechend regelt Ziff. 12 GPL, dass in keinem Fall, außer wenn dies das jeweils geltende Recht erfordere oder es schriftlich zugesichert worden sei, der Rechteinhaber oder ein Dritter, der das Programm bearbeitet hat und weitergibt oder einfach verbreitet, für Schäden haftet. Dabei fasst die Klausel den Haftungsausschluss weit und bezieht ihn auch auf sämtliche Folgeschäden, die aus der Nutzung des Programms resultieren. Dies soll selbst dann gelten, wenn der Rechteinhaber oder ein Dritter über die Möglichkeit solcher Schäden unterrichtet worden war. Was die Verletzung von Leben, Körper und Gesundheit, soweit sie Folge der Nutzung des Computerprogramms sind, anbelangt, kann gem. § 309 Nr. 7 a BGB die Haftung für Schäden nicht ausgeschlossen werden, soweit 92

Palandt/Heinrichs, § 277 Rn. 1.

I. Nicht durch Distributoren vertriebene Software

255

die Verletzung auf einer fahrlässigen Pflichtverletzung des Verwenders oder einer vorsätzlichen oder fahrlässigen Pflichtverletzung eines gesetzlichen Vertreters oder Erfüllungsgehilfen des Verwenders beruht. Der Anwendungsbereich erfasst Verträge jeder Art und gilt auch für unentgeltliche Verträge93. Die Regelung der Ziff. 12 GPL ist hiernach unwirksam, zumal sie die Haftung selbst dann ausschließen will, wenn der Rechteinhaber Kenntnis von möglichen Schäden hatte. Dies kann so ausgelegt werden, dass die Regelung sogar die Haftung für vorsätzliche Pflichtverletzungen ausschließen will. Dies wäre in keinem Fall zulässig. Danach verstößt eine Regelung wie Ziff. 12 GPL gegen § 309 Nr. 7 a BGB. (gg) Die vertragliche Haftung bei Open Source Verträgen Da auch hier die entsprechende Regelung in den AGB unwirksam ist, stellt sich auch bezüglich der „generellen“ Haftung die Frage, welcher Haftungsmaßstab sich aus dem Grundgeschäft ergibt. Die Frage des Haftungsmaßstabs ist hier wie bei der Frage nach der Gewährleistung zu beantworten. Dabei ergibt sich nichts anderes. Die Haftung für Vorsatz kann gem. § 276 III BGB nicht im Voraus ausgeschlossen werden. Dies gilt im Übrigen auch für den kaufmännischen Geschäftsverkehr. Hier gilt auch der Haftungsmaßstab gem. § 277 BGB. Danach haftet der Rechteinhaber oder ein Dritter, der das Programm in modifizierter Version weitergibt, bei Schäden des Anwenders in Fällen, in denen er vorsätzlich oder grob fahrlässig gehandelt hat94. In diesem Zusammenhang ergibt sich somit nichts anderes. Auch die Formulierung „Unless required by applicable law“ hilft aus den oben genannten Gründen nicht weiter. Danach bleibt es bei einer Haftung für vorsätzlichen und grob fahrlässiges Handeln. (3) Zwischenergebnis Der Open Source-Vertrag wird inhaltlich durch die im konkreten Einzelfall verwendeten Lizenzbedingungen ausgestaltet, die als AGB zu qualifizieren sind. Beinhaltet eine Open Source-Lizenz einen generellen Gewährleistungsund Haftungsausschluss, wie er in Ziff. 11 und 12 GPL niedergelegt ist, ist dieser nach den Vorschriften der §§ 305 ff. BGB unwirksam. Eine Unwirksamkeit dieser Regelungen hat zur Folge, dass Gewährleistungs- und Haf93 94

Palandt/Heinrichs, § 309 Rn. 41; Jaeger/Metzger, S. 155; Marly, Rn. 1326. Jaeger/Metzger, S. 155.

256

§ 9 Vertragliche Einordnung der Softwareüberlassung

tungsmaßstäbe dem Inhalt des Vertrages zu entnehmen sind. Der Natur eines Open Source-Vertrages entspricht es, die Haftung auf leichte Fahrlässigkeit zu beschränken. 10. Ergebnis Vieles spricht dafür, einen Open Source-Vertrag als atypischen Vertrag zuzulassen und in Zukunft weiterzuentwickeln. Für den Bereich Open Source Software bildet dieser jedenfalls den Rechtsgrund der Nutzungsrechtseinräumung.

II. Vertragliche Einordnung von Softwareüberlassung bei Vertrieb von Open Source Software durch Distributoren Open Source Software wird teilweise durch Distributoren vertrieben. Auch hier stellt sich die Frage nach der vertraglichen Einordnung. Hierbei gilt es jedoch grundsätzlich zwei Vorgänge zu unterscheiden. 1. Einräumung urheberrechtlicher Nutzungsrechte am Computerprogramm Der Distributor überlässt dem Anwender das Computerprogramm dem Anwender in Form einer Programmkopie. Damit kann der Anwender als Kunde des Distributor jedoch nichts anfangen, soweit er keine Nutzungsrechte eingeräumt bekommt. Diese erhält er aber regelmäßig nicht vom Distributor, da dieser nicht Urheber ist. Der Distributor kann natürlich Open Source Software verbreiten, er tritt aber gegen über einem nutzungsinteressierten Dritte wie gesagt als Bote auf. Der Anwender erhält die Nutzungsrechte demzufolge letztlich vom Urheber des Computerprogramms, wenn der die Lizenzbedingungen akzeptiert. Der Lizenzvertrag wird zwischen dem Urheber und dem Anwender und nicht zwischen dem Distributor und dem Anwender geschlossen. Für diesen Vorgang kann mithin nach oben verwiesen werden. 2. Abschluss eines Distributorenvertrages Verbreitet jemand ein Open Source-Computerprogramm und bietet Zusatzleistungen gegen Entgelt an, spricht man von einer Distribution. Grundlage der Zusatzdienstleistungen (z. B. Überlassung einer Programmkopie auf DVD, Sammlung von kompatibler Zusatzsoftware, Handbücher, Support)

III. Die Ankunft des Open Source-Gedankens im UrhG

257

kann ein Vertrag mit kauf-, werk- oder dienst-, mietvertraglichen Elementen sein. In diesen Fällen richtet sich die vertragliche Einordnung, die Inhaltskontrolle der AGB sowie Haftungsfragen, bezogen auf die Distributorenleistung, nach dem konkreten Einzelfall.

III. Die Ankunft des Open Source-Gedankens im UrhG Eines der Hauptprobleme, dass das UrhG der Open Source-Idee bereithielt, war die Regelung des § 32 UrhG a. F., wonach der Urheber nicht auf seinen Anspruch auf angemessene Vergütung verzichtet konnte. Nach der alten Regelung war die kostenlose Nutzungsrechtseinräumung gesetzlich unzulässig. Mit der aktuellen, seit 01.07.2002 geltenden Fassung hat der Gesetzgeber den Open Source-Gedanken erstmals anerkannt und in § 32 III S. 2 UrhG die Regelung eingeführt, wonach der Urheber jedenfalls unentgeltlich Nutzungsrechte an jedermann einräumen kann95. Damit hat der Gesetzgeber die Entwicklung im Bereich Open Source anerkannt96 und das Hindernis durch die Altregelung beseitigt. Diese Neuregelung macht deutlich, dass die Open Source-Idee im deutschen UrhG angekommen ist. Gespannt darf man sein, ob der Gesetzgeber weitere Änderungen vornimmt, um auch in noch strittigen Fragen Rechtsklarheit zu schaffen oder ob er die Gerichte damit alleine lässt.

95 BT-Drucks. 14/6433, S. 15; BT-Drucks. 14/8058, S. 19; Dreier/Schulze, § 32 Rn. 80; Wandtke/Bullinger/Wandtke/Grunert, § 32 Rn. 45; Kotthoff, in: HK-UrhR, § 32 Rn. 43. 96 So auch LG München I, CR 2004, S. 776. 17 Teupen

§ 10 Fazit und Ausblick Open Source ist im deutschen Urheberrecht angekommen. Die schnelle Verbreitung von Open Source Software hat mittlerweile erstmals die Beschäftigung eines deutschen Gerichts zur Folge gehabt. Es ist davon auszugehen, dass in Zukunft vermehrt Rechtsstreitigkeiten vor die Gerichte getragen werden, in denen Open Source Software der Gegenstand der Auseinandersetzung ist. Allein die Tatsache, dass sich auch immer mehr Softwareunternehmen in diesem Bereich engagieren, stützt diese Vermutung. Die Ausführungen im Rahmen der vorliegenden Arbeit haben gezeigt, dass das „Copyleft“-Modell nicht am UrhG scheitert. Das internationale Urheberrecht führt gerade in Bereichen eines grenzüberschreitenden Verbreitungsmodells wie Open Source Software in vielen Fällen zur Anwendung des UrhG. Allerdings suggeriert die Bezeichnung „Copyleft“, dass die Urheber auf ihre Urheberrechte verzichten würden. Die Arbeit hat deutlich gemacht, dass dies gerade nicht der Fall ist. Das Urheberecht wird vielmehr benötigt, um ein Werk als Open Source zu verbreiten. Die Urheber, die sich für eine Open Source-Verbreitung entscheiden, sind auf ein funktionierendes Urheberechtssystem angewiesen. Es werden Nutzungsrechte ohne Erhebung von Lizenzgebühren eingeräumt, die aber an die Einhaltung von Bedienungen geknüpft sind. Erst die Einhaltung der Lizenzbedingungen gewährleistet die Funktionsfähigkeit des Modells. Der Verstoß führt zum Rechtsverlust und zu einer Urheberrechtsverletzung. Das Urheberrecht gewährleistet Open Source! Open Source ist insofern auch nichts Revolutionäres. „Like many elements of the Internet economy, the media surrounds open source software with an overblown mix of hype and cynicism“1. Aus juristischer Sicht handelt sich eben „nur“ um eine neue Art von Lizenz. Nicht mehr, nicht weniger! Diese aus dem amerikanischen Rechtsraum stammende Lizenz kann in Einzelfragen zu Problemen führen. Bei einer unüberschaubaren Entwicklergemeinde wird die Frage nach der Urheberschaft praktisch nicht eindeutig beantwortet werden können. Vielleicht lässt sich dies aber durch neue Dokumentationsmechanismen erfolgreich regulieren. Auch hat die Arbeit deutlich gemacht, dass im Bereich des Vertragsrechts eine klare vertragliche 1

Weber, S. 224.

§ 10 Fazit und Ausblick

259

Qualifikation schwierig ist. Aufgrund der Verbreitung von Open Source Software erscheint die Annahme eines Open Source-Vertrages als atypische Vertragsart sinnvoll. Er bietet die Möglichkeit, dem Open Source-Gedanken auch in Bereichen außerhalb von Software einen rechtlichen Rahmen zu geben. Ein Blick in die Zukunft fällt schwer. Gerade im Bereich der Informationstechnologie sind Prognosen ein unseliges Unterfangen. In juristischer Hinsicht jedenfalls darf man auf die Entwicklung gespannt sein. Die Diskussionen werden auch hier anhalten, die Gerichte hoffentlich mit Open Source beschäftigt werden, und im Idealfall zeigt der Gesetzgeber, wie er Open Source rechtlich würdigt. Jedenfalls hat die Open Source-Community dafür gesorgt, dass auch in Deutschland rechtswissenschaftlich denkende Menschen ein neues Thema für sich entdecken durften.

„Open Source is not a piece of software, and it is not unique to a group of hackers“. Steven Weber

17*

Literaturverzeichnis Ahlberg, Hartwig/Nicolini, Käte (Hrsg.): Urheberrechtsgesetz-Kommentar, 2. Auflage, München, 2000 [zitiert: Möhring/Nicolini/Bearbeiter, §, Rn.] Albrecht, Friedrich: Technizität und Patentierbarkeit von Computerprogrammen, Computer und Recht, 1998, 694 ff. [zitiert: Albrecht, CR 1998, S.] Barr, Christian v./Mankowski, Peter: Internationales Privatrecht, Band I, Allgemeine Lehren, München, 2003 Bartsch, Michael: Softwareüberlassung – was ist das? Computer und Recht, 1992, 393 ff. [zitiert: Bartsch, CR 1992, S.] – Grad der Marktdurchdringung von Software als rechtliches Kriterium, Computer und Recht, 1994, 667 ff. [zitiert: Bartsch, CR 1994, S.] Bauer, Klaus-Albert: Rechtsschutz von Computerprogrammen in der Bundesrepublik Deutschland – eine Bestandsaufnahme nach dem Urteil des Bundesgerichtshof vom 9. Mai 1985, Computer und Recht, 1985, 5 ff. [zitiert: Bauer, CR 1985, S.] Baumbach, Adolf/Hefermehl, Wolfgang (Hrsg.): Wettbewerbsrecht, 22. Auflage, München, 2001 [zitiert: Baumbach/Hefermehl/Bearbeiter, §, Rn.] Betten, Jürgen: Titelschutz für Computersoftware, Computer und Recht, 1995, 383 ff. [zitiert: Betten, CR 1995, S.] Bettinger, Torsten/Scheffelt, Michael: Application Service Providing: Vertragsgestaltung und Konflikt-Management, Computer und Recht, 2001, 729 ff. [zitiert: Bettinger/Scheffelt, CR 2001, S.] Brandi-Dohrn, Matthias: Das UN-Kaufrecht, Computer und Recht, 1991, 705 ff. [zitiert: Brandi-Dohrn, CR 1991, S.] Brox, Hans/Walker, Wolf-Dietrich: Besonderes Schuldrecht, 28. Auflage, München, 2003 Broy, Manfred/Lehmann, Michael: Die Schutzfähigkeit von Computerprogrammen nach dem neuen europäischem und deutschem Urheberrecht – eine interdisziplinäre Stellungnahme, Gewerblicher Rechtsschutz und Urheberrecht, 1992, 419 ff. [zitiert: Broy/Lehmann, GRUR 1992, S.] Davies, Gillian: Copyright and the Public Interest, 2. Auflage, London, 2002 Deike, Thies: Open Source Software: IPR-Fragen und Einordnung ins deutsche Rechtssystem, Computer und Recht, 2003, 9 ff. [zitiert: Deike, CR 2003, S.] Delp, Ludwig: Das Recht des geistigen Schaffens in der Informationsgesellschaft, 2. Auflage, München, 2003

Literaturverzeichnis

261

Diedrich, Oliver: SCO verunsichert den Linux-Markt, Computer und Technik, 2003, Nr. 12, 66 Dreier, Thomas: Urheberrechte an der Schwelle des 3. Jahrtausends – Einige Gedanken zur Zukunft des Urheberrechts, Computer und Recht, 2000, 45 ff. [zitiert: Dreier, CR 2000, S.] – Primär- und Folgemärkte, in: Schricker, Gerhard/Dreier, Thomas/Kur, Annette (Hrsg.): Geistiges Eigentum im Dienst der Innovation, Baden-Baden, 2001 – Wem gehört die Information im 21. Jahrhundert? Proprietäre versus nicht-proprietäre Verwertung digitaler Inhalte, In: Büllesbach, Alfred/Dreier, Thomas (Hrsg.): Wem gehört die Information im 21. Jahrhundert? Köln, 2004 Dreier, Thomas/Schulze, Gernot (Hrsg.): Urheberrechtsgesetz, 2004 [zitiert: Dreier/ Schulze, §, Rn.] Dreyer, Gunda/Kotthoff, Jost/Meckel, Astrid (Hrsg.): Heidelberger Kommentar zum Urheberrecht, Heidelberg, 2004 [zitiert: Bearbeiter: in HK-UrhR, §, Rn.] Endler, Maximilian/Daub, Jan: Internationale Softwareüberlassung und UN-Kaufrecht, Computer und Recht, 1993, 601 ff. [zitiert: Endler/Daub, CR 1993, S.] Erdmann, Willi: Möglichkeiten und Grenzen des Urheberrechts, Computer und Recht, 1986, 249 ff. [zitiert: Erdmann, CR 1986, S.] Flechsing, Norbert: Urheberrecht in der Wissensgesellschaft, Zeitschrift für Rechtspolitik, 2004, 249 ff. [zitiert: Flechsing, ZRP 2004, S.] Fromm, Friedrich Karl/Nordemann, Jan-Bernd (Hrsg.): Urheberrecht, 9. Auflage, Stuttgart, Berlin, Köln, 1998 [zitiert: Fromm/Nordemann/Bearbeiter, §, Rn.] Funke, Fritz: Buchkunde, 6. Auflage, München, 1992 Gamm, Otto-Friedrich von: Kommentar zum Urheberrechtsgesetz, München, 1968 Gehring, Robert A./Lutterbeck (Hrsg.): Open Source Jahrbuch 2004, Berlin, 2004 [zitiert: Bearbeiter, OSJ 2004, S.] Grassmuck, Volker: Freie Software – Zwischen Privat- und Grundeigentum, Bonn, 2002 Haberstrumpf, Helmut: Handbuch des Urheberrechts, 2. Auflage, Neuwied, 2000 Hansen, Hans Robert: Wirtschaftsinformatik, Band I, 7. Auflage, Stuttgart, 1998 Heussen, Benno: Rechtliche Verantwortungsebenen und dingliche Verfügungen bei der Überlassung von Open Source Software, Multimedia und Recht, 2004, 445 ff. [zitiert: Heussen, MMR 2004, S.] Hilty, Reto M.: Der Softwarevertrag – ein Blick in die Zukunft, Multimedia und Recht, 2003, 3 ff. [zitiert: Hilty, MMR 2003, S.] – Der „zweite Korb“ – ein erster Schritt in die richtige Richtung, Multimedia und Recht, 2004, 713 ff. [zitiert: Hilty, MMR 2004, S.] Hoeren, Thomas: IPR und EDV-Recht, Computer und Recht, 1993, 129 ff. [zitiert: Hoeren, CR 1993, S.]

262

Literaturverzeichnis

– Multimedia als noch nicht bekannte Nutzungsart, Computer und Recht, 1995, 710 ff. [zitiert: Hoeren, CR 1995, S.] – Entwurf einer EU-Richtlinie zum Urheberrecht in der Informationsgesellschaft, Multimedia und Recht, 2000, 515 ff. [zitiert: Hoeren, MMR 2000, S.] Hoeren, Thomas/Sieber, Ulrich (Hrsg.): Handbuch Multimediarecht, München, 2004 [zitiert: Hoeren/Sieber/Bearbeiter, Abschn. Rn.] Hubmann, Heinrich/Götting, Horst-Peter: Gewerbliche Rechtsschutz, 7. Auflage, München, 2002 Jaeger, Till/Metzger, Axel: Open Source Software-Rechtliche Rahmenbedingungen der freien Software, München, 2002 Jayme, Erik/Hausmann, Reiner: Internationales Privat- und Verfahrensrecht, 11. Auflage, München, 2002 Junker, Abbo: Die Entwicklung des Computerrechts in den Jahren 2001/2002, Neue Juristische Wochenschrift, 2003, 2792 ff. [zitiert: Junker, NJW 2003, S.] Junker, Abbo/Berecke, Martina: Computerrecht, 3. Auflage, Baden-Baden, 2003 Kilian, Wolfgang/Heussen, Benno (Hrsg.): Computerrechtshandbuch, München, 2002 [zitiert: Kilian/Heussen/Bearbeiter, CHB, Nr. Rn.] Kindermann, Manfred: Softwarepatentierung, Computer und Recht, 1992, 577 ff. [zitiert: Kindermann, CR 1992, S.] – Softwarepatentierung (II), Computer und Recht, 1992, 658 ff. [zitiert: Kindermann, CR 1992, S.] Kirchner, Hildebert/Butz, Cornelie: Abkürzungsverzeichnis der Rechtssprache, Band 5, Berlin, 2003 Koch, Frank: Software- und Datenbank-Recht, Berlin/Heidelberg, 2003 Koch, Frank A.: Rechtsschutz für Benutzeroberflächen, Gewerblicher Rechtsschutz und Urheberrecht, 1991, 180 ff. [zitiert: Koch, GRUR 1991, S.] – Urheber- und kartellrechtliche Aspekte der Nutzung von Open-Source-Software (I), Computer und Recht, 2000, 273 ff. [zitiert: Koch, CR 2000, S.] Kröger, Detlef: Informationsfreiheit und Urheberrecht, München, 2002 Lehmann, Michael (Hrsg.): Rechtsschutz von Computerprogrammen, 2. Auflage, Köln, 1993 [zitiert: Lehmann/Bearbeiter, S.] Lehmann, Michael: TRIPS/WTO und der internationale Schutz von Computerprogrammen, Computer und Recht, 1996, 2 ff. [zitiert: Lehmann, CR 1996, S.] – Titelschutz für Software, Computer und Recht, 1998, 2 ff. [zitiert: Lehmann, CR 1998, S.] – Die IT-relevante Umsetzung der Richtlinie Urheberrecht in der Informationsgesellschaft, Computer und Recht, 2003, 553 ff. [zitiert: Lehmann, CR 2003, S.] Lesshaft, Karl/Ulmer, Detlef: Urheberrechtsschutz von Computerprogrammen nach der Europäischen Richtlinie, Computer und Recht, 1991, 519 ff. [zitiert: Lesshaft/Ulmer, CR 1991, S.]

Literaturverzeichnis

263

Loewenheim, Ulrich (Hrsg.): Handbuch des Urheberrechts, München, 2003 [zitiert: Loewenheim/Bearbeiter, §, Rn.] Lutterbeck, Bernd: Globalisierung des Rechts – am Beginn einer neuen Rechtskultur, Computer und Recht, 2000, 2 ff. [zitiert: Lutterbeck, CR 2000, S.] Marly, Jochen: Softwareüberlassungsverträge, 4. Auflage, München, 2004 Meretz, Stefan: Linux & Co – Ideen für eine andere Gesellschaft, Neu-Ulm, 2000 Metzger, Axel/Jaeger, Till: Open Source Software und deutsches Urheberrecht, Gewerblicher Rechtsschutz und Urheberrecht, 1999, 839 ff. [zitiert: Metzger/Jaeger, GRUR 1999, S.] Moritz, Hans-Werner: Softwarelizenzverträge (I), Computer und Recht, 1993, 257 ff. [zitiert: Moritz, CR 1993, S.] Moritz, Hans-Werner/Dreier, Thomas (Hrsg.): Rechts-Handbuch zum E-Commerce, Köln, 2002 [zitiert: Moritz/Dreier/Bearbeiter, E-Commerce, Abschn. C Rn.] Nüttgens, Markus: Consulting-Wissen für die Strategie-, Prozess und IT-Beratung, Saarbrücken: Scheer, A.-W. and Köppen, Alexander, 2001 Nüttgens, Markus/Tesei, Enrika: Veröffentlichungen des Instituts für Wirtschaftsinformatik, Saarland: Scheer, A.-W., 2000 o. A.: Computerlexikon, 4. Auflage, München: Irlbeck, Thomas and Langenau, Frank, 2002, Beck EDV-Berater – Der Brockhaus-Computer und Informationstechnologie, Mannheim, 2003 Ohly, Ansgar: Software und Geschäftsmethoden, Computer und Recht, 2001, 809 ff. [zitiert: Ohly, CR 2001, S.] Palandt, Otto (Hrsg.): Bürgerliches Gesetzbuch, 65. Auflage, München, 2005 [zitiert: Palandt/Bearbeiter, §, Rn.] Piltz, Burghard: Vom EuGVÜ zur Brüssel-I-Verordnung, Neue Juristische Wochenschrift, 2002, 789 ff. [zitiert: Piltz, NJW 2002, S.] Plaß, Gunda: Open Contents im deutschen Urheberrecht, Gewerblicher Rechtsschutz und Urheberrecht, 2002, 670 ff. [zitiert: Plaß, GRUR 2002, S.] Pres, Andreas: Gestaltungsformen urheberrechtliche Softwarelizenzverträge, Köln, 1994 Raubenheimer, Andreas: Softwareschutz nach den Vorschriften des UWG, Computer und Recht, 1994, 264 ff. [zitiert: Raubenheimer, CR 1994, S.] Rehbinder, Manfred: Urheberrecht, 12. Auflage, München, 2002 Rigamonti, Cyrill P.: Geistiges Eigentum als Begriff und Theorie des Urheberrechts, Baden-Baden, 2001 Rosenberg, Donald K.: Open Source: The Unauthorized White Papers, Foster City/ Chicago/Indianapolis/New York, 2000 Röttinger, Moritz: Patentierbarkeit computerimplementierter Erfindungen, Computer und Recht, 2002, 616 ff. [zitiert: Röttinger, CR 2002, S.]

264

Literaturverzeichnis

Schallbruch, Martin: E-Government: Der Staat als Nachfrager und Anbieter, in: Büchner, Wolfgang/Büllesbach, Alfred (Hrsg.): E-Government – Staatliches Handeln in der Informationsgesellschaft, Köln, 2003 Schiffner, Thomas: Open Source Software, München, 2003 Schippan, Martin: Nun endgültig verabschiedet: Das digitale Urheberrecht – Korb 1, Zeitschrift für Urheber- und Medienrecht, 2003, 387 ff. [zitiert: Schippan, ZUM 2003, S.] Schneider, Jochen: Handbuch des EDV-Rechts, 3. Auflage, Köln, 2003 Schricker, Gerhard (Hrsg.): Urheberrecht, 2. Auflage, München, 1999 [zitiert: Schricker/Bearbeiter, §, Rn.] Schuhmacher, Dirk: Wirksamkeit von typischen Klauseln in Softwareüberlassungsverträgen, Computer und Recht, 2000, 641 ff. [zitiert: Schuhmacher, CR 2000, S.] Sester, Peter: Open-Source-Software: Vertragsrecht, Haftungsrisiken und IPR-Fragen, Computer und Recht, 2000, 797 ff. [zitiert: Sester, CR 2000, S.] Sieber, Ulrich: Bilanz eines „Musterverfahrens“, Computer und Recht, 1986, 699 ff. [zitiert: Sieber, CR 1986, S.] Sonntag, Peter: Das Miturheberrecht, Köln, 1972 Spindler, Gerald (Hrsg.): Rechtsfragen bei Open Source, Köln, 2004 [zitiert: Bearbeiter in: Spindler, Abschn., Rn.] Spindler, Gerald/Wiebe, Andreas: Open Source-Vertrieb, Computer und Recht, 2003, 873 ff. [zitiert: Spindler/Wiebe, CR 2003, S.] Stallmann: Free Software/Free Society: selected essays of Richard M. Stallmann, Boston: Gay, Joshua, 2002 Staudinger, J. von (Hrsg.): Kommentar zum Bürgerlichen Gesetzbuch, Berlin/New York: von Staudinger, J., 1993 ff. [zitiert: Staudinger, §, Rn.] Stemplinger, Eduard: Das Plagiat in der griechischen Literatur, Leipzig/Berlin, 1912 Taeger, Jürgen: Softwareschutz durch Geheimnisschutz, Computer und Recht, 1991, 449 ff. [zitiert: Taeger, CR 1991, S.] Torvalds, Linus: Just for Fun, München, 2002 Troller, Alois: Der urheberrechtliche Schutz von Inhalt und Form der Computerprogramme, Computer und Recht, 1987, 352 ff. [zitiert: Troller, CR 1987, S.] Walch, Dieter E.: „Ersatz-Ausschließlichkeitsrechte“ bei Computerprogrammen und ästhetischen Schöpfungen, München: Sieber, Ulrich, 2002 Walter, Michael (Hrsg.): Europäisches Urheberrecht, Wien/New York, 2001 [zitiert: Bearbeiter in: Walter in: v. Lewinski/Walter/Blocher/Dreier/Daum/Dillenz, Europäisches Urheberrecht Art., Rn., Richtlinie] Wandtke, Artur-Axel/Bullinger, Winfried (Hrsg.): UrhG-Praxiskommentar zum Urheberrecht, München, 2002 [zitiert: Wandtke/Bullinger/Bearbeiter, §, Rn.]

Literaturverzeichnis

265

Weber, Steven: The Success of Open Source, Cambridge/Massachusetts/London (GB), 2004 Wernicke, Nina/Hoppe, Vera: Die neue EUGVO-Auswirkungen auf die internationale Zuständigkeit bei Internetverträgen, Multimedia und Recht, 2002, 643 ff. [zitiert: Wernicke/Hoppe, MMR 2002, S.] Westerholt, Margot Gräfin von/Berger, Konrad: Der Application Service Provider und das neue Schuldrecht, Computer und Recht, 2002, 81 ff. [zitiert: von Westerholt/Berger, CR 2002, S.] Wheeler, David A.: Why Open Source Software/Free Software (OSS/FS) – Look at the Numbers! 2006 (URL: www.dwheeler.com/oss_fs_why.html) Wiebe, Andreas: Rechtsschutz für Software in den neunziger Jahren, Betriebsberater, 1993, 1094 ff. [zitiert: Wiebe, BB 1993, S.] – Softwarepatente und Open Source, Computer und Recht, 2004, 881 ff. [zitiert: Wiebe, CR 2004, S.] Witte, Andreas: Urheberrechtliche Gestaltung des Vertriebs von Standardsoftware, Computer und Recht, 1999, 65 ff. [zitiert: Witte, CR 1999, S.] Wuermeling, Ulrich: Neue US-Entscheidungen zum Softwareschutz, Computer und Recht, 1993, 665 ff. [zitiert: Wuermeling, CR 1993, S.] Zahrnt, Christoph: Titelschutz für Software-Produkte, Betriebsberater, 1996, 1570 ff. [zitiert: Zahrnt, BB 1996, S.]

Sachwortverzeichnis Absolute Rechte 75 AGB 143, 225, 240 ff., 250 ff., 255, 257 Affero General Public License 188 Aktivlegitimation 122, 156, 160, 162 ff. Aktuelle Entwicklungen 79 Algorithmen 32, 71, 92 ff. Alleinurheberschaft 98 Allgemeingut 91 Anwendungsbereich 112, 120, 138, 139, 144 f., 152, 175, 178, 214, 250, 255 Apache-Programme 44, 167 f., 200 Application Service Providing 110, 187 Arbeitnehmererfinderrecht 107 Arbeitsspeicher 109, 175 ASP 187 ff., 201 AT&T 28, 38 f. Aufenthaltsort 130, 132 ff., 138 f. Auftrag 27, 86, 101, 119, 128, 227, 230 Ausdrucksform 21, 69 f., 75, 77, 82, 85 ff., 93, 95, 119 Ausschließlichkeitsrechte 26, 108, 113, 152 Bearbeiterketten 153, 156 Bearbeitung 108 f., 153 ff., 160, 174, 189 ff., 227 Bearbeitungsrecht 109, 112, 190, 192 Bedingungseintritt 207 Begleitmaterial 33, 85 bekannte Nutzungsart 180, 182, 188 Bereicherung 234, 237 f. Berkeley Software Distribution 39, 167 Beweislastumkehr 162 BGB-Gesellschaft 102, 131 f., 154 ff., 159, 164, 226 ff.

Bremer Lizenz 119 Computerimplementierte Erfindungen 79 ff., 83, 108 Computerspiele 90 f. Copyleft-Effekt, ohne 167 Copyleft-Effekt, strenger 167, 215 Copyleft-Modell 30, 56 f., 60, 64, 168 f., 191, 193 f., 196, 198, 200, 202, 204, 206, 208, 210, 212 Copyright-Vermerk 174, 176, 191, 245 CPU-Klauseln 117, 208, 210, 211 Datenbank 91 Dekompilierung 112, 113 Digitalisierung 21, 54, 120 Dinglich wirkender Vorbehalt 207 ff. Direkterwerb 221 f. Distributoren 47, 50, 225, 227, 229, 231, 233, 235, 237, 239, 241, 243, 245, 247, 249, 251, 253, 255 ff. Dokumentation 85, 156 f., 161, 163, 165 Domizilprinzip 143 Download 111, 124, 132 ff., 138, 180, 214, 226, 230 f. Eigene Nutzungsart 196, 199, 203 Eigentumsschutz 53 Einbeziehung, wirksame 244, 247 Einfaches 170 ff. Embedded Systeme 47, 175 Entreicherung 233 f., 237 Entwicklergemeinschaft 155, 228 Entwurfsmaterial 85 f., 119 EPA 78 ff. Erfindung 69, 75 ff., 102, 108 EuGVO 142, 144 ff.

Sachwortverzeichnis Fonts 90 Free Software 28 ff., 33 f., 39, 44, 57 f., 60, 128, 163 f., 166, 168, 177, 192 Free Software-Definition 39, 57 f., 166, 168, 177 Free Software Foundation 34, 163 f., 192 Freeware 35 General Public License 27, 41, 119, 127 f., 168, 174, 188 Gerichtsstand 141 f., 147 Gerichtsstandsvereinbarung 141 ff., 147, 148 Gesamthand 103 ff., 132, 139, 155 Gesamthandsgemeinschaft 102 ff., 131, 159, 164 Gesamtidee 100, 158, 160 Gesellschaftsvertrag 154, 159, 227 f. GNU-Projekt 40 ff., 60 Google 94 Grundfreiheiten 57 f., 242 Hacker 47, 259 Haftung 231, 236, 239, 248 f., 254 Haftungsausschluss 176, 189, 191, 203, 247, 249, 253 ff. Haftungsregelung 239, 248 f., 254 Historische Entwicklung 28, 36 f., 39, 41 IBM 28, 36 f., 47 f., 50, 52 Idee 40 f., 70, 77, 82, 86, 93, 216, 231, 257 Ideen 28, 75, 86 f., 89, 91 ff., 101, 112 Individualsoftware 86 Informationsgesellschaft 21 ff., 27, 44, 55, 111, 178 Informationstechnologie 24, 26, 84, 259 Informationszeitalter 22, 53 InfoSoc-RL 22, 111 Inhaltskontrolle 247 f., 250 f., 257 Internationales Urheberrecht 119 f.

267

Internet 21, 46, 51, 59, 64, 110, 119 f., 123, 133 ff., 147, 178 ff., 202, 209, 214, 217, 225 f., 231, 246, 258 Kaufvertrag 137, 203, 210, 229 Kennzeichnung 73, 74 Kerntheorie 78 Kollisionsrecht 119 f., 124, 126, 129, 134, 138 f., 242 Kostenfreiheit 199, 203, 215, 219, 223 f., 230 f., 251 Kumulationsprinzip 70 Leihe 214, 231 Linux 27 f., 36, 42 ff., 46, 48 ff., 63, 119, 128 f., 132, 199 f., 204 f., 218 Lizenzvertrag 116, 130, 133 ff., 146, 148, 163, 210, 212, 220, 242, 244, 256 Markenrecht 39, 73 ff. MIT 39, 40, 61 Mit Auslandsbezug 121, 124, 126, 139, 141 ff., 148 f. Miturheberschaft 99 ff., 131 f., 139, 158 ff., 164 Multics 38 Nachahmung 70, 115 Novellierung 23, 66 Nutzungsbefugnisse 58, 170, 174, 202 Nutzungsrechte 106, 108, 116 f., 125, 127, 130, 133 f., 134, 151, 155, 159 f., 164, 169, 171 ff., 176, 180 f., 184, 193 ff., 200, 205 ff., 211, 215, 222 f., 225 f., 231 ff., 236 ff., 240 f., 247, 253, 256 ff. OEM-Software 198 Open Office 119 Open Source-Definition 33 f., 57 f., 166, 168, 177, 242 Open Source Initiative 34, 62 Parteiautonomie 125 Patentanmeldung 78, 81 ff.

268

Sachwortverzeichnis

Patentrecht 69, 75 ff., 79 ff., 114 f. Pflichtenheft 86 Programmbibliotheken 91 Programmdatenbanken 91 Programmkopie 58, 190, 200, 214, 216, 256 Programmsperren 71 Prozessstandschaft 161 f., 172 Public Domain Software 35 Quellcode 28, 32 ff., 37 f., 40, 43, 45, 47, 58 ff., 62 f., 71 f., 87 ff., 95, 109, 112, 119, 152, 174, 176, 189 f., 215 Rechtsverletzungen 105, 113, 122, 141, 156, 161, 180 Rechtswahl 125 ff., 133, 135, 137 f. Relative Rechte 69, 75 Schenkung 195 f., 227, 232 ff., 238 ff., 249 f., 253 Schnittstellen 95 f., 112 f. Schrankenbestimmungen 23, 111 Schutzdauer 122, 159 Schutzgegenstand 29, 84, 118 Schutzlandprinzip 122, 127 f., 183 Schutzrechte 22, 56, 65, 115, 137, 141 Schutzumfang 82, 86 Schutzvoraussetzungen 66, 76, 96, 115 Sicherungskopie 112 Softwarelizenzen 167, 173, 239, 243, 246, 249 Softwarepiraterie 25 f. Spaltungstheorie 126 Sprachwerk 84 ff. Stand der Technik 80 Standardsoftware 138, 232 Sukzessionsschutz 172 Support 46 f., 50, 61, 110, 186, 203, 256 Supportkosten 46 f., 110

Technische Lehre 75, 82 Theorie der Gesamtbetrachtung 78, 80 Titelschutz 73 f. Trennungsprinzip 125 Unentgeltlichkeit 186, 231, 234 f., 238 f., 254 Unix 28, 36, 38 ff. Unterlizenz 220 Unterscheidungskraft 74 Urhebergesetz 25, 54, 120 f. Urheberrechtsschutz 54 f., 66 f., 84, 86, 92 f., 119 Urheberschaft 98 ff., 131 f., 139, 151 ff., 155, 157 ff., 244, 258 Urhebervertragsrecht 30, 124, 146, 169, 225 Verbraucherkollisionsrecht 134 Verbraucherschutzrecht 135 Verbreitungsrecht 109 ff., 174, 177 ff., 183 ff., 189 ff., 197 ff., 213 f., 216 ff., 220 f., 223 f., 238 Verkehrsdurchsetzung 74 Vermietrecht 110 f., 185 ff. Vertrag sui Generis 116, 228, 241 Vertragsrecht 30, 69, 75, 124, 146, 169, 225 f., 243, 249 f., 258 Vertragsstatut 125 f. Verwaltungssitz 131 f., 134 Verwertungsketten 173, 194, 220 Verwertungsrechte 33, 35, 46, 54, 57, 60, 72, 99, 102, 104, 106, 108, 120, 166, 168 ff., 194, 208 Warenbegriff 136 ff. WCT 22 Werktitel 73 f. Wettbewerbsrecht 68 ff., 114 WIPO 22, 31, 33 WPPRT 22 Zuwendung 232 ff.