Wie SPDX bei der Compliance-Prüfung von OSS-Lizenzen hilft

Die Etablierung eines professionellen OSS-Lizenz- und Compliance-Management (kurz OSS-LCM) ist für Unternehmen, deren Geschäftsmodell auf Erstellung und/oder Vertrieb von Software (-komponenten) basiert, mittlerweile unerlässlich geworden (zu den rechtlichen Risiken siehe etwa "Open-Source-Einsatz und die rechtlichen Risiken"). Das gilt auch für Systemhäuser, die "nur" Software etablierter Hersteller anpassen, oder für Konzerne, in denen Software intern verteilt wird.

Das OSS-LCM erfordert technische und rechtliche Expertise bei den zuständigen Personen verbunden mit einer spezifischen technischen und organisatorischen Infrastruktur im Unternehmen. Andernfalls können infolge möglicher Lizenzverstöße, etwa bei Missachtung einer sogenannten Copyleft-Klausel, aber auch bei sonstigen Verletzungen von zum Beispiel rein formellen Wiedergabepflichten, erhebliche Haftungsfolgen (unter anderem Unterlassungs- und Schadensersatzansprüche) auf den unberechtigten Verwender von OSS-Komponenten zukommen. Auch der weithin unterschätzten Problematik um etwaige Lizenzinkompatibilitätenim Falle der Verwendung verschiedener OSS-Komponenten kann durch entsprechende Compliance-Maßnahmen begegnet werden.

Der 3-Stufen-Test

Ein großes Risiko sind unerkannte OSS-Komponenten. Daher ist es auf der ersten Stufe wichtig, überhaupt identifizieren zu können, wo OSS enthalten ist und welche Komponenten dies betrifft.

Auf der zweiten Stufe sollte verifizierbar zugeordnet werden (können), unter welchen konkreten Lizenzbedingungen die jeweiligen OSS-Komponenten stehen.

Sodann ist auf der dritten Stufe zu prüfen, ob und wie die Lizenzbedingungen der in Betracht kommenden OSS-Komponenten bei der geplanten Nutzung eingehalten werden können. Besonders hervorzuheben sind hier die Offenlegungs- und Hinweispflichten, aber auch die sogenannte Lizenzkompatibilität. Das kann unter anderem davon abhängen, wie die OSS-Komponenten zum Beispiel mit proprietärem Code oder mit anderen OSS-Komponenten verbunden (verlinkt) sind oder wie sie weitergegeben beziehungsweise vertrieben werden (zum Beispiel in getrennten Dateien et cetera).

Während auf der dritten Stufe regelmäßig eine juristische Einzelfallprüfung erforderlich sein wird, drehen sich die Stufen eins und zwei vor allem um die (forensische) Code-Analyse, die durch technische Tools unterstützt werden kann.

Deutsche Gerichte gehen von erweiterten Prüfungspflichten aus

Die Einhaltung der lizenzrechtlichen Prüfpflichtenin dem oben vorgestellten Stufenmodell ist wichtig und sollte dokumentiert werden, denn die Rechtsprechung stellt hohe Compliance-Anforderungen an Unternehmen, die OSS-Komponenten (mit) vertreiben.

Das Landgericht Hamburg hat in einem vielbeachteten (aber durchaus umstrittenen) Urteil vom 14.06.2013 zulasten einer beklagten Software-Händlerin festgestellt: "Sie durfte sich […] nicht auf die Zusicherung ihrer Lieferanten verlassen, dass die gelieferte Ware keine Rechte Dritter verletzt. Jedenfalls hätte die Beklagte durch eigene Begutachtung oder unter Zuhilfenahme von sachkundigen Dritten eine Überprüfung der von ihr angebotenen und bereitgehaltenen Software in geeigneter Weise durchführen oder veranlassen müssen, auch wenn das mit zusätzlichen Kosten verbunden ist."

Im konkreten Fall hatte der chinesische Software-Sublieferant gegenüber dem Hauptlieferanten versichert, dass der gelieferte Code keine OSS-Komponenten enthält, was sich im Nachhinein als falsch herausstellte. Das Gericht verurteilte den Hauptlieferanten zu Unterlassung und Schadensersatz; auch die Verfahrenskosten musste er zahlen.

Auch das Landgericht Bochum hat in einem Urteil vom 03.03.2016 – Az. I-8 O 294/15 – die Notwendigkeit der Einhaltung von OSS-Lizenzbedingungen hervorgehoben: "Erforderlich ist danach insbesondere, dass auf die GPL [die Lizenzbedingungen] hingewiesen, der Lizenztext der GPL beigefügt und der Quellcode zugänglich gemacht wird (Ziffern 1 und 3 der GPL). Die Beklagte hat unstreitig diese Bedingungen der GPL nicht eingehalten. Ziffer 4 der GPL bestimmt, dass ein Lizenzverstoß automatisch zu einem Erlöschen der Lizenzrechte führt, so dass eine unberechtigte Nutzung durch die Beklagte vorliegt. Die Beklagte hat die Urheberrechtsverletzung auch zu vertreten, denn sie hat zumindest fahrlässig gehandelt." Die Berufung der Beklagten ist derzeit vor dem Oberlandesgericht Hamm anhängig.

