© Andrey Popov / 123RF.com

Softwarelizenzen teilen uns mit, wie wir Softwarepakete verwenden und die Software rechtlich zulässig in eigenen Projekten nutzen dürfen. Erfreulicherweise gibt es mittlerweile Werkzeuge, mit denen sich das automatisch überprüfen lässt.

Haben Sie Ihre Programmkomponente aus einem GPL-lizenzierten Softwarepaket abgeleitet, werden Sie Ihre Software unter derselben GPL-Lizenz veröffentlichen müssen. Kombiniert das Programm dagegen LGPL-lizenzierten Code mit Ihrem eigenen Werk, dürfen Sie das Ergebnis unter einer neuen, gegebenenfalls auch proprietären Lizenz verbreiten. Dieselben Möglichkeiten hätten Sie auch, wenn Sie Ihre Software aus einem BSD-lizenzierten Paket abgeleitet haben.

Obwohl GPL, LGPL und BSD allesamt zu den Lizenzen für freie Software zählen, erlauben sie sehr unterschiedliche Nutzungen. Um die prinzipiellen Unterschiede genauer herauszuarbeiten, teilt man die Softwarelizenzen verschiedenen Kategorien zu.

Außerhalb der Open-Source-Welt sind proprietäre Softwarelizenzen am häufigsten. Sie folgen nur selten einem Standard. Neben den weitverbreiteten kommerziellen Lizenzen zählen auch Shareware und Freeware in diese Kategorie.

Kategorisches

Freie und Open-Source-Softwarelizenzen werden von der Free Software Foundation (FSF [1]) und der Open Source Initiative (OSI [2]) definiert. Dabei kann man im Wesentlichen zwischen Copyleft-, freizügigen und gemeinfreien Lizenzen unterscheiden.

Copyleft-Lizenzen verpflichten den Lizenznehmer, jegliche Bearbeitung der Software (sogenannte Derivate) unter die Lizenz des ursprünglichen Werks zu stellen. Dieser deshalb auch als reziprok bezeichnete Lizenztyp soll Nutzungseinschränkungen der Software verhindern. Die bekannteste Copyleft-Lizenz ist zweifellos die GNU General Public License (GPL [3]). Das Copyleft der GPL gilt als sehr stark, wohingegen das der Mozilla Public License [4] als recht schwach angesehen wird.

Da die Lizenzgeber nicht selbst an ihr eigenes Copyleft gebunden sind, können sie neue Versionen unter einer proprietären Lizenz veröffentlichen oder dasselbe Dritten erlauben. Man spricht dann von einer Mehrfachlizenzierung.

Durch Copyleft-Lizenzen können bei der Verbreitung zusammen mit Software unter anderen freien Lizenzen jedoch schnell Inkompatibilitäten entstehen. So ist etwa die 3-Clause-BSD-Lizenz mit der GPL inkompatibel. Bei der European Union Public License (EUPL [5]) handelt es sich hingegen um eine mit den meisten anderen offenen reziproken Lizenzen kompatible und interoperable reziproke Lizenz: Die kompatiblen Lizenzverpflichtungen haben Vorrang, wenn sie mit den sich aus der EUPL ergebenden Verpflichtungen in Konflikt geraten [6].

Freizügige oder permissive Open-Source-Lizenzen erlauben eine breitere Wiederverwendung als die Copyleft-Lizenzen. Ableitungen und Kopien des Quellcodes darf man unter Bedingungen verbreiten, die grundlegend andere Eigenschaften haben als die Originallizenz. Die bekanntesten Beispiele für permissive Open-Source-Lizenzen sind die MIT- [7] und die BSD-Lizenz [8].

Schließlich gibt es noch die gemeinfreien oder neuhochdeutsch Public-Domain-Lizenzen: Bei ihnen gehen die Urheberrechte an die Allgemeinheit über. Zur Kennzeichnung der Gemeinfreiheit von Software wurde die Unlicense [9] aus der Taufe gehoben.

Jenseits von Software

Manche Open-Source-Softwarelizenzen lassen sich auch für Werke verwenden, bei denen es sich nicht um Software handelt. Oft stellen sie tatsächlich die beste Wahl dar, insbesondere, wenn man die betreffenden Werke als Quelltext bearbeitet und sie versioniert.

