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.

1. Identify the obligations of
Open Source & Free licenses
on the basis of a standard nomenclature
 Benjamin Jean

2. Summary
 What is a license
 License proliferation
 Why we need some clarification
 First classification (draft)
 Rights/Obligations/Scope/Trigger

3. 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.)

4. License proliferation
 Number of licenses is increasing
 OSI : 70 licenses
 FSF ”free licenses” : approximately 50 licenses
 Black Duck: more than 1 000

5.  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

6.  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 Ke

7. 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.

8.  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

9.  international standardization bodies.
 Might be a good way
 Expensive

10. 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

11. 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)

12. But the real difference isn't
there:
 There are (too) many :
 trigger
 scope
 obligations...

13. Obligations :
 no common definition
 need to identify / classify the obligations (licenses,
but also exception)

14. A standardization is useful
for :
 client (PA in call for tenders)
 OS industrialization
 Open Source projects
 Users / Licensees (community)

15. 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)

16.  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

17. 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

18. obligation to give :
 concerning rights given by the licensor
 IP rights

19. Further classifications
 Resolution (if licensee don't respect the license)
 automatic resiliation
 30 day redemption clauses (Android GPLv2 ).
 Scope
 Trigger

20. Scope :
 very limited (permissive licenses)
derivative work can be published under different
licenses (BSD, MIT, Apache, etc.)
 limited
derivative must be under the same license /work based
on can be under different licenses (CeCILL­C, MPL,
GNU LGPL in certain conditions)
 standard/legal
legal interpretation (EPL, EUPL, OSL, etc.)
 Large
very large conception (include dynamic linking, etc.)

21. Trigger :
 distribution (GNU GPL v2 and many variants)
 Use (RPL)
 External deployment (OSL, GNU AGPL, EUPL,
MPL v2)

22. 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

23. Comments/Remarks...
Are welcome