Editorial notes (collapse)

PDF booklet

A4 Letter Display Download

---

Additional functions using JSON converted checklists (Feedback)

Some additional functions can be performed on the overview page of the checklist if two or more licenses are selected using the checkboxes to the left of the license names. They are all based on the JSON converter, which is available and described separately here.

Context diff of selected licenses:

When exactly two licenses are selected, a button labeled "Show context diff" appears below the list of licenses. It can be clicked to open a new web page with a colorified output of the context diff of the two licenses after conversion to JSON format.

Concatenate selected licenses:

A project may contain a number of components that are distributed under more than a single license. One of the two methods of combining such licenses is to concatenate them. To do this, click on the "Concatenate selected licenses" button. The selected JSON-converted checklists are then concatenated in a JSON super dictionary with the key "OSADL OSLOC".

Merge selected licenses:

A project may contain a number of components that are distributed under more than a single license. In an approach other than concatenation, it may be desirable to merge the various license obligations so that duplicate license obligations are named only once and only different obligations are concatenated. This approach allows to add some more features, such as further subsuming obligations using unification (see below) or adding a list of incompatible licenses, if any, for the current selection of licenses. Furthermore, newer versions of licenses that may mitigate license incompatibility issues can on request automatically replace the older ones (also see below). To execute this merging operation, select the unification checkbox or leave it unselected, select the license upgrade checkbox or leave it unselected, then click on the "Merge selected licenses" button.

Unification: The unification rules currently in use can be viewed on the screen by clicking the "Show unify rules" button. In a first step, it is tested whether all obligations that are listed in the left column of this table are assigned to a particular use case or condition. If this is the case, they will be replaced by the single obligation given in the right column of that table.

License upgrade: The license upgrade rules currently in use can be viewed on screen by clicking on the "Show upgrade rules" button. If selected, the license in the second column will be used instead of the one in the first column. If an additional license obligation is imposed to make the license upgrade effective, this obligation is given in the third column.

Track obligations: When returning merged licenses to the checklist user interface, it may be important to trace the origin of a particular license obligation. The "Ref." button is used for this purpose; when clicked, the name or names of the licenses from which the obligation was taken are listed. If the unification rules are activated, the wording of the original obligation before unification is displayed in brackets in front of the corresponding license names.

Incompatible licenses: In addition to the original checklists, the merged checklist optionally contains the key "INCOMPATIBLE LICENSES". This key is associated with a list of licenses that may be incompatible with the current set of licenses, if used for a combined work and distributed. Some items are simply taken from the "INCOMPATIBILITY" key of the original licenses, if applicable. Some other items are added individually and also take into account under which license the present license mix is distributed. Please note that all information with respect to compatibility or incompatibility is based on the assumption that the licenses are used for software components that altogether form a combined work.

Checklists scope (Feedback)

The checklists assume a situation where a licensee of Open Source software incorporates such software components into a product - either a physical device with installed software or a software distribution on a storage medium or on the Internet - and needs to establish appropriate processes in order to fulfill the imposed license obligations for legal compliance when conveying the product to customers.

Implicit obligations (Feedback)

A license may contain implicit obligations, if a more general obligation mentions a prerequisite that must not necessarily be available. For example, the obligation

YOU MUST Provide License text In Documentation OR Distribution material

gives no instruction how to act, if the software came without documentation or distribution material. Thus, an explicit version of this obligation may read either

• You must provide the license text in the documentation or in distribution material, if such material came with the software. If it did not, this obligation is void.

or

• You must provide the license text in a documentation or in distribution material. If such material did not come with the software or it did, but does not contain the license, appropriate documentation or distribution material must be created and at least the license text must be included in it.

In the checklist "language", the first interpretation would be encoded as

IF Documentation OR Distribution material Is Available

YOU MUST Provide License text In Documentation OR Distribution material

while the second interpretation simply would become

YOU MUST Provide License text In Documentation OR Distribution material

and imply that such material must be created if not available.

The second interpretation is assumed in all checklists, unless the license specifies otherwise.

JSON schema principles (Feedback)

General rule when converting checklists to JSON format:

As a general rule, non-optimized OSADL OSLOC checklists in JSON format are recursive associative arrays with the language construct as key and the related dependent text such as use case, license obligation or further attributes as value, but the value may be void. For example, a simple checklist in a file named CHECKLIST may read

USE CASE Source code delivery

YOU MUST Forward License text

YOU MUST Forward Copyright notices

IF Source code modification

YOU MUST Provide Modification report

YOU MUST Provide Copyright notices

USE CASE Binary delivery

YOU MUST Provide License text In Documentation OR Distribution material

which will become

in JSON format. Arrays with empty values can be converted to a string, if a single key exists or to a list, if more keys exist. Thus, after optimization the above checklist would become:

Special case:

Since a particular checklist hierarchy level may contain more than a single "EITHER", "OR", "EITHER IF" or "OR IF" element that are significant in the original checklist, but are not in the JSON format because the ordering is lost, an enumeration level had to be introduced. The checklist snippet

USE CASE Binary delivery

EITHER

YOU MUST Distribute Source code In Product

OR

YOU MUST Provide Delayed source code delivery

OR

YOU MUST Provide Source code Via Internet

EITHER

YOU MUST NOT Promote

OR

YOU MUST Credit Original authors

will be converted to the JSON snippet

or after optimization to

This additional enumeration ensures that the original checklist can be reproduced from the JSON version and that several JSON checklists can be combined and thus simplified (see also this project.).

JSON schema:

A schema to validate license checklists in JSON format (plain and optimized version) is shown below. This is version 2 of the schema. It validates single as well as merged licenses.

Language manual (Feedback)

Language constructs:

