Rechtliche Fallstricke des Einsatzes von Open Source Software und freier Software – Hinweise für die Praxis

Als freie Softwarelizenzen sind alle Lizenzen zu betrachten, welche ohne Vergütung von ihren Urhebern zur Verfügung gestellt werden. Wird der Programmcode offen zur Verfügung und Bearbeitung gestellt, spricht man von „Open Source Software“ („OSS“ mit offenem Quellcode). In der Folge soll betrachtet werden, welche rechtlichen Fragen beim Einsatz freier Software zu beachten sind und welcher „Best-Practice“-Umgang sich mit den Lizenzen empfiehlt.

1.1 Grundsätze der Lizenzfreiheit

Urheber freier Software^{Footnote 1} können sich ihre Lizenz frei wählen. Sie können sich beispielsweise einer bestimmten, bereits existierenden Lizenz – wie etwa den Open Source Lizenzen, z. B. der noch zu behandelnden „General Public Licence“ („GPL“) – anschließen und diese für ihr Programm zur Anwendung bringen. Wie die Praxis zeigt, kann dies zu den kuriosesten Lizenzmodellen führen, wie etwa der Free-Beer^{Footnote 2}- oder Free-Chocolate^{Footnote 3}-Lizenzen.

Nach deutschem Recht sind diese Lizenzen zwar nicht immer mit den Prinzipen der Urheberrechts und den zugehörigen restriktiven Vorgaben für die klare Definition von Nutzungs- und Verwertungsrechten vereinbar^{Footnote 4}. Es existiert zum Bereich der freien Lizenzen leider noch nicht sehr viel Rechtsprechung^{Footnote 5}, es ist jedoch auch vor dem Hintergrund weniger Urteile anerkannt, dass durch den Download freier Software die Lizenzbedingungen des Urhebers rechtswirksam akzeptiert werden. Werden diese Bedingungen durch die Anwender nicht beachtet, kann dies zum Erlöschen der Nutzungs- und Verbreitungsberechtigung führen^{Footnote 6}. Die Einhaltung der Lizenzbedingungen stellt dementsprechend eine sogenannte „auflösende Bedingung“ des Vertrags nach § 158 Abs. 1 BGB dar^{Footnote 7}. Wird die Lizenzbedingung verletzt, verliert der Nutzer seine Berechtigung zur Verwendung der Software^{Footnote 8}.

1.2 Konsequenzen der Verletzung von Lizenzbedingungen

Die Verletzung von Lizenzrechten kann verschiedene Rechtsfolgen nach sich ziehen.

Zum einen führt dies zum bereits genannten Erlöschen der Lizenz, welches einen Anspruch des Urhebers auf Unterlassung der Nutzung der Software zur Folge hat^{Footnote 9}. Grundsätzlich erlischt jede Lizenz, wenn die Lizenzbedingungen – auch bei kostenloser Software – nicht erfüllt werden. Nutzt der Verletzer die Lizenz nur zu eigenen Zwecken, muss er die entsprechende Nutzung umgehend einstellen. Handelt es sich um ein unternehmenswichtiges Programm – oder den Teil eines solchen Programms bei Integration freier Software in eigene Systeme – kann dies entsprechend gravierende Konsequenzen zur Folge haben.

Zum Anderen kommen neben dem – auch im einstweiligen Rechtsschutz durchsetzbaren – Unterlassungsanspruch auch Schadensersatzansprüche für die Vergangenheit in Betracht^{Footnote 10}. Zur Aufklärung des Einsatzes und des Vertriebs der Software kann der Urheber außerdem Auskunftsansprüche geltend machen. Dies gilt auch dann, wenn die OSS lediglich zu Testzwecken in die eigene Software integriert wurde und keine produktive Funktion erfüllt^{Footnote 11}.

