Jusletter IT

Open Source Lizenzen sind die meist beachteten AGB der Welt. AGB haben in der Regel ein Problem gemeinsam: Sie werden nicht gelesen. Das unterscheidet sie (stark) von den mittlerweile 65 von der Open Source Initiative (OSI) anerkannten Open Source Lizenzen¹ . Diese Lizenzen führen seit der Herausgabe der Berkely Software Distribution (BSD) und der damit einhergehenden gleichnamigen Lizenz zur weltweit geführten Diskussion über die Anwendbarkeit und die Auslegungen der unterschiedlichen Lizenztexte.

Open Source Lizenzen schützen jedoch nicht nur das geistige Eigentum ihrer Benutzer, sondern versuchen auch eine Philosophie zu vermitteln, welche mittlerweile dazu beigetragen hat, alternative Geschäftsmodelle zu entwickeln. Darüber hinaus werden Open Source Lizenzen längst nicht mehr nur für die Lizenzierung von Quellcodes benutzt, sondern inspirieren Menschen wie bspw den KünstlerRonen Kadushin dazu, ihr Design oder ihre Produkte Open Source anzubieten und so Dritten die Möglichkeit einzuräumen, das Ursprungswerk nicht nur zum eigenen Gebrauch weiterentwickeln zu können. Doch die wenigsten Nutzer von Open Source Software bzw. Design können auch tatsächlich mit den eingeräumten Rechten etwas anfangen – wer kann schon einen Kernel umschreiben oder wie im Fall vonKadushin eine Stahlplatte mit einem Lasercutter bedienen – und so degradieren viele Open Source lizenzierte Software oder Güter zu rein kostenloser Ware² . Dabei ist das Potential von Open Source um vieles größer. Die dahinterstehende Philosophie birgt Chancen in einer Welt, welche sich momentan immer stärker hin zur totalen – wenn auch noch nicht totalitären – Überwachung bewegt, ein wenig Transparenz zu erzeugen. Dieser Beitrag soll diese Chancen kurz beleuchten und dabei auf die praktischen Probleme, welche Open Source Lizenzen momentan noch bereiten und welche Anforderungen noch an sie gestellt werden müssen, eingehen.

Als in den 1950er, 1960er Jahren die Geburt der Softwareindustrie stattfand, wie wir sie heute kennen, war die Lizenzierung von Software als solche praktisch unbekannt, da das «vendor lock-in» – wie es von Firmen wie DEC und IBM damals betrieben wurde – vorsah, Hardware und standardisierte (Basis-)Software zusammen zu vermieten und für die notwendige Individualisierung dann Gebühren zu verlangen. Dieses System des «eingesperrten» Kunden funktionierte solange bis die damalige US-Regierung unter Lyndon B. Johnson damit drohte den Monopolisten IBM in sieben unterschiedliche Unternehmen aufzuteilen³ . IBM entkam der Zerschlagung mit der Zusage, künftig Hard- und Software getrennt zu vermarkten. Ab dem 1. Januar 1970 mussten Kunden ihre IT getrennt bezahlen⁴ , hatten jedoch ab sofort die Möglichkeit, unterschiedliche IT-Lieferanten zu beauftragen.

