Anforderungen an Inhalte auf openCode

Anforderungen an Inhalte

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.

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