Standardised open-source-licenses

These license compliance guidelines describe the requirements for content on the openCode-Platform in terms of licensing rights and the relevant tasks of the repository owner/maintainer.

To avoid misunderstandings, please refer to the OSS glossary of terms and their definitions which we have used. The terms content, output of compilation, components, proprietary products and Software Bill of Materials (SBOM) are essential to licence compliance issues.

1. Requirements for content Kopiert!

1. Any content, e.g. source code, media, or accompanying documents, which is incorporated into the openCode platform must be accessible under an open source software licence as defined by the Open Source Initiative (OSI). Please consult the Annex below to find out which licences are included in the context of the platform. Any content within the platform must be subject to clear licensing; in addition, the application of the REUSE specification is recommended for one's own content.
   Please note: Licensing of software under an open source licence is only possible if there is a corresponding legal position allowing it under intellectual property law. Item 4 -of the Annex, “Licensing guidelines”, is designed to help users determine whether the legal position suffices. In cases in which the EVB IT requirements governing supplementary contract conditions for procuring IT services are applied without changes, the legal position tends to be insufficient. In cases of doubt, users should seek legal advice. It is not possible to make recommendations as to the type of licence to opt for, because the licensing conditions must meet the requirements of the case in hand. However, commonly and widely used licenses are recommended, because users will be more familiar with them than with rarely used licences. Item 5 of the Annex, “Help with the choice of licence”, includes some licences recommended by openCode.
   If you use licences in line with the open source definition as defined by the Open Source Initiative, but which have not yet been explicitly recognised by the platform or by OSI, please contact info@opencode.de with the exact wording of the licence, stating the reason why that licence should be added.
2. Open source content which is based on components with inadmissible licences or is exclusively designed to be embedded in them is admissible if the externally licenced components are not themselves incorporated into the platform.
3. In the case of outputs of compilation (e.g. executables, installers, objects), these licensing requirements also apply to all components used in the outputs of compilation and all dependencies. If the output of compilation contains a component whose licence has not been approved for free use, the output of compilation cannot be provided on the platform.
4. Open source outputs of compilation for which the rights of use cannot be proven or whose licensing requirements cannot be met (due to licensing incompatibilities or the failure to carry licensing or copyright information, among other reasons) cannot be included in the code repository.
5. Compliance with Item 1.3 must be verifiable, using a standardised software bill of materials (SBOM). For projects involving a likely output of compilation (e.g. through package.json/Dockerfile), generating a blanket SBOM for downstream users is recommended

2. Tasks of repository owners/maintainers Kopiert!

Repository owners/maintainers have to list all provided licences. To comply with this requirement, project owners or maintainers must take the following steps at project level:

1. Identify all components forming part of or being required for the provided outputs of compilation
   1. including transitive dependencies (dependencies of dependencies)
   2. including runtime environments provided with the output of compilation (e.g. a JRE within a container)
   3. excluding runtime environments provided externally (e.g. a JRE to be provided by the user)
   4. excluding all components which do not have direct effects on the output of compilation (e.g. tests and QA tools)
      
2. Identify all licences and copyrights of the components from Step 1 and their own source code/repository. So as to provide legal certainty, the licensing and copyright declarations of the packages and licence files need to be validated, because they tend to be flawed or to ignore internal licences. The recommendation is to use CodeScan solutions for validation, such as FOSSology, OSS-Review-Toolkit and ScanCode, Tern, and to obtain them from high-quality sources (typically OS distributions).
   
3. Provide the results from Steps 1 and 2 in a standardised SBOM within the repository. So as to allow technical comparison, the SBOM data file name must be in the format "SPDX_<ARTEFAKT_NAME>.<spdx_dateityp> and can be stored in a subfolder.
   
4. Meet any additional requirements in line with the applicable licensing requirements regarding distribution, such as a NOTICE file (in line with no. 4 Apache-2.0).

In all cases, the following information must be stated within the SBOM at component level (with the project within the repository being one of the components):

• The component/package/file name
• Optional: Component/package version
• Optional: Unique package URL or download source
• All available license identifiers (standardized according to SPDX if available, otherwise use the abbreviations from ScanCode LicenseDB [external]) see notes on license similarity and license identification
• If detectable, all available complete original license texts
• If detectable, all available complete original copyright information

