S. 702. Open-Source-Software in der Praxis

2.1. Die praktische Bedeutung von Open-Source-Software

233

Das Kapitel rund um das Thema „Open Source“ soll mit ein paar Gedankenspielen eingeleitet werden: Stellen Sie sich vor, Sie sind Vorstand einer Fluglinie. Eines Tages kommt es zur Katastrophe, ein Flugzeug Ihrer Fluglinie stürzt ab. Ein Gutachten ergibt, dass der Flugzeugabsturz auf eine fehlerhafte (embedded) Software zurückzuführen ist. Bei dieser Software handelt es sich um eine Open-Source-Software-Komponente. Wer haftet? Sie sind Sales-Mitarbeiter eines Industrieunternehmens und haben eine CRM-Software (Customer Relationship System) im Einsatz. Bei dieser Software handelt es sich um eine Open-Source-Software. Die Software lässt sich eines Tages nicht mehr öffnen. An wen wenden Sie sich? Sie sind Händler von elektronischer Hardware. Aus heiterem Himmel wird Ihnen eine Unterlassungserklärung zugestellt. Sie dürfen die Hardware nicht mehr vertreiben, da Sie gegen Open-Source-Lizenzen verstoßen. Wie sollen Sie sich verhalten? Diese Anwendungsfälle haben einen gemeinsamen Nenner: Wie ist mit Open-Source-Software umzugehen?

234

Software wird heute in wesentlichen Teilen auf Grundlage von Fremdkomponenten entwickelt. Schätzungen zufolge besteht proprietäre Standard- und Individualsoftware aus bis zu 98 % Fremdkomponenten. Beim Einsatz der Fremdkomponenten spielt der Einsatz von Open-Source-Software eine entscheidende Rolle.

235

Der Einsatz von Open-Source-Software etabliert sich zunehmend in der Softwarebranche. Mit der Digitalisierung des Alltags nimmt der Einsatz von Open-Source-Software zusätzlich zu. Nach Erhebungen des Scantool-Anbieters „Synopsys“ basieren durchschnittlich über 57 % einer Codebasis auf Open-Source-Software. Über 84 % der Unternehmen geben an, dass Open-Source-Software in wichtigen bzw unternehmenskritischen Bereichen eingesetzt wird. Das zeigt deutlich, dass die Open-Source-Bewegung unaufhaltsam ins Rollen gekommen ist und mittelfristig die Softwarebranche massiv beeinflussen wird. Eindrucksvoll bringt dies die Studie „The State of Enterprise on Open Source 2020” des Unternehmens „Red Hat“ zum Ausdruck. Demnach sinkt die Bedeutung von proprietärer Software signifikant. Waren im Jahr 2019 noch 55 % der genutzten Software in den befragten Unternehmen proprietär, sank dieser Wert im Jahr 2020 in den befragten Unternehmen auf 42 %. Der Anteil an Open-Source-Software stieg hingegen in diesem Zeitraum von 36 % auf 44 %. Studien zeigen weiters, dass Investitionen in Open-Source-Software einen positiven wirtschaftlichen Effekt haben.

S. 71

236

Das Hauptargument für die Nutzung von Open-Source-Software ist vor allem die Kostenersparnis bei der Anschaffung und Instandhaltung der Programme. Open Source wird als Möglichkeit gesehen, Softwarelösungen, Wissen und Expertise zu teilen. Dies wiederum kann zu einer Kostenreduktion und Bereicherung der Gesellschaft beitragen. Die Europäische Union sieht den Einsatz von Open-Source-Software aus diesen Gründen als äußerst positiv. Die Europäische Union sieht Open-Source-Software weiters als wesentlichen Beitrag zur Erreichung einer digitalen Souveränität. Gerade im Bereich der öffentlichen Verwaltung werden vielfältige Einsatzmöglichkeiten diagnostiziert. Konkret nahm die Kommission am 21.10.2020 eine neue Strategie für Open-Source-Software an, mit der die Verwendung quelloffener Software gefördert wird. Am 8.12.2021 wurde der Beschluss der Kommission über die Open-Source-Lizenzierung und die Weiterverwendung von Software der Kommission verlautbart. 2022 wurden die Mittel für Open Source in Deutschland und Europa um 37,5 Mio auf insgesamt 51 Mio € aufgestockt.

237

Teilweise besteht der Glaube, dass Open-Source-Software keine entgeltliche Verwertung zulässt. Dabei handelt es sich um einen Irrglauben. Richtig ist hingegen, dass Open-Source-Lizenzen keine Lizenzgebühren gestatten. Um es mit den Worten von Stallman zu fassen: „Think free as in free speech, not free beer“. Der Quellcode ist per se unentgeltlich erhältlich. Das heißt aber ausdrücklich nicht, dass Open-Source-Software nicht kommerziell genutzt werden darf. Stallman hat immer wieder betont, dass es nicht darum gehe, kostenlose Software zu entwickeln. Ein unmittelbarer Gewinn kann etwa mit Wartung, Pflege, Support und Dokumentation der Programme erzielt werden. Tatsächlich haben sich bereits verschiedene Geschäftsmodelle etabliert, um an Open-Source-Software unmittelbar oder mittelbar wirtschaftlich zu partizipieren. Für die damit verbundenen Dienstleistungen darf ein Entgelt verlangt werden.

238

„FLOSS“ hat sich als Entwicklungs- und Vertriebsmodell für Software durchaus etabliert. Die Abkürzung bedeutet „Free/Libre/Open-Source-Software“ und geht auf Ghosh zurück. So hat sich ein Dienstleistungsmarkt gebildet, auf dem Training, Pflege, Beratungsleistungen zu Open-Source-Software angeboten werden. Insbesondere die Wartung von komplexen Open-Source-Programmen ist ein wichtiges Geschäftsfeld. In der Praxis sind Unternehmen oft nur dann bereit, Open-Source-Software zu implementieren, wenn eine entsprechende Wartung sichergestellt ist. Wie alle Wirtschaftsprodukte, hat Software eine begrenzte Lebensdauer. Ohne Updates und Wartung ist sie schnell veraltet. Im Falle eines Problems mit der Software wünscht man sich einen kompetenten Ansprechpartner, der Bugs etc binnen fix definierten Zeiten (Service-Levels) löst. All dies entfällt grundsätzlich bei Open-Source-Software und sollte im Bereich der S. 72Open Source Compliance mitbedacht werden. Es gibt keine Garantie dafür, dass die Software auch in zwei, drei Jahren „dem Stand der Technik“ Genüge tut. Allerdings existieren Unternehmen, die sich auf den Support von Open-Source-Produkten spezialisiert haben. Mit diesen können (entgeltliche) Verträge zum Zwecke der Wartung abgeschlossen werden.

239

Eine weitere, bereits etablierte, wirtschaftliche Tätigkeit auf dem Gebiet der Open-Source-Software ist jene der Distribution. Diese Distributoren bieten den Mehrwert, Open-Source-Software professionell zu vertreiben, indem Installationsroutinen, Support, Qualitätssicherung, Dokumentation oder Weiterentwicklungen erbracht werden. Das wohl prominenteste diesbezügliche Beispiel ist das Unternehmen Red Hat, welches 2018 für kolportierte 34 Milliarden US-Dollar von „Big Blue“ IBM erworben wurde.

240

Möglich ist außerdem die sogenannte „Mehrfachlizenzierung“, bei der einem Anwender mehrere Softwarelizenzen zur Auswahl stehen. So kann ein Programm zum Beispiel wahlweise unter einer Open-Source-Lizenz wie der GPL oder unter einer proprietären Lizenz lizenziert werden. Es wird den Softwareentwicklern so beispielsweise ermöglicht, eine Basisversion der Software ohne besondere Extras und gleichzeitig eine Version mit weiteren Leistungen (etwa zusätzliche Programmkomponenten oder eine Servicehotline) anzubieten. Ein derartiges Szenario wird auch duales Lizenzsystem genannt.

241

Den Rechteinhabern an Open-Source-Software steht mit der Vertriebsmethode des Dual Licensing eine Option zur Verfügung. Dabei wird ein und dieselbe Software unter einer oder mehreren verschiedenen Open-Source-Lizenzen angeboten. Die Vorteile des Dual Licensing sind strategischer Natur, da sich die Open-Source-Software einerseits aufgrund ihrer Lizenzgebührenfreiheit leichter verbreitet und einen Softwarestandard am Markt etablieren kann. Auf der anderen Seite können die fehlenden Einnahmen aus der OSS-Lizenzierung aufgefangen werden, indem zum Beispiel Nutzer der Open-Source-Software als Kunden für proprietäre und damit gebührenpflichtige Lizenzen derselben Software gewonnen werden können. Die Hintergründe für einen solchen Wechsel von einer Open-Source-Software auf eine proprietäre Lizenz können dabei vielfältig sein. Eine Idee wäre beispielsweise, die Software unter einer Open-Source-Copyleft-Lizenz zu vertreiben. Gegebenenfalls werden Kunden auf eine proprietäre Lizenz derselben Software optieren, wenn sie die Software in eine bestehende Software implementieren möchten. Dual Licensing kann sich auch im Bereich der Forschung und Entwicklung anbieten. Durch die Bereitstellung der Open-Source-Variante kann die Fehlersuche vorangetrieben werden. Bei dieser Gelegenheit können Unternehmen Mitarbeiter anwerben. Dabei besteht für den Anbieter eines Dual Licensing aber stets die Gefahr, dass sich Abnehmer einer solchen Software mit einer abgeleiteten Version selbst als Lizenzgeber am Markt profilieren. Deshalb ist dem Anbieter in diesem Fall anzuraten, S. 73neben dem Einsatz von starken Copyleft-Lizenzen zugleich in einem Projektvertrag die kommerzielle Nutzung der Software-Komponenten zu verbieten.

242

Auch im Bereich „Embedded Software“ spielt Open-Source-Software bereits eine große Rolle – hier insbesondere in der Automobilindustrie. Schließlich setzt auch die kommerzielle Softwareindustrie zunehmend auf Open-Source-Software. Mehr und mehr werden sogenannte Bibliothek-Dateien, welche auf Open-Source-Basis programmiert wurden, in proprietäre Software integriert. Insbesondere in diesem Zusammenhang ist auf die „Gefahr“ des „Copyleft-Effektes“ hinzuweisen.

243

Taylor Armerding, Blogger des Forbes-Magazines, formuliert die Zukunft von Open-Source-Software folgendermaßen: „But when it comes to the future of Open-Source-Software, given the trend lines of the past few years, it seems pretty safe to say that a single word – more – will be present in just about everything …“. Dieser Eindruck wird dadurch bestätigt, dass große Anbieter von proprietärer Software, wie insbesondere Microsoft – nach dem Motto: „Angriff ist die beste Verteidigung“ – ganz intensiv in Open-Source-Projekte investieren. Das zeigt deutlich, dass die Open-Source-Bewegung unaufhaltsam ins Rollen gekommen ist und mittelfristig die Softwarebranche massiv beeinflussen wird. Ein Grund, warum auf Open-Source-Bibliotheken zurückgegriffen wird, ist freilich auch, dass das erforderliche Personal nicht zur Verfügung steht, um eine eigene, proprietäre Software zu entwickeln.

244

