Über unsMediaKontaktImpressum
Yvonne Roßmann 21. November 2017

Open Source-Software: Rechtliche Risiken

Nicht Freibier, aber auch nicht unbegrenzte Freiheit

Die Nutzung von Open Source erfodert häufig juristische Anforderungen, die beachtet werden sollten. © Jenny Sturm / Fotolia.com
© Jenny Sturm / Fotolia.com

Ein bekanntes Zitat zu Open Source-/ Free-Software von Richard Stallman, einem der Mitbegründer der Idee von "Freier Software" lautet übersetzt "Frei wie in Redefreiheit, nicht wie in Freibier" [1]. Doch auch diese Freiheit, also die Zugänglichkeit und Verwendbarkeit der Software, ist nicht komplett frei. Der Artikel liefert eine praxisorientierte Antwort auf die Frage, warum ein Open Source-Prozess notwendig ist und wie er aussehen sollte, um sich möglichst wenigen rechtlichen Risiken bei der Verwendung von Open Source-Software auszusetzen.

Es klingt ganz einfach und unkompliziert: Open Source-Software ist mit zugänglichem Quellcode frei verfügbar. Sofern für eine benötigte Aufgabe eine Open Source-Software zur Verfügung steht, muss somit aus technischer Sicht kein eigener Aufwand mehr betrieben werden und die Software kann schnell und einfach eingebunden werden. Schnell und einfach? Jedenfalls auf den ersten Blick. Dabei darf jedoch nicht vergessen werden, dass aus juristischer Sicht regelmäßig noch Anforderungen zu erfüllen sind, um keinen Rechtsverstoß zu begehen.

"Frei verfügbar" bedeutet nämlich nur, dass die Software in der Regel ohne Lizenzgebühren und mit sehr umfangreichen Nutzungsrechten des zugänglichen Quellcodes zur Verfügung steht. Dennoch müssen Lizenzvorgaben der Open Source-Lizenz für eine rechtmäßige Nutzung eingehalten werden. Das ist kein Problem, wenn der Verwender die Open Source-Software ausschließlich selbst nutzt. Ein klassischer Fall ist die Installation des Open Source-basierten Mozilla Firefox oder Notepad++ auf einem Rechner. Diese Fälle sind unproblematisch, da Open Source-Lizenzen Vorgaben meist an eine Weitergabe der Software knüpfen und die einfache Nutzung ohne weiteres zulassen.

Open Source-Grundlagen:

  • Frei verfügbarer Quellcode [2]
  • Unter einer Open Source-Lizenz, z. B. GNU General Public License (GPL) oder MIT License [3]
  • Lizenz räumt dem Nutzer weitreichende Rechte ein, z. B. Bearbeitung oder Weitergabe
  • in der Regel ist die Ursprungsversion kostenlos verfügbar
  • Häufig weitere Lizenzbedingungen wie z. B. Urhebernennung
  • Teilweise mit "Copyleft", d. h. bei Weitergabe müssen Empfängern wiederum alle erhaltenen Rechte eingeräumt werden

Ein Open Source-Prozess ist daher besonders wichtig, wenn Open Source-Software in einem irgendwie gearteten Produkt verwendet wird. In solchen Fällen ist zum Beispiel eine Nennung des ursprünglichen Urhebers und der Lizenz der Software erforderlich, es kann jedoch auch so weit gehen, dass eigene Software ebenfalls unter der Open Source-Lizenz der verwendeten Open Source-Software verfügbar gemacht werden muss (so genanntes "Copyleft").

Lizenzverletzungen bedeuten ein rechtliches Risiko

Und um einen beliebten Einwand gleich vorweg zu nehmen: Rechtsverletzungen an Open Source-Software werden tatsächlich verfolgt und können mit Unterlassungsansprüchen und Forderungen nach Aufwendungsersatz teuer werden. In diesem Fall hat sich der schnelle, einfache und dadurch kostengünstige Einsatz der Software nicht gelohnt.

Ein Beispiel ist der Einsatz von Linux in einem Produkt. Heute ist es eine Selbstverständlichkeit, dass viele Produkte ein Betriebssystem benötigen, um die von den Kunden gewünschten "smart"-Funktionen erfüllen zu können. Das ist bei meinem neuen Geschirrspüler, bei Kühlschränken, Kameras, Fahrzeugen und natürlich auch jedem Mobiltelefon der Fall. Tatsächlich habe ich mit meinem Geschirrspüler auch einen Ausdruck von Open Source-Lizenzangaben erhalten und in meinem Handy gibt es eine Open Source-Liste. Ebenso haben Mandanten schon eine Abmahnung mit Ansprüchen auf Unterlassung und Aufwendungsersatz erhalten, die Ihren Produkten keine oder nur eine unvollständige Auflistung beigefügt haben.

