27.04.2022 - 08:48

Lösungen, um von Open-Source-Software profitieren zu können, und die entsprechend rechtssichere Anwendung

Gastbeitrag von Monika Menz, Rechtsanwältin, Fachanwältin für Informationstechnologierecht

Rechtsanwältin Monika Menz publiziert mehrere Gastbeiträge exklusiv auf intellicar.de, die sich des Themas Open-Source-Software in der Automobilindustrie widmen. Im zweiten Beitrag zeigt Frau Menz auf, wie man rechtssicher Open-Source-Software einsetzt und davon profitieren kann.

Open-Source-Software ist im Idealfall kostengünstig und effizient. Als Unternehmen, das oder für das Software entwickelt wird, können wertvolle Ressourcen geschont werden, wenn bereits schon gefundene Lösungen für bereits bekannte Aufgaben, ohne zur Zahlung von Lizenzgebühren verpflichtet zu sein, eingesetzt werden können. Aber der Einsatz von Open-Source-Software bzw. Open-Source-Software-Komponenten in Software bietet – wie wir bereits im ersten Teil dieser Reihe erläutert haben – auch einige rechtliche Fallstricke. Denn Open-Source-Software ist keinesfalls „gemeinfreie Software“. Vielmehr handelt es sich bei Open-Source-Software und ihren Komponenten um ebenfalls urheberrechtlich geschützte Computerprogramme, die im Quellcode mit einer kostenlosen Lizenz für jedermann zur Verfügung gestellt werden. Die übrigen Bedingungen dieser kostenlosen Lizenz für jedermann können jedoch frei vom bereitstellenden Urheber festgelegt werden.

Unterschiedliche Anforderungen je nach Open-Source-Lizenz

Es gibt also bei Open-Source-Software eine Unmenge an unterschiedlichen Lizenzen, die unterschiedliche Anforderungen an den jeweiligen Verwender richten. Es gibt etablierte und bekannte Open-Source-Lizenzen, die von den Softwareurhebern verwendet werden können, aber der Urheber kann seine Bedingungen auch völlig frei variieren. Das führt mitunter zu kuriosen Lizenzen.

Die etablierten Open-Source-Lizenzen kann man grob in zwei Kategorien einteilen. Die sogenannten Permissiven Lizenzen (oder „freizügigen Lizenzen“) und solche Lizenzen mit einem sogenannten Copyleft-Effekt. Permissive Lizenzen erlauben die Einbindungen des Codes in proprietäre Systeme, ohne dass dies Auswirkungen auf diese hätte. Lizenzen mit Copyleft-Effekt verlangen, dass Derivate (oder „abgeleitete Werke“) ebenfalls unter die für die Open-Source-Komponente relevante Lizenz gestellt werden müssen. D.h., dass auch für die Derivate eine kostenlose Lizenz für jedermann unter der verwendeten Lizenz zur Verfügung gestellt werden muss. Schlimmstenfalls kann dies dazu führen, dass ehemals proprietäre Software für jedermann kostenlos zur Verfügung gestellt werden muss – und jedermann schließt eben auch den Wettbewerber mit ein.

Weiter ist den Open-Source-Software-Lizenzen in der Regel gemein, dass die jeweilige Lizenz benannt und der Lizenztext wiedergegeben werden muss, und zwar in der richtigen Version und – wenn eine Wahlmöglichkeit bestand – entsprechend der getroffenen Wahl. Manche Lizenzen erlauben die kommerzielle Nutzung, andere schließen sie aus oder erlauben nur die indirekte kommerzielle Verwertung durch Services. Nicht jede Open-Source-Software-Lizenz ist mit anderen Lizenzen beliebig kompatibel.

Open-Source-Compliance

Werden die Bedingungen der Open-Source-Software-Lizenzen nicht eingehalten, kann es sich je nach Lizenz um eine Vertragsverletzung handeln oder wie im Fall der GPL 2.0 oder 3.0 kann die Verletzung der Lizenzbedingungen dazu führen, dass die Lizenzerteilung von Anfang an unwirksam war und somit die Urheberrechte des Open-Source-Software-Rechteinhabers verletzt werden. Rechtlich kann dies von einer Nacherfüllung und kleinem Schadensersatz bis hin zur Nutzungsuntersagung, Vernichtung von Produkten und zu großem Schadensersatz führen.

Um die unübersehbaren Vorteile von Open-Source-Software nutzen zu können, sollten die Risiken so weit wie möglich gesteuert werden. Das ist nicht nur im eigenen Interesse sinnvoll, sondern wird auch zunehmend in der Lieferkette in Auftragsvergaben z.B. in der Automobilindustrie verlangt.