Als einer der wichtigsten Vorteile der Verwendung von Open-Source-Software wird oft die bessere Überprüfbarkeit der Software auf Sicherheitslücken genannt, da der Quellcode offenliegt. Open-Source-Software ist per Definition dadurch charakterisiert, dass der Quellcode der Öffentlichkeit zur Verfügung steht. Gleichzeitig stellt eben dies aber auch ein Sicherheitsrisiko dar. In der Regel gibt es auch keine Prozesse (wie etwa Programmier-Richtlinie), welche ein „Secure Coding“ oder eine Programmierung im Sinne von Privacy by Design sicherstellen. Daraus resultieren naturgemäß Sicherheitslücken. So hat etwa die Sicherheitslücke „Heartbleed“ organisatorische Mängel in einigen Open-Source-Projekten offengelegt. Durch die Offenlegung des Quellcodes können Dritte in die Lage versetzt werden, am Code und somit an der Software Veränderungen vorzunehmen oder den offenen Quellcode in eigene Software einzufügen und diese wiederum zu vertreiben, soweit dies die lizenzrechtlichen Bestimmungen zulassen. Fehlerhafte Programmierungen können durch die Offenlegung des Quellcodes einen hohen Verbreitungsgrad erreichen, was wiederum zu erheblichen Gefahren führen kann. Zu berücksichtigen ist dabei auch, dass die Transparenz des Quellcodes erheblich zur Auffindung (aber auch Behebung!) von Bugs beitragen kann. Durch den transparenten Quellcode wird die eigenständige, auch von mehreren unabhängigen Entwicklern durchgeführte Durchforstung der Software auf mögliche Hintertüren, Viren und Ähnliches ermöglicht. Richtig ist, dass die Wahrscheinlichkeit der Entdeckungen von Fehlern durch die Beteiligung zahlreicher externer Programmierer erhöht wird. AndeS. 74rerseits ist aber unklar, inwieweit dieser Vorteil mit dem gleichzeitigen Nachteil erkauft wird, dass durch die Offenlegung auch neue Missbrauchsmöglichkeiten durch Tools, die auf dem offengelegten Code aufbauen, erleichtert werden.

245

Ob im Vergleich mit proprietärer Software insgesamt im Hinblick auf mehr Sicherheit tatsächlich Open-Source-Software vorteilhafter ist, erscheint bislang noch ungeklärt. Die Annahme, die Veröffentlichung des Quellcodes trage per se zur Verbesserung der IT-Sicherheit bei, begegnet jedenfalls für den staatlichen Bereich durchgreifendem Zweifel, da nicht unterstellt werden kann, dass ein Dritter, der Kenntnis von einer Schwachstelle erlangt, die Behörde hierüber unterrichtet und sie nicht ausnutzt oder sein Wissen über sie weiterverkauft.

2.2. Die Charakteristika von Open-Source-Software, Ursprünge und Ausblick

246

Die erste grundlegende Definition von Open-Source-Software geht auf die Free Software Foundation Ende der 1990er Jahre zurück. Diese betont: „Free software is a matter of the users‘ freedom to run, copy, distribute, study, change and improve the software.“ Weiters hat die Open-Source-Initiative eine „Open-Source-Definition“ entwickelt. Demnach reicht es nicht aus, wenn der Sourcecode zugänglich gemacht wird, sondern es muss ohne Einschränkung jedermann lizenzgebührenfrei die Weiterentwicklung und der Vertrieb bearbeiteter oder unbearbeiteter Softwareversion gestattet werden.

247

Open-Source-Software kann am besten dadurch beschrieben werden, dass man sie von ihrem „Spiegelbild“, der proprietären Software, unterscheidet. Im Wesentlichen hat eine proprietäre Software folgende charakterisierende Eigenschaften:

• Der Quellcode ist privat und steht der Öffentlichkeit nicht zur Verfügung.

• Die Weiterverbreitung der Software ist grundsätzlich verboten.

• Die Nutzung der Software kann inhaltlich, zeitlich, territorial und personell beschränkt werden.

248

Spiegelbildlich dazu weist Open-Source-Software folgende Eigenschaften auf:

• Der Quellcode steht der Öffentlichkeit unverschlüsselt zur Verfügung.

• Die Weiterverarbeitung und Verbreitung der Software ist zulässig (und gewünscht).

• Eine Beschränkung der Nutzung ist verboten.

Open-Source-Software bildet somit einen Gegenpol zur klassischen proprietären Software. Der Unterschied liegt insbesondere auch darin, dass Open Source Code von vornherein mit dem Ziel der späteren Veröffentlichung programmiert wird. Hauptunterscheidungskriterien der lizenzrechtlichen Erscheinungsform von Open-Source-Software gegenüber traditioneller, proprietärer Softwarevertriebssysteme sind, dass dem Lizenznehmer der Quellcode zur Verfügung steht und an diesem Code umfangreiche S. 75Vervielfältigungs-, Bearbeitungs- und Verbreitungsrechte eingeräumt werden. Darüber hinaus ist keine Lizenzgebühr für die Rechtseinräumung durch den Lizenznehmer zu entrichten. Im Gegensatz dazu wird bei der Freeware und Shareware der Quellcode jeweils nicht veröffentlicht. Der Begriff der Open-Source-Software ist damit von jenem der Free Software strikt zu trennen.

249

Open-Source-Lizenzverträge müssen – neben weiteren Eigenschaften – insbesondere die folgenden drei Merkmale aufweisen:

• Free Redistribution: Die Software darf beliebig kopiert, verbreitet und genutzt werden.

• Source Code: Der Quelltext der Software liegt in einer für den Menschen lesbaren und verständlichen Form vor.

• Derived Works: Die Software darf verändert und in der veränderten Form weitergegeben werden.

Von der Entwicklung her unterscheiden sich der proprietäre und Open-Source-Ansatz dadurch, dass bei Open-Source-Software oft sehr viel mehr Entwickler beteiligt sind, diese jedoch in vielen Fällen keine organisatorische, wirtschaftliche oder persönliche Beziehung verbindet.

250

Die Anfänge der Open-Source-Bewegung liegen in den späten 1960er Jahren und sind untrennbar mit dem Betriebssystem Unix verknüpft. Dessen Nachfolger, das Betriebssystem „Linux“, ist heute allgegenwärtig. Betriebssysteme wie Android oder Chrome OS setzen auf „Linux“ auf. Es wird von über 15.000 Programmierern und 1.400 Unternehmen in einem kooperativen Modell weiterentwickelt.

251

Will man „Gründer“ der Open-Source-Bewegung benennen, so sind der Finne Linus Torvalds und der bereits erwähnte Amerikaner Richard Stallman anzuführen. Stallman gründete im Jahr 1985 als Mitarbeiter des Massachusetts Institute of Technology (MIT) in Boston die Free Software Foundation mit dem Ziel, eine für jedermann frei zugängliche Alternative zum kommerziellen Betriebssystem Unix zu entwickeln. In diesem Zusammenhang formulierte er die Grundregeln der Philosophie von Open-Source-Software, aus denen sich die bekannteste Open-Source-Lizenz, die GPL, entwickelte. Wesentliche Merkmale der GPL sind die Pflichten, die Software nur unentgeltlich zu den Bedingungen der GPL weiterzugeben. Als organisatorische und politische Basis wurde eben diese Free Software Foundation implementiert. Als weitere internationale Institutionen der Open Source Community sind zu nennen: die Open Source Initiative, die Apache Software Foundation, die Eclipse Foundation, die Linux Foundation, die Software Freedom Conservancy oder bspw die Open Source Automation Development Lab.

S. 762.3. Open-Source-Software und Recht

252

Mit zunehmender Popularität von Open-Source-Software treten auch damit verbundene rechtliche Fragestellungen in das Rampenlicht. Keinesfalls darf aus der Philosophie von Open Source gefolgert werden, dass die Lizenznehmer in der Einhaltung der Lizenzbedingungen willkürlich verfahren dürfen. Obwohl die Anzahl streitiger Verfahren zu Open-Source-Software noch überschaubar ist, haben die Gerichte bislang immer wieder entsprechende Lizenzverstöße anerkannt. Eine zusätzliche Schwierigkeit im Zusammenhang mit Open-Source-Lizenzen ergibt sich aus dem Umstand, dass diese aus dem nordamerikanischen Rechtsraum stammen und daher regelmäßig Probleme bei der Auslegung im Lichte der nationalen Rechtsordnung vorliegen.

253

Der Aspekt der Open Source Compliance wird in der Praxis auch im Rahmen von Due-Diligence-Prüfungen bei Unternehmenskäufern relevant. Open-Source-Verfehlungen können dabei den Kaufpreis erheblich negativ beeinflussen. Für den Wert des Unternehmens kann es einen erheblichen Unterschied machen, ob die dort verwendete Open-Source-Software rechtskonform eingesetzt wird oder ob diesbezügliche rechtliche Risiken bestehen. Auch kann ein Open-Source-Lizenzverstoß einen gewährleistungsrechtlich relevanten Rechtsmangel begründen.

254

Lange Zeit war der rechtliche „Gehalt“ von Open-Source-Lizenzen fraglich. Wie können diese sehr amerikanischen Vertragsschablonen mit dem europäischen Rechtsverständnis in Einklang gebracht werden? Wegbereitend war eine Entscheidung aus dem Jahr 2004. In diesem Verfahren hatte der deutsche Programmierer Harald Welte gegen den Hardwareanbieter Sitecom Unterlassungsansprüche geltend gemacht. Welte ist generell als treibende Kraft vieler gerichtlichen Auseinandersetzungen im Bereich Open Source zu nennen. Er ist Miturheber und -entwickler des Linuxkernel und betreibt eine zentrale Informations- und Community-Website, auf welcher zahlreiche Fälle von GPL-Verstößen dokumentiert werden. Der Vorwurf lautete, dass Sitecom Firmware vertreibe, ohne dabei die Lizenzpflichten aus der GNU General Public License (GPL) einzuhalten. Die Rechtssache landete vor dem Landesgericht München. Die Entscheidung des Gerichtes war bahnbrechend: Dieses bestätigte das Unterlassungsbegehren. Dies deshalb, weil ein Verstoß gegen Open-Source-Lizenzen eine Urheberrechtsverletzung begründet. Die Lizenzbedingungen der GNU GPL halten einer Prüfung am Maßstab deutschen Rechts zumindest dahingehend stand, als sie für den Fall der Lizenzverletzung den Rückfall der Nutzungsrechte an den Urheber vorsehen. Werden die Bedingungen von Open-Source-Lizenzbedingungen missachtet und damit der erlaubte Nutzungsumfang überschritten, liegt darin eine Urheberrechtsverletzung. Wird gegen die S. 77Pflichten verstoßen, fallen die Nutzungsrechte automatisch ex nunc weg und der Lizenznehmer begeht eine Urheberrechtsverletzung, wenn er die Software entgegen den Lizenzbedingungen vertreibt. Damit wurde klargestellt, dass Open-Source-Lizenzen einen (beachtlichen) rechtlichen Gehalt haben. Diese gerichtliche Durchsetzbarkeit der GPL-Lizenzbedingungen, trotz unwirksamer Gestaltung der AGB (etwa gänzliche Ausschlüsse bei Mängeln und Haftung) und trotz unklaren Vertragstyps, kann tatsächlich als ein „kleines Wunder“ bezeichnet werden.

255

Diese Ansicht wurde in der Folge mehrfach durch Gerichte bestätigt. Beispielsweise hat das LG Bochum die Möglichkeit eines Schadenersatzanspruches bei einer Verletzung von Open-Source-Lizenzen festgestellt. Mit dieser Entscheidung hat das Gericht die Durchsetzung der Entwicklungsrechte gestärkt. Ein Verstoß gegen die GPL stellt demnach eine Urheberrechtsverletzung dar, die nicht nur zu einem Unterlassungsanspruch und Verlust der Lizenzrechte führt, sondern auch einen Schadenersatzanspruch zugunsten der Softwareentwickler auslösen kann. Trotz kostenfreier Bereitstellung der Software soll die Schadensberechnung dabei nach der Lizenzanalogie grundsätzlich möglich sein.