Besonders problematisch sind in der Praxis daher Fälle, in welchen die freie Software in eigene, proprietäre Software integriert wurde^{Footnote 12} und an diesem Gesamtprodukt Rechte an Partner und/oder Kunden vergeben wurde. Diese haben einen Nacherfüllungsanspruch nicht nur auf Freiheit der Software von Sachmängeln (wie Programmierfehlern), sondern auch auf Freiheit von Rechtsmängeln. Wird Software unter Verletzung von Rechten der Open Source Programmierer vom Softwarehersteller geliefert, handelt es sich um einen solchen Rechtsmangel. Der Kunde hat bei einer dauerhaften Überlassung der Software dann das Recht, Nacherfüllung nach § 439 BGB, das heißt den Nachkauf der Rechte zu verlangen. Anders als beim Schadensersatz für die Vergangenheit kann der Urheber jeden Preis dafür verlangen, dass er nachträglich Rechte zur Weiterübertragung einräumt. Außerdem kann er den Softwarehersteller durch Drohung mit der Durchsetzung von Unterlassungsansprüchen in eine problematische Lage bringen. In den letzten Jahren hat hier vor allem der Linux-Programmierer McHardy für Schlagzeilen gesorgt, indem er Unternehmen entsprechend auf Lizenzverstöße hingewiesen und Unterlassungsverfahren angestrengt hat^{Footnote 13}. Wird ein solcher Unterlassungsanspruch geltend gemacht, muss der Programmierer allerdings neben der Urheberrechtsfähigkeit seines Beitrags nachweisen, dass sein Programmieranteil (zu den meist in sukzessiver Kooperation zahlloser Programmierer entstandenen Open Source Software-Produkten wie Linux) bereits vom ursprünglichen Willen des ersten Urhebers vorausgedacht und umfasst war^{Footnote 14} und er somit als Miturheber für eine Klage aktivlegitimiert ist^{Footnote 15}.

Neben den zivilrechtlichen Ansprüchen ist für den Softwarehersteller außerdem zu beachten, dass ein Verstoß gegen Lizenzbedingungen bei einer Verbreitung der Software nach §§ 106, 108 UrhG strafbar sein kann.

Um einen Verstoß gegen die Lizenzbedingungen zu erkennen und zu vermeiden, sollte eine sogenannte „IP Due Diligence“, also die Rechteanalyse durchgeführt werden. Entscheidend sind die Analyse und der Vergleich ein- und ausgehender Rechte, je nach Vertriebsmodell (bis hin zum Blockchain-Einsatz^{Footnote 16}) und Rechtemanagement des Unternehmens und des Geschäftsmodells (Abb. 1).

Lizenzfluss bei softwareerstellenden Unternehmen

Full size image

Jedes an Vertriebspartner oder Endkunden (oder ggf. innerhalb einer Unternehmensgruppe) vergebene Recht muss durch die eingehenden Rechte gedeckt sein. Eingehende Rechte können von angestellten Programmierern stammen, welche diese Rechte nach § 69b UrhG gesetzlich an ihren Arbeitgeber übertragen. Stammen die Rechte von den Urhebern freier Lizenzen (durch Download der Software von entsprechenden Plattformen), muss geprüft werden, ob die Bedingungen der Lizenz für eine Weitergabe erfüllt worden sind. Zu keinem Zeitpunkt dürfen mehr Rechte herausgegeben werden, als das Unternehmen von den Urhebern erhalten hat, um die oben geschilderten Unterlassungsansprüche zu verhindern. Ansonsten liegt der Fall einer unbedingt zu vermeidenden Lizenzlücke vor („Mind the Gap“).

In der Praxis wird die rechtliche Qualitätssicherung bei der Verwendung freier Lizenzen immer noch nicht ausreichend beachtet^{Footnote 17}. Zwar sind zahlreiche Tools im Einsatz für die Vermeidung von Über- oder Unterlizenzierungen bei proprietären, also klassischen Kauf- oder Mietlizenzen. Bei freien Lizenzen fällt jedoch eine Standardisierung schwerer, da insbesondere bei Nicht-Open-Source-Lizenzen zahllose Lizenzmodelle existieren, welche eine Einzelfallprüfung erfordern.

