Praxisleitfaden zur Lizenzanwendung

1. Die LICENSE-Datei ins Stammverzeichnis

Als Erstes legen Sie den Lizenztext als Datei LICENSE (oder LICENSE.txt, LICENSE.md) im Stammverzeichnis des Repositorys ab. GitHub, GitLab und Paketmanager suchen nach dieser Datei, um die Lizenz zu erkennen. Im Generator wählen Sie die Lizenz, geben Jahr und Rechteinhaber ein und können die Datei sofort herunterladen.

• Den Text nicht verändern: Füllen Sie nur Platzhalter wie [year] und [fullname] bei MIT, BSD und ISC aus und lassen Sie die übrigen Sätze unverändert. Geänderter Wortlaut wird nicht mehr als Standardlizenz erkannt und kann Auslegungsprobleme verursachen.
• GNU-Lizenzen im vollen Wortlaut: Die Texte von GPL, LGPL und AGPL haben keine auszufüllenden Stellen. Rechteinhaber und Versionsklausel geben Sie im Dateihinweis an.

2. Jahr und Rechteinhaber

• Jahr: Üblich ist das Jahr der ersten Veröffentlichung. Man schreibt auch Zeiträume wie 2019-2026. Eine rechtliche Pflicht zur jährlichen Aktualisierung besteht nicht.
• Rechteinhaber: Bei selbst geschriebenem Code Ihr eigener Name, bei im Rahmen eines Arbeitsverhältnisses geschriebenem Code in der Regel der Arbeitgeber (abhängig von Land und Vertrag). Projekte mit vielen Beitragenden schreiben oft etwa The Example Project Authors und pflegen eine Liste in einer Datei AUTHORS.
• Der Urheberrechtsvermerk begründet das Recht nicht, er macht es bekannt. Auch ohne Vermerk besteht das Urheberrecht.

3. Begleitdateien je nach Lizenz

Die NOTICE der Apache-2.0 ist nicht verpflichtend, aber wer Code mit vorhandener NOTICE weiterverbreitet, muss deren Inhalt erhalten. Die ASF empfiehlt, in die NOTICE nur rechtlich erforderliche Zuschreibungen aufzunehmen, keine Danksagungen und keine Lizenztexte.

4. Dateiköpfe im Quellcode

Mit einem kurzen Kopf in jeder Datei wandert die Lizenzinformation mit, auch wenn die Datei einzeln kopiert wird.

# SPDX-FileCopyrightText: 2026 Example Inc.
# SPDX-License-Identifier: Apache-2.0

GNU, Apache und MPL empfehlen auch offizielle Hinweistexte, doch immer mehr Projekte ersetzen sie durch die zwei SPDX-Zeilen. Details finden Sie im SPDX-Ratgeber.

5. Paketmetadaten und README

• Tragen Sie die SPDX-Kennung in das license-Feld von package.json, Cargo.toml, pyproject.toml usw. ein.
• Fügen Sie am Ende des README einen Abschnitt „Lizenz“ mit einer ein- bis zweizeiligen Zusammenfassung ein (z. B. „This project is licensed under the MIT License — see LICENSE“).

6. Hinweise zu Drittanbieter-Code

Wer fremden Code mitverbreitet, muss auch dessen Lizenzpflichten einhalten.

• Bei hineinkopiertem Code bleiben ursprünglicher Urheberrechtsvermerk und Lizenz in der jeweiligen Datei erhalten.
• Bei Verbreitung als Binärdatei oder App sammeln Sie die verwendeten Open-Source-Komponenten und vollständigen Lizenztexte in einer Datei THIRD_PARTY_NOTICES oder im Bildschirm „Open-Source-Lizenzen“ der App.
• Bei vielen Abhängigkeiten erzeugen Sie die Liste automatisch mit SBOM-Werkzeugen oder der Lizenzberichtsfunktion des Paketmanagers.

7. Beiträge annehmen: DCO oder CLA

Mit externen Beiträgen verteilt sich das Urheberrecht auf viele Personen. Dafür gibt es zwei Verfahren.

• DCO: Beitragende fügen dem Commit Signed-off-by: hinzu und bestätigen damit, dass sie berechtigt sind, den Code unter der Projektlizenz einzureichen. Leichtgewichtig; der Linux-Kernel nutzt es.
• CLA: Ein Vertrag, mit dem Beitragende dem Projekt weitreichende Rechte einschließlich Relizenzierung einräumen. Nötig für kommerzielles Dual Licensing oder wenn man sich einen späteren Lizenzwechsel offenhalten will.

Die Beitragsregeln halten Sie in CONTRIBUTING.md fest.

8. Wenn Sie die Lizenz ändern

• Der Rechteinhaber kann künftige Versionen unter eine andere Lizenz stellen. Die Erlaubnis für bereits verbreitete Versionen wird in der Regel nicht widerrufen.
• Enthält das Projekt Code anderer Beitragender, ist deren Zustimmung nötig (außer wenn per CLA Relizenzierungsrechte eingeräumt wurden).
• Ein Wechsel von freizügig zu Copyleft ist vergleichsweise einfach (freizügiger Code darf in Copyleft-Projekte), ein Wechsel von Copyleft zu freizügig ist ohne Zustimmung aller Rechteinhaber praktisch unmöglich.
• Dokumentieren Sie Zeitpunkt, Grund und betroffene Versionen des Wechsels klar in CHANGELOG und README.

Checkliste

1. LICENSE-Text (nur Platzhalter ausgefüllt)
2. Begleitdateien (NOTICE, COPYING.LESSER usw.)
3. Dateiköpfe (zwei SPDX-Zeilen)
4. Paketmetadaten und README
5. Hinweise zu Drittanbieter-Code
6. Beitragsregeln (DCO oder CLA)

Dieser Artikel enthält allgemeine Informationen und ist keine Rechtsberatung. Besprechen Sie wichtige Entscheidungen mit Fachleuten.

Quellen

• GitHub Docs, Adding a license to a repository — https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
• Apache, Applying the Apache License · Assembling LICENSE and NOTICE — https://www.apache.org/legal/apply-license.html
• GNU, How to Use GNU Licenses for Your Own Software — https://www.gnu.org/licenses/gpl-howto.html
• REUSE Specification — https://reuse.software/spec/
• Developer Certificate of Origin — https://developercertificate.org/