256

Praktisch hoch relevant sind auch die Erkenntnisse aus der Entscheidung OLG Karlsruhe. Ein Software-Entwickler hatte eine Wordpress-Plug-in, ein sogenanntes Theme, entwickelt. In dieser Sache ging es darum, ob ein Dritter verlangen könne, dass der Programmierer eines WordPress-Themes zur Veröffentlichung dessen Quellcodes verpflichtet werden kann. Dazu ist zu sagen, dass das Content-Management-System „WordPress“ unter der Open-Source-Lizenz GNU General Public License Version 2.0. lizenziert ist. Der Beklagte war der Auffassung, dass kommerzielle Plug-Ins grundsätzlich die GPL verletzen würden und daher von jedermann kostenlos genutzt werden dürfen. Er drohte damit, die Software auf GitHub hochzuladen. Der Software-Entwickler beantragte eine einstweilige Verfügung mit dem Ziel, diese Veröffentlichung zu unterbinden. Das Gericht kam zu dem Ergebnis, dass der Software-Entwickler selbst dann seine Verwertungsrechte behält, wenn er gegen die GPL verstoßen würde, worauf es jedoch in diesem Fall nicht mehr ankam. Es unterscheidet dabei zwischen den vertraglichen Obliegenheiten, das abgeleitete Werk unter die GPL zu stellen einerseits und der urheberrechtlichen Position des Bearbeiters andererseits. Aus der bloßen Übernahme einer vertraglichen Obliegenheit zur Veröffentlichung kann nicht der Wille entnommen werden, auf seine durch Modifikationen erworbene Rechtsposition vollständig zu verzichten. Die GPL 2.0. erstreckt sich somit nicht automatisch auf abgeleitete Werke, sondern bedarf der Zustimmung des Bearbeiters des abgeleiteten Werkes. Ein Dritter kann eine solche Zustimmung nicht verlangen. Dieser Dritte hat damit keine Veröffentlichungs- oder Verwertungsrechte an abgeleiteten Werken im Sinne der GPL 2.0. Es gebe gerade keinen Automatismus, der bei einer Infektion dazu führen würde, dass eigene Urheberrechte verloren gehen oder automatisch an Dritte eingeräumt werden. Eine etwaige Verpflichtung des Bearbeiters gegenüber den Urhebern des Originalprogramms S. 78würde Dritten keine Veröffentlichungs- oder Verwertungsrechte an der Bearbeitung bzw dem gemeinsamen Werk verschaffen. Im Ergebnis verneinte das Gericht einen Anspruch eines Dritten darauf, die abgeleiteten Werke unter die GPL 2.0. zu stellen. Es ist daher an den Open-Source-Lizenzgebern – repräsentiert durch die Free Software Foundation – gelegen, die vertraglichen Verpflichtungen aus der jeweiligen Open-Source-Lizenz durchzusetzen.

257

Auch die Entscheidung „Fantec II“ sorgte für Aufsehen. Das LG Hamburg äußerte sich darin zu den konkreten Umsetzungspflichten von Open-Source-Lizenzen. Überraschend daran war der strenge Auslegungsansatz der Open-Source-Lizenzbedingungen. Weiterhin gelten jedoch die gesetzlichen Unklarheitenregeln, wonach Auslegungszweifel zu Lasten des Verwenders der AGB gehen.

258

Open Source Compliance hat freilich nicht bloß ausschließlich deutsche Gerichte beschäftigt. In der Rechtssache Artifex Software gegen Hancom wurde beispielsweise im Jahr 2017 ein Unterlassungsvergleich vor dem US District Court N.D. of California geschlossen. Im Verfahren BusyBox gegen Westinghouse ging es bereits im Jahr 2010 um die erste Rechtsdurchsetzung der GPL-2.0. in einem gerichtlichen Verfahren vor dem United States District Court, der zu einer Verurteilung der Beklagten zu Schadenersatz nach dem U.S. Copyright Act wegen Nichteinhaltung der Lizenzbedingungen führte.

259

Ein weiteres Verfahren wurde vor dem französischem Cour d’appel de Paris in der Rechtssache AFPA gegen Edu4 ausgetragen. Neben der Bestätigung der Wirksamkeit der Open-Source-Lizenzbedingungen im Verhältnis zwischen Unternehmen hat die Entscheidung Gewicht, als sie einen direkten Anspruch auf Herausgabe des Source Codes und weiterer Informationen ausurteilte. Der Anspruch wurde dem Erwerber einer unter GPL lizenzierten Software gegen den Distributor der Software zugesprochen.

260

Dabei ist jedoch anzumerken, dass die allermeisten Rechtsstreitigkeiten rund um Open-Source-Lizenzen nicht vor Gerichten ausgestritten werden. Dies ist dadurch begründet, dass die Rechtsunsicherheiten nach wie vor hoch sind. Die weit überwiegende Zahl von Open-Source-Konflikten wird mit außergerichtlichen Unterlassungserklärungen beendet. Auch „Massenabmahnwellen“ der Open-Source-Entwickler wurden bislang nicht losgebrochen, sind aber in Anbetracht des doch weiten Einsatzes künftig nicht mehr per se ausgeschlossen. Dabei ist darauf hinzuweisen, dass das größte rechtliche Verfolgungsrisiko nicht von den Rechtsinhabern ausgeht, sondern von den Vertragspartnern, die sich verpflichtet sehen, alle Open-Source-Bedingungen einzuhalten.

S. 792.4. Potentielle Rechtsfolgen einer Open-Source-Verletzung und Due Diligence

261

Es entspricht also völlig herrschender Rechtsprechung und Lehre, dass Verstöße gegen Open-Source-Lizenzen einer Urheberrechtsverletzung gleichkommen können. Die potentiellen Rechtsfolgen einer Urheberrechtsverletzung sind:

• Unterlassungsansprüche;

• Beseitigungsansprüche;

• Anspruch auf angemessenes Entgelt;

• Ansprüche auf Schadenersatz;

• Strafrechtliche Verfolgung.

In gewissen Fällen kann auch ein Anspruch auf Urteilsveröffentlichung bestehen.

262

Unterlassungsansprüche, Beseitigungsansprüche und ein Anspruch auf angemessenes Entgelt bestehen dabei verschuldensunabhängig. Das bedeutet, dass die Nutzer einer Software belangt werden können, obgleich diese vom rechtswidrigen Einsatz der Software keine Kenntnis haben! Diese Erkenntnis ist hoch relevant. Bei Anschaffung, Beauftragung oder Investition in eine Software ist daher anzuraten, genau zu prüfen, ob die Software allfälligen Open-Source-Lizenzen Genüge tut („Open Source Due Diligence“). Eine Möglichkeit wäre dabei, den Lieferanten dazu zu verpflichten, vor der Veröffentlichung der Software einen Open-Source-konformen Zustand herzustellen. Werden daher ein Softwareunternehmen oder gegebenenfalls nur einzelne Software-Produkte erworben, so ist es sinnvoll, in den Vertrag entsprechende Klauseln bezüglich Open-Source-Software aufzunehmen.

263

Bei der Anschaffung von Software sollte der Erwerber auf die Vorlage einer Auflistung aller eingesetzten Open-Source-Komponenten bestehen. Diese Auflistung wird häufig als Bill-of-Material bezeichnet. Aus Anwendersicht ist es besonders wichtig, dass der Anbieter für vollständige Transparenz und eine vollständige Dokumentation in Bezug auf Open-Source-Komponenten, aber auch Third-Party-Komponenten, sorgt.

264

Die Konsequenz daraus ist, dass Open Source Compliance sowohl bei der Entwicklung von Software als auch bei deren Anschaffung bzw Anmietung beachtet werden sollte. Auf Seiten des Schadenspotentials sollte kalkuliert werden, welche Auswirkungen ein erfolgreich geltend gemachter Unterlassungsanspruch hätte. Ein solcher Anspruch sorgt bis zum Austausch der Software mindestens zu einem Auslieferungsstopp, unter Umständen auch zu einem Produktrückruf. Ein Open-Source-Verstoß kann für den HerS. 80steller eines Haushaltsgerätes oder eines KFZ, das nicht lizenzkonform eingesetzte Open-Source-Software enthält, bedeuten, dass er seine Geräte oder Fahrzeuge, die weltweite Verbreitung haben, zurückrufen muss. Die Margen im Vertrieb müssen schon sehr hoch sein, damit ein Rückruf nicht eine wirtschaftliche Katastrophe für den Hersteller zur Folge hat. Natürlich sind die Zeiten vorbei, in denen Rechtsabteilungen apodiktisch jeglichen Einsatz von Open-Source-Software verboten haben. Andererseits verbietet sich der kritiklose ungeprüfte Einsatz.

266

Dabei ist auch darauf hinzuweisen, dass von der Rechtsprechung ein strenger Maßstab angelegt wird, die auch eine Prüfungs- und Erkundigungspflicht beinhaltet. In diesem Zusammenhang ist auf die (deutsche) Rechtsprechung hinzuweisen, wonach: „ein Anbieter sich nicht auf die Zusicherung seiner Lieferanten verlassen darf, die Ware verletze keine Rechte Dritter“.

267

Die Gefahr des Schadenersatzes – nicht aber des Unterlassungsanspruches – im Fall der lizenzwidrigen Nutzung von Open-Source-Software hat hingegen bislang ein verhältnismäßig überschaubares Schadenspotential, was auch darauf zurückzuführen ist, dass Open-Source-Software lizenzkostenfrei vertrieben wird. Jedoch hat das LG Bochum bei einer Verletzung der LGPL bereits die grundsätzliche Möglichkeit eines Schadenersatzanspruches festgestellt.

268

Ausdrücklich ist darauf hinzuweisen, dass die bloße Nutzung von Open-Source-Software keine Verpflichtungen des Anwenders auslöst. Diese werden erst dann schlagend, wenn diese Software vertrieben/weitergegeben wird. Erst dann, wenn der Lizenznehmer die Software an einen Dritten überträgt – in der Sprache der GPL „convey“ – müssen die Lizenzpflichten eingehalten werden. Die GPL stellen nämlich ausdrücklich klar, dass das bloße Ablaufenlassen keine Pflichten aus der GPL auslösen kann. Die Herausforderungen fangen erst bei der Weitergabe der Open-Source-Software an. Eine Verbreitung von Open-Source-Software an ein konzernangehöriges Unternehmen S. 81stellt nach überwiegender, wohl aber nicht unbestrittener, Ansicht im Übrigen eine pflichtauslösende Weitergabe dar. Die Nutzung von Software in Tochter- oder Mutterunternehmen stellt daher regelmäßig eine relevante Verwertungshandlung dar und löst die Pflichten im Sinne der Open-Source-Lizenzen aus. Für ein „Inverkehrbringen“ reicht die Überlassung an einen einzelnen Dritten aus.

269

