SPDX - A Format for Open Source Software License Compliance

During LinuxCon Europe 2016, the Linux Foundation presented a tool for licensing compliance for Open Source Software (OSS): the SPDX specification 2.1 – Thus, a reason to take a look at content, verification and practical use and value of this specification (in a nutshell see "5. Takeaways" below).

SPDX is an acronym for Software Package Data Exchange and results a file that contains legal information about a particular computer program. This legal information relates to the composition and licensing of the open source software within the computer program, similar to an instruction leaflet for medicine or a list of ingredients for food.

(German version of this article below)

1. Content

The SPDX file is intended to explain the legal composition of a particular computer program. If the composition of this program is changed, the SPDX file has to be adapted accordingly. The SPDX file can in essence provide comments, licenses, and copyright notices as well as information about the origin of third party components that are incorporated into the computer program.

The SPDX specification supports about 300 different OSS licenses, whereas the creator of the SPDX file can add unsupported licenses manually with a new license label. This is very positive, given the possible many small deviations in known OSS licenses, e.g. the different acknowledgment notices with Apache Style licenses or individual compatibility notes of GPL style licenses (keyword: "GPLv2 only") For lawyers, the SPDX format is precise in the case of a dual or multi licensing of individual components under several OSS licenses. Accordingly, alternative licenses are marked with "OR"; mandatory licenses that have to be fulfilled at the same time (for example after a copyleft) can be marked with "AND", special exceptions to one license are marked with "WITH" (eg with GPLv2 with Classpath Exception). To determine the extent to which different parts of a program or file are under different licenses, the SPDX file uses the "Snippet" information (Details: Linux Foundation, SPDX Specification, Title 5: https://spdx.org/spdx-specification-21-web-version#h.lo3v4sra8jlj, dated 10/23/16). This information should be relevant in practice when code components (for example, within one file) are merged into different (permissive) OSS licenses, or if components under OSS licenses with Copyleft need to be removed from a program code.

2. Verification

The extent to which the information in a SPDX file is correct depends on the individual case. The creation of an SPDX is possible for everyone; i.e. there is no central SPDX certification body. In consequence, a recipient of the computer program has to trust the author of the corresponding SPDX file or initiate a separate license or code scan of the components (as the Linux Foundation recommends, cf. SPDX FAQ - How do I know if the information included in the SPDX file is accurate? Https://spdx.org/frequently-asked-questions-faq-0).

The options for verifying the SPDX file are limited to the file’s author and the associated computer program. According to the Linux Foundation, the SPDX file contains various types of encoded keys ("Package Checksum") that identify the scope of the computer program to which the SPDX file refers. If the contents of the computer program or the SPDX file are changed later, the keys lose their validity.

In addition, SPDX offers a modification history, which should give conclusions about the reliability of the SPDX information. The Linux Foundation recommends contractual agreements with the OSS supplier to increase the meaningfulness of the respective SPDX file. Accordingly, the supplier could for example, be obliged to assemble and create the SPDX file correctly and comprehensively (see. Linux Foundation, SPDX FAQ – How do I know if the information included in the SPDX file is accurate? https://spdx.org/frequently-asked-questions-faq-0).

3. Practical use

For the OSS recipient, it would be legally the safest way to seek a reliable contract with regard to the computer program and less with regard to the SPDX file. This contract should  specifically govern the recipient’s rights in case of material defects and defects in title, in particular if the computer program shall be re-distributable by the recipient.

Such a contractual arrangement would result in the OSS supplier having to combine the OSS licenses for the program’s components in a clear, compliant and compatible manner for re-distribution (for example, provide license texts and acknowledgments). Them, the contents of the SPDX file can then serve as a verification of the aforementioned obligations (see details below).

In case no agreement on the ability to drive or the deficiencies can be found, the value of the SPDX file would be a limited one. An OSS vendor in a strong negotiating position who does not want to be exposed to any claims for defects will also limit his scope of duties with regard to the SPDX file (see above, recommendations by the Linux Foundation). The reason: This avoids any liability for the computer program through the (SPDX-) backdoor; in any case it avoids a contractual inconsistency with regard to the rights for defects in the computer program. As far as the OSS supplier wishes to enter into any obligations with regard to the SPDX file, the OSS vendor is likely to accepts the fact that the SPDX file has been compiled to the best of his knowledge. If the supplier delivered incorrect license information, this fact may not be apparent from the SPDX file.

4. Further benefits

However, the SPDX file is likely to show obvious errors in the license clearing by the supplier. Suppliers fail, for example, if the SPDX file do not match with the program delivered (e.g. see package checksums), or if the license information in the SPDX file differs from those that the provider makes available (for example, via the program’s interface).

Furthermore, license conflicts can be identified, i.e. if the licenses used to create the computer program (SPDX: "Concluded License") are incompatible with the licenses under which the product is delivered (SPDX: "Declared License"). Such incompatibility may result in the product being legally incapable of distribution, e.g. if a "Concluded License" is an OSS license with Copyleft, the "Declared License" is a (permissive) OSS license without Copyleft. Why? Because, the copyleft of an OSS license - such as of the GNU General Public License version 2 ("GPLv2") - forces the author of the program to place it entirely under the GPLv2 ("as a whole") and regardless of the other licenses of the program’s components.

Finally, the contents of an SPDX file could be verified externally, e.g. by comparison with the result of a legal code analysis of the program. This procedure should result in the highest costs and is therefore only suitable for the initiation of or for random samples in long-lasting business relations. Providers of the aforementioned code analyzes, it might be interested in presenting their analysis’ results in the same SPDX-compliant manner to enable the customer to compare the results and create a new SPDX file where necessary.

5. Takeaways

• From a practical point of view, SPDX convinces with the possibility of assigning a file to different licenses ("snippet"). The legal value of an SPDX file is (only) as good as its author, the license information available and the contractual link between author (OSS supplier) and addressee (OSS recipient/buyer). An OSS customer should therefore rely on legally trained SPDX authors as well as reliable license information – both at the OSS supplier.

• An SPDX file can give an assessment about the minimum quality of license compliance by its author - even if the author has not taken over any obligations with respect to the SPDX file’s content:

(1) The Package Checksum of the SPDX file refers to whether the file belongs to the delivered product at all. Incorrect or outdated SPDX files should not be accepted by the OSS buyer.

(2) The comparison of "Concluded Licenses" and "Declared Licenses" within the SPDX file can determine whether license conflicts are to be expected.

(3) The result of a licensing code analysis of the product can be compared with the information from the SPDX file. If they match, they underline the high-quality licensing compliance by the OSS supplier.

• Conclusion: with the SPDX specification, one can assess the OSS license compliance by vendors or service providers that offer certification and/or legal code analysis. It is up to the OSS buyer not only to demand the SPDX information, but also to challenge it.

Anlässlich der LinuxCon Europe 2016 hat die Linux Foundation ein Werkzeug zur Lizenz-Compliance für Open Source Software (OSS) vorgestellt: die SPDX-Spezifikation 2.1 – also ein Grund, einen Blick auf Inhalt, Verifikation und praktischen Einsatz und Nutzen dieser Spezifikation zu werfen (für Eilige: siehe "5. Takeaways" unten).

SPDX steht für Software Package Data Exchange und stellt im Ergebnis eine Datei dar, die u.a. rechtliche Informationen über ein bestimmtes Computerprogramm enthält. Diese Informationen betreffen die Zusammensetzung und Lizenzierung der Open Source Software innerhalb des Computerprogramms, vergleichbar mit einem Beipackzettel für Medikamente oder einer Zutatenliste für Lebensmittel.

1. Inhalt

Die SPDX-Datei soll die Zusammensetzung eines bestimmten Computerprogramms erläutern. Wird die Zusammensetzung dieses Programms geändert, muss auch die SPDX-Datei entsprechend angepasst werden. Die SPDX-Datei kann im Wesentlichen Informationen in Form von Kommentierungen, Lizenzen und Urhebervermerke sowie Informationen über die Herkunft von Drittkomponenten liefern, die in dem Computerprogramm verbaut sind.

Die SPDX-Spezifikation unterstützt von Haus aus etwa 300 verschiedene OSS-Lizenzen; nicht-unterstützte Lizenzen können manuell vom Ersteller der SPDX-Datei unter einem neuen Lizenzlabel hinzugefügt werden. Das ist begrüßenswert, angesichts der möglichen Vielzahl kleiner Abweichungen bei bekannten OSS-Lizenzen, z.B. die verschiedenen Acknowledgement-Hinweise bei Apache Style Lizenzen oder individuellen Kompatibilitätsvermerke von GPL Style Lizenzen (Stichwort: „GPLv2 only“)

Für Juristen ist das SPDX-Format erfreulicherweise eindeutig bei einer Dual- oder Multi-Lizenzierung von einzelnen Komponenten unter mehreren OSS-Lizenzen. So können Lizenzen zwischen denen eine Wahlmöglichkeit besteht mit „OR“ gekennzeichnet werden; müssen mehrere Lizenzen gleichzeitig erfüllt werden (z.B. nach einem Copyleft) so können diese mit „AND“ gekennzeichnet werden, Sonderausnahmen werden mit "WITH" gekennzeichnet (denkbar z.B. bei GPLv2 mit Classpath Exception).

Inwieweit verschiedene Teile eines Programms oder einer Datei unter verschiedenen Lizenzen stehen, dürfte der SPDX-Datei mit Hilfe der „Snippet“-Information zu entnehmen sein (Details: Linux Foundation, SPDX Specification, Title 5: https://spdx.org/spdx-specification-21-web-version#h.lo3v4sra8jlj, Stand 23.10.16). Diese Informationen dürften in der Praxis vor allem relevant sein, wenn Code-Bestandteile (z.B. innerhalb einer Datei) unter verschiedenen (permissiven) OSSa-Lizenzen zusammengefügt werden oder wenn Bestandteile unter OSS-Lizenzen mit Copyleft aus einem Programmcode entfernt werden müssen.

2. Verifikation

Inwieweit die Informationen in einer SPDX-Datei auch zutreffend sind, hängt vom Einzelfall ab. Denn die Erstellung einer SPDX ist jedermann möglich; es gibt insoweit keine zentrale SPDX-Zertifizierungsstelle. Das bedeutet, dass man als Empfänger des Computerprogramms  dem Autor der entsprechenden SPDX-Datei vertrauen muss oder einen eigenen Lizenz- bzw. Code-Scan der Komponenten anstoßen muss (wie es im Übrigen auch die Linux Foundation empfiehlt, vgl. SPDX FAQ - How do I know if the information included in the SPDX file is accurate? https://spdx.org/frequently-asked-questions-faq-0).

Die Möglichkeiten zur Überprüfung der SPDX-Datei sind begrenzt auf die Angaben des Datei-Autors und dem zugeordneten Computerprogramm. Nach Angaben der Linux Foundation enthält die SPDX-Datei verschiedene Arten von codierten Schlüsseln ("Package Checksum"), die den Umfang des Computerprogramms identifizieren, auf das sich die SPDX-Datei bezieht. Wird der Inhalt des Computerprogramms oder die SPDX-Datei nachträglich verändert, verlieren die Schlüssel ihre Gültigkeit.

Des Weiteren existiert eine einsehbare Historie, die Rückschlüsse auf die Zuverlässigkeit der SPDX-Informationen geben soll. Die Linux Foundation empfiehlt vertragliche Vereinbarungen mit dem OSS-Lieferanten, um die  Aussagekraft der jeweiligen SPDX-Datei zu erhöhen. Der Lieferant könnte danach z.B. verpflichtet sein, die SPDX-Datei korrekt und vollständig zusammen zu stellen ist (vgl. Linux Foundation, SPDX FAQ - How do I know if the information included in the SPDX file is accurate? https://spdx.org/frequently-asked-questions-faq-0).

3. Praktischer Einsatz

Für den OSS-Abnehmer dürfte es rechtlich zunächst am sichersten sein, eine belastbare vertragliche Regelung hinsichtlich des geschuldet Computerprogramms zu finden und weniger hinsichtlich der SPDX-Datei. Das gilt vor allem hinsichtlich der Mangelrechte für Rechtsmängel, insbesondere wenn die Verkehrsfähigkeit der Computerprogramme geschuldet ist (z.B. zum Zweck des Weitervertriebs durch den OSS-Abnehmer).

Eine solche vertragliche Regelung würde dazu führen, dass der OSS-Lieferant die OSS-Komponenten lizenzrechtlich kompatibel kombinieren und korrekt für den Vertrieb einsetzen und ausweisen muss (z.B. Lizenzinformationen und Acknowledgements beigeben). Die Inhalte der SPDX-Datei können danach als Verifikation der übernommenen Pflichten dienen (dazu gleich).

Kann keine Vereinbarung über die Verkehrsfähigkeit oder die Rechtsmängel gefunden werden, dürfte sich auch der Wert der SPDX-Datei in Grenzen halten. Ein OSS-Lieferant in starker Verhandlungsposition, der sich keinen Mangelansprüchen oder einer Haftung wegen Rechtsmängeln aussetzen will, dürfte auch seinen Pflichtenkreis hinsichtlich der SPDX-Datei begrenzen (zur Empfehlung der Linux Foundation, s.o.). Der Grund: Damit vermeidet er eine Haftung für das Computerprogramm durch die (SPDX-)Hintertür, jedenfalls vermeidet er eine vertragliche Widersprüchlichkeit hinsichtlich Mangelrechte am geschuldeten Computerprogramm. Soweit der OSS-Lieferant danach überhaupt Pflichten hinsichtlich der SPDX-Datei eingehen will, dürften diese sich darin erschöpfen, dass die SPDX-Datei nach seinem besten Wissen und Gewissen zusammengestellt wurde. Wurden dem Lieferanten selbst falsche Lizenzinformationen zur Verfügung gestellt, so ist dieser Umstand auch aus der SPDX-Datei eventuell nicht erkennbar.

4. Weiterer Nutzen

Aus der SPDX-Datei erkennbar dürften jedenfalls offensichtliche Fehler im Lizenz-Clearing des Anbieters sein. Anbieter dürften z.B. nicht überzeugen können, wenn die gelieferte SPDX-Datei überhaupt nicht zu dem gelieferten Programm gehört (d.h. wenn deren Package Checksum nicht übereinstimmen) oder wenn die Lizenzinformationen in der SPDX-Datei von denen abweicht, die der Anbieter zusätzlich zu Verfügung stellt (z.B. auf seiner Programmoberfläche).

Des Weiteren können Lizenzkonflikte erkennbar werden, wenn die zur Erstellung des Computerprogramms verwendeten Lizenzen (SPDX: „Concluded License“) inkompatibel sind mit den Lizenzen unter denen das gelieferte Produkt steht (SPDX: „Declared License“). Eine solche Inkompatiblität kann dazu führen, dass das Produkt nicht weiterverbreitet werden kann, z.B. wenn es sich bei einer „Concluded License“ um eine OSS-Lizenz mit Copyleft handelt, die „Declared License“ aber eine (permissive) OSS-Lizenz ohne Copyleft sein soll. Denn der Copyleft einer OSS-Lizenz – wie z.B. der GNU General Public License Version 2 („GPLv2“) – zwingt den Ersteller eines Programms, dieses Programm insgesamt unter die GPLv2 („as a whole“) zu stellen - und unabhängig davon, unter welchen anderen Lizenzen das Programm oder Teile davon steht bzw. stehen soll.

Schließlich dürfte man die Inhalte einer SPDX-Datei extern verifizieren können, z.B. durch Abgleich mit dem Ergebnis der lizenzrechtlichen Code-Analyse des gelieferten Programms durch einen externen Anbieter. Dieses Vorgehen dürft den höchsten finanziellen Aufwand mit sich bringen. Es eignet sich daher z.B. eher bei der Anbahnung oder für Stichproben innerhalb von Geschäftsbeziehungen, die auf längere Dauer angelegt sind. Für die Anbieter der vorgenannten Code-Analysen dürfte es interessant sein, ihre Ergebnisse gleich SPDX-konform präsentieren zu können, um dem Kunden einen schnelleren Abgleich der Ergebnisse bzw. die Erstellung der SPDX-Datei selbst zu ermöglichen.

5. Takeaways

• In praktischer Hinsicht überzeugt vor allem die Möglichkeit die Code-Bestandteile eine Datei verschiedenen Lizenzen zuzuordnen ("Snippet"). Der rechtliche Wert einer SPDX-Datei ist (nur) so gut wie ihr Autor, die ihm vorliegenden Lizenz-Informationen und die vertraglichen Bindung zwischen Autor (OSS-Lieferant) und Adressat (OSS-Abnehmer). Es lohnt sich daher als OSS-Abnehmer auf juristisch vorgebildete Autoren sowie verlässliche Lizenz-Informationen beim OSS-Lieferanten zu setzen.

• Eine SPDX-Datei kann jedenfalls eine Aussage treffen, über die Mindest-Qualität der Lizenz-Compliance bei ihrem Autor – selbst wenn er keinerlei Pflichten hinsichtlich ihres Inhalts übernommen hat:

(1) Die Package Checksum der SPDX-Datei treffen zunächst eine Aussage darüber, ob die Datei überhaupt zu dem gelieferten Produkt gehört oder nicht. Falsche oder veraltete SPDX-Dateien sollten vom OSS-Abnehmer nicht akzeptiert werden.

(2) Der Vergleich von „Concluded Licenses“ und „Declared Licenses“ innerhalb der SPDX-Datei kann Aufschluss darüber geben, ob Lizenzkonflikte beim Einsatz oder Weitervertrieb des Produkts zu erwarten sind.

(3) Das Ergebnis einer lizenzrechtlichen Codeanalyse des Produkts kann mit den Informationen aus der SPDX-Datei abgeglichen werden. Stimmen sie überein, spricht viel für eine hochwertige Lizenz-Compliance beim OSS-Lieferanten.

• Wird die Erstellung von SPDX-Dateien ernsthaft verfolgt, so gilt: Die SPDX-Spezifikation kann ein weiteres Qualitätsmerkmal für die Lizenz-Compliance bei OSS-Lieferanten werden oder bei Dienstleistern, die Zertifizierungen und/oder lizenzrechtliche Code-Analysen anbieten. Es liegt an den OSS-Abnehmern die SPDX-Informationen nicht nur anzufragen, sondern auch zu hinterfragen.