Abb.1: Das sogenannte Copyleft fordert das Mitliefern von Source Code. © Yvonne Roßmann
Abb.1: Das sogenannte Copyleft fordert das Mitliefern von Source Code. © Yvonne Roßmann

Urheber auch einzelner Software-Bestandteile können solche Ansprüche geltend machen, wenn die Lizenzvorgaben vom Verwender ihrer Open Source-Software nicht eingehalten werden. Die Linux-Bestandteile stehen zu einem großen Teil unter der klassischen Open Source-Lizenz GPL (GNU General Public License).

Diese fordert unter anderem für den Fall einer Weitergabe zum Beispiel an Kunden in einem Produkt:

  • das Beifügen des Lizenztextes der GPL,
  • das Beifügen von Copyright-Vermerken,
  • die Zurverfügungstellung von Änderungen am ursprünglichen Code ebenfalls unter der GPL und
  • das Bereitstellen von hinzugefügtem eigenen Code unter der GPL, wenn ein so genanntes "derivative work" entstanden ist (Copyleft).

Deswegen muss ich also einen Ausdruck mit Lizenztexten, Copyright-Vermerken und einem Angebot zur Bereitstellung von Source Code mit meinem Geschirrspüler erhalten, wenn beispielsweise Linux mit Code unter der GPL in der Geschirrspüler-Software enthalten und dadurch mit dem Geschirrspüler an mich weitergegeben wird. Wird das versäumt, drohen aufwändige Ansprüche. Macht ein Rechteinhaber Unterlassung geltend, darf das Produkt mit dessen Code zukünftig nicht weiterverbreitet werden, ohne dass die Lizenzvorgaben eingehalten werden. Schadensersatzforderungen und Anwaltskosten stehen im Raum, häufig wird auch ein Rückruf und die Freigabe des hinzugefügten, regelmäßig proprietären Codes gefordert.

Für Linux-Bestandteile war Harald Welte von gpl-violations.org in Deutschland bereits an einigen Gerichtsverfahren beteiligt. Zum Beispiel gab es ein Verfahren von ihm als Urheber der netfilter-/iptables-Bestandteile unter der GPL gegen die FANTEC GmbH wegen eines Media Players, der diesen Code beinhaltet, ohne dass zu der Firmware auch der komplette korrespondierende Source Code bereitgestellt wurde. Dieser Verstoß wurde in einem "Hacking for Compliance-Workshop" festgestellt. Ihm geht es tatsächlich darum, dass die Bedingungen der GPL eingehalten werden und vor allem der verbundene oder veränderte Code in jedem Fall freigegeben werden muss.

Mit vergleichbaren Forderungen tritt Patrick McHardy an Unternehmen nach Testkäufen heran. Ihm wird vorgeworfen, mehr an einer finanziellen Lösung interessiert zu sein, als an der Durchsetzung der Lizenz; er wurde von dem Netfilter Core Development-Team suspendiert [4]. In einem Fall verlangte er eine Unterlassungserklärung, die für die Zukunft pauschal die Einhaltung aller Lizenzbedingungen der GPL einforderte, ohne sich lediglich auf konkrete Verstöße zu beziehen. Das macht die Compliance mit der Erklärung schwierig und Verstöße gegen sie, die hohe Vertragsstrafen auslösen können, wahrscheinlich. Daher ist im Umgang mit solchen Forderungen Vorsicht geboten. Wenn Open Source-Software eingesetzt wird, geht es in jedem Fall nicht ohne Einhaltung der Lizenzvorgaben. Das gilt nicht nur bei einer eigenen Verwendung in Produkten, es besteht auch eine Verantwortung beim Vertrieb von Produkten, die man selbst nur geliefert bekommen hat. 

Maßnahmen für einen rechtlich sicheren Einsatz von Open Source-Software

Die folgenden Schritte sind notwendig, um Open Source-Software lizenzgerecht einsetzen zu können und sich nicht solchen Ansprüchen und Forderungen auszusetzen:

  1. Technische Evaluation der eingesetzten Open Source-Software und zugrundeliegenden Lizenzen,
  2. Rechtliche Bewertung der Vorgaben der entsprechenden Lizenzen im Kontext mit dem Einsatz und
  3. Zusammenstellung verschiedener Endprodukte, die je nach Lizenzen verfügbar gemacht werden müssen.

