© Maksim Shebeko / 123RF.com

Die von uns vergebenen Open-Source-Lizenzen sollen anderen Nutzer verdeutlichen, wie sie unsere Software nutzen können. Dabei hilft es, wenn sich eine Lizenz automatisiert auslesen lässt.

Basis dieses Beitrags ist Teil 1 dieser Artikelserie, in dem wir uns mit dem Erkennen und dem Auswählen eines Softwarepakets auf Grundlage der vergebenen Lizenzen auseinandersetzten [1]. Nun nehmen wir die umgekehrte Perspektive ein. Wir sehen uns an, wie wir Lizenzen auswählen und so in unser Softwarepaket einbinden, dass andere dessen Verwendungsmöglichkeiten schnell und einfach erfassen können. Wir beleuchten, welche Vorgehensweisen und Werkzeuge sich im Alltag dafür bewährt haben und wie wir diese in den Entwicklungsprozess eigener Software integrieren.

Warum lizenzieren?

Ohne die Angabe einer Lizenz wissen Dritte nicht, unter welchen Bedingungen sie Ihr Werk oder Ihre Software überhaupt verwenden können. Zudem bleibt unklar, was sie beachten müssen, wenn sie das Werk auf die Bedürfnisse ihres konkreten Anwendungsfalls zuschneiden, es also anpassen und beispielsweise Änderungen am Quellcode vornehmen.

Die Lizenz bringt dabei Ihren Willen als Entwickler zum Ausdruck, regelt eindeutig den Umgang mit dem Werk für alle Seiten und beugt Missverständnissen und Streitigkeiten vor. Voraussetzung ist, dass alle Beteiligten die gewählte(n) Lizenz(en) und die damit verknüpften Regeln kennen und respektieren.

Welche Lizenzen?

Es gibt keine ideale Lizenz, die Sie für jeden Fall verwenden können. Die Auswahl hängt vielmehr von verschiedenen Faktoren ab:

• Welche Lizenzen verwenden abhängige Werke oder (Software-)Pakete?
• Welche Lizenzen bevorzugen andere Teammitglieder?
• Wie einfach und freizügig (permissiv) soll Ihr Werk sein?
• Wie wichtig ist es Ihnen, dass Erweiterungen und Änderungen ebenfalls wieder geteilt werden?

Für die interaktive Auswahl bietet sich der Joinup Licensing Assistant (Abbildung 1) der Europäischen Kommission [2] an, den Sie per Webbrowser bedienen. Durch Auswahl der jeweiligen Eigenschaften filtern Sie sukzessive diejenigen Softwarelizenzen heraus, die all Ihren Bedürfnissen entsprechen. Die passenden Lizenzen erscheinen am Ende unterhalb der Tabelle. Die Sortierung erfolgt absteigend anhand des Grads der Übereinstimmung mit den zuvor gesetzten Kriterien. Je genauer Sie die Vorgaben wählen, umso präziser fällt die Ergebnisliste aus.

Abbildung 1: Der Joinup Licensing Assistant der Europäischen Kommission hilft beim Aussuchen einer passenden Lizenz.

Lizenzangaben

Nun gilt es die Frage zu beantworten, wie und insbesondere wo die Lizenzangaben konkret zu hinterlegen sind. Viele Open-Source-Lizenzen verlangen, dass das Lizenzdokument dem Werk beiliegt. Üblicherweise erfolgt dies in einer separaten Datei namens »LICENSE«. Dienste wie Github und Gitlab erwarten eine solche Lizenzdatei auf oberster Ebene (Abbildung 2).

Abbildung 2: Eine automatisch generierte Lizenz bei Github.

In der Datei stehen der Name der Lizenz sowie alle Lizenzbedingungen. Damit aus der »LICENSE«-Datei die Lizenz automatisch ausgelesen werden kann, muss sie die passenden Formulierungen oder Schlüsselworte enthalten. Github verwendet dafür eine eigene Bibliothek [3], auf die Sie mittels einer Rest-API zugreifen. Weitere Quellen sind beispielsweise Spdx.org [4], Choose A License [5] und Gnu.org [6].

Erzeugen Sie via Github ein neues Repository zur Versionskontrolle für das Projekt, geben Sie die Lizenz gleich mit an (Abbildung 3) – wohlgemerkt nur eine einzige Lizenz, da Github Mehrfachlizenzierung (bislang) nicht unterstützt.

Abbildung 3: So sieht die Lizenzauswahl bei Github aus.

Zusatzinfos

Komplexer wird es bei einer Mehrfachlizenzierung für unterschiedliche Nutzungszwecke oder auch, wenn die einzelnen Bestandteile des Gesamtprojekts unter verschiedenen Lizenzen stehen. Nicht alle Werkzeuge zur Paketverwaltung und Auswertung kommen damit zurecht, wenn Sie mehrere »LICENSE«-Dateien beilegen oder mehrere Lizenzen in einer einzigen Lizenzdatei ausliefern. Diesbezüglich hat sich zwar mittlerweile einiges getan, insgesamt herrscht jedoch immer noch ziemlicher Wirrwarr.

Sowohl das DEB- als auch das RPM-Format unterstützen mehrere Lizenzen pro Softwarepaket. Für DEB-Pakete, die sogar mehrere Lizenzangaben pro im Paket enthaltener Datei erlauben, beschreibt das Debian Packaging Manual [7] die Vorgehensweise. In Listing 1 sind über Wildcards alle Dateien mit Pfadangabe und jeweiliger Lizenz aufgeführt. Listing 2 zeigt, wie sich mehrere Lizenzen für eine Datei angeben lassen. Im Beispiel stehen die Javascript-Dateien sowohl unter der Mozilla-Lizenz (MPL) als auch unter der GPLv2 bereit. Im Abschnitt »License:« hinterlegen Sie dann den vollständigen Lizenztext.

Files:
 *
Copyright: 1975-2010 Ulla Upstream
License: GPL-2+
Files:
 debian/*
Copyright: 2010 Daniela Debianizer
License: GPL-2+
Files:
 debian/patches/fancy-feature
Copyright: 2010 Daniela Debianizer
License: GPL-3+
Files:
 */*.1
Copyright: 2010 Manuela Manpager
License: GPL-2+

Files: src/js/editline/*
Copyright: 1993, John Doe
           1993, Joe Average
License: MPL-1.1 or GPL-2
License: MPL-1.1
 <I>Vollständiger Lizenztext<I>
License: GPL-2
 <I>Vollständiger Lizenztext<I>

Für RPM-Pakete beschreiben der RPM Packaging Guide [8] sowie die Fedora Licensing Guidelines [9], wie Sie die Lizenz angeben müssen. Hier kommt das SPDX-Format zum Einsatz. Eine fein abgestufte Lizenzangabe pro Datei im Paket wie in Listing 1 klappt damit allerdings nicht. So bleibt Ihnen als Paket-Maintainer nur der Ausweg, die Software in mehrere, einzelne Pakete zu zerlegen, um die Lizenz genau angeben zu können.

Etwas einfacher wird es, wenn der gesamte Quellcode eines Pakets dual lizenziert ist. In der SPEC-Datei legen Sie fest, aus welchen Komponenten sich das RPM-Paket zusammensetzt. Listing 3 enthält einen Vorschlag zur Angabe der Lizenz in der SPEC-Datei des RPM-Pakets. Laut RPM-Spezifikation müssen sich die beiden Lizenztexte in separaten Dateien befinden statt direkt in der SPEC-Datei.

License: MPL-1.1 OR GPL-2.0-or-later

Häufig gibt es in Paketen auch noch sprachspezifische Dateien mit Metainformationen. Für moderne Python-Pakete verwendet man eine Datei namens »pyproject.toml« [10]. Als Lizenzangabe dient hier entweder der Name der Lizenz, der Verweis auf eine Lizenzdatei oder eine Angabe mit dem Trove Classifier »License :: …«. Abbildung 4 zeigt als Beispiel die Angaben für die Bibliothek Matplotlib [11].

Abbildung 4: So sehen die Lizenzangaben bei der Bibliothek Matplotlib aus.

Während die »LICENSE«-Datei alle Lizenzen nennt, lässt der Trove Classifier [12] nur eine einzige Lizenz daraus zu. Das ist insofern unglücklich, als der Classifier auch an anderen Stellen ausgewertet wird, beispielsweise im Python Package Index. Dort erscheint dann ebenfalls nur diese eine Lizenz. Die anderen Lizenzen, die in der »LICENSE«-Datei angegeben sind, fallen unter den Tisch.

Ärgerlich sind zudem die unterschiedlichen Bezeichnungen für die Lizenzen. Sie machen eine Recherche und einen Vergleich der gewählten Lizenzierungen komplizierter als eigentlich notwendig [13]. Eine Vereinheitlichung tut hier dringend Not.

Richtig implementieren

Um Klarheit zur Lizenz zu bekommen, hilft das Konzept rund um SPDX [14]. Wie im ersten Teil dieser Serie schon angerissen, bietet es eine standardisierte Lösung für die beschriebenen Probleme.

Jede Quellcodedatei enthält am Anfang einen passenden Eintrag als Kommentar. Er beginnt mit dem Text »SPDX-License-Identifier:«, darauf folgt die gewählte Lizenz für den Programmcode. Listing 4 zeigt das für die Nutzung der GNU Public License v3 oder später. Diese Schreibweise erlaubt dank der standardisierten Formulierung ein maschinelles, automatisiertes Auslesen. Das schließt eine Fehlinterpretation der Lizenz aus.

# SPDX-License-Identifier: GNU General Public License v3.0 or later

Externe Unterstützung

Unterstützung bei der Lizenzauswahl ist stets hilfreich, da die große Vielfalt an Lizenzmodellen das Verständnis erschwert. Hier helfen sowohl das GNU-Projekt als auch Wikipedia [15] und Choose A License mit Hinweisen und Übersichten weiter.

Die Free Software Foundation Europe (FSFE) lässt sich diesbezüglich ebenfalls nicht lumpen und bietet sich als kompetenter Anlaufpunkt an. Dazu haben wir Lina Ceballos von FSFE befragt, wie die Hilfe im Rahmen des REUSE-Projekts [16] konkret aussieht (siehe Kasten “Interview mit Lina Ceballos”).

Nicht zu vergessen sind auch auf Lizenzrecht spezialisierte Beratungsfirmen und Rechtsanwälte, die weitere Klarheit bringen können.

Fazit

Bislang lag unser Blick primär auf Software und ihre korrekte Lizenzierung. Was noch fehlt, aber nicht übersehen werden darf, sind Daten und Datenströme, Bilder, Dokumentation, Mediadaten und Hardware. Diesem Thema widmen wir uns im nächsten Teil dieser Serie. (jlu)