Zentral beim Einbau fremder Software sind daher die Analyse und Beachtung der einzelnen Lizenz. Um festzustellen, ob und welche OSS in einer Software enthalten ist, empfehlen sich Scanprogramme wie Black Duck, Fossid, Palamida und White Source^{Footnote 18}.

3.1 Beispiel Open Source Lizenzen

Der Grundgedanke der Open Source-Software zeichnet sich durch die freie Bereitstellung des Quellcodes zur Weiterbearbeitung aus^{Footnote 19}. Bei Open Source gilt die Idee, dass jeder an einem Gemeinschaftswerk mitarbeiten kann, aber dafür als Lizenzbedingung auch das Ergebnis frei zur Verfügung stellen muss. Dies nennt man – als Gegensatz zum klassischen „Copyright“ bei „Verkaufssoftware“ – das „Copyleft“.

Open Source Lizenzen gliedern sich bei der Umsetzung des „Copyleft“ – Prinzips in drei verschiedenen Grade: Strengem Copy-Left, beschränktem Copy-Left und Lizenzen ohne Copyleft (Abb. 2).

Basismodelle der Open Source Lizenzen

Full size image

In den Basisformen der jeweiligen Lizenzmodelle bedeutet dies für die Integration der freie Software Folgendes:

3.1.1 Strenges Copyleft

Jeder, der Software unter einer solchen strengen Lizenz (Rot) mit einer eigenen Software (grün) kombiniert und verbreitet, muss das Gesamtergebnis unter der strengen Lizenz weitergeben (und den Quellcode veröffentlichen) (Abb. 3).

Strenges Copyleft: Integration großer OSS-Anteile

Full size image

Allerdings gibt es keine klare Regelung^{Footnote 20} welche etwa besagt, wieviel Prozent „OSS“ diesen viralen Effekt erzeugt, es kann daher auch ein kleiner „Schnipsel“ OSS dazu führen, dass der überwiegend eigene selbstprogrammierte Anteil unter die strenge Copyleft-Lizenz gestellt werden muss^{Footnote 21}. Die Ziffer 2 b) GPL V 2 regelt dies wie folgt: „You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.“ Demnach ist zu klären, ob ein aus der OSS „abgeleitetes Werk“ vorliegt (in der GPL v 3 lautet die entsprechende „virale“ Bestimmung in Ziffer 5 c) Abs. 2 als „work based on the earlier work“.) (Abb. 4).

Strenges Copyleft: Integration kleiner OSS-Anteile

Full size image

Die Abgrenzung zwischen einer unzulässigen bzw. zu einem viralen Effekt führenden Kombination eigener Software mit GPL-OSS und einer zulässigen Verbindung beider Programme kann in der Praxis sehr problematisch sein. So sind Tools auf Basis von der GPL unterstelltem Linux-Betriebssystems in der Regel ohne viralen Effekt zulässig; ebenso werden Contentmanagementsysteme auf Basis von OSS in aller Regel zulässig sein^{Footnote 22}. Die Entwicklung von Treibern für Linux kann dagegen zum viralen Effekt führen, wenn zu eine enge Interoperabilität der Programm vorliegt^{Footnote 23}.

