Leseprobe
Inhaltsverzeichnis
Literaturverzeichnis
Internetadressen
Gliederung
A. Einleitung
B. Erster Teil
I. Begriffserklärung
1. Open-Source-Software
2. Eingebettete Systeme
II. Bedeutung und Verbreitung in der heutigen Zeit
C. Zweiter Teil
I. Lizenzvertragssystem
1. GNU General Public License
a. GPL v2
b. GPL v3
c. Anwendbarkeit nach deutschem Recht
aa. GPL als Allgemeine Geschäftsbedingung
bb. Urheberrechtliche Besonderheiten
d. Probleme bei eingebetteten Systemen
aa. GPL bei Embedded Systems
bb. Digital Rights Management
cc. Der „virale Effekt“
(1) Der „virale Effekt“ nach der GPL v2
(2) Der „virale Effekt“ nach der GPL v3
(3) Fazit
dd. Wegfall der Nutzungsrechte
ee. Any-later-version-Klausel
2. Andere Lizenzen.
a. Beispiele
b. Lizenzkompatibilität
II. Anspruchsumfang bei Verletzung der GPL
1. Verletzungsfolgen
2. Vertragliche Ansprüche
3. Gesetzliche Ansprüche
a. Ansprüche des Urhebers
b. Ansprüche der Miturheber.
c. Ansprüche von Inhabern abgeleiteter Rechte
III. Gewährleistung und Haftung
D. Dritter Teil
I. Konflikt zwischen Patentrecht und Open-Source-Software
II. Patentierung von computerimplementierten Erfindungen
1. Auswirkungen auf eingebettete Open-Source-Software
2. Konfliktlösungen
3. Fazit
E. Zusammenfassung
F. Anhang
Lizenztext der GNU General Public License Version 1
Lizenztext der GNU General Public License Version 2
Lizenztext der GNU General Public License Version 3
Informationsdokument der Firma AVM bzgl. der Fritzbox WLAN FON 7112
Lizenzinformation der Firma AVM
Literaturverzeichnis
Aleman, Leonardo: Proprietäre Systeme mit Open-Source-Software, in: Elektronik 2002, S. 82 - 85
Beardwood, John P./Alleyne, Andrew C.: The Price of Binary Freedom: The Challenge of Open Hybrid Software, in: Cri 2006, S. 97 - 104
B ö cker, Lina Barbara: Computerprogramme zwischen Werk und Erfindung, in: Wirtschaftsrecht und Wirtschaftspolitik - Band 229, hrsg. von Mestmäcker/Möschel/Hellwig, 2009, Baden-Baden, S. 190 - 197
B ü scher, Wolfgang/Dittmer, Stefan/Schiwy, Peter (Hrsg.): Gewerblicher Rechtsschutz - Urheberrecht - Medienrecht - Kommentar, 2 Auflage 2011, Köln
Deike, Thies: Open Source Software: IPR-Fragen und Einordnung ins deutsche Rechtssystem, in: CR 2003, S. 9 - 18
Funk, Axel/Zeifang, Gregor: Die GNU General Public License, Version 3, in: CR 2007, S. 617 - 624
Gerlach, Carsten: Praxisprobleme der Open-Source-Lizenzierung, in: CR 2006, S. 649 - 654
Gr ü tzmacher, Malte: Open Source Software und Embedded Systems, in: ITRB 2009, S. 184 - 189
Grzeszick, Bernd: Freie Software: Eine Widerlegung der Urheberrechtstheorie?, in: MMR 200, S. 412 - 417
Habinger, Marc/Wendler, Svenja: Generative Software-Entwicklung für eingebettete Systeme mit Open-Source, in: ObjektSpektrum 2007, S. 26 - 31
Hoeren, Thomas/Gr ä big, Johannes (Hrsg.): Entwicklung des Internet- und Multimediarechts im Jahr 2009, in: MMR 6/2010 Beilage
Karl, Christof: Der urheberrechtliche Schutzbereich von Computerprogrammen, in: Information und Recht, Band 72, hrsg. von Hoeren/Spindler/Holznagel/ Gounalakis/Burkert/Dreier, 2009, München
Koch, Frank A.: Probleme beim Wechsel zur neuen Version 3 der General Public License (Teil 1), in: ITRB 2007, S. 261 - 263
Koch, Frank A.: Rechtsrisiko Open Source Software?, in: Informatik Spektrum 2004, S.
55 - 60
Koch, Frank A.: Urheber- und kartellrechtliche Aspekte der Nutzung von Open-Source- Software (I), in: CR 2000, S. 273 - 281
Koch, Frank A.: Urheber- und kartellrechtliche Aspekte der Nutzung von Open-Source- Software (II), in: CR 2000, S. 333 - 344
Koglin, Olaf: Die Nutzung von Open Source Software unter neuen GPL-Versionen nach der „any later version“-Klausel, in: CR 2008, S. 137 - 143
Koglin, Olaf: Opensourcerecht, in: Schriften zum Wirtschafts- und Medienrecht,
Steuerrecht und Zivilprozeßrecht - Band 31, hrsg. von Costede/Spindler, 2007, Frankfurt a. M.
Lejeune, Mathias: Rechtsprobleme bei der Lizenzierung von Open Source Software nach der GNU GPL, in: ITRB 2003, S. 10 - 12
Lettl, Tobias: Urheberrecht, 1. Auflage 2008, München
Schricker, Gerhard/Loewenheim, Ulrich (Hrsg.): Urheberrecht Kommentar, 4., neu bearbeitete Auflage 2010, München
Marly, Jochen: Praxishandbuch Softwarerecht, 5. Auflage 2009, München
Metzger, Axel: Zur Wirksamkeit von GPL-Lizenzen, in: CR 2004, S. 778 - 780
Metzger, Axel/Jaeger, Till: Open Source Software und deutsches Urheberrecht, in: GRUR Int. 1999, S. 839 - 848
Meyer, Oliver/Harland, Hanno: Haftung für softwarebezogene Fehlfunktionen technischer Geräte am Beispiel von Fahrassistenzsystemen, in: CR 2007, S. 689 - 695
Nimmer, Raymond T.: Coexisting with Free and Open Source Software, in: Cri 2006, S. 129 - 134
Oberhem, Carolina: Vertrags- und Haftungsfragen beim Vertrieb von Open-Source- Software, in: Schriftenreihe: Recht der Neuen Medien - Band 50, hrsg. von Verlag Dr. Kovac, 2008, Hamburg
Orthwein, Matthias/Obst, Jean-Stephan: Embedded Systems - Updatepflichten für Hersteller hardwarenaher Software, in: CR 2009, S. 1 - 4
Osterrieth, Christian: Patentrecht, 4. Auflage 2010, München
Palandt, Kommentar Bürgerliches Gesetzbuch, 65., neubearbeitete Auflage 2006. München
Sandl, Ulrich: „Open Source“-Software: Politische, ökonomische und rechtliche Aspekte, in: CR 2001, S. 346 - 315
Sch ä fer, Fabian: Aktivlegitimation und Anspruchsumfang bei der Verletzung der GPL v2 und v3, in: K&R 2010, S. 298 - 302
Sch ä fer, Fabian: Der virale Effekt - Entwicklungsrisiken im Umfeld von Open Source Software, in: Schriften des Zentrums für angewandte Rechtswissenschaft, Band 7, hrsg. von Dreier/Kühling/Sester, 2007, Karlsruhe
Scheja, Katharina/Mantz, Reto: Nach der Reform ist vor der Reform - Der zweite Korb der Urheberrechtsreform, in: CR 2007, S. 715 - 720
Schiffner, Thomas: Open Source Software: Freie Software im deutschen Urheber- und Vertragsrecht, in: Rechtswissenschaftliche Forschung und Entwicklung, Band 690, hrsg. von Michael Lehmann, 2003, München, S. 249 - 253
Schmid, Matthias/Wirth, Thomas/Seifert, Fedor (Hrsg.): Urheberrechtsgesetz Handkommentar, 2. Auflage 2008, Baden-Baden
Schneider, Jochen: Handbuch des EDV-Rechts, 4. Auflage 2009, Köln
Sester, Peter: Open-Source-Software: Vertragsrecht, Haftungsrisiken und IPR-Fragen, in: CR 2000, S. 797 - 807
Spindler, Gerald (Hrsg.): Rechtsfragen bei Open Source, Köln 2004
Spindler, Gerald/Wiebe, Andreas: Open Source-Vertrieb, in: CR 2003, S. 873 - 879
Spindler, Gerald: Open Source Software auf dem gerichtlichen Prüfstand - Dingliche Qualifikation und Inhaltskontrolle, in: K&R 2004, S. 528 - 534
Stickelbrock, Barbara: Linux & Co - Gewährleistung und Haftung bei kommerziell vertriebener Open Source Software (OSS), in: ZGS 2003, S. 368 - 372
Thalhofer, Thomas: Commercial Usability of Open Source Software Licenses, in: Cri 2008, S. 129 - 136
Wiebe, Andreas: Softwarepatente und Open Source, in: CR 2004, S. 881 - 888
Wuermeling, Ulrich/Deike, Thies: Open Source Software: Eine juristische Risikoanalyse, in: CR 2003, S. 87 - 91
Internetadressen
Tauchert, Wolfgang: Software-Patente und computerimplementierte Erfindungen, in: JurPC Web-Dok. 6/2005, Abs. 1 - 55,
http://www.jurpc.de/aufsatz/20050006.htm; Stand vom 16.12.2010
Studie der Firma Black Duck Software über GPL und Open Source Projekte:
http://blackducksoftware.com/oss/licenses#top20; Stand vom 16.12.2010
Lizenztext der GNU General Public License Version 1, abrufbar unter: http://www.gnu.org/licenses/gpl-1.0.html; Stand vom 16.12.2010
Lizenztext der GNU General Public License Version 2, abrufbar unter: http://www.gnu.org/licenses/gpl-2.0.html; Stand vom 16.12.2010
Lizenztext der GNU General Public License Version 3, abrufbar unter: http://www.gnu.org/licenses/gpl-3.0.html; Stand vom 16.12.2010
Information zur Fritzbox WLAN FON 7112 von der Firma AVM, abrufbar unter:
ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7112/firmware/deutsch/info.txt;
Stand vom 16.12.2010
Informationen zur Lizenznutzung der Firma AVM, abrufbar unter: ftp://ftp.avm.de/fritz.box/license.txt; Stand vom 16.12.2010
Abkürzungsverzeichnis
Gebraucht werden die üblichen Abkürzungen, vgl. Kirchner, Hildebert/Butz, Cornelie: Abkürzungsverzeichnis der Rechtssprache, 5. Auflage 2003, Berlin/New York
A. Einleitung
Open-Source-Software hat inzwischen alle Softwarebereiche erobert. Sie wird besonders als Alternative zu den Produkten großer marktbeherrschender US- Anbieter immer beliebter.1 Kleine mittelständige Unternehmen benutzen intern openCMS2 und bieten Softwareprodukte an, die auf Open Source Software aufbauen. Private Endnutzer verwenden Open Office oder den Internet-Browser Mozilla Firefox. Dies verdeutlicht, welch hohen Stellenwert Open-Source- Softwareprogramme heute für Unternehmer und Privatleute haben. Auch im Bereich der Mobiltelefone und PDAs kommt Open-Source-Software zum Einsatz. Hierbei jedoch meistens für den Nutzer unerkennbar, als fester Bestandteil von integrierten Systemen. So findet man unter anderem bei Motorola und Nokia eine Abwandlung von Embedded Linux als Open-Source-Betriebssystem.3 Doch welche rechtlichen Grundlagen und Voraussetzungen müssen für die Verwendung von Open-Source- Software im Bereich der eingebetteten Systeme erfüllt bzw. gegeben sein? Und was passiert, wenn sich vor allem Verbreiter von Open-Source-Software nicht an die Lizenzrahmenbedingungen halten?
Müssen dann Mobiltelefone, DVD-Player oder W-LAN-Router von den Nutzern abgeschaltet werden? Dieser Spezialfall ist Thema der vorliegenden Arbeit. Es sollen in einem ersten Teil notwendige Begriffe erläutert und Bezüge zur heutigen Bedeutung und derzeitigen Standards aufgezeigt werden. Im zweiten Teil wird der Vertrieb von Open-Source-Software ausführlicher behandelt, welche Möglichkeiten bestehen und wo es eventuell Konflikte mit dem deutschen Recht geben könnte. Abschließend werden im dritten Teil die Probleme der Patentierbarkeit von Open- Source-Software im Blickpunkt auf eingebettete Systeme beleuchtet und eine zusammenfassende Aufstellung des derzeitigen Rechtsstandes gegeben.
B. Erster Teil
I. Begriffserklärung
Nachfolgend werden Begriffe erläutert, welche als Grundvoraussetzung für die Beantwortung der zuvor aufgeworfenen Fragestellungen zu sehen sind. Diese umfassen die beiden Hauptschwerpunkte, nämlich den Open-Source-Begriff und eingebettete Systeme.
1. Open-Source-Software
Open-Source-Software4 steht in eindeutigem Gegensatz zu proprietärer Software, welche eigentumsorientiert verwertet wird. Hauptanliegen der Open-Source- Bewegung ist es, dass Programme, die unter Open-Source-Lizenzen gestellt werden, uneingeschränkt vervielfältigt, verändert, verbreitet und auch in abgeänderter Form weiterverbreitet werden dürfen.5 Damit soll erreicht werden, dass die Entwicklung von stabilen und von jedermann für seine Ziele anpassbare Programme gefördert wird.6 Die Besonderheit bei der Verbreitung solcher Software besteht folglich darin, dass jedem Nutzer vom Lizenzgeber ein einfaches Nutzungsrecht eingeräumt wird, das Programm verändert oder unverändert zu verbreiten und zu vervielfältigen.7 Diese Einräumung der Nutzungsrechte erfolgt meistens unentgeltlich. Dementsprechend schließt § 32 Abs. 3 S. 3 UrhG im Gleichklang mit bekannten Open-Source-Lizenzen den Anspruch des Urhebers auf angemessene Vergütung aus, wenn dieser einfache Nutzungsrechte unentgeltlich für jedermann einräumt.8 Durch diese neuartigen und fast unbegrenzten Nutzungsmöglichkeiten, aber auch wegen der hervorragenden Anpassbarkeit, erfreut sich OSS großer Beliebtheit, nicht nur bei den Entwicklergemeinschaften, sondern auch mehr und mehr bei großen Teilen der produzierenden Industrie. Dementsprechend verbreiten sich Open-Source- Programme rasend schnell.9 Im Aufbau unterscheidet sich OSS von der proprietären Software nicht10, da die gleichen Programmabläufe gegeben sind. Lediglich der Vertrieb und die Benutzbarkeit der Software, vor allem die Offenlegung des Quellcodes zeichnet die OSS aus. Auch deren Entwicklung läuft meistens anders ab als bei herkömmlicher Software. Bei ihr helfen eine fast unüberschaubare Mehrzahl von Internetnutzern weltweit an der Entwicklung der Programme. Am bekanntesten ist das Betriebssystem Linux, an dem mehrere tausend Programmierer weltweit gearbeitet haben.11 Aber nicht nur so umfassende Großprojekte wie Linux können OSS sein. Auch kleine Programme, Programmteile und sogar einzelne Quellcodeabschnitte können unter Open-Source-Lizenzen verbreitet werden.
2. Eingebettete Systeme
Eingebettete Systeme (engl. Embedded Systems) sind technische Verbindungen von Hardware und Software zu einem elektronischen Rechner oder Kleinstcomputer, der Steuer-, Überwachungs- und Ausführungsfunktionen wahrnimmt.12 Diese eingebetteten Systeme sind meistens für die Nutzer völlig unerkennbar. Sie finden sich in Mobiltelefonen, Fahrzeugen und in fast jeder Heimelektronik wieder. Meist müssen eingebettete Systeme speziell an eine bestimmte Aufgabe angepasst werden. Vom Prinzip her vereinigt eine solche Konstruktion die große Flexibilität von Software mit der Leistungsfähigkeit der verwendeten Hardware. Die Software dient dabei sowohl zur Steuerung des Systems selbst, als auch zur Interaktion des Systems mit der Außenwelt und anderen über definierte Schnittstellen oder Protokolle angeschlossenen Geräten.
II. Bedeutung und Verbreitung in der heutigen Zeit
Im Lauf der Zeit entwickelten sich eingebettete Systeme von 8- und 16-Bit-Systemen mit geringem Speicher hin zu 32-Bit-Prozessor beherbergenden Systemen, auf denen auch problemlos komplexe Betriebssysteme wie Linux untergebracht werden können.13 Solche Rechner werden heutzutage vermehrt in Mobiltelefonen, DVD- Playern, Waschmaschinen und vielen weiteren Elektronikartikeln verbaut. Auf vielen zur Zeit gängigen Smartphones, unter anderem von Nokia und Motorola, finden sich Linux-Derivate wieder. Eingebettete Systeme haben sich somit vom Kleinstcomputer zu leistungsfähigen Hardware-komponenten in der Elektronikindustrie entwickelt. Aber nicht nur die Embedded Systems haben sich rasant weiterentwickelt. Auch die OSS setzt sich immer weiter gegen herkömmliche, proprietäre Software durch. Die hervorragende Anpassbarkeit und dadurch gewährleistete Stabilität von Open- Source-Anwendungen hat nebenher dazu geführt, dass das Betriebssystem Linux, welches in vielen Embedded Systems in einer beliebigen Derivatform integriert ist, heutzutage dem Marktriesen Microsoft mit seinem Betriebssystem Windows den Rang abgelaufen hat.14
C. Zweiter Teil
I. Lizenzvertragssystem
OSS wird über ein System von Lizenzen vertrieben. Die bekannteste und verbreiteteste dieser Lizenzen ist die GNU General Public License15. Unter anderem wurde das Betriebssystem Linux unter der GNU GPL Version 2 lizenziert. Aus diesen Gründen wird die GPL exemplarisch an dieser Stelle dargestellt, um das System von Lizenzgebern, -nehmern und Lizenzverpflichtungen zu erläutern.
1. GNU General Public License
Die GPL wurde erstmals im Februar 198916 von der Free Soft- ware Foundation17 verabschiedet. Die Version 1 der GPL findet jedoch keine Anwendung mehr, seitdem diese durch die zweite Version ersetzt wurde. Die dritte und neueste Version dieser Lizenz hat die Vorgängerlizenz jedoch nicht abgelöst. Diese beiden finden nebeneinander Anwendung. Demnach ist es von enormer Bedeutung, sich beiden Lizenzversionen genauer zu widmen. Grundlegender Inhalt der GPL sind Regeln zum Vertrieb von OSS. Das durch die Free Software Foundation formulierte Hauptanliegen der GPL ist es, dass ihr unterstellte Software frei zugänglich, veränderbar und auch in abgeänderter Form vertreibbar ist.18
a. GPL v2
Die zweite Version der General Public License wurde im Juni 1991 veröffentlicht.19 Sie ist die zur Zeit noch bedeutendste Version der GNU GPL, da unter ihr der Großteil der Open-Source-Programme lizenziert ist.20 Einige Entwickler haben ihre Programme, wie zum Beispiel das Betriebssystem Linux, nur unter der GPL v2 lizenziert und somit nicht die Möglichkeit des „Upgrades“ auf die neue Version der General Public License genutzt. Die GPL v2 ist folgendermaßen aufgebaut. Neben den allgemeinen Bestimmungen in § 0 GPL v2 enthalten die nachfolgenden Paragraphen Regelungen zum Vertrieb von unveränderten und veränderten Kopien der OSS. In § 3 GPL v2 werden Festlegungen getroffen, die sich auf den Vertrieb von Software im Objektformat beziehen und Pflichten bei diesem Begründen. Diese Bestimmungen sind im Zusammenhang mit Embedded Systems besonders bedeutend, da hierin immer ein Objektcode-Vertrieb zu sehen ist. § 5 GPL v2 regelt die automatische Beendigung des Lizenzvertrages bei Missachtung der Regelungen der General Public License. Die §§ 6 und 7 der GPL v2 legen die Lizenzeinräumung des Softwareurhebers fest bzw. begründen eine Vertriebssperre, wenn rechtliche Hindernisse der Einhaltung der GPL-Bestimmungen entgegen stehen. Weiterhin bedeutend ist die Aussage des § 9 GPL v2, dass sich die Free Software Foundation die Verabschiedung neuer GPL-Versionen vorbehält, und der Haftungs- und Gewährleistungsausschluss in den §§ 11 und 12 GPL v2.
b. GPL v3
Am 29. Juni 2007 wurde die aktuelle Version der GPL21 von der Free Software Foundation (FSF) veröffentlicht.22 Als Nachfolgelizenz baut die Version 3 deutlich auf dem Vorgänger auf, ist jedoch inhaltlich weiter gefasst. Außerdem sind neue Regelungen unter anderem bezüglich Digital Rights Management (DRM) und computerimplementierten Erfindungen enthalten.23 Der Aufbau der GPL v3 ist dem der GPL v2 sehr ähnlich, was die Verwandtschaft der beiden Versionen noch einmal verdeutlicht. Am Anfang der Version 3 sind erneut Definitionen aufgeführt, gefolgt von Bestimmungen zum Quelltext von OSS. Neu eingeführt wurde § 3 GPL v3, der Schutz vor Umgehungsverbotsgesetzen, auch bekannt als Digital Rights Management, gewährleisten soll. Die §§ 4 bis 6 GPL v3 enthalten, wie schon aus Version 2 bekannt, Bestimmungen zum Vertrieb unveränderter und veränderter Kopien bzw. zum Vertrieb im Objektcode. Weiterhin erwähnenswert ist die „any-later- version-Klausel“ des § 14 GPL v3 und der Gewährleistungs- und Haftungsausschluss sowie deren neue Interpretationsbestimmungen gemäß §§ 15 bis 17 GPL v3.
c. Anwendbarkeit nach deutschem Recht
Da die General Public License von einer ausländischen, nichtstaatlichen Einrichtung, nämlich der Free Software Foundation verfasst wurde, stellt sich die Frage nach deren Qualifizierung und Anwendbarkeit nach deutschem Recht.
aa. GPL als Allgemeine Geschäftsbedingung
Schuldrechtlich handelt es sich bei der GPL um eine dinglich wirkende, auflösende Bedingung.24 Das bedeutet, dass bei Nichteinhaltung der Lizenzbestimmungen die Nutzungsrechte aus der GPL entfallen. Die General Public License legt folglich Rechte und Pflichten beim Vertrieb von OSS fest. Da sie selber kein Vertrag bezüglich der Überlassung von ist, jedoch für eine Vielzahl von Verträgen vorformulierte Vertragsbedingungen enthält, kann sie als Allgemeine Geschäftsbedingung gemäß §§ 305, 310 BGB qualifiziert werden.25 Somit muss die GPL auch wirksam in den Vertrag zwischen Lizenzgeber und Lizenznehmer einbezogen sein. Dies umfasst einen Hinweis auf die Geltung der GPL und deren Aushändigung oder eine Darstellung des Textes auf der Downloadseite der Software bzw. einen Link zu diesem Text. In Bereichen, in denen OSS nicht eigenständig verbreitet wird, sondern als Bestandteil eines Elektronikgeräts vertrieben wird, kann die Einbeziehung problematisch werden. Hier reicht aber eventuell auch die Einbeziehung über den Vertrag über das Elektronikprodukt selbst aus. Dies wird der Regelfall für die Verbreitung von Embedded Systems mit integrierter OSS sein.
bb. Urheberrechtliche Besonderheiten
Die General Public License v2 räumt dem Lizenznehmer gemäß § 0 Abs. 2 S. 2 die Position als Berechtigter im Sinne von § 69d Abs. 1 UrhG ein.26 In den nachfolgenden Bestimmungen der GPL wird dem Softwarenutzer auch das Vervielfältigen und Bearbeiten der OSS gestattet, welches in § 69c Nr. 1 UrhG normiert ist. § 69c Nr. 3 UrhG ermöglicht dem Rechtsinhaber weiterhin, das Softwareprodukt zu verbreiten. Da § 69c UrhG den Begriff des Verbreitens nicht selbst definiert, muss auf den Verbreitungsbegriff des § 17 UrhG zurückgegriffen werden. Dieser erfasst jedoch nur die Verbreitung von Werkstücken in körperlicher Form27, die bei eingebetteten Systemen jedoch vorliegt, da die Hardware als Speichermedium fungiert. Für Software, die in unkörperlicher Form zugänglich gemacht werden soll, ist § 69c Nr. 4 UrhG am 10.09.2003 neu eingeführt worden. Hervorzuheben ist jedoch, dass die Einräumung der Nutzungsrechte nach § 6 GPL v2 direkt vom Urheber des Open-Source-Produkts erfolgen soll.28 Dementsprechend werden keine Unterlizenzen vom jeweiligen Vertreiber erteilt, sondern jedes Mal ein neuer Lizenzvertrag zwischen Softwareurheber und Softwarenutzer abgeschlossen. Der Grundgedanke hierbei ist, dass ein Nutzungswegfall gemäß § 4 GPL v2 keine Auswirkungen auf Lizenznehmer haben soll, die von dem Lizenzbrechenden OSS erhalten haben. Der Urheber der Software räumt dem nachfolgenden Vertreiber seiner Open-Source-Software ein einfaches Nutzungsrecht gemäß § 31 Abs. 1 S. 2 Alt. 1 UrhG ein. Der Vertreiber als Inhaber eines einfachen Nutzungsrechts kann keine weitergehenden Nutzungsrechte einräumen.29 Der maßgebliche Umfang des eingeräumten Nutzungsrechts leitet sich wiederum aus den Bestimmungen der GPL ab.
d. Probleme bei eingebetteten Systemen
Als besonderer Schwerpunkt gestaltet sich das Vorhandensein von OSS als Teil eines eingebetteten Systems. Hier übernimmt die Software den steuernden Teil des verbundenen Geräts. Dadurch, dass sie jedoch kaum erkennbar in dem eingebetteten System steckt, ergeben sich einige praktische Probleme für die Nutzer dieser zusammengesetzten Gebilde. Für einen Laien ist es nicht feststellbar, welche Software auf einem Gerät als Steuerprogramm installiert ist, da die meisten eingebetteten Systeme weder über herkömmliche Schnittstellen verfügen, noch die Hersteller gerne enthüllende Angaben über ihre Produkte machen.
aa. GPL bei Embedded Systems
Zunächst besteht die Frage, ob OSS als Bestandteil eines eingebetteten Systems bzw. als eingebettete Software vertrieben werden darf. Diese Problematik wird jedoch sehr schnell und deutlich von beiden Versionen der GPL geklärt. Gemäß § 1 Abs. 1 GPL v2 und § 4 Abs. 1 GPL v3 darf OSS auf jedem beliebigen Medium30 unverändert verbreitet werden. Demnach steht einer Verbreitung als eingebettetes System lizenzrechtlich nichts entgegen. Jedoch müssen sämtliche Regelungen der Lizenzen beim Vertrieb erfüllt sein. Der Angelpunkt des Vertriebes von OSS in einem integrierten Hardwareprodukt ist die erforderliche Weitergabe bzw. Einräumung der Möglichkeit des Erhalts des Quelltextes der zugänglich gemachten Software. Festgesetzt ist dieses Erfordernis in § 3 GPL v2 und § 6 GPL v3. Die Übertragung in Nicht-Quelltextform ist ausdrücklich gestattet, jedoch an einige Prämissen geknüpft. So bestehen vier Möglichkeiten, bei einer Weitergabe der Software in einem eingebetteten System, die Lizenzbedingungen der GPL zu erfüllen. Zunächst könnte der Quelltext direkt beim Vertrieb auf einem Datenträger mitgegeben werden gemäß § 3 Abs. 1 lit. A GPL v2. Die zweite in Betracht kommende Möglichkeit ist, dass ein schriftliches Angebot des Verbreiters gegeben wird, den Quelltext zum Selbstkostenpreis auszuliefern. Dieses muss laut § 3 Abs. 1 lit. b GPL v2 drei Jahre Gültigkeit haben. Die letzten beiden Möglichkeiten scheiden kraft Natur der eingebetteten Systeme aus. Lediglich bei einer nichtkommerziellen Verbreitung könnte auch das Angebot eines Dritten auf Lieferung des Quelltextes ausreichen und beim Angebot des Objektcodes auf einer Internetseite, muss der Quelltext ebenfalls zum Download bereit stehen. Wie gesagt, kommen diese Möglichkeiten bei der Integration von OSS in einen technischen Apparat, wie zum Beispiel ein Mobiltelefon, nicht in Betracht. Zusammenfassend kann festgehalten werden, dass die Mitlieferung des Quelltextes, bzw. das schriftliche Angebot, den Quelltext zum Selbstkostenpreis zur Verfügung zu stellen, wohl eine mögliche und zumutbare Variante für den Vertreiber von OSS als eingebettete Software ist. Fraglich ist somit nur, warum in der Praxis kaum jemand den mitzuliefernden Lizenztext oder den Quelltext ausgehändigt bekommt. Geschweige denn, darüber aufgeklärt wird, dass er soeben ein Gerät mit integrierter OSS gekauft hat. Ein Beispiel hierfür ist die Fritzbox WLAN FON 7112 von der Firma AVM. In vielen Haushalten befinden sich solche oder ähnliche Router, die den Internetzugang ermöglichen. Diese Router nutzen eine Software, welche unter der GPL lizenziert wurde. Jedoch ist auch für einen versierten Computernutzer nicht ersichtlich, um welche Software es sich handelt und welche Funktionen sie in diesem komplexen Gerät wahrnimmt. Beim Kauf der besagten Hardware wird man nicht darauf hingewiesen, dass die Firmware des Routers OSS beinhaltet, die bestimmten lizenzrechtlichen Bedingungen unterliegt. Lediglich auf der Internetseite, und nur dann, wenn man auf die Idee kommt, seine Firmware zu aktualisieren, wird man auf die Informationen hingewiesen, welche unter einem externen Link abrufbar sind.31 In diesem Textdokument wird wiederum auf ein anderes Textdokument hingewiesen32, das den Text der GNU GPL v2 enthält. Hier ist man der Verpflichtung nur augenscheinlich nachgekommen, den Lizenztext beim Vertrieb mitzuliefern. Den Quellcode sucht man jedoch auf der Seite des Anbieters vergeblich. Lediglich ein kleiner Hinweis ist gegeben, dass man den Quelltext auf Nachfrage über eine Email- Adresse beziehen kann. Nun fragt man sich jedoch, ob dies entsprechend der GNU GPL v2 ausreicht, um nicht einen Verstoß zu begehen. Bei Vertragsschluss wird dem Kunden keinerlei Hinweis auf das Vorhandensein von Software, die unter eine Open- Source-Lizenz fällt, gegeben. Demnach kann man von einem Verschweigen reden, welches den Zielen der GPL v2 sinngemäß absolut widerspricht.
bb. Digital Rights Management
Als eine weitere Neuerung der General Public License v3 gelten die Regelungen zum Digital Rights Management (DRM). Digital Rights Management sind Umgehungsverbotsgesetze, die auf der Grundlage von Art. 11 des WIPO- Urheberrechtsvertrages WCT vom 20.12.1996 in zahlreichen nationalen Rechtsordnungen eingeführt wurden.33 In Deutschland schlug sich dies in den §§ 95a ff. UrhG nieder, welche Regelungen zum Schutz technischer Maßnahmen enthalten. Aus § 3 Abs. 1 GPL v3 lässt sich entnehmen, dass OSS, die unter der GPL lizenziert und vertrieben wurde, keine wirksame technische Schutzmaßnahme sein darf. Demnach würde man mit der Umsetzung des Digital Rights Managements mit GPL-Software konkludent die Erlaubnis zur Umgehung dergleichen erteilen. Dies ergibt sich auch aus dem Verzicht gemäß § 3 Abs. 2 GPL v3, die Umgehung verbieten, wenn diese durch die Ausübung der GPL-Rechte bewältigt wird.34 Dementsprechend ist fraglich, ob diese neuen Regelungen mit § 95a Abs. 3 UrhG vereinbar sind. Dort werden jegliche Maßnahmen, die dazu führen, dass Schutzmechanismen umgangen werden verboten. Daraus folgt, dass ein Nutzer gegen die Verbotsnorm des § 95a Abs. 3 UrhG verstößt, wenn er OSS bearbeitet, die als DRM fungiert. Somit steht die Intention der Regelung der GPL im eindeutigen Widerspruch zum Urhebergesetz.
cc. Der „virale Effekt“
Dieser etwas spektakuläre Begriff beschreibt ein Phänomen, welches besonders beim gemeinsamen Vertrieb von OSS und proprietärer Software oder bei der Vermischung von Quellcode verschiedener OSS auftaucht. Prädestiniert hierfür sind eingebettete Systeme, da sie als „Datenträger“ unterschiedliche Software enthalten können bzw. die Software dem System so angepasst werden muss, dass die Funktionen der Hardware bestmöglich ausgeführt werden können. Der Begriff des „viralen Effekts“ hat sich in der Rechtsliteratur weitgehend durchgesetzt35, sodass er auch hier stellvertretend für das nachfolgende Problem verwendet wird. Da wie anfangs erwähnt, die General Public License in den Versionen 2 und 3 im Rechtsverkehr Geltung beansprucht, erscheint die nachfolgende getrennte Beurteilung des „viralen Effekts“ nach beiden Lizenzversionen sinnvoll.
(1) Der „virale Effekt“ nach der GPL v2
Der sogenannte „virale Effekt“ bedeutet, dass Programme oder deren Teile, die zusammen mit GPL-Programmen vertrieben werden oder von denen abgeleitet wurden, auch unter die Anwendung der General Public License fallen.36 Daraus resultiert, dass auch proprietäre Software oder dessen Teile dem Empfänger in der Weise zugänglich gemacht werden muss, dass dieser den vollen Quelltext mit allen Anpassungen und Veränderungen, die in Bezug auf das eingebettete System unternommen wurden, erhalten kann. Dies hätte jedoch erhebliche Umsatzeinbußen und die Offenlegung von Geschäfts- und Entwicklungsgeheimnissen der Anbieter der proprietären Software zur Folge. Fraglich ist demnach, wie diese Regelungen nach deutschem Recht ausgelegt werden müssen und welche Anwendbarkeit diese auf eingebettete Systeme überhaupt haben. Seine lizenzrechtliche Grundlage findet der „virale Effekt“ in § 2 Abs. 1 lit. b und § 2 Abs. 2 GPL v2, welche viele fremdsprachige, unbestimmte Rechtsbegriffe enthalten. Diese bedürfen einer näheren Erläuterung und Einordnung in das System des deutschen Urheberrechts. Laut den Lizenzbestimmungen muss das Produkt zunächst von einem, von der GPL geschützten Programm abgeleitet worden sein („derived from“) oder Teile von diesem enthalten („contains“).37 Nun ist jedoch fragwürdig, welche Bedeutung das deutsche Recht diesen unbestimmten Rechtsbegriffen beimisst. Unter einer Ableitung eines Programms ist eine Bearbeitung bzw. Weiterverarbeitung eines Ausgangsprogramms zu verstehen. Das deutsche Urheberrecht nennt in den §§ 3, 69c Nr. 2 UrhG einen wesensähnlichen Begriff der Bearbeitung. Jedoch hat dieser einen gegensätzlichen Sinn. Hier lässt die Bearbeitung eines Werkes ein komplett neues Werk entstehen und erschafft demnach auch ein eigenständiges Bearbeitungsurheberrecht, welches als absolutes Recht dem Bearbeiter die alleinigen Nutzungsrechte zubilligt.38 Abgesehen von diesem teleologischen Unterschied lagert ein weiteres Problem in Bezug auf eingebettete Systeme an einer gänzlich anderen Stelle. Entscheidend ist hier, ob der gemeinsame Vertrieb von Open-Source- und proprietärer Software in einem eingebetteten System den „viralen Effekt“ nach § 2 Abs. 2 S. 3 GPL v2 auslöst.39 Nach § 2 Abs. 4 GPL v2 kommt es gerade nicht zu ebendiesem, wenn es sich lediglich um eine Zusammenlegung von verschiedenen Programmen auf demselben Speicher- oder Vertriebsmedium handelt, somit auch keine Verbindung zwischen den Programmen besteht.40 Die Hardware des eingebetteten Systems kann als ein solches Speichermedium qualifiziert werden, obwohl die Software auf diesem eine bestimmte Aufgabe wahrzunehmen hat. Dementsprechend greift der „virale Effekt“ nicht, wenn die Software vollkommen unabhängig voneinander verschiedene, nicht unmittelbar zusammenhängende Funktionen in diesem eingebetteten System ausführt. Oftmals ist es aber gerade das notwendige Zusammenwirken von verschiedener Software, die das eingebettete System erst funktionstüchtig machen. Open-Source- Betriebssysteme werden wegen den geringeren Speicherressourcen direkter eingebunden und verfügen nur über ein Minimum an eigenständigen Gerätetreibern. Demnach besteht bei Embedded Systems eine größere Infektionsgefahr.41
(2) Der „virale Effekt“ nach der GPL v3
Die Grundbestimmungen des „viralen Effekts“ in der GPL v3 sind größtenteils inhaltsgleich geblieben. Jedoch haben sich einige Einzelheiten bedeutend geändert.42 Die Verbreitungs-begriffe in § 2 Abs. 1 lit. b GPL v2 („distribute or publish“) wurden durch einen offeneren und auslegungsbedürftigeren Begriff in § 0 Abs. 7 GPL v3 („convey“) ersetzt. „Convey“ bildet einen Unterfall der „Propagation“, welche gemäß § 0 Abs. 6 GPL v3 jede Handlung erfasst, die nach dem jeweils anwendbaren Urheberrecht einer urheberrechtlichen Erlaubnis bedarf, allerdings mit der Ausnahme des Aufführens auf dem Computer und der Modifikation einer privaten Kopie.43 Das bedeutet für die Verbreitung von Embedded Systems, dass der „virale Effekt“ auch schon eingreifen kann, bevor ein Produkt offiziell auf den Markt gebracht wird. Denn wenn das Produkt innerhalb eines Unternehmens verbreitet wird und die Mitarbeiter des Unternehmens nicht durch persönliche Beziehungen gemäß § 15 Abs. 3 S. 2 UrhG verbunden sind, dann liegt ein Fall der „Propagation“ vor und der „virale Effekt“ greift. Das bedeutet jedoch nicht, dass der Quelltext jeglicher Software auf dem Embedded System der Öffentlichkeit, und schon gar nicht der Konkurrenz, zugänglich gemacht werden muss. Gemäß § 5 Abs. 1 lit. c GPL v3 besteht die Verpflichtung, das Softwareprodukt unter der GPL nur gegenüber demjenigen zu lizenzieren, der eine Kopie des Embedded Systems besitzt, wobei Besitz im Sinne des § 854 BGB zu verstehen ist.44 Demnach können sich nur diejenigen auf den „viralen Effekt“ berufen und somit die Veröffentlichung des „infizierten“ Quelltextes verlangen, die entweder das Produkt erworben oder sich in sonstiger Weise rechtmäßigen Besitz an dem eingebetteten System verschafft haben. Dies steht im Gegensatz zur GPL v2, die die Veröffentlichung des Quelltextes gegenüber jedermann bei Veröffentlichung des Embedded Systems verlangt hat. Als weitere Neuerung der GPL v3 ist die Einführung der „Aggregation Clause“ zu sehen. Diese soll verhindern, dass Softwarezusammenstellungen unter die GPL gezwungen werden. Niedergeschrieben in § 5 Abs. 2 GPL v3 bestimmt sie, dass eine Zusammenstellung eines unter der GPL lizenzierten Werks mit anderen unabhängigen Werken auf einem Speichermedium keinen viralen Effekt auslöst. Hierbei handelt es sich um eine inhaltsgleiche Regelung, wie schon in § 2 Abs. 4 GPL v2 vorhanden ist. Lediglich der Terminus hat sich geändert.
(3) Fazit
Abschließend kann festgehalten werden, dass sich das Grundprinzip des „viralen Effekts“ auch mit der Einführung der neuen General Public License v3 nicht geändert hat. Einige unscheinbare Modifikationen haben stattgefunden. Jedoch blieben große Teile dieser Regelungen stark auslegungs-bedürftig und es herrscht weiterhin eine große Rechtsunsicherheit. Diese betrifft nicht nur Privatleute, sondern auch Unternehmer, die drastische Folgen zu befürchten haben, sollten sie beim Vertrieb von Embedded Systems mit verschiedenen integrierten Open-Source- und/oder proprietären Softwareteilen die Reichweite des viralen Effekts falsch einschätzen.
dd. Wegfall des Nutzungsrechts
Gemäß § 8 Abs. 4 GPL v3 bleiben Lizenzen Dritter, die vom Rechtsverletzer Kopien von Programmen oder andere Rechte bekommen haben, erhalten. Hiervon abzugrenzen ist jedoch das urheberrechtlich gewährte, einfache Nutzungsrecht, welches entfallen kann. Wenn OSS, die unter der GPL lizenziert wurde, in einem Embedded System verbreitet wird, dann räumt der Urheber als Lizenzgeber jedem Lizenznehmer ein einfaches Nutzungsrecht nach § 31 Abs. 2 UrhG ein. Bei einer Verletzung der GPL durch den Vertreiber der OSS verliert er die Möglichkeit, nachfolgenden Erwerbern Nutzungsrechte einzuräumen. Mit der Verletzung der GPL entfallen diese Rechte jedoch wieder, sodass der Erwerber kein rechtmäßiger Nutzer geworden ist. Demzufolge kann er sich auch nicht auf die Nutzungsrechte des § 69d UrhG berufen.45 Hier müsste der Endnutzer erneut einen Lizenzvertrag mit dem Urheber der OSS abschließen, um sich auf seine Nutzungsrechte berufen zu können.
ee. Any-later-version-Klausel
Die in der General Public License enthaltene any-later-Version-Klausel besagt, dass Anwendern eine spezielle Versionsnummer oder eine spätere Version der GPL angeboten werden kann. Wird vom Rechtseinräumenden keine spezielle GPL- Version benannt, dann kann der Nutzer eine beliebige Version aussuchen.46 Nicht geregelt ist jedoch die Möglichkeit, dass der Nutzer eine bestimmte GPL-Version unter Ausschluss aller nachfolgenden Versionen wählt. Da sich die Free Software Foundation in § 9 Abs. 1 GPL v2 und § 14 Abs. 1 GPL v3 das Recht vorbehalten hat, „von Zeit zu Zeit“ neue GPL-Versionen zu veröffentlichen, wäre der Rechtsinhaber der OSS einer nicht zu beeinflussenden Entscheidung der FSF ausgeliefert. Wie jedoch die Lizenzierung von Linux als „GPL v2-only“47 zeigt, ist eine solche Handhabe jedoch möglich. Eine einseitige Lizenzabänderung durch den Lizenzgeber ohne die Zustimmung des Vertragspartners würde nach deutschem Recht gegen § 308 Nr. 4 BGB verstoßen. Ein automatischer Wechsel von Version 2 auf Version 3 der GPL scheidet somit aus.48 Anders sieht es auf Seiten des Lizenznehmers aus. Die any-later-version-Klausel gibt dem Lizenznehmer ein Wahlrecht in die Hand, um die für den Lizenzvertrag geltende Version selbst zu bestimmen.
2. Andere Lizenzen
Neben der GPL, die zu den bekanntesten Open-Source-Lizenzen zählt, existieren jedoch noch eine Vielzahl von anderen Versionen. Nachfolgend werden in aller Kürze einige wichtige Lizenzen vorgestellt und die Frage thematisiert, ob Software gleichzeitig unter verschiedenen Lizenzen stehen darf und kann.
a. Beispiele
Von der Free Software Foundation wurde neben der General Public License (GPL) auch eine Lesser General Public License (LGPL) herausgegeben, die sich besonders für den Schutz von Softwarebibliotheken eignet. Daneben existieren zum Beispiel die Berkeley Software Distribution Copyright License (BSD),49 Apache Lizenz, Mozilla Public License (MPL), Sun Public License (SPL), Q Public License (QPL), Eclipse Public License (EPL) und die Open Software License (OPL).50
[...]
1 Lejeune, ITRB 2003, 10 (10).
2 Content-Management-System insbes. für Inter- oder Intranet-Anwendungen.
3 Nokia verwendet das Betriebssystem Maemo und Motorola benutzt Mobilinux.
4 abgekürzt OSS.
5 Koglin, Opensourcerecht, S. 2.
6 Karl, Abschn. B, II, 3., S. 21.
7 Haberstumpf in Büscher/Dittmer/Schiwy, § 69d, Rn. 13.
8 Sog. „Linux-Klausel“; Schmid/Wirth in Schmid/Wirth/Seifert, § 32a, Rn. 15; Lettl, Urheberrecht, § 5 Rn. 44; Scheja/Mantz, CR 2007, 715 (716).
9 Vgl. Marly, Rn. 899; Sandl, CR 2001, 346 (348) - sprechen von explosionsartiger Verbreitung.
10 Koch, CR 2000, 273 (273).
11 Schiffner, Open Source Software, S. 64.
12 Orthwein/Obst, CR 2009, 1 (1).
13 Grützmacher, ITRB 2009, 184 (184).
14 So auch Karl, Abschn. B, II, 3., S. 21.
15 abgekürzt GNU GPL oder GPL; mit Versionsnummer GPL v2 bzw. GPL v3.
16 Der Lizenztext ist abrufbar unter: http://www.gnu.org/licenses/gpl-1.0.html (Stand:16.12.2010, siehe Anhang).
17 Kurz FSF.
18 Siehe §§ 1 f. GPL v2; §§ 4 f. GPL v3.
19 Der Lizenztext ist abrufbar unter: http://www.gnu.org/licenses/gpl-2.0.html (Stand: 16.12.2010, siehe Anhang).
20 Nach einer aktuellen Studie der Firma Black Duck Software wird die GPL v2 in 46,17 % der Open Source Projekte eingesetzt, vgl. unter http://www.blackducksoftware.com/oss/licenses#top20 (Stand: 16.12.2010, siehe Anhang).
21 Der Lizenztext ist abrufbar unter: http://www.gnu.org/licenses/gpl-3.0.html (Stand 16.12.2010, siehe Anhang)
22 Koch, ITRB 2007, 261 (261).
23 Koglin, CR 2008, 137 (137).
24 Metzger/Jaeger, GRUR Int. 1999, 839 (843); Metzger, CR 2004, 778 (779); Sester, CR 2000, 797 (797);
Spindler in Spindler, Rechtsfragen bei Open-Source, Abschn. C, Rn. 25 ff.; Spindler, KuR 2004, 528 (529); LG Frankfurt, CR 2006, 729 (732).
25 Metzger/Jaeger, GRUR Int. 1999, 839 (846); Koch, CR 2000, 333 (339); Deike, CR 2003, 9 (13).
26 Deike, CR 2003, 9 (16).
27 Loewenheim in Schricker/Loewenheim, § 69c, Rn. 26 und § 17, Rn. 5.
28 Deike, CR 2003, 9 (16).
29 Schricker/Loewenheim in Schricker/Loewenheim, § 31, Rn. 15.
30 Im Original: „any medium“; § 1 Abs. 1 S. 1 GPL v2; § 4 Abs. 1 S. 1 GPL v3.
31 ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7112/firmware/deutsch/info.txt. (Stand: 16.12.2010, siehe Anhang).
32 ftp://ftp.avm.de/fritz.box/license.txt. (Stand: 16.12.2010, siehe Anhang).
33 Funk/Zeifang, CR 2007, 617 (624).
34 Funk/Zeifang, CR 2007, 617 (624).
35 Funk/Zeifang, CR 2007, 617 (618); Gerlach, CR 2006, 649 (650); Beardwood/Alleyne, Cri 2006, 97 (98); Nimmer Cri 2006, 129 (129); Schäfer, S. 96; Spindler, Abschn. C., Rn. 112.
36 Funk/Zeifang, CR 2007, 617 (618).
37 Vgl. Funk/Zeifang, CR 2007, 617 (618).
38 Loewenheim in Schricker/Loewenheim, § 3, Rn. 38; § 69c, Rn. 19.
39 So Schäfer, S. 116, 165.
40 Funk/Zeifang, CR 2007, 617 (619); Wuermeling/Deike, CR 2003, 87 (90).
41 Grützmacher, ITRB 2009, 184 (187).
42 Funk/Zeifang, CR 2007, 617 (620).
43 So Funk/Zeifang, CR 2007, 617 (620).
44 So Funk/Zeifang, CR 2007, 617 (621).
45 Spindler/Wiebe, CR 2003, 873 (879).
46 Marly, Rn. 931.
47 Koch, ITRB 2007, 261 (262).
48 Spindler in Schricker/Loewenheim, Vor §§ 69a ff., Rn. 36.
49 Lejeune, ITRB 2003, 10 (10).
50 Thalhofer, Cri 2008, 129 (133ff).