Häufig versuchen gerade Unternehmen, über ein Modell mit Black- und Whitelists erlaubter und problematischer Lizenzen sicherzustellen, dass keine Rechtsverletzungen beim Umgang mit Open Source begangen werden. Aufgrund des Freigabe-Erfordernisses für eigenen verbundenen Code, müsste auf einer solchen Blacklist in jedem Fall die GPL stehen. Das bedeutet für die Mitarbeiter eines Unternehmens, dass keine einzige Software unter der GPL eingesetzt werden darf. Dies gilt selbst dann, wenn die konkrete Verwendung möglicherweise unproblematisch ist, weil zum Beispiel keine Weitergabe der Software in einem Produkt geplant ist, sondern die Software nur auf dem eigenen Server eingesetzt wird. Der Einsatz von Open Source-Software sollte daher differenzierter angegangen werden. Empfehlenswert ist ein Prozess, über welchen der Einsatz von Open Source gemeldet, gegebenenfalls verifiziert und analysiert wird. 

Technische Analyse – "Was ist drin?"

Abb.2: Scancode liefert eine Lizenzauflistung und zeigt auch Unterlizenzen. © Yvonne Roßmann
Abb.2: Scancode liefert eine Lizenzauflistung und zeigt auch Unterlizenzen. © Yvonne Roßmann

Es gibt verschiedene Herangehensweisen für die Erstellung und Analyse einer so genannten "Bill of Material". In jedem Fall sollte der Entwickler eine Auflistung vorliegen haben, aus der sich ergibt, welche Open Source-Software mit welchen möglichen Dependencies eingesetzt wird und unter welcher Open Source-Lizenz diese jeweils stehen. Alternativ oder im Idealfall parallel dazu empfiehlt sich eine Prüfung des Codes eines Projektes mit einer Scansoftware.

Ein guter Überblick über den eingesetzten Code lässt sich mit einem so genannten Header-Scan der Code Base, also des in das Produkt einfließenden Codes, erreichen. Um nicht unnötig Treffer zu generieren, die später überprüft und bewertet werden müssen, sollte der "Shipping Status" geklärt sein, das heißt die Code Base sollte nur die Files enthalten, die später in das entwickelte Produkt einfließen. Für diese Header-Scans gibt es Scan-Tools, die als Open Source verfügbar sind und somit nicht erworben werden müssen. Die bekanntesten sind FOSSology und Scancode [5], die beide zuverlässig Open Source-Informationen zu dem gescannten Code auflisten. Dabei wird zu den einzelnen Files die aus dem Header ersichtliche Lizenz zugeordnet.

Der Mehrwert der kommerziellen Scan-Tool-Anbieter besteht vor allem darin, dass auch so genannte "Snippets" bei der Suche identifiziert werden. Dabei handelt es sich um Code-Bestandteile von Open Source-Software, die nur aus einzelnen Zeilen oder Teilen von Files bestehen und daher keine Header-Informationen mehr zur Identifizierung aufweisen. Somit würden diese Treffer bei einem Header-Scan auch nicht gefunden. Die bekanntesten Anbieter kommerzieller Scan-Tools sind Black Duck und Palamida [6]. Diese scannen die übermittelte Code Base automatisiert auf Übereinstimmungen mit bekannter Open Source-Software, danach erfolgt manuell ein so genanntes Audit, in welchem die Treffer beurteilt und nicht relevante Hits aussortiert werden. Den gefundenen Open Source-Komponenten wird die bekannte Lizenz zugewiesen, der Kunde erhält eine Auflistung zur weiteren Auswertung.

Es ist wichtig, dass neben der so genannten Top-Level-Lizenz auch die Lizenzen von Unterfiles ermittelt werden. Die Top-Level-Lizenz ist die der Open Source-Software zugeordnete Lizenz, quasi eine Hauptlizenz. Stehen nicht sämtliche Files der Open Source-Software ohne Ausnahme unter eben der Lizenz, muss neben der Hauptlizenz auch jede weitere Lizenz solcher Unterfiles für die rechtliche Beurteilung berücksichtigt werden. Die Lizenzbedingungen müssen für jede enthaltene Lizenz eingehalten werden, die Hauptlizenz "konsumiert" nicht enthaltene Unterlizenzen auf, da der jeweilige Urheber des einzelnen Files die Lizenz frei festlegen kann. Die Angaben auf den Projektseiten von Open Source-Software zu Lizenzen beschränken sich regelmäßig auf die Hauptlizenzen, daher empfiehlt es sich, auch bei einer zuverlässigen Listung der eingesetzten Open Source-Software einen Header-Scan durchzuführen, um die implementierten Files auf abweichende Unterlizenzen zu überprüfen und auch diese zu listen. Diese Funktion soll auf Anforderung auch von den kommerziellen Tools umgesetzt werden können, standardmäßig wurden zuletzt nur Top-Level-Lizenzen gelistet.

