Community SUmmit: Legal & Licensing / A standard nomenclature to identify the obligations of FOSS...
23
Identify the obligations of Open Source & Free licenses on the basis of a standard nomenclature Benjamin Jean
-
Upload
open-world-forum -
Category
Technology
-
view
528 -
download
1
description
The definitions of the Open Source Initiative (OSD) and the FSF (FSFD) are essential in the sense that they qualify Free or Open Source Licenses (FOS License) in regard to the rights and freedoms they confer (the two main lists of licenses are made on their base). However, they do not meet an other industrial need: the identification and classification of obligations (which differ between each license) for the licenses and their variants (especially when there are additional terms – for instance exceptions or interpretations). Thus, based on existing definitions and as a complement to their action against license proliferation, it seems necessary to consider the drafting of such additional nomenclature. Indeed, this work would be useful for two reasons: to meet customer's expectation in relation with the development of services around free software (so they can state precisely, but not limited to, the type of licenses they require); and to back advances made in computerization and software identifications of the components and their licenses (both community projects like SPDX, QSOS or business's like Blackduck). Firstly, the relevance of the approach itself will be discussed. Its sole purpose is to characterize a license or its variants on a common nomenclature (detailed and scalable), this the method can only be descriptive and cannot replace the current process of writing the licenses. It will participate in the dissemination of good practices for distributing free software, will contribute movement to the rationalization and standardization in favor of major licenses, and may possibly be based on an international standardization bodies. The second part of the presentation will be an opportunity to present a first classification, based both on existing work on personal thoughts. Indeed, it seems possible to use the classic typology (obligation to give, to do and to not do) while adding specific references to free licenses such as obligation for the various IP rights granted - or excluded - as well as those organizing the formalism associated with the license. Finally, this classification can include other particular elements of licenses such as scope and trigger.
Transcript of Community SUmmit: Legal & Licensing / A standard nomenclature to identify the obligations of FOSS...
Identify the obligations of Open Source & Free licenses
on the basis of a standard nomenclature
Benjamin Jean
Summary
What is a license License proliferation Why we need some clarification First classification (draft)
Rights/Obligations/Scope/Trigger
What is a license
License or contract => a tool
Composition: Rights and obligations Scope Trigger
Writers Foundations (FSF/SFLC, Apache, EPL, MPL, etc) Companies (Netscape, CPL, etc.)
License proliferation
Number of licenses is increasing
OSI : 70 licenses FSF ”free licenses” : approximately 50 licenses Black Duck: more than 1 000
Black Duck GNU GPL v2 (42.77%) MIT (11.29%) Artistic License (7.80%) GNU LGPL 2.1 (7.23%) BSD (6.79%) GNU GPL v3 (6.43%) Apache license (5.41%)
Open Source License Data
OpenLogic report Apache license (32,7%) GNU LGPL v2.1 (21%) GNU GPL v2 (14,4%).
What is the Top Open Source License?, Sean Michael Kerner, 2011
We need some clarification
To help people/software to understand licenses
The existing definitions OSD (10 criteria) FSD (4 freedom) other variants :
Open Cloud CC Open Hardware Etc.
But we also need to work on their differences, not only their similarity
Needs for a common nomenclature detailed and scalable descriptive (doesn't replace current process of writing
the licenses).
Effects participate in the dissemination of good practices Contribute to the rationalization and standardization in
favor of major licenses, help to define a vocabulary for the community
international standardization bodies. Might be a good way Expensive
First classification
Classification based both on existing work personal thoughts. Need to be improved!!!
Mixed between the classic typology (obligation to give, to do and to
not do) specific free licenses organization : Rights and
obligations ; Scope ; Trigger
Rights (users/licensees-oriented)
Harmonized by the existing definitions Sometimes
some more rights (sublicense ; compatibility ; additional terms)
some rights are missing (GNU GPL V2 doesn't share the right to perform or to display)
But the real difference isn't there:
There are (too) many : trigger scope obligations...
Obligations :
no common definition need to identify / classify the obligations (licenses,
but also exception)
A standardization is useful for :
client (PA in call for tenders) OS industrialization Open Source projects
Users / Licensees (community)
Obligations to do
licensee engage himself to do some acts in favor of the licensor or a third party (subsequent licensees)
In favor of the licensees : to deliver something or to inform.
To distribute under a certain license (copyleft license) same license other licenses (express compatibility)
In favor of the licensor : notice acknowledgement of the open source provider in
advertizing advertising; to distinguish each contribution, to update a file on
changes, Tribunal/applicable law
not to do :
not to sue copyrights patents Patent
not to use some trademarks, names, signs, etc. (to endorse)
to not delete notices About non commercial use
None discussed there
obligation to give :
concerning rights given by the licensor IP rights
Further classifications
Resolution (if licensee don't respect the license) automatic resiliation 30 day redemption clauses (Android GPLv2 ).
Scope Trigger
Scope :
very limited (permissive licenses)derivative work can be published under different
licenses (BSD, MIT, Apache, etc.)
limitedderivative must be under the same license /work based
on can be under different licenses (CeCILLC, MPL, GNU LGPL in certain conditions)
standard/legallegal interpretation (EPL, EUPL, OSL, etc.)
Largevery large conception (include dynamic linking, etc.)
(GNU GPL, CeCILL
Trigger : distribution (GNU GPL v2 and many variants) Use (RPL) External deployment (OSL, GNU AGPL, EUPL,
MPL v2)
Compatibility (express)
limited compatibility (only when you mix with some component under other licenses (for instance GNU LGLP)
extended compatibility (the OSL v. 2.1 and v. 3.0, the CPL v. 1.0, l'EPL v. 1.0, the CeCILL v. 2.0 and the GNU GPL v. 2.0.)
to integrate : additional terms
Comments/Remarks...
Are welcome