Der virale Effekt tritt nur bei einer Verbreitung der OSS ein. Der Begriff der Verbreitung ist jedoch nach deutschem Recht schwierig zu definieren^{Footnote 24}. Bei bestimmten Lizenzen besteht die Gefahr, dass die Weitergabe innerhalb einer Unternehmensgruppe bereits den viralen Effekt auslöst^{Footnote 25}. Vielfach wird daher überlegt, OSS als Bestandteil der eigenen Software zu nutzen, ohne sie formal zu „verbreiten“. Dennoch kann in der Praxis der Versuch scheitern, die OSS nicht gemeinsam mit der eigenen Software zu verbreiten, sondern sie etwa als Systemumgebung zu definieren, welche der Kunde selbst stellen muss^{Footnote 26}. Wird die eigene Software nach der Installation beim Kunden so eng mit der (als Systemumgebung definierten) OSS zusammen funktionieren, dass ein gemeinsames Werk vorliegt, kann trotz des getrennten Verbreitungswegs der virale Effekt eintreten. Das LG Berlin hat die entsprechende Verbindung von OSS und eigener Software wie folgt als „Sammelwerk“ beschrieben:

„Die Infizierung eines Sammelwerks insgesamt bei Verwendung von Open-Source-Software in einzelnen Teilen eines Sammelwerks begegnet keinen Bedenken, da das Sammelwerk eine einheitliche Funktionalität aufweist und maßgeblich von den Open-Source-Bestandteilen abhängt“.^{Footnote 27}

Liegt der virale Effekt vor, führt dies zu einem Unterlassungsanspruch gegenüber der gemeinsamen Verbreitung der OSS mit eigener Software des Herstellers zu dessen Lizenzbedingungen, da der Hersteller für das Gesamtprodukt die virale Open Source Lizenz hätte verwenden und den Quellcode offenlegen müssen^{Footnote 28}.

Das Erlöschen der Lizenz aufgrund dieses Verstoßes hat nach deutschem Lizenzrecht nicht nur ein Erlöschen der Lizenz gegenüber dem Softwarehersteller, sondern auch gegenüber dessen Kunden zur Folge. Anders als bei der Verbreitung von gegenständlichem Eigentum existiert kein „gutgläubiger Rechteerwerb“, welcher die Nutzung durch den Endkunden gestattet, wenn dieser nicht von der Lizenzverletzung wusste oder wissen musste. Wurde die OSS falsch integriert und damit der virale Effekt ausgelöst, kommt jedoch bei manchen Lizenzen eine „Heilung“ durch eine nachholende Lizenzierung des Endnutzers in Betracht^{Footnote 29}, so etwa nach Art. 4 der GPL V 2 (Abb. 5).

Strenges Copyleft: Heilung der Lizenzverstöße

Full size image

Ergänzt wird dieser Absatz der GPL V 2 durch das sogenannte „Linux Kernel Enforcement Statement“ der Linux-Entwicklergemeinschaft:

„Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.“

Ob diese Heilung durch den Endkunden jedoch tatsächlich durchgreift und welche Voraussetzungen dafür im Einzelnen erforderlich sind, ist umstritten^{Footnote 30}. Unabhängig von der Heilungsmöglichkeit hat der Erwerber der Software gegen den Lieferanten jedoch einen Anspruch auf die Stellung einer lizenzgemäßen Software – einschließlich rechtmäßig integrierter Open Source Software.

3.1.2 Beschränktes Copyleft

Weniger gravierende Einschänkungen enthalten Lizenzen mit dem sogenannten „beschränkten Copyleft“, etwa der „LGPL“-Lizenz („Lesser General Public License“). Nach dieser Lizenz darf die freie Software nur als Programm-Bibliothek^{Footnote 31} genutzt und nur in einer bestimmten Weise (dynamisch, nicht statisch, siehe Abb. 6) mit dem eigenen ausführbaren Programm kombiniert werden.

Beschränktes Copyleft: Integrationsvorgaben

Full size image

Danach ist es von entscheidender Bedeutung, dass das unter der LGPL stehende Programm „sichtbar“ in einem Bibliotheksordner gespeichert ist die entsprechende Verlinkung zwischen dem eigenen ausführbaren Programm und der Bibliothek mit der OSS-Software auf die Einhaltung der Lizenzvorgaben geprüft wird.

3.1.3 Kein Copyleft