Aus technischer Sicht müssen daneben noch weitere Informationen evaluiert werden, die für die rechtliche Beurteilung wichtig sind. Je nachdem welche Open Source-Lizenzen relevant sind, kann es erforderlich sein, genaue Informationen dazu auszuwerten, mit welchen anderen Komponenten die Software interagiert. Besonders interessant sind die so genannten statischen und dynamischen Verlinkungen zum Beispiel bei der LGPL (GNU Lesser General Public License). Ist die Open Source-Komponente hier zur Runtime noch eigenständig auf dem Filesystem identifizierbar und wird nur über eine Standardschnittstelle geladen, sodass der User sie theoretisch auch austauschen kann, muss der übrige Code trotz Copyleft der Lizenz zum Beispiel nicht als Open Source verfügbar gemacht werden.

Weiteres wichtiges Thema sind möglicherweise für das Produkt eingesetzte Sicherungsmaßnahmen wie signierte Bootloader. Manche Open Source-Lizenzen, wie zum Beispiel die GPL in der aktuellen Version 3, verbieten es, das System dergestalt unzugänglich zu machen. Derartige Informationen zu dem Produkt müssen also ebenfalls evaluiert werden. Gleiches gilt, wenn Dependencies von Komponenten erst im Kompiliervorgang gezogen werden und daher in der analysierten Code Base noch nicht enthalten waren. Teilweise fließen auch aus Compilern wiederum einzelne Files in das kompilierte Produkt ein. Sollte das der Fall sein, muss die Information für die rechtliche Bewertung vorliegen, damit auch für diese Files die Lizenzbedingungen eingehalten werden. Eine exakte Aufbereitung aus technischer Sicht ist somit zur Vorbereitung der rechtlichen Beurteilung unerlässlich.

Rechtliche Prüfung – "Darf es verwendet werden?"

Auf der Grundlage dieser Informationen muss dann der Einsatz der Open Source-Software rechtlich analysiert werden. Urheber- und Lizenznennungen lassen sich leicht identifizieren. Die Beurteilung des Copyleft-Effekts und die Prüfung auf das Entstehen eines "derivative work" durch Bearbeitung oder Verbindung der Open Source-Software ist aufwändiger. Ist Code betroffen, der proprietär ist, also von einem Unternehmen nicht veröffentlicht werden soll, ist das jedoch die zentrale Frage zum Schutz des eigenen Know-hows. Dabei kommt es darauf an, wie intensiv der Code bearbeitet oder miteinander verbunden wurde, also ob überhaupt schutzfähige Werkteile betroffen sind und ein Maß der Bearbeitung erreicht wurde, welches das gesamte Ergebnis und nicht nur die ursprüngliche Open Source-Software unter die ursprüngliche Open Source-Lizenz stellt.

Teilweise sind gerade der GPL Ausnahmetexte hinzugefügt, die eine Verbindung unter bestimmten Voraussetzungen gestatten, ohne dass das gesamte entstehende Ergebnis wiederum unter den Bedingungen der GPL verfügbar gemacht werden muss. Anhand der technisch vorbereiteten Informationen muss beurteilt werden, ob diese Ausnahme im Einzelfall eingehalten wird. Dies gilt ebenso für die Compliance mit Erfordernissen zu einer möglichen Austauschbarkeit der Open Source-Komponente durch den Nutzer eines Endproduktes, wie sie beispielsweise die GPL vorsieht und was nach dem Wortlaut auch für die LGPL erforderlich ist.

Anders als bei vielen Rechtsgebieten gibt es im Bereich Open Source nur wenig Gerichtsentscheidungen und Literatur, sodass viele der rechtlichen Probleme ausgelegt und in Risiko-Kategorien eingeteilt werden müssen. Dabei kann der Verwender sein Compliance-Level von einer vorsichtigen über eine konservative und eine liberale bis hin zu einer riskanten Auslegung festlegen, was sich sowohl auf den erforderlichen Aufwand zur Einhaltung der Lizenzbedingungen als auch auf der anderen Seite auf die Gefahr des Vorwurfs einer Rechtsverletzung auswirkt.