Die Herausforderung, vor der alle Unternehmen stehen, deren Vertriebsmodell auf der Verbreitung von OSS-Komponenten basiert beziehungsweise basieren könnte, lautet deshalb: Wie kann durchCompliance-Maßnahmen ein Höchstmaß an lizenzrechtlicher Verlässlichkeit erreicht werden, ohne dass die Kosten für diese Überprüfung den Rahmen der Wirtschaftlichkeit übersteigen? OSS-Komponenten spielen inzwischen in fast allen Software-Bereichen (von Embedded Software in Fahrzeugen und Hausgeräten bis zu ERP-Software und Webshop-Lösungen) eine unverzichtbare Rolle für KMUs bis zu DAX-Konzernen, sodass die Investitionen in OSS-LCM steigen (müssen).

Was bei der Beschaffung von Software zu beachten ist

Bei Beschaffung von Fremdsoftware (-komponenten) durch externe Lieferanten ist es üblich, dass der Erwerber – sofern er genügend Verhandlungsmacht hat – in die vertragliche Vereinbarung eine Regelung aufnimmt, wonach der Lieferant den Erwerber von etwaigen Ansprüchen Dritter aufgrund lizenzrechtlicher Verstöße freistellt. Zunehmend wird geregelt, dass der Lieferant zusichert, dass die gelieferte Software keine OSS enthält.

Solche Regelungen haben im Innenverhältnis zwischen Lieferant und Erwerber ihre Berechtigung und erleichtern den Regress, sofern der Lieferant nicht insolvent ist. Die Insolvenz ist vor allem bei kleinen Lieferanten ein typisches Risiko, vor allem weil im Falle von Lizenzverstößen hohe Schadensersatzkosten drohen können. Bei ausländischen Lieferanten (vor allem aus dem EU-Ausland) ist die Rechtsdurchsetzung gegenüber dem Lieferanten häufig schwierig und/oder zeitaufwendig.

Das Hauptproblem solcher Regelungen zwischen Erwerber und Lieferant ist, dass sie den Erwerber bei (unbemerktem) OSS-Lizenzverstoß nicht davor schützen, durch den Rechteinhaber der OSS-Komponente in Anspruch genommen zu werden, wie das Urteil des LG Hamburg aus 2013 gezeigt hat (siehe oben). Vertragliche Regelungen mit dem Lieferanten entbinden den Erwerber also nicht von eigenem OSS-LCM, denn eine vertragliche Vereinbarung zwischen Erwerber und Lieferant kann nicht zulasten eines Dritten, wie hier etwa dem OSS-Lizenzgeber, gehen.

Kumulativer Einsatz verschiedener Compliance-Tools sinnvoll

Auf dem Markt sind verschiedene OSS-Scanner verfügbar, die die Code-Analyse automatisiert durchführen und als Ergebnis unter anderem eine Übersicht der relevanten OSS-Lizenzen auswerfen, wobei teilweise durch Ampelfarben markiert ist, wo Lizenzkonflikte drohen und wo nicht.

Es gibt auch kostenlose OSS-Varianten solcher Tools (zum Beispiel fossology). Wichtig ist, dass jedes dieser Tools naturgemäß eine (im Regelfall geringe) spezifische Fehlerrate hat. Durch Kombination mehrerer Tools lässt sich die Fehlerrate weiter reduzieren. Daher ist es sinnvoll, kumulativ verschiedene Identifizierungs- und Ermittlungsmaßnahmen zu ergreifen, wobei im Einzelfall – auch unter Berücksichtigung von Bedeutung und Gefährdungslage des Software-Einsatzes – abzuwägen ist, was mit Blick auf Aufwand und Kosten als angemessen und ausreichend eingestuft werden kann. Häufig ist eine individuelle/händische Analysetätigkeit jedoch nicht zu vermeiden.

Dateiformat SPDX zur Dokumentation von Software-Lizenzen

