Lizenzreport erstellen

Zunächst muss in das Wurzelverzeichnis des BSP gewechselt werden, in unserem Fall ist das ~/DistroKit. Das können wir überprüfen, indem wir schauen, ob die Symlinks selected_platformconfig und selected_ptxconfig in diesem Verzeichnis auffindbar sind. Existieren die Symlinks nicht, kann PTXdist jedoch auch im ~/DistroKit/configs-Verzeichnis suchen. Lediglich wenn auch dort keine Informationen zur Plattform und keine PTXconfig auffindbar sind, kann der Befehl nicht ausgeführt werden. Anschließend wird der Befehl ptxdist make license-report aufgerufen.

~/DistroKit $ ptxdist make license-report

In meinem Fall musste ich zuvor die Pakete graphviz, dot2tex und texlive-xetex nachinstallieren. Sind alle Voraussetzungen gegeben, sammelt PTXdist alle Lizenzinfos der Pakete zusammen, die im BSP gebaut werden. Dies sind die Variablen <PKG>_LICENSE und <PKG>_LICENSE_FILES einer jeden Paketdefinition, die entweder lokal im BSP oder im PTXdist-Installationsverzeichnis unter rules/<pkg>.make zu finden sind. Es meldet schließlich:

) [375] (./license-report-tools.aux) )
(see the transcript file for additional information)
Output written on license-report-tools.pdf (375 pages).
Transcript written on license-report-tools.log.
finished target license-report-tools.pdf

Der Lizenzreport liegt im Unterverzeichnis der verwendeten Plattform und dort unterhalb von report. Es interessiert uns gerade nur der license-report.pdf (der Report für die Tools ist für das fertig gebaute BSP, in welchem die Tools keine Anwendung mehr finden, nicht interessant), also schauen wir ihn an:

~/DistroKit $ evince platform-v7a/report/license-report.pdf

Bitte den Disclaimer auf der ersten Seite beachten:

!Attention!
This list of licenses is automatically generated and asserts no claims to
completeness or correctness. It is not legally binding, and comes without
warranty of any kind. We advise a manual counter-check before publication or
legal use.

Umgang mit dem Lizenzreport

Schauen wir uns das Paket BusyBox an:

Der Lizenzreport hat für BusyBox die Lizenz GPLv2-only gefunden. Das bedeutet, dass zur Verwendung von BusyBox die Bedingungen der GPLv2 erfüllt werden müssen. Aufgrund des Zusatzes -only darf nicht stattdessen auf GPLv3 ausgewichen werden. Befolgt man dauerhaft die Anforderungen der GPLv2, hat man für dieses Paket die Arbeit bereits beendet.

Schauen wir uns jedoch das Paket systemd an, so fällt auf:

License: GPL-2.0-or-later AND LGPL-2.1-only

Der Lizenzreport hat also Komponenten von systemd gefunden, welche unter GPLv2+ lizenziert sind, jedoch auch Komponenten, die unter LGPLv2-only lizenziert sind. Wenn die beabsichtigte Verwendung zufällig ohnehin konform mit beiden Lizenzen ist, sind wir auch hier bereits am Schluss. Das ist natürlich der ideale Zustand.

Im anderen Fall muss geprüft werden, ob die Komponenten ausgelassen werden können, die unter Bedingungen lizenziert sind, die man nicht erfüllen kann oder will.

Die Komponenten von Hand analysieren

Schauen wir uns beispielsweise an, welche Komponenten von systemd im BSP überhaupt verwendet werden:

~/DistroKit $ cd platform-v7a/build-target/systemd-243-51-gfab6f010ac6c

Den Befehl mit der Tabulator-Taste vervollständigen, nachdem jeweils die ersten Zeichen eingegeben wurden.