Die daraufhin einsetzende Entwicklung führte zur ersten UNIX-Version⁵ , welche den 1.1.1970 auch als Startzeitpunkt der «Unix Time»⁶ und der ersten populären Open Source Lizenz, der bereits erwähnten BSD-Lizenz, festlegt. Als UNIX-Versionen Anfang der 1980er Jahre wieder zunehmend proprietär lizenziert wurden, störte dies eine der Lichtgestalten freier Software⁷ :Richard Stallman , der das GNU-Projekt als UNIX-Alternative startete.Stallman , der geistige Vater der populärsten Open Source Lizenz, der General Public License (GPL), gründete 1985 die Free Software Foundation (FSF) und bemühte sich in Folge um Kapital für die Arbeit am GNU-Projekt.Stallmans Wirken zeichnet sich nicht nur durch die Arbeiten am GNU-Projekt aus, sondern mehr noch durch das Propagieren seiner Philosophie der freien Software, den Aufbau einer Community und der Hoffnung, dass diese Einfluss auf die Gesellschaft ausüben könnte⁸ . NachStallmans Definition lässt sich Freie Software in vier verschiedene Stufen aufteilen⁹ , welche von der Open Source Definition der OSD aufgegriffen und zu zehn Punkten ausgebaut wurden. Diese unterschiedliche, inhaltlich in den wesentlichen Punkten übereinstimmende, Definition von Freier bzw. Open Source Software hat in der Praxis für einige Verwirrung gesorgt¹⁰ und wird daher als erstes zu lösendes Problem angeführt.

Stallman war für die jüngere Generation der FSF-Community Wegbereiter und Hindernis zugleich. Daher wurde 1998 die Loslösung von ihm beschlossen, um den Begriff im Wettbewerb mit proprietärer Software als geschäftsfreundlich und weniger ideologisch belastet darstellen zu können. Im Februar 1998 gründeteBruce Perens¹¹ zusammen mitEric S. Raymond die OSI, der Begriff Open Source wurde erdacht¹² und in Folge vonBruce Perens als Warenzeichen¹³ angemeldet. Der Begriff wurde zum Erfolg und dankbar von Medien und Wirtschaft aufgenommen. Zu diesem Erfolg hat wesentlich das Betriebssystem Linux beigetragen, welches mittlerweile auf 29 Millionen Nutzer kommt¹⁴ . Ebenso zeigte die Abwendung des Web-Browsers Netscape von einer proprietären Strategie, dass Open Source von der Wirtschaft anerkannt wurde. Leider kann dieser Aspekt aber nicht nur positiv bewertet werden, da allzu viele ursprünglich proprietäre Projekte ihre plötzliche Zuneigung zu Open Source weniger aus Überzeugung, sondern vielmehr als letzten Ausweg und damit wirtschaftlich notwendigen Schritt sahen. Dabei wurde häufig übersehen, dass die Open Source Community kein Auffangbecken für in Turbulenzen geratene IT-Projekte war oder ist und viele Projekte auch nach dem Lizenzwechsel scheiterten. Dieses Scheitern führte wiederum dazu, dass Open Source Kritiker sich darin bestätigt fühlten, dass Open Source Software wirtschaftlich nicht überlebensfähig und daher eine reine Spielwiese für angehende Informatiker und «Freaks» sei. Sie hatten mit dieser These nicht ganz unrecht, da viele mit viel Enthusiasmus gestartete Open Source Projekte nach Studienabschluss ihres Entwicklers bzw. ihrer Entwickler tatsächlich nicht länger betreut wurden und oftmals enttäuschte und frustrierte Nutzer hinterließen.¹⁵ .

Diese Tatsache war die Geburtsstunde von sourceforge.net.¹⁶ Im November 1999 wurde das Portal gegründet, das mittlerweile über 230,000 Projekte¹⁷ beherbergt und dazu genutzt wird, die Entwicklung von IT-Projekten zentral steuern zu können. Somit konnten viele «verwaiste» Projekte weiterentwickelt werden, indem sie unter eine Open Source Lizenz gestellt wurden. Mit der zunehmenden Anzahl an Open Source Software wuchs auch die Anzahl der Open Source Lizenzen. Diese Entwicklung führte in Folge zu einem der größten Probleme aus rechtlicher Sicht: Zum einen gab es die Frage nach der Auslegung einer jeden Lizenz aus Sicht der unterschiedlichen nationalen Rechtsordnungen, zum anderen die Kompatibilität der Lizenzen untereinander. Während die erste Frage bisher von einigen Gerichten geklärt wurde und damit zur Rechtssicherheit beigetragen hat, bleibt die zweite Frage ein offenes Problem und damit eine der großen Herausforderungen.¹⁸

