FOSS lizenzkonform vertreiben Open Source Compliance Tools im Vergleichstest

Anbieter zum Thema

Open Source Automation Development Lab (OSADL) eG

emlix GmbH

FOSS (Free and Open Source-Software) ist heute selbst in der Industrie allgegenwärtig, bringt aber auch Herausforderungen bei der Lizenzkonformität mit sich. Tools können dabei helfen, den Freigabeprozess zu automatisieren und Compliance sicherzustellen. Doch welches Werkzeug ist für welche Aufgabe das richtige?

Free and Open Source-Software (FOSS) ist aufgrund ihrer zahlreichen Vorteile kaum noch aus der Industrie wegzudenken. Neben dem offenen Entwicklungsmodell und der Möglichkeit, Software flexibel an die eigenen Bedürfnisse anpassen zu können, ist die einfache Wiederverwendbarkeit von Komponenten sicherlich das Hauptargument für den Einsatz von FOSS. Folglich beinhalten viele Produkte FOSS-Komponenten in erheblichem Umfang, und diese gilt es zu analysieren, freizugeben und zu verwalten.

Weiterhin müssen die Lizenzbedingungen ermittelt werden, um das Produkt lizenzkonform vertreiben zu können. Der hiermit verbundene Aufwand ist nicht unwesentlich, denken wir nur einmal an den Linux Kernel mit mehr als 100 Lizenzen und fast 70.000 Rechteinhabern. Aus diesem Grund ist es weder möglich noch empfehlenswert, die notwendigen Teilschritte eines Freigabeprozesses ausschließlich manuell zu bearbeiten. Erfreulicherweise gibt es eine stetig wachsende Anzahl an Tools, die bei diesen Aufgaben unterstützen.

Dieser Beitrag gibt einen Überblick zu den wichtigsten Bestandteilen einer Compliance Toolchain, den hierfür verfügbaren Tools und gibt dabei Empfehlungen, welches Tool für die jeweilige Aufgabe verwendet werden kann. Die vorgestellten Werkzeuge stehen selbst alle unter einer FOSS-Lizenz zur Verfügung.

Anforderungen an eine Compliance Toolchain

Bevor wir uns damit beschäftigen, welche Tools wann zum Einsatz kommen, müssen wir zunächst einmal genau betrachten, wie die Freigabe von FOSS-Komponenten für ein Produkt abläuft. Bild 1 zeigt die wichtigsten Teilschritte und den grundsätzlichen Workflow eines solchen Freigabeprozesses.

An erster Stelle steht die Ermittlung der eingesetzten Komponenten und deren Abhängigkeiten. Hierbei ist es wichtig zu dokumentieren, in welchem Kontext die jeweilige Software eingesetzt wird. Denn zur Bestimmung und Umsetzung der Lizenzpflichten muss nicht nur bekannt sein, welche Software eingesetzt wird, sondern auch wie diese eingesetzt wird und wie die Schnittstellen zu anderen Komponenten gestaltet sind. In den weiteren Schritten wird ermittelt, welche Lizenzen zum Einsatz kommen und ob diese für den jeweiligen Produktkontext geeignet sind. Die Ergebnisse dieser Arbeiten werden dann in einem Komponentenkatalog abgelegt und mit der Bill of Material dokumentiert. Je nach Produktumfeld und individueller Risikobewertung kann es zusätzlich noch notwendig sein, die eingesetzte Software auch auf unlizenzierte oder ungekennzeichnete Codesnippets zu scannen.

Bei der Betrachtung dieses Ablaufes wird schnell klar, dass nicht alle Aufgaben von einem einzelnen Tool abgedeckt werden können. Für jeden Zwischenschritt gibt es mehrere geeignete Werkzeuge, die zu einer Toolchain zusammengestellt werden müssen.