Die am wenigstens restriktiven OSS-Lizenzen sind diejenigen ohne den Copyleft-Effekt, wie etwa die „Berkeley Software Distribution (‚BSD‘) License“ oder der „Apache License“. Diese Lizenzen sind somit „nicht viral“, dennoch sind sie – wie bei Freeware-Lizenzen – nur unter Beachtung der enthaltenen Hinweise zu verwenden (Abb. 7).

Kein Copyleft

Full size image

Ebenso wie bei Freeware-Lizenzen (s. unten) ist hier trotz der vermeintlich „liberalen“ Lizenzen zu beachten, dass auch Lizenzhinweise wie die Aushändigung von Lizenztexten an die Endkunden oder die Information über Haftungsausschlüsse oder Lizenzbedingungen penibel eingehalten werden müssen^{Footnote 32}.

3.2 Weitere Lizenzarten, Interkompatibilität

Neben der Aufteilung nach den Copyleft-Arten im Bereich der Open Source Software können freie Lizenzen auch noch nach weiteren Merkmalen unterschieden werden^{Footnote 33}. Es gibt freie Lizenzen, bei denen der Nutzer die Wahl hat, verschiedene Versionen der Lizenz, insbesondere spätere Versionen („any later“) zu benutzen. Da die jeweiligen Versionen teilweise große Unterschiede im Hinblick auf die Einsatzmöglichkeiten und eventuelle Vergütungsmöglichkeiten beinhalten (so etwa GPL V 2 und GPL V 3^{Footnote 34}) ist genau auf die Auswahl der jeweiligen Version zu achten. Nicht zulässig ist dagegen eine Auswahl einer Lizenzart durch den Nutzer, so etwa ein willkürlicher Wechsel von der durch den Urheber gewählten GPL zu der liberalen LGPL^{Footnote 35}.

Insbesondere strenge Copyleftlizenzen können Bedingungen enthalten, welche mit dem Einsatz anderer Lizenzen inkompatibel sind. Daher muss beim Einsatz mehrerer OSS-Bestandteile auch auf die Vereinbarkeit der zu integrierenden Lizenzmodelle geachtet werden, dies wiederum kann etwa dazu führen, dass bestimmte Versionen von OSS-Lizenzen, wie etwa die GPL V 3 zu wählen sind, die besser mit anderen Lizenzen kompatibel sind^{Footnote 36}.

Last not least gibt es Lizenzen, die eher für den Cloud-Einsatz von ihren Urhebern gedacht sind^{Footnote 37} und die entsprechenden Einsatzkonstellationen abdecken, auch hier sind die unterschiedlichen Nutzungsmöglichkeiten zu bedenken.

3.3 Dual Licensing

Denkbar sind auch – etwa unter der (für Cloud-Einsatz geeigneten) AGPL V 3-Lizenz – duale Lizenzen, also die zusätzliche Freigabe des Programmcodes unter einer Open Source-Lizenz neben der Veröffentlichung unter einer eigenen „Kauflizenz“. Es entstehen damit zwei unterschiedliche „Lizenzschienen“ der Software. Hierbei darf jedoch keine ungeprüfte Reintegration (also Wiedereingliederung in den proprietären, eigenen Quellcode) der unter OSS erfolgten Weiterentwicklungen durchgeführt werden (Abb. 8).

Dual Licensing

Full size image

Dual Licensing bietet auch den Vorteil, dass bei Lizenzverletzungen durch Dritte Schadensersatz für die Vergangenheit verlangt werden kann^{Footnote 38}.

Freeware-Lizenzen ohne offenen Quellcode erlauben grundsätzlich eine Weitergabe ohne den viralen Effekt der strengen Open Source-Lizenzen. Dennoch sind die Freeware-Lizenzbedingungen ebenso strikt zu beachten wie etwa diejenigen der Open Source-Lizenzen ohne Copyleft. Auch hier gilt, dass die Verletzung der Lizenzbedingungen zu einem Entfallen der Nutzungsberechtigung führt, sei es bei der eigenen Nutzung der Software oder bei der Integration in ein eigenes Produkt.