In den dort liegenden Komponenten von systemd findet sich obenan jeweils ein Lizenz-Header, der erklärt, unter welcher Lizenz die jeweilige Komponente lizenziert ist. Zum Beispiel könnte man die Komponente .mkosi/mkosi.debian weglassen. Nehmen wir mal für Erklärungszwecke an, dass das etwas ist, was man tun wollen würde. Wenn man dann bei Erstellung des BSP diese Komponente auslässt, gegebenenfalls also aktiv ausschaltet, müssen die Lizenzbedingungen hierfür nicht erfüllt werden. Das würde natürlich nicht so viel ändern, da auch die anderen .mkosi-Dateien unter LGPLv2 lizenziert sind. Um die LGPL zu vermeiden, müsste man sogar alle Komponenten von .mkosi auslassen. Und natürlich ist noch viel mehr LGPL in systemd verbaut. Vielleicht willst du dir das mal anschauen:

~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep LGPL -R

Das grept rekursiv nach den Buchstaben LGPL. Achtung, grep ist case-sensitive, also Groß- und Kleinschreibung beachten. Weil die Buchstabenfolge LGPL üblicherweise nur im License-Identifier verwendet wird, bekommt man eine gute Übersicht darüber, welche Komponenten unter einer Version der LGPL lizenziert sind. Du könntest stattdessen auch nach einer besonderen Version der LPGL greppen, versuche zum Beispiel LGPL-v2. Beachte dabei aber, dass nicht alle Entwickler die gleiche Syntax verwenden, zum Beispiel findet man LGPL v2.1 (ohne den Bindestrich zwischen L und v) in src/udev/ata_id/ata:id.c. Für die schlichte Suche nach LGPL ist es, wie erwartet, sehr viel. Nur die letzten paar Ergebnisse:

test/create-sys-script.py:# SPDX-License-Identifier: LGPL-2.1+
sysctl.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
network/80-container-host0.network:#  SPDX-License-Identifier: LGPL-2.1+
network/meson.build:# SPDX-License-Identifier: LGPL-2.1+
network/99-default.link:#  SPDX-License-Identifier: LGPL-2.1+
network/80-container-ve.network:#  SPDX-License-Identifier: LGPL-2.1+
network/80-container-vz.network:#  SPDX-License-Identifier: LGPL-2.1+
sysusers.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
tmpfiles.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
tmpfiles.d/portables.conf:# SPDX-License-Identifier: LGPL-2.1+

Vielleicht möchtest du die genaue Anzahl an Ergebnissen wissen, zum Beispiel zur Abschätzung der Arbeitszeit:

~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep LGPL -R | wc -l

In meinem Fall ganze:

2162

Oder du suchst nach GPL, was auch in der Buchstabenfolge LGPL beinhaltet ist. Wenn du nur nach der GPL greppen willst, brauchst du ein wenig RegExp-Magie:

grep '^GPL\|[^L]GPL' -R

Oder suche direkt nach den License-Identifiers:

~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep License-Identifier -R

Eine Wortzählung bringt uns auf eine Gesamtheit von 2224 (registrierten) License-Identifiers für die Version von systemd, die ich in meinem BSP verbaut habe, wobei manche Dateien gegebenenfalls die Buchstabenfolge License Identifier nicht exakt beinhalten.

Diese Arbeit nimmt dir der Befehl ptxdist make license-report ab und gibt dir einen guten Überblick über die Lizenzen der verwendeten Komponenten, bei bekannten Open-Source-Lizenzen sogar einschließlich Lizenztext. Es ist recht komfortabel, ein einfach zu lesendes PDF zu haben, was einem sagt, welches Programm im BSP welche Lizenzen beinhaltet. Das erlaubt dir, dich auf die verbleibenden problematischen Stellen zu konzentrieren. Der Lizenzreport benötigt jedoch natürlich korrekte Angaben und kann daher das individuelle Lizenzmanagement durch einen Menschen nicht ersetzen.

Wenn bei einem bereits bestehenden BSP nachträglich bestimmte Lizenzen vermieden werden sollen oder müssen, kann der Lizenzreport als Ausgangspunkt genutzt werden.