Lizenzieren#
Damit andere eure Software verwenden können, sollte sie eine oder mehrere Lizenzen erhalten, die die Nutzungsbedingungen beschreiben. Andernfalls dürfte sie meist urheberrechtlich geschützt sein. Urheber sind diejenigen, die zur Software originär beigetragen haben. Wenn eine Software relizenziert werden soll, ist die Zustimmung aller Personen erforderlich, die Urheberschaft beanspruchen können.
Bemerkung
Dies stellt keine Rechtsberatung dar. Wendet euch im Zweifelsfall bitte an eine Rechtsvertretung oder die Rechtsabteilung eures Unternehmens.
Siehe auch
Proprietäre Softwarelizenzen#
Proprietäre Softwarelizenzen sind selten standardisiert; sie können kommerziell, Shareware oder Freeware sein.
Freie und Open-Source Softwarelizenzen#
Sie werden von der Free Software Foundation (FSF) und der Open Source Initiative (OSI) definiert. Dabei kann im Wesentlichen unterschieden werden zwischen Copyleft-, freizügigen- und gemeinfreien Lizenzen.
Copyleft-Lizenzen#
Copyleft-Lizenzen verpflichten die Lizenznehmer, jegliche Bearbeitung der Software unter die Lizenz des ursprünglichen Werks zu stellen. Dies soll Nutzungseinschränkungen der Software verhindern. Die bekannteste Copyleft-Lizenz ist die GNU General Public License (GPL). Dabei wird das Copyleft der GPL als sehr stark, das der Mozilla Public License hingegen als sehr schwach angesehen.
Da die Lizenzgeber nicht selbst an ihr eigenes Copyleft gebunden sind, können sie neue Versionen auch unter proprietärer Lizenz veröffentlichen oder Dritten dies erlauben (Mehrfachlizenzierung).
Durch Copyleft-Lizenzen können jedoch schnell Inkompatibilitäten auch zu freien Lizenzen ohne Copyleft entstehen. So ist beispielsweise die 3-Clause-BSD-Lizenz mit der GPL inkompatibel.
Freizügige Open-Source-Lizenzen#
Freizügige oder permissive Open-Source-Lizenzen erlauben eine breitere Wiederverwendung als die Copyleft-Lizenzen. Ableitungen und Kopien des Quellcodes können unter Bedingungen verbreitet werden, die grundlegend andere Eigenschaften haben als die der Originallizenz. Die bekanntesten Beispiele solcher Lizenzen sind die MIT-Lizenz und die BSD-Lizenz.
Gemeinfreie Lizenzen#
Bei gemeinfreien oder Public Domain-Lizenzen gehen die Urheberrechte an die Allgemeinheit über. Zur Kennzeichnung der Freigabe weitest möglicher Nutzungsrechte wurde die Creative Commons Zero-Lizenz erstellt.
Nicht-Software-Lizenzen#
Open-Source-Software-Lizenzen können auch für Werke verwendet werden, die nicht Software sind. Oft sind sie auch die beste Wahl, insbesondere wenn die betreffenden Werke als Quelltext bearbeitet und versioniert werden.
Daten, Medien, etc.#
CC0 1.0, CC BY 4.0 und CC BY-SA 4.0 sind offene Lizenzen, die für Nicht-Software-Material verwendet werden, von Datensätzen bis zu Videos. Sie sind jedoch nicht für Software empfohlen.
Die Open Knowledge Foundation hat ebenfalls eine Reihe von Open Data Commons-Lizenzen für Daten/Datenbanken veröffentlicht:
- Open Data Commons Open Database License (ODbL) v1.0
Namensnennung und Weitergabe unter gleichen Bedingungen.
- Open Data Commons Attribution License (ODC-By) v1.0
Namensnennung.
- Open Data Commons Public Domain Dedication and License (PDDL) v1.0
Die PDDL stellt die Daten in den öffentlichen Bereich und verzichtet auf alle Rechte.
GovData hat die Datenlizenz Deutschland in zwei Varianten vorgelegt:
Bei der Verwendung des Community Data License Agreement – Permissive, Version 2.0 müssen die Urheberrechtshinweise beibehalten werden.
Eine weitere mögliche Lizenz für künstlerische Werke ist die Free Art License 1.3.
Dokumentation#
Jede Open-Source-Softwarelizenz oder offene Lizenz für Medien gilt auch für Software-Dokumentation. Wenn ihr unterschiedliche Lizenzen für eure Software und deren Dokumentation verwendet, solltet ihr darauf achten, dass die Quellcode-Beispiele in der Dokumentation auch unter der Software-Lizenz lizenziert sind. Neben den oben bereits genannten Creative Commons-Lizenzen gibt es speziell für freie Dokumentationen folgende Lizenzen.
- GNU Free Documentation License (FDL)
Copyleft-Lizenz für Dokumentationen, die für alle GNU-Handbücher verwendet werden soll. Ihre Anwendbarkeit ist auf textuelle Werke (Bücher) beschränkt.
- FreeBSD Documentation License
Freizügige Dokumentationslizenz mit Copyleft, die mit der GNU FDL vereinbar ist.
- Open Publication License, Version 1.0
freie Dokumentationslizenz mit Copyleft, sofern keine der Lizenzoptionen aus Abschnitt VI der Lizenz wahrgenommen werden. In jedem Fall ist sie mit der GNU FDL unvereinbar.
Schriftarten#
- SIL Open Font License 1.1
Schriftlizenz, die in anderen Werken frei verwendet werden kann.
- GNU General Public License 3
Sie kann auch für Schriften verwendet werden, sie darf jedoch nur mit der Schriftausnahme in Dokumente eingebunden werden.
Siehe auch
- LaTeX ec fonts
Freie European Computer Modern- und Text Companion-Schriften, die üblicherweise mit Latex verwendet werden.
- Arphic Public License
Freie Lizenz mit Copyleft.
- IPA Font license
Freie Lizenz mit Copyleft, deren abgeleitete Werte jedoch nicht den Namen des Originals verwenden oder beinhalten dürfen.
Hardware#
Entwürfe für Open-Source-Hardware werden von den CERN Open Hardware Lizenzen abgedeckt:
- CERN-OHL-P-2.0
permissiv
- CERN-OHL-W-2.0
schwach reziprok
- CERN-OHL-S-2.0
stark reziprok
Auswahl geeigneter Lizenzen#
Übersichten über mögliche Lizenzen findet ihr in SPDX License List oder OSI Open Source Licenses by Category. Bei der Wahl geeigneter Lizenzen unterstützt euch die Website Choose an open source license und Comparison of free and open-source software licenses.
Wenn ihr z.B. eine möglichst große Verbreitung eures Pakets erreichen wollt, sind MIT- oder die BSD-Varianten eine gute Wahl. Die Apache-Lizenz schützt euch besser vor Patentverletzungen, ist jedoch nicht kompatibel mit der GPL v2.
Abhängigkeiten überprüfen#
Daher solltet ihr schauen, welche Lizenzen diejenigen Pakete haben, von denen ihr abhängt und zu denen ihr kompatibel sein solltet. Zur Analyse von Lizenzen könnt ihr euch License compatibility anschauen und den licensechecker, verwenden, ein Kommandozeilenwerkzeug, das Installationsverzeichnisse nach Lizenzen durchsucht.
Darüberhinaus kann es auch sinnvoll sein, ein Package unter mehreren Lizenzen zu veröffentlichen. Ein Beispiel hierfür ist cryptography/LICENSE.
GitHub#
Auf GitHub könnt ihr euch eine Open Source-Lizenz in eurem Repository erstellen lassen.
Geht zur Hauptseite eures Repository.
Klickt auf Create new file und gebt anschließend als Dateiname
LICENSEoderLICENSE.mdein.Anschließend könnt ihr rechts neben dem Feld für den Dateinamen auf Choose a license template klicken.
Nun könnt ihr die für euer Repository passende Open Source-Lizenz auswählen.
Ihr werdet nun zu zusätzlichen Angaben aufgefordert, sofern die gewählte Lizenz dies erfordert.
Nachdem ihr eine Commit-Message angegeben habt, z.B.
Add license, könnt ihr auf Commit new file klicken.
Falls ihr in eurem Repository bereits eine /LICENSE-Datei hinzugefügt habt,
verwendet GitHub licensee um die Datei
mit einer kurzen Liste von Open-Source-Lizenzen abzugleichen. Falls GitHub die Lizenz
eures Repository nicht erkennen kann, enthält es möglicherweise mehrere
Lizenzen oder ist zu komplex. Überlegt Euch dann, ob ihr die Lizenz vereinfachen
könnt, z.B. indem ihr Komplexität in die
/README-Datei auslagert.
Umgekehrt könnt ihr auf GitHub auch nach Repositories mit bestimmten Lizenzen oder Lizenzfamilien suchen. Eine Übersicht über die Lizenz-Schlüsselwörter erhaltet ihr in Searching GitHub by license type.
Schließlich könnt ihr euch von Shields.io ein
License-Badge generieren lassen, das ihr z.B. auf eurer
README-Datei einbinden könnt:
|License|
.. |License| image:: https://img.shields.io/github/license/veit/jupyter-tutorial.svg
:target: https://github.com/veit/jupyter-tutorial/blob/main/LICENSE
Standardformat für die Lizenzierung#
SPDX steht für Software Package Data Exchange und definiert eine standardisierte Methode zum Austausch von Urheberrechts- und Lizenzinformationen zwischen Projekten und Personen. Die passenden SPDX-Identifier könnt ihr aus der SPDX License List auswählen und dann in den Kopf eurer Lizenzdateien eintragen:
# SPDX-FileCopyrightText: [year] [copyright holder] <[email address]>
#
# SPDX-License-Identifier: [identifier]
Konformität überprüfen#
REUSE#
REUSE wurde von der FSFE initiiert, um die Lizenzierung freier Software-Projekte zu erleichtern. Das REUSE tool überprüft Lizenzen und unterstützt euch bei der Einhaltung der Lizenzkonformität. Mit der REUSE API könnt ihr euch auch ein dynamisches Compliance-Badge generieren:
GitLab-CI-Workflow#
Ihr könnt REUSE einfach in euren Continuous Integration-Workflow integrieren,
z.B. für GitLab in der .gitlab-ci.yml-Datei mit:
reuse:
image:
name: fsfe/reuse:latest
entrypoint: [""]
script:
- reuse lint
Alternativen#
- ISO/IEC 5230/OpenChain
empfiehlt REUSE als eine Komponente, um die Klarheit der Lizenz- und Urheberrechtssituation zu verbessern, stellt jedoch höhere Anforderungen, um eine vollständige Konformität zu erreichen.
Sie basiert auf der OpenChain Specification 2.1 und ist ein internationaler Standard zu Software-Lieferketten, vereinfachter Beschaffung und Open-Source-Lizenz-Compliance.
- ScanCode
bietet eine Reihe von Tools und Anwendungen zum Scannen von Software-Codebasen und -paketen, um den Ursprung und die Lizenz (Provenienz) von Open-Source-Software (und anderer Software von Drittanbietern) zu ermitteln.
- DeltaCode
vergleicht zwei Codebase-Scans, um signifikante Änderungen zu erkennen.
- ClearlyDefined
sammelt und zeigt Informationen über die Lizenzierungs- und Urheberrechtssituation eines Software-Projekts an.
- FOSSology
ist ein Toolkit für die Einhaltung freier Software, das Informationen in einer Datenbank mit Lizenz-, Copyright- und Exportscanner speichert.
- OSS Review Toolkit (ORT)
ist ein Toolkit zur Automatisierung und Orchestrierung von FOSS-Richtlinien, mit dem ihr eure (Open-Source-)Software-Abhängigkeiten verwalten könnt. Es
generiert OWASP CycloneDX, SPDX Software Bill of Materials (SBOM) oder benutzerdefinierte FOSS-Attributionsdokumentation für euer Softwareprojekt
automatisiert eure FOSS-Policy, um euer Softwareprojekt und seine Abhängigkeiten auf Lizenzierung, Sicherheitslücken, Quellcode und technische Standards zu prüfen
erstellt ein Quellcode-Archiv für euer Softwareprojekt und seine Abhängigkeiten, um bestimmte Lizenzen einzuhalten
korrigiert Paket-Metadaten oder Lizenzfeststellungen selbst
Siehe auch
Python-Paket-Metadaten#
Mit PEP 658 wird die METADATA-Datei aus Distributionen in der
PEP 503-Repository-API auf PyPI verfügbar. Damit können die Metadaten
der Verteilungspakete analysiert werden
ohne dass das ganze Paket heruntergeladen werden muss.
In Python-Paketen gibt es noch weitere Felder, in denen Lizenzinformationen gespeichert werden, wie die Core metadata specifications, die zudem limitiert sind. Dies führt nicht nur zu Problemen für die Autoren, die richtige Lizenz angeben zu können, sondern auch zu Problemen beim Re-Paketieren für diverse Linux-Distributionen.
Aktuell werden zwar einige häufige Fälle abgedeckt und die Lizenzklassifizierung
kann auch erweitert werden, es gibt jedoch einige beliebte Klassifizierungen wie
License :: OSI Approved :: BSD License, die abgeschafft werden. Damit
ist dann jedoch die Abwärtskompatibilität nicht mehr gewährleistet und die
Pakete müssen relizensiert werden. Immerhin habt ihr mit trove-classifiers auch eine Möglichkeit, eure
Trove-Klassifizierungen zu überprüfen.