Auch wenn die Freeware-Lizenz kostenlos ist und nur eine einzige Bedingung enthält, wie etwa eine Registrierung oder eine Danksagung oder die Weitergabe des Lizenztextes in schriftlicher Form, hat die Nichtbeachtung wiederum das Nichtbestehen der Lizenz mit den oben geschilderten Konsequenzen zur Folge. Auch hier kann es daher neben Schadensersatzforderungen zu einem Unterlassungsanspruch durch den Urheber der Freeware kommen, der insbesondere bei der Integration in ein Produkt zu dem gefürchteten „Nachkaufzwang“ führen kann^{Footnote 39}.

Auch bei Freeware ist somit jede Voraussetzung in der Lizenz unbedingt zu lesen und zu erfüllen, wenn man die Software verwenden und insbesondere in ein eigenes Produkt integrieren und vertreiben möchte:

Ein Beispiel ist die wie folgt lautende „Picture-postcard-with-nice-stamp-Lizenz“^{Footnote 40}:

„Copyright (C) 1997–2006 by François PIETTE Rue de Grady 24, 4053 Embourg, Belgium francois.piette@overbyte.be Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented, you must not claim that you wrote the original software. (…) 4. You must register this software by sending a picture postcard to the author. Use a nice stamp and mention anything you like to say.“

Es muss daher in der Praxis die Einhaltung der Lizenzvorgaben dokumentiert werden. Dies kann hier durch ein Einwurfeinschreiben mit einer Bildpostkarte mit einer „netten“ Briefmarke geschehen (als Briefmarkenmotiv sollten beispielsweise Sonderbriefmarken verwendet werden, wie etwa Marken zu besonderen Anlässen, Marken mit freundlichen Motiven). Das Einschreiben wäre hier dann an François Piette Rue de Grady 24, 4053 Embourg, Belgium zu senden und ein Scan der Postkarte (beidseitig) mit Einschreibebeleg zu archivieren, um die Lizenzberechtigung nachweisen zu können.

Da in der Praxis Freeware regelmäßig nicht nach der Geeignetheit der Lizenz, sondern der Geeignetheit der lizenzierten Software ausgesucht wird, kann es passieren, dass solch kuriose Lizenzen (wie auch etwa die Chocolateware-Lizenz^{Footnote 41}) eingehalten und dokumentiert werden müssen.

Auch bei den „liberalsten“ Lizenzen, wie Freeware-Lizenzen oder Open Source-Lizenzen ohne Copyleft ist nicht jeder Einsatz möglich, selbst wenn sie keinerlei Lizenzbedingungen, also nicht einmal Urheberhinweispflichten oder Haftungsausschlüsse^{Footnote 42} enthalten. Die Urheber der Freeware räumen dem Nutzer nie Exklusivrechte, also ausschließliche Nutzungsrechte ein. Daher können auch nie Exklusivrechte an einer Gesamtsoftware, welche Freeware enthält, eingeräumt werden. Es können nur Exklusivrechte an der eigenen Software eingeräumt und einfache Rechte an der Freeware weitergegeben werden. Dementsprechend muss unbedingt bei der Integration solcher Lizenzen in zu vertreibende eigene Software bei der Nutzungsrechtsübertragung an Dritte differenziert werden zwischen der eigenen Exklusivlizenz und der nicht ausschließlichen Freeware-Lizenz (Abb. 9).

Integration von Freeware

Full size image