Um die Risiken zu beherrschen, empfiehlt sich der Aufbau eines Open-Source-Compliance-Systems. Gerade im Hinblick auf die Vertrauensanforderungen in der Lieferkette hat das OpenChain Project der Linux Foundation einen Standard für ein Open-Source-Software-Compliance-Programm entwickelt: den OpenChain Standard. Der OpenChain Standard 2.0 wurde wortgleich in die DIN ISO/IEC 5230 überführt. Und um das Vertrauen in dieses Open-Source-Compliance-System zu steigern und auch Auftraggebern in der Lieferkette dieses Vertrauen glaubhaft vermitteln zu können, sollte das Open-Source-Compliance-System zertifiziert werden. Auch hier bieten sich zwei unterschiedliche Pfade an, die Open-Chain-Selbstzertifizierung durch das jeweilige Unternehmen oder eine Drittzertifizierung unter der DIN ISO/IEC 5230.
Elemente eines Open-Source-Compliance-Systems

Wie jedes Compliance-Management-System sollte auch ein Open-Source-Compliance-Management-System in die 4 Phasen des PDCA-Zyklus aufgeteilt werden. Planen, Durchführen, Ausführen (oder im Englischen: Plan, Do, Check, Act).

Plan

Auf der Planungsebene sollte die Gesamtheit der Richtlinien, Prozesse und Mitarbeiter, die für die Einhaltung der Open-Source-Lizenzbestimmungen einer Organisation zuständig sind, festgelegt werden. Beim Festlegen der Rollen und Verantwortlichkeiten ist nach dem Standard der OpenChain ISO/IEC 5230 darauf zu achten, dass die verantwortlichen Mitarbeiter nicht nur im Engineering Team zu finden sind, sondern auch Legal Team, Compliance Team und das Produkt-Team sind in den Hauptverantwortungskreis mit einzubeziehen.

Darüber hinaus muss der Status quo der Open-Source-Software-Verwendung im Unternehmen in dieser Phase geklärt werden, d.h., welche Komponenten wie unter welcher Lizenz wo verwendet werden. Während dies zwar durchaus auch im Rahmen einer manuellen Erhebung möglich ist, gibt es daneben zahlreiche Tools, die diesen Prozess stützen.

Do

Sind die Eckpfeiler des Open-Source-Software-Compliance-Systems festgelegt, müssen die dort festgelegten Richtlinien und Prozesse mit Leben gefüllt und im Unternehmen etabliert werden. Auch hierfür sind die Mitarbeiter des Lenkungskreises entsprechend der ihnen zugeteilten Rolle verantwortlich. Die Umsetzung der Anforderung kann wieder toolgestützt erfolgen, um die Arbeit zu automatisieren, muss aber nicht. Als Ergebnis des Compliance-Programms sollte eine Sammlung von Artefakten zu der Software, in der Open-Source-Komponenten verwendet werden, entstehen. Diese Artefakte liefern das Kernstück der Open-Source-Compliance, da diese die Informationen darstellen und enthalten, die eine Einhaltung der jeweiligen Open-Source-Lizenzvorgaben ermöglichen. Hierzu zählen unter anderem Listen von Open-Source-Komponenten und SPDX-Dokumente, Kopien von Lizenzen, Urheberrechtsvermerke, Änderungsmitteilungen etc.

Check

In diesem nächsten Zykluselement kann die Zertifizierung des Open-Source-Compliance-Programms erfolgen. Zunächst sollte evaluiert werden, ob die Umsetzungen den Anforderungen des Standards entsprechen, und gegebenenfalls nachgebessert werden. Entspricht das umgesetzte Open-Source-Compliance-Programm dem Standard der OpenChain ISO/IEC 5230, kann in einem nächsten Schritt die Zertifizierung erfolgen. Hier haben Unternehmen die Wahl: entweder durch eine Selbstzertifizierung der Open Chain Foundation mittels deren Webapp oder über eine Zertifizierung der DIN ISO/IEC 5230.

Act

Zu guter Letzt sollte immer beachtet werden, dass auch eine Open Source Compliance Zertifizierung nur eine Momentaufnahme ist. Um der Open Source Compliance wirklich gerecht zu werden ist eine regelmäßige Evaluierung und Bewertung des bestehenden und ggf. zertifizierten Systems erforderlich. Die Ergebnisse hieraus und mögliche Vorfälle sollten dann zu Anpassungen des Compliance Verfahrens führen. Beispiel hierfür könnten angepasste Freigabevorgaben aufgrund neuere Versionen Open Source Software Lizenzen sein. Ein Open Source Compliance System ist nur dann gut, wenn es lebendig und nicht statisch und iterativ an die sich ändernden Anforderungen anpasst.

Über die Autorin: Rechtsanwältin Monika Menz ist Salary Partner, Fachanwältin für Informationstechnologierecht und Co-Head Digital Business Unit bei reuschlaw. Darüber ist sie Lehrbeauftragte für IT-Recht am Hasso-Plattner-Institut sowie zertifizierte Datenschutzbeauftragte.

Autor: jst

– ANZEIGE –


Aktuelle Termine

Recht in der Automobil­zulieferindustrie 2022

Zum Termin

Future Mobility Summit

Zum Termin

Automechanika Frankfurt 2022

Zum Termin
Gefunden bei intellicar.de
https://intellicar.de/markets/loesungen-um-von-open-source-software-profitieren-zu-koennen-und-die-entsprechend-rechtssichere-anwendung/
27.04.2022 08:14