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. It is very common for the recipients of such software to recursively redistribute it in such a way that a chain of distributors and recipients is created – all of them having to fulfill the same license obligations. However, for the time being, there is no common understanding of 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 generally establish checklists of obligations of commonly used Open Source software that are accepted by distributors and copyright holders and trusted by all members of the distribution chain.

Raw data

• Access to the raw data

Editorial notes

• All about the checklists

Vocabulary

• Language constructs
• Actions
• Terms

Licenses

• Checklists
• Acknowledgment table
  
• Copyleft table
• Patent hints table
• Source code disclosure table
• Compatibility matrix

Templates

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

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.

Data formats

The checklists are available in two formats, i) plain text with dependent text blocks by tabulator indenting and ii) JSON format with objects, arrays and strings where the language constructs are encoded as keys and the actions and terms as values. Both data formats are considered a primary data format of the checklists and are both maintained since they can be converted to each other without data loss. The JSON data structure can be validated against a schema, and a Python script is available that can be used among other for data format conversion.

The recommendations given by the license obligations checklists are not made to be taken as individual legal advice, which in some countries, in particular Germany, can only be given by certified personnel, i.e. lawyers. Therefore, access to the project material can be gained in two ways:

1. Access to the interactive user interface where use cases can be chosen to create customized checklists is granted on request. Please contact OSADL at officeªosadl.org to receive login data, information on the project and the legal disclaimer.
2. However, the raw data from which the checklists are created are available without access restrictions. This material may be incorporated into scanning tools, companies' internal utilities, and similar tools. Consequently, it is then the users' own responsibility to supply the checklist information in compliance with the national rules on legal advice. A description of how these raw data are available and can be accessed can be found here. Important note: This project is a work in progress, and additions, corrections and deletions are made on an ongoing basis. Therefore, it is strongly discouraged to save the data to a local file, but the current raw data from the OSADL website must always be used instead. If a local file has still been created, however, it may only be used if the up-to-dateness has been ensured beforehand. Instructions on how to do so are given here as well.