Defining a FOSS policy
One goal of Hermine is to help define a FOSS policy by providing a framework to analyse FOSS licences in a consistent and systematic way.
The analysis of a licence is divided in three parts:
The global characterics of the licence
For licences that are only authorized in specific contexts, the list of authorized contexts
Its decomposition into different obligations.
Global characterics of licences
Characterics pertaining to the identity of the licence
The short SPDX ID of the licence, including possible exceptions.
GPL-3.0-only WITH GCC-exception-3.1
The full name, as defined by the SPDX standard
The reference URL of the licence
The type of reciprocity clause of the licence.
Possible choices are:
Strong network copyleft
Weak network copyleft
If the licence if considered Free or Open Source software.
Possible values are:
We consider it is FOSS
We consider it is NOT FOSS
FOSS - deduced (when it’s approved by the FSF or the OSI)
NOT FOSS - deduced (when the FSF or the OSI have explicitely declared it as such)
The choice of applicable law
The choice of venue
Disclaimer of Warranty:
If the licence has a warranty disclaimer
Limitation of Liability:
If the licence has a non-liability clause
Exact text of the license:
The whole text of the licence, in case it is not referenced on the SPDX website.
The possible choices are:
The acceptability of the licence.
Possible choices are:
Always allowed (Green)
Never allowed (Red)
Allowed depending on the context (Orange)
Note: the Policy will remain Grey until it has been reviewed
OSS Policy explanation
The motivation for non green choices, and the acceptable contexts for orange licences.
To explain the interpretation of the licence
Conditions of use
True if the licence contains a patent grant, along with the copyright grant.
True if the licence contains an ethical clause (e.g. the JSON Licence)
Only non-commercial use
True if the licence allows only non-commercial uses (e.g. Creative commons with a NC clause)
Other optional information
The information below can be usefull, but is considered secondary from an operational point of view (only available in the Django Admnin interface).
categories: Currently, it is just a text to receive free text, that could be a comma separated list, for instance.
license_version: The version of the licence (e.g. “2.1” for LGPL-2.1-only).
radical: The root of the name of the licence (e.g. “LGPL” for LGPL-2.1-only).
autoupgrade: True if the licence authorise to apply latter versions of the licence (e.g. : False for LGPL-2.1-only and True for LGPL-2.1-or-later)
steward: The name of the entity that is allowed to create new versions of the licence (e.g. : the Eclipse Foundation for the EPL-2.0)
inspiration_spdx: The licence that served as inspiration for the analysed licence, mentionned by its SPDX ID, in case it’s not registered in Hermine
inspiration: The licence that served as inspiration for the analysed licence, in case it’s registered in Hermine
osi_approved: If the licence has been approved by the OSI
fsf_approved: If the licence has been approved by the FSF
non_tivoisation: True if the licence contains a clause against tivoization (e.g. GPL-3.0-only)
Obligations and generic obligations
Text of the obligations
For each licence that you analyse, you can extract from its text the part that is relevant to each individual obligation. For instance, in the BSD-3-Clause, this would be typed :
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Obligations that require specific actions to be in compliance with the licence.
For instance, in the BSD-3-Clause, the following obligation is active:
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Obligations that require that you refrain from doing something.
For instance, in the BSD-3-Clause, the following obligation is passive:
Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
Triggers of the obligation
An active obligation can be triggered by the combination of two factors. The first one is related to the exploitation of the software, the second one to its modification status.
Exploitation: Indicates which scenario triggers the obligation
Distribution as source code
Distribution as non source form
Providing access through the network
If an obligation is triggered by two different types of exploitation, you’ll have to create two instances of this obligation, one for each triggering scenario.
Modification: Indicates if the obligations applies only if the component is modified, only if it is not modified or in both cases.
A licence obligation can be related to a generic obligation. A generic obligation is a way to group licence obligations that would amount to the same operational actions.
Core set of generic obligations
Some generic obligations are very common and have a low cost of implementations. It appears often more effective to honor for every licence, even if the licence doesn’t explicitely require it.
The set of such generic obligations are named “core generic obligations”.
So if a release of a product has all its generic obligations in the core, you know that you don’t have any specific action to perform to reach compliance.