Defining a FOSS policy
One goal of Hermine is to help define a FOSS policy by providing a framework to analyze FOSS licenses in a consistent and systematic way.
The analysis of a license is divided in three parts:
The global characteristics of the license
For licenses that are only authorized in specific contexts, the list of authorized contexts
Its decomposition into different obligations.
Global characteristics of licenses
Characteristics pertaining to the identity of the license
SPDX Identifier:
SPDX is an open standard for communicating software bill of material information, including components, licenses, copyrights, and security references. SPDX short-form identifiers permits to communicate FOSS license information in a simple, efficient, portable and machine-readable manner.
Copyright notice:
Copyright notice is a legal form of notice to inform the public that the work is protected by copyright law and potentially gives information about the copyright owner, the date of publication etc.
Copyleft:
This clause present in the Open Source licenses imposes to the one who uses and/or modifies a component under the aforementioned license to redistribute/use it under the terms of the same license.
Possible choices are:
Permissive: When the open source license does not require redistribution/reuse of the component under the terms of the same agreement.
Strong copyleft: Derivative works or works based on the Open Source Software must be distributed under the initial license or another license approved by the initial license.
Weak copyleft: Redistribution of the software or work, modified or not, can only be done under the initial license, but new components can be added under other licenses, see proprietary license.
Strong network copyleft: Derivative works or works based on the Open Source Software must be made available to users interacting with your application remotely through a computer network under the initial license or another license approved by the initial license.
Weak network copyleft: Redistribution of the software or work, modified or not, can only be made available to users interacting with your application remotely through a computer network under the initial license, but new components can be added under other licenses, see proprietary license.
FOSS:
FOSS is the official definition of the Free Software Foundation or the Open Source Initiative.
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 explicitly declared it as such)
Permissive: When the open source license does not require redistribution/reuse of the component under the terms of the same agreement.
Law choice:
Provision of the License Agreement establishing the law applicable to the License Agreement.
Venue choice:
Provision of the License Agreement establishing the location of competent courts in case of litigation relating to the License Agreement.
Disclaimer of Warranty:
A provision in the License Agreement aiming at excluding or limiting certain warranties over the said component.
Limitation of Liability:
Provision in the contract that reduces or eliminates the possibility of being held liable for an event related to a product or service offered
Full Clause Full clause Indicates whether the no warranty and limitation of liability clause is fulfilled.
AND: Term indicating that the right holder has submitted the component to multiple licenses at once
OR: Term that indicates that the owner of the right to subject the component to multiple licenses from which the user can choose
Foss Policy
Review status
The possible choices are:
To check
Checked
To discuss
Pending
FOSS Policy status
The status of the license as defined by the Open Source policy.
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
Conditions of use
Patent grant
A specific situation in which the text of a license also grants an exclusive, worldwide license on the patents to make, have made, use and sell the licensed products.
Patent Peace:
Enforcing patents against licensees or making a non-infringement agreement contrary to the license is prohibited.
Ethical clause
A provision in the License Agreement setting certain rules relating to ethical practices and laws that may apply.
Only non-commercial use
Provision in the contract prohibiting its use is subject to a financial consideration or a commercial advantage.
Specific technical notions
Dependencies: Software element necessary for the execution of a program. A distinction is made between direct dependencies (dependencies that are called explicitly by the application that uses them) and indirect dependencies (called “dependencies of dependencies” of the application). Network access: Functionalities provided by the network (back-end). Non-source code distribution: Distribution in a form (e.g. binaries/object code/obfuscated code, etc.) which is not the preferred form for carrying out modifications. Source code Distribution: Distribution in a preferred form for making changes (source code). Source code and non source code distribution: Distribution in a preferred form for making changes (source code) and in a form (e.g. binaries/object code/obfuscated code, etc.) which is not the preferred form for carrying out modifications. To normalize: Check that components have valid SPDX license expressions during the Step 1 and add curation if not. Versions: Versions refer to components (release refer to a product).
Other optional information
The information below can be useful, but is considered secondary from an operational point of view (only available in the Django Admin interface).
categories:
steward:
osi_approved:
fsf_approved:
non_tivoisation:
Obligations and compliance actions
License obligations
Core obligation: Set of obligations an organization systematically applies according to its open source compliance policy. Core status: Status indicating whether or not the obligation is in the core.
Text of the obligations
For each license that you analyze, 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.
Active/Passive obligation
Active Obligations Active obligations are those that require the team to act.
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.
Passive Obligations
Passive obligations are those that can be met without specific action.
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:
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 apply only if the component is modified, only if it is not modified or in both cases.
Compliance actions
A licence obligation can be related to a compliance action (in older versions of Hermine, a “generic obligation”). A compliance action is a way to group license obligations that would amount to the same operational actions.
Core set of compliance actions
Some compliance actions are very common and have a low cost of implementations. It often appears more effective to honor for every license, even if the license doesn’t explicitly require it.
The set of such compliance actions are named “core compliance actions”.
So if a release of a product has all its compliance actions in the core, you know that you don’t have any specific action to perform to reach compliance.