Zwischen all den Aufgaben, mit denen Entwickler täglich zu tun haben, wird das Thema Software-Lizenzierung oft nur am Rande behandelt. Klar ist: Lizenzierung muss sein. Doch wenn es darum geht, die passende Lizenz auszuwählen, übernommenen Code korrekt zu kennzeichnen und alles konsistent zu halten, wird Lizenz-Management schnell zu einer bürokratischen Last.
Genau hier setzt das REUSE-Projekt an, welches von der Free Software Foundation Europe (FSFE) betreut wird. Es versucht daheo nicht, die rechtliche Arbeit bei der Wahl einer Lizenz oder der Entschlüsselung von Verpflichtungen zu ersetzen. Stattdessen konzentriert sich REUSE auf die praktische Umsetzung von Lizenzierung – also darauf, wie sich Lizenzinformationen klar, eindeutig und verlässlich direkt im Code selbst kommunizieren lassen. Zahlreiche Projekte setzen bereits auf REUSE, darunter SAP, Nextcloud und viele Rollen und Collections aus der Ansible-Community.
Vor Kurzem bin ich selbst tief in das Thema Lizenzierung und Supply Chain eingetaucht. Ich musste herausfinden, wie sich REUSE auf unsere Open-Source-Projekte anwenden lässt und gleichzeitig anderen in unserem Team und bei Kunden erklären, wie es funktioniert. Das war eine spannende Doppelrolle: lernen und lehren zugleich. Daraus entstanden viele Erkenntnisse darüber, was an REUSE praktisch ist, wo es hakt, und wie es im Alltag hilft. Dieser Artikel möchte genau diese Erfahrungen weitergeben – als Ergänzung zu reinen Schnellstart-Anleitungen.
Wer Video lieber mag: Ich habe hierzu auch einen REUSE-Vortrag auf der GPN23 gehalten (er enthält im wesentlichen den gleichen Inhalt wie der Text):
Warum Lizenzierung sich noch immer „kaputt“ anfühlt
Wer schon einmal versucht hat, die Lizenzierung in einem Code-Repository mit Beiträgen aus verschiedensten Quellen nachzuvollziehen, oder Software zu paketieren und dabei auf widersprüchliche oder unklare Lizenzangaben gestoßen ist, kennt das Problem aus erster Hand. Es ist ein häufiger Schmerzpunkt.
Das Projekt beginnt. Eine LICENSE-Datei kommt ins Wurzelverzeichnis. Vielleicht ist es MIT, vielleicht Apache 2.0, vielleicht GPLv3-or-later lizensiert. Man denkt: Das reicht schon. Und tatsächlich erkennen Tools wie Licensee, das auch GitHub verwendet, diese Datei und melden das Projekt als einheitlich lizenziert – basierend auf dem, was dort steht.
Aber das ist nur ein Teil des Ganzen.
Echte Projekte werden mit der Zeit chaotischer. Dateien stammen aus Pull Requests, Upstream-Forks, alten Backups oder fremden Repositories. Manchmal wird ein Skript von Stack Overflow eingefügt. Oder jemand kopiert die Ausgabe eines Codegenerators. Nach und nach wird das Repository zu einem Sammelsurium aus Dateien mit unklarer Herkunft. Die LICENSE-Datei im Root-Verzeichnis kann all das nicht mehr zuverlässig abdecken. Tools wie Licensee merken das nicht – und oft geht es dem Entwicklungsteam genauso.
Fehlen klare Lizenzinformationen im Quellcode, wird es für andere schwierig, die Software weiterzuverwenden oder daran mitzuwirken. Leider können Tools zur automatischen Lizenzerkennung keine rechtlich belastbare Sicherheit bieten. Sie arbeiten mit unscharfem Abgleich, Heuristiken und Annahmen wie: „ein Projekt, eine Lizenz“. Das reicht nicht, wenn es auf rechtliche Klarheit ankommt. Automatische Lizenzheuristiken sind kompliziert und werden niemals zuverlässige Ergebnisse für alle möglichen Anwendungsfälle liefern.
FSFE REUSE zur Rettung
Anstatt zu versuchen, Lizenzinformationen zu erraten oder herzuleiten, fordert REUSE Entwickler dazu auf, diese explizit, maschinenlesbar und überprüfbar bereitzustellen:
- Jede verwendete Lizenz muss als Textkopie im Verzeichnis
LICENSES/1 im Wurzelverzeichnis des Projekts abgelegt werden. - Jede Datei im Projekt muss mit maschinenlesbaren Copyright- und Lizenzangaben versehen sein.
Nochmals: Das ist wichtig. So lässt sich jede einzelne Datei im Repository sofort rechtlich einordnen – sei es durch ein Audit, beim Paketieren, durch Mitwirkende oder Compliance-Teams. Es braucht keine Vermutungen, keine Querverweise, kein „vielleicht ist das MIT, weil der Rest der Projekts ja auch MIT ist“. Alles ist klar, standardisiert und mit reuse lint auch automatisiert prüfbar – ideal für Projekte mit Continuous Integration.
Nach dem REUSE-Standard können Lizenz- und Copyright-Informationen auf verschiedene Weise hinterlegt werden:
- Kommentarzeilen im Quellcode oder alternativ
<dateiname>.licensefür Dateien, die keine Kommentare unterstützen. REUSE.toml– eine zentrale, maschinenlesbare Datei zur Beschreibung ganzer Dateien oder Verzeichnisse. Besonders hilfreich ist sie, um:- eine Standardlizenz für das gesamte Projekt festzulegen.
- abweichende Lizenzen für Drittanbieter-Komponenten in Unterverzeichnissen zu definieren.
Die klar definierte REUSE-Spezifikation wird dabei durch und ein schlankes reuse-Kommandozeilentool unterstützt. Damit lässt sich der Standard mit weniger Aufwand einführen, auch wenn alles notfalls von Hand machbar ist. REUSE fügt sich dabei gut ins bestehende Open-Source-Ökosystem ein, unter anderem durch die Verwendung von Software Package Data Exchange (SPDX) und SPDX-Lizenzkennungen.
Verwendung
Das offizielle REUSE-Tutorial und der Abschnitt zur Tool-Nutzung sind wirklich gut gemacht – daher folgt hier nur ein kompakter Schnellstart:
- Die verwendeten Lizenzen ins Verzeichnis
LICENSES/legen. - Einen Kommentar-Header in jede Datei einfügen, z. B.:
Das Format ist dabei recht flexibel, solange die Zeilen mit
SPDX-License-Identifier: GPL-3.0-or-later SPDX-FileCopyrightText: $YEAR $NAMESPDX-License-Identifier:und/oderSPDX-FileCopyrightText:beginnen. Es muss nicht an erster Stelle stehen und auch Leerzeilen sind möglich. Wichtig ist dennoch, dass es weit oben in einer Datei / in einem Header-Kommentar steht. Technisch ist es nicht notwendig, aber nur so kann ein Mensch diese wichtige Information direkt nach dem Öffnen einer Datei sehen.
Kommentar-Header
REUSE und viele Organisationen wie etwa GNU empfehlen, Lizenz-Header direkt in den Quellcode zu schreiben. Das hilft, Missverständnisse und Fehler zu vermeiden. Auch wenn eine zentrale REUSE.toml-Datei vorhanden ist, kommt es vor, dass einzelne Dateien in andere Projekte kopiert oder geforkt werden – und dort fehlt dann womöglich der Kontext oder die Lizenzdokumentation.
Ohne einen Lizenzhinweisdirekt in der Datei kann beim Weiterverwenden daher schnell die rechtliche Zuordnung verloren gehen. Ein klarer Kommentar schützt davor, selbst in Projekten ohne perfektes Lizenzmanagement.
Beispiel für einen einfachen Lizenz-Header:
# SPDX-FileCopyrightText: Andreas Haerter, ACME Corp (https://example.com)
# SPDX-License-Identifier: CC-BY-SA-4.0
Beispiel mit Dual-Lizenzierung:
/*
SPDX-FileCopyrightText: Jane Doe <j.doe@example.com>
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later
*/
REUSE.toml
Man könnte auch versucht sein, auf das Einfügen von Kommentar-Headern in jeder einzelnen Datei zu verzichten und stattdessen nur eine zentrale REUSE.toml zu verwenden – das ist legitim und bleibt REUSE-konform. Besonders bei vielen Dateien oder bei Drittanbieter-Code kann das deutlich praktischer sein, da man diese eventuell nicht verändern und stets als Kopie der originalen Quelle im Projekt haben will.
Mit einer REUSE.toml lassen sich auch ganze Verzeichnisse in einem Schritt lizenzieren. Das Format der Datei ist klar definiert, aber ein einfaches Beispiel zeigt am besten, wie es funktioniert:
version = 1
SPDX-PackageName = "Foo bar project"
SPDX-PackageDownloadLocation = "https://git.example.com/foobar"
SPDX-PackageSupplier = "ACME Inc. (https://example.com)"
[[annotations]]
path = "**"
precedence = "closest"
SPDX-FileCopyrightText = "ACME Inc."
SPDX-License-Identifier = "LGPL-2.1-or-later"
Damit wird das gesamte Projekt unter die angegebene Lizenz gestellt. Ausnahmen oder spezielle Regeln für bestimmte Dateien können natürlich ebenfalls über einzelne annotations ergänzt werden.
Überprüfung
Sobald alle Lizenzinformationen ergänzt wurden, lässt sich das Projekt ganz einfach mit reuse lint überprüfen:
$ reuse lint
[...]
Congratulations! Your project is compliant with version 3.4 of the REUSE Specification :-)
So bekommt man schnell Feedback, ob alles korrekt eingebunden wurde, ideal für automatisierte Tests oder Continuous Integration-Workflows.
Demo
Die FSFE erstellte einen kleinen Screencast2, der dem Tutorial folgt und das REUSE-Beispiel-Repository konform macht:
Tipps und Tricks
Benötigtes Vokabular beim Lernen oder Lehren
Wer sich mit Lizenzierung und REUSE beschäftigt, egal ob beim Einstieg oder beim Erklären, stößt schnell auf Begriffe, die hilfreich (oder sogar notwendig) für das Verständnis sind:
- Software Package Data Exchange (SPDX) und SPDX-Lizenz-Identifikatoren: Ein Standard zur einheitlichen Bezeichnung von Lizenzen mit kurzen, konsistenten Kürzeln (wie
MIToderGPL-3.0-only). Das vereinfacht die automatische Auswertung und Dokumentation von Lizenzinformationen. - Software Bill of Materials (SBOM): Eine strukturierte Auflistung aller Software-Komponenten und deren Lizenzen in einem Projekt. Hilft bei Transparenz, Sicherheit und rechtlicher Nachvollziehbarkeit.
- Copyleft (Lizenztyp): Ein Ansatz, der sicherstellt, dass abgeleitete Werke unter derselben Lizenz weitergegeben werden müssen. So bleiben Nutzungsfreiheiten erhalten. Ein bekanntes Beispiel ist die GPL.
- Permissive (Lizenztyp): Eine eher freizügige Lizenz, die eine Wiederverwendung des Codes mit nur wenigen Bedingungen erlaubt – auch in proprietären Projekten. Typische Beispiele sind MIT, BSD und Apache 2.0.
- TOML: Ein Dateiformat für Konfigurationen. Die Datei
REUSE.tomlverwendet dieses Format, um Lizenzinformationen anhand von Pfadmustern zu beschreiben. - DEP5: Eine ältere, maschinenlesbare Debian-Formatvorlage zur Lizenzdokumentation. Früher genutzt, bevor
REUSE.tomleingeführt wurde. DEP5 wird noch unterstützt, gilt aber als veraltet – wichtig zu wissen, falls man auf ältere Tutorials oder Tools trifft.
Mein persönliches Killer-Feature: Zusätzliche Kommentare in REUSE.toml
Es mag nach einer Kleinigkeit klingen, aber für mich war es immer umständlich, die ursprünglichen Download-URLs und andere typische Informationen zu Drittanbieter-Dateien im Blick zu behalten (etwa „dieses kleine Icon, das ich mir da kopiert habe“). Aus meiner Sicht ist die REUSE.toml-Datei der ideale Ort, um solche Zusatzinformationen mit Hilfe von SPDX-FileComment abzulegen. So bleibt das Repository übersichtlich, und auch die Endbenutzer-Dokumentation wird nicht mit für den End-User unnötige Detauls überladen.
Gibt es einmal ein Beispiel dafür, wird das Pflegen solcher Quellvermerke und Hinweise meiner Erfahrung nach schnell zur guten Praxis – selbst in Teams, die ansonsten wenig formale Prozesse haben:
Beispiel 1: REUSE.toml mit Abschnitten, die die ursprünglichen Download-URLs tracken oder Notizen hinzufügen
[...]
[[annotations]]
path = "assets/images/window.svg"
precedence = "closest"
SPDX-FileCopyrightText = "2022 Refactoring UI Inc."
SPDX-License-Identifier = "MIT"
SPDX-FileComment = "https://github.com/tailwindlabs/heroicons/blob/master/optimized/24/outline/window.svg"
[[annotations]]
path = ["extensions/Find-WindowHandle.ps1", "extensions/Helper.ps1"]
precedence = "closest"
SPDX-FileCopyrightText = "2018 Grégoire Geis (https://github.com/71/Focus-Window/)"
SPDX-License-Identifier = "MIT"
SPDX-FileComment = "Slightly adapted for this project by foundata GmbH (https://foundata.com)"
[...]
Beispiel 2: Die REUSE.toml von SAP/openui5, die Dateimuster und Kommentare verwendet, um einzelne Komponenten und Dateien zu tracken, die von anderen Projekten kopiert wurden:
[...]
[[annotations]]
path = "src/sap.ui.integration/test/sap/ui/integration/demokit/cardExplorer/webapp/thirdparty/CfWorkerJsonSchemaValidator.js"
precedence = "aggregate"
SPDX-FileCopyrightText = "2020 Jeremy Danyow"
SPDX-License-Identifier = "MIT"
SPDX-FileComment = "these files belong to: @cfworker/json-schema"
# Library: sap.ui.webc.common:
[[annotations]]
path = [
"src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/base/**",
"src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/theming/**",
"src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/localization/**",
"src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/icons/**",
"src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/icons-tnt/**",
"src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/icons-business-suite/**"
]
precedence = "aggregate"
SPDX-FileCopyrightText = "SAP"
SPDX-License-Identifier = "Apache-2.0"
SPDX-FileComment = "these files belong to: UI5 Web Components"
[...]
README-Abschnitts-Template über Lizenzierung und Copyright für Menschen
Aus meiner Sicht ist es hilfreich, einen generischen, leicht anpassbaren Textbaustein für die README.md oder eine vergleichbare zentrale Datei zu haben. Also dem Ort, den Menschen in der Regel leicht finden und verstehen können. Ich habe dafür eine Textvorlage vorbereitet und im Einsatz, die die bereits vorhandenen REUSE-Informationen in einem Repository nutzt und auf dieser verweist. So bleibt der Abschnitt im Wesentlichen wartungsfrei und ist trotzdem nützlich:
## Licensing, copyright
<!--REUSE-IgnoreStart-->
Copyright (c) YYYY, ACME Inc.
This project is licensed under the GNU General Public License v3.0 or later (SPDX-License-Identifier: `GPL-3.0-or-later`), see [`LICENSES/GPL-3.0-or-later.txt`](LICENSES/GPL-3.0-or-later.txt) for the full text.
The [`REUSE.toml`](REUSE.toml) file provides detailed licensing and copyright information in a human- and machine-readable format. This includes parts that may be subject to different licensing or usage terms, such as third-party components. The repository conforms to the [REUSE specification](https://reuse.software/spec/). You can use [`reuse spdx`](https://reuse.readthedocs.io/en/latest/readme.html#cli) to create a [SPDX software bill of materials (SBOM)](https://en.wikipedia.org/wiki/Software_Package_Data_Exchange).
<!--REUSE-IgnoreEnd-->
YYYY sollte durch das Jahr der ersten Veröffentlichung oder des Code-Beitrags ersetzt werden. Auch Lizenzname, Dateinamen und Links lassen sich je nach Projektbedarf anpassen. Die eingefügten HTML-Kommentare verhindern dabei REUSE-Linting-Fehler – etwa dann, wenn mehrere Lizenzen im Text genannt werden.
Die Formulierung verweist bereits auf die zentrale Lizenzdatei (REUSE.toml) und macht deutlich, dass einzelne Teile des Projekts unter anderen Lizenzbedingungen stehen können als der Hauptteil. Falls das nicht ausreicht, lässt sich der Satz zur Hauptlizenz natürlich gezielt anpassen – um die grundlegenden Lizenzierungsregeln hervorzuheben, ohne jedes Detail an mehreren Stellen pflegen zu müssen. Beispiele (nach Bedarf anpassen):
The project is dual-licensed under the
* GNU General Public License v3.0 or later (SPDX-License-Identifier: `GPL-3.0-or-later`), see [`LICENSES/GPL-3.0-or-later.txt`](./LICENSES/GPL-3.0-or-later.txt) for the full text.
* Apache License 2.0 (SPDX-License-Identifier: `Apache-2.0`), see [`LICENSES/Apache-2.0.txt`](./LICENSES/Apache-2.0.txt) for the full text.
[... das übliche Template folgt ...]
Lizenzerkennung auf Github oder Gitlab
Beim Einsatz von REUSE fällt auf, dass Plattformen wie GitHub und GitLab nicht mehr in der Lage sind, die Lizenz eines Projekts automatisch korrekt zu erkennen.
Auch wenn automatische Lizenzdetektion (wie weiter oben beschrieben) grundsätzlich fehleranfällig und konzeptionell problematisch ist, bleibt nachvollziehbar, warum man trotzdem ein maschinenlesbares Ergebnis möchte. Schließlich wird bei Suchen oder in Projektübersichten oft nach Lizenzen gefiltert und fehlerhafte oder fehlende Metadaten können hier zu Nachteilen in der Auffinbarkeit führen, vor allem wenn suchende Benutzer wenig Erfahrung mit Lizenzierung haben.
Wenn solche automatischen Erkennungsmechanismen daher dennoch bedient werden sollen, kann man einfach die „freiheitsfreundlichste“ Lizenz (bzw. die Hauptlizenz des Projekts) zusätzlich in einer LICENSE- oder COPYING-Datei im Wurzelverzeichnis ablegen. Also ausschließlich zur Nutzung via Suchindizes und GitHub, unabhängig von der eigentlichen REUSE-Struktur:
- GitHub verwendet Licensee, um die Projektlizenz zu erkennen. Licensee unterstützt die REUSE-Spezifikation jedoch nicht.
- Ein möglicher Workaround besteht darin, eine zusätzliche
LICENSE- oderCOPYING-Datei im Projekt-Root zu platzieren. Das ist laut REUSE-FAQ auch vollkommen zulässig. Diese Dateien werden vomreuse-Tool explizit ignoriert und benötigen daher weder Kommentar-Header noch.license-Begleitdateien. - Wer eine Duplizierung des Lizenztextes vermeiden möchte, sollte beachten:
reuse lintfolgt Symlinks, ein symbolischer Link vonLICENSES/<lizenz>.txtzur Root-Datei funktioniert also. Umgekehrt bringt ein deutlich sinnigerer Link vonLICENSEaufLICENSES/<lizenz>.txtnichts, da Licensee leider auch keine Symlinks unterstützt. Daher empfehle ich eine echte Kopie der Lizenzdatei im Wurzelverzeichnis als aktuell zuverlässigsten Weg, um GitHubs Probleme bei der Lizenzanzeige zu umgehen.
Aus meiner Sicht sollte dieser Workaround nur dann verwendet werden, wenn das gesamte Projekt unter einer einzigen Lizenz steht. Das vermeidet Missverständnisse und Konflikte – und in allen anderen Fällen lohnt es sich, GitHubs Einschränkungen einfach zu ignorieren.
Jahreszahlen und -angaben in Copyright-Texten
Das ist zwar kein zentrales REUSE-Thema, aber mir ist aufgefallen, dass Jahreszahlen in Copyright-Angaben sehr oft Diskussionsthema werden, wenn REUSE in einem Projekt eingeführt wird. IANAL, aber rechtlich gesehen ist es in der Regel nicht erforderlich, das Copyright-Jahr regelmäßig zu aktualisieren oder überhaupt anzugehen (auch nicht aus US-Sicht). Entscheidend ist eher die leichte Nachvollziehbarkeit des Jahrs der ersten Veröffentlichung oder des ersten Code-Beitrags.
Trotzdem ist es gängige Praxis, die Jahresangabe zu aktualisieren. Ich finde dies auch persönlich sinnvoll, da es gegenüber Dritten signalisiert, dass das Projekt aktiv gepflegt wird und auch die Kontaktdaten wahrscheinlich noch aktuell sind. Ich empfehle zur Aktualisierung die folgende pragmatische Vorgehensweise, die sich auch für andere Projekte gut eignet:
- Die Jahresangabe zwar stets aktuell halten, aber nur an zentraler Stelle wie in der
README.md. So bleibt der Aufwand überschaubar. - Mehrere Jahre einfach durch Kommas getrennt auflisten oder bei aufeinanderfolgenden Jahren eine Zeitspanne angeben (
JahrX–JahrY). - Beispiel:
- Die erste Veröffentlichung und Copyright-Erklärung war
Copyright (c) 2013. - Es gab Veröffentlichungen oder Updates in mehreren, aber nicht allen Jahren danach:
- 2023 →
Copyright (c) 2013, 2015, 2018-2021, 2023. - 2015 →
Copyright (c) 2013, 2015. - 2018 →
Copyright (c) 2013, 2015, 2018. - 2019 →
Copyright (c) 2013, 2015, 2018, 2019. - 2020 →
Copyright (c) 2013, 2015, 2018-2020. - 2021 →
Copyright (c) 2013, 2015, 2018-2021.
- 2023 →
- Die erste Veröffentlichung und Copyright-Erklärung war
Fazit
Lizenzklarheit ist eine grundlegende Voraussetzung für nachhaltige Zusammenarbeit im Open-Source-Bereich. Die REUSE-Spezifikation ersetzt dabei weder rechtliche Rahmenbedingungen noch die Entscheidung für eine bestimmte Lizenz. Sie sorgt aber dafür, dass das oft chaotische Lizenzmanagement vorhersehbar, klar und automatisierbar wird.
Gerade bei bestehenden Codebases kann sich die Einführung von REUSE zunächst nach zusätzlichem Aufwand anfühlen. Doch sobald alles eingerichtet ist, zahlt sich dieser Schritt aus: Das Projekt wird leichter verständlich, einfacher wartbar, besser paketierbar und tatsächlich besser … wiederverwendbar (REUSE it 🙂). REUSE hilft dabei, die rechtliche Struktur eines Projekts so zu beschreiben, dass Menschen und Maschinen gleichermaßen damit arbeiten können. Und genau das ist enorm viel wert.
-
Die Nutzung des
LICENSES/-Verzeichnisses wird auch von den CII Best Practices empfohlen und ist z. B. im Linux-Kernel umgesetzt. ↩︎ -
Quelle: https://download.fsfe.org/videos/reuse/screencasts/reuse-tool.gif, Copyright © 2001-2025 Free Software Foundation Europe, Verbatim copying and distribution is permitted in any medium, provided this notice is preserved. ↩︎