Die erste Frage im Zuge der Open Source Compliance sollte daher immer sein, ob überhaupt eine Intention besteht, die Software weiterzugeben. Die Frage, ab wann die Einhaltung der Open-Source-Lizenzbedingungen geboten ist, ist damit an den Begriff der „distribution“ geknüpft. Bei der Definition dieses Begriffes ist sowohl das österreichische Urheberrecht als auch die Definition der „distribution“ nach amerikanischem Recht zu beachten. § 106 U.S. Copyright Act enthält eine Definition für die Aktivität „distribute“: „to distribute copies or phonorecords of the copyrighted work to the public by sale or other transfer of ownership, or by rental, lease, or lending“. Die U.S.-Terminologie lässt daher darauf schließen, dass für die Weitergabe eine Überlassung an einen anderen Rechtsträger erforderlich und eine interne Weitergabe nicht ausreichend ist.

270

Praktisch hoch relevant ist die Frage, ob eine SaaS-Anwendung als relevante Weitergabe zu qualifizieren ist. Dies gilt zumindest dann, wenn die Lizenzbedingungen nicht dezidiert eine ASP- oder SaaS-Anwendung in deren Anwendungsbereich einbeziehen. Die AGPL-3.0 sieht etwa unter gewissen Voraussetzungen einen Copyleft auch bei einer ASP- bzw SaaS-Nutzung vor. Sowohl Gerichte als auch die Literatur haben eine öffentliche Wiedergabe bei Cloud-Diensten und bei Software as a Service als das maßgebliche Verwertungsrecht angesehen. Wer Softwarefunktionalität über einen Cloud-Dienst öffentlich zugänglich macht, ohne dass dem Endnutzer eine Kopie überlassen wird, nimmt somit eine öffentliche Wiedergabe vor. In der unkörperlichen Verwertung durch öffentliche Zugänglichmachung von Open-Source-Software wird man eine relevante, pflichtauslösende Weitergabe sehen können. Dabei wird eine Weitergabe eher zu bejahen sein, wenn die Software auf der Plattform eines externen Cloud-Computing-Anbieters betrieben wird, als wenn die Software im eigenen Rechenzentrum gehostet wird. Eine Verbreitung findet nach herrschender Meinung statt, wenn ein Vervielfältigungsstück der Software in der Öffentlichkeit angeboten oder in Verkehr gebracht wird.

271

Teilweise wird in der Literatur davor gewarnt, Open-Source-Software im Wege des Application Service Providings oder Software as a Service zu nutzen bzw zur Nutzung zur Verfügung zu stellen. Problematisch sei unter anderem hinsichtlich der GPL, dass diese grundsätzlich eine entgeltliche Vermietung der Software ausschließen soll, da für die Einräumung des Nutzungsrechts kein Entgelt verlangt werden dürfe. Insoweit sei jeS. 82denfalls für die GPL v2 umstritten, ob die Lizenzbedingungen der Nutzung von Open-Source-Software im Wege des ASP entgegenstehen. Diese Unsicherheit rührt daher, dass die „betagteren“ Lizenzbedingungen diese Formen der Softwarenutzung nicht kannten. Demgegenüber sind nach Ziffer 6 d) und 3) der GPL v3 ASP oder andere – entgeltliche wie unentgeltliche – Formen der Online-Nutzung von Software, wie etwa SaaS, ausdrücklich erlaubt. Jaeger/Metzger machen jedoch darauf aufmerksam, dass diese Rechtsunsicherheit dadurch entschärft wird, dass viele der Entwickler dauerhaft an Entwicklungsprojekten mitarbeiten und dabei die Bearbeitungsurheberrechte mitsamt der von ihnen zuvor programmierten Software regelmäßig neu lizenzieren, sodass auch älterer Code unter der neuen Nutzungsart verwendet werden kann. Zudem sei bislang nicht bekannt geworden, dass Rechteinhaber Anstoß an dieser Form der Nutzung nehmen würden. Es bestehe vielmehr Konsens, dass die Nutzung von freier Software möglichst weitgehend zulässig sein soll.

2.5. Open Source und Fragen der Vertragsbeziehung

272

Praktisch bedeutsam ist der kombinierte Vertrieb von Open-Source-Software und proprietärer Software innerhalb eines Produkts. Typisch dafür ist die Verwendung von Open-Source-Bibliotheken innerhalb einer Eigenentwicklung. Wir gehen von folgendem typischen Sachverhalt aus: Ein Software-Anbieter hat eine Software programmiert und dabei einige Komponenten (Libraries) eingebaut, die einer Open-Source-Lizenz unterliegen.

273

Der Anbieter und Anwender dürfen in diesem Fall nicht außer Acht lassen, dass durch den Einsatz von Open-Source-Software eine weitere Vertragspartei zu berücksichtigen ist. Diese Vertragspartei erlegt dem Anbieter und dem Anwender nicht-verhandelbare Lizenztexte auf. Deren Nichteinhaltung kann erhebliche rechtliche Konsequenzen nach sich ziehen.

274

Die Tendenz in der Literatur geht nach dem Modell der sogenannten Direktlizenzierung zumindest bei den weit verbreiteten Ausprägungen der GPL-Lizenzen davon aus, dass der Lizenzvertrag in Bezug auf die Open-Source-Bestandteile in der proprietären Software und den zugrunde liegenden Open-Source-Lizenztexten direkt zwischen dem Open-Source-Rechteinhaber und dem Anwender zustande kommt. Open-Source-Lizenzen werden damit grundsätzlich direkt vom Urheber bzw Inhaber der Lizenzrechte an einer Software eingeräumt, weshalb es zu keiner Lizenzkette zwischen Urheber, Distributor und Nutzer kommt. Es ist daher darauf zu achten, dass die vertraglichen Regelungen sauber zwischen Open-Source-Bestandteilen und proprietärer Software trennen.

276

Nach ganz herrschender Meinung handelt es sich bei der Einräumung von Open-Source-Lizenzen um einen Lizenzvertrag mit schenkungsvertragsrechtlichen Elementen. Schneider sieht die vertragstypologische Einordnung der Open-Source-Lizenzen durchaus schwierig, was damit zusammenhängt, dass die AGB sehr stark an anglo-amerikanisches Recht angelehnt sind und der dortige Haftungs- und Gewährleistungsausschluss in den meisten Fällen unwirksam sein dürfte, auch wenn der genaue Vertragstyp als Referenz nicht feststeht. Dies hat vor allem Auswirkungen für das Gewährleistungsrecht und Haftungsregelungen. Das Gewährleistungsrecht bezieht sich ausdrücklich nur auf entgeltliche Verträge – „einem geschenkten Gaul schaut man schließlich nicht ins Maul“. Allerdings kann der Open-Source-Lizenzgeber dann zur Haftung herangezogen werden, wenn er wissentlich eine fremde Sache verschenkt. Zudem kann eine Haftung im Falle groben Verschuldens, jedenfalls aber bei Vorsätzlichkeit, angenommen werden.

277

Open-Source-Software ist durch einen gänzlichen Gewährleistungs- und Haftungsausschluss charakterisiert. Wobei hier zu differenzieren ist:

Rechtsverhältnis Anwender – Open Source Distributor: In diesem Rechtsverhältnis bestehen die Gewährleistungs- und Haftungsansprüche sehr wohl, schließlich erbringt der Open Source Distributor seine Leistung regelmäßig entgeltlich.

Rechtsverhältnis Anwender – Programmierer (Urheber): Hier stellt sich die Frage, ob ein gänzlicher Gewährleistungs- und Haftungsausschluss mit der österreichischen Rechtsordnung in Einklang gebracht werden kann. Nach herrschender Lehre und Rechtsprechung sind Open-Source-Lizenzen als Allgemeine Geschäftsbedingungen zu qualifizieren. Es handelt sich nämlich um einen Mustervertrag, der für eine Vielzahl von Anwendungsfällen konzipiert und vorformuliert wurde. Demnach unterliegen sie S. 84einer Inhalts- und Geltungskontrolle. Insgesamt sollte ein Anbieter, der seine Open-Source-Software an einen Erwerber auf Grundlage einer Open-Source-Lizenz weitergeben möchte, damit berücksichtigen, dass die Bestimmungen der Open-Source-Lizenzen grundsätzlich den AGB-rechtlichen Korrektiven unterliegen. Überraschende, ungewöhnlich und gröblich benachteiligende Vertragsklauseln sind damit nichtig. Marly führt weiters an, dass bspw die GPL Version 3 nicht inhaltlich ausreichend verständlich ist. Hier sind nicht auf Open-Source-Software spezialisierte Juristen der Prüfungsmaßstab, sondern der unternehmerische Durchschnittskunde in der jeweiligen Branche.

278

Dabei ist jedoch zu beachten, dass Gewährleistungsansprüche und Haftungsansprüche im Falle einer unentgeltlichen Leistungserbringung (Schenkung) beschränkt sind. Die Haftungseinschränkungen sind nach europäischem Recht rechtswidrig, da sie selbst für Vorsatz entsprechende Haftungsausschlüsse statuieren. Nach Kulke besteht allgemein Einigkeit, dass die Haftungsklauseln in Open-Source-Lizenzbedingungen so gut wie immer rechtswidrig sind. Problematisch ist dabei nämlich, dass die gängigen Open-Source-Lizenzen einen Haftungsausschluss sogar für Vorsatz enthalten, was jedenfalls sittenwidrig und damit unwirksam ist. Die Konsequenz daraus ist, dass für den Verwender der Open Source Lizenzen die dispositive uneingeschränkte Haftungsregelung zur Anwendung gelangt. Hinzuweisen ist jedoch darauf, dass aufgrund der unentgeltlichen Weitergabe der Software die Haftungsprivilegierungen des Schenkungsrechts greifen. In der Regel wird auch bei einer Schenkung für grob fahrlässiges Verhalten gehaftet. Auch die allermeisten in Open-Source-Lizenzbedingungen geregelten Gewährleistungsausschlüsse sind im Ergebnis unwirksam. Die offenbar aus dem amerikanischen Rechtssystem stammenden Regelungen zur Beschränkung der Haftung für Sach- und Rechtsmängel („as is“-Regelung) lassen sich nicht mit einer Geltungskontrolle im Sinne des § 864a ABGB bzw Inhaltskontrolle im Sinne des § 879 Abs 3 ABGB in Einklang bringen. Derartige weite Haftungs- und Gewährleistungsausschlüsse sind nach österreichischem Recht unzulässig. Allerdings ist schon auch zu berücksichtigen, dass zwischen Unternehmern ein Verzicht auf Gewährleistungsansprüche grundsätzlich zulässig sein kann, wobei ein solcher Verzicht im Zweifel restriktiv zu interpretieren ist.

279

Daher empfiehlt Huppertz Anwendern von Open-Source-Lizenzbedingungen im Ergebnis, durch eine gesonderte Vereinbarung mit dem jeweiligen Erwerber eine eigenständige Haftungs- und Gewährleistungsregelung zu treffen, um so nicht den gesetzlichen Haftungs- und Gewährleistungsbestimmungen uneingeschränkt ausgesetzt zu sein. Hinzuweisen ist jedoch freilich nochmals darauf, dass bei unentgeltlicher Überlassung S. 85einer Sache gar keine Gewährleistungsansprüche bestehen. Zudem ist ein Abschluss zwischen den Programmierern und den Anwendern in der Regel praktisch nicht umsetzbar.

280

Das Angebot zum Abschluss der Open-Source-Lizenztexte ist im Text der jeweiligen Open-Source-Lizenz enthalten. Die Annahme dieses Angebots erklärt der Anwender konkludent, indem er die Software verändert oder eine sonstige Nutzungshandlung vornimmt. Eine wirksame Einbeziehung der Open-Source-Lizenzbedingungen ist grundsätzlich zu bejahen. Voraussetzung für die Einbeziehung von Vertragsformularen ist generell, dass der Anbieter den Anwender bei Vertragsabschluss ausdrücklich auf diese hinweist und ihm die Möglichkeit verschafft, in zumutbarer Weise von ihrem Inhalt Kenntnis zu nehmen. Sodann muss der Vertragspartner mit der Geltung des Vertragsformulars einverstanden sein.

