You are here: Home / Projects / 
2018-03-19 - 17:40

Open Source License Checklists

Background and goal of the project

Whenever Open Source software is copied and distributed which typically is permitted by every type of Open Source license, a number of obligations and prohibitions are imposed on the distributor. As a very common situation of such software, the receivers of the software will recursively redistribute it in such a way that a chain of distributors and receivers is created – all of them having to fulfill the same license obligations. However, for the time being, there is no common understanding how these obligations are to be fulfilled in detail which regularly leads to misunderstandings, conflicts and sometimes even to court cases.

This project is launched with the goal to create generally accepted checklists of the obligations of commonly used Open Source software that are accepted by distributors and copyright holders and trusted by all members of the distribution chain.

Instructions for participants

What has to be developed?

In order to be accepted by a large variety of professionals, the checklists must be written in plain English language using the identical words for the same condition or action. However, in many cases different license texts use different words for the same condition or action which makes it necessary to create a vocabulary of common license terms. This vocabulary must clearly describe every item of the vocabulary in such a way that it can be used to create canonical versions of the license texts. A selection of frequently employed and important Open Source licenses will then be compiled into checklists and undergo review by the project participants. The license display engine adds tooltips to the language construct, actions and terms and allows to provide references to the original license text with highlighting in order to facilitate working and collaboration in the project.

How to contribute?

The below Web links lead to overviews of the various vocabularies and from there to individual checklist elements each on a separate page. An editable text field at the end of every page with a submit button is used to forward a participant's contribution to the OSADL project team along with the name of the item and the email address of the contributor. The submitted text will then be added as quickly as possible and the contributor be notified.

"Language" elements

On the base level, a license contains obligations (“YOU MUST”) and prohibitions (“YOU MUST NOT”). In order to allow for the extraction of license obligation and prohibition in atomic granularity, “YOU MUST” and “YOU MUST NOT” atoms may be repeated as often as required. The atoms are understood as logical “and” elements, i.e. all of them must be followed to reach license compliance. The arguments of the atoms, i.e. what must or what must not be done, are described with words that are selected from a vocabulary. This vocabulary along with a distinct description of every term and action will be created and reviewed in the course of the project.

Sometimes the license obligation atoms may allow the distributor to freely select between a number of optional use cases; therefore, the “USE CASE” element is introduced which, in turn, may again be followed by “YOU MUST” and “YOU MUST NOT” atoms depending on the selected option. Several "USE CASE" elements to which the same license conditions apply may be combined using the "OR" element. In addition, the license may contain certain obligations that only are applicable, in case a particular unalterable condition is present; to encode such a situation the “YOU MUST” and “YOU MUST NOT” atoms may be preceded by the “IF” element along with a condition. To further specify a term, it may be followed repeatedly by an “ATTRIBUTE”. Finally, elements may be negated by preceding it with the element "NOT".

Hints to compatibility, patents and copyleft

If a license has a copyleft clause, it is marked and referenced using the "COPYLEFT CLAUSE" language construct. The same applies to patent hints which are encoded using the "PATENT HINTS" language construct. Compatibility with another license, i.e. whether software that uses another license can be integrated into software that uses the current license and copied and distributed in a compliant way is encoded and referenced using the "COMPATIBILITY" language construct. Incompatibility is encoded in a similar way, but there is an exception how referencing is handled, since two references separated by a vertical bar are required after the "INCOMPATIBILITY" language construct – the first one is the license obligation of the other license and the second one is the contradicted license obligation of the current license. Non-copyleft licenses are implicitly assumed to be compatible between each other.

How to participate?

The project is funded by a joint interest group, and participation is requested using a Letter of Intent.

Links to the project pages (currently restricted to project participants)

Editorial notes

  • Compilation rules


  • Language constructs
  • Actions
  • Terms


  • Checklists
  • Copyleft table
  • Patent hints table
  • Compatibility matrix


  • Ready-made text building blocks to fulfill certain license obligations