toggle quoted message
Show quoted text
(I have included the legal list on this response)
This has been discussed a couple times and part of this issue is listed as
a "to-do" on the legal page
namely making sure the license list has capture all the common exceptions
to begin with.
The concept of having a base license with additive options was discussed
(I can't seem to find it in the meeting minutes, but I only looked briefly
at this year and it may even have been before that or touched upon
tangentially) If memory serves, it wasn't a matter of consensus that this
was a bad idea, but there has yet to be a fully thought-out proposal
submitted for thorough consideration. So, if you have an idea as to how
to implement this idea, while keeping in mind the overall goal of the
LIcense List, etc. - that would be great!!
Maybe someone else from the legal team can also weigh in here regarding
the previous discussions on this topic.
On 6/22/12 12:10 PM, "Peter Bigot" <bigotp@...> wrote:
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.
On Fri, Jun 22, 2012 at 12:48 PM, Philip Odence
I sometimes skirt the issue by broadly referring "software that is_______________________________________________
available on the web."
When one is talking about new projects, picking licenses, and the like,
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
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.
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
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
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
better. I think when we get comfortable with our understanding of the
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@...>,
Subject: RE: "Scope" of licenses to be covered by SPDX
Re: " Out of this topic we just discussed (in my understanding) what
be a proper definition of ³FOSS². "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI)
the two organizations which, in my opinion, define what FOSS is. Any
to define FOSS which do not take into account the collective wisdom and
process that went into their respective license lists  would be a
FOSS = Free and Open Source Software, which is the union of software
meets the definition of Free Software and Open Source Software.
I have seen attempts in the past to expand the definition of FOSS beyond
licensing to include other parameters such as open development
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
Foundation, I am also a Director of the OSI.
Eclipse Foundation, Inc.
Office: +1.613.224.9461 x228
Out of this topic we just discussed (in my understanding) what could be
proper definition of ³FOSS².
_______________________________________________ Spdx mailing list
Spdx mailing list
Spdx mailing list