281

Die rechtskonforme Einbeziehung der Open-Source-Lizenzbedingungen ist dabei nur schwer mit der österreichischen Rechtsordnung in Einklang zu bringen, da diese nicht aktiv akzeptiert werden. Im Gegensatz zu den Clickwrap-Verträgen, bei denen der Anbieter den Anwender zwingt, diese per Mausklick zu akzeptieren, handelt es sich hier um Fälle, bei denen der Anbieter die Lizenzbedingungen lediglich online verfügbar hält. Derartige „Browsewrap-Verträge“ sind der österreichischen Rechtsordnung grundsätzlich fremd.

282

Aus haftungstechnischen Erwägungen ist es weiters ratsam, den Kunden vor Vertragsabschluss über die Risiken, die mit der Nutzung einer Open-Source-Software einhergehen, aufzuklären. Hier empfiehlt es sich, deutlich zu machen, dass sich der Disclaimer nicht auf das Rechtsverhältnis von Anbieter und Anwender bezieht, sondern auf das Verhältnis zwischen Anwender und Open-Source-Lizenzinhaber.

283

Sofern die jeweilige Open-Source-Lizenzbedingung das anwendbare Recht nicht regelt, stellt sich die Frage nach der Anwendbarkeit des nationalen Rechts. Diese Frage ist schon deshalb berechtigt, weil die meisten Open-Source-Lizenzbedingungen in englischer Sprache gefasst sind und sich offensichtlich an der im anglo-amerikanischen Rechtsraum üblichen Vertragsgestaltung und Terminologie orientieren. Bei der Bestimmung des anwendbaren Rechts ist zwischen den schuldrechtlichen Open-Source-Lizenzbedingungen und den lizenzierten (dinglichen) Schutzrechten an der Software zu unterschieden. Auf der schuldrechtlichen Ebene ist das anwendbare Recht für die Auslegung einer Open-Source-Lizenz relevant, etwa bei der Frage, ob der Copyleft-Effekt zur Anwendung gelangt oder nicht. Auf der Ebene des Schutzrechtes dient das anwendbare Recht zur Klärung, ob überhaupt ein Schutzrecht vorliegt, das verletzt werden konnte und welche Folgen sich daraus ergeben, also etwa, ob eine Software Urheberrechtsschutz genießt und wie sich der daraus ergebende Schaden bemisst.

S. 86

284

An völkerrechtlichen Verträgen sind die europäische Rom-I-VO für vertragliche Rechtsverhältnisse sowie die Rom-II-VO für außervertragliche deliktische Rechtsverhältnisse einschlägig. Mangels Rechtswahl oder einschlägigen Sonderregelungen bestimmt sich das Vertragsstatut nach Art 4 Abs 2, 19 Rom-I-VO der Rechtsordnung des Staates, in dem sich die Partei für gewöhnlich aufhält, welche die charakteristische Leistung erbringt. Bei einem Lizenzvertrag stellt die Einräumung der Nutzungsrechte die charakteristische Leistung dar, weil sie für den Lizenzvertrag eigentümlich ist und ihn von anderen Vertragstypen unterscheidet. Die Zahlung eines eventuellen Entgeltes im Lizenzgeschäft ist eine übliche Leistung und damit keine Pflicht, die den Lizenzvertrag prägt. Ohne auf die in diesem Zusammenhang zu berücksichtigenden schwierigen kollisionsrechtlichen Fragen näher einzugehen, wird man im Ergebnis davon ausgehen können, dass in der Regel österreichisches Recht Anwendung finden wird, wenn sowohl auf Seiten des Lizenzgebers als auch auf Seiten des Lizenznehmers ein Unternehmen mit Sitz in Österreich steht. Darüber hinaus findet österreichisches Urheberrecht jedenfalls dann Anwendung, wenn die Software in Österreich genutzt werden soll bzw die urheberrechtliche relevante Handlung in Österreich stattgefunden hat. Grundsätzlich ist davon auszugehen, dass bei einer Urheberrechtsverletzung von Open-Source-Software das jeweils nationale Recht anzuwenden ist.

285

Haben bei einer Open-Source-Software mehrere Urheber aus verschiedenen Ländern zu einer Software beigetragen, kann ein gemeinsames Vertragsstatut für die gesamte Software nur festgestellt werden, wenn die Urheber in einer juristischen Gesellschaft bzw im Wege der Miturheberschaft einer Gesamthandgemeinschaft zusammengefasst sind. Voraussetzung dafür ist ein abgestimmtes Verhalten in der Entwicklung. Liegt eine solche Abstimmung nicht vor, kommt es zu einer Zersplitterung des Vertragsstatuts entsprechend der Aufenthaltsorte der einzelnen Programmierer.

2.6. Open Source Compliance

2.6.1. Zum Begriff der Open Source Compliance

286

Die Verbreitung von Open-Source-Software erstreckt sich von Anwendersoftware über Haushaltsgeräte über Telekommunikationsprodukte bis hin zu Nutzfahrzeugen. Es sind Lizenztexte zu übermitteln, Urheberrechtsvermerke anzubringen, Haftungsausschlüsse zu kommunizieren und der Quellcode offenzulegen. Insbesondere bei Embedded Systems fällt diese Umsetzung besonders schwer. Damit eine Software als Open-Source-Software vertrieben werden kann, muss diese gewisse Voraussetzungen erfüllen. So muss die Lizenz uneingeschränkte Weiterverbreitung gestatten, die Software muss im Quellcode vorliegen, Veränderungen und Weiterentwicklung soll erlaubt sein und weitere BedinS. 87gungen dürfen nicht an die Einräumung der Rechte geknüpft sein. Dass diese Pflichten zu erfüllen sind, ist trotz der AGB-rechtlichen Bedenken bei einigen der besonders komplexen Lizenzbedingungen unstreitig. Doch was genau bedeutet „Open Source Compliance“? Der wichtigste diesbezügliche Standard ist das „OpenChain Project“. Dort werden folgende Aspekte als Elemente von Open Source Compliance gelistet:

287

• Eine schriftliche Open Source Policy;

• Schulungen von Mitarbeitern;

• Prozesse zur Ermittlung der Programmbestandteile;

• Analyse der anzuwendenden Open-Source-Lizenzen – so bieten die Clone Code Scanner FOSSID, WhiteSource, Revenera, Black Duck Software und Palamida eine Überprüfung von Quellcode auf Open-Source-Elemente an. Die von HP initiierte Software FOS Sology sowie Scanconde von nexB, die beide selbst unter Open-Source-Lizenzen zugänglich sind, dienen speziell dem Auffinden und Extrahieren von Lizenztexten und Urhebervermerken in Softwarepaketen und damit ebenfalls Compliance-Zwecken. Für den Einsatz von Scannern spricht, dass bei einer bloß manuellen Auflistung regelmäßig eingesetzte Komponenten übersehen werden. Im Idealfall wird ein hybrides Modell angewendet. Damit ist gemeint, dass die Einschätzungen der Entwickler gegebenenfalls durch die Ergebnisse der Scanner präzisiert werden. Umgekehrt kann auch der Weg gegangen werden, die Software zunächst anhand des Scanners zu analysieren und die Scan-Ergebnisse in einem zweiten Schritt manuell nachzubearbeiten;

• Ansprechpartner für Lizenzfragen Dritter;

• Prozess zur Überprüfung und Umsetzung der allgemeinen Vertriebspflichten;

• Überprüfung der Lizenzkompatibilität – eine Inkompatibilität ist bei der Anwendung mehrerer Copyleft-Lizenzen dann anzunehmen, wenn eine abgeleitete Arbeit unter mehreren sich widerstreitenden Copyleft-Lizenzen eingesetzt wird;

• Überprüfung der Einhaltung des Copylefts;

• Zertifizierung der OpenChain-Anforderung.

Eine besondere Rolle spielt dabei die Open Source Policy. Diese hat die Aufgabe, jenen Personen, die in der täglichen Praxis Berührungspunkte zu Open-Source-Software haben, eine Orientierungshilfe zu bieten. Eine Open Source Policy, oder auch Open-Source-Richtlinie, regelt, welche OSS die Entwickler unter welchen Voraussetzungen und in welcher Form einsetzen können (und welche nicht). Ohne sich tiefergehend mit der Materie auseinandersetzen zu müssen, erhalten die Stakeholder eine Handlungsempfehlung, was zu geschehen hat, wenn Open-Source-Software-Komponenten unter einem bestimmten Vertragswerk (zB MIT oder GNU GPL-Lizenz) lizenziert sind. Je nachdem, welche Open-Source-Lizenz betroffen ist, sollte ein entsprechender Prozess initiiert werden. Wenn also eine sehr „restriktive“ Open-Source-Lizenz eingesetzt werS. 88den soll, ist es wahrscheinlich sinnvoll, diese nur in Abstimmung mit der Geschäftsführung zu implementieren. Bei eher „liberalen“ Open-Source-Lizenzen ist dies hingegen nicht erforderlich. Ausgangspunkt für die Open Source Policy ist eine Einstufung der praktisch häufigsten Open-Source-Lizenzen nach ihrer „Kritikalität“.

289

Idealerweise wird bei größeren IT-Projekten zusätzlich ein OSS Due Diligence Board aus Vertretern beider Parteien eingerichtet. Dieses wird beispielsweise unter rechtzeitiger und präventiver Einbindung durch das OSS-Compliance-Team sowie (intern oder externer) Rechtsabteilung bei Schwierigkeiten unterstützt.

290

Die Risiko-Klassen richten sich unter anderem danach, wie stark der „Copyleft-Effekt“ ausgeprägt ist. Dies darf jedoch keinesfalls den Eindruck hinterlassen, dass Open-Source-Lizenzen ohne strengen Copyleft quasi vogelfrei sind. Auch bei Anwendung von liberalen Lizenzen wie beispielsweise der BSD oder Apache Lizenz müssen lizenzrechtliche Vorgaben eingehalten werden. Selbst bei Anwendung der MIT Lizenz müssen etwa der Copyrightvermerk und Lizenztext angeführt werden.

291

Aus rechtlichen Gesichtspunkten sollten folgende Parameter bei der Kategorisierung der Open-Source-Lizenzbedingungen anlassbezogen berücksichtig werden:

• Die „Intensität“ des Copylefts: Der Copyleft-Effekt ist eine Klausel, die sicherstellt, dass Weiterentwicklungen der Software unter denselben Bedingungen der Lizenz wieder freigegeben werden. Dahinter steht ein ganz wesentliches Grundprinzip, welches dafür sorgen soll, dass geänderte Open-Source-Software innerhalb des Open-Source-Anwendungsbereichs verbleiben und nicht als kommerzielle, proprietäre Software vertrieben werden kann. Der Copyleft ist insofern eine Schutzklausel, die sicherstellt, dass Weiterentwicklungen einer Software unter denselben Bedingungen der Open-Source-Lizenz wieder freigegeben werden. Die Intention solcher Copyleft-Klauseln liegt darin, die freie Nutzbarkeit der Software auch für weiterentwickelte Versionen sicherzustellen. Diese grundsätzliche Entscheidung kann im Rahmen einer Open-Source-Strategie festgelegt werden.

