Abschlussarbeit im Ergänzungsstudiengang

Transcrição

Abschlussarbeit im
Ergänzungsstudiengang Rechtsinformatik
zum Thema
HAFTUNG FÜR
DER GNU GENERAL PUBLIC LICENSE
UNTERSTELLTE OPEN SOURCE SOFTWARE
EULISP VIII
Wintersemester 2003/2004
Betreuer: Dr. Benno Heussen
vorgelegt von:
Stephan Krämer
Matrikel-Nr.: 2213350
E-Mail: [email protected]
INHALTSÜBERSICHT
INHALTSÜBERSICHT................................................................................ I
LITERATURVERZEICHNIS .......................................................... IV - XIV
Haftung für der GNU General Public License
unterstellte Open Source Software ...................................................... 1
A.
Einleitung ............................................................................................ 1
I. Erfolgsgeschichte Open Source Software .................................. 1
II. Gang der Untersuchung ............................................................ 5
B. Das Open-Source-Modell ................................................................ 6
I. Begriff Open Source Software .................................................... 7
1. Entstehungsgeschichte ....................................................... 7
2. Die „Basar-Methode“......................................................... 10
3. „Free – as in free speech“ ................................................. 12
4. Freiheit per Definition ........................................................ 13
5. „OSS” vs. “Free Software”................................................. 14
6. Open-Source-Lizenzmodelle............................................. 16
II. GNU General Public License ................................................... 17
1. Rechte des Nutzers .......................................................... 18
2. Das Copyleft-Prinzip ......................................................... 19
3. Verletzungen der GPL ...................................................... 20
4. Rechtseinräumung durch den Urheber ............................. 20
5. Gewährleistungs- und Haftungsausschluss ...................... 21
C. Erscheinungsformen und Einsatzmodelle...............................22
I. Soziale und wirtschaftliche Bedeutung ..................................... 23
1. Entwicklergemeinschaft ....................................................... 23
2. Distributionen .................................................................... 24
3. Software-Vertrieb .............................................................. 26
4. Software-Entwicklung ....................................................... 27
5. Embedded-Bereich ........................................................... 28
II. Motive und Interessen der Personenkreise ............................. 28
1. Überwiegend nichtkommerzielle Motivation ......................... 28
2. Wirtschaftliche Interessen rund um OSS ............................. 30
D. Kompabilität mit deutschem Recht............................................31
I. Anwendbarkeit des deutschen Rechts...................................... 31
1. Kollisionsrecht................................................................... 32
2. Vertragsstatut und Territorialitätsprinzip ........................... 33
a. Art. 27 EGBGB .............................................................. 34
b. Art. 28 EGBGB .............................................................. 35
c. Art. 29 EGBGB .............................................................. 36
II. AGB-Kontrolle.......................................................................... 39
1. Allgemeine Geschäftsbedingungen .................................. 39
2. Einbeziehung bei Vertragsschluss .................................... 40
a. Verwender ........................................................................ 40
b. Zumutbare Kenntnisnahme .............................................. 40
II
3.
Einbeziehung bei Modifikation .......................................... 42
a. Englische Fassung ........................................................... 43
b. Unzulässige Tatsachenfiktion ........................................... 43
c. Ergebniskorrektur ............................................................. 44
II. Inhaltskontrolle.................................................................. 45
a. § 12 GPL, Haftungsausschluss ........................................ 46
b. § 11 GPL, Gewährleistungsausschluss ............................ 46
c. Salvatorische Klauseln ..................................................... 47
d. Rechtsfolgen..................................................................... 48
E. Gesetzliche Gewährleistung und Haftung................................48
I. Vertragsrechtliche Typisierung ................................................. 49
1. Veräußerungsvertragliche Konzepte.................................... 50
a. Schenkung........................................................................ 50
1.) Zuwendung .................................................................. 51
2.) Entreicherung .............................................................. 52
3.) Bereicherung ............................................................... 53
4.) Unentgeltlichkeit .......................................................... 53
5.) Schenkung mit Auflagen .............................................. 54
b. Gemischte Verträge.......................................................... 55
1.) Distributionen/Software-Vertrieb .................................. 55
2.) Zusätzliche Dienstleistungen ....................................... 57
3.) Embedded-Bereich ...................................................... 57
4.) Software-Entwicklung .................................................. 58
2. Gesellschaftsvertragliche Konzepte.................................. 59
3. Verträge sui generis .......................................................... 61
a. Lizenzvertrag .................................................................... 61
b. „Know-how“-Vertrag ......................................................... 63
4. Verzicht/Dereliktion ........................................................... 64
5. Eigene Bewertung und Zuordnung ................................... 66
a. Verträge sui generis/Urheberrechtsverzicht...................... 66
b. Veräußerungsverträge...................................................... 67
c. Gesellschaftsrechtliche Lösung ........................................ 68
II. Haftung entsprechend der vertraglichen Einordnung............... 69
1. Entwicklergemeinschaft ....................................................... 69
a. Gewährleistung................................................................. 70
1.) Sachmängel................................................................. 70
2.) Rechtsmängel.............................................................. 71
b. Verschuldensabhängige Haftung...................................... 72
c. Verschuldensunabhängige Haftung.................................. 73
1.) Produkt i.S.d. ProdHaftG ............................................. 73
2.) § 1 Abs. 2 Nr. 3 ProdHaftG .......................................... 75
3.) Fehler i.S.d. § 3 ProdHaftG.......................................... 76
4.) Haftung ........................................................................ 76
2. Distributionen und Software-Vertrieb ................................... 77
1.) Sachmängel................................................................. 78
2.) Rechtsmängel.............................................................. 79
3.) Zusätzliche Dienstleistungen.............................................81
III
F.
b. Verschuldensabhängige Haftung...................................... 81
1.) Vertragliche Haftung .................................................... 81
2.) Deliktische Haftung ...................................................... 82
c. Verschuldensunabhängige Haftung.................................. 83
d. Haftungsbeschränkungen................................................. 84
3. Embedded-Systems.......................................................... 85
a. Rechtsmängelhaftung....................................................... 86
b. Produkthaftung ................................................................. 87
4. Individuelle Softwareerstellung ......................................... 87
1.) Mitverarbeitung proprietären Codes ............................ 88
2.) Reichweite des „Copyleft“-Prinzips .............................. 89
3.) Dekompilierung § 69e UrhG ........................................ 91
b. Haftung ............................................................................. 91
III.
Rechtsverfolgung und Haftungsadressaten................... 92
Fazit ....................................................................................................94
G. Anhang:
Die GNU-General Public License und ihre dt. Übersetzung........97
GNU General Public License ....................................................... 97
Deutsche Übersetzung der GNU General Public License ............. 101
LITERATURVERZEICHNIS
Ahn, Hyo-Jil
Der urheberrechtliche Schutz von Computerprogrammen im Recht der Bundesrepublik Deutschland und der Republik Korea
Baden-Baden, 1999
(zit.: Ahn)
Backu, Frieder
„Open Source Software und Interoperabilität“
in ITRB 2003, S. 180 ff.
(zit.: Backu/ITRB 2003)
Bothe, Michael/Kilian, Wolfgang
Rechtsfragen grenzüberschreitender Datenflüsse
Köln, 1992
(zit.: Bothe/Kilian, Bearbeiter)
Deike, Thies
„Open Source Software: IPR-Fragen und Einordnung ins deutsche Rechtssystem“ in
CR 2003, S. 9 ff.
(zit.: Deike/CR 2003)
Feil, Thomas
„Open Source Software: Eine juristische Risikoanalyse“
Vortrag Managerakademie Ueberreuter, 1.07.2003
http://www.recht-freundlich.de/download/OSS_Rechtliche_Informationen.pdf
(zit.: Feil)
Fromm, Friedrich Karl/Nordemann, Wilhelm
Urheberrecht – Kommentar zum Urheberrechtsgesetz und zum Urheberrechtswahrnehmungsgesetz, 9. Auflage,
Stuttgart-Berlin-Köln, 1998
(zit.: F/N, Bearbeiter)
V
Goldmann, Bettina/Redecke, Rebecca
„Gewährleistung bei Softwareverträgen nach dem Schuldrechtsmodernisierungsgesetz“ in MMR 2002, S. 3 ff.
(zit.: Goldmann/Redecke, MMR 2002)
Grassmuck, Volker
Freie Software – Zwischen Privat- und Gemeineigentum
Bonn, 2002
(zit.: Grassmuck)
Grzeszick, Bernd
„Freie Software: Eine Widerlegung der Urheberrechtstheorie?“
in MMR 2000, S. 412 ff.
(zit.: Grzeszick/MMR 2000)
Günther, Andreas
Produkthaftung für Informationsgüter
Köln, 2001
(zit.: Günther)
Hilty, Reto M.
„Der Softwarevertrag – ein Blick in die Zukunft – Konsequenzen der trägerlosen Nutzung und des patentrechtlichen Schutzes von Software“
in MMR 2003, S. 3 ff.
(zit.: Hilty/MMR 2003)
Hoeren, Thomas/Sieber, Ulrich
Handbuch Multimedia-Recht – Rechtsfragen des elektronischen Geschäftsverkehrs
Stand November 2002
München, 2003
(zit.: Hoeren/Sieber, Bearbeiter)
Jaeger, Till
„Vererbungsleere“ in Linux-Magazin 1/2002, S. 85
(zit.: Jaeger/Linux-Mag. 2002)
Jaeger, Till
„GPL und Haftung – Ohne Verantwortung?“ in Linux-Magazin 05/2000
http://www.linuxmagazin.de/Artikel/ausgabe/2000/05/Haftungsrecht/haftungsrecht.html
(zit.: Jaeger/Linux-Mag. 2000)
VI
Jaeger, Till
„No license to bill“ in Computerwoche Spezial 2/2001, S. 46
http://www.ifross.de/ifross_html/art19.html
(zit.: Jaeger/Computerwoche)
Jaeger, Till/ Metzger, Axel
Open Source Software – Rechtliche Rahmenbedingungen der freien Software
München, 2002
(zit.: Jaeger/Metzger, OSS)
Jaeger, Till/ Metzger, Axel
„Open Source Software und deutsches Urheberrecht“
in GRUR Int. 1999, S. 839 ff.
(zit.: Jaeger/Metzger, GRUR Int. 1999)
Jakob, Georg
„Freiheit und Software“ in Schweighofer/Menzel/Kreuzbauer (Hrsg.) „Aktuelle Fragestellungen der Rechtsinformatik 2001 - Auf dem Weg zur ePerson“
Wien, 2001, S.69 ff.
(zit.: Jakob)
Juncker, Abbo/Benecke Martina
Computerrecht, 3. Auflage
Baden-Baden, 2003
(zit.: Juncker/Benecke)
Jürgens, Uwe
„Datenschützer beziehen Position zu Open Source“ in DSB 2000, S. 6f.
(zit.: Jürgens/DSB 2000)
Kaminski, Bert/Henßler, Thomas/Kolaschnik, Helge/Papathoma-Baetge,
Anastasia
Rechtshandbuch des E-Business
Neuwied-Kriftel, 2001
(zit.: Kaminski/Henßler et al., Bearbeiter)
Kilian, Wolfgang/Heussen, Benno
Computerrechtshandbuch,
Stand: 15. Januar 2003, 20. Ergänzungslieferung
(zit.: Kilian/Heussen, Bearbeiter)
VII
Kloepfer, Michael
Informationsrecht,
München 2002
(zit.: Kloepfer)
Koch, Frank A.
Urheber- und kartellrechtliche Aspekte der Nutzung von Open-Source-Software (I/II)
in CR 2000, S. 273 ff., 333 ff.
(zit.: Koch/CR 2000)
Köhntopp, Kristian/Köhntopp, Marit/Pfitzmann, Andreas
„Sicherheit durch Open Source? – Chancen und Grenzen“
in DuD 2000, S. 508 ff.
(zit.: Köhntopp/Köhntopp/Pfitzmann, DuD 2000)
Kropholler, Jan
Internationales Privatrecht einschließlich der Grundbegriffe des internationalen Zivilverfahrensrechts, 4. Auflage, Hamburg, 2001
(zit.: Kropholler)
Lejeune, Mathias
„Rechtsprobleme bei der Lizenzierung von Open Source Software nach der GNU
GPL“ in ITRB 2003, S. 10 ff.
(zit.: Lejeune/ITRB 2003)
Mankowski, Peter
„E-Commerce und Internationales Verbraucherrecht“
in MMR-Beilage 7/2000, S. 22 ff.
(zit.: Mankowski/MMR-Beilage)
Marly, Jochen
Softwareüberlassungsverträge
3. Auflage
München, 2000
(zit.: Marly)
Medicus, Dieter
Bürgerliches Recht, 19. Auflage,
Köln-Berlin-Bonn-München, 2002
(zit.: Medicus)
VIII
Meretz, Stefan
„Freie Software – 20 Thesen für eine andere Gesellschaft“
in SPW (Zeitschrift für Sozialistische Politik und Wirtschaft, 2001, S. 32 ff.
(zit.: Meretz/SPW)
Mestmäcker, Ernst-Joachim/Schulze, Erich
Kommentar zum deutschen Urheberrecht, Band 1,
Loseblattkommentar, München, Stand: Juni 2003, 34. Ergänzungslieferung
(zit.: M/S, Bearbeiter)
Metzger, Axel
„Zur Zulässigkeit von CPU-Klauseln in Softwarelizenzverträgen“
in NJW 2003, S.1994f.
(zit.: Metzger/NJW 2003)
Metzger, Axel
„Haftung ausgeschlossen?“ in Linux-Magazin 05/2002
http://www.linux-magazin.de/Artikel/ausgabe/2002/05/recht/recht.html.
(zit.: Metzger/Linux-Mag. 2002)
Moglen, Eben
“Free Software Matters: Enforcing the GPL, I”, 12.08.2001
http://moglen.law.columbia.edu/publications/lu-12.pdf
(zit.: Moglen)
Morner, Michèle
„Das Open-Source-Software-Phänomen – Betrachtungen aus organisationstheoretischer Perspektive“, Diskussionsbeitrag zum Forschungsseminar der Wirtschaftswissenschaftlichen Fakultät der Katholischen Universität Eichstätt, 21.03.2001
http://www.kueichstaett.de/Fakultäten/WWWF/Lehrstuehle/OP/Downloads/Papers/Sections/content
/mim_opensource.pdf
(zit.: Morner)
O’Reilly, Tim
„Schlüsse aus der Open-Source-Software-Entwicklung“
13.07.1999, Aufsatz bei Heise Online
http://www.heise.de/tp/deutsch/special/wos/6433/1.html,
(zit.: O’Reilly)
IX
Omsels, Hermann-Josef
„Open Source und das deutsche Vertrags- und Urheberrecht“
in Christian Schertz/Hermann-Josef Omsels (Hrsg.)
Festschrift für Paul W. Hertin zum 60. Geburtstag, S. 141 ff.
München, 2000
(zit.: Omsels/FS Hertin)
Palandt, Otto
Bürgerliches Gesetzbuch - Kommentar, 63. Auflage,
München, 2004
(zit.: Palandt/Bearbeiter)
Plaß, Gundula
“Open Contents im deutschen Urheberrecht” in GRUR 2002, S. 670 ff.
(zit.: Plaß/GRUR 2002)
Rauscher, Thomas
Internationales Privatrecht mit internationalem Verfahrensrecht,
2. Auflage
Heidelberg, 2003
(zit.: Rauscher)
Raymond, Eric Steven
The Cathedral and the Bazaar - Musings on Linux and Open Source by an Accidental
Revolutionary, Sebastopol, 2001
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
(zit.: Raymond)
Redecker, Helmut
„Wer ist Eigentümer von Goethes Werther?“
in NJW 1992, S. 1739f.
(zit.: Redecker, NJW 1992)
Rehbinder, Manfred
Urheberrecht, 11. Auflage,
München, 2001
(zit.: Rehbinder)
Sandl, Ulrich
„Open Source Software: Politsche, ökonomische und rechtliche Aspekte“
in CR 2001, S. 346 ff.
(zit.: Sandl/CR 2001)
X
Schanze, Erich
„Legalism, Economism, and Professional Attitudes Toward Institutional Design“
in JITE (Journal of Institutional and Theoretical Economics),
Nr. 149 (1993), S. 122 ff.
(zit.: Schanze/JITE 1993)
Scherer, Josef/Butt, Marc Eric
„Rechtsprobleme bei Vertragsschluss via Internet“
in DB 2000, S.1009 ff.
(zit.: Scherer/Butt)
Schiffner, Thomas
Open Source Software – Freie Software im deutschen Urheber- und Vertragsrecht,
München, 2002
(zit.: Schiffner)
Schneider, Jochen
Handbuch des EDV-Rechts
3. Auflage,
Köln, 2003
(zit.: Schneider)
Schneider, Jochen/Günther, Andreas
„Haftung für Computerviren“
in CR 1997, S. 389 ff.
(zit.: Schneider/Günther, CR 1997)
Schneidewind, Uwe/Landsberger, Matthias/ Eggers, Hendrik
„Mythos Linux? Zur Übertragbarkeit der Koordinations- und Anreizmechanismen der
Linux-Entwicklung auf Unternehmen“ in ZFO (Zeitschrift für Führung und Organisation), 2002, S. 226 ff.
(zit.: Schneidewind/Landsberger/Eggers, ZFO 2002)
Schricker, Gerhard
Urheberrecht - Kommentar, 2. Auflage,
München, 1999
(zit.: Schricker/Bearbeiter)
Schulz, Carsten
„Die scharfe Klinge des Gesetzes“
in Linux-Magazin 2003, S. 68 ff.
(zit.: Schulz/Linux-Magazin)
XI
Schulz, Carsten
„Freie Software, Big Business?“ in CR 2003, S. 80
(zit.: Schulz/CR 2003)
Schumann, Sven
„LINUX – Ein Überblick über ein alternatives Betriebssystem“
in DSB 2002, S. 7
(zit.: Schumann/DSB)
Schwarz, Mathias/Peschel-Mehner, Andreas
Recht im Internet
Augsburg, 2002
Loseblattsammlung,
Stand: März 2003, 2. Ergänzungslieferung
(zit.: Schwarz/ Peschel-Mehner, Bearbeiter)
Sester, Peter
„Open-Source-Software: Vertragsrecht, Haftungsrisiken und IPR-Fragen“
in CR 2000, S. 797 ff.
(zit.: Sester/CR 2000)
Siepmann, Jürgen
Freie Software – rechtsfreier Raum? Rechtssicherheit im Umgang mit Open Source
Software
München, 2000
(zit.: Siepmann/Freie SW)
Siepmann, Jürgen
„Lizenz- und haftungsrechtliche Fragen bei der kommerziellen Nutzung Freier
Software“, JurPC Web-Dok. 163/1999
http://www.jurpc.de/aufsatz/19990163.htm
(zit.: Siepmann/Jur-PC 1999)
Speichert, Horst
„Haftungsrisiko Open Source Software? Eine Erörterung der rechtlichen Fragen zu
OSS“, Gastbeitrag bei Medienkultur-Stuttgart, http://www.medienkulturstuttgart.de/source/frameset.htm?../thema02/2archiv/news6/mks6OSS.htm
(zit.: Speichert)
XII
Spindler, Gerald
Verschuldensabhängige Produkthaftung im Internet
in MMR 1998, S. 23 – 29
Verschuldensunabhängige Produkthaftung im Internet
in MMR 1998, S. 119 ff.
(zit.: Spindler, MMR 1998)
Spindler, Gerald
Studie zu Rechtsfragen der Open Source Software, erstattet im Auftrag des Verbandes der Softwareindustrie Deutschlands e.V. (VSI), Juni 2003
http://www.vsi.de/inhalte/information/presse/presse_34.htm
(zit.: Spindler/VSI)
Spindler, Gerald
Verschuldensabhängige Produkthaftung im Internet
in MMR 1998, S. 23 ff.
Verschuldensunabhängige Produkthaftung im Internet
in MMR 1998, S. 119 ff.
(zit.: Spindler, MMR 1998)
Spindler, Gerald/Wiebe, Andreas
“Open Source Vertrieb – Rechteeinräumung und Nutzungsberechtigung”
in CR 2003, S.873 ff.
(zit.: Spindler/Wiebe, CR 2003)
Stallman, Richard
„The GNU Operating System and the Free Software Movement“
in Chris DiBona/Sam Ockman/Mark Stone (Hrsg.), Open Sources – Voices from the
Open Source Revolution, Sebastopol, 1999
http://www.openresources.com/documents/open-sources/
(zit.: Stallman/Open Sources)
Stichtenoth, Jonas
„Softwareüberlassungsverträge nach dem Schuldrechtsmodernisierungsgesetz“ in K
& R 2003, S. 105 ff.
(zit.: Stichtenoth/K & R 2003)
Stickelbrock, Barbara
„Linux & Co – Gewährleistung und Haftung bei kommerziell vertriebener Open Source
Software“ in ZGS 2003, S. 368 ff.
(zit.: Stickelbrock/ZGS 2003)
XIII
Taeger, Jürgen
Außervertragliche Haftung für fehlerhafte Computerprogramme
Tübingen, 1995
(zit.: Taeger)
Ullrich, Hanns/Körner, Eberhart
Der Internationale Softwarevertrag,
Heidelberg 1995
(zit.: Ullrich/Körner, Bearbeiter)
Ulmer, Eugen
Urheber- und Verlagsrecht, 3. Auflage,
Berlin 1980
(zit.: Ulmer)
Ulmer, Peter/Brandner, Hans Erich/Hensen, Horst-Diether/Schmidt, Harry
AGB Gesetz - Kommentar zum Gesetz zur Regelung des Rechts der Allgemeinen
Geschäftsbedingungen mit Nachtrag zur Schuldrechtsreform, 9. Auflage,
Köln, 2001
(zit.: Ulmer/Brandner/Hensen/Schmidt)
Valloppillil, Vinod
„Open Source Software – A (New?) Development Methodology (Halloween I)”
Studie vom 11.08.1998
http://www.freesoft.org/mirrors/www.opensource.org/halloween/halloween1.html#comment28
(zit.: Valloppillil)
Wayner, Peter
Kostenlos und überlegen! - Wie Linux und andere freie Software Microsoft das Fürchten lehren
Stuttgart - München, 2001
(zit.: Wayner)
Weber, Rolf H.
„Freie Software – Befreiung vom Vertragstypenkonzept?“
in Friedrich Harrer/Wolfgang Portmann/Roger Zäch (Hrsg.): „Besonderes Vertragsrecht – aktuelle Probleme“,
Festschrift für Heinrich Honsell zum 60. Geburtstag, S. 41 ff.
(zit.: Weber/FS Honsell)
XIV
Westphalen, Friedrich Graf von
Produkthaftungshandbuch,
Band 2: Das deutsche Produkthaftungsgesetz, Internationales Privatrecht und Prozeßrecht, 2. Auflage, München, 1999
(zit.: v.Westphalen/Bearbeiter)
Wiebe, Andreas/Heidinger, Roman
„Open Source Software – eine erfolgreiche Alternative“
online abrufbar unter: http://recht.wuwien.ac.at/INSTITUT/PR/informationsrecht/OpenSource/OSS_Langtext.pdf
(zit.: Wiebe/Heidinger)
Winzerling, Werner
„Linux und Freie Software – Eine Entmystifizierung“
in PROKLA, Zeitschrift für kritische Sozialwissenschaft, 2002, S. 37 ff.
(zit.: Winzerling/PROKLA)
Witzel, Michaela
“AGB-Recht und Open Source Lizenzmodelle”
in ITRB 2003, S.175 ff.
(zit.: Witzel/ITRB)
Wuermeling, Ulrich/Deike, Thies
„Open Source Software: Eine juristische Risikoanalyse“
in CR 2003, S. 87 ff.
(zit.: Wuermeling/Deike, CR 2003)
1
HAFTUNG FÜR
DER GNU GENERAL PUBLIC LICENSE
UNTERSTELLTE OPEN SOURCE SOFTWARE
A. Einleitung
I. Erfolgsgeschichte Open Source Software
Open Source Software (OSS) oder auch „freie Software“ ist in aller
Munde. Als der Rat der Stadt München im Mai 2003 in einer weltweit
beachteten Entscheidung beschloss, die 14.000 PC der Kommunalverwaltung mit dem quelloffenen Betriebssystem GNU/Linux und
dem Anwendungspaket OpenOffice anstelle von entsprechenden
Microsoft Produkten auszustatten, erreichte die öffentliche Aufmerksamkeit einen neuen Höhepunkt1. Der Beschluss, dem erhebliche
Signalwirkung für die Zukunft beigemessen wird2, wurde getroffen,
obwohl Microsoft-Chef Steve Ballmer eigens seinen Skiurlaub unterbrochen hatte, um den Münchnern durch großzügige Rabattangebote die weitere Zusammenarbeit schmackhaft zu machen. Er fußt auf
einem zwischen dem Bundesinnenministerium und IBM im Juni 2002
geschlossenen Rahmenvertrag, der der öffentlichen Verwaltung
Sonderkonditionen beim Erwerb von auf offenen Standards basierender Hard- und Software einräumt3. Neben der Stadt München haben infolgedessen bis heute über 400 weitere Behörden auf freie
Software umgesattelt4. Auch zuvor schon waren von öffentlicher Sei1
Vgl. Spiegel-Online vom 28.05.2003,
http://www.spiegel.de/netzwelt/politik/0,1518,250721,00.html. Alle zitierten Links
wurden am 1. Januar 2004 abgerufen und erwiesen sich dabei als funktionierend,
weshalb im Folgenden auf die Angabe des Abrufsdatums verzichtet wird.
2
Vgl. Handelblatt Nr. 103 vom 30.05.03, Seite 14, „Microsoft verliert prestigeträchtigen Kampf um München“.
3
Vgl. Pressemitteilung vom 2.06.2002 unter
http://www.bmi.bund.de/dokumente/Pressemitteilung/ix_82618.htm.
4
Vgl. Die Zeit Nr.44 vom 23.10.2003, „Programmierer aller Länder vereinigt
Euch!“, http://www.zeit.de/2003/44/Open_Source.
2
te bemerkenswerte Initiativen auf nationaler5 und europäischer6
Ebene ins Leben gerufen worden, um deren Einsatz zu fördern7. Insbesondere nutzen im deutschen Bundestag Verwaltung und Server
schon seit März 2002 Open Source Software8.
Auch im Bereich der Wirtschaft konnte freie Software durch ihr Einsparungspotenzial gerade in Zeiten knapper Kassen als Alternative
zu den teureren Produkten der etablierten Software-Industrie auf sich
aufmerksam machen9. So setzen namhafte Unternehmen wie Edeka,
Sixt, Debis oder Ikea bereits seit geraumer Zeit auf GNU/Linux10.
Nicht zuletzt dringt dieses Betriebssystem und andere Open-SourceProgramme auch immer weiter in den Bereich der privaten Heim-PC
vor, da sog. Distributoren (wie SuSE oder RedHat) GNU/LinuxKomplettpakete inklusive zusätzlicher Programme, Handbuch und
Support anbieten und auf diese Weise eine höhere Benutzerfreundlichkeit des Produkts schaffen11.
Nach alldem überrascht es kaum, dass gewisse Open-SourceProdukte heute beträchtliche Marktanteile auf sich vereinen. Paradebeispiel hierfür ist vor allem wiederum GNU/Linux, welches im Jahr
2002 bei den PC- und Serverbetriebssystemen einen Anteil von ca.
25 Prozent erobern konnte und damit die schnellste Wachstumsrate
in diesem Segment aufweist12. Weitere erfolgreiche Beispiele sind
5
So der vom Bundesministerium für Wirtschaft und Technologie (BMWi) geförderte
Aufbau eines nationalen Kompetenzzentrums „BerliOS“, vgl. CR 2001, S.143.
6
So das von EU-Kommissar Liikanen angeregte Projekt POOS (Pooling Open
Source Software), vgl. http://europa.eu.int/ISPO/ida/export/files/de/1320.pdf; s.a.
ITRB 2002, S. 198. Mittlerweile fördert die EU 20 Open Source Projekte direkt, vgl.
Computerwoche Online am 23.12.2003:
http://www.computerwoche.de/index.cfm?pageid=254&artid=56493. Erst gerade
hat die EU eine aktuelle Informationsseite über OSS und freie Software auf ihren
Servern bereitgestellt:
http://europa.eu.int/information_society/activities/opensource/text_en.htm.
7
Vgl. CR 2001, S.283.
8
Vgl. http://www.bundestux.de.
9
Vgl. Handelsblatt Nr.46 vom 6.03.2002, „Leo liebt Linux – Das Betriebssystem mit
dem Pinguin-Logo erobert langsam aber sicher Unternehmens-Netze von Hannover bis Hollywood“, S.9; Schulz/CR 2003, S.80; Schumann/DSB, S.7.
10
Vgl. VDI-Nachrichten 42/98 http://www.suse.de/presse/archiv/vdi42.html.
11
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.840; Stickelbrock/ZGS 2003, S.369.
12
Vgl. Schumann/DSB, S.7; Speichert, Einleitung.
3
die Datenbank MySQL13 sowie Skriptsprachen wie Perl und PHP
oder der Webserver Apache14, der - ähnlich wie die Applikationen
SendMail15 und BIND16 - weltweit sogar mit ca. zwei Dritteln Anteil
Marktführer seines Marktbereichs ist17.
Angesichts dieser Zahlen betrachtet die etablierte Industrie das OSSPhänomen durchaus mit zunehmendem Argwohn: Microsoft hat das
freie Betriebssystem GNU/Linux als „Konkurrenten Nummer eins“
ausgemacht18 und erst unlängst betitelte Steve Ballmer Open Source
Software als ein „Krebsgeschwür“ und auch Jim Allchin, immerhin
Vizepräsident von Microsofts Plattformabteilung, titulierte sie als
„Zerstörer geistigen Eigentums“19. Bereits im Jahre 1999 bezeichnete
ein Jurist des Unternehmens freie Software als „das nächste große
Ding der Computerindustrie“20.
Andere Branchen-Größen wie IBM, Hewlett-Packard, Compaq und
Sun investieren ohnehin schon seit einiger Zeit dreistellige Millionensummen in Open-Source-Projekte21, um durch das Setzen offener
Standards die Marktkontrolle Microsofts aufzubrechen und so einen
größeren Wettbewerb auf dem Softwaremarkt zu ermöglichen22.
13
Vgl. FAZ vom 13.08.2003,„Ein Juraprofessor schreckt die Linux-Welt auf“,
http://www.faz.net/s/RubEC1ACFE1EE274C81BCD3621EF555C83C/Doc~EBE25
7B98B3E04068BBA249C6F4790C84~ATpl~Ecommon~Scontent.html.
14
Vgl. zum aktuellen Marktanteil von Apache:
http://news.netcraft.com/archives/web_server_survey.html.
15
Sendmail ist ein Programm, welches die Zustellung und Weiterleitung von Emails steuert, vgl. O’Reilly, 3. Abschnitt, Innovation und Evolution.
16
BIND bezeichnet die Berkeley Internet Name Domain Server, auf denen das
Domain Name System basiert. Die Software wandelt die vom Nutzer eingegebene
URL in die IP-Adresse um, die benötigt wird um den angesprochenen Computer im
WWW zu lokalisieren, vgl. O’Reilly, 2. Abschnitt, Software: Produkt oder Dienstleistung.
17
Vgl. Schulz/Linux-Magazin, S.68; O’Reilly, aaO; Weber/FS Honsell, S.46.
18
Vgl. Handelsblatt Nr. 208 vom 29.10.2002, „Deutschland, einig Linux-Land“,
S.13.
19
Vgl. Jaeger/Computerwoche, S.46; siehe auch “Microsoft schießt gegen Open
Source”, Heise Newsticker vom 16.02.2001:
http://www.heise.de/newsticker/data/odi-16.02.01-000/.
20
Vgl. Florian Rötzer, http://www.heise.de/tp/deutsch/special/wos/6446/1.html.
21
Vgl. Sandl/CR 2001, S.351, dort FN 48; Die Zeit, „Programmierer aller Länder
vereinigt Euch!“ aaO; Handelsblatt, „Deutschland, einig Linux-Land“ aaO.
22
Vgl. Sandl/CR 2001, S.349f.; Sester/CR 2000, S.799; Jakob, S.81, Koch/CR
2000, S. 281.
4
Neben diesem Motiv und den bereits erwähnten erhofften wirtschaftlichen Vorteilen sind die Gründe der großen Beliebtheit von Open
Source Software vielseitig. So gilt sie wegen ihrer Transparenz als
sicherer23 und zugleich als schneller, stabiler und zuverlässiger als
ihre kommerzielle Konkurrenz24. Zudem verspricht der Einsatz freier
Software mehr Unabhängigkeit, da Support und Wartung auch durch
Dritte oder selbst vorgenommen werden können25. Nicht zuletzt
scheint die Open Source Software-Entwicklung besondere Chancen
für die europäische Softwarewirtschaft26 zu bieten und gerade auch
in Deutschland einen besonderen Entwicklungsstandort gefunden zu
haben27.
Diesen Vorteilen gegenüber werden von verschiedenen Autoren Bedenken bezüglich juristischer Risiken geäußert, die vor allem Probleme mit dem hiesigen Urheber- und Haftungsrecht skizzieren. Es
heißt insbesondere, dass die für das amerikanische CopyrightSystem entwickelten Open-Source-Lizenzen bei ihrer Implementierung in die deutsche Rechtsordnung zu erheblichen Rechtsunsicherheiten führten28. Tatsächlich existiert trotz der weiten Verbreitung von
Open-Source-Produkten bis heute kaum Rechtsprechung zu diesen
Fragen29.
Zuletzt wurden die Befürworter der Open-Source-Idee durch den
Verband deutscher Software Industrie (VSI) aufgeschreckt, der medienwirksam30 eine Studie des Göttinger Rechtsprofessors Gerald
23
Vgl. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.511; Grzeszick/MMR 2000,
S.415; Dies ist ein Aspekt der insbes. auch vom Bundesinnenministerium betont
wird, vgl. Pressemitteilung vom 2.06.2002, aaO.
24
Vgl. Sandl/CR 2001, S.346; Jaeger/Metzger, GRUR Int. 1999, S.840; Omsels/FS
Hertin, S.144; Speichert, 1.Abschnitt „Was ist Open Source Software?“.
25
Vgl. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.512.
26
Vgl. CR 2001, S.283, „Freie und Open-Source-Software in der Verwaltung“.
27
Vgl. Handelsblatt, „Deutschland, einig Linux-Land“ aaO.
28
Vgl. Stickelbrock/ZGS 2003, S. 372; Lejeune/ITRB 2003, S.12; Wuermeling/Deike, CR 2003, S.87; Sester/CR 2000, S.806.
29
Vgl. Wuermeling/Deike, CR 2003, S.87; Stickelbrock/ZGS 2003, S. 372; Jakob,
S.81.
30
Vgl. die Reaktionen der Presse:
FAZ vom 13.08.2003, „Ein Juraprofessor schreckt die Linux-Welt auf“, aaO; Financial Times Deutschland vom 2.07.2003, „Rechtsunsicherheit bedroht Erfolg von
5
Spindler präsentierte, welches diese Rechtsunsicherheiten und daraus folgende unabsehbare Haftungsrisiken angeblich belege31.
II. Gang der Untersuchung
Das Ziel dieser Arbeit soll es sein, die Haftungsvoraussetzungen im
Umfeld von Open Source Software unter der GNU General Public
License zu untersuchen und darzustellen. Der Begriff der Haftung
soll hierbei in umfassender Bedeutung nach deutschem Zivilrecht zu
verstehen sein und insbesondere auch die Gewährleistung und vertragliche Haftung umfassen, um ein vollständiges und praktisch
brauchbares Bild abzugeben.
Zunächst wird es daher nötig sein, das Open-Source-Modell zu erläutern sowie einen Überblick über die Entstehung und Entwicklung
von Open Source Software in technischer und gesellschaftlicher Hinsicht zu geben. Hierbei sollen die in der Praxis bedeutsamen Fallkonstellationen aufgezeigt werden, anhand derer die Darstellung erfolgen soll. Im weiteren Fortgang der Untersuchung wird dann die
Kompabilität des GNU-Open-Source-Modells mit deutschem Rechts
überprüft, um schließlich den gegenwärtigen Diskussionsstand in der
Literatur aufzugreifen und die Haftung innerhalb der bezeichneten
Fallstricke zu bewerten.
Aufgrund der Tatsache, dass gerichtliche Entscheidungen zur rechtlichen Behandlung von Open Source Software nicht vorliegen, können konkrete Beispielsfälle aus der Praxis leider nicht einbezogen
werden. Die Untersuchung muss sich daher in erster Linie an theoretischen Überlegungen sowie an allgemeinen Wertungen des Softwarerechts orientieren und diese auf die praktischen Anwendungsfäl-
Linux“, http://www.ftd.de/tm/it/1056704881575.html?nv=cpm; Artikel bei zdnet.de
vom 25.07.2003 „Hat Open-Source ein ernstes Problem?“,
http://www.zdnet.de/itmanager/kommentare/0,39023450,2138161,00.htm; NZZ
vom 23.11.2003, „Ohne Copyright kein Copyleft“,
http://www.nzz.ch/2003/09/23/ob/page-article93CDI.html.
31
Vgl. Pressemitteilung des VSI vom 1.07.2003 unter
http://www.vsi.de/inhalte/information/presse/presse_34.htm, zugleich mit Downloadmöglichkeit der angesprochenen Studie.
6
le von Open Source Software unter der GNU General Public License
übertragen.
B. Das Open-Source-Modell
Zunächst ist daher festzustellen, worin die Besonderheit des Modells
der Open Source Software liegt. Worin unterscheidet sich Open
Source Software also von herkömmlicher, oftmals als „proprietär“32
bezeichneter Software?
Während die Letztere dem User üblicherweise nur im maschinenlesbaren Binärcode (Objectcode) zur Verfügung steht, ist für den Nutzer
von Open Source Software der sog. Quellcode (Sourcecode) beigefügt und voll einsehbar33.
Dieser enthält den technischen Konstruktionsplan der Software und
gibt Aufschluss über ihre Funktionsweise und das in ihr verarbeitete
„Know-how“ der Entwickler. Er ist für den Programmierer der
„Schlüssel zum Verständnis“ und ermöglicht es ihm, die Software zu
analysieren und zu modifizieren34. Auf einer späteren Entwicklungsstufe wird der Quellcode dann mittels Interpreter- oder Compilersoftware in den Binärcode umgewandelt, der die Anweisungen an den
Rechner enthält und das Programm damit ausführbar macht35.
Somit ist es gerade der Quellcode der ein Computerprogramm in
wirtschaftlicher Hinsicht wertvoll macht. Aus diesem Grund sind die
Hersteller kommerzieller Software darauf bedacht, diesen „Bauplan“
wie ein Betriebsgeheimnis zu schützen, um der Nachahmung durch
32
Bei genauerem Hinsehen ist dieser Begriff – eine Anspielung auf die vom „geistigen Eigentum“ gewährten Ausschließlichkeitsrechte - nicht geeignet, die hier angesprochene Software kommerzieller Hersteller von Open Source Software zu
differenzieren, da aber auch Letztere, wie noch zu zeigen sein wird, nicht auf die
ihr immanenten Urheberrechte verzichtet, sondern diese lediglich anders einsetzt –
nämlich um die Freiheiten die das Open Source Modell den Nutzern bietet, zu sichern (siehe dazu unten E. I. 4.Verzicht/Dereliktion). Open Source Software ist
daher strenggenommen ebenfalls proprietär. Diese Bezeichnung hat sich jedoch in
der Praxis mangels einer gebräuchlichen Alternative zur Abgrenzung beider Modelle durchgesetzt und soll daher auch im Folgenden gebraucht werden; vgl. auch
Jaeger/Metzger, OSS, S.3.
33
Vgl. zu den Begriffen Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.508
34
Vgl. Backu/ITRB 2003, S.180; Lejeune/ITRB 2003, S.10; Deike/CR 2003, S.9
35
Vgl. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.508; Sandl/CR 2001, S.346
7
andere vorzubeugen und ihr Produkt wirtschaftlich möglichst exklusiv
verwerten zu können. So wird einerseits die Möglichkeit abgesichert,
den Kunden hinsichtlich von Support-Dienstleistungen an sich zu
binden, und andererseits die Weiterentwicklung des Produkts den
eigenen Programmierern vorzubehalten36. Dies geschieht technisch
durch Geheimhaltung des Sourcecodes und in Ergänzung rechtlich
durch das an ihm bestehende Urheberrecht und das Wettbewerbsrecht37.
I. Begriff Open Source Software
Namensgebend für den Begriff der Open Source Software war daher
das Grundprinzip der Quelloffenheit. Nicht weniger wichtig ist jedoch
die dahinterstehende Überlegung, dem Nutzer hierdurch mehr Freiheiten im Umgang mit der Software zu gewähren.
1. Entstehungsgeschichte
Diese Überlegung ergab sich ursprünglich aus einer Idee Richard
Stallmans, dem „Vater“ der Free-Software-Bewegung38, aus Frustration über die zunehmende Proprietarisierung von Computerprogrammen.
In den 1960er und 70er Jahren gab es für Software keinen eigenen
Markt, sie wurde vielmehr als kostenlose Beigabe zur Hardware verstanden. Dass ihr Quellcode offen lag, galt damals als Selbstverständlichkeit39. So hatte jeder Sachverständige die Möglichkeit, die
Programme seinen Bedürfnissen entsprechend anzupassen. Die
36
Vgl. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.509; Grzeszick/MMR 2000,
S.413; Wayner, S.127.
37
Vgl. Grzeszick/MMR 2000, S.413; Backu/ITRB 2003, S.180; Marly, Rn. 78;
Kloepfer, § 6, Rn.72.
Der urheberrechtliche Schutz besteht in Deutschland gem. §§ 2 Abs. 1 Nr.1, 69a ff.
UrhG, in wettbewerbsrechtlicher Hinsicht ist vor allem die Vorschrift des § 1 UWG
von Bedeutung, die beispielweise dann einschlägig ist, wenn das Computerprogramm eines Wettbewerbers durch einfaches Kopieren vervielfältigt und in den
Verkehr gebracht wird. Dieses Verhalten ist deshalb wettbewerbswidrig, weil der
Konkurrent ohne nennenswerten Aufwand um den Ertrag seiner Investitionen gebracht werden könnte, vgl. zu Einzelheiten Schiffner, S.55.
38
Vgl. Jaeger/Metzger, OSS, S.11; siehe hierzu auch die Website Richard Stallmans: http://www.stallman.org.
39
Vgl. Jaeger/Metzger, OSS, S.8; Jakob, S.69
8
größte Verbreitung erfuhr zu dieser Zeit das ursprünglich von Ken
Thompson und Dennis Ritchie für ihren Arbeitgeber, den USTelekommunikationsriesen AT & T, entwickelte UNIX. Dieses Betriebssystem war aufgrund seiner technischen Eigenschaften sehr
beliebt und wurde in den 70er Jahren von den Universitäten durch
sog. „Hacker“ gepflegt und weiterentwickelt. Dieser Begriff war damals keineswegs mit der Bedeutung „Softwarepirat“ oder „Computereinbrecher“ besetzt, wie er heute meistens verstanden wird. Vielmehr sahen „Hacker“ sich als leidenschaftliche Programmierer an,
die gemeinsam eine Weiterentwicklung ihrer Programme anstrebten40. Hierbei war ein freier Informations- und Programmaustausch
und gegenseitige Inspiration zwischen diesen Experten gang und
gäbe und ihrer Ansicht nach eine der wichtigsten Grundvoraussetzungen ihrer Arbeit.
Einer der ersten, die demgegenüber das wirtschaftliche Potenzial
eines zusätzlichen Software-Markts erkannten, war William Henry
Gates III, der erstmals im Jahre 1976 die gängige Praxis der Programmweitergabe und der freien Bearbeitung als Diebstahl anprangerte41. Zu Beginn der 80er Jahre fand seine Idee immer mehr Anhänger in der Computerindustrie und ein eigenständiger Markt für
Software entstand42. Der Quellcode wurde von nun an zunehmend
geheim gehalten und nach der Zerschlagung von AT & T im Jahre
1984 passierte dies ebenfalls mit den verschiedenen UNIXDerivaten, die sich bis zu dieser Zeit aus der ursprünglichen Version
entwickelt hatten – sie wurden in den Händen derer, die sie zuletzt
noch offen genutzt und verbessert hatten, zu Betriebsgeheimnissen43. So kam es, dass UNIX sich zu einer ganzen Betriebssystemfamilie entwickelte, deren zahlreiche Mitglieder zunehmend inkompa-
40
Vgl. Grassmuck, S.218; Raymond, S.19; Jaeger/Metzger, OSS, S.10, sowie zur
Geschichte von UNIX: Grassmuck, S.211ff.
41
Vgl. ders., „An Open Letter to Hobbyists“, zu finden unter:
http://www.blinkenlights.com/classiccmp/gateswhine.html.
42
Vgl. Grassmuck, S.221f.
43
Vgl. Winzerling/PROKLA, S.37.
9
tibel zueinander wurden44. Dies war schließlich die Stunde von Bill
Gates und Microsoft, die es schafften, ihr DOS-System zum internationalen Standard für Betriebssysteme zu erheben und ihre bis heute
dominante Rolle in der Softwareindustrie einzunehmen45.
Ganz besonders bedrückt durch diese Entwicklung war der o.g.
Richard Matthew Stallman, einer der „Hacker“ der ersten Stunde.
Erzürnt über die nunmehr fehlende Möglichkeit, jegliche Software frei
bearbeiten zu können und die entstandenen Inkompabilitäten selbst
zu beseitigen, fasste er den Entschluss, ein „freies“ UNIXkompatibles Betriebssystem zu entwickeln46.
Zu diesem Zweck rief er 1984 das GNU-Projekt47 ins Leben und
gründete ein Jahr später die Free Software Foundation (FSF) in
Form einer gemeinnützigen Stiftung, um seine Zielsetzung in eine
rechtlich wirkungsvolle Form zu gießen48. In der Folgezeit bis 1990
entwickelte der Programmiererkreis um Stallman nahezu alle Bestandteile des angestrebten Betriebssystems49. Lediglich das Design
des benötigten Kernels50 misslang fortwährend, bis im Jahre 1991
der finnische Informatikstudent und Programmierer Linus Torvalds
den Prototyp seines Linux-Kernels veröffentlichte und 1992 schließlich den GNU-Komponenten hinzufügte51. Dies war die Geburtsstun44
Vgl. Jakob, S.70; So zum Beispiel die heutigen proprietären AIX (IBM), HP/UX
(Hewlett-Packard), Sinix (Siemens), Sun/OS und Solaris (Sun) oder Unixware (Novell), diese und weitere Bsp. bei Grassmuck, S.216.
45
Vgl. Jaeger/Metzger, OSS, S.8
46
Vgl. Wayner, S.98ff.; Meretz/SPW, S.32
47
„GNU“ steht hierbei im Sinne von Stallmans „Hacker-Humor“ für „GNU’s Not
UNIX“ entsprechend seiner Zielsetzung: Ein zu UNIX funktional äquivalentes Betriebssystem zu schreiben, welches ohne jede Zeile dessen geschützten Quellcodes auskommt, vgl. Jaeger/Metzger, OSS, S.11; Grassmuck, S.222
48
Vgl. http://www.fsf.org; im Jahre 2001 wurde zudem von einer Gruppe deutscher
Entwickler deren europäische Schwesterorganisation FSF Europe gegründet, vgl.
CR 2001, S.65; http://www.fsfeurope.org/documents/whyweexist.de.html; Grassmuck, S.222.
49
Vgl. Grassmuck, S.226.
50
"Kernel" ("Kern") ist der zentrale Teil eines Betriebssystems, der die wesentlichsten Funktionen realisiert und sich (solange der Computer läuft) immer im Arbeitsspeicher des Computers befinden muss.
Er erledigt die Hauptaufgaben (Verwaltung von Speicher und Ähnliches) und lädt
bei Bedarf externe Routinen nach, die für spezielle Aufgaben benötigt werden.“,
vgl. Jakob, S.71, FN 13.
51
Vgl. Jaeger/Metzger, OSS, S.13; Omsels/FS Hertin, S.144
10
de des bekannten freien GNU/Linux-Betriebssystems, das im März
1994 in der offiziellen Version 1.0 erstmals verfügbar war52.
2. Die „Basar-Methode“
GNU/Linux war zugleich der Ursprung der für Open Source Software
heute als typisch bekannten dezentralen Entwicklungsmethode, die
auf dem Prinzip der Quelloffenheit aufbaut.
Als Linus Torvalds den Quellcode seiner ersten Version des LinuxKernels im Internet veröffentlichte, bat er zugleich die Nutzer einer
Newsgroup ähnlich interessierter Programmierer um Hilfe bei der
weiteren Fortentwicklung, und trat damit eine Lawine los: Über die
Grenzen seiner Newsgroup hinaus wurde das Projekt zunehmend
publik. Schließlich war es über das Internet für interessierte Hobbyund Profi-Programmierer möglich geworden, sich weltweit daran zu
beteiligen53. So kam es, dass jedes sich stellende Problem gleichzeitig von verschiedenen Programmierern bearbeitet werden konnte. Je
versierter und ausgefeilter die jeweilige Problemlösung war, umso
mehr steigerte sich die Reputation ihres Entwicklers innerhalb dieser
Programmiererkreise. Auf diese Art entstand zwischen den beteiligten „Hackern“ ein ehrgeizig getriebener Wettbewerb um Anerkennung in der Programmierergemeinde54.
Dieses Entwicklungsmodell wird nach Eric Raymond auch die „Basar-Methode“ genannt, weil die Entwicklung parallel und unkoordiniert durch den gegenseitigen Austausch belebt - dem äußeren Erscheinungsbild eines Basars ähnlich - verläuft55. Es förderte schließlich das heutige GNU/Linux-Betriebssystem zutage, setzte sich bei
der Entwicklung von Open Source Software als weitverbreitetes
52
Vgl. Koch/CR 2000, S.333; Grassmuck, S.227.
53
Vgl. Jakob/S.71f.
54
Vgl. Grzeszick/MMR 2000, S.414.
55
Demgegenüber vergleicht der Autor (wie Stallman ein versierter „Hacker“ der
ersten Stunde) die Entwicklung proprietärer Programme mit dem Bau einer Kathedrale: Nach den Vorstellungen eines einzelnen Bauherren oder einer kleinen
Gruppe Stein auf Stein, vgl. Raymond, Kap.1, “The Cathedral and the Bazaar”
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedralbazaar/index.html#catbmain.
11
Standardmodell durch und führte so zu einer mittlerweile breiten Palette von robusten und verlässlichen Programmen dieser Art56.
Wenngleich heute die Programmierung von GNU/Linux durch ein
zentrales Komitee einer Qualitätskontrolle unterzogen wird57, haben
dazu weltweit über 1.000 Programmierer sog. Patches und Bugfixes
beigetragen58. Investierte Arbeit und eingebrachtes Wissen potenzieren sich auf diese Weise und beschleunigen den Entwicklungsprozess, während gleichzeitig auch die Fehlerkorrektur durch das Prinzip „Viele Augen sehen mehr“ schneller abläuft59. Hinzu kommen die
Vorteile der unaufwendigen, schnellen Verbreitung über das Internet60. Produktupdates und Folgeversionen stehen in kürzeren
Zeitintervallen bereit.
Aus diesen Gründen gilt Open Source Software heute ihrer proprietären Konkurrenz gegenüber als technisch überlegen. Speziell durch
ihren transparenten Quellcode verspricht sie eine besondere Vertrauenswürdigkeit durch erhöhte Sicherheitskontrollmöglichkeiten61.
Manche sehen in diesem Entwicklungsmodell gar die einzig zukunftstaugliche Form der Qualitätssicherung62 sowie eine essenzielle
Voraussetzung effektiver Sicherheitsverifizierung63. Raymond merkte
56
57
Linus Torvalds selbst steht diesem Komitee vor und trifft mit einigen Mitarbeitern
die letzte Entscheidung darüber, welche neuen Codes in den offiziellen
GNU/Linux-Sourcebaum aufzunehmen sind. Seine Maxime hierbei ist es allerdings
das System offen und demokratisch zu halten – insbesondere die Nutzerinteressen
bei der Weiterentwicklung zu berücksichtigen, vgl. Grzeszick/MMR 2000, S.414.
Zur Verwaltung des offiziellen Sourcebaums in OSS-Projekten siehe Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.510f.; Schneidewind/Landsberger/Eggers,
ZFO 2002, S.227.
58
Vgl. Valloppillil, 2.Kap. “Open Source Process”, http://www.freesoft.org/mirrors/www.opensource.org/halloween/halloween1.html#_Toc427495722;
Schneidewind/Landsberger/Eggers sprechen gar von 3.000 beteiligten Entwicklern, vgl. dies., ZFO 2002, S.227.
59
Vgl. Raymond, Kap. 5, “How many Eyeballs Tame Complexity”,
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s05.html;
Linus Torvalds: “Die Arbeit, die man hineinsteckt, vervielfacht sich…Es gibt eine
automatische Qualitätskontrolle, weil alles ständig unterBeobachtung steht“ in Die
Zeit, „Programmierer aller Länder vereinigt Euch!“, aaO. Omsels/FS Hertin, S.143;
Grzeszick/MMR 2000, S.415.
60
Vgl. Grützmacher/ITRB 2002, S.85; Weber/FS Honsell, S.45f.
61
Vgl. Jürgens/DSB 2000, S.6; Grzeszick/MMR 2000, S.415.
62
Vgl. Schumann/DSB 2002, S.8.
63
12
zur Person Torvalds an, dass wohl nicht der Entwurf des LinuxKernels sein größter Erfolg gewesen sei, sondern die Erfindung dieses innovativen, effizienten Entwicklungsmodells64.
3. „Free – as in free speech“
Stallman schrieb seine Motivation im GNU-Manifest nieder. Demnach sollte das neue Betriebssystem jedermann „frei wie Luft“ ohne
Kopierverbote zur Verfügung stehen65.
Konkretisiert wurde dieser Gedanke von der FSF-Free-SoftwareDefinition, welche erstmals die grundlegenden Eigenschaften freier
Software umriss66. Diese orientierten sich an den Bedürfnissen der
Entwickler und umfassten die Freiheit, das Programm zu benutzen,
Kopien herzustellen und weiter zu verbreiten sowie das Programm
zu modifizieren und zu verbessern und auch in dieser Form weiter zu
verbreiten67. Darüber hinaus sollte niemand für die Erlaubnis zahlen
müssen, ein Programm entsprechend dieser Definition zu benutzen.
Folgerichtig wurden die Freiheiten durch ein absolutes Lizenzgebührenverbot ergänzt. Dabei ging es jedoch keinesfalls darum, jeglichen
Gelderwerb mittels der Produkte zu stigmatisieren. Stallman und die
FSF sowie auch Torvalds sehen grundsätzlich bis heute nichts Falsches daran, freie Programme kommerziell einzusetzen, solange
diese frei im Sinne ihrer Definition bleiben68. Lediglich die Rechte am
Programm mussten demnach entgeltfrei überlassen werden. Für die
Überlassung des Programms selbst hingegen könne jeder einen
Preis in beliebiger Höhe verlangen, sofern jemand anders bereit sei,
diesen zu zahlen69.
64
„In fact, I think Linus's cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development
model.” vgl. Raymond, Kap. 3, “The Importance of Having Users”,
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s03.html.
65
Vgl. http://www.gnu.org/gnu/manifesto.html; auf Deutsch:
http://www.gnu.de/mani-ger.html.
66
Vgl. Jaeger/Metzger, OSS, S.1.
67
Vgl. http://www.fsf.org/philosophy/free-sw.html: „Free software is a matter of the
users’ freedom to run, copy, distribute, study, change and improve the software.”
68
Vgl. Die Zeit Nr.44 vom 23.10.2003, „Programmierer aller Länder vereinigt
Euch!“, http://www.zeit.de/2003/44/Open_Source.
69
Vgl. Schulz/Linux-Magazin 2003, S.68;
13
Zur Veranschaulichung der missverständlichen Bedeutung des Wortes „frei“ formuliert deshalb die Free-Software-Definition klarstellend:
„»Freie Software« hat etwas mit Freiheit zu tun, nicht mit dem Preis.
Um das Konzept zu verstehen, ist an »frei« wie in »freier Rede«, und
nicht wie in »Freibier« zu denken“70.
4. Freiheit per Definition
Dieses Grundkonzept griff Bruce Perens in seinen Debian Free
Software Guidelines (DFSG) auf71. Hier wurden die wesentlichen
Charakteristika geordnet und in eine griffige Kurzformel gebracht, die
Software erfüllen musste, um im Sinne des Debian-Projekts72 als
freie Software zu gelten73. Die DFSG dienten schließlich 1998 als
Basis für die ebenfalls von Perens entwickelte, heute gängige Open
Source Definition (OSD), welche die Anforderungen über das Debian-Projekt hinaus verallgemeinert74. Diese entscheidenden Merkmale können wie folgt zusammengefasst werden:
Open Source Software muss die unbeschränkte Weiterverbreitung
ohne Lizenzgebühren gestatten und Zugang zum Quellcode gewährleisten. Weiter muss die Veränderung, Weiterentwicklung und Weiterverbreitung der Software erlaubt sein. Diese Rechte dürfen nicht
gegenüber bestimmten Personengruppen oder hinsichtlich bestimmter Nutzungen beschränkt werden. Auch darf keine andere Software
eingeschränkt werden, was insbesondere bedeutet, dass eine OpenSource-Lizenz nicht verlangen darf, dass sämtliche Software, die
http://www.gnu.org/philosophy/selling.html: “You can charge nothing, a penny, a
dollar, or a billion dollars. It's up to you, and the marketplace, so don't complain to
us if nobody wants to pay a billion dollars for a copy.”;
Linus Torvalds: “Jeder darf aus Linux so viel Kapital schlagen, wie er will. Es geht
lediglich darum, das System offen und demokratisch zu halten.“ in Die Zeit, „Programmierer aller Länder vereinigt Euch!“, aaO.
70
“’Free software’ is a matter of liberty, not price. To understand the concept, you
should think of ‘free’ as in ‘free speech’, not as in ‘free beer’.''
71
http://www.debian.org/social_contract.html#guidelines.
72
Bei Debian handelt es sich um ein nichtkommerzielles Freie-Software-Projekt,
welches eine GNU/Linux-Distribution herausgibt, vgl. http://www.debian.org.
73
74
Vgl. Jaeger/Metzger, OSS, S.2; Grassmuck, S.296.
Vgl. http://www.opensource.org/osd.html; Köhntopp/Köhntopp/Pfitzmann, DuD
2000, S.509, Deike/CR 2003, S.10; Jaeger/Metzger, OSS, S.2
14
zusammen mit der Open Source Software verbreitet wird, selbst freie
Software sein muss75.
Im Gegensatz zu proprietärer Software wird das Open-SourceModell demnach von zwei Aspekten grundlegend geprägt, die einander ergänzen und bedingen: Dies ist zum einen die technische Möglichkeit, durch Zugang zum Quellcode das Programm den individuellen Bedürfnissen des Nutzers anzupassen, es zu kopieren und sogar
weiterzugeben, und zum anderen die rechtliche Erlaubnis, dies auch
zu dürfen76. Juristisch wird diese Erlaubnis durch die umfassende
Einräumung entsprechender urheberrechtlicher Nutzungsrechte an
jedermann (erga omnes) erteilt77.
Open Source Software unterscheidet sich demnach nicht technisch z.B. nach Art der verwendeten Programmiersprache - von anderer
Software, sondern stellt lediglich in wirtschaftlicher und rechtlicher
Hinsicht und auf konzeptioneller Ebene einen Gegenentwurf zu den
proprietären Programmen dar78.
5. „OSS” vs. “Free Software”
Es fällt auf, dass ursprünglich stets der Begriff „freie Software“ gebraucht wurde und der jüngere Begriff „Open Source Software“ gegen Ende der neunziger Jahre erst relativ spät auftaucht.
Hintergrund dieser begrifflichen Abspaltung war ein Beschluss der
von Bruce Perens und Eric Raymond im Februar 1998 neugegründeten Open Source Initiative (OSI)79. Perens und Raymond hatten das
gestiegene wirtschaftliche Potenzial freier Software erkannt, als die
Firma Netscape auf dem Höhepunkt des bekannten Browserkrieges
mit Microsoft die Offenlegung des Quellcodes ihres Browsers angekündigt hatte. Durch die Initiative sollte das jüngst aufgekommene
75
Vgl. zu diesen Kriterien u.a. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.509;
Weber/FS Honsell, S.43; Jaeger/Metzger, OSS, S.2; Omsels/FS Hertin, S.141
76
Vgl. Sandl/CR 2001, S.346; Speichert, 1.Abschnitt, „Was ist OSS?“
77
Vgl. Grützmacher/ITRB 2002, S.87; Koch/CR 2000, S.333; Jaeger/Metzger,
OSS, S.2f. In Deutschland geschieht dies gem. § 31 Abs. 1 S. 1 UrhG, vgl.
Koch/CR 2000, S.273.
78
Vgl. Koch/CR 2000, S.273; Grzeszick/MMR 2000, S.413.
79
Vgl. Grassmuck, S.232; http://www.opensource.org/docs/board.html.
15
Interesse verschiedener Unternehmen an dem neuen SoftwareModell weiter verstärkt werden. Die Bezeichnung „frei“ hatte ihrer
Ansicht nach allerdings etwas Missverständliches80 sowie Kommunistisches oder Rebellisches81 an sich und drohte daher mögliche
Investoren zu verschrecken. Statt der idealistischen Hintergründe
wollte man die pragmatischen technischen und wirtschaftlichen Vorzüge freier Software in den Vordergrund rücken82. Man einigte sich
daher auf die Verwendung des Begriffs „Open Source Software“83
und betonte in der Folge vermehrt deren besondere Qualität anstelle
ihrer freiheitlichen Aspekte, und bewirkte so eine Spaltung der moralischen von der wirtschaftlichen Seite derselben Sache. Stallman und
die FSF sahen durch diesen Schritt die freiheitlichen Ideale ihrer
Entwicklung gefährdet und gingen ihrerseits auf Distanz84, was jedoch nichts mehr am durchschlagenden Erfolg des Begriffswechsels
ändern konnte: Im Laufe des Jahres 1998 stiegen eine Reihe der
weltgrößten Computerunternehmen wie IBM, Sun Microsystems, Corel und Oracle in die Entwicklung ein, um ihrerseits von den durch
Open Source Software gebotenen Möglichkeiten zu profitieren. Auch
die Computer- und Finanzpresse nahm diesen Begriff auf85. Die Bezeichnung hatte sich hiermit endgültig durchgesetzt. Inhaltlich sind
beide Ausdrücke jedoch wohl weitgehend deckungsgleich86.
80
Das englische Wort bedeutet gleichermaßen “kostenlos” und “frei”, vgl. oben
unter B. I. 3.) Free – as in free speech.
81
Was nicht zuletzt auch an der durchaus streitbaren „Hacker-Ethik“ ihres geistigen Vaters Richard Stallman lag, vgl. Grassmuck, S.231, 305.
82
Vgl. History of the OSI, http://www.opensource.org/history.html; Grassmuck,
S.230f.; Jakob, S.72.
83
Vorgeschlagen wurde dieser Ausdruck von Christine Peterson während der konstitutiven OSI-Sitzung am 3.02.1998, vgl. http://www.foresight.org/FI/Peterson.html.
84
Vgl. Stallman/Open Sources, S.69f.: “The rhetoric of ‘Open Source’ focuses on
the potential to make high quality, powerful software, but shuns the ideas of freedom, community, and principle.”, online abrufbar unter:
http://www.openresources.com/documents/open-sources/node70.html.
85
86
Vgl. Grassmuck, S.230f.; Jaeger/Metzger, OSS, S.4.
Dies wird durch die oben beschriebenen inhaltlich weitgehend übereinstimmenden Definitionen deutlich, vgl. oben B. I. 4.) Freiheit per Definition. Aus diesem
Grund werden hier auch beide Begriffe synonym verwandt.
Es bleibt zudem anzumerken, dass in jüngster Zeit eine Tendenz innerhalb der
Szene zur Rückbesinnung auf den alten Begriff wahrzunehmen ist: So kehrte Perens der OSI den Rücken und wählte erneut die Seite der FSF, indem er ausdrück-
16
6. Open-Source-Lizenzmodelle
In der Folge entwickelte die OSI ein Verfahren zur Beurteilung und
Zertifizierung von Open-Source-Lizenzen. Solche, die den bereits
beschriebenen Kriterien der OSD entsprechen, werden demnach als
„OSI-certified“ anerkannt87.
Dies geschah bei mittlerweile 45 verschiedenen Lizenzmodellen, deren ältestes und wichtigstes die hier auf dem Prüfstand stehende
GNU General Public License (GPL) ist88. Neben der GPL zählen in
der Praxis auch die GNU Lesser General Public License (LGPL)89,
die Mozilla Public License (MPL)90 sowie die Berkeley Software Distribution License (BSD)91 und die Artistic License92 zu den am weitesten verbreiteten „klassischen“ Open-Source-Lizenzen93.
lich von „freier Software“ sprach und die Überschattung der Ziele und Bemühungen
der FSF sowie die daraus resultierende Spaltung öffentlich bedauerte, vgl. Grassmuck, S.232.
Es sprechen somit gute Gründe für die Annahme, dass die Bezeichnung „freie
Software“ gleichberechtigt neben dem populäreren Ausdruck „OSS“ steht.
Nicht zuletzt merkt Stallman selbst an: “‘Free software’ and ‘Open Source’ describe
the same category of software, more or less, but say different things about the
software, and about values.”, vgl. Stallman/Open Sources, S.70.
87
Vgl. Weber/FS Honsell, S.43; Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.510
88
Vgl. die Liste der anerkannten Lizenzmodelle auf
http://www.opensource.org/licenses/index.html;
89
Die LGPL gilt im Wesentlichen für sog. Programmbibliotheken (DLL-Dateien)
(sie wurde daher früher auch Library General Public License genannt) und sieht
mit Rücksicht auf deren technische Voraussetzungen einige weniger strenge („lesser“) Lizenzbestimmungen vor, als die GPL dies tut, vgl. Jaeger/Metzger, OSS,
S.50f.; ein inhaltlicher Vergleich zwischen GPL und LGPL findet sich bei Siepmann/Freie SW, S.36ff.
90
http://www.mozilla.org/MPL/MPL-1.1.html.
91
http://www.opensource.org/lisenses/bsd-license.php; Die BSD-Lizenz wurde
1989 für eine an der Universität Berkeley entwickelte UNIX-Variante geschaffen
und diente als Vorbild für verschiedene ähnliche Lizenzen, u.a. der Apache Software License (http://www.apache.org/LICENSE-1.1), vgl. Jaeger/Metzger, OSS,
S.54f.
92
http://www.opensource.org/licenses/artistic-license.php; Auch die Artistic License
stand Pate für eine Reihe von bedeutsamen Lizenzmodellen: So gilt die insbesondere Perl Artistic License für die weitverbreitete Web-Skriptsprache Perl
(http://www.perl.com/pub/a/language/misc/Artistic.html), vgl. Jaeger/Metzger, OSS,
S.71.
93
Vgl. http://www.opensource.org/licenses/index.html; Witzel/ITRB 2003, S.176
17
II. GNU General Public License
Die GNU General Public License (GPL) wurde 1989 von Richard
Stallman in Zusammenarbeit mit dem New Yorker Rechtsprofessor
Eben Moglen von der Columbia Universität entwickelt, um der
Verbreitung von freier Software ein stabiles rechtliches Fundament
zu geben, welches insbesondere die Freiheiten gemäß der FSFFree-Software-Definition auf Dauer sicherstellte94. Sie wird deshalb
gelegentlich als der „juristische Hack“ der FSF bezeichnet95.
Nach § 0 GPL96 gilt die Lizenz für Programme und andere Werke, die
nach der Entscheidung des Urhebers unter ihren Bedingungen veröffentlicht werden97. So geschah es beispielweise durch Linus Torvalds, als er 1991 die erste Version seines Linux-Kernels publizierte
und um Mithilfe daran bat. Das wohl prominenteste Werk unter Geltung der GPL ist infolge dieser Entscheidung das erfolgreiche
GNU/Linux-Betriebssystem, das später durch die Zusammensetzung
mit den GNU-Komponenten entstand, die ohnehin unter der GPL
verbreitet wurden98.
Nach deutschem Urheberrecht sind insbesondere Computerprogramme i.S.v. §§ 2 Abs. 1 Nr.1, 69a UrhG und Datenbankwerke
i.S.v. § 4 UrhG, aber auch sonstige nach § 2 UrhG urheberschutzfähige Softwareteile von diesem Geltungsbereich erfasst99.
Derzeit liegt die GPL in ihrer zweiten Fassung vom 2.06.1991 vor,
die offiziell nur in englischer Sprache existiert100. Auch außerhalb des
94
Vgl. Präambel der GPL, Abs. 1:“…the GNU General Public License is intended
to guarantee your freedom to share and change free software - to make sure the
software is free for all its users.”; vgl. auch Jaeger/Metzger, OSS, S11f.
95
Vgl. Grassmuck, S.225.
96
In der Nummerierung der GPL erkennt man erneut Stallmans Handschrift: Es ist
unter Computerwissenschaftlern üblich, die Nummerierung von Datenbanken mit
„0“ beginnen zu lassen, weil dies deren weitere Programmierung erleichterte, vgl.
Wayner, S.104.
97
Vgl. § 0 GPL: “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.”
98
Vgl. oben B. I. 1. Entstehungsgeschichte.
99
Vgl. Grützmacher/ITRB 2002, S.86
100
Diese amtliche Fassung ist abrufbar unter: http://www.gnu.org/copyleft/gpl.html;
siehe auch den Anhang dieser Arbeit.
18
englischen Sprachraums verweist die FSF jeden ausschließlich auf
diese Fassung – diverse Übersetzungen bestehen lediglich zum
besseren Verständnis der verbindlichen Version und sind von der
FSF nicht als offiziell anerkannt101.
In Kürze steht möglicherweise eine dritte Auflage der GPL ins Haus,
die zur Klarstellung bezüglich gewisser internationaler urheberrechtlicher Fragestellungen, insbesondere der Anpassung an neuere
Formen der Online-Nutzung, wie beispielsweise das Application Service Providing, beitragen soll102.
1. Rechte des Nutzers
Als erste freie Software Lizenz gab die GPL das Muster für viele weitere Open-Source-Lizenzen vor103 und bietet alle definitionsgemäßen
Charakteristika im Sinne der OSD104. So räumt sie dem SoftwareNutzer umfangreiche Nutzungs- und Bearbeitungsrechte ein:
•
§ 0 GPL bestimmt neben der Definition des allgemeinen Geltungsbereichs zunächst, dass die einfache Ausführung eines
GPL-Programms keinerlei Einschränkungen unterliegt. Das
bloße Ablaufenlassen des Programms wird damit von der GPL
nicht erfasst. Dieses wird dem Nutzer in Deutschland jedoch
aufgrund von § 69c UrhG ermöglicht, wenn eine Lizenz, wie
hier, keine besondere Bestimmung dazu enthält105.
•
§ 1 GPL betrifft das Recht, auf beliebigen Medien unveränderte Kopien des Programms zu speichern und zu verbreiten.
Voraussetzung hierfür ist es allerdings, jede Kopie mit einem
Urhebervermerk zu versehen, einen Text der GPL beizufügen
und auf den in §§ 11 und 12 GPL vermerkten Haftungsausschluss hinzuweisen.
101
Vgl. Jaeger/Metzger, OSS, S.166; Omsels/FS Hertin, S.145, 148 – selbst die
SuSE AG, offizielle Vertreiberin von GNU/Linux in Deutschland, verbreitet eine
solche deutsche Übersetzung unter dem Vorbehalt, dass in Zweifelsfällen die englische Version maßgeblich sein soll.
102
Vgl. ITRB 2002, S.150, „Neue GNU GPL in Aussicht“; So auch Stallman:
http://old.lwn.net/2002/features/rms.php3.
103
104
Vgl. dazu die Ausführungen oben unter B. I. 4.) Freiheit per Definition.
105
Vgl. F/N, Vinck, § 69d UrhG, Rn.1f.
19
Entsprechend der Philosophie der FSF fügt § 1 Abs. 2 GPL
an, dass es erlaubt sei, für den eigentlichen Kopiervorgang
oder für eine Garantie für das Programm eine Gebühr zu erheben.
•
§ 2 GPL erlaubt schließlich die Veränderung des Programms
sowie auch die Verbreitung dieser veränderten Versionen,
wenn die modifizierten Dateien mit einem Vermerk versehen
werden, der auf die Änderung selbst, ihren Urheber und ihr
Datum hinweist. Ferner ist diese Erlaubnis an eine spezielle
Bedingung geknüpft, die gewährleisten soll, dass freie Software auch weiterhin frei von proprietären Exklusivrechten
bleibt106.
2. Das Copyleft-Prinzip
Inhaltlich schreibt § 2b GPL dem Nutzer nämlich vor, die erfolgten
Bearbeitungen im Falle der Verbreitung seinerseits unter die GPL zu
stellen und damit auch Dritten wiederum im Quellcode und frei von
Lizenzgebühren zugänglich zu machen. Diese Verpflichtung gilt für
das bearbeitete Datenwerk als Ganzes. Sie enthält allerdings eine
vom Nutzer zu beweisende Ausnahmeregelung107 für als unabhängig
und eigenständig identifizierbare Werke, die frei von den GPLBedingungen weitergegeben werden können108. Diese Abgrenzung
ist anhand verschiedener technischer Kriterien zu treffen, ist in der
Praxis jedoch einzelfallabhängig und mitunter kompliziert109.
Bei dieser Bestimmung handelt es sich um einen Selbstschutzmechanismus, der verhindert, dass eine Umwandlung in proprietären
Code stattfinden kann. Um das auch auf rechtlicher Ebene oppositionelle Konzept freier Software zu verdeutlichen, bezeichneten Stall106
Vgl. Grzeszick/MMR 2000, S.415.
107
Vgl. Stickelbrock/ZGS, S.370.
108
Vgl. § 2 Abs. 2 GPL: “These requirements apply to the modified work as a
whole. If identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in themselves,
then this License, and its terms, do not apply to those sections when you distribute
them as separate works.”
109
Vgl. Jaeger/Metzger, OSS, S.41; Stickelbrock/ZGS, S.370; daher soll dieses
Problem erst dort eingehender behandelt werden, wo das es Haftungsrelevanz
offenbart, vgl. unten E. II .4. a. 2.) Reichweite des „Copyleft“-Prinzips.
20
man und Moglen dieses Konzept als das sog. „Copyleft“ - ein Gegenbegriff zum Copyright, mit dem die proprietäre Softwareindustrie
ihre Produkte zu sichern sucht110. Das Copyleft-Prinzip ist charakteristisch für die GPL und unterscheidet sie durch seinen freiheitssichernden Effekt von verschiedenen anderen Open-Source-Lizenzen,
die ihren Nutzern weniger strenge Nutzungskonditionen auferlegen,
wie dies beispielsweise bei der BSD-Lizenz der Fall ist111.
3. Verletzungen der GPL
§ 4 GPL dient der Durchsetzung der Lizenzbedingungen112. Für den
Fall ihrer Verletzung ordnet die Bestimmung die Nichtigkeit jeder
Modifizierung, Weiterlizenzierung und Verbreitung an und sanktioniert den Lizenznehmer mit dem automatischen Verlust seiner Rechte aus der Lizenz113. Die Klausel wirkt damit wie eine auflösende Bedingung nach § 158 Abs. 2 BGB, die bei Lizenzverletzungen ex nunc
zum Verlust der Nutzungsrechte führt114. Ausdrücklich ausgenommen davon sind aber die Personen, die vom Lizenznehmer die Software inklusive GPL erworben haben und diese ihrerseits anerkennen.
4. Rechtseinräumung durch den Urheber
Dieser Effekt soll durch einen weiteren juristischen Kniff gelingen:
Nach § 6 GPL erhält jeder Nutzer die über das einfache Ablaufenlassen des Programms hinausgehenden Rechte unmittelbar vom Urhe110
Vgl. http://www.gnu.org/licenses/licenses.html#WhatIsCopyleft: “Proprietary
software developers use copyright to take away the users' freedom; we use copyright to guarantee their freedom. That's why we reverse the name, changing ‘copyright’ into ‘copyleft’.''
111
Hier steht es dem Nutzer frei, die Software in eigene proprietäre Produkte einzufügen und diese unter eigenen Lizenzbestimmungen zu vertreiben. So unterscheiden Jaeger/Metzger beispielsweise kategorisch nach „Copyleft“- und „NonCopyleft“-Software, vgl. dies., OSS, S.4f.
112
Vgl. Deike/CR 2003, S.11; vgl. auch Lejeune/ITRB 2003, S.10.
113
Vgl. § 4 GPL: „You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt otherwise to copy,
modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or
rights, from you under this License will not have their licenses terminated so long
as such parties remain in full compliance.”
114
Vgl. Spindler/Wiebe, CR 2003, S.876; Schiffner, S.165f.; Jaeger/Metzger,
GRUR Int., S.843; Deike/CR 2003, S.16.
21
ber des Programms bzw. der betreffenden Programmteile115. Hieraus
wird ersichtlich, dass er nicht das Recht haben soll, diese zusammen
mit dem Programm weiter zu übertragen. Ein Kettenerwerb von Empfänger zu Empfänger findet daher an den Nutzungsrechten nicht
statt116. Gibt er die Software an Dritte weiter, so handelt er in Bezug
auf die Rechte an Programmteilen, die nicht von ihm selbst entwickelt wurden, lediglich als Bote oder Vertreter des jeweiligen Urhebers117. Es liegt mithin ein dreipoliges Vertragsverhältnis vor118. Mit
jeder Weitergabe der Software durch einen Nutzer findet auch
gleichzeitig eine Neueinräumung der Nutzungsrechte durch den berechtigten Urheber statt119. Nach deutschem Urheberrecht trifft dieser
durch die Einräumung eines einfaches Nutzungsrechts an jedermann
i.S.d. § 31 Abs. 1, 2 UrhG eine Vorausverfügung nach § 40 Abs. 1
UrhG120. Für die verfügungsrechtliche Übertragung der Nutzungsrechte sind daneben die Vorschriften der §§ 398, 413 BGB anzuwenden121.
5. Gewährleistungs- und Haftungsausschluss
Eine weitere Besonderheit der GPL ist der absolute Gewährleistungs- und Haftungsausschluss der §§ 11, 12 GPL. Schützen soll
dieser denjenigen, der das Programm lizenzgebührenfrei abgibt122.
Diese Haftungsfreizeichnung soll sowohl dem Vertrieb als auch der
Entwicklung der Software zugute kommen, denn auch Open-Source115
Vgl. § 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.”
116
Vgl. Weber/FS Honsell, S.56; Omsels/FS Hertin, S.159.
117
Vgl. Stickelbrock/ZGS 2003, S.370; Spindler/VSI, S.33; Spindler/Wiebe, CR
2003, S.873. Die genaue Einordnung ist umstritten ob der Frage, inwieweit dem
weitergebenden Nutzer Entscheidungsspielräume bei Vertragsschluss zustehen:
Vgl. Deike/CR 2003, S.13 (für Vertreter); sowie Plaß/GRUR 2002, S.677; Lejeune/ITRB 2003, S.11 (für Botenschaft).
118
Vgl. Koch/CR 2000, S.338.
119
Vgl. Koch/CR 2000, S.336; Jaeger/Metzger, GRUR 1999, S.843f.
120
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.843f.
121
F/N, Hertin, Vor § 31, Rn. 10.
122
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.846; Grützmacher, S.89;
§11 GPL: “…BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE,
THERE IS NO WARRANTY FOR THE PROGRAM…”.
22
Entwickler müssten demnach keine Haftung befürchten: Das betreffende Programm soll nur „as is“ zur Verfügung gestellt werden, wie
die ausschließlich in Großbuchstaben unter der fettgedruckten Überschrift „NO WARRANTY“ verfassten §§ 11, 12 GPL ihren Leser wissen lassen123. Das Risiko bezüglich der Qualität und Leistungsfähigkeit des Programms sowie jeglicher Mangelschäden oder Mangelfolgeschäden soll damit dem Nutzer auferlegt werden124. Die Liste mit
den hier beispielhaft genannten Fällen von Datenverlusten, fehlerhafter Datenverarbeitung und Inkompabilitäten mit anderen Programmen ließe sich problemlos erweitern – eine besondere Bedrohung
geht beispielweise auch von Virenbefall oder Sicherheitslücken innerhalb der Software aus125. Die für die Verfasser der GPL außerordentliche Wichtigkeit dieses Haftungsausschlusses wird nicht nur
durch seine äußerliche Form, sondern auch durch die Hinweispflichten bei der Weitergabe des Programms gem. § 1 GPL deutlich gemacht126.
Gerade diese Bestimmungen der GPL werden aber häufig kritisiert
und für die geltend gemachten Rechtsunsicherheiten ursächlich erklärt127. Zumindest aber stellen sie den Ansatzpunkt der vorliegenden
Untersuchung dar und werden daher noch von besonderem Interesse sein.
C. Erscheinungsformen und Einsatzmodelle
Schon die Einleitung hat gezeigt, in welch vielfältigen und differenzierten Bereichen Open Source Software heute zum Einsatz kommt.
Sofern es sich dabei um GPL-lizenzierte Software handelt, werden
die hier entstehenden rechtlichen Beziehungen zwischen den handelnden Personen wesentlich durch die GPL definiert. Um diese
123
Dies bedeutet „wie besehen“; vgl. den Text der §§ 11, 12 GPL im Anhang G.
124
Vgl. Stickelbrock/ZGS, S.369.
125
Vgl. Spindler/VSI, S.83; Jaeger/Metzger, OSS, S.167; Schneider/Günther, CR
1997, S.389.
126
Vgl. Omsels/FS Hertin, S.150; vgl. oben unter B. II. 1. Rechte des Nutzers.
127
Vgl. nur beispielhaft Spindler/VSI, S.72ff.; Stickelbrock/ZGS, S.369.
23
Rechtsverhältnisse (richtig) zu behandeln, besteht zuvor der Bedarf,
einen Blick auf die sozialen und wirtschaftlichen Implikationen zu
werfen, von denen sie geprägt werden, und sich die Gründe hierfür
vor Augen zu führen.
I. Soziale und wirtschaftliche Bedeutung
In welcher Weise kommt Open Source Software daher in der Praxis
der Informationsgesellschaft am häufigsten zur Anwendung und wie
wird sie konkret eingesetzt?
1. Entwicklergemeinschaft
Open Source Software wird oftmals nach der „Basar-Methode“ in
Programmierergemeinschaften entwickelt, zu denen sich Experten
rund um den Globus zusammenschließen, um ihr Wissen zu teilen
und zu vernetzen128.
Hierbei handelt es sich zumeist um leidenschaftliche HobbyProgrammierer oder Profis, die sich in ihrer Freizeit freiwillig an
Open-Source-Projekten beteiligen129. Die Softwareweitergabe findet
dabei in der Regel aufgrund der großen Praktikabilität über InternetDienste, wie durch Down- bzw. Uploads untereinander oder aus dem
zentralen Repository130 eines existierenden Projekts statt. Auch der
Austausch von Datenträgern ist aber prinzipiell denkbar.
Zu der weiteren Entwicklergemeinschaft wird man zudem auch sachverständige und ambitionierte User zählen müssen, die ihre Software
aus Quellen der Entwickler beziehen und vereinzelt selbst entsprechend ihrer individuellen Bedürfnisse zum privaten Gebrauch anpas128
Vgl. dazu die Darstellung der Arbeitsweise unter B. I. 2. Die „Basar-Methode“.
129
Raymond spricht in diesem Zusammenhang von „voluntary communities of
interest“, vgl. Kap.11, „The Social Context of Open-Source Software”; Koch/CR
2000, S.280; Schneidewind/Landsberger/Eggers, ZFO 2002, S.227; Morner, S.7.
130
Die meisten gut organisierten Projekte verfügen ein solches Repository, welches im Grunde genommen eine Website mit Downloadmöglichkeit der jeweils
aktuellen Version des Quelltexts ist. Gepflegt wird das Repository i.d.R. vom sog.
Concurrent Versioning System (CVS). Hier werden zudem alle Änderungen und
eine Versionshistorie gespeichert, die es ermöglicht komplette ältere Stände zu
rekonstruieren und Änderungen rückgängig zu machen. Im Falle von GNU/Linux
stellt das Linux-Komitee um Linus Torvalds das CVS dar, welches den offiziellen
Sourcebaum und offizielle Versionen bestimmt,
vgl. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.511; näheres auch bei Schneidewind/Landsberger/Eggers, ZFO 2002, S.227.
24
sen, aber zunächst nicht unbedingt daran interessiert sind, ihre Erzeugnisse weiterzugeben131. Immer wieder rekrutieren sich die Mitglieder der Entwicklergemeinschaften schließlich aus dem Umfeld
dieser ambitionierten Nutzer132.
2. Distributionen
Lösungen für weniger geschulte Anwender hingegen bieten die sog.
Distributoren, die schon früh einen besonderen Geschäftsbereich im
Umfeld von Open Source Software für sich erschließen konnten und
dort seitdem eine der ersten etablierten Formen der kommerziellen
Betätigung ausüben133.
Die Distributionen nutzen die Erwerbsmöglichkeiten im Rahmen der
§§ 0 Abs. 2, 1 Abs. 2 GPL und stellen heute wirtschaftlich bedeutsame, zukunftsträchtige Komplettlösungen auf der Basis von Open
Source Software dar134. So fügen Firmen wie RedHat, SuSE, TurboLinux, Caldera oder Mandrake135 eigene GNU/Linux-Distributionen
zusammen, die neben dem eigentlichen Betriebssystem mit ca.
1.000 bis 2.000 weiteren Applikationen aus den eigenen Entwicklungsabteilungen angereichert werden136. Darunter befinden sich
Installationsroutinen und weitere Beigaben, die den Umgang mit der
freien Software vereinfachen, wie beispielsweise graphische Benutzeroberflächen und andere Systemprogramme137. Teilweise befinden
131
Vgl. Jakob, S.78.
132
133
134
Vgl. Deike/CR 2003, S.10; Koch/CR 2000, S.281; Stickelbrock/ZGS 2003,
S.369; Metzger/Linux-Mag 2002. Die Möglichkeit der Distribution hatte Stallman
bereits im GNU-Manifest vorgesehen und dargelegt - so schrieb er dort: „Wenn die
Menschen lieber für GNU mit Service bezahlen, als GNU ohne Service frei zu erhalten, sollte eine Firma, die speziell diesen Service für Leute anbietet, die GNU
frei erhalten haben, rentabel sein…Programmierer können in der Schulung, Benutzerhilfe und Wartung unterkommen.“, vgl. http://www.gnu.de/mani-ger.html.
135
Marktführer sind SuSE und RedHat, wobei die SuSE-Distribution den europäischen Markt dominiert und RedHat auf dem amerikanischen Markt erfolgreicher ist.
Insgesamt gibt es mehrere hundert verschiedene Distributionen, vgl. Schumann/DSB 2002, S.8.
136
137
Vgl. Schumann/DSB 2002, S.8; Jaeger/Metzger, OSS, S.15.
Beispiele hierfür sind die der SuSE-Linux-Distribution beigefügte SetUp-Routine
„YaST“: http://www.suse.de/de/private/products/suse_linux/i386/yast.html, welche
die SuSE AG unter eine eigene Lizenz gestellt hat, vgl.
25
sich hierunter auch kostenpflichtige und unabhängige, eigenständige
Programme, die nach § 2b GPL nicht dem Copyleft-Prinzip und dem
Lizenzgebührenverbot
unterfallen.
Im
weiteren
Angebot
der
Distributoren stehen Handbücher und Dokumentationen und auf
Wunsch auch Dienstleistungen wie Systembetreuung und -pflege138.
Auf diese Weise gaben diese Unternehmen dem GNU/LinuxBetriebssystem eine gewisse „Windows-Nähe“ und schlugen eine
wichtige Brücke zum Enduser, indem sie die zuvor immanente geringe Anwenderfreundlichkeit und den Bedarf nach Kundendienst behoben haben139. Für den Einsatz im Unternehmensbereich bieten die
Distributoren darüber hinaus Dienstleistungen wie Beratung, Schulungen und Training sowie Systemintegration und Support an und
gingen besondere Kooperationen mit großen Soft- und Hardwareherstellern wie SAP, Oracle, IBM und Hewlett-Packard ein, die ihre
Produkte nunmehr für den Einsatz unter GNU/Linux spezifizieren140.
So machten sie insbesondere das GNU/Linux-System zu einem –
wohl nicht zuletzt auch wegen seiner Preisvorteile - konkurrenzfähigen Endnutzerprogramm141.
Der Vertrieb der Distributionen läuft typischerweise auf Datenträgern
über den Handel. Ergänzend wird die Software auch zum Download
http://www.suse.de/de/private/support/licenses/yast.html, sowie die
Benutzeroberfläche KDE:
http://www.suse.de/de/private/products/suse_linux/i386/kde.html.
138
Vgl. Koch/CR 2000, S.334; Grützmacher/ITRB 2002, S.87; Jaeger/Metzger,
GRUR Int. 1999, S.840; Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.512.
139
Diese Eigenschaften hafteten freier Software durch die eher pragmatischtechnischen, auf Funktionalität gerichteten, Interessen ihrer Entwickler in der Programmierergemeinschaft, sowie die dort vorherrschende Praxis sich in Diskussionsforen selbst zu informieren scheinbar naturgemäß an, vgl. Köhntopp/ Köhntopp/Pfitzmann, DuD 2000, S.512; Jaeger/Metzger, GRUR Int. 1999, S.840.
140
Vgl. Deike/CR 2003, S.10; Schumann/DSB 2002, S.8. Siehe auch Pressemitteilung der SuSE AG zur Kooperation mit IBM vom 5.12.2003:
http://www.suse.de/de/company/press/press_releases/archive03/ibm_sof_int_cen.
html sowie die Pressemitteilung vom IBM zur Zusammenarbeit mit RedHat vom
11.12.2003: http://biz.yahoo.com/iw/031211/060988.html.
141
Vgl. Koch/CR 2000, S.281; Stickelbrock/ZGS 2003, S.369.
Die Preise für kommerzielle GNU/Linux-Distributionen liegen bei ca. 9 – 15% des
Preises eines vergleichbaren proprietären Betriebssystems, vgl. Jaeger/Metzger,
OSS, S.49. Im Fall der SuSE-Distribution zahlt der Enduser ca. 50 € für das Softwarepaket, vgl. Die Zeit Nr.44 vom 23.10.2003, „Programmierer aller Länder vereinigt Euch!“, aaO.
26
angeboten142. Bei zusätzlichen Dienstleistungen, wie Installation und
Systemintegration, liegt es in der Natur der Sache, dass die Einrichtung vom Distributor selbst vor Ort wahrgenommen wird.
3. Software-Vertrieb
Wie bereits beschrieben, zeigt auch eine Vielzahl von Softwareanbietern wie Corel, Oracle und IBM erhebliches Engagement in diversen
Open-Source-Projekten. Dieser Einsatz besteht häufig in der
finanziellen Förderung dieser Projekte143. In anderen Fällen betreuen
Softwarefirmen die Fortentwicklung ihrer vormals proprietären, nunmehr freigegebenen Produkte144.
Das dahinter stehende Konzept ähnelt dem der Distributoren und ist
im Grunde darauf angelegt, Open Source Software als Marktöffner
für eigene Produkte und Dienstleistungen einzusetzen145. Gezielt
werden hier Open-Source-Produkte gefördert, um offene Standards
zu setzen, die wiederum dem Absatz eigener proprietär vermarkteter,
auf diesen Standards (z.B. auf dem Betriebssystem GNU/Linux) aufsetzender Programme dienen146. Open Source Software kann so
ebenfalls benutzt werden, um auf sich aufmerksam zu machen und
zu werben147. Auch gelingt es so, teilweise in Marktsegmente vorzudringen, in denen Microsoft noch unterrepräsentiert ist, und diese
neu zu erschließen148 und die eigene Wirtschaftlichkeit zu steigern.
Als IBM das Apache-Projekt durch Beisteuerung seines hauseigenen
Quellcodes förderte, konnte nicht nur ein neuer Markt erschlossen
142
Vgl. Jaeger/Metzger, OSS, S.15; Die Zeit Nr.44 vom 23.10.2003, „Programmierer aller Länder vereinigt Euch!“, aaO; Grützmacher/ITRB 2002, S.85.
143
Vgl. dazu oben A. I. Erfolgsgeschichte Open Source Software.
144
Dies ist z.B. bei StarOffice, MySQL und dem Netscape Browser der Fall, vgl.
Jaeger/Metzger, OSS, S.14; Omsels/FS Hertin, S.144.
145
Vgl. Koch/CR 2000, S.281; Sandl/CR 2001, S.346, 348; Stickelbrock/ZGS 2003,
S.372.
146
147
148
wie z.B. auf die Plattformen Sparc (Sun Microsystems) oder Alpha (Compaq/Digital), vgl. Schumann/DSB 2002, S.7
27
werden, sondern ebenfalls die unrentable Produktion des eigenen
Webservers eingestellt werden149.
Das geschilderte Vermarktungskonzept beginnt oftmals schon beim
gemeinsamen Vertrieb eigener Programme zusammen mit Open
Source Software. Die eigene Software wird dann als zusätzlicher
Mehrwert (als „Value-added“-Produkt) hinzugegeben, für welchen die
Einnahme von Lizenzgebühren möglich ist150. Erfolgversprechend ist
dieses Vorgehen besonders auch dann, wenn es sich dabei um Innovationen handelt, die in Form freier Software noch nicht erhältlich
sind, oder auch bei Nischenanwendungen, die ohne die Beigabe weiterer Software wenige Interessenten finden würden151.
4. Software-Entwicklung
Auch bei der individuellen Software-Erstellung spielt Open Source
Software eine zunehmend größere Rolle. So wird diese nicht ausschließlich nach der „Basar-Methode“ erstellt, sondern es ist durchaus auch üblich, bei der Entwicklung von Einzellösungen zu vereinbaren, die Ergebnisse nach Fertigstellung unter eine Open-SourceLizenz wie die GPL zu stellen. Dies kann für beide Seiten vorteilhaft
sein. Auf der Seite des Entwicklers liegt der Vorteil, auf bereits bestehende Open-Source-Produkte zurückgreifen zu können und die
erstellte Software auch für ähnliche zukünftige Entwicklungen einsetzen zu können152. Für den Besteller wird das Produkt hierdurch
günstiger und er ist für den Support nicht auf den Programmierer
selbst angewiesen, sondern kann beliebige Wartungsfirmen mit der
Systempflege beauftragen153. Insbesondere im Insolvenzfall des
Erstellers wird diese Möglichkeit wertvoll und wichtig154.
Des Weiteren gibt es eine Reihe vornehmlich kleinerer Softwarehäuser, die bestehende Open-Source-Programme an die individuellen
149
Vgl. Jakob, S.80f.
150
Vgl. Jaeger/Metzger, OSS, S.17; Koch/CR 2000, S.281, 334; Sester/CR2000,
S.798.
151
152
153
154
Vgl. Feil, S.2.
28
Bedürfnisse spezieller Kunden anpassen155. Diese Unternehmen
erzielen häufig, ähnlich den Distributoren, zusätzlich auch Einnahmen durch einen umfangreichen, ausgefeilten Kundendienst an ihren
Produkten.
5. Embedded-Bereich
Von wichtiger praktischer Bedeutung ist nicht zuletzt auch der sog.
„Embedded-Bereich“. Große Computerhersteller wie IBM, Dell, Hewlett-Packard oder Compaq liefern ihre Hardware mit vorinstalliertem
GNU/Linux-Betriebssystem aus156. Hierdurch wird es für die Hersteller möglich, Preisvorteile durch die Einsparung von Lizenzgebühren
an ihre Kunden weiterzugeben und ihre Komplett-Systeme günstiger
anzubieten.
Der Bereich der Embedded-Systeme reicht jedoch wesentlich weiter:
Überall dort, wo in der Elektronik Hardware mit einem Prozessor zum
Einsatz kommt, wird ein Betriebssystem benötigt. An Produktionssteuerungsanlagen und Automobilelektronik ist in diesem Zusammenhang genauso zu denken, wie an Haushaltsgeräte, Unterhaltungselektronik und Mobiltelefone. In all diesen Systemen kommen
häufig – unter Umständen bedarfsgemäß reduzierte - GNU/LinuxVersionen zum Einsatz157.
II. Motive und Interessen der Personenkreise
Der Überblick macht deutlich, dass die beteiligten Personenkreise
aus verschiedenen Motiven tätig werden. Der signifikanteste Unterschied besteht dabei zwischen nichtkommerziellem Antrieb und wirtschaftlich orientierten Interessen.
1. Überwiegend nichtkommerzielle Motivation
Die in der internationalen Entwicklergemeinschaft existenten Motivationen sind vielschichtig. Die von Stallman vorgegebene Idee freier
Software basiert auf dem kant’schen kategorischen Imperativ: So
155
Vgl. Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.512; Jaeger/Metzger, OSS,
S.17.
156
Vgl. Koch/CR 2000, S.273; Jaeger/Metzger, OSS, S.17; Sester/CR2000, S.798.
157
Vgl. Jaeger/Metzger, OSS, S.15f.
29
sieht dieser in der freien Softwareweitergabe einen „Akt der Nächstenliebe“ und fühlt die Verpflichtung einer „goldenen Regel“, die es
gebiete, geistiges Eigentum zum Wohl aller verfügbar zu halten und
Software als öffentliches Gut zu behandeln158. Die „Kreativität selbst“
und der „Ruhm“ seien Lohn genug. Auch die Präambel der GPL formuliert dementsprechend derartige Motive159.
Innerhalb der Programmierergemeinschaft ist dieser Ansatz in der
Tat tragfähig. Zu weiten Teilen werden die hier beteiligten Programmierer losgelöst von Finanzinteressen durch ihre Leidenschaft am
Programmieren und die Anerkennung der Community inspiriert160.
Teilweise kommen jedoch auch weitere Interessen hinzu. Dies können im Einzelfall variierende zusätzliche Absichten, wie die Verbreitung des eigenen Know-hows oder Namens zur Steigerung der persönlichen Bekanntheit im Hinblick auf lukrativere Anstellungen, eine
Effizienzsteigerung durch bessere Software oder auch die Hoffnung
auf späteren Profit durch Schulung oder Support am Programm
sein161. Im Vordergrund wird jedoch stets die Weiterentwicklung des
gemeinsamen Projekts oder die individuelle Bearbeitung der Software „aus Spaß an der Freude“ stehen. Mögen daher den ursprünglichen altruistischen Motiven Stallmans auch sekundäre strategische
oder wirtschaftliche Interessen der bezeichneten Art hinzutreten, so
sind es innerhalb der aus Experten bestehenden Entwicklergemeinschaft und ihres Umfeldes die nichtkommerziellen Motive, die überwiegen. De facto handeln hier nämlich ganz überwiegend qualifizierte Software-Entwickler mit hohen Bezügen auf freiwilliger Basis oder
158
Vgl. Stallman, ursprüngliche Ankündigung des GNU Projekts, 1983,
http://www.gnu.org/gnu/initial-announcement.de.html; ders., GNU-Manifest
http://www.gnu.org/gnu/manifesto.html - auf Deutsch: http://www.gnu.de/maniger.html. Siehe dazu auch Jaeger/Metzger, GRUR Int., S.841, die darauf hinweisen, dass Stallmans Hinweis auf Kant recht kurz gegriffen ist, da dieser in seinem
Text „Von der Unrechtmäßigkeit des Büchernachdrucks“ von 1785 das Urheberrecht als subjektives Recht betrachtet.
159
Vgl. Präambel der GPL: “The licenses for most software are designed to take
away your freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free softwareto make sure the software is free for all its users.”
160
Vgl. Speichert, 1.Abschn., „Was ist OSS?“; Schneidewind/Landsberger/Eggers,
ZFO 2002, S.227.
161
Vgl. Jakob, S.77; Jaeger/Metzger, GRUR Int. 1999, S.841.
30
eben Freizeithacker, deren materielle Situation abgesichert und nicht
mit der vieler Urheber aus dem künstlerischen Bereich vergleichbar
ist162.
2. Wirtschaftliche Interessen rund um OSS
Die angesprochenen potenziellen Sekundärinteressen zeigen jedoch, dass die Grenzen zwischen Altruismus und Kapitalismus fließend sein können. Auch die Abspaltung der OSI von den ursprünglichen freiheitlichen Idealen der FSF und das darauf einsetzende Engagement großer Unternehmen zeigen eindrucksvoll, dass seit geraumer Zeit im Umfeld von freier Software handfeste ökonomische
Interessen verfolgt werden. Hat die kommerzielle Öffnung durch
Perens und Raymond bei Gründung der OSI möglicherweise noch im
Interesse der Open-Source-Idee selbst gestanden, so werden Großunternehmen, die Open-Source-Projekte finanziell oder durch Beteiligung an der Entwickler-Community fördern, dazu eindeutig durch
marktstrategische Ziele veranlasst163. Wohl kaum wären bezeichnete
Konzerne bereit, derartige Investitionen ohne die Erwartung späterer
Gewinnschöpfung zu tätigen. Diese beabsichtigten Profite können
einerseits durch höhere Absätze erzielt werden, welche durch die
Erschließung neuer Märkte oder auch Werbung mit freien Projekten
erzielt werden sollen. Andererseits kann der finanzielle Vorteil der
Unternehmen aber auch in einer Umwegrentabilität liegen. Die Qualitätssteigerung der eigenen Produkte durch Rückfluss des von Dritten
eingebrachten Expertenwissens („return on invested know how“)
oder eine Effizienzsteigerung durch Verbesserung der intern eingesetzten Software sind durchaus ökonomische Faktoren, die die eigene Marktstellung positiv beeinflussen können164. Erneut ist auch das
Einsparungspotenzial beim Einsatz freier Software im EmbeddedBereich zu beachten.
162
Vgl. Koch/CR 2000, S.280; Jaeger/Metzger, GRUR Int. 1999, S.841; ähnlich ist
die Interessenlage vieler Hobby- und Profiprogrammierer auch bei der Freewareentwicklung, vgl. Marly, Rn. 285f.
163
Vgl. Jakob, S.80f.; Stickelbrock/ZGS 2003, S.372.
164
Vgl. Sester/CR 2000, S.799.
31
Auch seitens der Distributoren sind gegenüber der überwiegend
nichtkommerziellen Motivation der Entwicklergemeinschaft eindeutige wirtschaftliche Zielsetzungen zu konstatieren165. So bieten sie
kommerzielle Dienstleistungen und Komplettpakete an, die wiederum
den Interessen ihrer Klientel gerecht werden sollen. Diesem aus einfachen Nutzern oder Unternehmen bestehende Kundenkreis ist weniger an den besonderen Eigenschaften freier Software gelegen,
sondern er erwartet in erster Linie ein funktionierendes, lauffertiges
System und verspricht sich durch den Einsatz von Open Source
Software vor allem Kosteneinsparungen166.
Nicht zuletzt dient auch die individuelle Software-Entwicklung in den
geschilderten Fällen dem Broterwerb und ist daher zuvorderst von
Geschäftsinteressen motiviert.
D. Kompabilität mit deutschem Recht
Unklar ist, wie sich das aufgezeigte Konzept hinsichtlich seiner tatsächlichen und rechtlichen Eigenschaften und Besonderheiten nach
der deutschen Rechtsordnung darstellt. Von spezieller Bedeutung
im Hinblick auf die Frage der Gewährleistung und Haftung ist vor
allem die rechtliche Beurteilung der absolute Haftungs- und Gewährleistungsausschluss der §§ 11, 12 GPL.
I. Anwendbarkeit des deutschen Rechts
Voraussetzung für die Beurteilung der Vereinbarkeit der GPL mit
dem deutschen Vertrags- und Haftungsrecht ist die generelle Anwendbarkeit deutschen Rechts auf die GPL. Auch ein in Deutschland
angerufenes und mit derartigen Rechtsfragen beauftragtes Gericht
müsste zunächst prüfen, welche nationale Rechtsordnung bezüglich
des Sachverhalts Anwendung findet, bevor es zur Beurteilung der
165
Vgl. Grützmacher/ITRB 2002, S.85; Stickelbrock/ZGS 2003, S.372; Grzeszick/MMR 2000, S.416.
Eine wichtige Ausnahme stellen jedoch nichtkommerzielle Distributionen (z.B. das
Debian Projekt) dar.
166
Vgl. Koch/CR 2000, S.280; Schumann/DSB 2003, S.10; Stickelbrock/ZGS
2003, S.372, dort FN 47.
32
Rechtslage schreitet167. Es muss sich dabei nicht zwangsläufig um
deutsches Recht handeln, vielmehr sind auch vor hiesigen Gerichten
Prozesse nach verschiedenen nationalen Rechtsordnungen denkbar168.
Im Fall von GPL-Software könnte die Anwendung deutschen Rechts
aus zwei Gründen fraglich sein:
Zunächst ist die GPL unter US-amerikanischem Urheber- und Vertragsrecht entstanden und wurde in englischer Sprache formuliert169.
Somit ist sie auf die durchaus abweichenden rechtlichen Voraussetzungen des amerikanischen Vertragsrechts abgestimmt, wie insbesondere der Gewährleistungs- und Haftungsausschluss zeigt170.
Auch im amerikanischen Copyrightsystem bestehen erhebliche Unterschiede zum deutschen Urheberrecht. Dort ist nach der sog.
Work-made-for-hire-Doktrin dasjenige Unternehmen Inhaber des
Copyrights, welches den Programmierer beschäftigt, während im
kontinentaleuropäischen Urheberrechtssystem immer der Programmierer selbst der Urheber bleibt171.
Des Weiteren entsteht freie Software oftmals in Open-SourceProjekten durch ein weltweites Programmierernetzwerk, wodurch der
Sachlage zusätzlich eine internationale Komponente beigemischt
wird.
Es handelt sich folglich nicht um ein rein deutsches Phänomen und
es erscheint zumindest grundsätzlich möglich, dass amerikanisches
Recht oder das Recht anderer beteiligter Staaten zur Anwendung
kommen könnte172.
1. Kollisionsrecht
Die Frage des einschlägigen Rechts bei derartigen grenzüberschreitenden Vorgängen bestimmt sich nach dem internationalen Privat167
Vgl. Rauscher, S.3.
168
Vgl. Jaeger/Metzger, OSS, S.89, 93.
169
Vgl. Schiffner, S.108; Deike/CR 2003, S.11.
170
Vgl. Deike/CR 2003, S.11; Jaeger/Linux-Mag. 2000.
171
Vgl. M/S, Haberstrumpf, § 69b, Rn.21; Jaeger/Metzger, OSS, S.88; Stickelbrock/ZGS 2003, S.372, dort FN 48; Deike/CR 2003, S.17.
172
Vgl. Deike/CR 2003, S.11.
33
recht (IPR) oder auch Kollisionsrecht des Staates, bei dessen Gerichtsbarkeit der Rechtsschutz begehrt wird173. Im IPR legt ein Staat
selbst fest, unter welchen Voraussetzungen im Falle mehrerer konkurrierender Rechtsordnungen seine nationale Rechtsordnung Anwendung finden soll174. Das IPR selbst ist demnach innerstaatliches
und kein internationales Recht, auch wenn der Staat bei dessen
Normierung im Rahmen gewisser völkerrechtlicher Abkommen gebunden ist175. Die Bundesrepublik Deutschland hat von diesem
Recht vor allem in den Art. 3 ff. EGBGB Gebrauch gemacht, welche
nichtabschließend Regelungen des deutschen IPR enthalten.
2. Vertragsstatut und Territorialitätsprinzip
Wie bereits gezeigt, stellt die GPL eine Einräumung eines einfaches
Nutzungsrechts gem. § 31 Abs. 1, 2 UrhG an jedermann dar. Es handelt sich mithin um eine urhebervertragsrechtliche Abrede, die ein
urheberrechtliches
Verpflichtungsgeschäft
darstellt176.
Für
das
Urheberrecht finden sich in den Bestimmungen des EGBGB jedoch
keine einschlägigen Vorschriften. Auch das UrhG selbst trifft keine
Anordnung über die Anwendbarkeit deutschen Rechts bei internationalen Streitigkeiten.
Zu beachten ist jedoch, dass dieses Verpflichtungsgeschäft nach
dem deutschen Abstraktionsprinzip streng von der urheberrechtlichen Verfügung zu unterscheiden ist177. Während diese in Ermangelung einer eindeutigen Zuordnung durch das EGBGB oder das
UrhG dem sog. Territorialitäts- und Schutzlandprinzip unterfällt178,
173
Vgl. Kropholler, § 3 II, S.19.
174
Vgl. Palandt/Heldrich, 3 EGBGB, Rn.2.
175
Vgl. Jaeger/Metzger, OSS, S.89; Palandt/Heldrich, 3 EGBGB, Rn.6.
176
Vgl. Omsels/FS Hertin, S.147.
177
Vgl. Schiffner, S.109; Deike/CR 2003, S.11; Jaeger/Metzger, GRUR Int. 1999,
S.842.
178
Hiernach bestimmt sich die Frage der anwendbaren Rechtsordnung danach, für
welchen Staat urheberrechtlicher Schutz gesucht wird, da die Wirkung der Immaterialgüterrechte auf das Gebiet des Staates beschränkt ist, der diese individuell
verleiht oder anerkennt, vgl. BGH GRUR Int. 1998, 427 (429), Urt. v. 2.10.1997;
M/S, Haberstrumpf, Vor §§ 69a ff., Rn.28ff.
Die Geltung dieses Grundsatzes ergibt sich aus der Anwendung des Prinzips der
urheberrechtlichen Inländerbehandlung gem. Art. 5 Abs. 1 der Revidierten Berner
Übereinkunft (RBÜ), vgl. Schiffner, S.108f.
34
werden nach internationalem Urhebervertragsrecht derartige Lizenzverträge über Urheberrechte – nach deutscher Terminologie also
Verpflichtungsgeschäfte – dem sog. Vertragsstatut untergeordnet179.
Hiernach bestimmt sich die Frage des anwendbaren nationalen
Rechts nach dem zwischen den Parteien geschlossenen Vertrag. Im
deutschen Kollisionsrecht hat das Vertragsstatut in den Art. 27, 28
EGBGB seinen Niederschlag gefunden.
a. Art. 27 EGBGB
Art. 27 EGBGB kodifiziert den Grundsatz der Parteiautonomie180.
Hiernach ist das anzuwendende Recht frei wählbar. Die Parteien
können daher generell selbst darüber bestimmen, welcher Rechtsordnung ihre Übereinkunft unterstellt werden soll181. Es ist daher
festzustellen, ob durch die Vereinbarung der GPL eine solche
Rechtswahl getroffen wurde.
Eine ausdrückliche Rechtswahlklausel enthält die GPL nicht182. Es ist
jedoch auch möglich, konkludent eine Abrede über das anzuwendende Recht zu treffen183. Teilweise tauchen in der Literatur Überlegungen auf, die eine solche stillschweigende Wahl amerikanischen
Rechts nach Art. 27 Abs. 1 S. 2 EGBGB aus den Umständen des
Falles durch die Verwendung der englischen Sprache oder die Entstehungsgeschichte der GPL in Betracht ziehen184. Eine solche
Rechtswahl muss sich jedoch mit hinreichender Bestimmtheit aus
dem Vertrag entnehmen lassen, und gerade im Fall der Weltsprache
Englisch kann dies nur angenommen werden, wenn weitere Anhaltspunkte
hinzukommen185.
Da
die
GPL
aber
lediglich
als
Mustervertragstext entworfen ist und außerdem in den §§ 11 bzw. 12
179
Vgl. Deike/CR 2003, S.11; Jaeger/Metzger, OSS, S.92f.
180
Vgl. Palandt/Heldrich, 27 EGBGB, Rn.1
181
Vgl. Schiffner, S.109; Deike/CR 2003, S.11; Jaeger/Metzger, GRUR Int. 1999,
S.842.
182
Im Gegensatz dazu ist dies beispielweise bei der MPL (Art.11)
http://www.mozilla.org/MPL/MPL-1.1.html oder der IBM Public License (Art.7)
http://www.opensource.org/licenses/ibmpl.php der Fall, die eine Rechtswahlklausel
zugunsten US-amerikanischen Rechts beinhalten.
183
Vgl. Palandt/Heldrich, 27 EGBGB, Rn.5; F/N, Nordemann, Vor §120, Rn.5.
184
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.842, dort FN 49; Deike/CR 2003, S.11;
Weber/FS Honsell, S.49.
185
Vgl. F/N, Nordemann, Vor §120, Rn.5; Jaeger/Metzger, OSS, S.147.
35
tragstext entworfen ist und außerdem in den §§ 11 bzw. 12 GPL
ausdrückliche Vorbehalte zu Gunsten des „anwendbaren Rechts“
enthalten sind186, ist gerade ein gewisser Kompatibilitätswille zu verschiedenen nationalen Rechtsordnungen zu erkennen187. Eine
Rechtswahl nach Art. 27 EGBGB kann daher tatsächlich nicht vorliegen.
b. Art. 28 EGBGB
Wird eine Rechtswahl durch den Vertrag nicht getroffen, so bestimmt
sich das anzuwendende Recht nach Art. 28 EGBGB grundsätzlich
danach, mit welchem Staat der Lizenzvertrag die engsten Verbindungen aufweist188. Nach der Vermutungsregel des Art. 28 Abs. 2
EGBGB ist dies derjenige Ort, an dem die Vertragspartei, welche die
charakteristische Leistung erbringen soll, ihren gewöhnlichen Aufenthaltsort hat. Die charakteristische Leistung ist diejenige, die dem
Vertrag seine rechtliche und wirtschaftliche Eigenart verleiht und ihn
gegen andere Vertragstypen abgrenzbar macht189.
In der Regel liegt bei sog. Lizenzverträgen190 der Schwerpunkt der
Leistung beim Lizenzgeber durch Einräumung der Nutzungsrechte
am Programm191. Dies kann jedoch dann anders zu bewerten sein,
wenn den Lizenznehmer besondere Ausübungspflichten treffen192. In
diesem Fall dürfte die charakteristische Leistung in der Ausübung der
Lizenz liegen - mit der Folge, dass in einer solchen Konstellation das
Recht des Staates, aus dem der Lizenznehmer kommt, anwendbar
sein sollte193. Auch die GPL knüpft die Einräumung des Nutzungs186
Vgl. die Beschränkungsklauseln des Gewährleistungs- und Haftungsausschlusses in § 11 GPL bzw. § 12 GPL: “to the extend permitted by applicable law”/“unless
required by applicable law”.
187
Vgl. Schanze/JITE 1993, S.122; Sester/CR 2000, S.802; Deike/CR 2003, S.11.
188
189
Vgl. Palandt/Heldrich, 28 EGBGB, Rn.3; F/N, Nordemann, Vor §120, Rn.6.
190
D.h. hier allgemein bei Verträgen über Einräumung von urheberrechtlichen Nutzungsrechten. Näheres zum Begriff des Lizenzvertrages im Folgenden unter E. I.
3. a. Lizenzvertrag.
191
Vgl. Spindler/VSI, S.67; Deike/CR 2003, S.12.
192
Vgl. BGH GRUR 1960, 447 (448) Urt.v. 29.03.1960; BGH GRUR 1980, 227
(230), Urt.v. 7.12.1979.
193
Vgl. Ullrich/Körner, Körner, Rn. 343; F/N, Nordemann, Vor §120, Rn.6.
36
rechts an jene Bedingungen, die sie im Copyleft-Prinzip statuiert194.
Allerdings bleibt es dem Nutzer überlassen, wie er die Software nutzt
und inwieweit ihn die Verpflichtungen aus § 2 b GPL treffen, da diese
erst bei Bearbeitung und Veröffentlichung des Programms eintreten195. Bei einfacher Benutzung des Programms oder Modifikation
lediglich für den privaten Gebrauch treffen ihn diese Verbindlichkeiten nicht196. Man wird daher nicht von besonderen Ausübungspflichten seitens des Nutzers ausgehen können. Es bleibt damit dabei,
dass die charakteristische Leistung die Einräumung der Nutzungsrechte ist und damit prinzipiell das Recht am Sitz des Urhebers
gilt197.
c. Art. 29 EGBGB
Diese Grundsätze werden jedoch durch die Regel des Art. 29
EGBGB für sog. „Verbraucherverträge“ wieder eingeschränkt. Demnach darf eine Rechtswahl bei Verträgen über die Lieferung beweglicher Sachen oder Dienstleistungen zu privaten Zwecken nicht dazu
führen, dass dem Verbraucher der Schutz durch zwingende
Verbraucherschutzregelungen seines Heimatstaates entzogen wird.
Wurde keine Rechtswahl getroffen, so bestimmt Art. 29 Abs. 2
EGBGB, dass das Recht des Staates gelten soll, an dem der
Verbraucher seinen gewöhnlichen Aufenthaltsort hat. Der Verbraucherbegriff ist in Art. 29 Abs. 1 EGBGB legaldefiniert und weitgehend
inhaltsgleich mit § 13 BGB. Die Vorschrift kommt auch bei Vertragsschlüssen, die ausschließlich zwischen Verbrauchern getätigt werden, zur Anwendung, wenn der Vertrag nach einer der unter den in
Art. 29 Abs. 1 Nr. 1 bis 3 EGBGB genannten Fallkonstellationen zu
Stande gekommen ist198.
194
Vgl. dazu oben unter B. II. 2. Das „Copyleft“-Prinzip.
195
Vgl. Jaeger/Metzger, OSS, S.39; Wuermeling/Deike, CR 2003, S.87.
196
Vgl. hierzu auch Moglen, S.2: “The license does not require anyone to accept it
in order to acquire, install, use, inspect, or even experimentally modify GPL’d software.“
197
Vgl. Spindler/VSI, S.67; Deike/CR 2003, S.12.
198
Vgl. Deike/CR 2003, S.12; Palandt/Heldrich, 29 EGBGB, Rn.3.
37
Eine mögliche Gestaltung ist hiernach, dass dem Vertragsschluss ein
ausdrückliches Angebot im Aufenthaltsstaat des Verbrauchers vorausgegangen ist. Das Angebot auf einer Website ist hierbei ausreichend, da sich das Internet als weltweites wirkendes Medium grundsätzlich auch an den Aufenthaltsstaat des Verbrauchers richtet199.
Etwas anderes gilt nur dann, wenn der Anbieter dieses Land ausdrücklich von seinem Angebot ausgenommen hat. Dies kann beispielsweise auch dadurch geschehen, dass der Urheber bestimmte
nationale Nutzungsbeschränkungen seines Programms vorsieht, die
nach § 8 GPL ausdrücklich zum Schutz vor Klagen und Ansprüchen
wegen Patent- oder Urheberrechtsverletzungen in einzelnen Ländern
gestattet sind200.
Erwirbt ein Verbraucher von Deutschland aus Open Source Software
daher im Wege des Downloads oder auf einem Datenträger durch
den Versandhandel über das Internet, so ist in der Regel von einem
Angebot auch in Deutschland auszugehen.
Weiterhin setzt Art. 29 EGBGB die Lieferung beweglicher Sachen
oder die Erbringung von Dienstleistungen voraus. Beim Versand von
Datenträgern liegt daher die Lieferung einer beweglichen Sache vor.
Fraglich ist jedoch, wie es sich verhält, wenn der Verbraucher die
Software lediglich in Form von Bits und Bytes auf seinen Rechner
herunterlädt, eine körperliche Fixierung mithin nicht gegeben ist. Ob
Software als eine bewegliche Sache angesehen werden kann oder
nicht, ist im deutschen Recht noch immer umstritten201. Es ist jedoch
zu beachten, dass die Auslegung von Art. 29 EGBGB nach Art. 36
EGBGB autonom, also unabhängig von der deutschen Rechtsordnung, zu erfolgen hat202. Art. 29 EGBGB basiert auf Art. 18 des Eu199
Vgl. Mankowski/MMR 2000, S.22; Palandt/Heldrich, 29 EGBGB, Rn.5; Ulmer/Brandner/Hensen/Schmidt, §12a.F., Rn.11.; Jaeger/Linux-Mag. 2000.
200
Vgl. Deike/CR 2003, S.12; Palandt/Heldrich, 29 EGBGB, Rn.5.
Siehe auch § 8 GPL: „If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is
permitted only in or among countries not thus excluded.”
201
Zum Streitstand ausführlich Marly, Rn.32ff.
202
38
ropäischen Schuldvertragsübereinkommen (EVÜ)203 und soll hiernach in den Vertragsstaaten einheitlich ausgelegt und angewandt
werden. Unabhängig von der Streitfrage zur Einordnung von Software unter den Sachbegriff kann daher insbesondere auf den
Schutzzweck des Art. 29 EGBGB Bezug genommen werden204.
Hiernach erscheint es nicht ersichtlich, warum zwingende Bestimmungen des Verbraucherschutzes beim Erwerb von Software ausgenommen werden sollen, und zwar unabhängig davon, ob diese
Software auf einem Datenträger fixiert oder körperlos per Download
erworben wird. Ein Grund für eine Besserstellung des Erwerbers von
Software auf einem Datenträger ist nicht gegeben205. Außerdem lässt
Art. 29 EGBGB erkennen, dass der gleiche Schutz auch dann greifen
soll, wenn der Verbraucher Dienstleistungen in Anspruch nimmt. Auf
eine körperliche Fixierung des Vertragsgegenstands kann es daher
nicht ankommen.
Grundsätzlich wird daher beim Erwerb von Open Source Software
durch einen deutschen Verbraucher auch deutsches Recht anzuwenden sein206. Dies betrifft sowohl die Fälle des Downloads von
Software aus Quellen der Entwicklergemeinschaft oder von Distributionen, als auch bei der Erstehung von Datenträgern aus dem Ausland, etwa aus dem E-Commerce-Angebot ausländischer Distributoren. Werden weitere Dienstleistungen oder Angebote der Distributoren in Anspruch genommen, wie z.B. die Lieferung von Begleitmaterialien oder Supports, können auch weitere Vertragsverhältnisse mit
dem Softwaregeber in verschiedener Form vorliegen, die vom Anwendungsbereich des Art. 29 EGBGB jedoch ebenso umfasst
sind207.
203
Römisches Übereinkommen über das auf vertragliche Schuldverhältnisse anzuwendende Recht vom 19.6.1980, vgl. BGBl. II, 1986, S.809.
204
Vgl. Spindler/VSI, S.69; Deike/CR 2003, S.12; Schiffner, S.177f.
205
206
So auch Spindler/VSI, S.69; Deike/CR 2003, S.12; Jaeger/Metzger, OSS, S.147
207
Vgl. hierzu die detaillierte Einordnung der Vertragsverhältnisse im Umfeld von
OSS, unten E. I. Vertragsrechtliche Tysierung.
39
Diese Regel greift jedoch nicht ein, wenn Unternehmer oder öffentliche Körperschaften Open Source Software aus dem Internet oder
von einem ausländischen Distributor erwerben208. Hierin mag für diese Erwerber ein globales Rechtsanwendungsrisiko liegen, einer ausländischen Rechtsordnung unterworfen zu sein209. Hieraus kann je
nach anwendbarer Rechtsordnung ein deutlich niedrigeres Schutzniveau bestehen. Fundamentale Prinzipien der deutschen Rechtsordnung, wie sie insbesondere von §§ 138, 276 Abs. 3 BGB statuiert
werden, können jedoch auch in diesen Fällen nicht außer Acht gelassen werden. Diesbezüglich setzt sich der Vorbehalt des ordre
public gem. Art. 6 EGBGB auch gegen ein ausländisches Vertragsstatut durch und bietet so ein Mindestschutzniveau210.
Beim rein inländischen Rechtsverkehr im Umfeld von freier Software
bestehen an der Anwendbarkeit deutschen Rechts keine Zweifel.
II. AGB-Kontrolle
Von einigen Ausnahmefällen abgesehen, wird daher grundsätzlich
deutsches Recht zur Anwendung kommen, sodass die GPL einer
Kontrolle durch das Recht zur Einbeziehung und Wirksamkeit von
allgemeinen Geschäftsbedingungen (AGB) unterzogen werden kann.
1. Allgemeine Geschäftsbedingungen
Die GPL ist ein für eine Vielzahl von Anwendungsfällen und vom jeweiligen Nutzer zu akzeptierender Mustervertrag. Eine Modifikation
ihres Inhalts verbietet die Lizenz ausdrücklich, sodass grundsätzlich
Individualabreden nicht in Betracht kommen211. Vielmehr muss der
Nutzer die GPL bei Vertragsschluss ohne Verhandlungsmöglichkeit
akzeptieren. Es handelt sich daher bei der GPL um allgemeine Geschäftsbedingungen i.S.v. § 305 Abs. 1 BGB212.
208
Vgl. Deike/CR 2003, S.12f.; Stickelbrock/ZGS 2003, S.370; Wuermeling/Deike,
CR 2003, S.88.
209
Vgl. Stickelbrock/ZGS 2003, S.370; Spindler/VSI, S.79.
210
Vgl. Spindler/VSI, S.86; Sester/CR 2000, S.802.
211
Vgl. Copyright-Vermerk gleich unterhalb der Überschrift. Dies gilt jedoch nicht
für Modifikationen im Bereich der Gewährleistung und Haftung; vgl. hierzu § 1 Abs.
2 GPL und unten D. II. 4. d. Rechtsfolgen.
212
Vgl. Stickelbrock/ZGS 2003, S.370; Spindler/VSI, S.34; Koch/CR 2000, S.339.
40
2. Einbeziehung bei Vertragsschluss
Für die Wirksamkeit von AGB bedarf es nach § 305 Abs. 2 BGB deren wirksamer Einbeziehung in den Vertrag. Hierzu ist es erforderlich, dass der Verwender bei Vertragsschluss deutlich auf ihre Geltung hinweist und der anderen Vertragspartei die Möglichkeit verschafft, von ihrem Inhalt in zumutbarer Weise Kenntnis zu nehmen.
a. Verwender
Zunächst muss daher ermittelt werden, wer als Verwender der GPL
im Sinne des Gesetzes zu gelten hat. Verwender ist nach § 305 Abs.
1 BGB derjenige, der die vorformulierten Vertragsbedingungen der
anderen Vertragspartei bei Vertragsschluss stellt. Nach der Regelung des § 6 GPL erhält der Nutzer seine Nutzungsrechte immer unmittelbar vom jeweiligen Programmautor, der sein Werk der Lizenz
unterstellt hat; ein Kettenerwerb der Nutzungsrechte von Empfänger
zu Empfänger ist gerade nicht bezweckt.
Erwirbt der Anwender das Programm unmittelbar vom Urheber, stellt
dieser damit unproblematisch die GPL, ist also Verwender der AGB.
Erhält der Nutzer die Software dagegen von einem Dritten (etwa einer unentgeltlich weitergebenden Person oder auch von einem
Händler oder Distributor), so tritt dieser bezüglich der durch die GPL
eingeräumten Nutzungsrechte als Bote oder Vertreter des Urhebers
auf213. Auch in diesem Fall wird die GPL also durch den bzw. die
Urheber gestellt, die damit Verwender der AGB sind.
b. Zumutbare Kenntnisnahme
Von einer zumutbaren Kenntnisnahme der AGB ist auszugehen,
wenn dem Vertragspartner die Möglichkeit verschafft wird, sich vor
dem Vertragsschluss über deren Inhalt und Reichweite zu informieren214.
Wie bereits gesehen, erfolgen Erwerb und Vertrieb von Open Source
Software auf vielen verschiedenen Wegen. In der Praxis werden vor
allem der Download aus dem Internet oder der Erwerb innerhalb ei-
213
Vgl. zum Ganzen oben B. II. 4. Rechtseinräumung durch den Urheber.
214
Vgl. Jaeger/Metzger, OSS, S.149; Schiffner, S.184.
41
nes Distributionspaketes die häufigsten Fälle sein. Beim Download
aus dem Internet ist es grundsätzlich möglich, allgemeine Geschäftsbedingungen mit einzubeziehen215. Der Hinweis auf ihre Geltung muss sich dabei unmittelbar bei der Downloadmöglichkeit befinden und die AGB selbst müssen durch einen Hyperlink zur direkten
und bequemen Einsichtnahme durch den Vertragspartner bereitgestellt werden216. Beim Kauf eines Distributionspakets beim Händler
wären hingegen ein einfacher Aushang oder der Hinweis des Händlers auf die Möglichkeit der Einsichtnahme ausreichend217.
Blickt man jedoch auf die Realität, muss man wohl einräumen, dass
diese Bedingungen zwar im Einzelfall erfüllt sein mögen, man hiervon jedoch nicht generell ausgehen kann. So wird Open Source
Software oftmals von Privatleuten weitergegeben oder auch online
zur Verfügung gestellt, die dem Erwerber nicht regelmäßig Einsicht in
die GPL gewähren. Die GPL sieht zwar vor, dass die Lizenzbedingungen bei der Installation möglichst automatisch angezeigt und im
Folgenden vom Nutzer anerkannt werden können, erlaubt es aber
auch, unter gewissen Umständen lediglich auf die Geltung der Bedingungen hinzuweisen und dem Nutzer die Adresse der FSF zur
Verfügung zu stellen218. Man kann also nicht einmal deren Vorliegen
als unbedingt gegeben voraussetzen. Bieten schon die sog. „Clickwrap-“ oder „Enter“-Vereinbarungen innerhalb der Installationsroutine
eines Computerprogramms keine zumutbare Möglichkeit der Kenntnisnahme219, so stellt die Möglichkeit, sich die GPL per Post von der
FSF schicken zu lassen, sicherlich erst recht keinen tauglichen Weg
zur Vereinbarung ihrer Lizenzbedingungen dar220. Selbst bei der
215
216
Vgl. Marly, Rn. 234; Hoeren/Sieber, Waldenberg, 13.4, Rn.35ff.
217
Vgl. Palandt/Heinrichs, § 305, Rn.29ff.
218
Vgl. § 2c GPL: “…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…and that users
may redistribute the program under these conditions, and telling the user how to
view a copy of this License…”.
219
Vgl. hierzu Schneider, I, Rn. 6f.; Marly, Rn. 367ff.; Spindler/Wiebe, CR 2003,
S.874.
220
Vgl. Jaeger/Metzger, OSS, S.149; dies., GRUR Int. 1999, S.844.
42
Distribution der SuSE AG, immerhin bedeutendster Distributor auf
dem europäischen Markt, liegt die GPL in ihrer inoffiziellen deutschen Version lediglich innerhalb der Packung bei, sodass auch hier
nicht von einer solchen Kenntnisnahme bei Vertragsschluss ausgegangen werden kann221. Fraglich ist hier auch, ob beim Erwerb von
Hardware mit vorinstallierter Open Source Software der Hinweis auf
die GPL durch den Händler stets erfolgt. Mit Blick auf die tatsächlichen Gegebenheiten des Computerhandels ist dies zumindest zu
bezweifeln.
In der Tat sind die Vertriebswege von GPL-Software zu verschieden,
um präzise Rückschlüsse auf die Umstände des Vertragsschlusses
und damit auf Vorliegen bzw. Kenntnis der GPL zu ziehen222. Man
wird daher zunächst davon ausgehen müssen, dass beim Erwerb
des Programms keine Einbeziehung der GPL erfolgt. Für den Nutzer
bedeutet dies, dass er zunächst mangels vereinbarter Lizenz hinsichtlich der von der GPL eingeräumten weitergehenden Nutzungsrechte zur Bearbeitung und anschließender Weiterverbreitung des
Programms nicht berechtigt wird223. Das Recht zur bloßen Benutzung im Sinne eines reinen Ablaufenlassens erwirbt er jedoch nach
§ 69d UrhG.
3. Einbeziehung bei Modifikation
Grundsätzlich besteht jedoch auch die Möglichkeit einer späteren
Einbeziehung224. Die GPL enthält in ihrem Anhang Anweisungen an
den Programmierer, wie er sein Werk unter die Bedingungen der
GPL zu stellen hat. Demnach soll zu Anfang des Quelltexts stets ein
Hinweis auf die GPL und ihre Geltung eingefügt werden225. Demnach
kann unterstellt werden, dass der Nutzer in der Regel spätestens
dann Kenntnis von der Lizenz erlangt hat, wenn er das Programm
seinen Vorstellungen entsprechend modifiziert. § 5 GPL sieht für den
221
Vgl. Jaeger/Metzger, OSS, S.166; Spindler/VSI, S.36.
222
So auch Omsels/FS Hertin, S.148; Jaeger/Metzger, OSS, S.148.
223
Vgl. Jaeger/Metzger, OSS, S.148. Vgl. auch oben B. II. 1. Rechte des Nutzers.
224
Vgl. Spindler/VSI, S.36; Omsels/FS Hertin, S.151.
225
Vgl. Speichert, 8.Abschn., “Gewährleistungs- und Haftungsausschluss”;
Sester/CR 2000, S.804f.
43
Fall der Veränderung und Weiterverbreitung der Software die automatische konkludente Einverständniserklärung mit den Lizenzbedingungen vor226. Demnach könnte hier ein neuer Vertragsschluss - gerichtet auf Einräumung der weitergehenden Nutzungsrechte - mit
dem Urheber bzw. den Urhebern des Programms geschlossen werden, wobei Letztere auf den Zugang der Annahmeerklärung gem.
§ 151 Abs. 1 BGB verzichten227. Hierdurch könnte die Geltung der
GPL nun wirksam vereinbart worden sein.
a. Englische Fassung
Man kann sich demgegenüber jedoch auf den Standpunkt stellen,
dass lediglich in englischer Sprache vorliegende Vertragsbedingungen dem Grundsatz widersprechen, dass AGB stets verständlich
sein müssen und ausreichende Englischkenntnisse nicht bei jedem
deutschen Verbraucher vorausgesetzt werden können228. Aus diesem Grund könnte hier erneut keine zumutbare Möglichkeit der
Kenntnisnahme gegeben sein. Dieser Einwand lässt sich jedoch
leicht entkräften, wenn man bedenkt, dass derjenige, der sich Zugang zum Quelltext verschafft, in aller Regel ein sachkundiger Programmierer sein wird. Auch alle gängigen Computersprachen basieren auf der englischen Sprache, und gerade im Umfeld von fachkundigen Internet- und Softwarenutzern kann man auch aufgrund der
allgemeinen Verbreitung der Weltsprache Englisch gerade in diesem
Bereich eine solche Kenntnis durchaus unterstellen229.
b. Unzulässige Tatsachenfiktion
Problematischer erscheint es jedoch, dass die automatische Annahme des Lizenzvertrages durch Bearbeitung des Programms eine
nach § 308 Nr.5 BGB unzulässige fingierte Erklärung darstellt, was
226
Vgl. § 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…By modifying or distributing the Program (…), you
indicate your acceptance of this License…”
227
Vgl. Spindler/VSI, S.36; Omsels/FS Hertin, S.154; Jaeger/Metzger, OSS, S.149.
228
So Omsels/FS Hertin, S.149; Grützmacher/ITRB 2002, S.88.
229
Vgl. Jaeger/Metzger, OSS, S.149; Sester/CR 2000, S.805; Schiffner, S.185;
Scherer/Butt, DB 2000, S.1014.
44
die Unwirksamkeit dieser Annahmeklausel zur Folge hat230. Demnach käme es auch bei der Modifikation des Programms nicht zur
wirksamen Vereinbarung der GPL. Es ist jedoch zu beachten, dass
§ 308 Nr. 5 BGB auf den Vertragsschluss selbst keine Anwendung
findet231.
Im Übrigen wurde die GPL ja vorher auch gar nicht zwischen den
Parteien vereinbart, sodass die Klausel, die an das Bearbeiten der
Software hier eine Annahmefiktion knüpft, gar nicht gelten kann232.
Folglich löst sich das diskutierte Problem auf, wird aber sofort durch
ein Neues ersetzt: Nach wie vor ist es durch die Gegenstandslosigkeit des § 5 GPL nicht zur Einbeziehung der GPL-Bedingungen gekommen233.
c. Ergebniskorrektur
Es stellt sich jedoch ernsthaft die Frage, ob dieses Ergebnis Bestand
haben kann. Denn tatsächlich ist es so, dass dem Nutzer durch die
GPL im Wesentlichen über § 69d hinausgehende Rechte gewährt
werden sollen, die er ohne wirksame Vereinbarung der GPL nicht
hätte234. Insbesondere das Recht, ein Werk zu verändern und in diesem Zustand weiterverbreiten zu dürfen, ist das weitest gehende
Recht, welches einem Werknutzer überhaupt eingeräumt werden
kann235. Von der Zulässigkeit eines solchen Vorhabens darf er nicht
per se ausgehen. Vielmehr kann man erwarten, dass er sich über die
Einzelheiten der Lizenz informiert236. Nimmt der Nutzer nun diese
Rechte in Anspruch, so würde es einem venire contra factum proprium entsprechen, sich einerseits darauf zu stützen, dass ihm sein
230
Vgl. Koch/CR 2000, S.339f.; Omsels/FS Hertin, S.152; Deike/CR 2003, S.13;
Spindler/VSI, S.36f.
231
Vgl. BGH WM 1990, 1787 (1788), Urt.v. 31.05.1990; Omsels/FS Hertin, S.152.
232
Vgl. Spindler/VSI, S.37.
233
Vgl. Stickelbrock/ZGS 2003, S.370.
234
Vgl. Spindler/VSI, S.36f.; ders./Wiebe, CR 2003, S.874; Schiffner, S.187.
235
Jakob, S.79.
236
Jaeger/Linux-Mag. 2002.
45
Handeln von der GPL gestattet wurde, andererseits aber ihre Kenntnisnahme wegen Unzumutbarkeit abzustreiten237.
Als weiteres Argument für einen Vertragsschluss zu den Bedingungen der GPL ist außerdem die Tatsache zu betrachten, dass der Teil,
der durch die AGB-Bestimmungen geschützt werden soll, nämlich
der Lizenznehmer, bis hierher gar nicht schutzbedürftig, ja sogar
ausschließlich begünstigt ist238. Solange er das Software-Produkt
einfach benutzt, privat verändert oder unverändert weitervertreibt, ist
er nämlich keinerlei Restriktionen durch die GPL ausgesetzt239. Auch
in der Praxis wird sich daher niemand auf § 305 BGB berufen240.
Es ist mithin spätestens bei Weiterverbreitung der eigenen Modifikationen eine Zustimmung zur GPL und ihren Bedingungen eine wirksame vertragliche Vereinbarung zu sehen.
II. Inhaltskontrolle
Liegt eine Einbeziehung der GPL vor, so steht der Weg zur Inhaltskontrolle der einzelnen Klauseln nach den Vorschriften über die Gültigkeit von AGB gem. §§ 307ff. BGB offen. Grundsätzlich finden diese Regelungen gem. § 310 Abs. 1 BGB auch zur Kontrolle von Verträgen zwischen Unternehmern Anwendung. Allerdings gelten dort
bestimmte Einschränkungen. So gelten insbesondere die Klauselverbote der §§ 308, 309 BGB nicht unmittelbar. Ihnen kommt aber
gem. § 310 Abs.1 S. 2 BGB bei der Inhaltskontrolle von AGB im
Rahmen des § 307 BGB eine gewisse Ausstrahlungswirkung zu241.
Nach der Rechtsprechung des BGH ist demnach ein Indiz für eine
unangemessene Benachteiligung des Vertragspartners auch gegenüber Unternehmern gegeben, wenn eines der Klauselverbote aus
den Katalogen der §§ 308, 309 BGB tatbestandlich vorliegt242. Nach
Maßgabe des § 310 Abs. 1 S. 2, 2. Halbs. BGB kann diese Indizwir237
Vgl. Jaeger/Metzger, OSS, S.149f.; Jakob, S.79; Spindler/VSI, S.38f.
238
Vgl. Jakob, S.78f.
239
Vgl. Jaeger/Metzger, OSS, S.143; Spindler/VSI, S.74; Deike/CR 2003, S.15.
240
Vgl. Grützmacher/ITRB 2002, S.88; Omsels/FS Hertin, S.154.
241
Vgl. Grützmacher/ITRB 2002, S.90; Stickelbrock/ZGS 2003, S.371.
242
46
kung nur noch entkräftet werden, wenn die entsprechende Klausel
ausnahmsweise wegen der Besonderheiten des kaufmännischen
Geschäftsverkehrs als gerechtfertigt anzusehen ist243.
Neuralgischer Punkt der Inhaltskontrolle ist, wie bereits angedeutet,
vor allem der komplette Gewährleistungs- und Haftungsausschluss,
der von §§ 11, 12 GPL vorgesehen ist.
a. § 12 GPL, Haftungsausschluss
Besonders ins Auge sticht auf Anhieb der komplette Haftungsausschluss, den die GPL in § 12 vorsieht. Mit umfasst von dieser Regelung soll daher offensichtlich auch der Ausschluss der Haftung für
grobe Fahrlässigkeit und Vorsatz, sowie für Verletzungen von Körper, Leben und Gesundheit sein. Es besteht mithin ein Widerspruch
zu § 309 Nr. 7 BGB, welcher einen formularmäßigen Ausschluss in
dieser Hinsicht untersagt. Grundsätzlich lässt der BGH eine solche
Haftungsfreizeichnung nur bis zur Grenze leichter Fahrlässigkeit
zu244. Insbesondere die Haftung für vorsätzliches Handeln kann bereits nach § 276 Abs. 3 BGB überhaupt nicht ausgeschlossen werden245. Die Klausel des § 12 GPL ist demnach gegenüber einem
Verbraucher gem. § 309 Nr. 7 BGB und gegenüber einem Unternehmer gem. § 307 Abs. 2 Nr. 1 BGB unwirksam.
b. § 11 GPL, Gewährleistungsausschluss
Aber auch der vollkommene Gewährleistungsausschluss des § 11
GPL stößt hier auf Widerstand. Selbst wenn man in Betracht zieht,
dass die Software in der Praxis oft kostenlos überlassen wird und die
Geltung des Schenkungsrechts annimmt246, so geht dieser Ausschluss zu weit. Indem die Klausel auch die Arglisthaftung bezüglich
aller Rechts- bzw. Sachmängel ausschließt, weicht sie wesentlich
von den Grundgedanken der §§ 523 Abs.1, 524 Abs. 1 BGB ab, und
stellt damit eine unangemessene Benachteiligung des Erwerbers
243
Vgl. BGH NJW 1984, 1750f., Urt.v.8.03.1984 = BGHZ 90, 273 (278); BHG NJW
1988, 1785 (1788), Urt.v. 3.03.1988.
244
BGH NJW 1985, 3016 (3018), Urt.v. 23.2.1984; Feil, S.4; Palandt/Heinrichs, §
309, Rn.40.
245
Stickelbrock/ZGS 2003, S.371; Koch/CR 2000, S.340.
246
Zur vertraglichen Einordnung s. unten E.I. Vertragsrechtliche Typisierung.
47
dar247. Auch § 11 GPL ist daher nach § 307 Abs. 2 Nr.1 BGB unwirksam.
c. Salvatorische Klauseln
§§ 11 und 12 GPL enthalten jeweils eine salvatorische Klausel zu
Gunsten des „anwendbaren Rechts“248. Hiernach sollen die Ausschlüsse von Gewährleistung und Haftung nur insoweit gelten, wie
dies vom jeweils geltenden Recht zugelassen wird. Nach herrschender Auffassung sind solche Klauseln in AGB jedoch deshalb unwirksam, weil sie den Versuch einer grundsätzlich verbotenen geltungserhaltenden Reduktion darstellen249. Zudem muss sich die Rechtslage aufgrund des geschlossenen Vertrages für den Vertragspartner in
zumutbarer Weise erschließen. Ist ihm die Ermittlung dieser nur mithilfe weiterer Quellen, wie der nationalen Rechtsordnung, möglich,
so kann von einer zumutbaren Kenntnisnahme i.S.v. § 305 Abs. 2
BGB nicht ausgegangen werden250.
Vereinzelt wird in den Klauseln jedoch ein zulässiger Verweis auf
internationales Recht gesehen, der eine lokalisierte Auslegung der
GPL ermögliche251. Demnach wäre die Haftungs- und Gewährleistungsfreizeichnung dann auf das gesetzliche zulässige Maß zu reduzieren252. Begründet wird diese Auffassung damit, dass es international aktiven Softwareanbietern nicht zumutbar sei, ihre AGB nach
den Besonderheiten der verschiedensten nationalen Rechtsordnungen auszurichten. Dieser Ansicht ist zu widersprechen. Abseits der
grundsätzlichen Einwände gegen eine geltungserhaltende Reduktion
kann angesichts der klaren gesetzlichen Wertung der Bestimmungen
zur Wirksamkeit von AGB auch eine international unklare Rechtslage
nicht zu Lasten des hiernach besonders schutzwürdigen Vertrags-
247
Vgl. Koch/CR 2000, S.340; Jaeger/Metzger, OSS, S.153.
248
Vgl. oben unter D. I. 2. a. Art. 27 EGBGB.
249
Vgl. Ulmer/Brandner/ Hensen/Schmidt, §9, Rn.51; Jaeger/Metzger, OSS, S.151.
250
Vgl. Omsels/FS Hertin, S.150f.; Deike/CR 2003, S.14; Schiffner, S.242.
251
Vgl. Sester/CR 2000, S.805; Koch/CR 2000, S.340.
252
Vgl. Schiffner, S.242.
48
partners gehen253. Auch international verwandte AGB können daher
vom deutschen Gesetz nicht privilegiert werden. Es bleibt daher bei
der grundsätzlichen Unwirksamkeit der bezeichneten Klauseln254.
d. Rechtsfolgen
Die Rechtsfolgen der festgestellten Verstöße ergeben sich aus § 306
Abs. 2 BGB. Hiernach fallen die für unwirksam befundenen Klauseln
gänzlich weg und sind durch die gesetzlichen Regelungen zu ersetzen. Nach Abs. 1 bleibt der geschlossene Vertrag im Übrigen jedoch
grundsätzlich bestehen. Fraglich ist jedoch, ob unter diesen Voraussetzungen die Schutzvorschrift des § 7 GPL eingreift. Dieser sieht
zum Schutz des „Copyleft“-Systems ein vollständiges Verbot der
Verbreitung eines GPL-Programms vor, wenn die Lizenz nicht in all
ihren Einzelbestimmungen wirksam vereinbart werden kann255. Dies
führte dann zu der fatalen Konsequenz, dass GPL-Software in
Deutschland gar nicht vertrieben werden dürfte256. Wie anhand der in
den salvatorischen Klauseln formulierten Vorbehalte zu Gunsten der
nationalen Rechtsordnung jedoch zu erkennen ist, gilt § 7 GPL nicht
schon für die Unwirksamkeit des Ausschlusses der Mängelrechte
und der Haftung257.
E. Gesetzliche Gewährleistung und Haftung
Es zeigt sich also, dass der Haftungs- und Gewährleistungsausschluss der §§ 11, 12 GPL entweder mangels wirksamer Vereinbarung der GPL (so häufig, wenn beim Erwerb der Software eine zumutbare Kenntnisnahme ihrer Bedingungen nicht angenommen werden kann und auch keine nachträgliche Einbeziehung stattgefunden
hat) oder durch den Wegfall infolge seiner Unwirksamkeit (so, wenn
253
Vgl. Omsels/FS Hertin, S.150f.; Deike/CR 2003, S.14.
254
Vgl. Grützmacher/ITRB 2002, S.90; Jaeger/Metzger, OSS, S.151.
255
Vgl. § 7 GPL: “… If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all…”
256
Vgl. Omsels/FS Hertin, S. 153.
257
Vgl. Grützmacher/ITRB 2002, S.89.
49
die GPL wirksam bei Vertragsschluss oder durch spätere Modifikation des Programms mit einbezogen wurde) nicht zum Tragen kommt.
Die Haftung bzw. die Gewährleistung beurteilt sich nunmehr nach
den allgemeinen gesetzlichen Regeln. Gerade das Gewährleistungsund Haftungsrecht nimmt stark Bezug auf die zugrundeliegenden
Gegebenheiten. So wird die Frage nach der Haftung auch immer
danach zu beantworten sein, wie die vertraglichen Beziehungen zwischen den betroffenen Personen ausgestaltet sind. Es wird daher für
die aufgeworfene Frage entscheidend sein, die vertragliche Konstellation im Einzelfall herauszuarbeiten.
I. Vertragsrechtliche Typisierung
Fraglich ist deshalb, wie die vorgefundenen praktischen Anwendungsfälle und Erscheinungsformen des Einsatzes von Open Source
Software juristisch erfasst werden können.
Bereits die vertragliche Einordnung von Verträgen über die Überlassung von Standard-Software ist seit jeher hoch umstritten. Insbesondere besteht keine Einigkeit über die Frage, ob Software als Sache
i.S.d. § 90 BGB zu gelten hat oder vielmehr ein Erwerb von Rechten
oder eines sonstigen Immaterialguts vorliegt258. Eine ausführliche
Darstellung dieses Problemkreises würde jedoch deutlich über den
Rahmen dieser Arbeit hinausgehen. Viele Aspekte der allgemein diskutierten Fragen um die vertragsrechtliche Beurteilung von StandardSoftware machen aber auch vor dem Open-Source-Segment nicht
halt und werden daher ebenfalls im Folgenden Beachtung finden
müssen. Man kann zweifellos sagen, dass die vertragsrechtliche
Einordnung von Open Source Software zusätzliche Schwierigkeiten
birgt, die auf ihren besonderen Eigenschaften beruhen. Eine vertragstypologische Einordnung auf der Basis der geschilderten Fallgruppen muss infolgedessen deren individuellen Besonderheiten
gerecht werden sowie im Weiteren auch allgemeine Probleme bei
der Typisierung von Software berücksichtigen.
258
Vgl. die ausführliche Darstellung des Diskussionsstands bei Marly, Rn.32ff.
Schiffner, S.200ff.; Hilty/MMR 2003, S.3ff.
50
In der Literatur werden zu dieser Fragestellung einige Ansätze diskutiert, die jedoch zum Teil sehr konträr zueinander erscheinen. Dieser
Eindruck mag auch teilweise deshalb entstehen, weil es manchmal
an der deutlichen Bezugnahme auf die jeweilige Fallkonstellation
fehlt. Im Wesentlichen lassen sich bei den bestehenden Vorschlägen
zwei Hauptströmungen ausmachen.
So wird einerseits für eine Einordnung unter veräußerungsvertragliche Konzepte argumentiert und andererseits für die Zugrundelegung kooperativer gesellschaftsrechtlicher Konzeptionen plädiert.
Neben diesen Hauptströmungen bestehen jedoch auch weitere alternative Ansätze.
1. Veräußerungsvertragliche Konzepte
Bei der Überlassung von Software durch Veräußerungsgeschäft ist
grundsätzlich die Einräumung der urheberrechtlichen Nutzungsrechte von dem schuldrechtlichen Erwerbsgrund, dem Erwerb der Software als solcher, zu trennen259. Beide Elemente stellen jeweils einen
selbstständigen Vertragsgegenstand dar und es liegen daher bei genauer Betrachtung zwei Rechtsgeschäfte vor.
Auch beim Erwerb von Open Source Software stellt sich die Sachlage nicht anders dar. Insbesondere dadurch, dass § 6 GPL den Erwerb der Nutzungsrecht unmittelbar vom Urheber vorsieht, liegen
oftmals Vertragsbeziehungen zwischen drei oder mehr Personen vor,
sodass die Verhältnisse zusätzlich an Komplexität gewinnen. Demnach ist auch hier eine differenzierte Betrachtung zwischen beiden
Vertragsgegenständen notwendig, die bei allen gängigen Ansätzen
berücksichtigt werden muss260.
a. Schenkung
Teilweise wird die Überlassung von Open Source Software als
Schenkung nach § 516 Abs. 1 BGB betrachtet. Grundlage dieser
Ansicht ist die oftmals völlig kostenfreie Überlassung der Software
259
Vgl. Spindler/VSI, S70; Juncker/Benecke, Rn.161
260
Vgl. Spindler/VSI, S.72; Jaeger/Metzger, OSS, S.138.
51
und der Nutzungsrechte261. Nach den festgelegten Fallgruppen ist
dies beispielsweise beim Austausch der Software innerhalb der Entwicklergemeinschaft über das Internet oder beim Download der
Software aus dem zentralen Repository eines Open-Source-Projekts
gängige Praxis, kann aber auch bei kostenloser Übergabe eines Datenträgers der Fall sein262.
Das Vorliegen einer Schenkung setzt nach § 516 BGB die Bereicherung des Beschenkten durch eine unentgeltliche Zuwendung des
Schenkers aus dessen Vermögen voraus.
1.) Zuwendung
Es muss also zunächst ein Vermögensbestandteil hingegeben werden. Dieses Merkmal ist insbesondere bei der Übertragung von Sachen oder Rechten erfüllt263. Wenn der Urheber dem Nutzer das einfache Nutzungsrecht an der Software gem. §§ 398, 413 BGB unentgeltlich überträgt, könnte darin also eine Schenkung liegen264.
Komplizierter gestaltet sich die Prüfung dieses Tatbestandsmerkmals
jedoch hinsichtlich der Software selbst. Anders als bewegliche Sachen kann Software verlustfrei kopiert werden, ohne dass der Übergebende seinen Sachbesitz aufgeben muss265. Dies passiert insbesondere dann, wenn die Software in unverkörperter Form im Wege
des Down- oder Uploads übertragen wird. Für das Verfügungsgeschäft bedeutet dies, dass eine „klassische“ Übergabe, wie von
§ 929 S. 1 BGB für den Sachkauf vorgesehen, nicht stattfinden
kann266.
Auf die rechtliche Qualifizierung von Software als Sache kann es hier
jedoch nicht ankommen, da die endgültige Überlassung des Vermögensgegenstandes Software an den Erwerber im Vordergrund der
Transaktion steht. Dieser wirtschaftliche Zweck wird durch Übergabe
261
Vgl. Jaeger/Metzger, GRUR Int. 1999, S. 847; dies., OSS, S.138; Spindler/VSI,
S.73ff.; Jakob, S.78; Deike/CR 2003, S.14.
262
Vgl. im Einzelnen dazu oben unter C. I. 1. Entwicklergemeinschaft.
263
Vgl. Palandt/Weidenkaff, § 516, Rn.5.
264
Vgl dazu oben B. II. 4. Rechtseinräumung durch den Urheber.
265
Vgl. Sester/CR 2000, S.799f.
266
Jaeger/Metzger, OSS, S.140.
52
des auf einen Datenträger kopierten Programms oder durch unmittelbare Online-Übertragung auf dessen Festplatte gleichermaßen
erreicht. Alleine die unterschiedliche technische Übertragungsweise
kann eine andere rechtliche Behandlung nicht rechtfertigen267. Dementsprechend wendete auch der BGH bereits unter Geltung des alten
Schuldrechts in ständiger Rechtsprechung die Vorschriften über die
Sachübergabe zumindest analog an268. Software konnte damit nach
§ 929 S. 1 BGB analog wie eine Sache übertragen werden.
Diese Überlegungen werden neuerdings zudem von § 453 Abs. 1
BGB n.F. gestützt, der eine systematische Gleichstellung des
Rechts- und Sachkaufes bewirkt269. Ausdrücklich sind hiernach beim
Kauf von Rechten und sonstigen Gegenständen die Vorschriften
über den Sachkauf entsprechend anzuwenden. Software kann demnach zumindest als sonstiger Gegenstand Objekt eines Kaufvertrages sein270. Gleichermaßen kann sie damit auch Gegenstand einer Zuwendung nach § 516 Abs. 1 BGB sein, da das Schenkungsrecht in § 523 Abs. 2 S.2 BGB auf das Kaufrecht verweist.
2.) Entreicherung
Eine Zuwendung setzt weiterhin eine Entreicherung des Schenkers
„aus seinem Vermögen“ voraus271. Erneut ist hierbei zu unterscheiden:
Hinsichtlich der Nutzungsrechte tritt eine Entreicherung ein, indem
der Urheber sein Werk unter die GPL stellt. Hierdurch räumt er jedem unwiderruflich die Möglichkeit ein, das Programm lizenzgebührenfrei zu erwerben, und verliert so dauerhaft einen urheberrechtlichen Vermögensbestandteil272. Beispielsweise wäre eine spätere
Einräumung von ausschließlichen Nutzungsrechten wegen des von
267
268
Vgl. BGH NJW 1990, 320 (321), Urt.v. 18.10.1989; BGH NJW 1993, 2436
(2437), Urt.v. 14.07.1993.
269
Vgl. Schiffner, S.39f.; Spindler/VSI, S.73; Stichtenoth/K & R 2003, S.107.
270
So zählen die Gesetzesmaterialien zum neuen § 453 BGB explizit zu den sonstigen Gegenständen, vgl. BT-Drucks. 14/6040 v. 14.052001, S.242.
271
Vgl. Palandt/Weidenkaff, § 516, Rn.5.
272
Vgl. Jaeger/Metzger, OSS, S.141; Deike/CR 2003, S.15.
53
§ 33 UrhG zu Gunsten des durch die GPL an jedermann erteilten
einfachen Nutzungsrechts gewährten Sukzessionsschutzes wirkungslos273.
Hinsichtlich der Software als solcher ergeben sich jedoch erneut
Probleme wegen ihrer qualitätsverlustlosen Kopier- und Übertragungsmöglichkeit. So halten Kritiker dieser Auffassung entgegen, die
erforderliche Vermögensminderung trete auf Seiten des Zuwendenden nicht ein274. Abzustellen ist hier jedoch gleichermaßen auf die
wirtschaftliche Betrachtungsweise. Wirtschaftlich stellt die Software
das einzig relevante Vermögensgut dar, ganz gleich, ob sie auf einem Datenträger fixiert ist oder nicht. Dies wird insbesondere auch
durch den mit der Schuldrechtsreform neu eingefügten § 453 Abs. 1
BGB indiziert275. Auch hier rechtfertigten die Unterschiede zwischen
beiden Übertragungsmethoden keine rechtliche Differenzierung276.
Eine Entreicherung liegt daher vor.
3.) Bereicherung
Spiegelbildlich zur Entreicherung des Veräußerers ergibt sich ein
„Plus“ im Vermögen des Nutzers. Die ebenfalls erforderliche Bereicherung beim Beschenkten folgt somit aus der Erlangung der Nutzungsrechte und der Software als solcher.
4.) Unentgeltlichkeit
Letztes und charakteristisches Merkmal einer Schenkung ist die Unentgeltlichkeit der erhaltenen Zuwendung. Diese ist dann gegeben,
wenn die Hingabe des Vermögensgegenstands unabhängig von einer Gegenleistung des Beschenkten erfolgt. Unentgeltlich bedeutet
hier jedoch nicht kostenlos277. Die Gegenleistung kann in irgendeiner
seitens des Erwerbers oder eines Dritten eingegangenen Verpflichtung oder zu bewirkenden Leistung bestehen, wenn diese als Bedin-
273
Vgl. F/N, Hertin, §33 UrhG, Rn.1.
274
Vgl. Sester/CR 2000, S.799f.; Koch/CR 2000, S.335; Weber/FS Honsell, S.53.
275
276
Vgl. Deike/CR 2003, S.15; Marly, Rn.103f.
277
Vgl. Palandt/Weidenkaff, §516, Rn.8.
54
gung für die Zuwendung kausal hiermit verknüpft wird oder im Synallagma steht278.
Im Fall von „Copyleft“-Lizenzen wie der GPL wird in diesem Zusammenhang diskutiert, ob die Bedingungen, die der Nutzer erfüllen
muss, sich möglicherweise als eine solche Gegenleistungspflicht
darstellen279. Schließlich ist die Nichtbeachtung der Pflichten aus
§ 2b GPL gem. § 4 GPL mit dem sofortigen Verlust der Rechte aus
der Lizenz sanktioniert. Es liegt damit die Vermutung nahe, dass eine
Einräumung der Nutzungsrechte nur unter Beachtung dieser Bedingungen gewollt ist.
Betrachtet man die „Copyleft“-Klausel genauer, so erschließt sich,
dass ihre Bedingungen aber erst dann greifen, wenn der Nutzer das
Programm in modifizierter oder unveränderter Form weiterverbreiten
will. Das bloße Ablaufenlassen des Programms sowie das Recht, es
zu kopieren oder für den privaten Gebrauch zu modifizieren, werden
von der GPL mit keinerlei Verpflichtungen oder Restriktionen überzogen280. Diese Rechte erhält der Nutzer unmittelbar mit dem
Vertragsschluss aus der GPL bzw. § 69d UrhG, ohne dass
irgendwelche konditionalen Gegenleistungen zu erbringen wären281.
Es zeigt sich also, dass bei den Verpflichtungen aus § 2b GPL nicht
von
synallagmatischen
Gegenleistungsverpflichtungen
des
Programmerwerbers gesprochen werden kann. Sie stehen mithin
dem Charakter der Unentgeltlichkeit nicht im Wege.
5.) Schenkung mit Auflagen
Weiterhin wird in den GPL-Bedingungen auch vereinzelt eine mit der
Schenkung verbundene Auflage erblickt282. Die Schenkung unter
Auflage nach § 525 Abs. 1 BGB räumt dem Schenker einen schuldrechtlichen Anspruch auf Erfüllung der Auflage gem. § 527 Abs. 1
BGB ein. Deswegen erfordert diese Konstruktion grundsätzlich eine
278
Vgl. BHG NJW 2002, 2469, Urt.v. 17.04.2002; BGH NJW 1951, 268, Urt. v.
10.01.1951.
279
Vgl. Sester/CR 2000, S.799f.; Koch/CR 2000, S.334f.
280
Vgl. Jaeger/Metzger, OSS, S.143; Spindler/VSI, S.74; Deike/CR 2003, S.15.
281
Vgl. oben B. II.1. Rechte des Nutzers.
282
55
notarielle Beurkundung. Unterbleibt diese, wie in der Praxis der
Übertragung von Open Source Software üblich, so ist die Schenkung
formnichtig283.
Ein solcher durchsetzbarer Anspruch liegt bei „Copyleft“-Lizenzen
aber gerade nicht vor. So ordnet § 4 GPL lediglich den automatischen Verlust der Rechte aus der GPL an, zwingt den Benutzer aber
nicht, die eingegangenen Verpflichtungen zu befolgen284. Eine
Schenkung unter Auflagen ist demnach richtigerweise nicht anzunehmen. Zudem wäre auch der Formverstoss gem. § 518 Abs. 2
BGB mit Vollzug der Schenkung, grundsätzlich also mit Einräumung
der Rechte, spätestens aber mit deren Gebrauch geheilt285.
Die kostenlose Übertragung von Open Source Software lässt sich
somit unter das Konzept der Schenkung gem. § 516 BGB subsummieren.
b. Gemischte Verträge
Oftmals kommt es in der Praxis jedoch vor, dass dem Nutzer die
Software nicht komplett kostenlos zur Verfügung gestellt wird, sondern § 1 Abs. 2 GPL entsprechend ein Entgelt für gewisse Dienstleistungen oder Waren erhoben wird. In diesen Fällen wird die Lage
auch von den Vertretern der zuvor geschilderten Auffassung anders
beurteilt.
1.) Distributionen/Software-Vertrieb
In diese Fallgruppe gehört zunächst die Zahlung eines Entgelts für
den Datenträger, aber auch der praktisch häufige Erwerb eines
Distributions-Komplettpakets im Handel oder direkt aus dem Webangebot des Distributors erfolgt zumeist gegen Gebühr286. Hier kann
nicht ausschließlich auf das Schenkungskonzept Bezug genommen
werden, sondern es wird das Hinzutreten gewisser kaufrechtlicher
283
Vgl. Palandt/Weidenkaff, §525, Rn.2.
284
285
286
Vgl. zu weiteren denkbaren Konstellationen kommerzieller Nutzung die Ausführungen oben unter C. I. 2. – 5.; II. 2.
56
Elemente angenommen, die je nach Ausprägung sogar das Vorliegen eines reinen Kaufvertrages nahe legen287.
Grundsätzlich soll es bezüglich der weitergehenden Nutzungsrechte
jedoch weiterhin bei einer Schenkung durch den Urheber bleiben, da
Lizenzgebühren (auch bei selbstentwickelten Programmen) unter
Geltung der GPL nicht gestattet sind. Wird hingegen für den Datenträger ein Entgelt bezahlt, liegt diesbezüglich unzweifelhaft ein Kaufvertrag nach § 433 BGB vor288. Insgesamt handelt es sich dann um
einen sog. Typenkombinationsvertrag oder Mischvertrag aus mehreren verschiedenen vertraglichen Bestandteilen. Dementsprechend
sollen für diese Bestandteile die jeweilig passenden gesetzlichen
Regelungen anwendbar sein289.
In diesem Zusammenhang stellt sich jedoch die Frage, inwieweit
beide Vertragsgegenstände durch einen solchen Typenkombinationsvertrag aufgespaltet werden können. Eine entscheidende Rolle
für die Klassifizierung des Vertrages spielt immer auch die Verkehrsanschauung der betroffenen Kreise290. Für denjenigen, der bei einem
Händler oder Distributor Software gegen Zahlung eines Geldbetrages erwirbt, stellt sich der geschlossene Vertrag zweifellos als einheitlicher Kaufvertrag dar291. Ausnahmen können lediglich dann bestehen, wenn bei den Parteien ausdrücklich Einigkeit über die
Schenkung der Software besteht oder wenn im Falle einer geringen
Schutzgebühr für den Datenträger ein auffälliges Missverhältnis zwischen Marktwert und tatsächlichem Preis besteht292.
Andererseits verschwimmen die Grenzen im Fall der gemeinsamen
Vermarktung von proprietären Eigenprodukten mit freier Software.
Durch die Vermischung der Software ist der Erwerber nicht mehr in
287
Vgl. Deike/CR 2003, S.15; Jaeger/Metzger, OSS, S.156, Stickelbrock/ZGS
2003, S.371; Jakob, S.80.
288
289
Vgl. Siepmann/Jur-PC 1999, Abs.136; Deike/CR 2003, S.15.
290
291
292
Vgl. Stickelbrock/ZGS 2003, S.371; Schiffner, S.223; Siepmann/Jur-PC 1999,
Abs.136.
57
der Lage, eindeutig festzustellen, welche Teile der Software lizenzgebührenfrei sind und für welche das erhobene Entgelt bezahlt wurde293. Je höher in dem erworbenen Software-Paket der Anteil
proprietärer Programme ist, die zusammen mit der freien Software
vermarktet werden, desto drastischer erscheint diese Situation. Je
näher der Erwerbsvertrag seinem Gesamtbild nach einem einheitlichen Kaufvertrag kommt, desto weniger können Lizenzvereinbarung
und Übereignung der Software getrennt werden294. Zur Ermittlung
des bei gemischten Verträgen dieser Art im Einzelfall anzuwendenden Rechts nimmt der BGH unter Berücksichtigung der beiderseitigen Parteiinteressen eine Orientierung am wirtschaftlichen Zweck
ihrer Vereinbarung vor295.
2.) Zusätzliche Dienstleistungen
Erwirbt der Kunde einer Distribution die Software zusammen mit weiteren Produkten, wie Handbüchern und zusätzlichen Dienstleistungen (z.B. Support) im Rahmen eines einheitlichen Vertrags, wird der
Kaufpreis in der Regel deutlich über den reinen Materialkosten liegen296. Aufgrund der Bündelungen der verschiedenen Leistungen
kann dieser Vertrag ebenfalls nur einheitlich betrachtet werden297.
Hier treten zu den kaufvertraglichen Elementen weitere dienstvertragliche Bestandteile298. Der Schwerpunkt wird jeweils nach den im
Vordergrund stehenden Leistungen zu bewerten sein299.
3.) Embedded-Bereich
Ähnlich sieht es auch beim Verkauf von Hardware mit vorinstallierter
Open-Source-Software aus.
293
Vgl. Deike/CR 2003, S.15; Spindler/VSI, S.83.
294
Vgl. Speichert, 9.Abschn. „Gewährleistungs- und Haftungsausschluss“; Spindler/VSI, S.82; Schiffner, S.223; Feil, S.3; Grützmacher/ITRB 2002, S.86.
295
Vgl. BGH NJW 1952, 20 (21), Urt.v 2.10.1951; BGH NJW 1990, 2616 (2620),
Urt. v. 2.07.1990.
296
Vgl. Spindler/VSI, S.84; Schiffner, S.223.
297
298
Vgl. Stickelbrock/ZGS 2003, S.371; Jaeger/Metzger, OSS, S.165.
299
Vgl. Schiffner, S.222; Jaeger/Metzger, OSS, S.165.
58
Hebt der Veräußerer bei Vertragsschluss die besonderen Eigenschaften der aufgespielten Software hervor oder weist er während
des Verkaufsgespräches auf den deutlich geringeren Preis gegenüber gleichwertigen Produkten mit proprietärer Software hin, so kann
eine Einigung der Parteien über eine Schenkung bezüglich der Nutzungsrechte in Betracht kommen300. Im Regelfall tut er dies jedoch
nicht; somit wird demgegenüber nur ein einheitlicher Kaufvertrag
über Hard- und Software, wie im Falle gewöhnlicher OEM-Lizenzen,
anzunehmen sein301.
4.) Software-Entwicklung
Teilweise anders sind die aufgezeigten Beispiele der individuellen
Softwareerstellung zu bewerten302. Zwischen dem Kunden und dem
Softwareentwickler wird hier ein Werkvertrag gem. § 631 BGB über
die Entwicklung eines bestimmten Computerprogramms geschlossen303. Soll diese Software vereinbarungsgemäß unter die GPL gestellt werden, so werden entsprechende Eigenschaften, wie insbesondere Quelloffenheit, schon vertraglich geschuldet304.
Hiervon abzugrenzen sind Werklieferungsverträge, die sich gem.
§ 651 S. 1 BGB nach Kaufrecht beurteilen. Bei diesen tritt der Herstellungsaspekt in den Hintergrund. Primär kommt es auf die Lieferung und somit auf den Verschaffensaspekt der geschuldeten Sachen an305. Anzunehmen ist dies etwa bei einer für eine Vielzahl von
Kunden hergestellten Standardsoftware, deren Entwicklungskosten
auf die Masse der Kunden umgelegt werden. So könnte die Sachlage sein, wenn sich ein Distributor verpflichtet, über den bloßen Verkauf seines Distributionspakets auch die Installation und Konfiguration der Software auf dem Rechner des Kunden vorzunehmen.
300
Vgl Jaeger/Metzger, OSS, S.172.
301
Vgl. Schiffner, S.223; BGH NJW 1990, 3011 (3012), Urt.v. 7.03.1990; zum
OEM-Vertrieb vgl. allgemein Schneider, N, Rn.1ff.
302
Vgl. hierzu die oben dargestellte Beschreibung der Fallgruppen unter C. I. 4.
Software-Entwicklung.
303
Vgl. Siepmann/Jur-PC 1999, Abs.152; Stichtenoth/K & R 2003, S.109; Metzger/Linux-Mag. 2002; Kilian/Heussen, Moritz, § 31, Rn.55ff..
304
305
Vgl. Stichtenoth/K & R 2003, S.109.
59
Für das Verhältnis der beteiligten Personen zu Dritten lassen sich die
bis hierher gezeigten Strukturen zu Grunde legen. So wird der Softwarehersteller das Ergebnis seiner Arbeit Dritten gegenüber durch
Unterstellung unter die GPL im Wege der Schenkung verfügbar machen. Sein Kunde kann die für ihn erstellte Software je nach seinen
eigenen Vorstellungen kommerziell oder nichtkommerziell vertreiben.
Mit Dritten werden dann, je nach Vertragsgestaltung, reine Schenkungs-, Kauf- oder Dienstleistungsverträge oder auch Typenkombinationsverträge vorliegen.
Es zeigt sich, dass die veräußerungsvertragliche Konzeption prinzipiell dazu geeignet ist, die aufgezeigten Fallgruppen juristisch zu erfassen. Dennoch sollen auch die weiteren Ansätze ins Blickfeld gerückt werden.
2. Gesellschaftsvertragliche Konzepte
So wird demgegenüber von Teilen der Literatur in der Überlassung
von Open Source Software ein Vertragsgebilde erblickt, welches am
ehesten dem gesellschaftsrechtlichen Vertragstypus der Gesellschaft
bürgerlichen Rechts (GbR) ähnelt306.
Diese Überlegung wird vor allem damit begründet, dass die Interessenlage innerhalb der Programmierergemeinschaft – vor allem durch
das Hinzutreten großer Unternehmen aus der Computerindustrie –
nicht, wie ursprünglich auf den altruistischen Motiven Stallmans beruhe, sondern von gemeinsamen Wertschöpfungsabsichten durch
den Rückfluss von zusätzlichem Know-how bestimmt sei. Das Konzept des Schenkungsrechts könne angesichts dieser primär wirtschaftlich zu charakterisierenden Interessenkonvergenzen nicht aufrechterhalten werden307.
Grundlegend ist hierbei die Annahme, die Zielsetzung und damit der
Gesellschaftszweck der Entwicklergemeinschaft sei die Entwicklung,
Verbreitung und ständige Verbesserung eines Betriebssystems, welches allen beteiligten Programmierern die „Freiheit“ von einem Mo306
Vgl. Sester/CR 2000, S.801; Weber/FS Honsell, S.54; in Ansätzen auch Jakob,
der jedoch nach Fallgruppen differenziert.
307
Vgl. Jakob, S.80; Weber/FS Honsell, S.55.
60
nopolisten wie Microsoft und damit vor allem Erwerbschancen durch
Anwenderprogramme oder zusätzliche Dienstleistungen sichere308.
In der Tat kann jeder erlaubte Zweck, wie auch der Betrieb eines
nichtkaufmännischen Gewerbes, Gegenstand einer GbR sein309.
Weiter führen die Vertreter dieser Auffassung an, die zudem für die
GbR erforderliche Verpflichtung zur Förderung eines gemeinsamen
Gesellschaftszwecks sei durch die in der GPL vorgesehenen detaillierten Verpflichtungen ausreichend konkretisiert310.
Dieses Argument scheint zumindest zweifelhaft, da der einfache Erwerb freier Software mit keinerlei Verpflichtungen durch die GPL belegt ist311. Problematisch erscheint an dieser Wertung des Weiteren
jedoch auch, dass eine gesellschaftsvertragliche Konstruktion zunächst nur die Verhältnisse der Programmierer untereinander regeln
kann312. Auf der Rechtsfolgenseite, insbesondere bei Gewährleistung
und Haftung, verbleiben hier aufgrund der unüberblickbaren Anzahl
der an solchen offenen Projekten beteiligten Personen Unsicherheiten darüber, wer letztlich nach außen für das gemeinsame Produkt
gerade stehen soll. Dies wird sogar von den Befürwortern dieser Zuordnung eingeräumt313.
Aus diesem Grund wird von Sester bewusst die ausdrückliche Annahme einer GbR vermieden314. Stattdessen sollen für die Haftung
und Gewährleistung maßgeschneiderte Fairnessregeln greifen, die
einerseits auf einer teilweisen Anwendung von gesellschaftsrechtlichen Grundregeln für den isolierten Erwerb der Open-SourceProgramme selbst, sowie andererseits dem Regelungsanspruch der
typisierten Rechtsgeschäfte bezüglich weiterer Beigaben oder Dienste beruhen. Innerhalb der „Gesellschaft“ soll so lediglich nach dem
Maßstab der §§ 708, 277 BGB eine Haftung in Betracht kommen.
308
Vgl. Sester/CR 2000, S.801; Weber/FS Honsell, S.55.
309
Vgl. Palandt/Sprau, §705, Rn.20ff.
310
311
Vgl. Jaeger/Metzger, OSS, S.145; Schiffner, S.223.
312
313
Vgl. Sester/CR 2000, S.801; Weber/FS Honsell, S.55f.
314
61
Die Haftungsgrenze liegt damit minimal im Bereich der bewussten
Fahrlässigkeit. Rechtfertigen soll sich die Anwendung des gesellschaftsrechtlichen Haftungsprivilegs aus der prinzipiellen Risikogeneigtheit innovativer Projekte, wie es die Beteiligung innerhalb einer
Open-Source-Entwicklergemeinschaft ist315.
Von Weber wird andererseits vorgeschlagen, einzelne Elemente des
Gesellschaftsvertrages in Kombination mit Verträgen eigener Art anzuwenden, um auf neue Phänomene, wie die Open-SourceEntwicklung, angemessen reagieren zu können316.
3. Verträge sui generis
Bereits die zuletzt erwähnte Auffassung versucht, vom klassischen
Vertragstypenkonzept des bürgerlichen Rechts Abstand zu nehmen,
und sieht eine gewisse Nähe zu Verträgen eigener Art. Die Bezugnahme auf solche Kontrakte sui generis hat bei der Einordnung von
Softwareüberlassungsverträgen bereits eine gewisse Tradition.
a. Lizenzvertrag
In der Praxis werden Computerprogramme nicht verkauft, sondern
„lizenziert“. Auch die GPL bezeichnet sich selbst als „Lizenz“. Sie
könnte dementsprechend als ein Lizenzvertrag zu betrachten sein.
Der Lizenzvertrag hat die Vereinbarung urheberrechtlicher Befugnisse zum Gegenstand und auch die GPL räumt dem Nutzer ein einfaches Nutzungsrecht i.S.v. § 31 Abs. 1, 2 UrhG ein.
Unklar ist jedoch die exakte dogmatische Einordnung einer solchen
Vereinbarung. So steht eine allgemein anerkannte Umschreibung
des Lizenzvertrages bisher aus317. Einigkeit besteht jedoch darüber,
dass es sich hierbei um einen zum Typenraster des BGB atypischen
Vertrag handelt, der den Rechtsgrund für die Überlassung oder Nutzung eines immateriellen Gutes darstellt318. So wurde früher die Ansicht vertreten, dass der Wille der Parteien hier eben auf eine „Lizen-
315
Vgl. Sester/CR 2000, S.805ff.
316
Vgl. Weber/FS Honsell, S.58.
317
Vgl. Weber/FS Honsell, S.50.
318
Vgl. Marly, Rn.72; Juncker/Benecke, Rn.160; Schiffner, S.231.
62
zierung“ der Software als geistiges Gut gerichtet sei und eben nicht
auf deren Kauf oder Miete319.
Dieser Vertragspraxis steht jedoch eine gefestigte Rechtsprechung
entgegen, die für Fälle der Softwareüberlassung generell nicht dem
lizenzvertraglichen Ansatz folgt. Als solcher Vertrag eigener Art birgt
das Konstrukt erhebliche Rechtsunsicherheiten gerade im Hinblick
auf die rechtlichen Konsequenzen, etwa bezüglich der Haftung und
Gewährleistung. Dementsprechend ortet die Rechtsprechung Lizenzverträge eher im Bereich riskanter Geschäfte, die Unwägbarkeiten hinsichtlich der technischen Ausführbarkeit, Brauchbarkeit oder
wirtschaftlichen Verwertbarkeit etwa eines Patents als geistiges Gut
bergen320. Gerade im Bereich der Standard-Software-Überlassung
bestehen solche Risiken aber nicht. Wegen dieser Sachlage sei ein
Ausweichen auf nicht geregelte Vertragstypen nicht gerechtfertigt321.
Insbesondere durch allgemeine Geschäftsbedingungen (wie die
GPL) könne ein Vertrag nicht abweichend vom gängigen Typenraster
charakterisiert werden322.
Einigkeit besteht zwischen Rechtsprechung und Literatur auch insofern, dass nach dem Grundsatz falsa demonstratio non nocet die
Verwendung bestimmter rechtlicher Begriffe nicht zwingend bedeutet, dass auch die entsprechenden Rechtsnormen zur Anwendung
kommen. Vielmehr sind nach §§ 133, 157 BGB der wirkliche Parteiwille sowie Sinn und Zweck der Vertragsabsprache ausschlaggebend323.
Daraus folgt für die Softwareüberlassung, dass auch dann, wenn die
Parteien ausdrücklich den Begriff Lizenzvertrag bestimmt haben,
Kauf- oder Mietrecht (zumindest analog) anwendbar ist, wenn auch
das Kaufrecht und die Rechte des Käufers durch die zugrundelie319
Vgl. Koch, Rn. 831; Juncker/Benecke, Rn.160.
320
Vgl. BGH GRUR 1961, 27 (28), Urt.v. 5.07.1960; Koch, Rn. 831.
321
Vgl. BGH NJW 1988, 406, (408f.), Urt.v. 4.11.1987; Koch, Rn. 831.
322
Vgl. BGH NJW 1993, 2436 (2437f.), Urt.v. 14.07.1993; BGH CR 1997, 470
(472f.), Urt.v. 4.03.1997.
323
Vgl. Weber/FS Honsell, S.52; Schneider, D, Rn. 167ff.; OLG Düsseldorf NJW
1989, 2627, Urt.v. 9.06.1989; OLG Nürnberg CR 1993, 359, Urt.v. 20.10.1992.
63
gende Lizenzvereinbarung teilweise stark modifiziert – insbesondere
eingeschränkt – werden324.
b. „Know-how“-Vertrag
Ähnliche Schwierigkeiten ergeben sich bei der vereinzelt befürworteten Einordnung der Software-Überlassung als „Know-how-Vertrag“.
Unter dem Stichwort „Überlassung von Software als Preisgabe von
Wissen“ wird so teilweise versucht, einen solchen Vertragstypus zu
begründen325. Auf den ersten Blick erscheint dies gerade in Bezug
auf quelloffene Software durchaus plausibel, weil gerade hier das
eingebrachte „Know-how“ offengelegt und eine gegenseitige Vernetzung des Wissens bezweckt wird326. Es darf jedoch nicht übersehen
werden, dass sich auch hier das Problem stellt, einen solchen nichttypisierten Vertrag mit Leben zu füllen. Gerade die exakte Definition
des „Know-how“-Begriffs bereitet – insbesondere auch angesichts
der weitgehenden Nutzung von Open Source Software auch außerhalb der Entwicklungscommunity - Probleme327. Entsprechend der
für Software-Überlassung als Lizenzvertrag getroffenen Feststellungen wird die Rechtsprechung auch hier einer Umgehung des Kaufoder Mietrechts einen Riegel vorschieben328. Nicht zuletzt bedeutet
auch die Überlassung des Quellcodes nicht notwendig einen „Know-
324
Vgl. Juncker/Benecke, Rn. 161. Diese Überlegung wir i.Ü. auch durch die im
Gesetz mit § 453 Abs. 1 BGB neugetroffene Wertung gestützt, vgl. Schiffner,
S.231, dort FN 858.
Die Einschränkung der Rechte des Käufers geschieht durch eine von Vornherein
durch das Urheberrecht inhaltlich und damit dinglich begrenzte Überlassung des
erworbenen Nutzungsrechts, wie z.B. im Fall von sog. „weichen CPU-Klauseln“,
die es dem Nutzer nicht erlauben, die Software auf mehreren Computern gleichzeitig zu installieren und auszuführen, vgl. Metzger/NJW 2003, S.1994; Schricker/Loewenheim, § 69d, Rn.14. Nach h.M. ist auch bei GPL-Software das Nutzungsrecht von Vornherein dinglich auf die Nutzung innerhalb der GPLBedingungen beschränkt, wie der Heimfall der Nutzungsrechte im Falle einer Lizenzverletzung durch § 4 GPL zum Ausdruck bringt, vgl. Sester/CR 2000, S.797;
Jaeger/Metzger, GRUR 1999, S.843; Grzeszick/MMR 2000, S.415; Spindler/Wiebe, CR 2003, S.874.; a.A. Ahn, S.174.
325
326
So anscheinend auch Marly, Rn.81.
327
Vgl. Schiffner, S.31ff; Koch, Rn.829.
328
Vgl. E. I. 3. a. Lizenzvertrag.
64
how“-Transfer, da zu dessen Verständnis oft mehrtausendseitige
Benutzerdokumentationen erforderlich sind329.
4. Verzicht/Dereliktion
Betrachtet man die GPL, so wird man an verschiedenen Stellen auf
den kompletten Gewährleistungs- und Haftungsausschluss hingewiesen. Es fragt sich deshalb, ob der Autor überhaupt eine Vertragsbeziehung mit jedermann eingehen will, da bei einer solchen in vielen Rechtsordnungen ebenfalls die Möglichkeit der vertraglichen Haftung nicht ausgeschlossen werden kann. Man könnte daher unterstellen, dass der Urheber nicht die Einräumung von Nutzungsrechten an der Software intendiert hatte, als er sie der GPL unterstellte,
sondern eher die Software im Wege einer einseitigen Gestattung
verfügbar machen wollte. Es könnte also ein Verzicht auf die Ausübung seines Urheberrechts vorliegen330. Ähnlich einer Dereliktion
am Sacheigentum nach § 959 BGB gäbe der Urheber sein „geistiges
Eigentum“ auf, sodass das Werk gemeinfrei würde331. Für die Haftung bedeutete dies, das nach deutschem Recht vertragliche Haftungsansprüche sowie Gewährleistungsansprüche seitens der Nutzer von Open Source Software nicht geltend gemacht werden können.
Diese Überlegung stößt jedoch vor dem Hintergrund der monistischen Konzeption des deutschen Urheberrechts auf Bedenken. Im
Gegensatz zur dualistischen Vorstellung vieler ausländischer Urheberrechtsordnungen stehen Vermögens- und Persönlichkeitsrechte
hier nicht selbstständig nebeneinander332. Demnach handelt es sich
beim Urheberrecht um ein einheitliches Recht, dass nicht beliebig
aufgespaltet werden kann. Alle urheberrechtlichen Befugnisse entwachsen grundsätzlich einem Stamm und sind in dem Rahmen ver-
329
Vgl. Koch, Rn.829, der das Beispiel der Quellcode-Überlassung durch Netscape
1998 reflektiert.
330
Vgl. Grützmacher/ITRB 2002, S.89.
331
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.842.
332
Vgl. F/N, Nordemann, §11 UrhG, Rn.2; Ulmer, S.112ff.; Hilty/MMR 2003, S.7.
65
kehrsfähig, wie das Gesetz dies zulässt333. Selbst wenn man - wie
einige Autoren - den Verzicht auf einzelne Verwertungsrechte für
zulässig erachtet, gilt dies nicht für den urheberpersönlichkeitsrechtlichen Kernbereich, der das „Band zwischen Urheber und Werk“
schützt334. So ist auch das Urheberrecht als Ganzes gem. § 29
Abs. 1 UrhG nicht übertragbar. Aus der Unübertragbarkeit des Urheberrechts folgt auch dessen Unverzichtbarkeit335. Eine der Dereliktion
des Sachenrechts vergleichbare völlige Rechtsentäußerung, die
Schaffung eines „herrenlosen“ Urheberrechts, ist nicht möglich336.
Aber auch die GPL legt einen Verzicht auf das Urheberrecht bei genauem Hinsehen nicht nahe. Bereits die Betitelung mit der Bezeichnung „Lizenz“ lässt die Vermutung zu, dass von den Verfassern sehr
wohl der Abschluss eines Vertrages gewollt ist337. Dieser Eindruck
verstärkt sich zudem dadurch, dass die GPL in § 5 eine konkludente
Einverständniserklärung des Nutzers vorsieht, der von den besonderen Rechten Gebrauch macht, die ihm diese Lizenz einräumt338. Das
zuvor durch den Autor abzugebende Angebot ist durch die GPL immer im Raum und kann jederzeit angenommen werden339. Diese
Konstruktion fügt sich in die Vorstellung eines durch schlüssiges
Handeln zustande gekommenen Vertrages.
Nicht zuletzt sieht § 6 GPL für den Fall des Verstoßes den sofortigen
Heimfall der Nutzungsrechte vor. Dies zeigt deutlich, dass man von
333
Besonders zum Ausdruck kommt dies auch durch § 11 UrhG: „Das Urheberrecht schützt den Urheber in seinen geistigen und persönlichen Beziehungen zum
Werk und in der Nutzung des Werkes. Es dient zugleich der Sicherung einer angemessenen Vergütung für die Nutzung des Werkes.“
334
Vgl. F/N, Hertin, Vor § 12 UrhG, Rn.5; Jaeger/Metzger, GRUR Int. 1999, S.842.
Zur Möglichkeit eines solchen Verzichts siehe: Schricker/Schricker, § 29 UrhG,
Rn.18
335
Vgl. Rehbinder, Rn.301.
336
Vgl. BGHZ 129, 66 (73), Urt.v. 23.02.1995, „Mauer-Bilder“.
337
Vgl. Speichert, Abschn. 5: “Rechtliche Konstruktion der OSS”.
338
Vgl. § 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…By modifying or distributing the Program (…), you
indicate your acceptance of this License…”
339
Vgl. Omsels/FS Hertin, S.154.
66
dem Fortbestand der Urheberrechtsposition als solcher sowie der
Verbotsrechte beim Schöpfer des Werks ausgeht340.
Ein Verzicht auf die Ausübung der Urheberrechte ist demnach nicht
nur in das deutsche Urheberrechtssystem nicht übertragbar, sondern
von den Verfassern der GPL auch gar nicht gewollt. Vielmehr ist richtigerweise von einer Inanspruchnahme des urheberrechtlichen
Schutzes zur dauerhaften Gewährleistung der Freiheiten auszugehen341. Es bleibt daher bei der Einräumung eines einfachen Nutzungsrechts an jedermann.
5. Eigene Bewertung und Zuordnung
Abschließend zu diesem Überblick ist es notwendig, eine Bewertung
über die Zuordnung der aufgezeigten typischen Anwendungsfälle
von GPL-Software vorzunehmen.
a. Verträge sui generis/Urheberrechtsverzicht
Es wurde festgestellt, dass durch Unterstellung von Software unter
die GPL jedenfalls ein Vertragsschluss beabsichtigt wird, weshalb die
These vom Verzicht auf das Urheberrecht und der daraus folgenden
außervertraglichen Lösung von vornherein ausscheiden muss.
Darüber hinaus verspricht aus praktischer Sicht - allein wegen der
ablehnenden Haltung der Rechtsprechung - keine der diskutierten
Sui-generis-Lösungen die notwendige Rechtssicherheit im Umgang
mit Open Source Software zu bieten. Die in diesem Zusammenhang
geäußerten Bedenken der Rechtsprechung greifen durch. Es ist angesichts der mit Mitteln der konventionellen Rechtsanwendung möglichen Einordnung des Open-Source-Phänomens in die deutsche
Rechtsordnung nicht einzusehen, inwieweit durch die Annahme eines Vertrages eigener Art eine sachgerechtere Lösung herbeigeführt
werden kann.
340
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.843; Stickelbrock/ZGS 2003, S.369.
Dies wird auch aus den Worten ihres Mitverfassers Eben Moglen deutlich: “the
work’s user is obliged to remain within the bounds of the license not because she
voluntarily promised, but because she doesn’t have any right to act at all except as
the license permits.”, vgl. Moglen, S.1f.
341
Vgl. oben unter B. II. 2. Das „Copyleft“-Prinzip.
67
b. Veräußerungsverträge
Insbesondere die Einordnung unter veräußerungsvertragliche Konzepte erweist sich bei genauerem Hinsehen als tauglicher Ansatz.
Zunächst hat die Subsumtion gezeigt, dass eine Einordnung unter
die Veräußerungsvertragstypen trotz der geäußerten Bedenken gelingt. Weiterhin dürfte eine solche Klassifizierung aber auch den zu
berücksichtigenden Interessen gerecht werden, da eine ausreichende Differenzierung zwischen den verschiedenen Konzepten im Umgang mit Open Source Software erreicht wird.
Dort, wo innerhalb der Entwicklergemeinschaft nichtkommerzielle
oder gar altruistische Motive hinter dem Gebrauch von Open Source
Software stecken, erreicht eine Einordnung unter das Schenkungsrecht eine weitgehende Haftungsprivilegierung durch die §§ 521,
523, 524 BGB. Dies dürfte gerade deshalb den Bedürfnissen der
Praxis entsprechen, weil es sich, wie wir gesehen haben, bei den
hier beteiligten Personen um sachkundige Experten und Programmierer handelt, die aufgrund ihrer persönlichen gleichgerichteten
Hobbys und Interessen handeln. Aufgrund ihres besonderen Wissens kennen sie die besonderen Risiken und akzeptieren im Interesse ihrer Leidenschaft und ihrem Interesse diese besondere Risikosituation im Vergleich zur Anwendung von Standardsoftware. Im Verkehr untereinander räumen sich die Programmierer Handlungsspielräume ein und schaffen so eine besondere Vertrauenssituation untereinander. Auf dieser gemeinsamen Basis bedarf es eines besonderen Rechtsschutzes nicht – im Gegenteil: Im Rahmen eines innovativen Handelns dieser Art erscheinen zu strikte Rechtsregelungen
eher hinderlich342.
Dort aber, wo wirtschaftliche Interessen in den Vordergrund treten,
erscheint es ebenfalls sachgerecht, durch die Anwendung des Kauf-,
Dienst- oder Werkvertragsrechts die notwendige Rechtssicherheit zu
gewährleisten und eine den tatsächlichen Bedürfnissen entsprechende Risikoverteilung vorzunehmen. So stehen sich auf dieser
Stufe als Vertragspartner nicht allein Experten gegenüber, sondern
342
So auch Sester/CR 2000, S.805.
68
werden durch große Unternehmen und Distributoren auch einfache
Anwender bzw. Verbraucher an dem System beteiligt. Aus diesem
Grund wird es hier auch oftmals an den gleichgerichteten Interessen
und der wirtschaftlichen Ebenbürtigkeit der Vertragspartner fehlen
und somit eine grundsätzliche andere Gefahrenlage als innerhalb der
Programmierergemeinschaft bestehen. Wer also seine Expertenstellung zu Erwerbszwecken nutzt, dem kann vor dem Hintergrund des
bestehenden Informationsungleichgewichts gerechterweise auch ein
verstärktes Maß an Rechtssicherheit und folglich eine verschärfte
Haftung abverlangt werden.
Aber auch im Interesse der beteiligten Unternehmer, wie etwa der
Distributoren, wird durch zusätzliche Rechtssicherheit ein lukratives
Geschäftsfeld erschlossen. So schafft erhöhte Rechtssicherheit
gleichzeitig ein höheres Vertrauen seitens der einfachen Anwender,
die hierdurch eher bereit sein werden, auf Open Source Produkte
umzusteigen und die Angebote der verschiedensten Dienstleister in
diesem Umfeld wahrzunehmen.
So wird ebenfalls für die Computer- und Softwareindustrie ein größerer Markt geschaffen, der seinerseits Investitionssicherheit mit sich
bringt. Open Source Software hat sich zu einem wichtigen Wirtschaftsfaktor entwickelt und kann ihre Anwendungsbereiche so weiter ausbreiten.
Blickt man damit auf die erklärten Zielsetzungen, wie etwa der Gewährung einer größtmöglichen Freiheit nach Stallman oder der Förderung der wirtschaftlichen Stellung und einer weitest möglichen
Verbreitung von Open Source Software durch die OSI, zeigt sich,
dass mit dem hier verfolgten Ansatz beiden Idealen nachzukommen
ist.
c. Gesellschaftsrechtliche Lösung
Dem gesellschaftsrechtlichen Lösungsansatz ist zuzugeben, dass
seine Vertreter sich gleichermaßen um eine interessengerechte Risikoverteilung bemühen. So erreicht die Ansicht Sesters ebenfalls eine
Haftungsprivilegierung im Bereich der „Szene“ und will überall dort,
wo kommerzielle Interessen beteiligt sind, gleichermaßen höhere
69
Obligationen schaffen. Entgegenzuhalten ist dieser Ansicht jedoch,
dass sie die Interessen der beteiligten Personen auf nachfolgende
Erwerbsabsichten reduziert, was der tatsächlichen historischen und
gegenwärtigen Entwicklung des Open-Source-Modells nicht entspricht. Zudem fehlt es innerhalb der Projekte an der vertraglichen
Pflicht, den gemeinsamen Gesellschaftszweck zu fördern, denn wie
erläutert, ist der Erwerb und die Modifikation der Software zu privaten
Zwecken keinerlei Verpflichtungen unterworfen. Es erscheint deshalb
verfehlt, jeden Nutzer eines Open-Source-Programms in diese konstruierte Quasi-Gesellschaft zu integrieren343. Mit Blick auf die Größe
und Unüberschaubarkeit heutiger Projekte, wie etwa auf die
GNU/Linux-Entwicklergemeinschaft, wird die Möglichkeit einer sachgerechten Differenzierung im Einzelfall abgeschnitten. Sehr wohl ist
es jedoch vorstellbar, die Mitglieder einer geschlossenen Entwicklergemeinschaft, wie diese auch im Umfeld von Open Source Software
existieren, einer gemeinsamen Gesellschaft zuzuordnen.
Das veräußerungsvertragliche Konzept erscheint daher am passendsten für die Einordnung der GPL in das deutsche Vertragsrecht
und soll deshalb als Basis für die weitere Untersuchung der Gewährleistungs- und Haftungsrisiken im Umfeld von GPL-Software dienen.
II. Haftung entsprechend der vertraglichen Einordnung
Die oben dargestellten Möglichkeiten, quelloffene Software sowohl
im Rahmen kommerzieller Tätigkeiten entgeltlich sowie als ein Produkt der Freizeitgestaltung unentgeltlich abzugeben, müssen natürlich auch bei der Analyse der Gewährleistungs- und Haftungsbedingungen berücksichtigt werden. Diese muss deshalb entsprechend
der einzelnen Fallgestaltungen differenziert erfolgen.
1. Entwicklergemeinschaft
Wie dargelegt liegen den Softwareerwerbsvorgängen innerhalb der
Entwicklergemeinschaft in der Regel Schenkungen gem. § 516 BGB
343
So auch Spindler/VSI, S.75; Grützmacher/ITRB 2002, S.86.
70
sowohl hinsichtlich der Nutzungsrechte als auch der Software zu
Grunde344.
a. Gewährleistung
Das Schenkungsrecht sieht gem. §§ 523, 524 BGB eine geringe gesetzliche Gewährleistungspflicht vor. Demnach haftet der Schenker
seinem Vertragspartner gegenüber sowohl hinsichtlich Rechts- als
auch Sachmängeln jeweils nur bei arglistigem Verschweigen des
Mangels. Es handelt sich dabei lediglich um einen Schadensersatzanspruch; die weiteren Mängelgewährleistungsrechte des Kaufrechts
kommen hier nicht zur Anwendung345.
1.) Sachmängel
Für die Beurteilung eines Mangels gilt nach § 434 Abs. 1 S. 1 BGB
der subjektive Fehlerbegriff, nach dem es auf die vereinbarte Beschaffenheit des Vertragsgegenstands ankommt346. Gerade im
Open-Source-Bereich werden aber Beschaffenheitsvereinbarungen
für die Programme in der Regel nicht getroffen347. Die Fehlerhaftigkeit eines Open-Source-Programms bestimmt sich daher anhand
objektiver Anknüpfungspunkte. Dies wird nach den Regeln der
§§ 434 Abs. 1 S. 2 Nr. 1, 2 BGB danach zu bestimmen sein, ob sie
sich für die nach dem Vertrag vorausgesetzte Anwendung eignet
oder ob sie eine Beschaffenheit aufweist, die bei Sachen der gleichen Art üblich ist und die der Käufer nach Art der Sache erwarten
kann. Gerade im Softwarebereich muss aber von einer grundsätzlichen Unvermeidbarkeit von Fehlern ausgegangen werden348. Dies
trifft umso mehr für die Open-Source-Entwicklung zu: Hier kursieren
zwischen den Entwicklern unfertige, noch nicht in jeder Hinsicht
überprüfte Programme. Grundsätzlich kann daher ein Bewusstsein
unterstellt werden, dass ein größeres Risiko besteht, ein fehlerhaftes
344
Vgl. hierzu oben E. I. 1. a. Schenkung.
345
346
Vgl. Palandt/Weidenkaff, § 524, Rn. 5.
347
Vgl. Spindler/VSI, S. 77.
348
Vgl. Marly, Rn. 714ff.; Koch, Rn. 1441.
71
Programm zu erhalten349. Dieses Bewusstsein ist Grundlage des
gemeinsamen Projekts der Softwareentwicklung, dessen ausgemachtes Ziel es ist, gemeinsam diese Fehler aufzuspüren und zu
beseitigen.
Nach § 524 Abs. 1 BGB kann es daher einen Anspruch des Erwerbers nach sich ziehen, wenn ein Programmierer das sich gegenseitig
eingeräumte Vertrauen missbraucht und das Programm weitergibt,
ohne auf ihm bekannte erhebliche „Bugs“, Fehlfunktionen oder gar
Viren hinzuweisen, von denen Gefährdungen ausgehen könnten350.
Hinsichtlich einer potenziellen Virenverseuchtheit ist anzumerken,
dass in der Praxis in erster Linie proprietäre Programme, insbesondere Microsoft-Produkte von diesem Problem betroffen sind, während eine Verseuchung freier Software selten ist. Aus diesem Grund
reduziert sich diese Möglichkeit fast ausschließlich auf das vorsätzliche Verbreiten einer solchen Schadensroutine. Innerhalb der Programmierer-Community wird es jedoch selten so weit kommen.
Schließlich ist es gerade Sinn und Zweck der Arbeit nach der „Basar“-Methode, bestehende Programmfehler gemeinsam zu bearbeiten, um diese so besser lösen zu können. Ein solches Verhalten
würde die Popularität des Saboteurs erheblich beeinträchtigen, mithin seiner zukünftigen Mitwirkung die Basis entziehen.
Nach diesen Grundsätzen kann der Anbieter des Weiteren dafür verantwortlich sein, dass der Erwerber keine falschen Eindrücke von der
Software bezüglich ihrer Qualität und Verwendbarkeit vermittelt bekommt351. Bewusst irreführende Aussagen diesbezüglich könnten
hier ebenfalls als arglistig i.S.v. § 524 BGB angesehen werden.
2.) Rechtsmängel
Die Haftung für Rechtsmängel richtet sich nach § 523 Abs. 1 BGB.
Eine solche könnte beispielsweise ausgelöst werden, wenn ein Mitglied der Entwicklergemeinschaft wider besseres Wissen proprietären Code Dritter verbreitet, an dem der Erwerber keine Nutzungs349
350
351
Vgl. Siepmann/Jur-PC 1999, Abs.138.
72
rechte eingeräumt bekommen kann352. Eine Haftung für unwissentlich verbreitete fremde Programme besteht demnach nicht.
Hinsichtlich von Rechts- und auch Sachmängeln ist es allerdings
auch ausreichend, wenn falsche Angaben „ins Blaue hinein“ gemacht
werden, bei denen der Schenker mit der Möglichkeit ihrer Unrichtigkeit rechnet353.
b. Verschuldensabhängige Haftung
Die Haftung des Schenkers ist bei Vertragsverletzungen gem. § 521
BGB auf Vorsatz und grobe Fahrlässigkeit beschränkt354. Dies betrifft
zuvorderst Schäden, die aufgrund einer Verletzung nebenvertraglicher Schutz- und Verkehrssicherungspflichten entstehen. Denkbar
wären insoweit eventuelle Hinweispflichten bezüglich besonderer
Gefahren355. Betreibt der Anbieter beispielweise einen Server, auf
dem jedermann seine Software im Wege des Uploads übertragen
kann, scheint ein Hinweis auf die sich hieraus ergebenden Gefahren
schon aufgrund der allgemeinen Verantwortlichkeitsgrundsätze zur
Haftung im Internet angebracht356. Es ist jedoch zu bedenken, dass
die spezifischen Risiken des Einsatzes „unfertiger“ Software innerhalb der Open-Source-Entwicklerkreise bekannt sind. Da § 524
Abs. 1 BGB eine bezüglich Sachmängeln abschließende, dem § 521
BGB vorgehende Spezialvorschrift ist, haftet der Anbieter von kostenloser Open Source Software zudem nicht für Mangelfolgeschäden
des Vertragspartners357.
Dieser Haftungsmaßstab ist ebenfalls auf die deliktische Haftung zu
übertragen, wenn durch den Einsatz der Software eine Verletzung
absoluter Rechtsgüter entsteht358. Auch diese Privilegierung erscheint im Umfeld der Entwicklergemeinschaft sachgemäß. So fällt
352
353
Vgl. Spindler/VSI, S.77; zu Angaben in ins Blaue hinein: BHGZ 63, 382 (386),
Urt. v. 21.01.1975; BGH NJW 1998, 302, Urt. v. 26.09.1997.
354
Vgl. Spindler/VSI, S.79; Grützmacher/ITRB 2002, S.90.
355
Vgl. Palandt/Weidenkaff, § 524, Rn. 4.
356
Vgl. Siepmann/Jur-PC 1999, Abs.138; Spindler/MMR 1998, S.27.
357
Vgl. Spindler/VSI, S.79; Palandt/Weidenkaff, § 521, Rn.4.
358
Vgl: Jaeger/Metzger, OSS, S.155; Siepmann/Jur-PC 1999, Abs.155.
73
erneut ins Gewicht, dass hier keineswegs fertige Programme, sondern eher Prototypen im Umlauf sind. Wegen der besonderen Eigenschaften freier Software als autodistributive Software besteht für den
Autor, nachdem er das Programm aus den Händen gibt, zudem keine Möglichkeit mehr, darauf Einfluss zu nehmen359. So können weitere Fehler oder gar Schadensroutinen, wie Viren oder Trojanische
Pferde, auch von Dritten hinzugefügt werden. Der Autor soll daher
nur für grobe Fehler haften, die bereits erkennbar waren, als das
Programm seinen Einflussbereich verlassen hat.
c. Verschuldensunabhängige Haftung
In Betracht zu ziehen ist weiterhin eine verschuldensunabhängige
Haftung nach den Vorschriften des Produkthaftungsgesetzes (ProdHaftG). Die Produkthaftung ist ein außervertragliches Haftungsinstitut, welches Verbraucher bei Personen- und Sachschäden schützen
soll, die durch fehlerhafte Produkte hervorgerufen werden360. Sie ist
deshalb als verschuldensunabhängige Gefährdungshaftung ausgestaltet, damit dem Geschädigten die oftmals schwierige Beweisführung hinsichtlich des Verschuldens des Herstellers erspart bleibt361.
1.) Produkt i.S.d. ProdHaftG
Zunächst müsste es sich bei Software dann um ein Produkt i.S.d.
ProdHaftG handeln. Grundsätzlich verlangt das ProdHaftG in § 2 als
Produkt eine bewegliche Sache. Ist die Software daher auf einem
Datenträger gespeichert, der sie verkörpert, so ist nach herrschender
Ansicht diese Voraussetzung erfüllt, wie sich insbesondere aus der
Rechtssprechung des BGH ergibt, der die Sacheigenschaft von Software nach § 90 BGB insbesondere bei deren Speicherung auf einem
Datenträger anerkannt hat362. Problematisch sind aber die Fälle, in
denen Software durch das Internet heruntergeladen wird, also in
unverkörperter Form in den Verkehr gegeben wird. Hinsichtlich zum
359
Vgl. Schiffner, S. 257.
360
Vgl. Medicus, Rn. 650.
361
Vgl. Jaeger/Metzger, OSS, S.152; Medicus, Rn. 650.
362
Vgl. BGH NJW 1993, 2436 (2437), Urt. v. 14.07.1993; BGH CR 1997, 470, Urt.
v. 4.03.1997; vgl. auch Taeger, S.143ff.; Kaminski/Henßler et al., PapathomaBaetge/Iliev, E, Rn. 54.
74
lich zum Download angebotener fehlerhafter Software wurde deshalb
bisweilen die Meinung vertreten, dass eine bewegliche Sache nach
§ 2 ProdHaftG mangels deren Verkörperung nicht vorliegt363. Dem
lässt sich jedoch entgegenhalten, dass die Verkörperung nach dem
Download auf dem Datenträger des Nutzers eintritt364. Vielfach wird
zudem auch als Lösung angeboten, Software unter den Begriff der
Elektrizität zu subsummieren, die von § 2 ProdHaftG explizit als taugliches Produkt i.S.d. Gesetzes normiert wird. Schließlich erfolge die
Übertragung von Software mittels elektromagnetischer Ströme, also
durch das Medium der Elektrizität365.
Letztlich entscheidend ist aber wohl folgende Überlegung: Auch das
ProdHaftG beruht auf einer Richtlinie der Europäischen Union366. Für
seine Auslegung kann daher nicht allein die deutsche Rechtslage
maßgeblich sein. Vielmehr muss im Interesse einer homogenen Anwendung innerhalb aller Mitgliedstaaten eine richtlinienkonforme
Auslegung des ProdHaftG erfolgen. Unabhängig von der Streitfrage
zur Einordnung von Software unter den Sachbegriff innerhalb der
deutschen Rechtsordnung ist daher auf den Schutzzweck der Produkthaftungsrichtlinie abzustellen. So soll hierdurch ein besserer
Schutz des Verbrauchers vor gefährlichen Gütern erreicht werden367.
Hiernach muss davon ausgegangen werden, dass es für die Produkteigenschaft nur auf den Warencharakter, also die Austauschbarkeit des Produkts und dessen Gefährlichkeit ankomme, nicht jedoch
auf dessen Körperlichkeit368. Diese Auslegung wird zudem auch
durch das ProdHaftG selbst gestützt, da dieses auch Elektrizität zu
363
Vgl. Redecker, NJW 1992, S. 1739f.
364
Vgl. BGHZ 109, 97 (100f.) Urt. v. 7.11.1995; Spindler, MMR 1998, S. 24, 120;
Marly, Rn. 89ff., 107; Stichtenoth/K & R 2003, S.107.
365
Vgl. Spindler, MMR 1998, S. 120ff.; v.Westphalen/ders., § 73, Rn. 40.
366
Richtlinie 85/374/EWG des Rates vom 25. Juli 1985 zur Angleichung der
Rechts- und Verwaltungsvorschriften der Mitgliedstaaten über die Haftung für fehlerhafte Produkte.
367
368
Vgl. Bothe/Kilian, Kilian, S. 373f.; Spindler, MMR 1998, S. 120;
Schwarz/Peschel-Mehner, Schwarz, 20 G, Rn. 68; Taeger, S.187ff.
75
den Produkten i.S.d. Gesetzes zählt369. Eine Haftung nach Maßgabe
des ProdHaftG für fehlerhafte Software ist daher anzunehmen370.
2.) § 1 Abs. 2 Nr. 3 ProdHaftG
In Fällen der privaten Open-Source-Entwicklung innerhalb der Entwicklergemeinschaft ist sinnvoller Weise bei der weiteren Prüfung
zunächst festzustellen, ob möglicherweise der haftungsausschließende Tatbestand des § 1 Abs. 2 Nr. 3 ProdHaftG eingreift. Hiernach
haftet der Hersteller dann nicht für die Software, wenn er das Produkt
weder zum Verkauf oder einer anderen Form des Vertriebs mit wirtschaftlichem Zweck, noch im Rahmen seiner beruflichen Tätigkeit
hergestellt hat.
Im Hinblick auf die im Einzelfall auch innerhalb der Programmierergemeinschaft vorhandenen Sekundärinteressen371 wird man diese
Frage jedoch nicht pauschal beantworten können.
Bietet der Autor die Software zum Beispiel gezielt deshalb an, um
später durch kostenpflichtigen Support zu profitieren, wird man bereits im Moment der Programmierarbeit eine mittelbare Gewinnerzielungsabsicht und somit ein Handeln zu einem wirtschaftlichen Zweck
annehmen können. Andererseits kann aber auch die Tatsache, dass
sich ein Berufsprogrammierer an seinem Arbeitsplatz an OpenSource-Projekten beteiligt, nicht zwingend zu der Annahme führen,
dass er im Rahmen seiner beruflichen Tätigkeit handelt, wenn dies in
seiner Freizeit geschieht372.
Die Beispiele zeigen, dass die Sachlage nach den Gesamtumständen des Einzelfalls zu ermitteln ist, wonach zumindest ein enger inhaltlicher Zusammenhang mit der beruflichen Tätigkeit oder dem
wirtschaftlichen Zweck bestehen muss. Als Abgrenzungskriterien
können hierbei verschiedene Aspekte entscheidend sein, so zum
Beispiel, ob die Software als Nebenprodukt der beruflichen Tätigkeit
oder im Rahmen eines privat geförderten Projekts erstellt wird, oder
369
Vgl. Jaeger/Metzger, OSS, S.152; v.Westphalen/ders., § 73, Rn. 40.
370
371
Vgl. zur Motivation der beteiligten Programmierer C. II. 1. Überwiegend nichtkommerzielle Motivation.
372
76
auch, ob der Programmautor im Zusammenhang mit seiner beruflichen Tätigkeit auftritt373.
Innerhalb der Programmierergemeinschaft werden die nichtkommerziellen Motive wohl tendenziell überwiegen, weshalb im Regelfall eine rein private Tätigkeit nach § 1 Abs. 2 Nr. 3 ProdHaftG vorliegen
wird374. Die Verantwortlichkeit nach dem ProdHaftG ist daher hier
meistens nicht gegeben.
3.) Fehler i.S.d. § 3 ProdHaftG
Liegen diese Voraussetzungen aber im Einzelfall nicht vor, so ist der
Anwendungsbereich des ProdHaftG eröffnet. Der Programmierer
haftet dann für die aufgrund eines Fehlers i.S.v. § 3 ProdHaftG entstandenen Schäden. Dieser Fehlerbegriff ist dann erfüllt, wenn die
Software nicht die Sicherheit bietet, die berechtigterweise erwartet
werden kann, und sie daher nicht für ihren bestimmungsgemäßen
Gebrauch einsetzbar ist375.
Innerhalb der Entwicklergemeinschaft ist man sich jedoch weitestgehend im Klaren darüber, dass die Programme fehlerhaft sein können.
Die Erwartungen an das Produkt werden daher hier im Regelfall nicht
allzu hoch ausfallen, insbesondere auch deshalb, weil die Software
kostenlos zur Verfügung gestellt wird. Es dürfte hier daher nur eine
gewisse „Basis-Sicherheit“ zu erwarten sein376. Ähnlich der Gewährleistung im Rahmen des § 524 Abs. 1 BGB dürfte der Programmierer
daher nur für schwerwiegende Fehler gerade stehen müssen, wie
beispielsweise für Virenbefall377.
4.) Haftung
Die Haftung ist jedoch beschränkt auf Schäden, die an Körper und
Gesundheit des Nutzers oder anderen Sachen, also nicht am fehlerhaften Produkt selbst, entstehen. Personenschäden werden hier selten auftreten, da in Bereichen, in denen derartig hohe Rechtsgüter
auf dem Spiel stehen, so zum Beispiel in Krankenhäusern oder Arztpraxen, für gewöhnlich keine Open Source Software aus Kreisen der
373
Vgl. zum Ganzen Jaeger/Metzger, OSS, S.153f.
374
Vgl. Jaeger/Metzger, OSS, S.153; Schiffner, S.258; Spindler/VSI, S.93.
375
376
Vgl. Spindler/VSI, S.94; ders./MMR 1998, S:27; Schiffner, S.250.
377
Vgl. Günther, S.678.
77
Entwicklergemeinschaft zum Einsatz kommen wird378. Die Haftung
für Sachschäden ist im Übrigen auf Gegenstände beschränkt, die
zum privaten Gebrauch des Nutzers bestimmt sind. Auch Schäden
am Computer des Nutzers sind kaum vorstellbar, da selbst Viren in
der Regel keine Beschädigungen der Hardware zur Folge haben
können. Tatsächlich werden es daher am ehesten andere Software
oder Daten auf dem Rechner des Nutzers sein, die durch das Produkt zu Schäden kommen können379. Für diese Fälle ist aber auch
an die Selbstbeteiligung des Geschädigten nach § 11 ProdHaftG zu
denken, wonach Schäden bis zu 500 Euro vom ihm selbst zu tragen
sind. Aufgrund der weiten Einschränkungen, die das ProdHaftG
selbst macht, und den geschilderten tatsächlichen Gegebenheiten ist
daher aber die praktische Relevanz dieser Vorschriften für den Softwareaustausch innerhalb der Entwicklergemeinschaft eher gering
einzuschätzen380.
2. Distributionen und Software-Vertrieb
Grundlegend anders stellt sich die Gewährleistungs- und Haftungssituation jedoch dar, wenn an die Stelle der ideellen Motive ökonomische Interessen treten. So wird im Fall von Distributionen bzw. anderer kommerzieller Vertriebskonzepte mit freier Software grundsätzlich
von gemischten Vertragstypen auszugehen sein, wodurch auch andere Gewährleistungs- und Haftungsvorschriften greifen.
a. Gewährleistung
So wird beim Erwerb einer kommerziellen Distribution regelmäßig ein
Kaufvertrag gem. § 433 Abs. 1 BGB über die vom Distributor zusammengestellte und meist auf Datenträgern gespeicherte Software
sowie begleitender Dokumentation geschlossen381. Auch beim
Download der Software über die Website des Distributors ist aber
infolge des § 453 Abs. 1 BGB von einem Kaufvertrag auszugehen,
378
Hier werden grundsätzlich wohl eher ganzheitliche Lösungen der Gerätehersteller von medizinischen Geräten zum Einsatz kommen, vgl. Schiffner, S.251.
379
Vgl. Schiffner, S.251; Wiebe/Heidinger, S.3.
380
So gibt es bisher beispielweise keine einzige Gerichtsentscheidung, die sich mit
der Haftung für Software nach dem ProdHaftG befasst, vgl. Günther, S.616; Jaeger/Metzger, OSS, S.152.
381
Vgl. oben unter E. I. 1. b. 1.) Distributionen/Software-Vertrieb.
78
da lediglich die unterschiedliche Übertragungsweise eine andere Betrachtung nicht rechtfertigen kann382. Die Nutzungsrechte erhält der
Erwerber nach der Konstruktion des § 6 GPL weiterhin vom Urheber
des Programms selbst.
Die Gewährleistung für Sachmängel und Rechtsmängel richtet sich
nach den §§ 433 Abs. 1 S. 2, 434 ff. BGB bzw. §§ 453 Abs. 1, 435 ff.
BGB383.
1.) Sachmängel
Grundsätzlich gilt hier daher auch der subjektive Fehlerbegriff des
§ 434 Abs. 1 S. 1 BGB. Da auch in den Fällen des Softwarekaufs bei
einem Distributor oder Händler in der Regel keine besonderen Beschaffenheitsabreden getroffen werden, ist erneut auf die Frage abzustellen, ob die erworbene Sache eine Beschaffenheit, die bei Sachen der gleichen Art üblich ist und vom Kunden erwartet werden
darf, aufweist. Diese Erwartungshaltung des Käufers wird hier je
nach Fallgestaltung unterschiedlich hoch ausfallen.
Wird die Software zu einem sehr günstigen Preis abgegeben, der
deutlich unterhalb des Gewöhnlichen liegt, werden dementsprechend
auch die Erwartungen des Erwerbers deutlich geringer sein384. Gleiches gilt auch, wenn die Entgeltlichkeit ausdrücklich auf den Datenträger beschränkt wird und der Verkäufer darauf hinweist, dass die
darauf befindliche Software verschenkt wird. Demnach könnte ein
Gewährleistungsanspruch nicht bereits im Fall von kleineren Fehlfunktionen oder Unausgereiftheiten entstehen. Lediglich bei schwerwiegenden Mängeln, stünden dem Käufer gem. §§ 434, 437ff. BGB
die Gewährleistungsansprüche, gerichtet zunächst auf Nachbesserung, aber im Weiteren auch auf Minderung und Rücktritt, bis
schließlich zum Schadensersatzanspruch wegen Mangel- und Mangelfolgeschäden zu385.
382
383
384
385
Vgl. Goldmann/Redecke, MMR 2002, S.5.
Hierbei ist zu beachten, dass das Recht auf Nacherfüllung hier vielfach nur durch
echte Nachbesserung, d.h. durch Lieferung eines Updates oder eines Reparatur-
79
Handelt es sich hingegen um eine kommerzielle Distribution inklusive
eigener proprietärer Programme aus der eigenen Entwicklungsabteilung des Distributors oder Vertreibers, deren Preis deutlich über den
Kosten für den Datenträger liegt, wie dies bei den meisten LinuxKomplettlösungen anzunehmen ist, stellt sich die Sachlage anders
dar. Hier erwartet der Kunde zu Recht ein funktionierendes System,
das für ihn als Nutzer brauchbar ist386. Angesichts der komplexen
Struktur solcher Komplettlösungen erscheint es nicht zumutbar, ihm
die Beweisführung aufzubürden, dass die Funktionsunfähigkeit auf
den entgeltlichen Leistungen des Distributors beruht. Vielmehr muss
sich die Mängelgewährleistung in diesen Fällen auf das gesamte Paket inklusive der Open Source Software erstrecken. Ebenso sind
nach der sog. „Ikea-Klausel“ des § 434 Abs. 2 S. 2 BGB Ansprüche
wegen mangelhafter Dokumentation denkbar387.
Die gleiche Situation ergibt sich auch, wenn sog. „Value-added“Pakete großer kommerzieller Software-Hersteller erworben werden,
die auf Open Source Software basieren, aber kommerzielle Beigaben enthalten, um deren Absatzchancen zu verbessern. Auch hier
muss die Gewährleistung aufgrund der gleichen Interessenlage umfangreich eingreifen388.
2.) Rechtsmängel
Ähnlich ist die Lage bei Vorliegen eines Rechtsmangels gem. § 435
BGB. Ein solcher könnte vor allem die fehlende Befugnis sein, das
Programm berechtigt benutzen zu dürfen. Diese Befugnis könnte
dann nicht vorliegen, wenn es sich bei dem betreffenden Programm
entgegen den Aussagen des Vertreibers nicht um freie Software
handelt, sondern tatsächlich um ein proprietäres Programm, welches
nicht unter einer Open-Source-Lizenz vertrieben werden darf. Ausreichend hierfür ist, dass der Autor des Programms Teile proprietäpatches, da es sich bei Softwarefehlern typischerweise um Serienfehler handelt,
die allen Kopien anhaften, mithin durch einfache Nachlieferung nicht zu beheben
sind.
386
Vgl. Siepmann/Jur-PC 1999, Abs.139; Stickelbrock/ZGS 2003, S.372..
387
388
80
ren Codes eines Dritten verwendet hat389. In diesen Fällen kann der
Berechtigte am Werk die Werknutzung jederzeit untersagen390.
Wird beim Erwerb des Softwarepakets aus den Gesamtumständen
des Falles klar, dass es sich um freie Software handelt, die lediglich
im Wege der Schenkung übertragen wird, kommt ein Schadensersatzanspruch gem. §§ 440, 281 BGB gegen den Distributor nur bei
schweren Sorgfaltspflichtverletzungen in Bezug auf die aufgetretenen Mängel in Betracht, so zum Beispiel, wenn er sich nicht im Rahmen der ihm zumutbaren Möglichkeiten nach der Einhaltung des Urheberrechts durch den Autor erkundigt hat391. Hinsichtlich des
Rechtsmangels wäre der Erwerber dann gehalten, sich an den Programmautor selbst zu wenden, der allerdings, wenn er überhaupt
festgestellt werden kann, höchstens unter den Voraussetzungen des
Abschnitts 1. Entwicklergemeinschaft haftet392.
Stellt sich der Vertrag für den Erwerber, wie in den o. g. Fällen jedoch als einheitlicher Kaufvertrag dar, so muss der Anbieter gem.
§ 453 Abs. 1 BGB nach den gleichen Gewährleistungsrechten auch
für Rechtsmängel an der Sache einstehen. Eine solche Gewährleistung kann sich oftmals auch daraus ergeben, dass der Distributor
das Produkt gerade mit den besonderen Eigenschaften der freien
Software anpreist. So wird oftmals damit geworben, dass die Software angepasst, vervielfältigt und verbreitet werden darf393. Auch im
Bereich des „Value-added“-Vertriebs betonen die Anbieter zu gerne
diese Möglichkeiten. Liegen diese aber nicht vor, führt dies zu einem
Mangel i.S.v. § 434 Abs. 1 S. 3 BGB394.
Dem Käufer stehen wegen eines Rechtsmangels gem. §§ 435,
437 ff. BGB grundsätzlich Gewährleistungsansprüche auf Nachbesserung, Minderung und Rücktritt, bis schließlich hin zum Schadensersatzanspruch zu. Ein wesentlicher Unterschied zum Sachmangel
389
Vgl. Wuermeling/Deike, CR 2003, S.89.
390
Vgl. Jaeger/Linux-Mag. 2002.
391
392
Vgl. oben II. 1. a. 2.) Rechtsmängel.
393
394
81
ist jedoch, dass vor allem das Minderungsrecht und zumeist auch
das Nachbesserungsrecht in Fällen des Rechtsmangels keine Abhilfe darstellen können, da dem Erwerber die Benutzung des Programms infolge der urheberrechtlichen Ausschließlichkeitsrechte eines Dritten untersagt bleibt. In der Praxis dürfte daher nur Rücktritt
und Schadensersatz in Betracht kommen395.
3.) Zusätzliche Dienstleistungen
Schließt der Softwareerwerber mit dem Distributor zusätzliche Vereinbarungen über weitere Dienstleistungen wie Support oder Schulungen ab, besteht hinsichtlich dieser Dienstleistungen ein Dienstvertrag396. Neben die kaufvertragliche Gewährleistung bezüglich der im
Rahmen des Gesamtvertrages gelieferten Sachen tritt dann für die
spezifisch nach Dienstvertragsrecht zu beurteilenden Leistungen die
Gewährleistung nach §§ 611, 280 Abs. 1, 281 BGB397. Hiernach hat
der Dienstleistende jede Pflichtverletzung zu vertreten, die zu einem
Schaden beim Dienstberechtigten führt, insbesondere wäre hier an
mangelhafte Beratung oder Fehlleistungen bei der Systempflege zu
denken.
b. Verschuldensabhängige Haftung
Auch die Haftung verschärft sich im Umfeld kommerzieller Angebote
deutlich gegenüber der schenkungsweisen Überlassung, da hier die
Haftungsprivilegierung des Schenkers nicht eingreift. Inhaltlich wird
es hier in erster Linie um den Ersatz von Schäden gehen, die durch
Virenbefall oder Datenverluste in Folge der Mangelhaftigkeit des
Programms beim Vertragspartner oder bei Dritten auftreten.
1.) Vertragliche Haftung
So muss der Veräußerer nach §§ 440, 280 Abs. 1 BGB für alle beim
Einsatz der Software schuldhaft entstandenen Mangel- und Mangelfolgeschäden haften, wie sie zum Beispiel durch Produktionsausfälle
395
396
Vgl. oben unter E. I. 1. b. 2.) Zusätzliche Dienstleistungen.
397
Vgl. Jaeger/Metzger, OSS; S.167; Palandt/Putzo, § 611, Rn.14f.; Medicus, Rn.
321; Stickelbrock/ZGS 2003, S.372; Feil, S.4.
82
infolge funktionsuntüchtiger Software verursacht werden können398.
Des Weiteren treffen den Verkäufer insbesondere auch Warn- und
Instruktionspflichten hinsichtlich ihm bekannter Risiken beim Einsatz
der verkauften Software. Distributoren werden hinsichtlich ihrer
Zusammenstellungen gehalten sein, sowohl die Zuverlässigkeit ihrer
Quellen zu überprüfen, als auch eine dem Stand der Technik entsprechende „Warenausgangskontrolle“ durchzuführen, die insbesondere die Abwesenheit von Computerviren ausschließt399. Dem einfachen Händler wird man eine solche Pflicht hingegen nicht aufbürden
können, solange aus seiner Sicht keine besonderen Umstände Anlass zu einer solchen Kontrolle ergeben400. Der Distributor wird hingegen nur dann haften, wenn der Käufer die Software unmittelbar bei
diesem erwirbt. Sobald ein Händler die Software verkauft, besteht ein
vertraglicher Anspruch nur gegen ihn.
2.) Deliktische Haftung
Beim Handel mit Software ist für die deliktische Haftung insbesondere das von der Rechtsprechung entwickelte Institut der Produzentenhaftung im Rahmen des § 823 BGB zu beachten401. Wer ein Produkt
herstellt, importiert oder es durch Veräußerung in den Verkehr bringt,
muss hierbei die aus dem Produkt drohenden Gefahren möglichst
gering halten. Ihn treffen deswegen besondere Pflichten beim Vertrieb des Produkts, die sich auf die betriebliche Sorgfalt und Organisation beziehen. Eine Haftung hiernach kann sich infolge von Konstruktionsfehlern oder Fertigungsfehlern bei der Herstellung des Produkts, Kontroll- und Instruktionsfehlern bei dessen Inverkehrgabe
und unterlassenen Warnungen hinsichtlich festgestellter Fehler ergeben402. Typischerweise bringt in den hier untersuchten Fällen gerade der Distributor die kommerziell vertriebene Software in den Verkehr. Hierbei könnte eine Verantwortlichkeit für Konstruktionsfehler,
398
Vgl. Spindler/VSI, S.83; Goldmann/Redecke, MMR 2002, S.5; Stickelbrock/ZGS
2003, S.372..
399
Vgl. Siepmann/Jur-PC 1999, Abs.140; Schneider/Günther, CR 1997, S.391..
400
401
Vgl. dazu Medicus, Rn. 650; Günther, S.254.
402
Spindler/MMR 1998, S.28.
83
wie Programmierfehler an einzelnen Komponenten, Fabrikationsfehler am Datenträger und vor allem Instruktionsfehler, innerhalb der
mitgelieferten Handbücher gegeben sein.
Innerhalb des Tatbestandes des § 823 BGB ist jedoch stets ein Verschulden erforderlich, welches in der Praxis mit Beweisschwierigkeiten verbunden ist, obwohl die Rechtsprechung von einer Beweislastumkehr zu Gunsten des Geschädigten ausgeht403. Zudem führt dieses Institut gerade im Software-Bereich ein Schattendasein, da es
nicht geklärt ist, ob im Falle von Datenverlusten eine Eigentumsverletzung i.S.d. § 823 BGB vorliegt404 oder lediglich ein deliktsrechtlich
nicht geschützter Vermögensschaden anzunehmen ist405. Bei realistischer Betrachtung werden sich daher kaum Anwendungsfälle ergeben. Denkbar sind jedoch Personen- oder Hardwareschäden durch
ausfallende oder falsch funktionierende Steuerungssoftware bei gefährlichen Anlagen in der industriellen Nutzung406.
Auch eine allgemeine deliktsrechtliche Haftung des Händlers kommt
wohl eher selten in Betracht, da diesem nur bei besonderen Hinweisen auf die Fehlerhaftigkeit der Produkte eine Kontrollpflicht der gehandelten Waren obliegt407.
c. Verschuldensunabhängige Haftung
Neben der verschuldensabhängigen Haftung ist das ProdHaftG aufgrund der Nichtgeltung von § 1 Abs. 2 Nr. 3 ProdHaftG stets anwendbar, wenn ein Produkt verkauft wird408. Es bietet dem Verbrau403
Vgl. Günther, S.255; BGH NJW 1969, 269, Urt.v. 26.11.1968.
404
So z.B. OLG Karlsruhe NJW 1996, 200 (201), Urt. v. 07.11.1995; Taeger,
S.261.
405
Vgl. Spindler/MMR 1998, S.25; Günther, S.272ff.
406
Vgl. Spindler/VSI, S.90f.
Es ist jedoch auch hier zu bedenken, dass die Steuerungssoftware dieser Anlagen
in der Regel vom Hersteller der betreffenden Anlagen stammt (vgl. die Überlegungen zum einsatz von Software in Krankenhäusern oder Arztpraxen, oben unter 1.
c. 3.) Fehler i.S.d. § 3 ProdHaftG), so dass dieser als Haftungsadressat in Frage
kommt. Interessant ist die Überlegung für derartige Haftung daher vor allem für
den Embedded-Bereich. Im Einzelfall mag die Software aber auch von einem
kommerziellen Software-Hersteller stammen, der diese nach dem „Value-added“Prinzip vertreibt. Der industrielle Einsatz standardmäßiger OSSDistributionsprodukte ist jedoch auszuschließen.
407
408
Vgl. Stickelbrock/ZGS 2003, S.372; Jaeger/Metzger, OSS, S.159.
84
cher gegenüber dem Institut der Produzentenhaftung vor allem den
Vorteil, dass auf Seiten des Produktherstellers ein Verschulden nicht
gegeben sein muss409. Nach den oben bereits angestellten Überlegungen gilt das ProdHaftG ebenfalls für Software410.
In dieser Fallkonstellation gilt jedoch die Besonderheit, dass auch
(und gerade) der Distributor zu Schadensersatz verpflichtet sein
kann, da Hersteller eines Produktes nach § 4 Abs. 1 S. 2 ProdHaftG
auch derjenige ist, der sich durch Anbringen seines Namens, seiner
Marke oder ein anderes Kennzeichen als solcher ausgibt411. Gerade
weil sich der tatsächliche Autor eines Open-Source-Programms in
den meisten Fällen nicht ermitteln lässt, kann der Geschädigte auf
den Distributor zurückgreifen.
Weitere Voraussetzung einer solchen Haftung ist das Vorliegen eines Fehlers nach § 3 ProdHaftG. Je nach Fallgestaltung ist hier zu
beachten, dass die Sicherheitserwartungen des Käufers nicht wie im
Fall unentgeltlicher Abgabe des Programms im Sinne einer gewissen
„Mindestsicherheit“ reduziert sein müssen. Eine mögliche Haftung
auch für Schäden infolge weniger gravierender Mängel ist die Folge.
Hinsichtlich der praktischen Bedeutung dieser Haftungsrisiken ist
jedoch erneut auf die umfangreichen Ausnahmen hinzuweisen, die
das ProdHaftG selbst normiert412.
d. Haftungsbeschränkungen
Weiterhin zu beachten können auch beim Verkauf getroffene Individualabreden oder AGB der Distributoren bzw. Händler sein, die beim
Verkauf in den Vertrag mit einbezogen wurden und die Haftungsund Gewährleistungsmodalitäten im Einzelnen modifizieren. Formularmäßig liegt die zulässige Grenze dabei innerhalb von § 309 Nr. 7,
8 BGB, da es sich stets um neu hergestellte Sachen i.S. dieser Vor409
410
Vgl. dazu II. 1. c. 1.) Produkt i.S.d. ProdHaftG.
411
Vgl. Schiffner, S.249; Palandt/Thomas, § 4 ProdHaftG, Rn.6.
412
Vgl. oben unter 1. c. 4.) Haftung.
Immerhin scheint hier jedoch die Annahme von Personenschäden oder Hardwareschäden im Falle des industriellen Einsatzes von „Value-added“-Produkten möglich
und auch die Hersteller von Embedded-Systems könnten in Anspruch genommen
werden, vgl. FN 406.
85
schrift handeln wird413. Beim Erwerb der Software auf einem Datenträger gilt dies zweifellos, aber auch beim Download über das Internet entsteht auf der Festplatte des Nutzers eine neue Kopie des Programms414. Insbesondere die Gewährleistung kann daher zunächst
auf Nacherfüllung beschränkt werden415.
Oft wird aber der Käufer eine Distribution zu privaten Zwecken erwerben, sodass zusätzlich die Regeln über den Verbrauchsgüterkauf
gem. §§ 474 ff. eingreifen, die selbst Individualabreden über einen
Gewährleistungsausschluss, bis auf den individuellen Ausschluss
von Schadensersatz, für unzulässig erklären416. Die Haftung nach
dem ProdHaftG ist indessen gem. § 14 ProdHaftG unabdingbar.
3. Embedded-Systems
Prinzipiell ähnlich verhält es sich mit der Haftung von Hardwareherstellern, die ihre Produkte mit vorinstallierter GPL-Software ausliefern417. Im Regelfall wird sich der Vertrag aus Sicht des Erwerbers
als einheitlicher Kaufvertrag über Soft- und Hardware nach § 433
Abs. 1 BGB darstellen418. Die Gewährleistung und Haftung richtet
sich daher nach den für die Distributionen und den Software-Vertrieb
dargestellten Grundsätzen nach §§ 433 Abs. 1 S. 2, 434 ff., 280
BGB. Auch der Hardwarehersteller haftet daher grundsätzlich für alle
Sach- und Rechtsmängel an Hard- und Software. Ausnahmen bezüglich der Software sind dort denkbar, wo es für den Käufer ersichtlich wird, dass diese lediglich infolge einer Schenkung hinzugegeben
wird. Weiterhin bestehen für die Software die gleichen deliktsrechtlichen Haftungsvoraussetzungen wie oben bereits geschildert.
Abgesehen davon bestehen jedoch gerade in diesem Bereich einige
typische Haftungsrisiken, auf die noch hinzuweisen ist.
413
Vgl. Schiffner, S.244; Goldmann/Redecke, MMR 2002, S.7.
414
Vgl. Deike/CR 2003, S.14; Stickelbrock/ZGS 2003, S.371.
415
416
Vgl. Spindler/VSI, S.82; Grützmacher/ITRB 2002, S.89; Stickelbrock/ZGS 2003,
S.372.
417
Vgl. zu dieser Fallgruppe oben E. I. 1. b. 3.) Embedded-Bereich.
418
Vgl. Metzger/Linux-Mag. 2002.
86
a. Rechtsmängelhaftung
Immer wieder kommt es in der Praxis nämlich vor, dass der Anbieter
es unterlässt, den Käufer auf die Verwendung von freier Software
hinzuweisen, und auch nicht auf die Möglichkeit zur Einsichtnahme in
den Quellcode aufmerksam macht419. Auch wird es häufig versäumt,
die Änderungen an den individuell auf die spezielle Hardware angepassten Programmen erneut unter die GPL zu stellen und zugänglich
zu machen420. Zwar kommt es dem Erwerber in der Regel nicht auf
den Erwerb der besonderen Nutzungsrechte an, die ihm infolge der
GPL zuteil werden können, jedoch ist zu berücksichtigen, dass ein
solcher Verstoß gegen das „Copyleft“-Prinzip zum Verlust der Rechte
des Verkäufers aus der GPL führt. Er darf die Software daher nicht
weiterverbreiten. Für den Kunden bedeutet dies, dass er ebenfalls
keine Rechte an der Software erwerben kann, da die von § 69d UrhG
eingeräumten Mindestrechte nur einem „Berechtigten“ zuteil werden421. Diese Berechtigung hat der Käufer aber wegen der fehlenden
Befugnis des Verkäufers zur Weiterverbreitung der Software nicht
erlangt und kann diese infolge der fehlenden Kenntnisnahme der
GPL auch nicht ohne Weiteres erwerben. Es greift daher die
Rechtsmängelhaftung gem. §§ 435, 437 BGB durch, die dazu führen
kann, dass die Kaufverträge des so handelnden Verkäufers rückabgewickelt werden müssen oder er gegenüber seinen Vertragspartnern schadensersatzpflichtig wird422.
Auch hier kann ein Schadensersatzanspruch wegen Rechtsmangels
sich zudem aus § 434 Abs. 1 S. 3 BGB ergeben, wenn der Verkäufer
mit den besonderen Eigenschaften freier Software für sein Produkt
geworben hat, tatsächlich jedoch proprietäre Software auf dem System installiert ist423.
419
Vgl. Jaeger/Linux-Mag. 2002
420
Vgl. Jaeger/Metzger, OSS, S.173f.
421
Vgl. Spindler/Wiebe, CR 2003, S.878.
422
423
87
b. Produkthaftung
Des Weiteren ist gerade im Embedded-Bereich die besondere Bedeutung sowohl der verschuldensabhängigen als auch der verschuldensunabhängigen Produkthaftung zu würdigen. Die im Fall von reiner Softwareüberlassung bestehenden Anwendungsprobleme der
Produkthaftungsgrundsätze bestehen hier nicht, da immer eine bewegliche Sache in Form der Hardware vorliegt. Ein wichtiger Aspekt
besteht zusätzlich darin, dass der Embedded-Bereich, wie gezeigt,
nicht lediglich auf Computer beschränkt ist, sondern ebenfalls alle
möglichen anderen prozessorgesteuerten Produkte, wie vereinzelte
Haushaltsgeräte, industrielle Produktionsanlagen, Automobiltechnik
und durchaus auch medizinische Geräte umfasst. Von derartigen
Gegenständen und Systemen können teilweise große Gefahren ausgehen und hohe Rechtsgüter abhängig sein. Kommen durch Fehlfunktionen der Software Personen oder Sachen zu Schaden, werden
Produkthaftungsansprüche gegen den Hersteller und Verwender der
Software nach den geschilderten Voraussetzungen stets vorliegen,
weil hier ein einheitliches Produkt vorliegt424. Dem Hersteller bleibt
dann die Möglichkeit, den Nachweis nach § 1 Abs. 2 Nr. 5 ProdHaftG
zu führen, dass dieser Fehler nach dem Stand der Technik zum Zeitpunkt der Auslieferung des Produktes nicht erkannt werden konnte.
Das ProdHaftG legt in § 10 einen Haftungshöchstbetrag von 85 Millionen Euro fest.
4. Individuelle Softwareerstellung
Auch der Bereich der individuellen Softwareerstellung bedarf hier
einer gesonderten Betrachtung. Zwischen dem Besteller und dem
Programmierer liegt hier in der Regel ein Werkvertrag gem. § 631
BGB bzw. vereinzelt auch ein Werklieferungsvertrag gem. § 651 S. 1
BGB vor425. Soweit Letzteres der Fall ist, kann auf die Ausführungen
zum kommerziellen Vertrieb von Open Source Software verwiesen
werden, da hier ebenfalls das Kaufrecht Anwendung findet.
424
425
Vgl. zu den hier möglichen Fallkonstellationen sowie deren Vertragsbestimmung die Erläuterungen unter C. I. 4. Softwareentwicklung.
88
Liegt hingegen ein Werkvertrag vor, wird eine funktionsfähige, an die
besonderen Spezifikationen des Bestellers angepasste Software mitsamt der daran erforderlichen Benutzungsrechte gem. § 69d UrhG
sowie der weitergehenden Befugnisse nach der GPL geschuldet.
In der Regel werden im Bereich der Softwareerstellung individuell
ausgehandelte Gewährleistungs- und Haftungsvereinbarungen getroffen. Da es zumeist Unternehmen sind, die eine nach ihren speziellen Geschäftsbedürfnissen angepasste Software einsetzen wollen, wird oftmals auch ein besonderer Supportvertrag über die Pflege
und Wartung der Software nach Fertigstellung geschlossen werden426. Andererseits ist es dem Werkunternehmer aber auch möglich, seine Haftung und Gewährleistung durch Individualvereinbarung
weit zu beschränken. So ist nach § 639 BGB ein Haftungs- und Gewährleistungssauschluss bis zur Arglist möglich.
Wird der Software durch den Autor jedoch lediglich die GPL beigefügt, so gelten aufgrund der Nichtgeltung ihrer §§ 11, 12 GPL die
gesetzlichen Gewährleistungs- und Haftungsregeln.
a. Gewährleistung
Die gesetzliche Gewährleistung des Softwareerstellers ab Abnahme
des Produkts für Sach- und Rechtsmängel bestimmt sich nach
§§ 633 ff. BGB. Hiernach bestehen auf Seiten des Bestellers eine
Reihe von Gewährleistungsrechten wie Minderung, Selbstvornahme,
Rücktritt und Schadensersatzansprüche - aber auch der Softwareentwickler ist zur Nacherfüllung berechtigt427.
1.) Mitverarbeitung proprietären Codes
Ein besonderes Problem ist bei der individuellen Softwareerstellung
oftmals die Mitverarbeitung proprietären Codes durch den Auftragnehmer, welches in der Praxis bereits bei der Gestaltung von Verträgen über die Überlassung von Individualsoftware Schwierigkeiten
bereitet. Oftmals wird der Programmierer aber auch auf bestehende
Open-Source-Lösungen zurückgreifen, deren Code dann in eigene
426
Vgl. Metzger/Linux-Mag. 2002.
427
Vgl. Stichtenoth/K & R 2003, S.109.
89
Produkte integriert wird. Selbst bei diesem Rückgriff ist es aber nicht
auszuschließen, dass sich in den freien Programmen proprietärer
Code befindet428. Somit besteht immer die Gefahr, dass das erstellte
Werk aufgrund dieses Problems unter einem Rechtsmangel leidet,
weil der Programmierer keine Nutzungsrechte an diesem fremden
Code einräumen kann. Es besteht dann grundsätzlich die Möglichkeit, im Wege der Nacherfüllung die betreffenden Zeilen durch eigene
auszutauschen
oder
die
mitverarbeitete
Open-Source-
Anwendung zu ersetzen. Schlägt dieser Versuch fehl, kann der Besteller vom Vertrag zurücktreten und bei Verschulden des Programmierers, wie dieses bei vorsätzlicher Verwendung proprietären Codes anzunehmen sein wird, Schadensersatz verlangen.
2.) Reichweite des „Copyleft“-Prinzips
Weitere Probleme können sich auch aus der gem. § 2 b GPL bestehenden Pflicht ergeben, Bearbeitungen von „Copyleft-Software“ erneut der GPL zu unterstellen. Wird im Rahmen der individuellen
Software-Entwicklungen auf bestehende Open-Source-Lösungen
zurückgegriffen, müssen die GPL-Pflichten stets beachtet werden.
Sollen nämlich die erstellten Produkte proprietär vermarktet werden,
könnte sonst der umgekehrte Fall eintreten, dass dies aufgrund des
bestehenden „Copylefts“ nicht möglich ist. Auch hier käme es, wie in
den Fällen der GPL-Verletzung im Embedded-Bereich, nicht zur Einräumung der Nutzungsrechte an der Software. Ein Rechtsmangel
läge dann immer vor429.
Weitere Unsicherheiten bestehen auch bezüglich der Reichweite der
GPL. So stellt sich aufgrund der Abgrenzungsschwierigkeiten die,
§ 2 Abs. 2 GPL in Bezug auf die Eigenständigkeit und Unabhängigkeit eines Programms mit sich bringt430, das Problem, inwieweit auf
428
Hiervon geht nach eigener Aussage selbst Richard Stallman aus: „The Linux
sources themselves have a more serious problem with with non-free software: they
actually contain some“, vgl. ders.:http://www.gnu.org/philosophy/linux-gnufreedom.html;
NZZ vom 23.11.2003, „Ohne Copyright kein Copyleft“,
http://www.nzz.ch/2003/09/23/ob/page-article93CDI.html.
429
Vgl. oben E. II. 3. a. Rechtsmängelhaftung.
430
Vgl. dazu oben unter B. II. 2. Das Copyleft-Prinzip.
90
Open-Source-Plattformen (wie auf dem GNU/Linux-Betriebssystem)
aufsetzende proprietäre Produkte als eigenständige Programme in
diesem Sinne zu betrachten sind und daher nicht unter den Voraussetzungen der GPL vertrieben werden müssen431. Teilt sich das Programm mit dem Betriebssystem einzelne Programmroutinen, so wird
teilweise angenommen, dass es sich dabei um ein Werk handelt,
welches auf der GPL-Software basiert und damit nicht von den Bestimmungen der GPL ausgenommen werden kann. Eine Lösung
kann über die Verwendung sog. Programmbibliotheken (DLLDateien) erfolgen, die zumeist nach der GNU-LGPL lizenziert werden, die aus diesem Grund für diesen Zweck einige Lockerungen
vom strengen „Copyleft“-Prinzip vorsieht432. Im Einzelfall kann jedoch
nicht ausgeschlossen werden, dass es in dieser Hinsicht zu GPLVerletzungen kommen kann, die ebenfalls zu einem Rechtsmangel
der geschilderten Art führen können. Im Bereich der individuellen
Auftragssoftwareerstellung kann der Besteller diese Software dann
lediglich betriebsintern verwenden. Ist eine proprietäre Vermarktung
geplant, wird dies durch die GPL ebenfalls vereitelt433.
Diese Sachlage kann insbesondere auch für Distributoren prekäre
Folgen haben, die hinsichtlich ihrer eigenen beigefügten Installationsroutinen oder graphischen Benutzeroberflächen nachweisen müssen, dass dies eigenständige und unabhängige Programme sind434.
Bei der Verwendung von GPL-Entwicklungstools, wie z. B. Compilersoftware, spielen diese Abgrenzungsschwierigkeiten in der Praxis
jedoch keine Rolle, weil die schlichten Arbeits- und Ausgabeergebnisse von GPL-Programmen nicht dem Geltungsbereich von
§ 2 Abs. 2 GPL unterfallen435.
431
Vgl. Wuermeling/Deike, CR 2003, S.90; Lejeune/ITRB 2003, S.11.
432
Vgl. Vgl. Wuermeling/Deike, CR 2003, S.89; Stickelbrock/ZGS 2003, S.370.
Zur LGPL siehe oben B. I. 6. Open-Source-Lizenzmodelle.
433
Vgl. Wuermeling/Deike, CR 2003, S.90.
434
435
Vgl. Wuermeling/Deike, CR 2003, S.88; Siepmann/Jur-PC 1999, Abs.152;
Grützmacher/ITRB 2002, S.86.
91
3.) Dekompilierung § 69e UrhG
Bei der Erstellung von freier Software, die umgekehrt auf proprietären Produkten aufsetzen soll, ist es ggf. zur Herstellung der Interoperabilität im gewissen Umfang notwendig, die Schnittstelleninformationen der proprietären Software im Wege des Dekompilierens zu ermitteln436. Dies ist nach § 69e UrhG grundsätzlich auch zulässig, jedoch sind die hierbei ermittelten Informationen sehr restriktiv zu
handhaben437. Unter Umständen können im Quellcode der daraufhin
entstandenen freien Software Hinweise auf den dekompilierten
Quellcode dieser Programme vorhanden sein, wodurch Untersagungsansprüche des Herstellers ausgelöst werden438. § 7 GPL verbietet zudem eine Verbreitung eines Programms, wenn sich die Einhaltung der GPL-Bedingungen nicht ohne Verletzungen des nationalen Urheber- oder Patentrechts eines anderen existenten Programms
gewährleisten lässt439.
Die vertragliche Verpflichtung, eine funktionsfähige, an die besonderen Bedürfnisse des Bestellers angepasste Software mitsamt der
daran erforderlichen Benutzungsrechte gem. § 69d UrhG sowie der
weitergehenden Befugnisse nach der GPL herzustellen, kann dann
wegen dieses Rechtsmangels nicht erfüllt werden. Dies hat unter den
Voraussetzungen der §§ 633, 634 Nr. 3, 636 BGB Rücktrittsansprüche sowie bei weiterem Vorliegen des Verschuldens gem. §§ 633,
634 Nr. 4, 636, 280 BGB Schadensersatzansprüche des Bestellers
zur Folge.
b. Haftung
Die vertragliche Haftung des Softwareentwicklers bestimmt sich nach
§§ 280 ff. BGB. Demnach hat er für jede schuldhafte Pflichtverlet436
Vgl. Backu/ITRB 2003, S.180f.
437
Vgl. F/N, Vinck, § 69e UrhG, Rn. 1; M/S, Haberstrumpf, § 69e UrhG, Rn.14.
438
Vgl. Backu/ITRB 2003, S.181f.
439
Vgl. § 7 GPL: “If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues), conditions are
imposed on you that contradict the conditions of this License, they do not excuse
you from the conditions of this License. If you cannot distribute so as to satisfy
simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.”.
92
zung Schadensersatz zu leisten. Funktioniert die Software nicht wie
angefordert und löst - beispielsweise im Fall von industriellen Steuerungsanlagen - Schäden durch Produktionsausfall oder unbrauchbare Produkte aus, liegt ein solcher Fall vor440.
Außervertraglich kann eine Haftung nach allgemeinem Deliktsrecht
sowie auch nach Produkthaftungsgesichtspunkten eintreten. Es ist
jedoch zu beachten, dass das ProdHaftG nur dann anwendbar ist,
wenn der Besteller die Software zu privaten Zwecken anfertigen
lässt, was in der Praxis aber wohl sehr selten vorkommen wird.
III. Rechtsverfolgung und Haftungsadressaten
Aufgrund der dezentralen Entwicklung von Open Source Software
nach der „Basar“-Methode kann nicht, wie bei proprietären Produkten
der kommerziellen Software-Industrie, ein einziger Hersteller ausgemacht werden. Nach der Konstruktion der GPL und den tatsächlichen Gegebenheiten können hier mehrere Haftungsadressaten in
Betracht kommen. So ist unter gewissen Umständen auch immer ein
Haftungsdurchgriff auf den Programmautor oder Urheber hinsichtlich
seines Programmteils möglich.
Oftmals werden aber aufgrund der großen Zahl der an den Projekten
Beteiligten die Entwickler einzelner Patches praktisch gar nicht zu
ermitteln sein. Zwar sieht die GPL in § 2a zwingend vor, die jeweiligen Beiträge mit Urhebervermerken zu versehen, jedoch ist dieser
Verpflichtung genügt, wenn statt des Namens des Programmierers
ein einfacher Copyright-Vermerk oder auch ein Pseudonym verwandt
wird441. Die GPL steht damit im Einklang mit dem deutschen Urheberrecht, welches dem Urheber in § 13 S. 2 UrhG gestattet, anonym
zu bleiben442. Zudem können die Programmierer aus den verschiedensten Ländern und Kontinenten stammen. Es ergeben sich so für
die Rechtsverfolgung von entstandenen Ansprüchen unweigerliche
Schwierigkeiten443.
440
441
Vgl. Jaeger/Metzger, GRUR Int. 1999, S.845; Schiffner, S.188f.
442
Vgl. Mestmäcker/Schulze, § 13 UrhG, Rn.4; F/N, Hertin, § 13 UrhG, Rn.8.
443
Vgl. Lejeune/ITRB 2003, S.12; Feil, S.4.
93
Die Organisation der verschiedenen Open-Source-Projekte verläuft
aber durchaus unterschiedlich. So existiert nicht in jedem Fall wie
beim GNU/Linux-Entwicklungsprojekt ein zentrales Komitee, welches
die Verwaltung des offiziellen Sourcebaums übernommen hat. Andere Projekte wickeln sich demgegenüber in unkonventioneller und
anarchischer Form über Internetforen und Newsgroups ab, während
wieder andere in geschlossenen Benutzergruppen bestehen. Gerade
im Fall der geschlossenen Projekte werden die Programmierer daher
enger zusammenarbeiten und so auch einzeln identifizierbar bleiben.
Danach scheint hier ein Rückgriff auf das gesellschaftsrechtliche
Modell von Sester möglich444. Dies scheint insbesondere dort möglich, wo über die GPL hinausgehende Vereinbarungen zwischen den
beteiligten Programmierern getroffen wurden. Erstellen sie im Rahmen ihrer Arbeitsteilung selbstständige Teile des Gesamtkonzepts,
die sie im Nachhinein zusammenfügen, oder arbeiten sie gleichzeitig
an einem gemeinsamen Projekt, so liegen urheberrechtlich Werkverbindungen nach § 9 UrhG oder Miturheberschaft nach § 8 UrhG
vor445. Bezüglich der Verwertung ihrer Werke bilden sie dann entweder eine BGB-Gesellschaft oder eine Gesamthandsgemeinschaft,
wodurch dieses Konzept ebenfalls gestützt wird. In diesen Fällen ist
gerade durch die individuelle Ermittelbarkeit der verschiedenen Autoren dieser Haftungsdurchgriff leichter. Zusätzlich ist auch eine akzessorische Haftung der einzelnen Gesellschafter für die Verbindlichkeiten aus dem gemeinsamen Projekt denkbar446.
In anderen Situationen, in denen sich die einzelnen Beteiligten nicht
ermitteln lassen, wird sich ein Geschädigter wohl vorzüglich an seinen Händler oder den Distributor halten, von dem er die freie Software erworben hat. So werden Letztere vor allem im Bereich der
Produzenten- und Produkthaftung richtigerweise die Anspruchsgegner sein. Dieses Ergebnis erfährt auch eine Rechtfertigung darin,
444
So auch Schiffner, S.234ff., 237.
Vgl. zu diesem Ansatz oben E. I. 2. Gesellschaftsvertragliche Konzepte.
445
Vgl. Jaeger/Metzger, OSS, S.27; Omsels/FS Hertin, S.166f.; Schiffner, S.121ff.
446
94
dass die kommerziellen Verwerter schließlich auch Verdienste aus
der Software erwirtschaften, was eben bei den freiwilligen, unentgeltlich arbeitenden Programmierern nicht der Fall ist.
Zuletzt besteht natürlich auch auf Seiten der Nutzer und Verwender
von Open Source Software die Gefahr einer Inanspruchnahme nach
den §§ 97 ff. UrhG, wenn gegen Urheberrechte Dritter verstoßen
wird447. Sie müssen damit in den weiteren Haftungsadressatenkreis
mit einbezogen werden, werden aber, wie gezeigt, oftmals Regressmöglichkeiten gegenüber demjenigen haben, von dem sie das Programm erworben haben.
F. Fazit
In Ansehung gerade der jüngsten Erfolge des Open-Source-Modells
und des gestiegenen öffentlichen Interesses ist auch in Zukunft mit
einer weiteren Verbreitung freier Software zu rechnen. Es überrascht
daher nicht, dass gerade im Augenblick der größten Aufmerksamkeit
die Kritiker und Vertreter proprietärer Softwareunternehmen Stellung
beziehen, um ihre Position zu verteidigen. Möglicherweise sollten sie
sich dabei auf ein langes Gefecht einstellen.
Nach der vorliegenden Betrachtung ist den Kritikern sicherlich zuzugeben, dass die Einordnung der GPL in das deutsche Rechtssystem an bestimmten Stellen auf Widerstand stößt - von schier unlösbaren Rechtsunsicherheiten zu sprechen, mutet jedoch als pauschal
und nicht gerechtfertigt an. Einige der ausgemachten Probleme
scheinen vielmehr auf Missverständnissen und unzureichender Differenzierung zwischen den verschiedenen Anwendungsbereichen zu
beruhen.
Demgegenüber hat die haftungsrechtliche Bewertung der einzelnen
Fallgruppen gezeigt, dass in der Regel unter Zugrundlegung des
deutschen Rechts durchaus praxisgerechte Lösungen erzielt werden.
Gerade die im Open-Source-Umfeld entstandenen Dienstleistungsangebote, wie insbesondere das Geschäftsmodell der Distributoren,
447
Vgl. Spindler/VSI, S.101f.; Jaeger/Linux-Mag. 2002.
95
zeigen, dass freie Software nicht gewährleistungsfrei bleiben muss.
So besteht gerade beim privaten Einsatz und Erwerb von Open
Source Software ein weitgehender gesetzlicher Schutz durch Gewährleistungs- und Haftungsvorschriften. Dass die daraus folgenden
Verpflichtungen des Anbieters beim gebührenfreien Download über
das Internet auf ein Minimum reduziert sind, kann nicht wirklich überraschen. Letztlich bleibt es der Wahl des Anwenders überlassen, ob
er auf eigene Verantwortung vollkommen kostenfreie Software einsetzen möchte oder sich einem entsprechenden Anbieter zuwenden
und diesen so in die vertragliche Pflicht nehmen will.
Im professionellen Bereich ist es darüber hinaus ohnehin üblich, die
Gewährleistung und Haftung im Rahmen eines Supportvertrags zu
regeln. Hier lässt auch das Gesetz ausreichende Spielräume. So
kann beispielsweise durch zusätzliche Abreden die Haftung im gesetzlich zulässigen Bereich reduziert, aber andererseits auch – gegen Zahlung eines entsprechenden Entgelts – übernommen werden.
Auf diese Weise werden weitere Dienstleistungen ermöglicht, was
nicht zuletzt im Interesse einer gesunden Volkswirtschaft steht.
Bleiben im Einzelfall größere Haftungsrisiken bestehen, wie vor allem
im Embedded-Bereich, so handelt es sich dabei nicht typischerweise
um Probleme freier Software, sondern um allgemein mit der Herstellung und dem Verkauf technischer Systeme verknüpfte Risiken, die
im Rahmen der Kostenkalkulation und durch Versicherungen berücksichtigt werden können. Insgesamt fällt auf, dass viele der diskutierten Fragen, wie beispielsweise auch die vertragliche Einordnung
von Software, im Bereich proprietärer Programme gleichermaßen
bestehen und daher keine spezifischen Rechtsprobleme der Open
Source Software behandeln.
Für die Praxis des Open Source Software-Einsatzes sei es bei der
Vertragsgestaltung dennoch empfohlen, im Rahmen des für den jeweiligen Vertragstyp gesetzlich Möglichen besondere Gewährleistungs- und Haftungsvereinbarungen zu treffen bzw. AGB daraufhin anzupassen, um eine für die eigenen Verhältnisse optimale Lösung herbeizuführen, wie dies im Softwarevertragsrecht auch grund-
96
sätzlich üblich ist. Darüber hinaus sollte sich die Vereinbarung einer
Rechtswahl- und Gerichtsstandsklausel auf der anwaltlichen Checkliste befinden, um dem erwähnten globalen Rechtsanwendungsrisiko
zu begegnen. Im Bereich der individuellen Softwareerstellung wird
von manchen Autoren die Verwendung elektronischer Signaturen
vorgeschlagen, um die Authentizität des verwendeten Codes zu gewährleisten448. Ob dies mit dem Konzept freier Software in Einklang
steht, mag jedoch bezweifelt werden.
Der deutsche Gesetzgeber hat die Bedürfnisse dieser Entwicklung
erkannt und durch die Einführung der sog. „Linux-Klausel“ des § 32
Abs. 3 S. 3 UrhG sein legislatives Feingefühl bereits unter Beweis
gestellt. Abschließend bleibt zu hoffen, dass er dieses beibehält und
auch weiterhin bestrebt sein wird, die verbleibenden Rechtsunsicherheiten, wie sie auch im Urheberrecht noch bestehen, aus dem
Weg zu räumen, um so auch die Zukunft dieses erfolgreichen und
demokratischen Konzepts sicherzustellen. Eine besondere Herausforderung dürfte dabei die vieldiskutierte Frage der Patentierbarkeit
von Software bieten. Die jüngsten Entwicklungen machen in dieser
Hinsicht jedenfalls Mut.
448
So Köhntopp/Köhntopp/Pfitzmann, DuD 2000, S.511; Jürgens/DSB 2000, S.6.
97
G. Anhang: Die GNU-General Public License und ihre deutsche
Übersetzung
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General
Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all
its users. This General Public License applies to most of the Free Software Foundation's software and to any other program
whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public
License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure
that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source
code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you
can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the
rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they
know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to
copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this
free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is
not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
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.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. 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. The "Program", below, refers to any such program or work, and a
"work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work
containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.
(Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the Program). Whether that is true depends on what the Program
does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all
the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of
this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in
exchange for a fee.
98
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy
and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
• a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any
change.
• b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or
any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
• c) 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. (Exception: if the Program itself is interactive but does
not normally print such an announcement, your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply
to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole
which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for
other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program)
on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the
terms of Sections 1 and 2 above provided that you also do one of the following:
•
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the
terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
• b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
• c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative
is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work,
complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the
scripts used to control compilation and installation of the executable. However, as a special exception, the source code
distributed need not include anything that is normally distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies
the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated
so long as such parties remain in full compliance.
5. 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.
Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this
License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
6. 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. You may not impose
any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance
by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent
issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at
all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies
99
directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from
distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is
intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is
implemented by public license practices. Many people have made generous contributions to the wide range of software
distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or
she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License may add an explicit geographical distribution limitation
excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such
new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to
it and "any later version", you have the option of following the terms and conditions either of that version or of any later version
published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose
any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the
author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software
Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of
all derivatives of our free software and of promoting the sharing and reuse of software generally.
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. 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.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to
make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is
found.
one line to give the program's name and an idea of what it does.
Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
100
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'. This is free software, and you are welcome
to redistribute it under certain conditions; type `show c'
for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course,
the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu
items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the
program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright
interest in the program `Gnomovision'
(which makes passes at compilers) written
by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a
subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you
want to do, use the GNU Lesser General Public License instead of this License.
101
Deutsche Übersetzung der GNU General Public License
Erstellt im Auftrag der S.u.S.E. GmbH http://www.suse.de
von Katja Lachmann Übersetzungen,
überarbeitet von Peter Gerwinski, G-N-U GmbH http://www.g-n-u.de
(31. Oktober 1996, 4. Juni 2000)
Diese Übersetzung wird mit der Absicht angeboten, das Verständnis der GNU General Public License (GNU-GPL) zu erleichtern.
Es handelt sich jedoch nicht um eine offizielle oder im rechtlichen Sinne anerkannte Übersetzung.
Die Free Software Foundation (FSF) ist nicht der Herausgeber dieser Übersetzung, und sie hat diese Übersetzung auch nicht als
rechtskräftigen Ersatz für die Original-GNU-GPL anerkannt. Da die Übersetzung nicht sorgfältig von Anwälten überprüft wurde,
können die Übersetzer nicht garantieren, daß die Übersetzung die rechtlichen Aussagen der GNU-GPL exakt wiedergibt. Wenn
Sie sichergehen wollen, daß von Ihnen geplante Aktivitäten im Sinne der GNU-GPL gestattet sind, halten Sie sich bitte an die
englischsprachige Originalversion.
Die Free Software Foundation möchte Sie darum bitten, diese Übersetzung nicht als offizielle Lizenzbedingungen für von Ihnen
geschriebene Programme zu verwenden. Bitte benutzen Sie hierfür stattdessen die von der Free Software Foundation
herausgegebene englischsprachige Originalversion.
This is a translation of the GNU General Public License into German. This translation is distributed in the hope that it will facilitate
understanding, but it is not an official or legally approved translation.
The Free Software Foundation is not the publisher of this translation and has not approved it as a legal substitute for the
authentic GNU General Public License. The translation has not been reviewed carefully by lawyers, and therefore the translator
cannot be sure that it exactly represents the legal meaning of the GNU General Public License. If you wish to be sure whether
your planned activities are permitted by the GNU General Public License, please refer to the authentic English version.
The Free Software Foundation strongly urges you not to use this translation as the official distribution terms for your programs;
instead, please use the authentic English version published by the Free Software Foundation.
GNU General Public License
Deutsche Übersetzung der Version 2, Juni 1991
Copyright © 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
Es ist jedermann gestattet, diese Lizenzurkunde zu vervielfältigen und unveränderte Kopien zu verbreiten; Änderungen sind
jedoch nicht erlaubt.
Diese Übersetzung ist kein rechtskräftiger Ersatz für die englischsprachige Originalversion!
Vorwort
Die meisten Softwarelizenzen sind daraufhin entworfen worden, Ihnen die Freiheit zu nehmen, die Software weiterzugeben und
zu verändern. Im Gegensatz dazu soll Ihnen die GNU General Public License , die Allgemeine Öffentliche GNU-Lizenz,
ebendiese Freiheit garantieren. Sie soll sicherstellen, daß die Software für alle Benutzer frei ist. Diese Lizenz gilt für den Großteil
der von der Free Software Foundation herausgegebenen Software und für alle anderen Programme, deren Autoren ihr
Datenwerk dieser Lizenz unterstellt haben. Auch Sie können diese Möglichkeit der Lizenzierung für Ihre Programme anwenden.
(Ein anderer Teil der Software der Free Software Foundation unterliegt stattdessen der GNU Library General Public License , der
Allgemeinen Öffentlichen GNU-Lizenz für Bibliotheken.) [Mittlerweile wurde die GNU Library Public License von der GNU Lesser
Public License abgelöst - Anmerkung des Übersetzers.]
Die Bezeichnung ,,freie`` Software bezieht sich auf Freiheit, nicht auf den Preis. Unsere Lizenzen sollen Ihnen die Freiheit
garantieren, Kopien freier Software zu verbreiten (und etwas für diesen Service zu berechnen, wenn Sie möchten), die
Möglichkeit, die Software im Quelltext zu erhalten oder den Quelltext auf Wunsch zu bekommen. Die Lizenzen sollen
garantieren, daß Sie die Software ändern oder Teile davon in neuen freien Programmen verwenden dürfen - und daß Sie wissen,
daß Sie dies alles tun dürfen.
Um Ihre Rechte zu schützen, müssen wir Einschränkungen machen, die es jedem verbieten, Ihnen diese Rechte zu verweigern
oder Sie aufzufordern, auf diese Rechte zu verzichten. Aus diesen Einschränkungen folgen bestimmte Verantwortlichkeiten für
Sie, wenn Sie Kopien der Software verbreiten oder sie verändern.
Beispielsweise müssen Sie den Empfängern alle Rechte gewähren, die Sie selbst haben, wenn Sie - kostenlos oder gegen
Bezahlung - Kopien eines solchen Programms verbreiten. Sie müssen sicherstellen, daß auch die Empfänger den Quelltext
erhalten bzw. erhalten können. Und Sie müssen ihnen diese Bedingungen zeigen, damit sie ihre Rechte kennen.
102
Wir schützen Ihre Rechte in zwei Schritten: (1) Wir stellen die Software unter ein Urheberrecht (Copyright), und (2) wir bieten
Ihnen diese Lizenz an, die Ihnen das Recht gibt, die Software zu vervielfältigen, zu verbreiten und/oder zu verändern.
Um die Autoren und uns zu schützen, wollen wir darüberhinaus sicherstellen, daß jeder erfährt, daß für diese freie Software
keinerlei Garantie besteht. Wenn die Software von jemand anderem modifiziert und weitergegeben wird, möchten wir, daß die
Empfänger wissen, daß sie nicht das Original erhalten haben, damit irgendwelche von anderen verursachte Probleme nicht den
Ruf des ursprünglichen Autors schädigen.
Schließlich und endlich ist jedes freie Programm permanent durch Software-Patente bedroht. Wir möchten die Gefahr
ausschließen, daß Distributoren eines freien Programms individuell Patente lizensieren - mit dem Ergebnis, daß das Programm
proprietär würde. Um dies zu verhindern, haben wir klargestellt, daß jedes Patent entweder für freie Benutzung durch jedermann
lizenziert werden muß oder überhaupt nicht lizenziert werden darf.
Es folgen die genauen Bedingungen für die Vervielfältigung, Verbreitung und Bearbeitung:
Allgemeine Öffentliche GNU-Lizenz
Bedingungen für die Vervielfältigung, Verbreitung und Bearbeitung
§0. Diese Lizenz gilt für jedes Programm und jedes andere Datenwerk, in dem ein entsprechender Vermerk des CopyrightInhabers darauf hinweist, daß das Datenwerk unter den Bestimmungen dieser General Public License verbreitet werden darf. Im
folgenden wird jedes derartige Programm oder Datenwerk als ,,das Programm`` bezeichnet; die Formulierung ,,auf dem
Programm basierendes Datenwerk`` bezeichnet das Programm sowie jegliche Bearbeitung des Programms im
urheberrechtlichen Sinne, also ein Datenwerk, welches das Programm, auch auszugsweise, sei es unverändert oder verändert
und/oder in eine andere Sprache übersetzt, enthält. (Im folgenden wird die Übersetzung ohne Einschränkung als ,,Bearbeitung``
eingestuft.) Jeder Lizenznehmer wird im folgenden als ,,Sie`` angesprochen.
Andere Handlungen als Vervielfältigung, Verbreitung und Bearbeitung werden von dieser Lizenz nicht berührt; sie fallen nicht in
ihren Anwendungsbereich. Der Vorgang der Ausführung des Programms wird nicht eingeschränkt, und die Ausgaben des
Programms unterliegen dieser Lizenz nur, wenn der Inhalt ein auf dem Programm basierendes Datenwerk darstellt (unabhängig
davon, daß die Ausgabe durch die Ausführung des Programmes erfolgte). Ob dies zutrifft, hängt von den Funktionen des
Programms ab.
§1. Sie dürfen auf beliebigen Medien unveränderte Kopien des Quelltextes des Programms, wie sie ihn erhalten haben,
anfertigen und verbreiten. Voraussetzung hierfür ist, daß Sie mit jeder Kopie einen entsprechenden Copyright-Vermerk sowie
einen Haftungsausschluß veröffentlichen, alle Vermerke, die sich auf diese Lizenz und das Fehlen einer Garantie beziehen,
unverändert lassen und desweiteren allen anderen Empfängern des Programms zusammen mit dem Programm eine Kopie
dieser Lizenz zukommen lassen.
Sie dürfen für den eigentlichen Kopiervorgang eine Gebühr verlangen. Wenn Sie es wünschen, dürfen Sie auch gegen Entgeld
eine Garantie für das Programm anbieten.
§2. Sie dürfen Ihre Kopie(n) des Programms oder eines Teils davon verändern, wodurch ein auf dem Programm basierendes
Datenwerk entsteht; Sie dürfen derartige Bearbeitungen unter den Bestimmungen von Paragraph 1 vervielfältigen und verbreiten,
vorausgesetzt, daß zusätzlich alle im folgenden genannten Bedingungen erfüllt werden:
1.
Sie müssen die veränderten Dateien mit einem auffälligen Vermerk versehen, der auf die von Ihnen vorgenommene
Modifizierung und das Datum jeder Änderung hinweist.
2.
Sie müssen dafür sorgen, daß jede von Ihnen verbreitete oder veröffentlichte Arbeit, die ganz oder teilweise von dem Programm
oder Teilen davon abgeleitet ist, Dritten gegenüber als Ganzes unter den Bedingungen dieser Lizenz ohne Lizenzgebühren zur
Verfügung gestellt wird.
3.
Wenn das veränderte Programm normalerweise bei der Ausführung interaktiv Kommandos einliest, müssen Sie dafür sorgen,
daß es, wenn es auf dem üblichsten Wege für solche interaktive Nutzung gestartet wird, eine Meldung ausgibt oder ausdruckt,
die einen geeigneten Copyright-Vermerk enthält sowie einen Hinweis, daß es keine Gewährleistung gibt (oder anderenfalls, daß
Sie Garantie leisten), und daß die Benutzer das Programm unter diesen Bedingungen weiter verbreiten dürfen. Auch muß der
Benutzer darauf hingewiesen werden, wie er eine Kopie dieser Lizenz ansehen kann. (Ausnahme: Wenn das Programm selbst
interaktiv arbeitet, aber normalerweise keine derartige Meldung ausgibt, muß Ihr auf dem Programm basierendes Datenwerk
auch keine solche Meldung ausgeben).
Diese Anforderungen gelten für das bearbeitete Datenwerk als Ganzes. Wenn identifizierbare Teile des Datenwerkes nicht von
dem Programm abgeleitet sind und vernünftigerweise als unabhängige und eigenständige Datenwerke für sich selbst zu
betrachten sind, dann gelten diese Lizenz und ihre Bedingungen nicht für die betroffenen Teile, wenn Sie diese als eigenständige
Datenwerke weitergeben. Wenn Sie jedoch dieselben Abschnitte als Teil eines Ganzen weitergeben, das ein auf dem Programm
basierendes Datenwerk darstellt, dann muß die Weitergabe des Ganzen nach den Bedingungen dieser Lizenz erfolgen, deren
Bedingungen für weitere Lizenznehmer somit auf das gesamte Ganze ausgedehnt werden - und somit auf jeden einzelnen Teil,
unabhängig vom jeweiligen Autor.
103
Somit ist es nicht die Absicht dieses Abschnittes, Rechte für Datenwerke in Anspruch zu nehmen oder Ihnen die Rechte für
Datenwerke streitig zu machen, die komplett von Ihnen geschrieben wurden; vielmehr ist es die Absicht, die Rechte zur Kontrolle
der Verbreitung von Datenwerken, die auf dem Programm basieren oder unter seiner auszugsweisen Verwendung
zusammengestellt worden sind, auszuüben.
Ferner bringt auch das einfache Zusammenlegen eines anderen Datenwerkes, das nicht auf dem Programm basiert, mit dem
Programm oder einem auf dem Programm basierenden Datenwerk auf ein- und demselben Speicher- oder Vertriebsmedium
dieses andere Datenwerk nicht in den Anwendungsbereich dieser Lizenz.
§3. Sie dürfen das Programm (oder ein darauf basierendes Datenwerk gemäß Paragraph 2) als Objectcode oder in ausführbarer
Form unter den Bedingungen der Paragraphen 1 und 2 kopieren und weitergeben - vorausgesetzt, daß Sie außerdem eine der
folgenden Leistungen erbringen:
1.
Liefern Sie das Programm zusammen mit dem vollständigen zugehörigen maschinenlesbaren Quelltext auf einem für den
Datenaustausch üblichen Medium aus, wobei die Verteilung unter den Bedingungen der Paragraphen 1 und 2 erfolgen muß.
Oder:
2.
Liefern Sie das Programm zusammen mit einem mindestens drei Jahre lang gültigen schriftlichen Angebot aus, jedem Dritten
eine vollständige maschinenlesbare Kopie des Quelltextes zur Verfügung zu stellen - zu nicht höheren Kosten als denen, die
durch den physikalischen Kopiervorgang anfallen -, wobei der Quelltext unter den Bedingungen der Paragraphen 1 und 2 auf
einem für den Datenaustausch üblichen Medium weitergegeben wird. Oder:
3.
Liefern Sie das Programm zusammen mit dem schriftlichen Angebot der Zurverfügungstellung des Quelltextes aus, das Sie
selbst erhalten haben. (Diese Alternative ist nur für nicht-kommerzielle Verbreitung zulässig und nur, wenn Sie das Programm als
Objectcode oder in ausführbarer Form mit einem entsprechenden Angebot gemäß Absatz b erhalten haben.)
Unter dem Quelltext eines Datenwerkes wird diejenige Form des Datenwerkes verstanden, die für Bearbeitungen vorzugsweise
verwendet wird. Für ein ausführbares Programm bedeutet ,,der komplette Quelltext``: Der Quelltext aller im Programm
enthaltenen Module einschließlich aller zugehörigen Modulschnittstellen-Definitionsdateien sowie der zur Compilation und
Installation verwendeten Skripte. Als besondere Ausnahme jedoch braucht der verteilte Quelltext nichts von dem zu enthalten,
was üblicherweise (entweder als Quelltext oder in binärer Form) zusammen mit den Hauptkomponenten des Betriebssystems
(Kernel, Compiler usw.) geliefert wird, unter dem das Programm läuft - es sei denn, diese Komponente selbst gehört zum
ausführbaren Programm.
Wenn die Verbreitung eines ausführbaren Programms oder von Objectcode dadurch erfolgt, daß der Kopierzugriff auf eine dafür
vorgesehene Stelle gewährt wird, so gilt die Gewährung eines gleichwertigen Zugriffs auf den Quelltext als Verbreitung des
Quelltextes, auch wenn Dritte nicht dazu gezwungen sind, den Quelltext zusammen mit dem Objectcode zu kopieren.
§4. Sie dürfen das Programm nicht vervielfältigen, verändern, weiter lizenzieren oder verbreiten, sofern es nicht durch diese
Lizenz ausdrücklich gestattet ist. Jeder anderweitige Versuch der Vervielfältigung, Modifizierung, Weiterlizenzierung und
Verbreitung ist nichtig und beendet automatisch Ihre Rechte unter dieser Lizenz. Jedoch werden die Lizenzen Dritter, die von
Ihnen Kopien oder Rechte unter dieser Lizenz erhalten haben, nicht beendet, solange diese die Lizenz voll anerkennen und
befolgen.
§5. Sie sind nicht verpflichtet, diese Lizenz anzunehmen, da Sie sie nicht unterzeichnet haben. Jedoch gibt Ihnen nichts anderes
die Erlaubnis, das Programm oder von ihm abgeleitete Datenwerke zu verändern oder zu verbreiten. Diese Handlungen sind
gesetzlich verboten, wenn Sie diese Lizenz nicht anerkennen. Indem Sie das Programm (oder ein darauf basierendes
Datenwerk) verändern oder verbreiten, erklären Sie Ihr Einverständnis mit dieser Lizenz und mit allen ihren Bedingungen
bezüglich der Vervielfältigung, Verbreitung und Veränderung des Programms oder eines darauf basierenden Datenwerks.
§6. Jedesmal, wenn Sie das Programm (oder ein auf dem Programm basierendes Datenwerk) weitergeben, erhält der Empfänger
automatisch vom ursprünglichen Lizenzgeber die Lizenz, das Programm entsprechend den hier festgelegten Bestimmungen zu
vervielfältigen, zu verbreiten und zu verändern. Sie dürfen keine weiteren Einschränkungen der Durchsetzung der hierin
zugestandenen Rechte des Empfängers vornehmen. Sie sind nicht dafür verantwortlich, die Einhaltung dieser Lizenz durch Dritte
durchzusetzen.
§7. Sollten Ihnen infolge eines Gerichtsurteils, des Vorwurfs einer Patentverletzung oder aus einem anderen Grunde (nicht auf
Patentfragen begrenzt) Bedingungen (durch Gerichtsbeschluß, Vergleich oder anderweitig) auferlegt werden, die den
Bedingungen dieser Lizenz widersprechen, so befreien Sie diese Umstände nicht von den Bestimmungen dieser Lizenz. Wenn
es Ihnen nicht möglich ist, das Programm unter gleichzeitiger Beachtung der Bedingungen in dieser Lizenz und Ihrer
anderweitigen Verpflichtungen zu verbreiten, dann dürfen Sie als Folge das Programm überhaupt nicht verbreiten. Wenn zum
Beispiel ein Patent nicht die gebührenfreie Weiterverbreitung des Programms durch diejenigen erlaubt, die das Programm direkt
oder indirekt von Ihnen erhalten haben, dann besteht der einzige Weg, sowohl das Patentrecht als auch diese Lizenz zu
befolgen, darin, ganz auf die Verbreitung des Programms zu verzichten.
Sollte sich ein Teil dieses Paragraphen als ungültig oder unter bestimmten Umständen nicht durchsetzbar erweisen, so soll
dieser Paragraph seinem Sinne nach angewandt werden; im übrigen soll dieser Paragraph als Ganzes gelten.
Zweck dieses Paragraphen ist nicht, Sie dazu zu bringen, irgendwelche Patente oder andere Eigentumsansprüche zu verletzen
oder die Gültigkeit solcher Ansprüche zu bestreiten; dieser Paragraph hat einzig den Zweck, die Integrität des
104
Verbreitungssystems der freien Software zu schützen, das durch die Praxis öffentlicher Lizenzen verwirklicht wird. Viele Leute
haben großzügige Beiträge zu dem großen Angebot der mit diesem System verbreiteten Software im Vertrauen auf die
konsistente Anwendung dieses Systems geleistet; es liegt am Autor/Geber, zu entscheiden, ob er die Software mittels
irgendeines anderen Systems verbreiten will; ein Lizenznehmer hat auf diese Entscheidung keinen Einfluß.
Dieser Paragraph ist dazu gedacht, deutlich klarzustellen, was als Konsequenz aus dem Rest dieser Lizenz betrachtet wird.
§8. Wenn die Verbreitung und/oder die Benutzung des Programms in bestimmten Staaten entweder durch Patente oder durch
urheberrechtlich geschützte Schnittstellen eingeschränkt ist, kann der Urheberrechtsinhaber, der das Programm unter diese
Lizenz gestellt hat, eine explizite geographische Begrenzung der Verbreitung angeben, in der diese Staaten ausgeschlossen
werden, so daß die Verbreitung nur innerhalb und zwischen den Staaten erlaubt ist, die nicht ausgeschlossen sind. In einem
solchen Fall beinhaltet diese Lizenz die Beschränkung, als wäre sie in diesem Text niedergeschrieben.
§9. Die Free Software Foundation kann von Zeit zu Zeit überarbeitete und/oder neue Versionen der General Public License
veröffentlichen. Solche neuen Versionen werden vom Grundprinzip her der gegenwärtigen entsprechen, können aber im Detail
abweichen, um neuen Problemen und Anforderungen gerecht zu werden.
Jede Version dieser Lizenz hat eine eindeutige Versionsnummer. Wenn in einem Programm angegeben wird, daß es dieser
Lizenz in einer bestimmten Versionsnummer oder ,,jeder späteren Version`` (``any later version'') unterliegt, so haben Sie die
Wahl, entweder den Bestimmungen der genannten Version zu folgen oder denen jeder beliebigen späteren Version, die von der
Free Software Foundation veröffentlicht wurde. Wenn das Programm keine Versionsnummer angibt, können Sie eine beliebige
Version wählen, die je von der Free Software Foundation veröffentlicht wurde.
§10. Wenn Sie den Wunsch haben, Teile des Programms in anderen freien Programmen zu verwenden, deren Bedingungen für
die Verbreitung anders sind, schreiben Sie an den Autor, um ihn um die Erlaubnis zu bitten. Für Software, die unter dem
Copyright der Free Software Foundation steht, schreiben Sie an die Free Software Foundation ; wir machen zu diesem Zweck
gelegentlich Ausnahmen. Unsere Entscheidung wird von den beiden Zielen geleitet werden, zum einen den freien Status aller
von unserer freien Software abgeleiteten Datenwerke zu erhalten und zum anderen das gemeinschaftliche Nutzen und
Wiederverwenden von Software im allgemeinen zu fördern.
Keine Gewährleistung
§11. Da das Programm ohne jegliche Kosten lizenziert wird, besteht keinerlei Gewährleistung für das Programm, soweit
dies gesetzlich zulässig ist. Sofern nicht anderweitig schriftlich bestätigt, stellen die Copyright-Inhaber und/oder Dritte
das Programm so zur Verfügung, ,,wie es ist``, ohne irgendeine Gewährleistung, weder ausdrücklich noch implizit,
einschließlich - aber nicht begrenzt auf - Marktreife oder Verwendbarkeit für einen bestimmten Zweck. Das volle Risiko
bezüglich Qualität und Leistungsfähigkeit des Programms liegt bei Ihnen. Sollte sich das Programm als fehlerhaft
herausstellen, liegen die Kosten für notwendigen Service, Reparatur oder Korrektur bei Ihnen.
§12. In keinem Fall, außer wenn durch geltendes Recht gefordert oder schriftlich zugesichert, ist irgendein CopyrightInhaber oder irgendein Dritter, der das Programm wie oben erlaubt modifiziert oder verbreitet hat, Ihnen gegenüber für
irgendwelche Schäden haftbar, einschließlich jeglicher allgemeiner oder spezieller Schäden, Schäden durch
Seiteneffekte (Nebenwirkungen) oder Folgeschäden, die aus der Benutzung des Programms oder der Unbenutzbarkeit
des Programms folgen (einschließlich - aber nicht beschränkt auf - Datenverluste, fehlerhafte Verarbeitung von Daten,
Verluste, die von Ihnen oder anderen getragen werden müssen, oder dem Unvermögen des Programms, mit
irgendeinem anderen Programm zusammenzuarbeiten), selbst wenn ein Copyright-Inhaber oder Dritter über die
Möglichkeit solcher Schäden unterrichtet worden war.
Ende der Bedingungen
Anhang: Wie Sie diese Bedingungen auf Ihre eigenen,
neuen Programme anwenden können
Wenn Sie ein neues Programm entwickeln und wollen, daß es vom größtmöglichen Nutzen für die Allgemeinheit ist, dann
erreichen Sie das am besten, indem Sie es zu freier Software machen, die jeder unter diesen Bestimmungen weiterverbreiten
und verändern kann.
Um dies zu erreichen, fügen Sie die folgenden Vermerke zu Ihrem Programm hinzu. Am sichersten ist es, sie an den Anfang
einer jeden Quelldatei zu stellen, um den Gewährleistungsausschluß möglichst deutlich darzustellen; zumindest aber sollte jede
Datei eine Copyright-Zeile besitzen sowie einen kurzen Hinweis darauf, wo die vollständigen Vermerke zu finden sind.
[eine Zeile mit dem Programmnamen und einer kurzen Beschreibung]
Copyright (C) [Jahr] [Name des Autors]
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
105
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
Auf Deutsch:
[eine Zeile mit dem Programmnamen und einer kurzen Beschreibung]
Copyright (C) [Jahr] [Name des Autors]
Dieses Programm ist freie Software. Sie können es unter den Bedingungen der GNU General Public License, wie von der Free
Software Foundation veröffentlicht, weitergeben und/oder modifizieren, entweder gemäß Version 2 der Lizenz oder (nach Ihrer
Option) jeder späteren Version.
Die Veröffentlichung dieses Programms erfolgt in der Hoffnung, daß es Ihnen von Nutzen sein wird, aber OHNE IRGENDEINE
GARANTIE, sogar ohne die implizite Garantie der MARKTREIFE oder der VERWENDBARKEIT FÜR EINEN BESTIMMTEN
ZWECK. Details finden Sie in der GNU General Public License.
Sie sollten eine Kopie der GNU General Public License zusammen mit diesem Programm erhalten haben. Falls nicht, schreiben
Sie an die Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
Fügen Sie auch einen kurzen Hinweis hinzu, wie Sie elektronisch und per Brief erreichbar sind.
Wenn Ihr Programm interaktiv ist, sorgen Sie dafür, daß es nach dem Start einen kurzen Vermerk ausgibt:
version 69, Copyright (C) [Jahr] [Name des Autors]
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome
to redistribute it under certain conditions; type `show c' for details.
Auf Deutsch:
Version 69, Copyright (C) [Jahr] [Name des Autors] Für Gnomovision besteht KEINERLEI GARANTIE; geben Sie `show w' für
Details ein. Gnonovision ist freie Software, die Sie unter bestimmten Bedingungen weitergeben dürfen; geben Sie `show c' für
Details ein.
Die hypothetischen Kommandos `show w' und `show c' sollten die entsprechenden Teile der GNU-GPL anzeigen. Natürlich
können die von Ihnen verwendeten Kommandos anders heißen als `show w' und `show c'; es könnten auch Mausklicks oder
Menüpunkte sein - was immer am besten in Ihr Programm paßt.
Soweit vorhanden, sollten Sie auch Ihren Arbeitgeber (wenn Sie als Programmierer arbeiten) oder Ihre Schule einen CopyrightVerzicht für das Programm unterschreiben lassen. Hier ein Beispiel. Die Namen müssen Sie natürlich ändern.
Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written
by James Hacker.
[Unterschrift von Ty Coon], 1 April 1989
Ty Coon, President of Vice
Auf Deutsch:
Die Yoyodyne GmbH erhebt keinen urheberrechtlichen Anspruch auf das von James Hacker geschriebene Programm
,Gnomovision` (einem Schrittmacher für Compiler).
[Unterschrift von Ty Coon], 1. April 1989
Ty Coon, Vizepräsident
Diese General Public License gestattet nicht die Einbindung des Programms in proprietäre Programme. Ist Ihr Programm eine
Funktionsbibliothek, so kann es sinnvoller sein, das Binden proprietärer Programme mit dieser Bibliothek zu gestatten. Wenn Sie
dies tun wollen, sollten Sie die GNU Library General Public License anstelle dieser Lizenz verwenden.

Abschlussarbeit im Ergänzungsstudiengang

Transcrição

Documentos relacionados

Anmeldeformblatt_2013

Lieber Freund der rheinischen Volksmusik! Erstaunlich!

Wetterfester 12dBi 5GHz High Power Wireless N PoE Access Point

Quick Installation Guide TEW-637AP

Benutzerhandbuch

Erstellen Bericht (Form C) in e

Dahn, Jazzfreunde Dahn 19.01.2014

erich jaeger - jaeger poway

Über GPL und das Tuxbox Projekt.

Neustadt, Kleinkunstverein Reblaus, 25.04.2009