Community SUmmit: Legal & Licensing / A standard nomenclature to identify the obligations of FOSS licenses / Benjamin Jean


Published on

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.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Community SUmmit: Legal & Licensing / A standard nomenclature to identify the obligations of FOSS licenses / Benjamin Jean

  1. 1. Identify the obligations ofOpen Source & Free licenses on the basis of a standard nomenclature  Benjamin Jean
  2. 2. Summary What is a license License proliferation Why we need some clarification First classification (draft)  Rights/Obligations/Scope/Trigger
  3. 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. 4. License proliferation Number of licenses is increasing OSI : 70 licenses FSF ”free licenses” : approximately 50 licenses Black Duck: more than 1 000
  5. 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. 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. 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. 8.  Needs for a common nomenclature  detailed and scalable  descriptive (doesnt 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. 9.  international standardization bodies.  Might be a good way  Expensive
  10. 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. 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 doesnt  share the right to perform or to display)
  12. 12. But the real difference isnt there: There are (too) many :  trigger  scope  obligations...
  13. 13. Obligations  : no common definition need to identify / classify the obligations (licenses,  but also exception)
  14. 14. A standardization is useful for : client (PA in call for tenders)  OS industrialization  Open Source projects Users / Licensees (community)
  15. 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. 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. 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. 18. obligation to give : concerning rights given by the licensor  IP rights
  19. 19. Further classifications Resolution (if licensee dont respect the license)  automatic resiliation  30 day redemption clauses (Android GPLv2 ). Scope Trigger
  20. 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. 21. Trigger : distribution (GNU GPL v2 and many variants) Use (RPL) External deployment (OSL, GNU AGPL, EUPL,  MPL v2)
  22. 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, lEPL v. 1.0, the CeCILL v. 2.0  and the GNU GPL v. 2.0.) to integrate : additional terms
  23. 23. Comments/Remarks...Are welcome