Bei der Definition einer solchen Toolchain spielen aber nicht nur Lizenzaspekte eine Rolle. Die eingesetzten FOSS-Komponenten müssen über die Produktlebenszeit selbstverständlich auch gepflegt und gewartet werden. Dies beinhaltet insbesondere das Erkennen bekannter Sicherheitslücken und die Bereitstellung sicherheitsrelevanter Updates. Die Zuständigkeiten für die korrekte Lizenzierung und für die Pflege der Software liegen zwar meist in unterschiedlichen Unternehmensbereichen, die damit verbundenen Arbeiten sind aber sehr eng verbunden und bauen zwingend aufeinander auf. Bei der Zusammenstellung einer geeignete Toolchain muss also darauf geachtet werden, dass die Zusammenarbeit der verschiedenen Disziplinen im Unternehmen gewährleistet ist. Hierfür muss in erster Linie sichergestellt sein, dass die jeweils verantwortlichen Teams Informationen austauschen, wiederverwenden und auch ergänzen können.

Die Analyse: Welche Software wird wie genutzt?

Die Ermittlung der eingesetzten FOSS-Komponenten scheint auf den ersten Blick eine einfache Aufgabe zu sein. Doch gerade dieser Schritt kann sich durchaus als sehr aufwendig herausstellen. Das genaue Vorgehen hängt hierbei in starkem Maße vom jeweiligen Buildsystem bzw. der verwendeten Distribution ab. Nun ist es zwar sehr einfach, über einen Paketmanager die installierten Komponenten zu ermitteln und zu dokumentieren, doch leider ist diese Information nicht immer ausreichend. Python oder Go zum Beispiel haben ein eigenes System zur Softwareinstallation und erfordern somit das Zusammentragen von Informationen aus ganz unterschiedlichen Quellen.

Das Open Source Review Toolkit (ORT) kann bei dieser Aufgabe unterstützen. Mit dem sogenannten Analyzer können die Abhängigkeiten eines Projektes ermittelt werden. Hierbei werden sowohl die Paketmanager aller gängigen Distributionen, als auch die Installationssysteme verschiedener Programmiersprachen unterstützt. Neben dem Analyzer bringt ORT übrigens eine ganze Reihe weiterer Werkzeuge mit, die zusätzliche Bereiche eines Freigabeprozesses abdecken können: Mit dem Advisor lassen sich bekannte Sicherheitslücken der eingesetzten Software ermitteln, der Downloader hilft dabei, die Quellen der verwendeten FOSS-Komponenten zu beschaffen. Scanner, Evaluator und Reporter decken die Teilschritte vom Scanning bis hin zur Bill of Material ab. Bild 2 zeigt die in ORT enthaltenen Tools und deren Workflow.

Eine besondere Herausforderung stellt der Einsatz von Containern dar. Durch die Kapselung von Abhängigkeiten lassen sich Applikationen mit Hilfe von Containern sehr einfach in beliebige Szenarien integrieren. Technologisch bringt dies viele Vorteile, doch die Erfüllung von Lizenzpflichten ist bei der Verwendung von Containern in Produkten durchaus mit einigen Fallstricken verbunden. In erster Linie ist es nicht immer einfach nachzuvollziehen, aus welchen Komponenten ein Container Image genau besteht. Daher stehen zur Analyse von Containern Werkzeuge wie der container-inspector zur Verfügung. Diese helfen zu verstehen, welche Layer zum Einsatz kommen und in welcher Verbindung diese zueinanderstehen.

Ein häufig leider vernachlässigter Aspekt ist die Betrachtung der genauen Verwendung einzelner Programme, insbesondere deren Verlinkung. Dies ist zum Beispiel wichtig, um beurteilen zu können, ob es sich bei einem Programm um ein abgeleitetes Werk handelt. Für abgeleitete Werke von FOSS-Komponenten, die unter einer Copyleft behafteten Lizenz stehen, gelten möglicherweise zusätzliche Lizenzierungspflichten, die bei der Weitergabe beachtet werden müssen. Wer solche direkten und indirekten Abhängigkeiten eines Binaries ermitteln möchte, dem steht das Programm callgraph zur Verfügung. Dieses wertet aus, welche Komponenten eines Rootfilesystems durch Funktionsaufrufe mit dem untersuchten Programm verbunden sind und somit ein gemeinsames Werk bilden.

Informatives Scanning: Extrahieren von Information

Nach der Analyse der verwendeten Komponenten und der Zusammenstellung des zugehörigen Sourcecodes folgt das sogenannte Scanning. Leider wird der Begriff Scanning häufig als Überbegriff für zwei völlig unterschiedliche Dinge verwendet. Zum einen für das Erkennen und Extrahieren von lizenzrelevanter Information, dem sogenannten informativen Scanning. Diese Form des Scannings ist zwingend erforderlich und dient nicht nur der Ermittlung der verwendeten Lizenzen, sondern hilft auch bei der Erfüllung von Lizenzpflichten, wie dem Extrahieren von Lizenztexten und von Urherbervermerken.

Zum anderen wird das Wort Scanning häufig auch für das Auffinden von Codesnippets, die nicht gekennzeichnet oder nicht lizenziert sind, verwendet. Hier spricht man von Snippet matching oder auch von forensischem Scanning. Dies kann je nach Produktkontext und Risikobewertung notwendig sein, ist jedoch nicht zwingend erforderlich. Bild 3 zeigt eine Gegenüberstellung beider Formen des Scannings.

Wir befassen uns in diesem Beitrag mit den Tools für informatives Scanning. Die bekanntesten Vertreter dieser Kategorie sind Scancode und FOSSology.

Scancode zeichnet sich durch einfache Installation und Anwendung aus. Es handelt sich um ein Kommandozeilenwerkzeug mit sehr wenigen Abhängigkeiten, das auf unterschiedlichen Betriebssystemen verwendet werden kann. Ein Aufruf von Scancode, um Quellcode auf Lizenzinformationen und Urhebervermerke zu scannen, kann wie folgt aussehen:

FOSSology verfolgt ein etwas anderes Konzept. Die Bedienung erfolgt über ein Web-Frontend und das Tool verfügt über ein Multi User Konzept. Genau genommen handelt es sich bei FOSSology nicht um ein Scanning Tool, sondern um ein Werkzeug zur Durchführung und Verwaltung von Scans. FOSSology ist von Hause aus mit drei Scannern ausgestattet, die mit unterschiedlichen Strategien arbeiten:

• Nomos: Heuristiken und reguläre Ausdrücke

• Monk: Textbasierte Suche

• Ojo: Suche nach SPDX-License-Identifiern

Üblicherweise werden alle drei Scanner verwendet und die Ergebnisse kombiniert. In aktuellen Versionen besteht auch die Möglichkeit, Scancode zu integrieren. Neben dem reinen Scanning können mit FOSSology die Ergebnisse auch einem Review unterzogen und bearbeitet werden. Dies ist im Workflow auch explizit vorgesehen. Alle Scanergebnisse werden vom Anwender geprüft, bestätigt oder ggf. auch korrigiert.

Bild 4 zeigt, wie sich dieser Ablauf in der FOSSology Oberfläche darstellt.

Dieser Vorgang kann sehr umfangreich und zeitintensiv sein. Daher bietet FOSSology bei Versionsupdates von bereits gescannten Komponenten die Möglichkeit, die Ergebnisse der alten Version zu übernehmen. Es müssen dann nur die Änderungen zwischen beiden Versionen betrachtet werden.

Insbesondere bei sehr großen Softwarepaketen ist die Wiederverwendung von Scanergebnissen ein äußerst wichtiger Aspekt. Auch bei der Verwendung von Scancode und anderen Scanning Tools gibt es geeignete Strategien, die eine solche Wiederverwendung vereinfachen.

Mit Deltascan lassen sich effizient Modifikationen am Linux Kernel identifizieren. Dies kann zum Beispiel genutzt werden, um die BSP Anpassungen, die ein Hardwarelieferant am Mainline-Kernel vorgenommen hat, zu isolieren und im Anschluss zu scannen.