Neben den OSS-Scannern haben sich in letzter Zeit auch technische Dateiformate weiter herausgebildet, mit deren Hilfe ein einfacheres Handling der OSS-Lizenzinformationen ermöglicht werden soll. Ein oft genanntes Beispiel ist das Format des "Software Package Data Exchange" (SPDX), das von der Linux Foundation vorgestellt wurde und mittlerweile in der Version 2.1 vorliegt (abrufbar über https://spdx.org/). Es handelt sich um die Spezifikation eines Dateiformats für die Dokumentation von Lizenzinformationen unter der freien "Creative Commons Attribution 3.0 Unported"-Lizenz, mit der der Urheber einer OSS-Komponente die dazugehörigen relevanten lizenzrechtlichen Informationen (Komponentenname, Komponentenversionsnummer, Lizenztext, Lizenzlink, Copyright-Vermerke) bekanntgeben kann.

Diese Informationen – das heißt deren klare Identifikation und Zuordnung (siehe oben, Stufe 1 und 2) – sind unerlässlich, um eine urheberrechtlich einwandfreie Verwendung von OSS-Komponenten zu ermöglichen.

Mithilfe des SPDX-Formats kann eine gebündelte Wiedergabe der erforderlichen lizenzrechtlichen Informationen erfolgen, die bei Verbreitung von OSS regelmäßig relevant sind. Eine Vielzahl von Lizenztypen ist standardmäßig innerhalb der SPDX-Systems vordefiniert, weitere sind manuell ergänzbar. Auch Dual- und Multi-Licensing ist abbildbar.

Besonders nützlich sind Zusatzfunktionalitäten wie etwa ein summarischer Kontrollabgleich, ob die gespeicherten SPDX-Informationen tatsächlich zu der betrachtete Softwarekomponente gehören (Feld "package checksum"). Zudem kann zwischen der vom Urheber deklarierten Lizenz ("declared license") und der vom Ersteller der SPDX-Datei festgestellten Lizenz ("concluded license") differenziert werden. Das SPDX-System kann in der Gesamtschau auch auf erste lizenzrechtliche Probleme oder Unwägbarkeiten aufmerksam machen. Eine weitergehende, oft manuelle Überprüfung wird jedoch in der Regel unerlässlich sein, um die mittels SPDX gefundenen (und gegebenenfalls auch nicht gefundenen) lizenzrechtlichen Probleme zu verifizieren beziehungsweise auszuschließen und gegebenenfalls Lösungen hierfür zu finden.

Korrektheit und Authentizität von OSS-Lizenzinformationen nachprüfen

Inwieweit die (zum Beispiel im SPDX-Format) bereitgestellten Lizenzinformationen zu OSS-Komponenten tatsächlich als verlässlich, authentisch und vollumfänglich korrekt eingestuft werden können, ist eine Frage, die mit der Integrität des Ausstellers der spezifischen SPDX-Datei zusammenhängt. Die in der SPDX-Datei gemachten Angaben können sich als falsch, fehlerhaft oder unvollständig erweisen.

Gerichtsurteile zum Umgang mit OSS-Dokumentationstools sind, soweit ersichtlich, bislang nicht ergangen. Jedenfalls bei Anhaltspunkten für etwaige Widersprüche, Ungenauigkeiten oder Unkorrektheiten entbindet die Verwendung von SPDX-Dateien den Nutzer nicht von einer weitergehenden lizenzrechtlichen (Detail-)Prüfung.

Selbst wenn solche nach außen erkenntlichen Anhaltspunkte für fehlerhafte Angaben in der SPDX-Datei nicht ersichtlich sind und infolgedessen der Verwender einer OSS-Komponente die tatsächlich geltenden Lizenzbedingungen nicht kennt (und gegebenenfalls auch nicht erfüllt), führt dies nicht zu einem Sanktionsschutz. Wie hoch der Aufwand zur Überprüfung der Richtigkeit von vorgefundenen OSS-Dokumentationsdaten sein muss, ist eine bislang unbeantwortete Frage. Hier wird es aber wohl auch jeweils auf den konkreten Einzelfall ankommen.

Somit kann Einsatz von SPDX oder ähnlichen Formaten (etwa unternehmensinterne Eigenentwicklungen) zwar eine Erleichterung bei der OSS-Compliance bieten, ist aber allein nicht ausreichend.

Einsatz von SPDX und Compliance-Tools in Unternehmen

Der Verbreitungsgrad von SPDX und damit arbeitenden Compliance-Tools wird mit Blick auf die große und stetig steigende Bedeutung des OSS-LCM voraussichtlich weiter ansteigen. Gerade für kleine und mittelständische Unternehmen, die ohne eigenständige Compliance-Abteilung auskommen müssen, dürfte der Rückgriff auf das standardisierte SPDX-Format eine erste Option sein. Bei größeren Unternehmen und Konzernen mit eigenständiger Compliance-Abteilung wird erfahrungsgemäß ein internes, individualisiertes OSS-Compliance-Modell aus Gründen der Effektivität und Passgenauigkeit präferiert, aber auch hier sind Kenntnisse im Umgang mit dem SPDX-Spezifikationen hilfreich.

Entscheidend für jedes Unternehmen, das mit OSS in Berührung kommt, ist der Aufbau entsprechender Compliance-Strukturen. Mit technischer Expertise, juristischem Know-how und dem Rückgriff auf verschiedene Compliance-Tools aus dem skizzierten "OSS-Werkzeugkasten" kann es Unternehmen gelingen, diese lizenzrechtlichen Herausforderungen zu meistern.