Lizenzmanagement mittels ptxdist make license-report

PTXdist kommt standardmäßig mit einem Werkzeug, welches das Lizenzmanagement erleichtert: ptxdist make license-report. Hiermit lässt sich ein Lizenzreport als PDF erstellen, welcher aus dem verwendeten BSP alle auffindbaren Lizenzen herausfiltert. Die Generierung und Befolgung des Lizenzreports sollte als Mindestanforderung mit viel Raum für weitergehende Lizenzpflege verstanden werden.

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.


Weiter führende Links

Fürchte nicht den offenen Quellcode - 1x1 des Lizenzmanagements

Computerprogramme und Code sind urheberrechtlich geschützt, in Deutschland lässt sich dieser Schutz nicht umgehen oder ausschalten. Das Urheberrecht gewährt grundsätzlich nur demjenigen, der das Werk geschaffen hat ("Urheber"), die Rechte an dem Werk. Mithin dürfte nur der Entwickler den von ihm geschriebenen Code verwenden, verändern und verbreiten.


Jetzt als Creative Commons!

Felicitas Jung | | Lizenzen

Vielleicht hast du es schon bemerkt: Wir haben jetzt einen Footer, welcher nur im Blog auftaucht. Hintergrund ist, dass wir unsere Blogposts bisher ohne Angabe einer Lizenz veröffentlicht haben, sodass weder die Texte noch die sonstigen Informationen frei nutzbar waren.


Statische Dateisysteme

Jürgen Borleis | | PTXdist

Wann immer es erforderlich ist, ein embedded Gerät einfach so ohne Vorbereitung ausschalten zu können, kommt das Thema Dateisystem-Konsistenz auf. Werden Daten geschrieben und haben vor dem Ausschalten ihren Weg auf das Speichermedium noch nicht vollständig gefunden, droht deren Verlust.


Jump Start your BSP using DistroKit and PTXdist Layers

A BSP (Board Support Package) in Embedded Software is the layer of software that lets you run your application on a specific hardware. For Pengutronix a BSP usually contains a bootloader, Linux Kernel and a userspace. DistroKit is our Demo-BSP that supports a variety of common evaluation boards. DistroKit gives you a head start if you want to develop an application on top of such an evaluation board with most of the hard problems already solved.


PTXdist.org: Departure into a new Age

Enrico Jörns | | PTXdist

Over the past months, we did a lot of work in giving some open source projects maintained by Pengutronix folks the attention they deserve while also being more open to the community and ease contributing to and using them.


DistroKit - A Playground BSP for PTXdist

At Pengutronix we are using PTXdist to automatically integrate many industrial embedded Linux projects. Some time ago I started DistroKit: This example BSP shall be able to demonstrate PTXdist features.