Standardisierte Open-Source-Lizenzen

Standardisierte Open-Source-Lizenzen

Diese Lizenz Compliance beschreibt die aus lizenzrechtlicher Sicht bestehenden Anforderungen an Inhalte auf der openCode-Plattform sowie die dazugehörigen Aufgaben der Repository Owner / Maintainer.

Zum eindeutigen Verständnis der nachfolgenden Handreichung und zur Verhinderung von Missverständnissen gilt es die im OSS Glossar dargestellten Erläuterungen anzuwenden. Von zentraler Bedeutung für die Lizenz Compliance sind dabei die Begriffe Inhalte, Kompilate, Komponenten, Proprietäre Produkte sowie Software Bill of Materials (SBOM).

1. Anforderungen an Inhalte Kopiert!

1. Jeglicher Inhalt, z. B. Quellcode, Medien, Begleitdokumente, innerhalb der openCode-Plattform müssen unter einer Open Source Software Lizenz entsprechend der Definition der Open Source Initiative (OSI) nutzbar sein. Welche Lizenzen im Kontext der Plattform dazu zählen, kann im untenstehenden Anhang eingesehen werden. Alle Inhalte innerhalb der Plattform müssen einer eindeutigen Lizenzierung unterliegen – die Anwendung der REUSE Spezifikation wird zudem für eigene Inhalte empfohlen. ACHTUNG: Die Lizenzierung von Software unter einer Open-Source-Lizenz ist nur möglich, wenn eine entsprechende Rechteposition besteht, die dies urheberrechtlich zulässt. Im Anhang unter Punkt 4. „Lizenzensierungsleitfragen" finden sich Leitfragen zur Lizenzierung, die bei der Prüfung helfen sollen, ob eine ausreichende Rechtsposition vorliegt. Eine unveränderte Nutzung der EVB-IT Vorlagen sieht häufig keine ausreichende Rechteposition vor. Im Zweifelsfall sollte rechtlicher Rat eingeholt werden. Eine Empfehlung der zu wählenden Lizenz gibt es nicht, da die jeweiligen Lizenzbedingungen den Anforderungen des Einzelfalls genügen müssen. Pauschal empfiehlt es sich dennoch, gängige und weitverbreitete Lizenzen zu verwenden, die den Nutzenden eher bekannt sind als selten verwendete Lizenzen. Im Anhang unter Punkt 5. „Unterstützung Lizenzauswahl“ befinden sich einige von openCode empfohlene Lizenzen. Sollten Sie Lizenzen verwenden, die der Open-Source-Definition gemäß der Definition der Open Source Initiative entsprechen, jedoch von der Plattform oder OSI noch nicht explizit anerkannt wurden, melden Sie sich bitte unter  info@opencode.de mit dem exakten Lizenztext und einer Erläuterung, wieso diese Lizenz aufgenommen werden sollte.
2. Open-Source-Inhalte, welche auf Komponenten mit nicht zulässigen Lizenzen basieren oder ausschließlich zur Einbettung in diese vorgesehen sind, sind zulässig, sofern diese fremdlizenzierten Komponenten nicht selbst in die Plattform eingebracht werden.
3. Bei bereitgestellten Kompilaten (bspw. Executables, Installer, Objekte etc.) gelten diese Lizenzanforderungen zusätzlich für alle von dem Kompilat verwendeten Komponenten und Abhängigkeiten. Geht in ein solches Kompilat eine Komponente ein, deren Lizenzen nicht freigegeben ist, kann das Kompilat nicht auf der Plattform bereitgestellt werden.
4. Open-Source-Kompilate für die kein Nutzungsrecht belegbar ist oder deren Lizenzbedingungen nicht erfüllt werden können (etwa durch Lizenzinkompatibilitäten oder mangelndes Mitführen von Lizenz- und Urheberinformationen) können nicht in das Code Repository eingestellt werden.
5. Die Einhaltung von Punkt 1.3. muss durch eine standardisierte Software Bill of Materials (SBOM) nachvollziehbar sein. Bei Projekten mit naheliegendem Kompilat (bspw. durch package.json/Dockerfile) wird die Erzeugung einer pauschalen SBOM. für die Nachnutzenden empfohlen.

2. Aufgaben der Repository Owner / Maintainer Kopiert!

Es ist Aufgabe der Repository Owner / Maintainer alle bereitgestellten Lizenzen auszuweisen. Zur Erfüllung sind folgenden Schritte auf Projektebene durch den Project Owner oder einen Maintainer vorzunehmen:

