Re: "Scope" of licenses to be covered by SPDX


Well I have not really through how this extend to the SPDX standard. But if you look at Blackduck protext tool there is probably 1500 to 2000 licenses described, Palamida is around 1500 (if I am not mistaking). The SPDX standard must cope with all these licenses, it should not limit itself to the 60 to 70 OSI certified licenses. It would be useless. Now if you have not a standard name for these licenses it is not a big issue but in fact they exist “Sun binary license”, “ Sun entitlement license”, “Oracle binary licence”, “ Oracle OTN license” (might also be “Oracle technology network” license) , “Alcatel-Lucent public license” …


Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France

De : Philip Odence [mailto:podence@...]
Envoyé : vendredi 22 juin 2012 19:49
À : Mike Milinkovich; Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); Michael Herzog; spdx@...
Objet : Re: "Scope" of licenses to be covered by SPDX


I sometimes skirt the issue by broadly referring "software that is freely available on the web." 


When one is talking about new projects, picking licenses, and the like, it makes sense to steer/limit to OSI approved licenses. When, on the other hand, the use case is documenting all the "junk" that may be found in a package and associated licenses (as with SPDX), it makes sense to be expansive in order to be able to represent software under licenses outside the OSI definition. 


So, the SPDX license list goes beyond the OSI list. Our goal has been to handle the bulk of license one might run into in a software package. And, the spec provides a mechanism for handling licenses not on the list, by essentially including the text of the license. One of the benefits of the License List is that it keeps the size of the SPDX file down by not requiring the text to be included.


I don’t think we've come to grips with where we draw the line on the size of the license list. With the 150 or so license on there now, we certainly handle the vast majority of components, but for user convenience, more is better. I think when we get comfortable with our understanding of the effort involved in maintaining the list and adding new licenses, we'll be in a better position to say how big we want the list to be.


From: Mike Milinkovich <mike.milinkovich@...>
Organization: Eclipse Foundation
Reply-To: Mike Milinkovich <mike.milinkovich@...>
Date: Fri, 22 Jun 2012 13:24:42 -0400
To: <Soeren_Rabenstein@...>, Michel Ruffin <Michel.Ruffin@...>, Michael Herzog <mjherzog@...>, <spdx@...>
Subject: RE: "Scope" of licenses to be covered by SPDX


Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "


The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.


FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].


I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.


In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.








Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223



twitter: @mmilinkov




Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.


_______________________________________________ Spdx mailing list Spdx@...

Join { to automatically receive all group messages.