YOCTO, IOT und die GPLv3

2019-06-30 / 2023-08-03 von Karsten Reincke | 1 Kommentar zu YOCTO, IOT und die GPLv3

IOT-Geräte bieten meist nur eingeschränkte Möglichkeiten, die darin verwendete Software zu untersuchen oder gar zu verändern. YOCTO möchte Software ganz spezifisch für IOT-Geräte zusammenstellen. Die GPLv3 erfordert aber, dass man so lizenzierte Software ersetzen können muss. Wie also stehen sie wirklich zueinander, YOCTO, IOT und die GPLv3?

[ de | en ]

Das “open source collaboration project” YOCTO bewirbt sich mit dem Slogan “it’s not an embedded Linux Distribution, it creates a custom one for you” (→ [7]): Man sammelt und kompiliert genau die Software, die man benötigt. So kann auch die ausführende IOT-Hardware einfach gehalten werden. Das ist der YOCTO-Ansatz. Allerdings: die technische Struktur der Geräte beeinflusst auch die Erfüllbarkeit der Lizenzen. Und da kann haarig werden!

Grundsätzlich weiß YOCTO um die Komplexität der FOSS Compliance und unterstützt die Produzenten schon während des Kompilationsprozesses. Es listet z.B. alle Pakete und alle in das Image eingeflossene Lizenzen auf (→ [8] 3.5). Außerdem erlaubt es, automatisiert auch die Lizenztexte in den Build zu integrieren (→ [8] 5.20.2). Und es bietet die Option, auch den korrespondierenden Quellcode als Paket zusammenzustellen (→ [8] 5.20.1). Das sind wichtige Vorarbeiten. [Nur der Vollständigkeit halber: diese Vorarbeiten sind notwendig, aber nicht hinreichend. Allerdings ist das jetzt nicht unser Thema.]

Nun fordert jede (A|L)GPLv lizenzierte Software mehr als nur die Mitgabe der Lizenz. Oder die Nennung der Copyright-Owner und die Mitgabe des Disclaimers und (auf Anfrage) die Übersendung des Codes. Zusätzlich muss dem Empfänger die Möglichkeit gegeben werden, selbst eine verbesserte oder verschlechterte Version auf der Hardware installieren zu können. (→ [1,2,3] §3) Wenn das IOT-Gerät den Zugriff auf die interne Platte erlaubt — sei es über ein USB-Interface oder sonst wie — ist das kein Problem: der Nutzer speichert seine Version der zu ersetzenden Software darauf ab und legt den Link um. Bingo. Was aber, wenn das Gerät kein solches Interface hat? Oder wenn der Hersteller nicht möchte, dass seine Kunden dieses Recht ausüben, sei es, um gesetzliche Sicherheitsstandards nicht zu unterlaufen, sei es um seinen Betreuungsaufwand gering zu halten?

Dann — so die einfache Antwort — darf der Hersteller keine GPLv3, keine LGPLv3 und keine AGPLv3 lizenzierte Software in seinem Softwarestack verwenden. Denn über die Lizenz verspricht er, die Benutzung oder Modifikation der genutzten Software nicht zu beschränken (→ [1] §3): Entweder man erfüllt die Lizenzen oder man verwendet die Software nicht. So einfach und binär ist das ganz generell mit der FOSS Compliance.

Glücklicherweise unterstützt YOCTO den Produktmanager auch bei der Einhaltung dieser Maxime. Man kann im “recipe” zur Erzeugung des Images die Variable INCOMPATIBLE_LICENSE mit Lizenzidentifikatoren belegen kann. (→ [9] Chapter 10) Der Kompilationsvorgang bricht dann ab, wenn Entwickler trotzdem so lizensierte Software einbauen. Allerdings hat das funktionelle Nebeneffekte: YOCTO warnt sogar mehrfach, dass mit dieser Option nur sehr rudimentäre Images erzeugt werden können, (→ [9] pars pro toto: Chapter 10), eben weil so viele gute Software mittlerweile unter der GNU Lizenzen V3 veröffentlicht werden. Aber immerhin, es geht in Grenzen.

So weit, so gut. Leider stößt man damit auf ein Kernproblem, das sich viel stärker auswirkt:

Einige Standardbibliotheken — wie eben die libstdc++ — stehen in akzeptabler Reife nur noch unter den Bedingungen der GPLv3 zur Verfügung. Wenn überhaupt ist es nur sehr schwer möglich, sie zu ersetzen. Und so integriert YOCTO die libstdc++ — fast, als wolle das Projekt dies unterstreichen — in sein Image, auch wenn die Belegung der Variable INCOMPATIBLE_LICENSE dies eigentlich verhindern müsste. Es scheint also, als würde YOCTO nicht-Lizenz-konforme Images erzeugen. Betrachtet man die Lage genauer, erkennt man, dass YOCTO dennoch auf dem richtigen Weg ist:

Standardbibliotheken haben eine besondere Stellung. Sie stellen die Basisfunktionen bereit, über die ein Programm mit dem ausführenden Kernel kommuniziert und über die es erst ausführbar gemacht wird. Sie sind unumgehbar. Wird eine Standardbibliothek unter einer Lizenz mit starkem Copyleft (AGPL|GPL) veröffentlicht, ergibt sich so unmittelbar, dass jede ‘höher liegende’ Bibliothek und jedes Programm unter derselben Lizenz veröffentlich werden müsste. Die “GNU Standard C++ Library v3” — kurz libstdc++ — ist eine solche Bibliothek: Sie sieht sich als ein “ongoing project to implement the ISO 14882” (→ [5] 1.1), sie versteht sich als Teil der “GNU compiler collection” (→ [5] 1.2) [4] und ist unter der GPLv3 lizensiert (→ [4]).

Trotzdem verneint die Libstdc++-FAQ die Frage ganz klar, ob jedes Programm, das die libstdc++ nutze, unter die GPL falle: “No. The special exception permits use of the library in proprietary applications. ” (→ [5] 2.2) Wie ist das möglich?

Die libstdc++ ist nicht nur unter der GPLv3 allein lizenziert: “The source code is distributed under the GNU General Public License version 3, with the addition under section 7 of an exception described in the ‘GCC Runtime Library Exception, version 3.1’ as follows” (→ [4]). Und diese GCC-Runtime Library Exception sagt unter §1:

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. (→ [4] §1)

Das klingt erst einmal kryptisch. Aber das Erratische löst sich auf, wenn man auch die unter §0 hinzugefügten Definitionen berücksichtigt:

Der “Target Code” bezeichnet jeden “[…] Output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase”. Die “Runtime Library” meint eben die Bibliothek, für die Ausnahme gilt, hier also die libstdc++. Und “Independent Modules” sind die Dateien, zu deren Ausführung in kompilierter Form die Runtime Library notwendig ist. (→ [4] §0) Oder anders gesagt: Es sind die Dateien, die Funktionsaufrufe in die libstdc++ enthalten, die deren Objekt und Methoden nutzen oder deren Inline-Funktionen über libstdc++ aufgelöst werden.

Also erlaubt uns der Erste der oben zitierten Sätze, sein kompiliertes Programm auch unter Bedingungen zu verteilen, die die GPLv3 verletzten. Vorausgesetzt wird nur, man hat sein ganzes Produkt über einen Eligible Compilation Process generiert.

Ein Compilation Process wiederum ist jedes Verfahren, dass menschlich lesbaren Softwarecode oder JAVA-Byte-Code in den Target Code überführt. Und Eligble ist ein solcher Compilation Process dann und nur dann, “[…] if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC.” (→ [4]) Entweder ganz GCC oder gar nicht — aber kein Mischmasch. Darum geht es.

Der erste Satz von §1 besagt also, dass man seine gegen die libstdc++ kompilierten eigenen Programme auch dann verteilen darf, wenn man durch die Art der Verteilung die GPLv3 verletzen würde, vorausgesetzt, man hat alle Teile komplett mit dem GCC kompiliert (oder keines). Der erste Satz hebt also den starken Copyleft-Effekt unter bestimmten Bedingungen auf.

In unserem Kontext von IoT-Geräten ohne Interface zum Ersetzen der Software ist das aber nicht genug! Die Frage bleibt ja, ob man die libstdc++ selbst unter Verletzung der GPLv3 vertreiben dürfte. Um diese Frage zu beantworten, benötigen wir den 2. Satz von §1. Er besagt,

You may then [= unter den zuvor genannten Bedingungen] convey [= propagate = distribute] such a combination under terms of your choice, consistent with the licensing of the Independent Modules. (→ [4] §1)

Die genannte Kombination kann dann nichts anderes sein als die libstdc++ plus die gegen sie kompilierten unabhängigen Module und Programme. Wir dürfen das ganze Konglomerat unter den Bedingungen vertreiben, die zu den Bedingungen der unabhängigen Module passen, also auch unter Verletzung der GPLv3 — eben mit Rückgriff auf die Runtime Exception selbst. Und das gilt mithin auch für die libstdc++.

Bingo! Wirklich? Leider noch nicht ganz.

Im Urheberrecht kommt es nicht nur darauf an, die wörtliche Bedeutung eines Vertragstextes, einer Lizenz zu ermitteln. Stattdessen muss man auch berücksichtigen, was die Urheber gemeint haben. Glücklicherweise kann man das in diesem Fall recht einfach ermitteln:

Der Copyright-Owner der GNU Compiler Collection ist die FSF. Und die hat in einer libstdc++-FAQ erläutert, wie sie die GCC Runtime Exception im Kontext der libstdc++ verstanden haben möchte (→ [5]) :

Einerseits fragt die FSF ob “[…] any program which uses libstdc++ falls under the GPL?”. Und antwortet kurz und knapp: “No. The special exception permits use of the library in proprietary applications.” (→ [5] 2.1) Auf der anderen Seite erläutert des FSF in dieser FAQ, dass die libstdc++ ganz generell nicht so einfach ersetzt werden könne, wie es bei anderen Bibliotheken möglich sei, weil “much of the library consists of inline functions and templates, which are expanded inside the code that uses the library” and replacing the library would also require to recompiling the using program. (→ [5] 2.3)

Also dürfen wir auch aus der FAQ schließen, dass die FSF nicht nur den starken Copylefteffekt unter den genannten Bedingungen aufgehoben sehen will, sondern auch die Bedingung der Ersetzbarkeit.

Unglücklicherweise gibt es ein drittes Dokument, was diesem Schluss zu widersprechen scheint. Die libstdc++ ist nicht die einzige Bibliothek, die unter der Runtime Library Exception veröffentlicht ist. Deshalb hat die FSF unter dem Titel “GCC Runtime Library Exception Rationale and FAQ” auch eine generelle Einführung veröffentlich. (→ [6]) Dieses Dokument erklärt zuerst, warum man diese Technik der Ausnahmeregelungen ab der Version 3 generell einführt. Im 2. Abschnitt erläutert es, wie die Technik funktioniert. Und endet hier in dem jetzt bereits bekannten Satz “As long as you use an Eligible Compilation Process, then you have permission to take the Target Code that GCC generates and propagate it ‘under terms of your choice.’” (→ [6])

Die Frage, ob auch die libstdc++ unter den Ausnahmebedingungen der Runtime Library Exception vertrieben werden darf, stellt der Text jedoch nicht. Im Kontext einer Frage nach der Nutzung einer komplett proprietären Kompilerkette wird allerdings herausgehoben, dass man auch dann die Vorteile der Runtime Exception nutzen kann, allerdings müsse man die libstdc++ selbst unter den Bedingungen der GPLv3 weitergeben.

Diesen Zusatz könnte man generell sehen wollen. Allerdings gibt es zwei starke Gründe, die das verbieten. Zum ersten ist er im spezifischen Kontext dieser Frage eingefügt worden, also nicht generalisiert worden. Und zum zweiten würde eine generelle Geltung die Runtime Exception im durch die FSF dargestellten Sinne unterlaufen. Wenn auf der einen Seite der starke Copylefteffekt der GPLv3 für die eigenen Programme über die GCC Runtime Exception aufgehoben werden soll und wenn andererseits die Art der Bibliothek trotzdem die Offenlegung des nutzenden Codes erzwingen würde, damit man die Bedingung der Ersetzbarkeit überhaupt erfüllen kann, dann hätte die FSF etwas Selbst-widersprüchliches im Sinn gehabt. Und davon ist nicht auszugehen.

So liegt die Sache nunmehr klar auf dem Tisch:

YOCTO darf die libstdc++ Bibliothek auch dann in seine Images integrieren, wenn die Nutzung von GPLv3 Software eigentlich ausgeschlossen sein soll. Es entsteht auch damit ein lizenzkonformes Image. Denn der starke Copylefteffekt ist durch die Runtime Exception ebenso aufgehoben, wie die Forderung nach der Ersetzbarkeit der libstdc++.

Allerdings gilt dies nur für die libstdc++. Auf andere Libraries können wir es nicht so einfach übertragen. Die Möglichkeit, die libstdc++ auch — wie es in der GCC Runtime Library Exception heißt — unter Verletzung der GPLv3 zu vertreiben, hängt von der Lizenzierung der libstdcc unter der GPLv3 mit GCC Runtime Library Exception ebenso ab, wie von ihrer immanenten Natur als c++-Bibliothek.

Und in welchem Zusammenhang …

… steht das mit einer systematischen Erfüllung von FOSS-Lizenzen? Nun, dazu müssen wir halt auch politische Konnotationen bedenken, konzeptionelle und kontextuelle Aspekte analysieren — einzeln oder gemeinsam auf Konferenzen. Wir müssen konkrete Fälle und allgemeine Nebenwirkungen durchdenken, für Software, Bilder oder Dokumente. Wir müssen Trends benennen und Leitfäden erstellen. Vornehmlich aber müssen wir die Automatisierung der Lizenzerfüllung vorantreiben, unser Lizenzwissen frei zur Verfügung stellen, es in kleinere Tools gießen und in größere Systeme einbringen: Denn FOSS lebt von der Freiheit durch Lizenzerfüllung, im Großen und im Kleinen.