Hingegen sind die populären Creative-Commons-Lizenzen explizit nicht für Software gedacht [10], sondern für Daten, Medien und Dokumentation. Für Daten und Datenbanken hat die Open Knowledge Foundation [11] die Open-Data-Commons-Lizenzen [12] formuliert. Die Tabelle “Lizenzen jenseits von Software” stellt die Varianten von Nicht-Software-Lizenzen gegenüber. Das schließt mittlerweile auch Varianten für Open-Source-Hardware [13] mit ein.

Wie eingangs beschrieben, steht Ihnen die Auswahl der Lizenz für Ihre Programme nur dann frei, wenn Sie Ihr Werk nicht von anderer Software abgeleitet oder es mit anderer Software kombiniert haben. Die Lizenzkompatibilität [14] für abgeleitete oder kombinierte Werke aus eigener Software und externem Code, der einer Open-Source-Lizenz unterliegt, stellt Abbildung 1 dar.

Abbildung 1: Übersicht zur Kompatibilität abgeleiteter Softwarelizenzen. Quelle: Quelle: Wikimedia Commons, CC0 1.0

Lizenzen abgeleiteter oder kombinierter Werke finden Sie auf verschiedenen Wegen, entweder von Hand oder per Software. Ersteres trifft zu, wenn das Projekt auf Github gehostet ist. Dann steht die Lizenz entweder in der »license«-Datei oder befindet sich im Verzeichnis »license/«. Dazu sehen Sie im Repository des Projekts nach, ob sich dort eine Lizenz findet. Falls nicht, gilt der nächste Blick den Hinweisen in der Datei »README«.

Per Software lassen sich Lizenzen mit Werkzeugen wie Liccheck [15] oder REUSE [16] identifizieren.

Liccheck

Liccheck ist für diejenigen interessant, die Python in ihren Projekten verwenden – entweder direkt oder als Paketabhängigkeit.

Zu den festen Bestandteilen eines jeden Python-Pakets zählt eine Datei namens »requirements.txt«. Darin legt der Programmierer fest, welche anderen Python-Packages das Python-Paket benötigt, um zu funktionieren. Liccheck überprüft die Lizenzen der in dieser Datei aufgezählten Pakete und zeigt alle entdeckten Lizenzkonflikte an.

Zuvor legen Sie noch eine Strategie fest, anhand derer Liccheck seine Prüfung vornimmt: Welche Lizenzen soll es als Verstoß werten, welche nicht? Je genauer diese Vorbereitung erfolgt, desto exakter fällt das Ergebnis der Prüfung aus. Listing 1 zeigt den Aufruf und die Analyse zum Python-Modul cryptography [17].

$ liccheck -s liccheck.ini -r requirements.txt
gathering licenses...
3 packages and dependencies.
check unknown packages...
3 packages.
  cffi (1.15.1): ['MIT']
    dependency:
      cffi << cryptography
  cryptography (41.0.3): ['Apache Software', 'BSD']
    dependency:
      cryptography
  pycparser (2.21): ['BSD']
    dependency:
      pycparser << cffi << cryptography

REUSE

Das REUSE-Projekt [18] entstand unter der Federführung der Free Software Foundation Europe (FSFE) und basiert auf zwei Säulen: maschinell lesbaren Copyright-Dateien aus dem Debian-Projekt und SPDX [19]. SPDX steht für Software Package Data Exchange und definiert eine standardisierte Methode für den Austausch von Copyright- und Lizenzinformationen zwischen Projekten und Menschen [20].

REUSE bietet sowohl die Anleitung als auch das Werkzeug Reuse [21], sodass Ihr Projekt damit die richtigen Lizenzangaben bekommt. Die Projektwebseite (Abbildung 2) stellt REUSE anderen Lösungen [22] gegenüber, darunter Scancode [23], ClearlyDefined [24], Fossology [25] und OpenChain [26].

Abbildung 2: Die Homepage des FSFE-Projekts REUSE. Quelle: FSFE e.V.

Das Kommandozeilenwerkzeug Reuse basiert auf Python. Die Installation via Pip ist erfreulicherweise vollständig dokumentiert. Seit Debian GNU/Linux 12 “Bookworm” ist die Software zudem als gleichnamiges Debian-Package [27] in den Paketquellen verfügbar.