Dependent blocks: Several language constructs that depend from a given use case or condition are combined into a block by indenting them with a single tabulator. Spaces cannot be used instead.

USE CASE: A condition offered by the license that can freely be selected by the licensee, must be followed by an indented block of one or more dependent license obligations.

IF: A condition that was selected for a particular product and is treated by the license in a particular way. It must be followed by an indented block of one or more dependent license obligations.

YOU MUST: A license obligation, must be followed by an action; if more than a single obligation is given in the same block, all of them must be fulfilled. Alternatively, a YOU MUST language construct may be indented and preceded by a line with the EITHER language construct in which case at least this or one of the following obligations that are preceded with the OR language construct must be fulfilled.

YOU MUST NOT: A license prohibition, must be followed by an action; if more than a single prohibition is given in the same block, all of them must be fulfilled. Alternatively, a YOU MUST NOT language construct may be indented and preceded by a line with the EITHER language construct in which case at least this or one of the following obligations that are preceded with the OR language construct must be fulfilled.

ATTRIBUTE: Describing property of an action or a term that may be selected from the available terms.

Referencing:

A reference to the original license text must be separated by a vertical bar (|) from the obligation part of the checklist. By default, the entire text section that contains the reference is cited. Particular sections of the license text to be displayed, but not highlighted, may be replaced with an asterisk (*). The vertical bar may be used repeatedly, if references from more than a single text sections are to be cited. Consecutive spaces in the license and the reference text a squeezed into a single space when compared and displayed.

Special referencing of INCOMPATIBILITY: Exactly two references separated with a vertical bar are required, the first one referencing a contradicting text section of the other, and the second one referencing the contradicted text section of the current license.

License compatibility (Feedback)

Compatibility of a particular first (leading) license with another (subordinate) license becomes an issue when a work that is licensed under the other license is to be integrated into a common work and to be compliantly copied and distributed under the leading license.

Such compatibility is assumed, if

• compatibility with the other license is explicitly ruled in a particular license, or
• the two licenses in question both do not contain a copyleft clause, or
• the leading license contains a copyleft clause and the other license does not and also does not impose any obligation that the first license does not allow to impose.

Incompatibility is assumed, if

• incompatibility with another license is explicitly ruled in a particular license, or
• one license imposes an obligation that the other license does not allow to impose, or
• the two licenses in question both contain a copyleft clause and no license contains an explicit compatibility clause for this license combination.

In addition, the term "dependent compatibility" has been introduced. Such compatibility is assumed if the two licenses are incompatible, but one or both licenses explicitly allow the license to be updated to a newer version or to switch to another license that is then no longer incompatible. The respective change path is described in the "Interpretation" of the DEPENDING COMPATIBILITY line of the checklist.

License rights and obligations (Feedback)

Software licenses normally grant rights and, in turn, impose obligations. The Open Source license obligations checklists project aims to provide complete lists of license obligations that, if fulfilled without exception, very probably lead to license compliance. Rights, however, are not listed, since one of the prerequisites of entering a particular license into the project is that this license grants the elementary unrestricted, unlimited, royalty-free and non-discriminatory rights of an Open Source license such as to i) use, ii) analyze, iii) modify and iv) convey original or modified versions of the software.

The English language provides a number of direct and indirect ways to impose an obligation:

1. "YOU MUST do something" is evident.

2. "YOU MUST NOT do something" is evident.

3. "YOU MAY NOT do something" is equivalent to "YOU MUST NOT do something" and also is evident.

4. "YOU MAY ..." followed by an at first glance positive, but nevertheless somewhat restrictive statement is less evident. However, it still may contain an obligation.

a) "YOU MAY only do something" is equivalent to "YOU MUST NOT do anything else than something".

b) "YOU MAY do less than something" is equivalent to "YOU MUST NOT do same or more than something".

c) "YOU MAY do up to a threshold" is equivalent to "YOU MUST NOT do more than the threshold".

5. "YOU SHOULD do something" is a recommendation, not an obligation.

6. "YOU SHOULD NOT do something" is a prohibition, not a recommendation.

Software modification and copyleft (Feedback)

Open Source licenses always permit changing or expanding existing material or combining it with other components. In some cases, the license imposes obligations on the resulting modified work. In particular it might be required to license the modified work under the original license. Such a clause in an Open Source license is called "copyleft". The scope of a copyleft clause, i.e. which modifications must be licensed under the original license, depends on the individual license. Some licenses state the scope of the copyleft clause explicitly, i.e. the file-based copyleft of the MPL-2.0 or the exemption of linked components from copyleft of the LGPL-2.1. For others it is open to interpretation. To reflect these differences in the canonical language of the checklists, a copyleft clause appears twice in a checklist.

• The actual obligations resulting from a copyleft clause are listed under the condition "IF Software modification" without specifying which types of modifications are affected.
• If applicable, the section "Copyleft clause" contains the reference to the respective wording in the license text to help interpret the scope of the copyleft.

Warranty disclaimer obligations (Feedback)

The warranty disclaimer may be part of the license text itself or not.

Without any particular hint, it is assumed that the warranty disclaimer, if any, is part of the license text. In this case, all license obligations are implicitly assumed to relate to the warranty disclaimer as well, no separate obligation is listed, and the warranty disclaimer is not provided as template.

Sometimes, however, the warranty disclaimer is separated explicitly from the license text for example by adding it in an appendix of the license text or by marking the end of the license text and providing the text of the warranty disclaimer thereafter. A similar situation is created when the warranty disclaimer is at the end of the license text, but the license obligations do not refer to the entire text, but only to the license permissions and obligations and mention the warranty disclaimer separately. In these cases, provisioning of the warranty disclaimer is explicitly mentioned in a YOU MUST license obligation, and the warranty disclaimer is provided as a template.