Im Jahr 2004 hatten Open Source Lizenzen erste größere Bewährungsproben zu bestehen. Sowohl Wien¹⁹ als auch München²⁰ gaben bekannt, in ihrer Verwaltung auf Linuxdistributionen umzusteigen bzw. Pilotprojekte damit fortzusetzen²¹ . Kurz vor diesen Entscheidungen war am 19. Mai 2004 das weltweit erste Urteil zur Wirksamkeit der GPL vom LG München²² gefällt worden, welches als ein Meilenstein für die Rechtssicherheit der Lizenznutzer angesehen werden kann. Die GPL festigte durch dieses Urteil ihre Vormachtstellung als «Mutter aller Open Source Lizenzen», dennoch bleibt festzuhalten, dass Open Source Lizenzen die Gerichte bisher nur wenig beschäftigt haben²³ . Paradoxer Weise führt gerade dieser Umstand zu einer negativen Beurteilung von Open Source Software durch Rechtsberater. Zu verstehen ist das nur unter dem Aspekt des hohen Aufwands, sich ausreichend mit deren Lizenzinhalten auseinanderzusetzen. Neben diesen Hürden haben ebenfalls die haftungs- und gewährleistungsrechtlichen Regelungen der Open Source Lizenzen, die sich überwiegend am US-amerikanischen Recht orientieren, zu Rechtsunsicherheit geführt. Diese Kritikpunkte wurden in Folge aufgegriffen und führten zur Entwicklung der GPL 3 durch die FSF und der EUPL 1.0 im Auftrag der EU.

Die EUPL 1.0 wurde im Rahmen des EU-Programms der Kommission IDABC²⁴ im Zeitraum 2005 – 2007 geschrieben und von der Kommission am 9. Januar 2007 gebilligt²⁵ . Das IDABC hat die Aufgabe, die Interoperabilität europaweiter elektronischer Behördendienste für die öffentliche Verwaltung, Unternehmen und Bürger zu fördern. Da es im Rahmen dieser Aufgaben zur Entwicklung verschiedener Computerprogramme kam, deren Urheber die EG ist, wurde überlegt diese Programme unter eine Open Source Lizenz zu stellen. Dies nahm die EG zum Anlass, eine eigene Lizenz als Gegenstück zu den anderen Open Source Lizenzen zu schaffen, die auf amerikanischem Recht beruhen und nur unzureichend auf europäische Rahmenbedingungen Rücksicht nehmen. Bereits zwei Jahre später wurde die erste Überarbeitung am 9. Januar 2009 in Form der aktuell gültigen EUPL 1.1 veröffentlicht, welche in allen offiziellen europäischen Sprachen abrufbar ist.²⁶ Konnte man der EUPL 1.0 noch vorwerfen, potentielle Lizenzpartner mit der Bereitstellung des Lizenztextes ohne Hilfestellung alleine zu lassen²⁷ , so werden seit der EUPL 1.1 Kommentare angeboten, welche wesentlich dazu beitragen, die Akzeptanz der Lizenz in der Community zu erhöhen. Doch auch die Überarbeitung der Lizenz hinterlässt offene Fragen auf Grund unpräziser Formulierungen.

