License Management Process for 52°North Software Projects

---

Introduction

Licensing plays a central role in today's Open Source Software projects. It has an impact on a project's user base, as well as, on third-party software that can be used within a software. 52°North strives to address project-specific circumstances. This page summarizes the guidelines for all software projects hosted as Open Source within the 52°North network. We try to be as transparent as possible and to support the scope of inidividual projects in a reasonable manner. If you miss something or need clarification, add a comment or contact Matthes.

Guidelines

In order to assess a software project, the project's code manager (probably you) shall follow these guidelines. Strict requirements are marked with .

License Types

Projects hosted within the 52°North network shall use either

• the GNU General Public License, Version 2 (GPL, scope: web services, clients [web or desktop]) or
• the Apache Software License, Version 2.0 (ASL, scope: classic middleware, processing engines, data bindings).

We cannot build a knowledge base for every variety of existing licenses and therefore focus on these two established ones. They cover most use cases very well.

Use of Third-party Components

Most of the hosted projects use a set of third-party components (e.g. .jar libraries within a Java project, .h header files for C projects). As every component is published under a certain license, its compatibility with the project's license has to be assessed. In order to do so, we have created whitelists, greylists and blacklists for the two aformentioned project license types:

• Third-party licensesfor GPL
• Third-party licenses for ASL

Third-party components with a whitelisted license can be included without any problems.

If you would like to include a greylisted component, please get in touch with Matthes and provide a brief summary of the planned usage (linking/importing, runtime dependency, etc.).

Blacklisted libraries cannot be included into the project. If you think they can, also get in touch with Matthes.

Hosting Source Code

Every source code project hosted within the 52°North network shall have a license header in each source file. This allows easy identification of a single source file with 52°North and also covers specific aspects that need to be addressed when using grey listed third-party components.

Source file headers must be in line with the project's license:

• ThirdPartyLicensesForGPL
• ThirdPartyLicensesForASL

Metainformation

A software project shall provide a set of metadata organized in dedicated files in the project's root directory:

• README or README.md, providing
  • basic project information (name, description, version, scope, date of inception)
  • contact information (code manager, contributors)
  • installation/deployment guidance
  • project URL (e.g. https://52north.org/sos)
  • link to the project's source code management (SVN, Git, etc.)
• LICENSE, providing
  • the full text version of the project license
• NOTICE, providing
  • a list of the used third-party components and their licenses (see Apache's information on NOTICE files)

Projects with Issues

If you are not sure whether your project follows these guidelines, please get in touch with Matthes. If your concerns include issues with third-party components, fill the license template and attach it to your email.

In certain situations (e.g. when one of the steps is not addressed and is obviously not easily resolvable) we might consider restricting public access to the project's SCM. This will of course be discussed with the code manager. Subsequently, we will provide support on how to resolve existing issues. Once the issues are resolved, the access to the SCM will be made public again.

Transition (DRAFT)

things to be considered when a projects desires a transition to another license (e.g. GPLv2 to ASL):

• do we need approval from all contributors? or is this covered by the CLA?
• prominently state this in an upcoming release (e.g. first entry in changelog)
• what else?

Release Guidance (DRAFT)

In order to create a release bundle, additional requirements need to be fulfilled. This can range from simply including the metainformation up to providing the full source of some third-party components. The following aspects shall be addressed when creating a release:

tbd

Good Practices

We have collected some good practices on how to integrate license management into the daily work of a software project. You can find these under BestPracticeLicenseManagementInSoftwareProjects.