Reuse bietet eine ganze Reihe nützlicher Funktionen. Die beschränken sich keineswegs auf das Hinzufügen von Copyright- und Lizenzinformationen im Kopf einer Datei (Unterbefehl »annotate«) oder das Vorbereiten eines Projekts gemäß der REUSE-Vorgaben (»init«). Hinzu kommen außerdem das Prüfen eines Projekts auf Übereinstimmung mit den REUSE-Vorgaben (»lint«) und das Erzeugen eines SPDX-Dokuments mit allen Dateien aus dem Projekt (»spdx«).

Listing 2 zeigt das Reuse-Prüfergebnis zum Python-Modul cryptography. Schon auf den ersten Blick wird klar, dass mehrere Dateien keine Urheberrechts- und Lizenzinformationen enthalten und das Modul somit nicht der REUSE-Spezifikation entspricht.

$ cd cryptography
$ reuse lint
# FEHLENDE URHEBERRECHTS- UND LIZENZINFORMATIONEN
Die folgenden Dateien haben keine Urheberrechts- und Lizenzinformationen:
* .gitattributes
* .github/ISSUE_TEMPLATE/openssl-release.md
[...]
* vectors/cryptography_vectors/x509/wosign-bc-invalid.pem
* vectors/pyproject.toml
Die folgenden Dateien haben keine Lizenzinformationen:
* docs/_ext/linkcode_res.py
* src/cryptography/__about__.py
# ZUSAMMENFASSUNG
* Falsche Lizenzen: 0
* Veraltete Lizenzen: 0
* Lizenzen ohne Dateiendung: 0
* Fehlende Lizenzen: 0
* Unbenutzte Lizenzen: 0
* Verwendete Lizenzen: 0
* Read errors: 0
* files with copyright information: 2 / 2806
* files with license information: 0 / 2806
Allerdings ist Ihr Projekt nicht konform mit Version 3.0 der REUSE-Spezifikation :-( $

Lizenz auswählen

Sind die Lizenzen der einzelnen Werke geklärt, steht die Wahl der Lizenz für Ihr eigenes Projekt an. Hilfestellung bietet hier neben Github auch SPDX. Dazu wählen Sie zunächst die passenden SPDX-Begriffe [28] aus und fügen sie dann dem Kopf der Lizenzbeschreibung oder Ihrer Software hinzu. Die Tabelle “SPDX-Bezeichner (Auswahl)” listet die wichtigsten SPDX-Bezeichner auf. Mit Reuse können Sie später überprüfen, ob Sie den angepeilten Standard auch eingehalten haben.

Nach der Auswahl einer Lizenz müssen Sie sie noch mit den Lizenzen der verwendeten Werke abgleichen und auf Konflikte hin überprüfen. Tritt dabei kein Konflikt auf, passt alles. Fördert die Überprüfung doch einen Konflikt zutage, müssen Sie die gewählte Lizenz überdenken und anschließend den Kontrollschritt wiederholen.

Nie ohne Lizenz

Zu Software gehört eine Softwarelizenz einfach dazu. Für freie Software [29] wählen Sie aus einer recht großen Palette aus. Eine Übersicht dazu stellt beispielsweise die Open Source Initiative (OSI) zusammen.

Als Autor wählen Sie passende Lizenzbestimmungen aus, die Sie Ihrem Werk in Textform beifügen. Mit der Lizenz legen Sie fest, was andere mit Ihrem Werk tun dürfen. Das betrifft sowohl die private Nutzung als auch den kommerziellen Einsatz. Eine Mehrfachlizenzierung liegt vor, wenn Sie für die beiden Nutzungsarten unterschiedliche Lizenzen angeben. Listing 3 zeigt das für das Python-Modul cryptography.

This software is made available under the terms of *either* of the
licenses found in LICENSE.APACHE or LICENSE.BSD. Contributions to
cryptography are made under the terms of *both* licenses.
The code used in OpenSSL locking callback and OS random engine is
derived from the same in CPython, and is licensed under the terms
of the PSF License Agreement.

Dabei gibt es einige Fallen, die später für ungewollte Konflikte sorgen, beispielsweise, wenn Sie die Server Side Public License (SSPL [30]) verwenden. Die OSI hat festgestellt, dass sie nicht mit ihrer Open-Source-Definition übereinstimmt. Sie kommt jedoch bei bedeutenden Softwareprojekten wie dem DBMS MongoDB [31], der Suchmaschine Elasticsearch [32] und dem Visualisierungswerkzeug Kibana [33] zum Einsatz.

Die Wahl einer proprietären Softwarelizenz ist legitim, jedoch fehlen dafür Standards. Das macht Vergleiche komplizierter. So lizenzierte Programme können kommerzielle Programme im engeren Sinn sein, aber auch Share- oder Freeware. Bei gemeinfreien oder Public-Domain-Lizenzen gehen die Urheberrechte an die Allgemeinheit über. Zur Kennzeichnung der Freigabe weitestmöglicher Nutzungsrechte wurde die Creative-Commons-Zero-Lizenz [34] erstellt.

Würden Sie Ihrem Werk hingegen überhaupt keine Lizenz beifügen, müsste jeder Interessent erst bei Ihnen nachfragen, wie Sie sich die Benutzung Ihrer Software vorstellen, sprich: welche Rechte Sie gewähren und welche Pflichten auf einen Benutzer zukommen. Dasselbe gilt umgekehrt, wenn Sie Software oder Bibliotheken benutzen möchten, denen der Urheber keine Lizenz beigefügt hat: Dann liegt der Aufwand zur Klärung der Situation bei Ihnen als Nutzer.

Dieser Weg der Rückfrage stellt zwar das übliche Verfahren beim Verwenden fremder Werke dar, ist aber schlicht und ergreifend umständlich und behindert schnelle Entscheidungen, wie sie heute vielfach stattfinden. Es lässt sich deshalb nicht ausschließen, dass der Interessent dann entweder Ihr Werk benutzt, ohne vorher Ihre Vorstellung zur Verwendung zu erfragen, oder stattdessen ein anderes Werk auswählt, das klar und eindeutig lizenziert ist, um möglichen Streitigkeiten mit Ihnen aus dem Weg zu gehen. Harald Welte dokumentiert entsprechende Streitfälle seit 2004 mit seinem Projekt GPL Violations [35].

Hilfestellung

Die Auswahl der richtigen Lizenz ist nicht immer einfach. Mehrere Projekte, darunter die Free Software Foundation [36], Github [37] und Wikipedia [38], machen sich daher die Mühe, online Ratgeber anzubieten (Abbildung 3). Darin stellen Sie die Ziele der unterschiedlichen freien Lizenzen gegenüber [39] und beschreiben deren Anwendungsfälle [40]. Die FSFE bietet daneben ihre Unterstützung bei der Überprüfung von Lizenzkonformität in Form rechtlicher Beratung durch eine Rechtsfachkraft an [41].

Abbildung 3: Online-Ratgeber helfen dabei, die richtige Lizenz für Ihr Softwareprojekt auszuwählen. Quelle: Github Inc. / You!

Diese Möglichkeiten verschaffen Ihnen den passenden Durchblick und erleichtern den Weg durch das rechtliche Dickicht, sofern es sich um Einzelprojekte handelt. Bei einer Mehrfachlizenzierung wie im Beispiel aus Listing 3 oder unterschiedlichen Lizenzen für die enthaltenen Dateien/Komponenten steigt beispielsweise Github aus. Es kann mit einem solchen Fall nicht sauber umgehen, bislang können Sie dort pro Projekt nur eine einzige Lizenz hinterlegen.

Abbildung 4: Einige Beispiele für die von Shields.io erzeugte Lizenzschilde. Quelle: Shields.io

Fazit

Im vorliegenden Beitrag haben wir die verschiedenen Softwarelizenzen beleuchtet, sind auf deren Nutzung eingegangen und haben auf die Fallstricke hingewiesen, die es dabei zu berücksichtigen gilt. Daneben haben wir Ihnen Methoden und Werkzeuge vorgestellt, mit denen Sie die Lizenz einer von Ihnen verwendeten Software automatisiert erkennen können.

In einem Folgeartikel werden wir besprechen, wie Sie einem eigenen Python-Paket und dessen Dokumentation eine oder mehrere Lizenzen hinzufügen. Wir stellen Ihnen dabei die Vorgehensweisen und Werkzeuge vor, die sich dazu im Alltag bewährt haben, und zeigen, wie wir sie in den Entwicklungsprozess integrieren. (jlu)