Bspw. beinhaltet die in den Punkten 7 und 8 EUPL angeführten Gewährleistungs- und Haftungsausschlüsse bzw. Haftungsbeschränkungen mE eine solche unpräzise Formulierung. «Die Arbeit an diesem Werk wird laufend fortgeführt » impliziert eine dauernde Weiterentwicklung des Werkes des Anwenders bzw. Lizenznehmers und sorgt damit für ein Sicherheitsgefühl bei diesem, da er davon ausgehen kann, dass er ein «lebendiges» Programm benutzt. Dies mag eventuell auf die Werke zutreffen, die unter der EUPL stehen und von der Kommission der EG entwickelt wurden, da diese evtl stetig weiterentwickelt werden. Dennoch wird man erstens nicht davon ausgehen können, dass das EUPL-lizenzierte Programm des Anwenders immer weiterentwickelt wird und zweitens ist es möglich, dass dies auf solche Programme nicht zutrifft, die zwar unter der EUPL lizenziert wurden, die aber nicht von der EG betreut werden. Der zweite Satz des Punkts 7 EUPL ist ebenso unverständlich, da er zwar den Lizenznehmer auf mögliche Bugs im Programm hinweist, dies jedoch keinen rechtlichen Nutzen hat²⁸ . Im Ergebnis muss die EUPL als Schritt in die richtige Richtung gewertet werden. Die Intention, eine europäische Lizenz zu schaffen hat seine Berechtigung, da sich die europäischen Immaterialgüterrechte sowie das Haftungs- und Gewährleistungsrecht teilweise eklatant vom amerikanischen Recht unterscheiden und diese Abweichungen immer wieder ein Hindernis bei der praktischen Anwendung waren. Neben der inhaltlichen Kritik an der Lizenz sollte auch der Sinn der EUPL als solche kurz hinterfragt werden. Fakt ist, dass eine Fülle von Open Source Lizenzen nicht dazu beiträgt, eine größere Rechtssicherheit unter den Vertragspartnern herzustellen. Die Zielsetzung eine «gesamteuropäische» Open Source Lizenz zu erstellen, erscheint mir momentan noch zum Scheitern verurteilt, da eine gemeinschaftsrechtliche Harmonisierung in den jeweiligen Rechtsgebieten zwar in Gang gebracht, aber noch nicht abschließend hergestellt wurde. Die Problematik der nicht einwandfreien Umsetzbarkeit der «amerikanischen » Open Source Lizenzen in Europa haftet damit auch der EUPL an, deren Geltung ebenfalls jeweils im nationalen Recht überprüft werden muss.

Auch die Weiterentwicklung der GPL 3, welche am 29. Juni 2007 präsentiert wurde²⁹ , ist bis heute nicht unumstritten. Stärkstes Indiz dafür war die Ansage von Linus Torvalds, den Linuxkernel nicht unter den Schutz der GPL 3 zu stellen³⁰ . Dennoch hat man bewiesen, dass die Anmerkungen der Wirtschaft ernst genommen werden und auch auf darauf reagiert werden kann. Ohne genauer auf den Inhalt der GPL 3 an dieser Stelle einzugehen, zeigt sich eine der großen Herausforderungen: Die Problematik hinsichtlich der Kompatibilität der Open Source Lizenzen untereinander.

Wichtig zu erwähnen bleibt der Rechtsstreit zwischen der SCO Group und IBM³¹ . In dem vor einem amerikanischen Gericht geführten «Stellvertreterkrieg» ging es nicht nur um die in der Klage beanspruchte 1 Milliarde Dollar, welche SCO von IBM wegen einer angeblichen Urheberrechtsverletzung bezahlt haben wollte, sondern dahinter steckte die Strategie, die Nutzer von Open Source Software zu verunsichern und vor allem von der Benutzung von Linux abzubringen. Die Klage kann als Indiz dafür gewertet werden, dass sich die Anbieter von proprietärer Software durch Open Source Software bedroht sahen und in äußerst dilettantischer Weise³² versuchten, gegen den wirtschaftlich immer erfolgreicher agierenden «Feind» vorzugehen. Die gerichtlichen Auseinandersetzungen fanden seit 2003 auf mehreren Schauplätzen statt und endeten 2007 vorerst mit dem Sieg der SCO-Gegner. Der Sieg gegen SCO, welches mittlerweile von einem Konkursverwalter geführt werden muss, kann als momentan größter Sieg der Open Source Community angesehen werden und zeigt, dass Open Source mittlerweile im Wirtschaftsleben angekommen ist, denn ohne den Rückhalt aus Wirtschaft und Industrie hätten die vielen auf Zermürbungstaktik ausgelegten Verfahren weder geführt noch allesamt gewonnen werden können. Abschließend bleibt der Blick auf die gegenwärtigen Herausforderungen und rechtlichen Problemstellungen zu legen.