Disjunctify wird verwendet, um den Quellcode einer alten und einer neuen Version eines Softwarepakets zu vergleichen. Hierbei werden geänderte und neue Dateien identifiziert und in ein neues Verzeichnis kopiert. Dort können diese dann einem Scan, z.B. mit Scancode, unterzogen werden.

Das Clearing: Sind die Lizenzen kompatibel und im Produkt einsetzbar?

Der nächste Schritt im Freigabeprozess ist das Clearing. Dies beinhaltet das Prüfen und das Bestätigen der Scan-Ergebnisse, die Untersuchung der erkannten Lizenzen auf Kompatibilität und die Beurteilung ob die verwendeten Lizenzen im jeweiligen Produkt- oder Projektkontext verwendet werden können. FOSSology bietet bereits umfangreiche Funktionen, mit denen auch ein Clearing durchgeführt werden kann. Neben der Prüfung der Scanergebnisse, ermöglicht FOSSology auch das Hinterlegen von Kommentaren, zum Beispiel für die Zusammenarbeit zwischen verschiedenen Disziplinen, wie dem verantwortlichen Open Source Compliance Officer und der Rechtsabteilung. Wird FOSSology für das Scanning eingesetzt, so kommt es üblicherweise auch beim Clearing zum Einsatz.

Neben FOSSology gibt es aber noch einige weitere Werkzeuge, die beim Clearing Anwendung finden. So bietet das Open Source Review Toolkit passende Teilkomponenten. Auch Opossum kann mit Funktionen aufwarten, die beim Clearing unterstützen.

Bill of Materials / Komponentenkatalog: Ablage und Dokumentation von Software- und Compliance Informationen

Die Ergebnisse des Scanning- und Clearing-Prozesses werden üblicherweise in einem Komponentenkatalog abgelegt. Idealerweise haben unterschiedliche Disziplinen, wie Open Source Compliance Teams oder Security Teams Zugriff darauf. Neben den Informationen über die eingesetzten Komponenten, wie Scan- und Clearing-Ergebnisse, sollte dort auch einfach abzufragen sein, welche Komponenten in welchen Projekten zum Einsatz kommen und ggf. auch in welchen Geräten welche Versionen im Umlauf sind.

SW360 bietet hierfür sehr umfangreiche Möglichkeiten. Allerdings gestalten sich Installation und Wartung sehr komplex. SW360 kann neben der Verwaltung von Komponenten auch zur Generierung einer Bill of Material verwendet werden. Auch ORT und Opossum bieten die Möglichkeit, eine Bill of Material zu erzeugen.

Fazit

Für die Freigabe von FOSS-Komponenten in einem Produkt sind unterschiedliche Teilschritte notwendig. Die Umsetzung dieser Aufgaben kann mit rein manuellem Aufwand nicht bewältigt werden. Hierfür existiert eine Vielzahl an Werkzeugen, die zu einer Compliance Toolchain kombiniert werden müssen. Eine solche Toolchain reduziert den Aufwand für den lizenzkonformen Vertrieb von FOSS in einem Produkt in erheblichem Maße, eine komplette Automatisierung des Freigabeprozesses ist aber nicht möglich. Denn die Überprüfung von Scan-Ergebnissen, die Beurteilung, ob Lizenzen mit dem Produktkontext vereinbar sind, und auch die Dokumentation der Softwarearchitektur erfordern immer manuellen Aufwand und fachliche Expertise. (sg)

Dieser Beitrag wurde mit freundlicher Genehmigung des Autors aus dem Tagungsband des ESE Kongress 2022 übernommen.

* *Jan Altenberg hat mehr als 15 Jahre Erfahrung in der Entwicklung und Pflege von Embedded-Linux-Systemen. Seit Oktober 2021 arbeitet er als Senior Open Source-Consultant und Embedded Systems Integrator für das Open Source Automation Development Lab (OSADL) eG.

(ID:50199189)