Zur Freeware (bzw. Shareware) gehören auch etliche Entwicklungswerkzeuge, welche für die Programmierung eingesetzt werden können. Auch hier ist die Lizenz penibel einzuhalten. Zwar wird in aller Regel nicht davon auszugehen sein, dass der Urheber des Entwicklungswerkzeugs Rechte an den mit dem Werkzeug erzeugten Arbeitsergebnissen postulieren kann (dies wird allenfalls bei komplexen Grafikerzeugnissen der Fall sein). Werden solche Werkzeuge aber unter der falschen Lizenz eingesetzt, kann die damit erstellte Software nicht benutzt werden. Dies gilt beispielsweise für die Nutzung der Shareware-Version eines Werkzeugs, welche nur für nichtkommerzielle Einsatzzwecke freigegeben ist. Sollten also unternehmenseigene Entwickler statt des vom Unternehmen lizenzierten Entwicklungswerkzeugs ihr eigenes „Lieblingswerkzeug“ einsetzen, kann dies ebenfalls zu Unterlassungsansprüchen (auch gegenüber den Kunden des Unternehmens) führen.

Grundsätzlich sollten die Lizenzbedingungen ernst genommen und akribisch umgesetzt werden, dies gilt sowohl für die Art der Nutzung, die mögliche Registrierung der Software oder die Verbindung der Software mit eigenen Programmen.

6.1 Nutzer/Endkunde

Als Nutzer der Software sollte bei relevanten Softwaresystemen geprüft werden, ob bei einem Bezug der Software von einem Hersteller zusammen mit dessen eigenen Programmteilen die Vorgaben der Lizenzen eingehalten worden sind. Im Zweifel sollte eine Zusicherung der Einhaltung der Lizenzvorgaben der freien Software verlangt werden.

Insbesondere wenn die freien Softwarebestandteile zwar nicht durch den Hersteller des Gesamtprodukts geliefert werden, sondern dieser die freien Softwarebestandteile als Systemsoftware ausweist, welche der Nutzer selbst installieren soll, ist Vorsicht geboten. Hier sollte abgeklärt werden, ob die freien Softwareanteile unter einer viralen Lizenz stehen und möglicherweise aufgrund engen Zusammenwirkens mit den eigenen Anteilen des Herstellers „infektiös“ wirken könnten.

Der Lizenzvertrag des Herstellers sollte typischerweise auf die Lizenzbedingungen der freien Softwareanteile hinweisen und/oder entsprechende Drittlizenzbedingungen weitergeben. Dies kann nur dann entbehrlich sein, wenn gesichert ist, dass keine solchen Softwareanteile implementiert wurden (was jedoch in der Praxis untypisch wäre).

Handelt es sich bei dem Nutzer um eine Unternehmensgruppe, sollte die Integration der freien Softwareanteile in eigene Systeme durch unternehmensinterne Entwicklungsgesellschaften erfolgen. Diese wären dann von den nutzenden Mitgliedern der Unternehmensgruppe mit der Entwicklung (wie ein externer Auftragnehmer) zu beauftragen werden („verlängerter Arm des Integrators“). Aufgrund der ungewissen Rechtslage sollte im Zweifel vermieden werden, dass – unabhängig von der Weitergabe in der Gruppe – die an eine Verbreitung angeknüpften Lizenzpflichten ausgelöst werden. Verbreitete Methoden zur Vermeidung des viralen Effekts bei der Weitergabe wären etwa die formale Trennung von OSS und proprietären Komponenten, je nach Lizenz.

6.2 Softwarehersteller