Die aktuellen Herausforderungen für Open Source aus praktischer Sicht sowie die Einflussmöglichkeiten der Philosophie auf die Gesellschaft werden in Folge punktuell dargestellt und kommentiert:

Der Begriff Open Source hat lediglich die OSI als Markenverwalter³³ und ist mit keinem bestimmten Produkt assoziiert. Dies führt dazu, dass einige Firmen den Begriff Open Source für ihre Software benutzen, obwohl die Lizenzbedingungen, unter der die Produkte vertrieben werden, nicht als Open Source Software iSd OSD angesehen werden dürfen. Ein prominenter Fall, der die OSI dazu veranlasst hat, gegen solche «Trittbrettfahrer» vorzugehen, die den Ruf von Open Source nutzen, ohne jedoch deren Vorgaben erfüllen zu wollen, ist «SugarCRM». Der Erfolg von Open Source mag die Vertreiber von SugarCRM und Socialtext dazu bewogen haben, ihre CRM Lösungen als Open Source Software zu bezeichnen, obwohl die dazugehörigen Lizenzen SugarCRM Public License und Socialtext Public License bisher nicht von der OSI in die Liste der «approved licenses» aufgenommen wurden und die Lizenzinhalte keine Open Source Lizenzen iSd OSI sind.³⁴

Aus diesem Verhalten ergeben sich eine Reihe von Fragen für den markenrechtlichen Umgang mit der Wortmarke «Open Source». Es gilt – unter dem Gesichtspunkt, dass «Open Source» mittlerweile eine Gattungsbezeichnung darstellt und daher aus den Gründen des § 4 Abs. 1 Z 5 MSchG nicht eintragungsfähig ist – zu klären, welche Rechtswahrnehmung der Markeninhaber von «Open Source» gegenüber anderen hat. Der OGH hat dazu festgestellt³⁵ , dass es ausreiche, «dass das Wort in den beteiligten Verkehrskreisen als Gattungsbegriff zur Bezeichnung von Waren allgemein verwendet wird. Handle es sich dabei um seltene Waren oder hochspezialisierte Dienstleistungen, an denen nur ein sehr kleiner Abnehmerkreis interessiert sei, komme es eben nur auf die Auffassung dieses kleinen und fachlich gebildeten Personenkreises an. » Open Source Dienstleistungen sind schon lange nicht mehr hochspezialisiert, weswegen diese erweiterte Qualifikation nicht einmal zur Bewertung des Begriffs «Open Source» als Gattungsbezeichnung herangezogen werden muss. Außerdem besteht das Problem, dass Firmen, die Computerprogramme vertreiben, nicht sicher sein können, ob sie den Begriff «Open Source» für Ihre Produkte verwenden dürfen.