• Die „Verträglichkeit“ mit anderen Lizenzen („Lizenzkompatibilität“): Eine Inkompatibilität ist bei der Anwendung mehrerer Copyleft-Lizenzen dann anzunehmen, wenn eine abgeleitete Arbeit unter mehreren sich widerstreitenden Copyleft-Lizenzen eingesetzt wird. Beispielsweise gelangt die Free Software Foundation zu der AnS. 89sicht, dass die BSD-4-Clause mit der GPL-2.0. inkompatibel ist. Zwei der häufigsten Open-Source-Lizenzen, nämlich Apache-2.0 und GPL dürfen nach der Einschätzung der Lizenzgeber ebenfalls nur beschränkt in ein und demselben Projekt eingesetzt werden. Daher ist für jeden Einzelfall zu prüfen, ob eine Open-Source-Lizenz die Nutzung einer anderen Open-Source-Lizenz gestattet. Schließlich wäre es unzulässig, Softwarekomponenten so zu verbinden, dass sie gleichzeitig unter zwei sich widersprechenden Bedingungen lizenziert sein müssen.

• OSS und Patentrecht: „Patente“ sind dadurch charakterisiert, dass sie „neu und geheim“ sind, weshalb deren vertraulicher Behandlung höchste Priorität zukommt. Dass dies nur schwer in Einklang mit der „Philosophie“ von Open Source gebracht werden kann, ist offensichtlich. Die Open Source Community hegt daher eine grundsätzlich ablehnende Haltung gegenüber dem Patentwesen. Diese kritische Haltung manifestiert sich deutlich in der Präambel der GPL-2.0: „Schließlich und endlich ist jedes freie Programm permanent durch Softwarepatente bedroht“.

• OSS und Tivoisierung: Inhaber von geistigen Rechten an Software stehen vor der Herausforderung, ihr digitales Eigentum vor unberechtigten Eingriffen zu schützen. Im Zuge des Digital Rights Managements werden daher technische Maßnahmen umgesetzt, um unberechtigte Nutzungen zu verhindern. Unter Tivoisierung versteht man einen Aspekt des Digital Rights Managements, nämlich technische Schutzmaßnahmen für Software, welche die Austauschbarkeit von Software-Komponenten beschränken. Das Verbot der Tivoisierung wird daher auch als „DRM-Verbot“ bezeichnet. Da derartige Maßnahmen die Nutzung von Software beschränken, stehen sie in einem Spannungsverhältnis zum Einsatz von OSS. So regelt etwa die GPL-3.0, dass Software nicht dazu eingesetzt werden soll, um Maßnahmen des Digital Right Managements zu fördern.

• Risiko der Rechtsverfolgung: Obgleich die Rechtsdurchsetzung von Open-Source-Lizenzbedingungen – vor allem in Österreich – noch in ihren Kinderschuhen steckt, kann konstatiert werden, dass gerade im Bereich des Einsatzes des Linux Kernels und von WordPress-Plug-Ins die Wahrscheinlichkeit einer rechtlichen Auseinandersetzung zunimmt. „Streitgeneigte“ Lizenzen sind daher mit größerer Vorsicht zu genießen.

• SaaS- bzw ASP-Kompatibilität: Ein praktisch immer wichtigeres Kriterium ist, ob die Software als SaaS- bzw ASP-Anwendung vertrieben werden darf. In einigen moderneren Lizenzversionen, wie der GPL-3.0, AGPL-3.0, LGPL.3.0 und der MPL-2.0, wird SaaS speziell berücksichtigt und in allen genannten Lizenzen auch entsprechende Nutzungsrechte eingeräumt. Ältere Lizenzen jedoch erwähnen eine SaaS- bzw ASP-Anwendung hingegen nicht. Dies ist damit zu begründen, dass diese Technologie erst Mitte/Ende der 1990er Jahre wirtschaftlich an Relevanz gewann. Ob diese älteren OSS-Lizenzbedingungen eine Nutzung via ASP bzw SaaS gestatten, ist durch S. 90tiefergehende Recherche sowie durch eine ergänzende Vertragsauslegung zu klären. Teilweise wird gar die Meinung vertreten, dass die cloudbezogene Verwendung von OSS in proprietärer Software keinen Copyleft auslöst und auch dem Anwender keine weiteren Pflichten der Software in der Cloud auferlegt werden dürfen.

• Rechtswahlklausel und Gerichtsstand: Wenngleich die Wirksamkeit, gerade von Gerichtsstandsvereinbarungen, in Lizenzbedingungen generell als fraglich beurteilt werden kann, sollte auch dieser Aspekt berücksichtigt werden. Einige Lizenzbedingungen, etwa die „CeCILL“, die „deutsche Frei Software Lizenz“ oder die „EUPL“ sehen Rechtswahl- und Gerichtsstandsklauseln dezidiert vor.

• Spezialfall „Software der Kommission“: Hinsichtlich „Software der Kommission“ ist der Beschluss der Kommission vom 8.12.2021 über die Open-Source-Lizenzierung und die Weiterverwendung von Software der Kommission zu beachten. Hinsichtlich Software der Kommission sollte grundsätzlich eine Lizenzierung unter die „EUPL“, die European Union Licence in der aktuellen Version (Version 1.2) sowie allen künftigen Versionen der Kommission, erfolgen. Die EUPL wurde 2007 von der Europäischen Kommission veröffentlicht. Sie liegt mittlerweile in der Version 1.2 aus dem Jahr 2016 vor. Sie wurde von der IDABC („Interoperable Delivery of European eGovernment to public Administrations, Business and Citizens“), einem Programm der Europäischen Gemeinschaft, entwickelt. Die bekannten Open-Source-Lizenzen wurden von der IDABC als unzureichend verworfen, weil keine offiziellen Sprachfassungen existieren und die Ausrichtung auf das US-Recht als unpassend empfunden wurde bzw als rechtlich problematisch, was etwa die Klauseln für den Haftungsausschluss betrifft. Als Software der Kommission ist dabei zu verstehen:

  –

  Software, an der die Kommission im Namen der Union die Rechte des geistigen Eigentums besitzt und

  –

  Software im Besitz eines Dritten, die im Rahmen einer Open-Source-Lizenz zur Verfügung steht und von der Kommission oder einem Dritten auf Verlangen der Kommission geändert wurde.

Wichtig ist, dass es „die richtige“ Open-Source-Lizenz nicht gibt. Es kommt stets auf den konkreten Einzelfall an, welche Lizenz als passend und opportun zu qualifizieren ist. So wird es bei Software, die vom Auftraggeber vermarktet werden soll, regelmäßig das primäre Ziel des Auftraggebers sein, einen Copyleft-Effekt und damit die Preisgabe des zugehörigen Quellcodes zu vermeiden. In solchen Fällen wird sich die Anwendung einer MIT- oder BSD-Lizenz anbieten. Möchte der Auftraggeber die Software hingegen im Rahmen der Open Source Community weiterentwickeln, kann die Anwendung des Copyleft-Effektes hingegen ein ausdrücklicher Wunsch sein. In diesem Fall wäre die Anwendung der GNU GPL v2 naheliegend.

S. 91

292

Auf die Frage, welche Open-Source-Lizenzbedingungen zu empfehlen sind, muss daher mit einer Gegenfrage reagiert werden: Was ist dem Entwickler der Software wichtig? Es kann gar nicht stark genug betont werden: Die Auswahl der Open-Source-Lizenz hängt primär davon ab, welche Ziele der Entwickler, der Auftraggeber bzw künftige Inhaber der Werknutzungsrechte („Lizenzgeber“) verfolgt. Geht es ihm darum, die OSS möglichst zu verbreiten, dann sind Open-Source-Lizenzbedingungen mit einem starken Copyleft, wie etwa die GNU GPL 3.0, zu empfehlen. Dies macht etwa Sinn, wenn die Software zugunsten der Allgemeinheit weiterentwickelt und gleichzeitig eine Kommerzialisierung durch Dritte eingedämmt werden soll.

293

Soll hingegen sowohl der Anbieter als auch der Anwender möglichst viel Freiraum haben, so ist in Richtung der „permissiven Lizenzen“ zu tendieren wie etwa den Lizenzbedingungen: „MIT“. Die MIT-Lizenz wurde vom Massachusetts Institute of Technology entworfen und ist mit ca 26 % die meistgenutzte Open-Source-Lizenz. Die MIT-Lizenz ist eine einfache Non-Copyleft-Lizenz. Die Rechteklausel ist sehr weitgehend formuliert („to deal in the Software without restriction, including without limitation to use,…“) und zeigt klar die Intention des Lizenzgebers, jegliche Art der Nutzung zu gestatten.

294

Grundsätzlich spricht auch nichts dagegen, eigene, nach seinen Vorstellungen „maßgeschneiderte“, Lizenzen zu kreieren. Ein Überblick über mögliche Lizenzen kann dem Lizenzcenter des ifrOSS entnommen werden. Dabei ist jedoch darauf hinzuweisen, dass etwa 93 % der gesamten verfügbaren Open-Source-Software unter lediglich zehn verschiedenen Lizenzen angeboten werden. Letztlich ist aber die Eigenkreation von (vor allem nationalen) Open-Source-Lizenzbedingungen als kritisch zu betrachten, da diese mangels Bekanntheitsgrad nur zurückhaltend oder gar nicht akzeptiert werden.

296

Die nachstehende Kategorisierung soll einen ersten Überblick über das Risikopotential der verschiedenen Lizenzen verschaffen. Ausdrücklich soll jedoch darauf hingewiesen werden, dass eine pauschale Beurteilung regelmäßig optimale Resultate konterkariert. So würde man mit einem pauschalen Verbot von etwa GPL-Lizenzen möglicherweise praktikable Anwendungen zu restriktiv ausschließen:

Kategorie „restriktiv“:

• GPL (GNU General Public License v.2.0/3.0)

• AGPL (GNU Affero General Public License v1.0/3.0)

• EPL-1.0 (Eclipse Publice License)

• European Union Public License

• S. 92Deutsche Freie Software Lizenz

• Open Software License

Kategorie „neutral“:

• Mozilla Public License

• Common Development and Distribution License

• GNU Lesser General Public License

• Microsoft Public License

• EPL-2.0 (Eclipse Public License)

• Apache-2.0

• LGPL (GNU Lesser General Public License)

Kategorie „liberal“:

• BSD License (2-Clause, 3-Clause)

• MIT-License

• Zlib License

• Universal Permissive License

2.6.2. Zum rechtskonformen Einsatz von Open-Source-Software

297

Die überwiegende Zahl an Abmahnungen aufgrund von Verstößen gegen Open-Source-Lizenzbedingungen ist darauf zurückzuführen, dass die Lizenzbedingungen nicht eingehalten werden. Teilweise ist unklar, wie die Open Source Compliance konkret umzusetzen ist und dies ist Gegenstand vieler Diskussionen zum Wortlaut einzelner Lizenzen und deren Auslegung. Was bedeutet es für den Hersteller eines Embedded Systems, der aus Praktikabilitätsgründen Lizenztexte oder Urheberrechtsvermerke nicht als Kopie mit dem Produkt ausliefert, sondern „nur“ über eine Website zugänglich macht? Folgt man dem strengen Wortlaut der GNU Lizenzen, dürfte dies nicht lizenzkonform sein. Die Folgen wären weitreichend. Daher soll nun auf jene rechtlichen Verpflichtungen eingegangen werden, die mit dem Vertrieb von Open-Source-Software einhergehen:

298

Mitlieferung des Lizenztextes: In der Regel ist es erforderlich, dass der Nutzer von Open-Source-Software beim Erhalt der Software eine Kopie der Lizenzbestimmungen erhält. In der Praxis werden die Lizenzbestimmungen regelmäßig im Quellcode abgelegt.