Ein Beispiel: Im Rahmen einer Android-App soll Open Source-Software unter der LGPL eingesetzt werden.

  • Die LGPL hat ein beschränktes Copyleft und ist somit keine komplett liberale Lizenz, sodass nach der vorsichtigen Auslegung auf eine Verwendung verzichtet werden sollte, was zu eigenem Programmieraufwand führt, wenn keine andere Open Source-Lösung existiert.
  • Nach der konservativen Auslegung fordert der Wortlaut der LGPL auch bei einer dynamischen Einbindung der Open Source nur zur Laufzeit und über Standardschnittstellen die Möglichkeit für den Nutzer der App, zumindest theoretisch die Open Source-Komponente austauschen zu können. Das ist bei Android-Apps aufgrund der technischen Ausgestaltung nur schwer umsetzbar, sodass auf den Einsatz verzichtet werden sollte, was wiederum zu eigenem Mehraufwand führen kann.
  • Die liberale Auslegung würde davon ausgehen, dass die Austauschbarkeit nach der LGPL nicht zwingendes Kriterium ist und die dynamische Einbindung genügen lassen. In diesem Fall müssten noch Pflichtangaben zu allen enthaltenen Files und ein Freigabe-Paket für die Open Source-Komponente zusammengestellt und mitgeliefert werden (s. u.).
  • Bei einer riskanten Auslegung wäre die Austauschbarkeit ebenfalls kein Thema und der Entwickler würde einfach einen Verweis auf die Verwendung der Open Source-Komponente und den Lizenztext der LGPL beifügen und auf die Zusammenstellung von exakten Materialien zu allen einzelnen Files verzichten.

Häufig wird derzeit in der Branche im Endeffekt eine riskante Auslegung betrieben. Man kann dies in vielen Apps sehen, die eine Auflistung enthaltener Open Source-Komponenten meist mit einem Hinweis auf die zugrundeliegende Lizenz und eine Verlinkung lösen, jedoch keine Detailangaben machen und teils nicht einmal die Lizenztexte direkt anzeigen.

Zusammenstellen der notwendigen Endprodukte – "Was benötige ich?"

Wie müsste aber nun das Material aussehen, wenn man die Verwendung der Open Source auch nach der konservativen oder zumindest liberalen Auslegung rechtmäßig gestalten will? Dafür muss der Verwender Pflichtangaben, ein Freigabe-Paket und gegebenenfalls eine Austauschanleitung zusammenstellen. Zusätzlich muss noch entschieden werden, wie diese Informationen dem Empfänger der Software bereitgestellt werden.

Das klingt erst einmal nicht besonders kompliziert. Betrachtet man jedoch die Vorgaben im Kontext dessen, was oben bereits erläutert wurde genauer, ist schnell ersichtlich, dass für diesen Schritt viel Aufwand entstehen kann. Besonders bei den so genannten Pflichtangaben sind Fehler schnell sichtbar und daher gut verfolgbar und nur im Rahmen einer riskanten Auslegung würde es genügen, lediglich die Bezeichnungen der eingesetzten Komponenten und der entsprechend diesen zuzuordnenden Top-Level-Lizenz anzugeben. Die Lizenzbedingungen geben bei fast allen Open Source-Lizenzen vor, dass der komplette Lizenztext samt Urhebernennung mitgeliefert werden muss. Wie schon oben erwähnt, muss bei einer nicht riskanten Auslegung dafür jede abweichende Unterlizenz von Files berücksichtigt werden. Zudem müssen bei konservativer Auslegung auch alle verschiedenen Copyright-Vermerke für Files unter der gleichen Lizenz zum Beispiel für die GPL oder LGPL angegeben werden. Es genügt nicht, lediglich einmal einen Verweis auf die Lizenz und den Lizenztext aufzunehmen.

Abb.3: Angaben zur Hauptlizenz im Source Code einer Open Source-Software. © Yvonne Roßmann
Abb.3: Angaben zur Hauptlizenz im Source Code einer Open Source-Software. © Yvonne Roßmann