Betrachtet man das grundlegende Problem des Registrierungshindernisses der Marke «Open Source» als Gattungsbezeichnung, muss dennoch die Möglichkeit bestehen, die Bezeichnung gegenüber anderen Softwarevarianten³⁶ abzugrenzen. Eine freie Verwendung ist klar abzulehnen – eine Schallplatte kann nicht als CD bezeichnet werden – die Gattungsbezeichnung «Open Source» muss sich daher nach den Bestimmungen der OSD richten. Die OSI hat in der OSD den Begriff geprägt und – wie bereits erwähnt – jene Vorgaben festgelegt, die eingehalten werden müssen, um eine Software bzw. Lizenz als Open Source anzusehen. Dieses Ergebnis muss zwangsläufig Einfluss auf die Beantwortung des nächsten sich ergebenden Problems haben. Kann aufgrund des absoluten Freihaltebedürfnisses der Gattungsbezeichnung kein Markeninhaber gegen eine missbräuchliche Verwendung vorgehen, würde dies eine große Gefahr für den Begriff «Open Source» darstellen. Dieses Problem wird aber durch das Lauterkeitsrecht, mit seinem – wieWiebe richtig betont³⁷ – «primär kommunikationsregelnden Charakter » gelöst. Das Lauterkeitsrecht sichert über die Generalklausel des § 1 UWG auch dort den Schutz vor Ausbeutung fremder Leistung, wo ein immaterialgüterrechtlicher Schutz – wie in diesem Fall durch das Markenrecht – nicht vorhanden ist³⁸ . Anbieter von «Nicht-Open Source Software» können daher aufgefordert werden, den missbräuchlichen Nutzen des Begriffs «Open Source» einzustellen, da ihr Produkt nicht den Anforderungen des Gattungsbegriffs entspricht.

Die Vielzahl an genutzten Open Source Lizenzen ist, wie erwähnt, eine der größten Herausforderungen. Anfragen aus der Praxis, wie bspw «Wir bauen gerade das gesamte Source Paket mit Code + Libraries wie in der GPL vorgesehen zusammen. Damit wir das Projekt kompilieren können, müssen wir auch die proprietären Libs, sowie Nicht-GPL lizenzierte Teile mit in dem Paket ausliefern. Wie schaut das rechtlich aus? », führen lediglich dazu, dass einzelne Rechtsmeinungen abgegeben werden können, ohne dass es hier eine fundierte Basis aus hM bzw. hL oder Rsp gibt. Die Open Source Lizenzen selbst gehen nur zögerlich aktiv auf diese Problematik ein, lobend zu erwähnen ist in diesem Zusammenhang die EUPL, welche in ihrem Anhang fünf Open Source Lizenzen explizit als kompatibel anführt³⁹ . Die EUPL enthält dabei in Art. 5 eine «devote2 Klausel» gegenüber diesen Lizenzen, da sie bestimmt: «Sollten die Verpflichtungen des Lizenznehmers aus der kompatiblen Lizenz mit denjenigen aus der vorliegenden Lizenz (EUPL) in Konflikt stehen, werden die Verpflichtungen aus der kompatiblen Lizenz Vorrang haben. ». Diese Klausel mag für die Praxis zufrieden stellend gelöst worden sein, schwächt die EUPL aber, da im Falle einer Zusammenführung von verschieden lizenzierter Open Source Software die EUPL «verschwindet».

Für die Problematik der Kompatibilität allgemein wäre ein noch wenig von der Forschung beachteter Ansatz zu empfehlen, welcher eine Kompatibilitätsmatrix zum Ziel haben sollte. Dieser Matrix könnten Lizenzinteressenten dann einfach entnehmen, welche Arten von Lizenzzusammenschlüssen für sie rechtlich möglich sind. Dabei muss berücksichtig werden, dass ein Lizenzzusammenschluss sowohl aufwärts (upstream) als auch abwärts (downstream) erfolgen kann.⁴⁰ Generell muss bei der Einbindung von Quelltext, welcher unter einer (Open Source-)Lizenz lizenziert ist in einen Quelltext, welcher unter einer anderen (Open Source) Lizenz steht die Frage geklärt werden in welcher Art und Weise dies rechtlich möglich ist. Der Unterschied zwischen der Aufwärtskompatibilität und der Abwärtskompatibilität besteht in der unterschiedlichen Sichtweise. In beiden Fällen gibt es eine Ursprungs- und eine Weiterentwicklungslizenz und bei beiden Fällen wird die rechtliche Wertung aus der Sichtweise der Ursprungslizenz vorgenommen. Zum näheren Verständnis wird dieser Vorgang an Hand eines Beispiels erläutert: Gehen wir einmal davon aus, dass wir zwei Quelltexte haben, welcher unter den unterschiedlichen Open Source Lizenzen A und B stehen. Bei der Aufwärtskompatibilität wird beurteilt, inwiefern die Einbindung von Quelltext, welcher unter der Open Source Lizenz A lizenziert ist (in dem Fall die Ursprungslizenz), in Quelltext, welcher unter der Open Source Lizenz B geschützt ist (in dem Fall die Weiterentwicklungslizenz), rechtlich möglich ist. Bei der Abwärtskompatibilität dreht sich diese Sichtweise um. Hier wird überprüft, inwiefern Quelltext, welcher unter der Open Source Lizenz B lizenziert ist (B wird in diesem Fall zur Ursprungslizenz) in Quelltext, welcher unter der Open Source Lizenz A lizenziert, rechtlich möglich ist. Siehe zur Vereinfachung auch folgende Abbildung:

Um die Vielzahl an Lizenzen rechtlich bewerten zu können, kann die Klassifizierung des IFROSS⁴¹ zur Vereinfachung herangezogen werden. Dabei kann die Aufwärts- bzw. Abwärtskompatibilität auf die jeweiligen Lizenzklassen angewendet werden, wobei im Einzelfall noch genauer geprüft werden muss, ob die Kompatibilität in der Praxis rechtlich Bestand haben wird. Diese Lösung erscheint aber aus rechtspolitischer Sicht alternativlos, da ansonsten die Gefahr droht, das Kompatiblilitätsfragen im Streitfall analog wie bei «Battle of Forms» gelöst werden⁴² . In diesem Fall würden beide Lizenzen nur teilweise überbleiben, was keine befriedigende Lösung für Open Source Lizenzen insgesamt sein kann.

Open Source ist aus seinem Nischendasein herausgekommen, wie die bisher gemachten Ausführungen wohl beweisen, dennoch besitzt Open Source nicht genügend Trennschärfe, um sich gegenüber ähnlichen Philosophien abseits der IT abgrenzen zu können. Als Beispiel mögen das eingangs erwähnte Open Design oder aber auch die Bestrebungen der Creative Commons oder Open Access Bewegung dienen. Während die Creative Commons der Philosphie von Open Source noch sehr nahe steht - Lizenzform soll als Schutzinstrument für Inhalte eingesetzt werden, die kein Quelltext sind (Texte, Aufsätze, etc) - hat Open Access außer dem «Open» sehr wenig mit Open Source zu tun. Bei Open Access geht es um den kostenlosen Zugang zu wissenschaftlichen Texten⁴³ , welche hinsichtlich des Urheberrechts fordert, das «die einzige Einschränkung darin bestehen sollte, den jeweiligen Autorinnen und Autoren Kontrolle über ihre Arbeit zu belassen und deren Recht zu sichern, dass ihre Arbeit angemessen anerkannt und zitiert wird. »⁴⁴ Dieser Ansatz unterscheidet sich wesentlich von den Open Source Bestrebungen, führt aber auf Grund der Ähnlichkeit der Bezeichnung zu einer Verwässerung des Begriffs Open Source, da eine große Anzahl an Menschen hier jeweils zuwenig Hintergundwissen hat, um sinnvoll unterscheiden zu können.

Befragt man Vertreter aus der Praxis so weisen diese darauf hin, dass die meisten Diskussionen über Open Source Lizenzen betonen, was alles «nicht gehe». Dieser Hinweis verwundert umso mehr, wenn man bedenkt, dass Open Source Lizenzen zumindest die gleichen, wenn nicht mehr Freiheiten bieten als ihre proprietären Konkurrenten. Ebenso häufig hört man, dass die Offenheit des Quelltextes zu großen Sicherheitslücken führe. Diese Diskussion soll an dieser Stelle nicht geführt werden, die Kritik zeigt aber, dass hier noch viel Arbeit auf die Open Source Community und ihre Vertreter wartet, diese Mängel zu beseitigen, um größere Akzeptanz zu erlangen.

