With respect to the license list, an issue I happened to notice this
morning is that items on it appear to reflect a very flat concept of a
license when there are options, e.g. GPL-2.0-with-GCC-exception and
GPL-2.0+. The problem is that this approach limits the succinct
representation of licenses. For example, if a package (e.g., libgcc)
is GPL 2.0 or later version with runtime exception, there is no
GPL-2.0+-with-GCC-exception. If a package also incorporates the GPL
classpath exception, that isn't listed either. It's not obvious that
this can be fixed by disjunction or conjunction of the listed licenses
(wouldn't GPL-2.0+ AND GPL-2.0-with-GCC-exception be simple GPL-2.0?)

In a future revision, perhaps the concept of a base license with a set
of options (GPL-2.0, option for later revision, exception for runtime
library, exception for classpath) would be more expressive. It could
also cut down on the size of the list.

Peter

On Fri, Jun 22, 2012 at 12:48 PM, Philip Odence
<podence@...> wrote:

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.



[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd





Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov







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



_______________________________________________ Spdx mailing list
Spdx@... https://lists.spdx.org/mailman/listinfo/spdx

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx