Table of Contents

sprungmarken_marker_66

1 Choosing a License

When finding a license, it should be considered from the outset that, in addition to the interests of the project managers, the interests of other parties must also be taken into account. For example, there may be interests on the part of the higher-level OU or KIT that relate to exploitation and patent interests. Project partners and contributors may also have an influence on the license to be selected. In order to take these interests into account accordingly, we have visualized the decision-making process in 3 flowcharts and summarized the relevant points in bullet points.

1.1 Interests of the superordinate OU and KIT.

On the part of the OU are to be clarified:

  • Are there exploitation interests (e.g. with regard to patents or proprietary software licensing)?
  • Is the outlicenising of the software code subject to an embargo or ethical restrictions?
  • Are there any requirements from funders that prescribe certain licenses?

 

 

1.2 Consideration of project partners and code contributors. Clarify the licensing framework conditions.

Here it is clarified whether the licensing framework conditions have been clarified:

  • Are there external contributors (also students who do not have an employment relationship with KIT according to §69b UrhG)?
  • Is external open source code used?
  • Are proprietary code blocks to be integrated?
  • Have CAs (contributor agreements) been concluded with the contributors?
  • Creation of documentation for complete proof of license compliance (e.g. SBOM - software bill of material)

 

 

 

1.3 Decision on license

Flowchart 2 shows the license for two general types: "permissive" and "copyleft".

 

 

1.4 Compatibility matrix of OpenSource licenses

Outbound License in rows | Inbound License in columns

  GPLv3 LGPLv3 AGPLv3 EUPL 1.2 MIT/BSD2 X11/BSD3 Apache 2.0 Proprietary Description
GPLv3 ✅ ✅ ✅ ✅ 1 ✅ ✅ ✅ ❌ SPDX / Short
LGPLv3 ❌ ✅ ❌ ❌ ✅ ✅ ✅ ❌ SPDX / Short
AGPLv3 ✅ ✅ ✅ ✅ 1 ✅ ✅ ✅ ❌ SPDX / Short
EUPL 1.2 ❌ ❌ ❌ ✅ ✅ ✅ ✅ ❌ SPDX / Short
MIT/BSD2 ❌ ❌ ❌ ❌ ✅ ✅ ❌ ❌ MIT-SPDX / MIT-Short
BSD2-SPDX / BSD2-Short
X11/BSD3 ❌ ❌ ❌ ❌ ✅ ✅ ✅ ❌ X11-SPDX / X11-Short
BSD3-SPDX / BSD3-Short
Apache 2.0 ❌ ❌ ❌ ✅ ✅ ✅ ✅ ❌ SPDX / Short
Proprietary ❌ ❌ ❌ ❌ ✅ ✅ ❌ ❌  

 

2 Tools for the development of software projects

The development of software projects should be carried out on modern software platforms such as GitLab (SCC) or GitHub. These have intelligent mechanisms for collaboration and enable traceable storage as well as documentation of the software. Furthermore, these platforms offer tools for capturing and incorporating Contributor Agreements (CAs), as well as for checking license compliance and code quality. When using GitLab/GitHub, care should be taken to give contributors the appropriate roles to ensure systematic review of code contributions. Developers should be given the Developer role, and administrators the "Maintainer" or "Project Manager" role.

3 License handling - Contributor Agreements: templates and documentation

3.1.1 Simplified license marking and copyright notices

  • Suitable for small projects with clear overview of contributors.
  • Attachment of a License.md with the text of the outbound license used
  • Sttachment of a Copyright.md with the details of the creators and copyright holders

3.1.2 inbound=outbound

  • On GitHub, every user has to confirm the "Terms and Conditions" once, accepting that contributed software automatically takes over the license of the main project.
  • Since in GitLab (KIT) no terms and conditions have to be confirmed, this can be controlled by explicitly requesting to accept them in a merge request.
  • In the root directory of the repository, one can be specify rules of this kind for example in a file "terms_and_conditions.md", which must be confirmed then in the merge request.

3.1.3 Extended procedure with license header

  • For better traceability it is recommended to provide each source code file with a license header. This procedure later enables a better automated license check as well as the automated creation of the SBOM (software bill of materials):

3.1.4 Licenseheaderdesign in License.md or in sourcecodefiles

Example: License identification
SPDX-License-Identifier: (Example: GPL-2.0-or-later)
Copyright 2020-2022, Copyright Owner: Karlsruhe Institute of Technology (KIT)
Author: Martina Musterfrau, Max Mustermann
Contact: email∂institute.kit.edu, Institute of Software Development

3.2 Rights transfer via ContributorAgreements

3.2.1 Simple procedure via header identification

External contributors who are not subject to §69b UrhG (e.g. KIT students without a corresponding HiWi contract) and who are willing to grant KIT the rights to modify the license can do so in an additional header line for the assignment of rights:

Example: rights transfer
SPDX-License-Identifier: (Example: GPL-2.0-or-later)
Author: Martina Musterfrau, Max Mustermann
Contact: email∂institute.kit.edu, Institute of Software Development
1. Copyright © 2018, 2020-2022, Karlsruhe Institute for Technology
2. KIT may place softwarecontribution under any license.
3. KIT may place softwarecontribution under any other open source license!

3.2.2 Manual agreements

  • Contributor Agreements can be created in dialogue form in the following portal: CA Generator
  • Contract options: There are two templates to choose from:
    • Custom CLA: 5 options that can be selected to govern the license agreement between the project and the contributor.
    • recommended by FSFE: 3 options (options 1 to 3 from table)
Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 (planned)
any FOSS license usable (permissive/copyleft) only listed FOSS licenses usable (input required) only FOS licenses conforming to KIT policy usable inbound=outbound any license usable (also proprietary) any license usable + additionally inbound=outbound

The options specify which license the contributed software should be able to accept.

3.2.3 in case of unclear contractual situation

  • For CAs that cannot be legally regulated via header marking or manual contracts, it is recommended to contact "RECHT" (regarding legal questions, e.g. DualUse) or "IRM" (regarding exploitation-oriented questions, e.g. DualLicensing).

4 Inclusion of meta-data

  • Providing metadata about the project is very helpful for automated search by research platforms and required to comply with the FAIR principles for research software, which aim for findable, accessible, interoperable and resusable software.

4.1 Project specific metadata

  • Info on general project data such as name of project/contributors/licenses, etc for example in the README.md file.
  • To inform users of your software how to attribute it, include a freetext CITATION.md in the repository, or even better a CITATION.cff file, which can be automatically parsed.

4.2 Comprehensive metadata in standardized formats for retrieval and archiving in persistent repositories (e.g. RADAR4KIT)

  • One standard format to include metadata is the codemeta.json file. You can for example generate it using the CodeMeta web portal and then place it in the root directory of the repository.
  • You can use the FACILE-RS tool to automatically derive other metadata files from this (CITATION.cff, Datacite) and to publish releases of your software on RADAR.

5 Cookiecutter KIT-template:

The Cookiecutter template provides a good starting point for new KIT software projected and already includes basic metadata file templates (LICENSE.txt/CITATION.cff/README.md and codemeta.json).

5.1 Instructions for using the cookiecutter template

In order to generate a project from this template:

6 Further documentation

  1. https://joinup.ec.europa.eu/collection/eupl/news/eupl-or-gplv3-comparison-t - see "5. Freedom and Copyleft effect" for EUPL v1.2  ↩2