In einer Zeit, in der Datensicherheit, Datenschutz und (Vorrats-)Datenspeicherung zentrale Themen darstellen, erscheint es als Ironie, dass die «Datenkrake» Facebook selbst behauptet, dass man ohne Open Source Software keine Aussicht auf Erfolg gehabt hätte.⁴⁵ Diese Tatsache zeigt auch, dass Open Source nur einem bestimmten Nutzerkreis vorbehalten ist. Erstaunlich war das Verhalten von Microsoft, als bekannt wurde, dass eine Software für Windows 7 Quelltext enthielt, der unter der GPL 2 lizenziert war. Da die Software insgesamt aber proprietär vertrieben wurde, verstieß dies gegen den Copylefteffekt der GPL. Microsoft reagierte und – anstelle den GPL-lizenzierten Quelltext durch proprietären zu ersetzen – stellte den Quelltext der ganzen Software unter die GPL⁴⁶ . Open Source Software hat sich also etabliert und erfährt mittlerweile selbst von ehemaligen «Feinden» zumindest Respekt. Diese gewonnene Anerkennung kann dazu genutzt werden, Open Source und die dahinter stehende Philosophie einem immer breiteren Publikum zuzuführen und diesem zu zeigen, das Open Source Urheberrecht nicht nur ernst nimmt, sondern auch dazu beitragen kann, den Umgang mit diesem sinnvoll und eigenverantwortlich zu steuern. Dieser Beitrag darf keinesfalls als unwesentlich bewertet werden, da der Umgang mit Urhebern und ihren Rechten eine zentrale Rolle in der momentanen Gesellschaft spielt, was einerseits die mediale Aufmerksamkeit rund um das Google-Book-Stettlement-Agreement⁴⁷ zeigt, andererseits auch die erwähnten Bestrebungen abseits der eigentlichen Open Source Bewegung. Ein Beitrag zu einer sachlich geführten Diskussion kann allemal erwartet werden.

Auer-Reinsdorff , Escrow-Lizenzen und Open Source, Der IT-Rechtsberater 3/09, 69.
Bastien/Laurent , Report on Study of the compatibility mechanism of the EUPL.http://ec.europa.eu/idabc/servlets/Doc?id=27472 aufgerufen 8.1.2010 (2003).
Erenli , Die rechtliche Relevanz von Open Source Lizenzen unter besonderer Berücksichtigung praktischer Problemstellungen 170 ff. (Publikation ausstehend).
Heidinger/Wiebe , European Union Public License – EUPL V1.1
www.wkw.at/docextern/ubit/EUPL _Broschuere09.pdf abgerufen am 8.1.2010 (2009).
Heidinger/Wiebe , GPL 3.0 und EUPL – Aktuelle Entwicklungen im Bereich der Open Source Lizenzen MR 05/06, 262.
Kucsko, Geistiges Eigentum 2003.
Schoditsch , Die Kollision von AGB bei der Eigentumsvorbehalts-Vereinbarung, ÖJZ 2009, 53.
Stallman Richard, Free Software, Free Society: Selected Essays of Richard M Stallman., 2nd ed.http://shop.fsf.org/product/free-software-free-society aufgerufen 8.1.2010 (Boston: GNU Press, 2004).
Wiebe , Umsetzung der Geschäftspraktikenrichtlinie und Perspektiven für eine UWG-Reform, JBl 2007, 69.

---

Kai Erenli, Fachbereichsleiter Rechtslehre, FH des bfie Wien, Studiengang «Projektmanagement und Informationstechnik»
Wohlmuthstr. 22, 1020 Wien AT
kai.erenli@fh-vie.ac.at;http://www.fh-vie.ac.at