For the further processing of data, the platform requires a standardised SBOM format to state compliance information. At present, the platform supports SPDX 2.2.1 or ISO 5962.

3. Release methodology and description of how to use the license list Kopiert!

1. Notes on licence identification (LI) Kopiert!

A license is released if, after technical and legal review by openCode, it meets the open source definition (as defined by the Open Source Initiative) and does not pose any difficulties for the public administration. Except in exceptional cases, it is not to be expected that licenses once released will be declassified.

The first column shows the name of the open source license. In accordance with ISO 5962 and the functionally identical SPDX 2.2.1 in Annex A.1: SPDX License List, each name of an open source license list can be assigned a so-called short identifier. This identifier is unique for the full name of the open source license and can therefore be used interchangeably. When using the license, the correct version numbers in the license name and the identifier, as well as any additions at the end of the license name and the abbreviation for variations of the license, must be observed.

Item 2 “Open source license list” below contains a list of all licenses released by openCode.

Item 3 “Negative list” below contains a negative list of all explicitly non-released licenses, i.e. they are not considered open source licenses by openCode. The distribution of content of this license type is prohibited on openCode.

Notes on licence identification (LI)

• LI.1 Principles of licence identification: Licences are to be identified with their SPDX identifier. The indication is made with the so-called identifiers from https://spdx.org/licenses/ for licences and expressions.
• LI.2 Specification of non-standardized license identifiers: If license identifiers cannot be found in the list from SPDX ISO 5962, the license database Scancode LicenseDB AboutCode must be used next. Identifiers from this database use the prefix LicenseRef-scancode-[…] in their SPDX identifier to map the origin of the specified identifier.
• LI.3 Completely unknown licenses: If a license finding is not available in any of the established identifier lists, the prefix LicenseRef-[…] can be used according to SPDX ISO 5962 to assign a locally unique license identifier.

In addition, openCode asks for a dialog on your unidentified license via oslizenz@opencode.de for a legal assessment regarding the open source suitability of the license.

Notes on license similarity (LÄ)

• LÄ.1 Principles of license similarity: In principle, licenses are similar if they can be assigned to another license in accordance with the SPDX ISO 5962 Matching Guidelines.
• LÄ.2 Placeholders and templates in license texts: If placeholders and templates exist in license texts, replacing these placeholders and templates with individualized content is not to be understood as a license modification, but is to be assigned to the same license identifier.
• LÄ.3.0 SPDX operators and license concatenations: License expressions of multiple licensing, license selection options and license exceptions must be mapped with SPDX operators. The license operators link license identifiers. Permitted operators must be selected according to the standard. If individual licenses of a multiple licensing conflict with the releasing openCode license list, this conflict must be resolved, e.g. by selecting a license released on openCode. However, no selection needs to be made as long as all licenses of an option are released on openCode.
• LÄ.3.1 Exception clauses for licenses:If an exception clause is attached to a license text, it must be attached to a license identifier with WITH in accordance with the permitted SPDX operators.The names of the exception clauses, so-called exceptions, are to be described with identifiers analogous to the notes on license identification.LI.1 according to https://spdx.github.io/spdx-spec/v2.3/SPDX-license-list/#a2-exceptions-list, LI.2 analogous in license database Scancode LicenseDB AboutCode, LI.3 analogous notations.
• Exception clauses are generally permitted if they do not impose any further restrictions on use and application.If you are unsure, please contact info@opencode.de
• LÄ.4 Text Modifications: If a wording in a license text is changed compared to a released license text of a license, the license text can be assigned to the releasing license at openCode's discretion if the change is not substantial. In case of uncertainties, openCode is happy to provide support via info@opencode.de

2. Open-Source-License-List Kopiert!

in version 1.5 (as at January 2024)

History:
V1.5 Individual correction RSA on 29.01.2024
V1.4 New licenses added on 29.11.2023
V1.3 Sort key is now the SPDX identifier and new licenses added on 30.10.2023
V1.2 New licenses added on 04.09.2023
V1.1 D-FSL-1.0 added on 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. Negative list of all non-released-licenses Kopiert!

in version 1.4 (as of November 2023)

4. Licensing questions Kopiert!

Figure 1: Licensing questions

5. License selection support Kopiert!