1. Identifizieren sämtlicher in bereitgestellte Kompilate eingehender oder dafür notwendiger Komponenten.
   1. Inklusive transitiver Abhängigkeiten (Abhängigkeiten der Abhängigkeiten)
   2. Inklusive im Kompilat mitgelieferter Laufzeitumgebungen (etwa eine JRE innerhalb eines Containers
   3. Exklusive extern bereitzustellender Laufzeitumgebungen (etwa ein vom Nutzer bereitzustellendes JRE)
   4. Exklusive aller Komponenten ohne direkte Auswirkungen auf das Kompilat (etwa Test und QS-Werkzeuge)
      
2. Identifizieren sämtlicher Lizenzen und Copyrights der Komponenten aus Schritt 1. und dem Eigenen Quell-Code/Repository. Um einen rechtssicheren Raum zu schaffen, müssen Lizenz und Copyrightdeklarationen der Pakete und LICENSE-Files validiert werden, da diese häufig fehlerbehaftet sind oder Innenlizenzen ignorieren. Validierung über CodeScan Lösungen wie FOSSology, OSS-Review-Toolkit und ScanCode, Tern und der Bezug aus Quellen mit entsprechenden Qualitätsanforderungen (typisch sind hier OS-Distributionen) werden dazu empfohlen.
   
3. Bereitstellung der Ergebnisse von Schritt 1. und 2. in einer standardisierten SBOM. innerhalb des Repositories. Um technischen Abgleich zu ermöglichen, muss die SBOM als "SPDX_<ARTEFAKT_NAME>.<spdx_dateityp>" benannt sein und kann in einem Unterverzeichnis liegen.
   
4. Erfüllung zusätzlicher Anforderungen entsprechend der jeweiligen Lizenzanforderungen zur Distribution, etwa Notice-File (gem. Ziffer 4 Apache-2.0). Folgende Informationen sind in innerhalb der SBOM auf Komponentenebene wiederzugeben (das Projekt und dessen Informationen sollten in dieser Komponentenliste ebenfalls auftauchen):
   
   
   • Der Komponenten/Paket/Datei NameOptional: Komponenten/Paket VersionOptional: Eindeutige Paket-URL oder Download-QuelleAlle vorliegenden Lizenz-Identifier (nach SPDX-Standardisiert sofern vorhanden, andernfalls die Abkürzungen verwenden von ScanCode LicenseDB [extern]) vgl. Hinweise zu Lizenzähnlichkeit und LizenzidentifikationSoweit detektierbar alle vorliegenden vollständigen originalen LizenztexteSoweit detektierbar alle vorliegenden vollständigen originalen Copyright-Informationenigen originalen Copyright-Informationen

Zur weiteren Verarbeitung der Daten benötigt die Plattform ein standardisiertes SBOM.-Format zur Ausweisung von Compliance Informationen. Aktuell unterstützt die Plattform SPDX 2.2.1, beziehungsweise ISO 5962.

3. Anhang - Freigegebene Open-Source-Lizenzen für openCode Kopiert!

1. Freigabemethodik und Beschreibung zur Nutzung der Lizenzliste Kopiert!

Eine Lizenz ist freigegeben, wenn sie nach fachlicher und juristischer Prüfung seitens openCode sowohl der Open-Source-Definition (gemäß Definition der Open-Source-Initiative) entspricht und darüber hinaus keine für die Öffentliche Verwaltung erkennbaren Schwierigkeiten birgt. Außer in Ausnahmefällen ist nicht zu erwarten, dass einmal freigegebene Lizenzen deklassifiziert werden.

Die erste Spalte zeigt den Namen der Open-Source-Lizenz auf. Gemäß der ISO 5962 und dem funktional identischen SPDX 2.2.1 in Annex A.1: SPDX License List kann jedem Namen einer Open-Source-Lizenzliste ein so genannter Short Identifier, also ein Kürzel, zugeordnet werden. Dieser Identifier ist eindeutig für den vollen Namen der Open-Source-Lizenz und kann daher austauschbar verwendet werden. Bei der Nutzung sind die korrekten Versionsnummern im Lizenzname und dem Identifier, sowie gegebenenfalls Ergänzungen am Ende des Lizenznamens und des Kürzels für Variationen der Lizenz zu beachten.

Nachstehender Punkt 2. „Open-Source-Lizenzliste" enthält die Auflistung aller durch openCode freigegebenen Lizenzen

Nachstehender Punkt 3. „Negativliste" enthält eine Negativliste aller explizit nicht freigegebenen Lizenzen, d. h. werden durch openCode als keine Open-Source-Lizenz angesehen. Die Verbreitung von Inhalten dieser Lizenzart ist auf openCode untersagt.

Hinweise zu Lizenz-Identifikation (LI)

• LI.1 Grundsätze der Lizenz-Identifikation: Grundsätzlich sind Lizenzen mit ihrem SPDX-Identifier auszuweisen. Die Angabe erfolgt mit den sog. Identifiern aus https://spdx.org/licenses/ für Lizenzen und Expression-Ausdrücke.
• LI.2 Angabe nicht Standardisierter Lizenz-Identifier: Sind Lizenzen-Identifier nicht in der Liste aus SPDX ISO 5962 zu finden, ist als nächstes die Lizenz-Datenbank Scancode LicenseDB AboutCode heranzuziehen. Identifier aus dieser Datenbank nutzen in ihrem SPDX-Identifier den Präfix LicenseRef-scancode-[…] um die Herkunft des angegebenen Identifiers abzubilden.
• LI.3 Gänzlich unbekannte Lizenzen: Ist ein Lizenzfund in keiner der etablierter Identifier-Listen verfügbar, so kann entsprechend SPDX ISO 5962 der Präfix LicenseRef-[…] eingesetzt werden um eine lokal einzigartigen Lizenz-Identifier zu vergeben.

Zusätzlich bittet openCode um den Dialog zu Ihrer unidentifizierten Lizenz via oslizenz@opencode.de zur rechtlichen Bewertung hinsichtlich der Open Source Eignung der Lizenz.

Hinweise zu Lizenz-Ähnlichkeit (LÄ)

• LÄ.1 Grundsätze der Lizenz-Ähnlichkeit: Grundsätzlich sind Lizenzen ähnlich, wenn sie entsprechend dem SPDX ISO 5962 Matching Guidelines auf eine andere Lizenz zuordenbar sind.
• LÄ.2 Platzhalter und Templates in Lizenztexten: Existieren in Lizenztexten Platzhalter und Templates, so ist eine Ersetzung dieser Platzhalter und Templates durch einen individualisierten Inhalt, nicht als Lizenzmodifikation zu verstehen, sondern ist dem gleichen Lizenz-Identifier zuzuordnen.
• LÄ.3.0 SPDX-Operatoren und Lizenzverkettungen: Lizenzausdrücke von Mehrfachlizenzierungen, Lizenzwahlmöglichkeiten und Lizenzausnahmen sind mit SPDX-Operatoren abzubilden. Die Lizenz-Operatoren verbinden dabei Lizenz-Identifier. Zulässige Operatoren sind entsprechend Standard zu wählen. Sollten einzelne Lizenzen einer Mehrfachlizenzierung mit der freigebenden openCode Lizenzliste in Konflikt stehen, so muss dieser Konflikt z. B. durch die Wahl einer auf openCode freigegebenen Lizenz gelöst werden. Es muss jedoch keine Wahl erfolgen, solange alle Lizenzen einer Wahlmöglichkeit auf openCode freigegeben.
• LÄ.3.1 Ausnahmeklauseln für Lizenzen: Ist einem Lizenztext eine Ausnahmeklausel angehängt, so ist diese entsprechend den zulässigen SPDX-Operatoren mit WITH an einen Lizenz-Identifier anzuhängen. Die Namen der Ausnahmeklausel sog. Exceptions sind analog den Hinweisen zur Lizenz-Identifikation mit Identifiern zu beschreiben. LI.1 nach https://spdx.github.io/spdx-spec/v2.3/SPDX-license-list/#a2-exceptions-list, LI.2 analog in Lizenz-Datenbank Scancode LicenseDB AboutCode, LI.3 analoge Schreibweisen.
• Ausnahmeklauseln sind grundsätzlich freigegeben, wenn sie keine weitere Einschränkung hinsichtlich Einsatzes und Nutzung auferlegen. Sind sie sich unsicher wenden Sie sich an info@opencode.de
• LÄ.4 Textmodifikationen: Ist ein Wortlaut in einem Lizenztext verglichen zu einem freigegebenen Lizenztext einer Lizenz geändert, kann der Lizenztext der freigebenden Lizenz nach eigenem Ermessen zugeordnet werden, wenn die Änderung nicht wesentlich ist. Bei Unsicherheiten unterstütz openCode gerne über info@opencode.de 

2. Open-Source-Lizenzliste Kopiert!

in Version 1.5 (Stand Januar 2024)

Historie:
V1.5 Einzelkorrektur RSA am 29.01.2024
V1.4 Neue Lizenzen ergänzt am 29.11.2023
V1.3 Sortierschlüssel ist nun der SPDX-Identifier und neue Lizenzen ergänzt am 30.10.2023
V1.2 neue Lizenzen ergänzt am 04.09.2023
V1.1 D-FSL-1.0 ergänzt am 28.11.2022

Lizenzen mit LicenseRef-OpenCoDE- Kennung, können im zugehörigen Repository (https://gitlab.opencode.de/open-code/lizenztexte) eingesehen werden. Für alle Lizenzen wird die Überführung in etablierte Lizenzdatenbanken angestrebt.

3. Negativliste aller nicht freigegebenen Lizenzen Kopiert!

in Version 1.4 (Stand November 2023)

4. Lizenzierungsleitfragen Kopiert!

Abbildung 1: Lizenzierungsleitfragen

5. Unterstützung Lizenzauswahl Kopiert!