Wenn das Ausmaß hiervon noch nicht kompliziert klingt, sollten wir an dieser Stelle noch einmal auf Linux zurückkommen. Linux besteht aus tausenden Files, von denen zunächst die Mehrzahl unter der GPL steht, wobei jedoch nicht in jedem Header der gleiche Copyright-Vermerk enthalten ist. Für diese Files müssten somit aus den Headern die verschiedenen Vermerke zusammengestellt werden. Dann würde dazu der Lizenztext der GPL gelistet. Danach würde geprüft werden, unter welchen weiteren Lizenzen Unterfiles stehen, wobei sich eine Vielzahl von Lizenzen ergibt, zum Beispiel unter der BSD-, MIT- oder Apache-Lizenz. Für alle diese Files müssten dann wiederum die nach den entsprechenden Lizenzen erforderlichen Pflichtangaben aufgenommen werden. Bei der MIT-Lizenz sind das beispielsweise der komplette Lizenztext mit dem darüberstehenden Copyright-Vermerk, bei der Apache-Lizenz der Lizenztext und der Inhalte eines NOTICE-Files, falls ein File mit einer solchen Bezeichnung im Code der ursprünglichen Open Source-Komponente enthalten ist. Hier wird der Umfang der notwendigen Arbeiten für ein so großes Paket wie Linux gut ersichtlich: es entstehen schnell tausende Seiten an Auflistung. Manuell lässt sich das nicht wirklich bewältigen, hier sind die Scan-Tools ein dringend benötigtes Hilfsmittel.

Soll diese Zusammenstellung dann auf Papier mitgeliefert werden, müsste im Falle meines Geschirrspülers mit Linux ein umfangreiches Handbuch beigelegt sein. Einfacher ist es, zum Beispiel ein Speichermedium mit den Angaben beizufügen oder gleich die Angaben in einem bestimmten Screen des Produkts anzeigen zu lassen, was die Standardlösung für Apps ist. Eine genaue Regelung zur Art der Bereitstellung findet sich in den meisten Lizenzen nicht. Das lapidare "along with the software", das in den Open Source-Lizenzen teilweise zu lesen ist, schließt jedoch vom Wortlaut das Einfügen eines Links unter dem die Angaben stehen aus.

Bei Lizenzen mit Copyleft muss außerdem bei einer Weitergabe in kompilierter Form auch der Source Code der Open Source-Komponenten oder sogar des eigenen hinzugefügten Codes unter der Open Source-Lizenz der Ursprungskomponente bereitgestellt werden. Hat der Entwickler Code der Open Source-Komponente bearbeitet, so muss dieser ebenfalls enthalten sein. Dabei ist unerheblich, ob der Empfänger des kompilierten Codes sich den Source Code zu den Open Source-Komponenten selbst einfacher im Internet beschaffen könnte. Für etwaige Anfragen sollte der Code vorhanden sein und auch ausgegeben werden. Nach den meisten Lizenzen ist es nicht erforderlich, einen Datenträger mit dem Source Code mit auszuliefern, es genügt ein so genanntes "written offer", dem Empfänger auf Anforderung das Material verfügbar zu machen. Dieses schriftliche Angebot kann in die Pflichtangaben mit aufgenommen werden. Für den Fall einer Komponente unter einer Open Source-Lizenz, die zumindest nach konservativer Austauschbarkeit fordert, wie beispielsweise der LGPL, kann es erforderlich sein, eine Austauschanleitung zusammenzustellen, die dem Nutzer diese theoretische Austauschmöglichkeit erläutert. 

Fazit

Für alle diese Arbeiten sollten im Projektverlauf genügend Zeit und Ressourcen eingeplant werden. Dies gilt gerade beim Erstellen eines Produktes, welches an Kunden vertrieben wird und somit auch leichter auf Rechtsverletzungen überprüfbar ist. Mit zunehmendem Compliance-Bewusstsein und steigender Verfolgungsdichte wachsen die Anforderungen an einen lizenzgerechten Open Source-Einsatz auch in Lieferketten.

Es ist dabei ungleich schwieriger, die Maßnahmen im Nachhinein zu treffen und die nötigen Materialien erst dann zusammenzustellen, als wenn gleich von Beginn an ein ordentlicher Open Source-Prozess aufgesetzt und eingehalten wurde. Unserer Erfahrung nach wird bei einem nachträglichen Scan einer Code Base immer etwas Unerwartetes gefunden. Wollen Sie dieses Risiko eingehen?

nach Oben
Autor

Yvonne Roßmann

Yvonne Roßmann ist seit 2011 Rechtsanwältin in der Kanzlei JunIT in Würzburg. Sie ist Fachanwältin für Informationstechnologierecht und spezialisiert auf das IT- und Wirtschaftsrecht.
>> Weiterlesen
botMessage_toctoc_comments_929