Für Softwarehersteller empfiehlt es sich, die eigenen Lieferanten proprietärer Software (welche typischerweise OSS in nicht geringem Umfang^{Footnote 43} integriert hat) der gleichen Prüfung zu unterziehen wie unter 6.1 dargestellt. Grundsätzlich sollte bei der Integration freier Software der Einsatz viraler Lizenzen soweit möglich aufgrund der damit verbundenen Rechtsunsicherheiten vermieden werden, soweit nicht bewusst die Freilegung des Quellcodes bei der Weitergabe akzeptiert werden soll. Ist dies nicht möglich, ist zu prüfen, ob der Begriff der Verbreitung dadurch vermieden werden kann, dass der Endkunde gebeten wird, die freien Softwareanteile selbst zu installieren. Diese „Abmilderung“ des Vertriebs der freien Anteile wird jedoch (s. oben) dann keine ausreichende Sicherheit bieten, wenn die freien Anteile auf den Systemen des Kunden mit den Anteilen des Herstellers im Sinne des Sammelwerks eine gemeinsame Funktionalität ausüben, die wesentlich auf den freien Anteilen beruht. Daneben ist auch zu prüfen, ob beim Einsatz mehrerer freier Softwareanteile, die unter verschiedenen Lizenzen stehen, diese – insbesondere beim strengen Copyleft – miteinander kompatibel sind.

Im Entwicklungs- und Vertriebsprozess ist neben der technischen Qualitätssicherung auch auf eine fortlaufende rechtliche Qualitätssicherung zu achten: Erforderlich ist eine strukturierte Prüfung der integrierten freien Software auf die Einhaltung der Lizenzvorgaben und die Kompatibilität der Lizenzen untereinander. Hierzu sollte eine Unterstützung der Entwicklungsabteilung durch Schulungen und Unterlagen über Standards der OSS-Integration erfolgen. Bei der Einhaltung der Lizenzvorgaben zur Lieferung von Texten und Urheberhinweisen helfen Programme wie Fossology^{Footnote 44} oder Scancode^{Footnote 45}, die Ergebnisse zum Codescan sollten in einem OSS-Lizenzverwaltungssystem dokumentiert werden^{Footnote 46}.

Stellt man nach einer initialen Prüfung eine Lizenzverletzung fest, ist zu klären, ob und in welcher Form diese – etwa durch Ersetzen der freien Software ausgeräumt werden kann. Hilfreich ist es, wenn beim Einsatz von Vertriebspartnern die Vertragshändlerverträge eine gewisse Flexibilität zur Ersetzung von Softwareanteilen aufweisen, um nicht einem Nacherfüllungsanspruch und dem gefürchteten Zwang zum Nacherwerb der Lizenzen zu ungewissem Preis ausgesetzt zu sein.

Leilinien für die unternehmensinterne OSS-Compliance finden sich beim „Open Chain Project“/(https://www.openchainproject.org/), so etwa zu Supply Chain-Fragen des OSS Einsatzes im Dokument „Open Source Software License Compliance General Public Guide“^{Footnote 47}.

Werden diese Maßnahmen beachtet, sind die rechtliche Grundprobleme beim Einsatz von OSS beherrschbar, auch wenn sich zahlreiche formale Aufgaben bei der Weitergabe von Urhebervermerken, Lizenztexten, Ausschlussklauseln und anderen Informationen stellen, die sowohl Vertriebsdokumente als auch den Quellcode selbst betreffen können^{Footnote 48}.

Im Übrigen sollte keine Angst vor dem Einsatz von OSS auch unter strengen Lizenzen bestehen (soweit diese untereinander kompatibel sind), wenn das Geschäftsmodell des Unternehmens nicht von der Vergütung des Gesamtprodukts abhängt. Dies kann etwa bei Software der Fall sein, die als solche kein relevantes Know-How enthält und lediglich als Umgebung für zu lizenzierende Inhalte genutzt wird oder bei Software, die nur zum Betrieb von zu vertreibender Hardware in „embedded systems“^{Footnote 49} dient. Es ist also abschließend auch zu überlegen, ob die Zurverfügungstellung eines Produkts mit offenem Quellcode überhaupt als Problem gesehen werden muss. Es bleibt zu hoffen, dass die Bemühungen der OSS-Community, die offenen Rechtsfragen durch neue, einfacher anzuwendende Regelungen zu klären und den Einsatz der OSS zu erleichtern^{Footnote 50}, in der Zukunft noch stärker ihre Niederschlag in neuen Lizenzen finden.