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


Jilayne Lovejoy <jilayne.lovejoy@...>
 

(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
(http://spdx.org/wiki/legal-team-current-issues-last-updated-june-27),
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.

- Jilayne

On 6/22/12 12:10 PM, "Peter Bigot" <bigotp@acm.org> 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.

Peter

On Fri, Jun 22, 2012 at 12:48 PM, Philip Odence
<podence@blackducksoftware.com> 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@eclipse.org>
Organization: Eclipse Foundation
Reply-To: Mike Milinkovich <mike.milinkovich@eclipse.org>
Date: Fri, 22 Jun 2012 13:24:42 -0400
To: <Soeren_Rabenstein@asus.com>, Michel Ruffin
<Michel.Ruffin@alcatel-lucent.com>, Michael Herzog <mjherzog@nexb.com>,
<spdx@lists.spdx.org>
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@eclipse.org

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@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx

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

Join spdx@lists.spdx.org to automatically receive all group messages.