299

Veröffentlichung des Quellcodes: Zentrales Element der Open-Source-Lizenzen ist, dass der Quellcode der Öffentlichkeit zur Verfügung gestellt werden muss. Vorgeschrieben ist in allen Lizenzformen, dass ein Hinweis auf die Ursprungsquelle der Software in das Marketing aufgenommen werden muss. Neben der Frage, wie der Quellcode verS. 93öffentlicht wird (zB auf einer CD-ROM oder einem USB-Stick), ist auch die Frage, was konkret zu veröffentlichen ist, zu klären. Die GPL-2.0. sprechen in diesem Zusammenhang davon, dass der „vollständige korrespondierende Source Code“ veröffentlicht werden muss. Dies inkludiert auch Skripte und Definitionsdateien der Schnittstellen. Nach Suchomski muss der Quellcode in einer Form vorliegen, welche ein Programmierer zur Veränderung des Programms bevorzugen würde. Absichtlich verschlüsselte Quellcodes oder dessen Zwischenformen stellen keine gültige Weitergabe des Quellcodes dar. Die Bereitstellung des Quellcodes darf grundsätzlich in unterschiedlicher Weise erfolgen, wobei dieser jedenfalls maschinenlesbar, also elektronisch, zur Verfügung gestellt werden muss. In jedem Fall sollte der Downloadlink für den Sourcecode in einer räumlichen Nähe zum Download des ausführbaren Programms einfach auffindbar sein. Dabei dürfen keine unnötigen Hürden aufgebaut werden.

300

Vermerk des Urhebers: In der Regel verlangen die Open-Source-Lizenzbedingungen, dass Bearbeiter der Software – sofern diese einen urheberrechtlich relevanten Beitrag leisten (!) – als Urheber zu vermerken sind. Diese Vermerke werden regelmäßig in sog „Credit Lists“ eingetragen. Die (Mit-)Urheber der betroffenen Software sind anzuführen. Die Urheber sind dabei entweder aus der jeweiligen Software, den Files oder direkt aus dem ausgewerteten Code zu ermitteln.

301

Haftungsausschluss für Schadenersatz und Gewährleistung: Regelmäßig verlangen Open-Source-Lizenzen, dass im Falle des Vertriebs ein Haftungs- und Gewährleistungsausschluss („Disclaimer“) angeführt wird.

302

Verbot von Beschränkungen: Ein wesentliches Element von Open-Source-Lizenzbedingungen ist weiters, dass die Nutzung des Lizenznehmers nicht beschränkt werden darf. So wäre es beispielsweise unzulässig, die Nutzung auf einen territorialen Bereich einzuschränken.

303

Fraglich ist, ob die geforderten Informationen, hier insbesondere der Quelltext, auch über eine bloße Verlinkung auf beispielsweise GitHub bereitgestellt werden können. Nach dem Sinn und Zweck der Regelung sollte es wohl genügen, wenn der Empfänger so gut wie jederzeit Gelegenheit hat, die Informationen sofort einzusehen, wenn er dies wünscht. Durch die quasi ständige Verfügbarkeit mobiler Daten würde kaum ein Unterschied bestehen, egal ob dieser die erforderlichen Informationen direkt übermittelt bekommt oder „nur“ einen Link zu diesen. Dies gilt umso mehr, als davon auszugehen ist, dass der Adressat der Veröffentlichungspflichten in der Regel internetaffin sein wird. Wird die Software beispielsweise ausschließlich zum Download im Internet angeboten, ist es ausreichend, wenn der Source Code ebenso wie der Objekt Code zum Download bereitgestellt wird. Für Software jedoch, die auf Datenträgern oder eingebettet in Hardware weitergegeben wird, ist die Bereitstellung des Source Codes über eine Download-Plattform offenbar nicht ausreichend.

S. 94

304

Schließlich könnte in Analogie zur datenschutzrechtlich gelebten und akzeptierten Praxis wohl ein Multi-Layer-Ansatz gewählt werden. Das bedeutet, dass der Empfänger initial einen groben Überblick erhält. Sollte dieser ein tieferes Interesse haben, kann er diese Informationen durch einen Link auf weitergehende Ausführungen erhalten. Alternativ dazu können nach den meisten Open-Source-Lizenzen die gebotenen Informationen durch ein schriftliches Angebot (sogenanntes Written Offer) zur Übermittlung des Source Codes bereitgestellt werden.

305

Der Verpflichtung auf Vorsehung eines Copyright-Hinweises und Überreichung einer Lizenzkopie kann am leichtesten dadurch erfüllt werden, dass Copyright-Hinweise und der Lizenztext mittels Kommentarfunktion in den Quellcode der Software einkopiert werden. Eine Alternative bestünde darin, die Hinweise über eine gesonderte rechtliche Information in der Anwendung zum Abruf vorzuhalten.

2.6.3. Verhalten bei Abmahnung

306

Es wurde beschrieben, dass die primäre Gefahr der Verletzung von Open-Source-Lizenzen eine Abmahnung darstellt. Eine Abmahnung verfolgt immer das Ziel, dass eine bestimmte Handlung unterlassen wird. Gleichzeitig werden auch die (anwaltlichen) Kosten des Abmahnschreibens geltend gemacht. Generell ist dringend anzuraten, die Abgabe einer, gegebenenfalls geforderten, Unterlassungsverpflichtung genau zu evaluieren. In diesem Kapitel soll auf die in der Praxis drängendsten Fragen bei Abmahnungen, mit Fokus auf den Aspekt Open Source, eingegangen werden.

307

Vorab stellt sich die Frage, wer ist berechtigt eine Unterlassungsverpflichtung zu begehren? Einerseits sind dies die Urheber, welche an der Open-Source-Software als Programmierer tätig waren. Doch gerade bei Open-Source-Projekten ist oft unklar, wer als Urheber zu qualifizieren ist. Open-Source-Software wird in der Regel dezentral unter Einsatz modularer Konzepte entwickelt. Vielfach wird ein Fall der Miturheberschaft vorliegen. Charakteristisch für die Entwicklung von Open-Source-Software ist die Zusammenarbeit vieler unabhängiger Programmierer, die mitunter über die ganze Welt verstreut sind und über das Internet kommunizieren. Ein selbstständiger Softwareentwickler, der an einer Open-Source-Software Umarbeitungen vorgenommen hat, kann aufgrund eines Bearbeitungsurheberrechts einen Unterlassungsanspruch geltend machen, wenn er hinreichend substantiiert darlegt und gegebenenfalls beweist, welche Teile aus dem Programm von ihm in welcher Weise umgearbeitet worden sind, inwiefern diese Umarbeitungen die Anforderungen an ein Bearbeitungsurheberrecht erfüllen und dass gerade die Schutz begründenden umgearbeiteten Programmteile ihrerseits von dem Inanspruchgenommenen übernommen und genutzt worden sind. Mehrere Urheber von Open-Source-Software sind als Miturheber im Falle einer inhaltlich abgestimmten Projektgestaltung und damit gemeinsam OSS-Lizenzgeber als Gesamthandeigentumsgemeinschaft zu qualifizieren. Existiert dagegen eine Vielzahl unabhängiger Bearbeiter, die sukzessive Bearbeitungen vorgenommen haben, neben dem Urheber der Software, S. 95so ist jeder Einzelne insoweit autonomer Lizenzgeber seiner Beträge, was bei der dezentralen und unkoordinierten Entwicklung häufiger der Fall sein dürfte. In der Praxis werden die Miturheber häufig durch die Free Software Foundation vertreten, welche die Wahrnehmung der Urheberrechte treuhandschaftlich ausübt. Gerade bei Open-Source-Software hat der Abmahnende bzw Kläger möglicherweise Schwierigkeiten, nachzuweisen, dass er entweder tatsächlicher Urheber bzw Miturheber einer Software-Komponente ist oder mindestens Bearbeitungsrechte an Bestandteilen der maßgeblichen Software-Komponente innehat und die Bestandteile der Bearbeitung die erforderliche Schöpfungshöhe erreicht haben.

308

Das OLG Karlsruhe hat entschieden, dass der Copyleft-Effekt keine „Drittbegünstigung“ bewirke. Damit ist gemeint, dass Dritte, die keine Urheber des jeweiligen Werkes sind, keine Veröffentlichungs- oder Verwertungsrechte an grundsätzlich zu veröffentlichen Quellcodes durchsetzen können.

309

Andererseits treten als potentiell Abmahnende Konkurrenten bzw Mitbewerber, also Unternehmen, welche in derselben Branche wie das abgemahnte Unternehmen tätig sind, auf. Während sich der Anspruch der Urheber auf das UrhG stützt, beruht der Anspruch der Konkurrenten auf dem Gesetz gegen den unlauteren Wettbewerb („UWG“). Der Verstoß gegen Open-Source-Lizenzpflichten sowie die fehlerhafte Darstellung der weiterhin unter diesen Pflichten stehenden Open-Source-Produkte in der Werbung eignen sich als Gegenstand einer wettbewerbsrechtlichen Kontrolle nach dem Gesetz gegen den unlauteren Wettbewerb, da ihnen ein Bezug zu Wettbewerbern bzw Markteilnehmern nicht ohne weiteres abgesprochen werden kann.

310

Die Distribution von Open-Source-Software stellt dabei grundsätzlich eine geschäftliche Handlung dar, was eine Voraussetzung für die Anwendbarkeit des UWG ist. Dadurch, dass der Unterlassungsverpflichtete sich nicht an geltendes Recht hält, hat er gegenüber dem rechtstreu agierenden Konkurrenten einen Vorteil. So kann er beispielsweise ein Produkt günstiger anbieten. Er hat demnach einen „Rechtsvorteil durch Rechtsbruch“. Gegen ein derartiges Verhalten kann nach dem UWG vorgegangen werden. Der lizenzwidrige Vertrieb führt also nicht nur zu Ansprüchen der Urheber, sondern auch zu wettbewerbsrechtlichen Ansprüchen der Konkurrenten oder entsprechenden Interessenvertretungen.

311

Aber wie soll sich der Abgemahnte verhalten, wenn er mit einer Unterlassungsverpflichtung aufgrund einer Verletzung von Open-Source-Lizenzen konfrontiert wird? Die folgenden Aspekte sollten vor einer voreiligen Abgabe der Unterlassungsverpflichtung geprüft werden:

312

Ist der Abmahnende tatsächlich zu einer Abmahnung berechtigt? Hat dieser tatsächlich einen urheberrechtlich relevanten Beitrag geleistet? Hat die gegenständliche KomS. 96ponente überhaupt die gebotene schöpferische Höhe erreicht, um als urheberrechtliches Werk qualifiziert zu werden?

313

Wurde die streitgegenständliche Software tatsächlich „veröffentlicht“ („gepublished“)? Die Verpflichtungen aus der Open-Source-Lizenzvereinbarung werden vielfach nur schlagend, wenn die Software veröffentlicht wurde. Insbesondere bei einer „konzern“-internen Nutzung und Software-as-a-Service-Modellen kann es hier interessante Fragestellungen geben.

314

Die inkriminierte Rechtswidrigkeit kann nachträglich saniert werden. Dies wird beispielsweise in Fällen der nachträglichen Veröffentlichung des Lizenztextes wenig problematisch sein, bei der Veröffentlichung des Quelltextes hingegen schon. Weiters sollte überprüft werden, ob Open-Source-Komponenten, die nicht lizenzkonform eingesetzt werden, gegebenenfalls durch rechtskonforme Komponenten ersetzt werden können.

315

Sofern im Falle einer Abmahnung für die Nutzung der Open-Source-Software auch Bereicherungs- und Schadenersatzansprüche geltend gemacht werden, stellt sich die Frage nach deren Berechnung. Nach der Rechtsprechung und Lehre sind diese Ansprüche im Wege der Lizenzanalogie zu ermitteln. Man stellt also darauf ab, was im Fall einer gewöhnlichen Plannutzung entrichtet worden wäre. Nun ist es im Falle von Open-Source-Software aber regelmäßig so, dass kein Entgelt entrichtet worden wäre. Aus diesem Grund hat das OLG Hamm Schadenersatzansprüche abgelehnt, wenn kein Dual Licensing vorliegt, da der „objektive Wert der Nutzung mit Null angesetzt werden“ müsste. Dagegen hat das LG Bochum bei einer Verletzung der LGPL bereits die grundsätzliche Möglichkeit eines Schadenersatzanspruches festgestellt.

316

In der Open Source Community wird die aggressive Betreibung von Verstößen zu monetären Zwecken, durch sogenannte „Copyright-Trolle“, ungern gesehen. Möglicherweise verstößt der potentiell Verletzte gegen Wettbewerbsrecht oder aber die „Principles of Community-Oriented GPL Enforcement“, wobei Letzteres grundsätzlich keinen zwingenden rechtlichen Gehalt hat. Ein Kriterium für eine unlautere Abmahnung ist ein auffälliges Missverhältnis von Abmahntätigkeiten und sonstiger geschäftlicher Tätigkeit des Abmahnenden.

317

Ein interessantes Argument, das in der Literatur vorgebracht wird ist, dass sich der Erwerber auf den urheberrechtlichen Erschöpfungsgrundsatz nach § 16 Abs 3 UrhG berufen kann.

318

Weiters sollte genau geprüft werden, ob das gestellte Unterlassungsbegehren ausreichend konkretisiert ist und nicht „über das Ziel hinaus schießt“.

S. 972.6.4. Der Copyleft-Effekt

319

In diesem Kapitel wird ein besonders kritisches Element vieler Open-Source-Lizenzen behandelt: Der Copyleft-Effekt. Dieser ist nicht einheitlich definiert. Die nachstehende Formulierung beschreibt den Copyleft-Effekt jedoch gut: „Der Copyleft-Effekt ist eine Klausel, die sicherstellt, dass Weiterentwicklungen der Software unter denselben Bedingungen der Lizenz wieder freigegeben werden“. Dahinter steht ein ganz wesentliches Grundprinzip, welches dafür sorgen soll, dass geänderte Open-Source-Software innerhalb des Open-Source-Anwendungsbereichs verbleiben und nicht als kommerzielle, proprietäre Software vertrieben werden kann.

320

Das originelle Wortspiel Copyleft als Gegenstück zum Copyright wird Richard Stallman zugeschrieben. Die Intention solcher Copyleft-Klauseln liegt darin, die freie Nutzbarkeit der Software auch für weiterentwickelte Versionen sicherzustellen.

321

Der Copyleft-Effekt ist insofern problematisch, weil regelmäßig der Quellcode der von Open-Source-Software abgeleiteten Softwareelemente offengelegt werden muss. Wird ein Open Source Code mit einem kommerziellen Programm vermischt, spricht man von einem „Open-Source-Hybrid“. Die Open-Source-Lizenzbedingungen springen gleichsam auf die proprietäre Software über. Man spricht in diesem Zusammenhang anschaulich auch vom „viralen“ oder immunisierenden Effekt. Die Open-Source-Software „infiziert“ gleichsam die proprietäre Software. Durch die „Infizierung“ bei Einsatz von Open-Source-Software kann sich die Open-Source-Lizenz auf das gesamte Werk erstrecken. Für Entwickler von proprietärer Software besteht diese Gefahr insbesondere dann, wenn Bibliothek-Dateien (Plugins) auf Basis von Open-Source-Lizenzen in die proprietäre Software integriert werden. Greift der Copyleft-Effekt, muss daher eventuell der gesamte (!) Quellcode vollständig offengelegt werden.

322

Je nachdem, wie „aggressiv“ der Copyleft-Effekt in den einzelnen Lizenzbestimmungen formuliert wird, wird differenziert zwischen einem „starken Copyleft“, einem (normalen) „Copyleft“ und „Permissive Lizenzen“, die als eher liberal qualifiziert werden können. Dazu zwei Beispiele zur besseren Veranschaulichung:

323

Eine weit verbreitete Lizenz ist die GNU General Public License, Version 2. Die GPL ist wiederum als Grundlage bzw Muster für die anderen in der Praxis verwendeten Open-Source-Software-Lizenzen verwendet worden. Diese formuliert den Copyleft-Effekt (Punkt 2 lit b)) wie folgt sehr streng:

„You must cause any work … that in whole or in part contains or is derived from the (Open Source) Program … to be licensed as a whole … under the terms of this License“.

S. 98

324

Hingegen sehen die Lizenzen BSD Copyright License und MIT License gar keine diesbezüglichen Verpflichtungen vor (womit sie als Permissive Lizenzen zu qualifizieren sind). Dies macht die Nutzung lizenzrechtlich deutlich unkomplizierter als bei Copyleft-Software.

325

Wenn man nun in Erinnerung ruft, dass 57 % des weltweit programmierten Codes auf Open-Source-Lizenzen beruht und die GNU General Public License, Version 2, eine der am häufigsten eingesetzte Open-Source-Lizenz ist, wird deutlich, welche „Gefahr“ Open-Source-Software für proprietäre Software begründet. Die Open-Source-Lizenzbedingungen gelten jedoch nur für das Ursprungsprogramm selbst und seine Weiterentwicklungen, nicht aber für Ergänzungen, wenn sie klar getrennt erstellt und vermarket werden. Wann dies konkret der Fall ist, ist allerdings häufig sehr unklar. Wichtig ist eine technische Trennung. Hinzu kommt außerdem, dass jedes Programm auch ohne das andere einsetzbar ist.

326

Die springende Frage in diesem Zusammenhang ist somit, wann eine (von Open-Source-Software) abgeleitete Software („derived work“) vorliegt. Diese Frage zu beantworten ist wahrlich kein leichtes Unterfangen und lässt sich nur auf Basis einer interdisziplinären Zusammenarbeit zwischen Softwareentwicklern und Juristen lösen. Die schwierige Auslegungsfrage ist auch gerichtlich noch nicht abschließend geklärt. Auch wenn Vertreter der Free Software Foundation und mit ihr das LG Berlin davon ausgehen, dass fast jede Art der Verknüpfung von proprietärer Software mit Copyleft-Open-Source-Software einen viralen Effekt auslösen soll, erscheint eine differenzierende Betrachtung geboten. Als Auslegungshilfe kann hier auf den Terminus „derivative work“ in Titel 17 U.S. Code § 101 (U.S. Copyright Act) verwiesen werden. Anhand dieser Definition lässt sich festhalten, dass darunter ein Werk zu verstehen ist, (i) das auf einem oder mehreren vorbestehenden Werken basiert, oder (ii) jede andere Form, in welcher ein Werk umgestaltet, umgewandelt oder bearbeitet wird.

327

Damit eine solche abgeleitete Arbeit vorliegt, muss zunächst ein Eingriff in die Open-Source-Komponente vorliegen. Nach gängigem Verständnis muss für das Überschreiten der Grenzen zur Veränderung ein wesentlicher Eingriff in den Source Code erfolgen. Oder einfach gesprochen: Man muss programmieren. Die Grenze überschreiten zum Beispiel nicht:

• Veränderungen von Daten;

• Programmaufrufe und externe Befehle, auch wenn sie in den Programmablauf eingreifen;

• Nichtaufrufen von Programmen.

Folgende Prüfungsschritte sind im Zusammenhang mit der Qualifizierung eines abgeleiteten Werkes zu empfehlen:

S. 99

328

Prüfung anhand formeller Kriterien: Hier lautet die Prüfungsfrage: Sind die eigenen Entwicklungen von den Open-Source-Code-Elementen separat abgrenzbar? Demnach unterliegen selbstständige Software-Module nicht dem Copyleft-Effekt, wenn sie als eigenständige Werke weitergegeben werden. Entscheidend ist dabei, dass die eigenen Module funktional unabhängig und formal abgrenzbar sind und keine strukturelle Einheit bilden. Wird dies bejaht, spricht dies gegen ein abgeleitetes Werk und somit gegen den Copyleft-Effekt.

329

Prüfung anhand kommerzieller Kriterien: Hier steht die Frage im Zentrum: Wie wird die Software nach außen auf dem Markt vertrieben? Eine „einheitliche“ Vermarktung spricht eher für ein „derived work“ und somit für den Copyleft-Effekt. Die Eigenständigkeit liegt gerade dann nicht vor, wenn die proprietäre Software mit der Open-Source-Software als „Teil eines Ganzen“ verbreitet wird.

330

Prüfung anhand funktioneller Kriterien: Hier lautet die Prüfungsfrage: Sind die einzelnen Elemente (gemeint Open-Source-Elemente einerseits und proprietäre Software andererseits) jeweils für sich eigenständig nutzbar? Eine technische Trennung kann dabei zu einer Eigenständigkeit beitragen. Wenn also die proprietäre Software ohne die Open-Source-Elemente nicht genutzt werden kann, spricht dies für ein abgeleitetes Werk und somit für den Copyleft-Effekt.

331

Formal selbstständiger Vertrieb, technische und inhaltlich-funktionale Eigenständigkeit sind also erst gemeinsam als hinreichende Bedingungen dafür anzusehen, dass die in Frage stehenden Softwarebestandteile nach unterschiedlichen Lizenzen verbreitet werden können. Fehlt es an einem der Kriterien, so greift die Copyleft-Klausel ein.

332

Vereinfacht wird danach gefragt, ob die Software (i) zu einem unentwirrbaren Konglomerat aus Einzelkomponenten verbunden wurde (dann Copyleft) oder (ii) Bestandteile isoliert nutz- und identifizierbar sind (dann kein Copyleft). In der Fachliteratur wird die Bewertung der Intensität des Copylefts teilweise im Wege einer „wertenden Gesamtbetrachtung“ gelöst.

333

Der Copyleft-Effekt wird demnach dann nicht greifen, wenn die identifizierbaren Teile des Werks nicht von dem der Open-Source-Software unterstehenden Programm abgeleitet sind und bei vernünftiger Betrachtung als unabhängige und selbstständige Werke einzustufen sind, sofern diese Teile als eigenständige Werke weiterverbreitet werden. Zur Vermeidung des viralen Effekts ist es daher erforderlich, dass die proprietäre Software unabhängig und formal von der Open-Source-Software abgegrenzt werden kann und sowohl Open-Source-Software als auch die proprietäre Software keine strukturelle Einheit bilden. Technisch wird diese Unabhängigkeit dadurch erzeugt, dass zwischen der proprietären Software und der Open-Source-Software keine statische, sondern S. 100lediglich eine dynamische Verlinkung erzeugt wird. Weitere technische Kriterien, wonach allgemein anerkannt sei, dass Systemaufrufe von den Anwendungsprogrammen gegenüber dem Kernel sowie Pipes, Queues, Sockets und Kommandozeilenargumente als übliche Kommunikationsmittel zwischen selbstständigen Programmbestandteilen anzusehen seien, also für einen eigenständigen und nicht-abgeleiteten Beitrag sprechen, sind im Einzelfall zu prüfen.