PDF, 66 KB - Universität Zürich

Prof. Dr. Rolf H. Weber
Freie Software – Befreiung vom Vertragstypenkonzept?
Freie Software – Befreiung vom Vertragstypenkonzept? .......................................................... 1
I.
Freie Software .................................................................................................................... 1
II.
Vertragstypenkonzept......................................................................................................... 6
III. Urheberrechtliche Determinanten...................................................................................... 7
IV. Vertragsqualifikationsbezogene Problembereiche ............................................................. 8
V.
I.
1.
Problem des Wortlautbezugs .......................................................................................... 9
2.
Problem der Unentgeltlichkeit ..................................................................................... 11
3.
Problem der Interessenvergemeinschaftung................................................................. 13
4.
Problem der Weiterverwendungsordnung.................................................................... 14
Fazit .................................................................................................................................. 16
Freie Software
a) Dass die Entwicklung zur Informationsgesellschaft auch Veränderungen in
der „Zivilgesellschaft“ nach sich zieht, ist zwischenzeitlich allgemein anerkannt.
Der grössere Stellenwert von Informationen führt zu einem Bedeutungszuwachs
der immateriellen Güter; das Schmieröl der Handlungsabläufe liegt dabei in den
Computerprogrammen, der Software, die den Jubilar1 schon beschäftigt hat, bevor dieses Thema in aller Munde gewesen ist.
Angesichts der Bedeutung der Software ist es nicht erstaunlich, dass Entwickler
oder Inhaber von Software daran proprietäre Rechte zu erwerben versuchen. Je
nach gesetzlicher Ausgestaltung der Schutzordnung beruht diese „Inhaberschaft“ auf dem Urheberrecht oder in neuerer Zeit vermehrt auch auf dem Patentrecht2. Im Lichte der Standardisierung von Software, die jeder Informationstechnologie-Benutzer als allgemein eingesetztes technischen Hilfsmittel verwenden muss, hat in den letzten Jahren aber eine Entwicklung eingesetzt, die
1
2
Vgl. HEINRICH HONSELL, Standardsoftware- und Sachmängelhaftung, in: ERNST BREM /JEAN
NICOLAS DRUEY/ERNST A. KRAMER/IVO SCHWANDER (Hrsg.), Festschrift für Mario M. Pedrazzini, Bern 1990, 313 ff.
Grundlegend EMIL F. NEFF/MATHIAS ARN, Urheberrechtlicher Schutz der Software, SIWR II/2,
Basel/Frankfurt/München 1998, 1, 115 ff., 149 ff.
1
bezweckt, Software den proprietären Kontrollmöglichkeiten der Inhaber zu entziehen und sie allgemein dem Markt zur Verfügung zu stellen3.
Ursprünglich haben die Promotoren dieses Anliegens den Begriff „free software“ verwendet4; zwischenzeitlich wird – wenn zwar teilweise mit geringen
Abweichungen – auch der Begriff „Open Source“-Software gebraucht5. „Frei“
bedeutet nicht zwingend kostenlos (wenn zwar dies die Regel ist), sondern meint
die Verwirklichung verschiedener Freiheiten, nämlich (1) der Freiheit, das Programm für andere Zwecke zu benutzen, (2) der Freiheit, zu verstehen, wie das
Programm funktioniert und wie es sich anpassen lässt, (3) der Freiheit, Kopien
herzustellen und weiter zu verbreiten sowie (4) der Freiheit, das Programm zu
verbessern und die Verbesserungen wieder verfügbar zu machen6. Technisch ist
vorausgesetzt, dass der Zugang zum Quellcode (Source Code) möglich ist, insoweit also der ursprüngliche Urheber keine proprietären Rechte daran geltend
macht, der Folgenutzer an seiner Weiterentwicklung aber auch kein „copyright“
beansprucht (sog. „copyleft“)7.
Als freie Software gilt jede (system- oder anwendungsbezogene) Software, die
unter einer das Vervielfältigen, Verbreiten, Ändern und Nutzen frei gestattenden
Lizenz kostenfrei verfügbar gemacht wird und der bei jeder Weitergabe der
Quellcode8 von durchgeführten Änderungen des jeweiligen Programms beigefügt sein muss; charakteristische Merkmale sind also die unentgeltliche Zurverfügungstellung der Software, die Weitergabe des Quellformates des jeweiligen
Programms und das Recht des Nutzers, die Software zu ändern und weiterzuentwickeln9.
3
4
5
6
7
8
9
Einen allgemeinen Überblick geben AXEL METZGER/TILL JAEGER, Open Source Software und
deutsches Urheberrecht, GRUR Int. 1999, 839 ff.
http://www.fsf.org/philosophy/free-software-for-freedom.html; vgl. auch JÜRGEN SIEPMANN,
Lizenz- und haftungsrechtliche Fragen bei der kommerziellen Nutzung Freier Software,
http://www.jura.uni-sb.jurpc/aufsatz/19990163.htm, N 9 ff.
http://www.opensource.org; vgl. auch FRANK A. KOCH, Urheber- und kartellrechtliche Aspekte
der Nutzung von Open-Source-Software, CR 2000, 273 f. mit Verweisen; aus der amerikanischen
Lehre vgl. MARCUS MAHER, Open Source Software: The Success of an Alternative Intellectual
Property Incentive Paradigm, 10 Fordham Intellectual Property, Media & Entertainment Law
Journal 619 ff. (2000).
http://www.gnu.org/philosophy/free-sw.de.html.
Zum „copyleft“ hinten, IV.4.
Zum Quellcode WOLFANG STRAUB, Der Sourcecode von Computerprogrammen im schweizerischen Recht und in der EU-Richtlinie über den Rechtsschutz von Computerprogrammen, UFITA
2001/III, 807 ff.; ROLF H. WEBER, Ali Baba oder das Risiko exklusiver Informationsinhaltsrechte, in: Festschrift für Jean Nicolas Druey, Zürich 2002, 763, 770; STEFAN ERNST , Die Verfügbarkeit des Source Codes, MMR 2001, 208 ff.
Vgl. KOCH (FN 5), 273 f., 333; P ETER SESTER, Open-Source-Software: Vertragsrecht, Haftungsrisiken und IPR-Fragen, CR 2000, 797 f.; ULRICH SANDL, „Open Source“-Software: Politische,
ökonomische und rechtliche Aspekte, CR 2001, 346 f.
2
b) Die Idee der freien Software geht zurück auf den amerikanischen Ingenieur
Richard Stallman, der vor über zehn Jahren eine freie, UNIX-kompatible Software entwickelt hat, die er „Gnutella“ bzw. GNU als Akronym für „GNU is not
Unix“ bezeichnete10. In der Folge, nicht zuletzt angesichts von Distributionsproblemen für diese Software, hat der Finne Linus Torvalds den Kernel der
Software übernommen und daraus das Programm Linux entwickelt 11. Mit
GNU/Linux ist anfangs der neunziger Jahre erstmals ein vollständig freies Betriebssystem entstanden.
Bereits 1985 hat Stallman mit Kollegen die Free Software Foundation gegründet12. Angesichts der Personifizierung auf Stallman und GNU sowie der teilweise missverständlichen Begriffsverwendung „free“ hat sich gegen Ende der neunziger Jahre die „Open Source Initiative“ (OSI) herausgebildet, die sich seit 1998
als freie Software-Bewegung etabliert und ein Zertifizierungsprogramm für die
Beurteilung freier Software entwickelt hat13. Lizenzen, welche den Open Source-Bestimmungen der OSI entsprechen, sind „OSI-certified“14. Zwischenzeitlich
sind von der OSI bereits viele Open Source-Lizenzen anerkannt15:
10
11
12
13
14
15
•
GNU General Public License
•
GNU Library or „Lesser“ Public License
•
BSD License
•
MIT License („X Consortium License“)
•
Artistic License
•
Mozilla Public License
•
Qt Public License
•
IBM Public License
•
MITRE Collaborative Virtual Workspace License (CVW License)
•
Ricoh Source Code Public License
•
Python License
•
zlib/libpng license
http://www.gnu.com/gnu/the-gnu-project.html; vgl. auch SIEPMANN (FN 4), N 89 ff.
Vgl. ROLF H. WEBER, Does Intellectual Property Become Unimportant in Cyberspace?, International Journal of Law and Information Technology 2001, 171, 178 f.; vgl. auch LAWRENCE LESSIG, Code and Other Laws of Cyberspace, New York 1999, 105.
http://www.fsf.org/philosophy/free-software-for-freedom.html; vgl. auch ROLF H. WEBER, Regulatory Concepts for the Online World, Zürich 2002, 143 f.
Vgl. auch KOCH (FN 5), 273 f.
http://www.opensource.org/docs/definition_plain.html.
http://www.opensource.org/licenses; vgl. auch KOCH (FN 1), 274 f.
3
In nur wenigen Jahren ist die Zahl der auf dem Internet verfügbaren Lizenzen
für freie Software kaum mehr überblickbar angestiegen16; die grösste praktische
Bedeutung haben wohl GNU, BSD, Appache und Mozilla.
c) Als freie Software eignet sich nur Massen- bzw. Standard-Software. Sobald
eine individuelle Ausgestaltung von Software erfolgt, fehlt die Tauglichkeit für
die allgemeine Öffentlichkeit; zudem wird der Entwickler regelmässig nicht bereit sein, die Software unentgeltlich den Nutzern zur Verfügung zu stellen17. Der
Einsatz des Modells der freien Software ist somit vornehmlich ein alternativer
Ansatz des Vorgehens bei der Software-Entwicklung, dessen Vorteile teilweise
empirisch belegbar sind, nicht aber eine (neue) Vermarktungsstrategie 18.
Wesentliche Elemente der freien Software sind – wie erwähnt – die Verpflichtung zur Kostenfreiheit der Weiterverbreitung der Codeänderungen an der jeweiligen Software und zum Verfügbarmachen bzw. -halten des Quellformates
(Source Code) des jeweiligen Programms. Dogmatisch geht es dabei nicht um
eine volle Rechtsübertragung mit absoluter Wirkung (ohnehin mit Ausnahme
der Urheberpersönlichkeitsrechte), sondern um eine Übertragung von Rechten
mit obligatorischer Wirkung19, d.h. der Nutzungsberechtigte wird nicht Inhaber
eines dinglichen Rechts 20. In der Praxis zeigen sich dabei unterschiedliche Ausgestaltungen bei den vertraglichen Vorgaben, wie (bzw. in welcher Weise) die
freie Software zu gebrauchen ist. Während die am weitesten gehende GNU Li16
17
18
19
20
Artistic
License
(http://language.perl.com/misc/Artistic.html);
4.4
BSD
Copyright
(http://www.de.freebsd.org/copyright/license.html); Collaborative Virtual Workspace License
(CVW) (http://cvw.mitre.org/cvw/licenses/source/license.html); GNU General Public License
(GPL) (http://www.fsf.org/copyleft/gpl.html); GNU Lesser General Public License (LGPL)
(http://www.fsf.org/copyleft/lesser.html) mit deutscher Übersetzung (http://www.gnu.de/gplger.html); GNU Free Documentation License (FDL) (http://www.fsf.org/copyleft/fdl.html); IBM
Public License Version 1.0 (http://www.research.ibm.com/jikes/license/license3.htm); Linux Documentation
Project
Copying
License
(http://www.redhat.com/mirrors/LDP/LDPCOPYRIGHT.html); MIT License (http://www.opensource.org/licenses/mit-license.html); Mozilla Public License (http://www.mozilla.org/MPL/MPL-1.1.html; vgl. auch NZZ Nr. 129 vom 7.
Juni 2002, S. 79); Open Content License (OPL) (http://opencontent.org/opl.shtml); Open Map
Software License Agreement (http://openmap.bbn.com/license.html); Open RTLinux Patent License
(http://www.fsmlabs.com);
PLT
License
(http://www.plt.rwthaachen.de/ks/pltlicense.html); Python Copyright (http://www.python.org/doc/Copyright.html); Q
Public License (QPL) (http://www.troll.no/qpl/); Red Hat eCos Public License v1.1
(http://sourceware.cygnus.com/ecos/license.html); Ricoh Source Code Public License
(http://www.risource.org/RPL/RPL-1.0A.shtml);
Sun
Community
Source
Licensing
(http://www.sun.com/microelectronics/communitysource/); X Window System License
(http://www.x.org/xlicense.html).
Zum Aspekt der Entgeltlichkeit vgl. hinten IV.2.
KOCH (FN 5), 280.
Im Einzelnen dazu RETO M. HILTY, Lizenzvertragsrecht, Bern 2001, 122 ff.
Insoweit unterscheiden sich das schweizerische dualistische und das deutsche monistische Verständnis des Urheberrechts grundlegend (zum deutschen Recht vgl. HILTY [FN 19], 112 ff.;
KOCH [FN 5], 275; SESTER [FN 9], 797 f.; je mit Verweisen), weshalb die deutsche Lehre sich insoweit nur mit Zurückhaltung heranziehen lässt.
4
cense auch die freie Benutzbarkeit von Derivaten und den Verzicht auf die Begründung proprietärer Rechte verlangt, sehen andere Lizenzen gewissen Gestaltungsmöglichkeiten vor. Überblicksmässig ergibt sich folgendes Bild 21:
kosten- Freie Ver- UneingeQuellcode
lose
teilung
schränkter vorhanden
Nutzung
Gebrauch
Quellcode
modifizierbar
Derivate
müssen
frei sein
Kein Bezug
zu proprietärer Software
Proprietär
0
0
0
0
0
0
0
Shareware
r
r
0
0
0
0
0
Freeware
r
r
r
0
0
0
0
BSD
r
r
r
r
r
0
0
GNU Lessor
Public License
r
r
r
r
r
r
0
GNU General
Public License
r
r
r
r
r
r
r
d) Das Konzept der freien Software hat verschiedene Vorteile: Die kostenlose
Zurverfügungstellung der Software ermöglicht eine schnelle Verbreitung der
Software mit geringem Aufwand (mit der Folge der Verbesserung der Marktpräsenz und Kundengewinnung) und es entsteht ein freier Wettbewerb unter den
Entwicklern/Benutzern22; nachteilig vermag sich immerhin auszuwirken, dass
die Konkurrenz kaum mehr fassbar wird. Weiter dürfte die Offenheit des Source
Code die Innovation fördern; das Konzept der freien Software führt auch zu grosser Transparenz und ermöglicht die Schaffung neuer Support-Mechanismen
(Dienstleistungen wie Wartung, Pflege etc.); technisch lässt sich mit der freien
Software zudem die Aufwärtskompatibilität gewährleisten. Schliesslich ist der
Vorteil nicht zu unterschätzen, dass die Benutzer selber zu Mitentwicklern von
Software werden können und damit die schnelle, dynamische und auch situative
Einführung neuer Funktionalitäten möglich wird23. Eine solche Entwicklung ist
21
22
23
Die nachfolgende Darstellung geht zurück auf Vorarbeiten der Studierenden HADI MODARRES
und FETI SALIJI im Rahmen eines Seminars an der Universität Zürich.
Vgl. auch ANDREAS KAPP, Open Source „made in Switzerland“ – Eine Reportage, netzwoche
17/2002, 6 f.; zur wettbewerbssteigernden Funktion der freien Software vgl. SANDL (FN 9), 349 f.
In der Lehre wird das Vorgehen, Fehlerbereinigungen und Weiterentwicklungen durch eine Vie lzahl von Interessierten vorzunehmen, auch als „bazaar“ bezeichnet: Vgl. ERIC S. RAYMOND, The
cathedral and the bazaar, http://tuxedo.org/~esr/writings/cathedral-bazaar/.
5
insbesondere bei Vorliegen
unterstützt) denkbar.
aktiver
Benutzerkonferenzen
(newsgroup-
Zwischenzeitlich ist das wirtschaftliche und das wirtschaftspolitische Potential
der freien Software bereits erheblich: Gemäss Recherchen sollen heute schon
zwei Drittel der Internet-Server auf dem offenen Linux-System aufsetzen; über
die Hälfte der Unternehmen benutzen freie Software und auch die Behörden
werden sich ihrer Bedeutung immer stärker bewusst24.
II.
Vertragstypenkonzept
a) Das in Kontinentaleuropa kodifizierte Vertragsrecht sieht regelmässig eine
grössere Zahl von Vertragstypen vor, die den Rechtsunterworfenen zur Disposition stehen. Diese Vertragstypen widerspiegeln die Bedürfnislage der Zivilgesellschaft am Ende des 19. Jahrhunderts. Die geregelten Verträge stellen aber
nicht eine exklusive Palette verfügbarer Typen dar, d.h. das auf dem Prinzip der
– an sich grundrechtlich abgesicherten25 – Vertragsfreiheit26 beruhende Obligationenrecht statuiert keinen vertragsrechtlichen Typenzwang27; in den letzten
Jahren haben sich denn auch – gestützt auf die kraft Privatautonomie vorhandenen Gestaltungsfreiheiten – immer mehr Innominatkontrakte entwickelt28. Unter
diesen Begriff fallen Verträge, welche der Gesetzgeber weder im Besonderen
Teil des OR noch in einem Spezialgesetz geregelt hat29; als hauptsächlichste Ar-
24
25
26
27
28
29
Weitere Zahlen bei SANDL (FN 9), 347; zu den legisla torischen Bemühungen in der Europäischen
Union vgl. SANDL (FN 9), 347 f.; zur Bedeutung der freien Software vgl. auch die erste internationale Open Source Content Management Systems Conference an der ETH Zürich vom 21./22.
März 2002; zu den neuen Rechtsfragen BERND REICHERT , Welche Freiheit ist gemeint?, NZZ Nr.
176 vom 2.8.2002, S. 49.
Die Mehrheit der Verfassungsrechtler anerkennt zwar kein eigenständiges Grundrecht auf Vertragsfreiheit (ULRICH HÄFELIN/WALTER HALLER, Schweizerisches Bundesstaatsrecht, 5. Aufl.
Zürich 2001, N 630, 638; JÖRG P AUL MÜLLER, Grundrechte in der Schweiz, Bern 1999, 645, 667
f.; RENÉ RHINOW/GERHARD SCHMID/GIOVANNI BIAGGINI, Öffentliches Wirtschaftsrecht, Basel/Frankfurt 1996, 141), sondern nimmt einen Rückbezug auf die Wirtschaftsfreiheit bzw. die
Eigentumsgarantie vor; teilweise wird immerhin darauf hingewiesen, Vertragsfreiheit und Privatautonomie würden ein ungeschriebenes Grundrecht darstellen (FRITZ GYGI/P AUL RICHLI, Wirtschaftsverfassungsrecht, 2. Aufl. Bern 1997, 52; BURKARD J. WOLF , Vertragsfreiheit – das verkannte Verfassungsrecht, AJP 2002, 8).
Vgl. WALTER R. SCHLUEP /MARC AMSTUTZ , Kommentar zum Schweizerischen Privatrecht, Obligationenrecht I: Art. 1-529, hrsg. von HEINRICH HONSELL/NEDIM P ETER VOGT/WOLFANG
WIEGAND, 2. Aufl. Basel/Frankfurt a.M. 1996, Einleitung vor Art. 184 ff., N 1; ERNST A. KRAMER, Kommentar zum Obligationenrecht, Allgemeine Bestimmungen, Art. 19-22, Bern 1991,
Art. 19-20 N 49 ff. mit Verweisen.
Vgl. auch HEINRICH HONSELL, Schweizerisches Obligationenrecht, Besonderer Teil, 6. Aufl.
Bern 2001, 15 f., 402 f.
Dazu im Einzelnen SCHLUEP /AMSTUTZ (FN 26), Einleitung vor Art. 184 ff., N 81 ff.
SCHLUEP /AMSTUTZ (FN 26), Einleitung vor Art. 184 ff., N 5 mit Verweisen.
6
ten von Innominatkontrakten sind die gemischten Verträge, die Verträge eigener
Art (sui generis) und die zusammengesetzten Verträge in Betracht zu ziehen30.
b) Die Diskussion des Vertragstypenkonzepts lässt es als angebracht erscheinen,
den Begriff „Typus“ etwas genauer zu betrachten. Ein Typus beruht auf einem
Komplex von Merkmalen, die je nach den Umständen relevant sind; ein konkretes, einem bestimmten Typus zuordnungsfähiges Gebilde erfüllt die den Typus
auszeichnenden Eigenschaften in relativ hohem Masse31. Ein Typus weist somit
abstufbare Merkmale auf, welche eine Reihe darstellen, in die sich die relevanten Faktoren nach dem Grad der Ausprägung des betreffenden Merkmals einordnen lassen32. Das typologische Denken klassifiziert demgemäss nach dem
Grad, welchen die betroffenen Objekte im Lichte der charakteristischen Ordnungsfunktion des Typus erreichen33.
Die zu einem Typusmerkmal gehörigen Einordnungen lassen sich durch zwei
Relationen, nämlich die Relation G (x,y), welche die Ausprägung als gleich typisches Merkmal kennzeichnet, und die Relation V (x,y), welche eine unterschiedliche Nähe zum Typusmerkmal ausdrückt, charakterisieren34. Beide Relationen sind transitiv, die Relation G indessen symmetrisch, die Relation V
asymmetrisch35. Je mehr V-Elemente in einer bestimmten Konstellation vorhanden sind, umso weniger lässt sich eine Typengebundenheit annehmen.
III. Urheberrechtliche Determinanten
Die Frage der urheberrechtlichen Schutzfähigkeit von freier Software36 beurteilt
sich auf Grund der allgemeinen Kriterien des URG, d.h. das „Programm“ muss
eine geistige Schöpfung darstellen und einen individuellen Charakter aufweisen
(Art. 2 Abs. 1 URG)37. Materiell geht es somit um die Einmaligkeit der Software-„Komposition“; im Vordergrund steht das Quellformat („Source Code“),
d.h. der Code für alle in ihm enthaltenen Module inkl. Schnittstellendefinitionen
30
31
32
33
34
35
36
37
HONSELL (FN 27), 16 ff.; SCHLUEP /AMSTUTZ (FN 26), Einleitung vor Art. 184 ff., N 6 ff mit
Verweisen.
WALTER OTT , Die Problematik einer Typologie im Gesellschaftsrecht, Diss. Zürich, Bern 1972,
34.
OTT (FN 31), 39.
Vgl. auch CARL HEMPEL/P AUL OPPENHEIM , Der Typusbegriff im Lichte der Logik. Wissenschaftstheoretische Untersuchungen zur Konstitutionsforschung und Psychologie, Leiden 1936,
78 ff., 80 f.
HEMPEL/OPPENHEIM (FN 33), 36.
OTT (FN 31), 33.
Zur Wirkung der einzelnen Nutzungskomponenten sowie zur Abgrenzung von der Freeware und
der Shareware vgl. KOCH (FN 5), 334.
MANFRED REHBINDER, Schweizerisches Urheberrecht, 3. Aufl. Bern 2000, N 71 f.
7
und Skripts, welche die Kompilierung und Installation ausführbarer Programmteile kontrollieren38.
Die vorliegend nicht im Zentrum stehende urheberrechtliche Betrachtungsweise
verursacht mit Bezug auf die freie Software nicht zuletzt deshalb zusätzliche
Komplikationen, weil es deren Konzept entspricht, dass die ursprüngliche Entwicklung und Weiterentwicklung durch verschiedene Personen erfolgen39. Den
Linux-Kernel hat zwar Linus Torvalds (weitestgehend) allein erstellt, was die
Urheberrechte in seiner Person hat aufleben lassen (Art. 6 URG). Spätere Anpassungen sind jedoch durch andere Software-Entwickler erfolgt, mit der Konsequenz der Entstehung von Miturheberschaft (Art. 7 URG), deren genaue Ausgestaltung indessen angesichts der teilweise nur schwer identifizierbaren Beiträge eine komplexe Struktur aufweist40.
Ungeachtet dieser urheberrechtlichen Fragestellungen lässt sich für die vorliegende vertragstypologische Betrachtung grundsätzlich davon ausgehen, dass ein
(schuldrechtliches) einfaches und übertragbares „Nutzungsrecht“ an der jeweils
aktuellen Version der freien Software an den Nutzer eingeräumt wird41; Bearbeitungs- und Umgestaltungsergebnisse sind vom Nutzer wieder – ohne Verbindung mit proprietärer Software – den Interessierten offenzulegen, weshalb eine
Hinterlegung des Source Code unterbleiben kann42.
IV.
Vertragsqualifikationsbezogene Problembereiche
In den nachfolgenden Überlegungen zur vertragstypologischen Einordnung der
Nutzungsrechteeinräumung an freier Software wird davon ausgegangen, dass
materielles Schweizer Recht zur Anwendung kommt. Praktisch betrachtet ist
diese Vorgabe deshalb nicht selbstverständlich, weil viele zur Verfügung stehende „General License Conditions“ von amerikanischen Unternehmen stammen, die teilweise eine Rechtswahl für das amerikanische Recht treffen43. Eine
Ausnahme stellt immerhin die Regelung zur GNU General Public License dar,
die mit Bezug auf die Gewährleistungs- und Haftungsausschlussnormen einen
ausdrücklichen Vorbehalt zugunsten der anwendbaren Rechtsordnung („to the
extent permitted by applicable law“ bzw. „unless required by applicable law“)
enthält44.
38
39
40
41
42
43
44
Vgl. die Nachweise vorne FN 8 und zum deutschen Recht KOCH (FN 5), 275.
Vgl. vorne Ziff. I.
Vgl. im Einzelnen dazu KOCH (FN 5), 277, 278 f. mit Verweisen.
KOCH (FN 5), 333.
Vgl. auch HILTY (FN 19), 290 ff.; zum deutschen Recht KOCH (FN 5), 335.
Vgl. die vorne in FN 16 erwähnte IBM Public License (Art. 7) und Mozilla License (Art. 11,
wenn zumindest eine Person in den USA domiziliert ist).
GNU General Public License Art. 11 und Art. 12.
8
Nach allgemeinen international-privatrechtlichen Grundsätzen beurteilt sich bei
Fehlen einer Rechtswahl das anwendbare Recht im Falle von Immaterialgüterrechtsverträgen nach dem Wohnsitz derjenigen Vertragspartei, welche die Nutzung an einem Immaterialgüterrecht einräumt (Art. 122 IPRG); anzuknüpfen ist
somit am Recht des (hauptsächlichsten) Entwicklers der freien Software45. Teilweise wird in der (deutschen) Lehre argumentiert, bei Verwendung der GNU
General Public License müsse grundsätzlich das amerikanische Recht zur Anwendung kommen, weil dieses Vertragskonzept unter der US-Rechtsordnung
entstanden sei46. Dieser Argumentation lässt sich indessen entgegenhalten, dass
die vorformulierten „General License Conditions“ der Sache nach nur ein Vertragsmuster darstellen, das wie andere ähnliche „Muster“ unabhängig von einer
konkreten Rechtsordnung verwendbar sein soll47. Wird der Aspekt der Nähe
zum „Objekt“ in den Vordergrund gerückt, erscheint der Bezug zum amerikanischen Recht nicht unbedingt als zwingend, zumal wenn ein Nutzer in der
Schweiz eine Version der freien Software erhält, die ein anderer Schweizer weiterentwickelt hat.
Über diese Betrachtungsweise hinaus bleibt zu beachten, dass jedenfalls im
Verkehr mit Endverbrauchern die Sonderanordnungen zum Schutze der Konsumenten zur Anwendung gelangen können. Im Grundsatz hat ein Konsument die
Möglichkeit, auf dem Recht an seinem Wohnsitzort zu bestehen48 und ein
Streitverfahren beim zuständigen Gericht seines Wohnsitzes abzuwickeln49.
1.
Problem des Wortlautbezugs
Die Verwendung von freier Software, meistens verfügbar auf dem Internet, beruht regelmässig auf einer vertraglichen Absprache, die zwar nicht zwingend
schriftlich vorliegt. Der Anbieter von freier Software gibt nämlich zu verstehen,
dass der potentielle Nutzer sich an elektronisch zur Verfügung gestellte „General License Conditions“ zu halten habe. Ungeachtet des Aspekts der rechtsgültigen Übernahme von Allgemeinen Geschäftsbedingungen50 macht diese Aussage
im Zusammenhang mit dem Angebot deutlich, dass die Eingehung einer Vertragsbeziehung gewollt ist und dass ein Mindestmass an zu beachtenden Grundregeln zur Anwendung kommen soll. Vertragstypologisch stellt sich deshalb die
Frage, ob die Verwendung der Begrifflichkeit „General License Conditions“ bedeute, dass es sich bei der Vertragsabsprache um einen Lizenzvertrag handle.
45
46
47
48
49
50
FRANK VISCHER/LUZIUS HUBER/DAVID OSER, Internationales Vertragsrecht, 2. Aufl. Bern 2000,
N 602 ff.
Vgl. METZGER/JAEGER (FN 3), 842.
SESTER (FN 9), 802.
ROLF H. WEBER, E-Commerce und Recht, Zürich 2001, 43 ff. mit Verweisen.
WEBER (FN 48), 99 ff. mit Verweisen.
WEBER (FN 48), 326 ff.; KARIN F. SCHWAB, Die Übernahme von Allgemeinen Geschäftsbedingungen in elektronisch abgeschlossene Verträge, Diss. Zürich 2001.
9
a) Eine allgemein anerkannte Umschreibung des Lizenzvertrages steht weiterhin
aus, und zwar nicht zuletzt angesichts der Tatsache, dass lizenzvertragliche Beziehungen sehr unterschiedliche Ausprägungen erfahren können51. Ein Lizenzvertrag zeichnet sich regelmässig durch verschiedene Elemente aus, nämlich (1)
die Beteiligung von mindestens zwei Parteien (Lizenzgeber und Lizenznehmer),
(2) die Eingehung des Vertragsverhältnisses auf eine bestimmte oder unbestimmte Dauer, (3) das Vorhandensein eines faktisch oder rechtlich vorbehaltenen immateriellen Gutes auf der Anbieterseite, (4) die Ermächtigung an den
Nutzer zur beschränkten oder unbeschränkten Benutzung dieses Immaterialgutes
und (5) die etwaige Verpflichtung des Nutzers zur Erbringung einer Gegenleistung52.
Im Zusammenhang mit der freien Software ist unter den fünf vorerwähnten Begriffselementen insbesondere das Kriterium der „Gegenleistung“ (bzw. Vergütung) konkret zu betrachten. Selbst wenn die Lehre den Lizenzvertrag grundsätzlich als einen (vollkommen) zweiseitigen Vertrag qualifiziert und die Vergütung im Lizenzvertrag als „normaltypisch“ bezeichnet werden kann, ist sie doch
nicht zwingend53. Schon in den „traditionellen“ immaterialgüterrechtlichen Kontexten gibt es die sog. Gratis- oder Freilizenz54. Immerhin lässt sich nicht übersehen, dass eine solche Freilizenz regelmässig im Zusammenhang mit einem
anderen Transaktionstyp (z.B. einem Kauf- oder Werkvertrag) steht oder ein
längerfristiger Duldungstatbestand vorliegt; die Lehre geht deshalb zutreffend
davon aus, dass kostenlose Lizenzen selten und im Zweifel nicht zu vermuten
seien55.
b) Lizenzverträge enthalten regelmässig Bestimmungen zu Art und Ausmass der
Nutzung eingeräumter Rechte. Theoretisch lässt sich jegliche Berechtigung, die
nicht auf einer Rechtsübertragung beruht, als Lizenz werten; denkbar ist deshalb
insbesondere auch die Argumentation, die Weiterverwendungsbeschränkungen
bei der freien Software seien die „Gegenleistung“ für die unentgeltliche Einräumung der obligatorisch wirkenden Nutzungsrechte, und zwar im Sinne einer
Anknüpfung an das Konzept der sog. „Implied License“ 56. Immerhin ist im Vergleich zu den „traditionellen“ Lizenzvertragstypen bei der freien Software die
Anordnung, dass der Nutzer etwaige Weiterentwicklungen der Software wiederum unentgeltlich zur Verfügung zu stellen hat, nicht „typisch“ im vorerwähnten
Sinne; die Einbindung des Nutzers lässt sich nur mit dem besonderen Wesen der
51
52
53
54
55
56
Grundlegend HILTY (FN 19), 7 ff. mit Verweisen.
HILTY (FN 19), 6 f.
Vgl. etwa MARIO M. PEDRAZZINI, Werkvertrag, Verlagsvertrag, Lizenzvertrag, SPR VII/1, Basel
1977, 495, 596 f.
HILTY (FN 19), 13, 271 f. mit Verweisen; KOCH (FN 5), 280.
HILTY (FN 19), 485.
Eingehender dazu HILTY (FN 19), 260 ff. mit FN 290 und 264 f.; zum besonderen Aspekt der
Weiterverbesserung der Lizenz vgl. HILTY (FN 19), 528 ff.
10
freien Software erklären57; sowohl unter dem Gesichtspunkt der Vergütung wie
der Weiterverwendungsanordnungen ist die Begründung von Nutzungsrechten
an freier Software somit typologisch nicht völlig problemfrei unter das „traditionelle“ Konzept des Lizenzvertrages subsumierbar.
c) Die Verwendung der Begrifflichkeit „General License Conditions“ verursacht
indessen keine unüberwindbaren Komplikationen. Lehre und Rechtsprechung
gehen nämlich übereinstimmend davon aus, dass die Verwendung bestimmter
rechtlicher Begriffe nicht zwingend bedeutet, dass auch die entsprechenden
Rechtsnormen zur Anwendung kommen. Ausschlaggebend sind vielmehr Sinn
und Zweck der Vertragsabsprache58. Der Wortlaut mag zwar ein Indiz für die
Vorstellungen der Vertragsparteien sein, doch ist nicht auszuschliessen, dass
andere Indizien, z.B. der Regelungsinhalt der „General License Conditions“, den
Schluss auf einen anderen Vertragstyp als naheliegender erscheinen lassen. Die
Absprache, dass die „General License Conditions“ gelten, bedeutet deshalb
nicht, dass die Parteien einen Lizenzvertrag abgeschlossen haben.
2.
Problem der Unentgeltlichkeit
a) Die Einräumung eines (dinglichen oder obligatorischen) Nutzungsrechts an
freier Software ist regelmässig nicht mit einer Vergütung verknüpft59. Aus diesem Grunde sind diejenigen Nominatsvertragstypen des OR nicht anwendbar,
welche zwingend eine Gegenleistung bzw. Vergütung zugunsten des Anbieters
vorsehen60. Die Vergütung ist ein Essentiale insbesondere beim Kaufvertrag
(Art. 184 OR), beim Mietvertrag (Art. 253 OR) und beim Werkvertrag
(Art. 363 OR); mangels Pflicht zur Bezahlung eines Nutzungsentgelts bei freier
Software fällt somit die Anwendung des Kauf-, Miet- oder Werkvertragsrechts
ausser Betracht.
b) Das Recht der Leihe (Art. 305 OR) erscheint trotz der Möglichkeit einer unentgeltlichen Verabredung deshalb als nicht sehr passend, weil eine Rückgabe
der freien Software als Objekt der Leihe regelmässig nicht vorgesehen ist; die
Tatsache, dass sich der Nutzer verpflichtet, etwaige Weiterentwicklungen der
Software wiederum (unentgeltlich) zur Verfügung zu stellen, deckt sich nicht
mit dem bilateralen Konzept der Leihe, denn dem Wesen der freien Software
entspricht vielmehr, dass eine grosse Zahl potentieller Nutzer in den Genuss solcher Weiterentwicklungen kommen soll61.
57
58
59
60
61
Vgl. auch SESTER (FN 9), 798.
Vgl. BGE 113 II 51 f. und schon BGE 11, 399.
Mit Vergütung ist nachfolgend ein Nutzungsentgelt gemeint; eine Kostenerstattung z.B. für die
Programmkopie ist ohne weiteres gestattet (vgl. Art. 1 der GNU General Public License).
KOCH (FN 5), 335; SESTER (FN 9), 800.
KOCH (FN 5), 335.
11
c) Insbesondere die deutsche Lehre hat im Lichte der Unentgeltlichkeit der
Rechteeinräumung an freier Software dafür gehalten, das entsprechende Rechtsverhältnis sei als Schenkung zu qualifizieren62. Das Konzept der Schenkung
nimmt zwar den Gedanken der Unentgeltlichkeit auf, doch ist eine gewisse Zurückhaltung mit Bezug auf den altruistischen Charakter der Einräumung von
Nutzungsrechten an freier Software geboten63. Zumindest diejenigen Personen,
welche die Software weiterentwickeln, beabsichtigen regelmässig, durch die Investition ihres Know how eine Wertschöpfung (z.B. Effizienzsteigerung durch
Vermeidung von unnötigen Parallentwicklungen) zu erzielen und später allenfalls durch Pflege- und Wartungsaufträge zu profitieren64. Gerade bei der Verbreitung von Programmen wie Linux ist zudem unübersehbar, dass neben
wirtschaftlichen Interessen auch strategische Ziele vorhanden sind (z.B. Verbreitung des eigenen Know how), die vertragstypologisch sich kaum mit der Schenkung vereinbaren lassen65. Schliesslich tritt beim Urheber der Software (im Gegensatz zum Schenker) keine Entreicherung durch Weggabe eines werthaltigen
Objektes ein66; auch erwirbt der Beschenkte kein absolutes Recht an der Software.
Ein weiterer Problembereich betrifft die von den Nutzern zu beachtenden Folgeregeln, z.B. (1) die Pflicht, Weiterentwicklungen der Software unentgeltlich
zur Verfügung zu stellen, und (2) den Verzicht auf die monetäre Verwertung
von freier Software. Zwar lässt sich eine Schenkung mit Auflagen verbinden
(Art. 245 OR)67. Konzeptionell geht es bei den „traditionellen“ Schenkungsauflagen aber um Anliegen des Schenkers (z.B. bestimmte Verwendung des geschenkten Gegenstandes, Interessenwahrung zugunsten des Schenkers). Soweit
sich der Entwickler von freier Software im Sinne einer Nutzenmaximierung des
eigenen Produktes den Rückfluss von zusätzlichem Know how verspricht, ist die
Anwendung der Auflagenregelung des Schenkungsrechts nicht völlig unsachgemäss, doch erfolgt – abweichend vom traditionellen Modell – die auflagengemässe Leistung nicht aus den Erträgnissen des geschenkten Objekts und besteht aus technischen Gründen keine Möglichkeit eines Rückfalls der „Schen-
62
63
64
65
66
67
METZGER/JAEGER (FN 3), 847.
Auf den altruistischen Charakter der freien Software weisen die Präambel zur GNU General Public License und Richard Stallman hin (http://www.gnu.org/philosophy/free-sw.de.html); kritisch
zu dieser Betrachtungsweise zutreffend SESTER (FN 9), 798, 799; SANDL (FN 9), 347; KOCH (FN
5), 335.
SESTER (FN 9), 800.
Mit der freien Software sollte bewusst auch ein „Werkzeug“ gegen die Dominanz der MicrosoftAnwendungssoftware geschaffen werden: Vgl. auch SESTER (FN 9), 799; WEBER (FN 11), 179.
KOCH (FN 5), 335; SESTER (FN 9), 799.
Vgl. dazu NEDIM P ETER VOGT, Kommentar zum Schweizerischen Privatrecht, Obligationenrecht
I: Art. 1-529, hrsg. von HEINRICH HONSELL/NEDIM P ETER VOGT/WOLFANG WIEGAND, 2. Aufl.
Basel/Frankfurt a.M. 1996, Art. 245 N 1, 4; zur Problematik der Einhaltung von Formvorschriften
nach deutschem Recht (notarielle Beurkundung gemäss § 518 BGB) vgl. KOCH (FN 5), 335.
12
kung“ (Art. 246/247 OR) im Falle der Nichteinhaltung der Auflagen68. Mit der
Weiterentwicklung der freien Software zugunsten der Allgemeinheit hat das
Konzept von Art. 245 OR zudem wenig gemein, d.h. das Auflagenkonzept des
Schenkungsrechts würde im Falle der Anwendung auf freie Software recht stark
strapaziert.
Zusammenfassend lässt sich deshalb davon ausgehen, dass die Bestimmungen
des Schenkungsrechts als nur beschränkt geeignetes Instrumentarium erscheinen, um einen sinnvollen Rechtsrahmen für die freie Software zu schaffen; die
den Typus Schenkung prägenden Merkmale sind mit Bezug auf die freie Software lediglich teilweise vorhanden.
d) Bei Vorliegen eines Vertrags zugunsten Dritter (Art. 112 OR) erwirbt der
Dritte in die Regel die Leistung „unentgeltlich“, weil das Grundverhältnis ungeachtet der Leistungserbringung zwischen den ursprünglichen Vertragsparteien
bestehen bleibt69. Von einem Vertrag zugunsten Dritter lässt sich aber deshalb
im Konzept der freien Software kaum sprechen, weil jeder potentielle Nutzer auf
die freie Software zugreifen kann, d.h. es fehlt an der erforderlichen Bestimmbarkeit des Dritten70.
3.
Problem der Interessenvergemeinschaftung
Das der Idee der freien Software zugrunde liegende Konzept bezweckt weder
einen kurzfristigen Leistungsaustausch zwischen Urheber und Nutzer noch eine
einseitige Zuwendung (Schenkung); vielmehr haben die ursprünglichen Urheber
ein Interesse daran, dass die einmal zur Verfügung gestellte Software ständig
verbessert und weiter verbreitet wird (z.B. Betriebssystem Linux). Auch Zweitund Drittnutzer, die an der Weiterentwicklung der Software beteiligt sind, können daran interessiert sein, dass ein Viertnutzer ebenfalls Verbesserungen an der
Software anbringt und das neue „Produkt“ wieder unentgeltlich dem Markt anbietet. Die Weiterentwicklung der Software stellt somit nicht allein eine fremdnützige Tätigkeit dar, sondern gewisse Elemente von Interessenkonvergenzen
lassen sich nicht übersehen71.
Bei Vorliegen gleich gerichteter Interessen ist an das Zustandekommen einer
einfachen Gesellschaft zu denken (Art. 530 OR). Begriffselemente sind die ge-
68
69
70
71
Vgl. SESTER (FN 9), 800, 801; der Hinweis von METZGER/JAEGER (FN 3), 847, die Auflage würde keine finale Bedeutung haben, ändert nichts an der Tatsache, dass die besondere Art der Auflage bei freier Software nicht dem „Schenkungsmodell“ entspricht.
Vgl. ROLF H. WEBER, Kommentar zum Obligationenrecht, Allgemeine Bestimmungen, Art. 110113, Bern 2002, Art. 112 N 104 ff.
Vgl. WEBER (FN 69), Art. 112 N 39; KOCH (FN 5), 335.
Vgl. SESTER (FN 9), 800.
13
meinsame Zweckverfolgung und der Einsatz gemeinsamer Kräfte oder Mittel72.
Mit Bezug auf die Zielrichtung lässt sich beim Konzept der freien Software von
einer Vergemeinschaftung insoweit ausgehen, als Urheber, Weiterentwickler
und Nutzer an einer Optimierung der Software interessiert sind, und zwar in einer Weise, dass die Verwendung der Software eigene Vorteile mit sich bringt73.
Hingegen dürfte es schwieriger sein, die gemeinsamen Kräfte und Mittel zu identifizieren; in der Regel wird ein Weiterentwickler dasjenige Know how einsetzen, das ihm zur Verfügung steht, ohne mit dem ursprünglichen Urheber oder
mit dem Vornutzer vorerst Kontakt aufgenommen zu haben; in der Praxis kann
es auch durchaus vorkommen, dass die Weiterentwicklung von freier Software
in Bahnen gelenkt wird, die den Intentionen des ursprünglichen Urhebers nicht
entsprechen.
Dogmatisch nicht unproblematisch ist weiter die Tatsache, dass die Mitglieder
der einfachen Gesellschaft sich zwar theoretisch identifizieren lassen, im voraus
aber einander nicht bekannt sind, weil sich die Identifikation erst aus der Anbringung des Weiterentwicklungsvermerks, soweit tatsächlich vorgenommen,
ergibt; die Mitglieder der einfachen Gesellschaft sind somit (zumindest teilweise) nur virtuell vorhanden. Zudem fehlt es an einem Gesellschaftsvermögen und
bedarf es keiner Vertretungsregelung74.
Die Anwendung des Rechts der einfachen Gesellschaft auf das Konzept der freien Software lässt sich deshalb ebenfalls nicht ohne dogmatische Probleme verwirklichen, d.h. die typologischen Merkmale der einfachen Gesellschaft sind
beim Konzept der freien Software nur in beschränktem Ausmasse vorhanden;
wie auch immer eine Anknüpfung erfolgt, ist der Aspekt einer gewissen Interessenvergemeinschaftung der Beteiligten bei freier Software aber zu beachten.
4.
Problem der Weiterverwendungsordnung
Die GNU General Public License ordnet vertragsrechtlich ausdrücklich an, dass
die Nutzer von freier Software nicht das Recht haben, die ihnen eingeräumten
Rechte weiter zu übertragen, sondern jeder nächste Nutzer der Lizenz erhält die
erforderlichen Rechte unmittelbar vom ursprünglichen Urheber eingeräumt75.
Rechtlich ergibt sich somit nicht eine fortlaufende Kette der Einräumung von
Nutzungsrechten, sondern in jedem einzelnen Fall ist von einer (obligatorischen)
Rechteeinräumung durch den ursprünglichen Berechtigten auf den Folgenutzer
72
73
74
75
Vgl. ARTHUR MEIER-HAYOZ/P ETER FOSTMOSER, Schweizerisches Gesellschaftsrecht, 8. Aufl.,
Bern 1998, § 12 N 19.
SESTER (FN 9), 801.
Die Haftungsregelung wird regelmässig vertraglich detailliert vorgenommen; zu den Haftungsaspekten vgl. den demnächst erscheinenden Beitrag von ROLF H. WEBER, Open Source Software:
Vertragsgestaltung, in: ROLF H. WEBER/MATHIS BERGER/ROLF AUF DER MAUR (Hrsg.), Geschäftsplattform Internet IV – Open Source, Multimedia, Online Arbitration, Zürich 2003.
GNU General Public License, Art. 6.
14
auszugehen76. Dogmatisch liegt eine Besonderheit zudem darin, dass der ursprüngliche Urheber oft gar nicht weiss, wer Folgenutzer ist und im Sinne der
klassischen Vertragsabschlusslehre auch nicht von vornherein die Bestimmbarkeit möglicher Nutzer feststeht. Vielmehr kommen Nutzungsverträge mit
schuldrechtlicher Wirkung zwischen dem ursprünglichen Urheber und einem
Folgenutzer zustande, ohne dass sich der Urheber im Zeitpunkt der Nutzungsrechteeinräumung zwingend bewusst ist, wer — unter dem Gesichtspunkt der
Identität — der Folgenutzer sein soll. Die Bestimmbarkeit ergibt sich lediglich
durch Rückverfolgung der faktischen Nutzungskette, gestützt auf entsprechende
urhebervermerke und Mitwirkungspflichten der Zwischenglieder in der Nutzungskette77.
Der eigentliche Nutzungsumfang von freier Software wird regelmässig nicht
substantiell eingeschränkt78, d.h. der Urheber von freier Software räumt ein –
nicht exklusives – Recht zur (grundsätzlich kostenfreien) Verbreitung ein. Hingegen erwirbt der (potentielle) Nutzer kein Vermietrecht79; zwar stellt nach allgemeinen urheberrechtlichen Grundsätzen das Vermietrecht ein eigenständiges
Verwertungsrecht dar, doch widerspricht dem Konzept der freien Software,
durch Vermietung die Schaffung proprietärer Rechte zu ermöglichen. Der Nutzer ist zudem verpflichtet, auf eine proprietäre Ausgestaltung irgendeiner Weiterentwicklung der Software zu verzichten. Das „Copyleft-Prinzip“ bedeutet,
dass die Software rechtlich davor geschützt ist, bei Weiterentwicklung oder Einbindung in ein anderes Programm in einen (neuen) Urheberschutzbereich zu fallen80, d.h. freie Software soll konzeptgemäss frei bleiben.
Ungeeignet ist mit Bezug auf Computerprogramme, insbesondere freie Software, auch der sog. Erschöpfungsgrundsatz81. Zwar legt Art. 12 Abs. 2 URG
fest, dass nach Veräusserung bzw. Zustimmung zur Veräusserung eines Computerprogramms der Urheber keine Einwendungen gegen den weiteren Gebrauch
oder die Weiterveräusserung erheben kann, doch hat Art. 17 URV in Übereinstimmung mit der europäischen Rechtslage bereits eine liberalisierende Präzisierung vorgenommen82. Zudem lässt sich schon formal sagen, im Falle der Einräumung von Nutzungsrechten an freier Software fehle es an einer „Veräusserung“, weshalb die an sich wettbewerbsfreundliche und das Urheberrecht limi-
76
77
78
79
80
81
82
KOCH (FN 5), 338; die Vergabe von Unterlizenzen ist somit ausgeschlossen (vgl. HILTY [FN 19],
758 ff.).
Vgl. auch KOCH (FN 5), 338 f.
KOCH (FN 5), 337.
KOCH (FN 5), 336 f.; entsprechende Überlegungen gelten für das Leasing.
WEBER (FN 11), 178 f.; KOCH (FN 5), 333; vgl. auch IRA V. HEFFAN, Copyleft: Licensing Collaborative Works in the Digital Age, 49 Stanford Law Review 1467, 1507 ff. (1997).
Vgl. zum Erschöpfungsgrundsatz auch KOCH (FN 5), 335 f.
Vgl. RETO M. HILTY, Der Schutz von Computerprogrammen – nationale und internationale Normen auf dem Prüfstand des Internets, sic! 1997, 128, 139 f.
15
tierende Erschöpfungsregel gar nicht zur Anwendung komme; überdies entspricht dem Konzept der freien Software, dass schon vor dem Zeitpunkt der Erschöpfung keine exklusive Rechtsposition entsteht, weil die (unentgeltliche)
Zurverfügungstellung der Nutzungsrechte die (potentiellen) Nutzer gerade motivieren will, Weiterentwicklungen (als technisch und wirtschaftlich eigenständige
Nutzungsart) zu tätigen, ohne dass dadurch eine neue Rechtsposition erworben
wird, welche die freie Benutzbarkeit der Software einschränken könnte.
V.
Fazit
Die freie Software bzw. die Open Source Software ist ein relativ neues Phänomen, dessen Bedeutung in der wichtiger werdenden Informationsgesellschaft
indessen noch steigen wird; die Frage, ob Nutzungsrechte proprietär oder offen
zugänglich ausgestaltet werden sollen, ist dabei eine Grundfrage des Softwarerechts. Inwieweit im Falle einer nicht proprietären Regelung dennoch Weiterverwendungsbeschränkungen eine Rolle zu spielen vermögen, bedarf ebenfalls
einer prinzipiellen Lösung.
Erste Reaktionen nach dem Aufkommen der freien Software haben zur Annahme tendiert, dass bisherige urheber- und vertragsrechtliche Philosophien auf den
Kopf gestellt würden83. Diese weitgehende Einschätzung ist zwischenzeitlich
einer nüchternen Betrachtungsweise gewichen: Freie Software bringt zwar Neues, das aber mit dem herkömmlichen rechtlichen Instrumentarium erfassbar
bleibt.
Vertragsrechtlich betrachtet haben die vorerwähnten Überlegungen gezeigt, dass
die vorhandenen Vertragstypen des Obligationenrechts die freie Software nicht
sachgerecht in den Griff zu bekommen vermögen:
• Angesichts der Unentgeltlichkeit der Einräumung von Nutzungsrechten fällt
eine Anwendung der zwingend entgeltlich ausgestalteten Vertragstypen (z.B.
Kauf-, Miet- und Wertkvertrag) nicht in Betracht.
• Das Konzept der freien Software ist nicht so altruistisch ausgestaltet, dass die
Anwendung des Schenkungsrechts, ungeachtet der zusätzlichen Auflagenproblematik, sachgerecht wäre. Die Leihe setzt eine Objektrückgabe voraus,
die dem Konzept der feien Software widersprechen würde.
• Der im Gesetz nicht geregelte Lizenzvertrag ist an sich flexibel genug, um
verschiedene Aspekte des Modells der freien Software zu erfassen, selbst
wenn nicht alle „typischen“ Elemente vorhanden sind.
83
In diese Richtung gehen METZGER/JAEGER (FN 3), 848; relativierend KOCH (FN 5), 280.
16
• Das Recht der einfachen Gesellschaft spricht zwar die Interessenvergemeinschaftung an, setzt aber in der Regel einen engeren „Zusammenschluss“ voraus, als er bei der „Nutzergemeinschaft“ von freier Software vorliegt.
Gesamthaft betrachtet ist somit anstelle eines wenig überzeugenden Rückgriffs
auf kodifizierte Vertragstypen eher Bezug zu nehmen auf die allgemeinen Bestimmungen des OR, ergänzt durch einzelne Elemente des Lizenzvertrags, der
selber ein Innominatkontrakt ist, und der einfachen Gesellschaft, soweit ein Heranziehen solcher Elemente sich als sachgerecht erweist. Dieser Ansatz erscheint
angemessener als ein zwanghafter Versuch, die freie Software in ein vorhandenes dogmatisches Korsett zu drücken. Freie Software verlangt deshalb tatsächlich eine gewisse Befreiung von der traditionellen Vertragstypenlehre; anzustreben ist ein bewegliches System von allgemeinen rechtlichen Elementen, deren
Anwendung auf die neuen Formen der informationsgesellschaftsbezogenen
Phänomene passt.
17