License List v1.2 wiki page created


Jilayne Lovejoy <Jlovejoy@...>
 

Hi,

 

Okay, I uploaded the v1.2 spreadsheet and accompanying guidelines in a word doc as attachments to a new Wiki page here:  http://www.spdx.org/wiki/license-list-v12

 

Disregard my previous email this morning, as I did make a couple minor updates to the uploaded version (but did not rename).

 

Here are is the list particular things that need some form of resolution:

 

Outstanding Issues/Questions:

  • How exactly are we handling all the GPL/LGPL exceptions?
  • How do we want to handle LGPL/GPL “vXor later” versus LGPL/GPL vX?
  • Older versions – we don’t have Apache 1.1, EUPL v1.0, MPL v1.0, NPL v1.0, other OSL versions, AFL, etc.
    • Added Apache 1.1 as that is often still seen, but what about others?
  • See email Vol1, Issue 14 – list of licenses, does not match with this one – add to current?
  • Licenses with an alternative name or an associated project in parenthesis after the name – some of these need a determination and some may be superfluous, perhaps?  Can we come up with a “rule” for this?:
    • See ISC License (Bind, DHCP Server)
    • Lucent Public License v1.02 (Plan9)
    • MIT (also X11)
    • BSD licenses – currently include all naming variations “BSD 3-clause ‘New’ or ‘Revised’ License”  à seems like we should pick one naming protocol and stick with it, maybe putting the others in parenthesis or omitting??
  • X.Net License à this is really an LGPL notice + special exception - should we have it as a separate license?
  • Zlib/libpng License à note: this is the zlib license, but OSI calls it the zlib/libpng license.  Yet there is a different license for libpng:  see http://www.libpng.org/pub/png/src/libpng-LICENSE.txt
    • Why is “with acknowledgments” listed in “Recognized Exceptions” column?

 

 

Cheers,

 

Jilayne Lovejoy  |  Corporate Counsel

jlovejoy@...

 

720 240 4545  |  phone

720 240 4556  |  fax

1 888 OpenLogic  |  toll free

www.openlogic.com

 

OpenLogic, Inc.

Headquarters, Broomfield, Colorado 80021

 


Peter Williams <peter.williams@...>
 

On 11/4/10 11:15 AM, Jilayne Lovejoy wrote:

*Outstanding Issues/Questions:*

* How exactly are we handling all the GPL/LGPL exceptions?
We could just have a separate license for GPL+amendment for all the common exceptions. This fits the current license model pretty well. However, it means that an uncommon set of amendments would require a custom license declaration in SPDX file.

Another approach that might be to have a LicenseAmendment concept and allow a "composite" license to be defined as a base license plus a set of amendments. This feasible but would require a bit of work in the technical working group to nail down the specifics.

* How do we want to handle LGPL/GPL “vXor later” versus LGPL/GPL vX?
I think this should not be handled at license level. There is no such license as "GPL v2 or later". Rather, content is licensed under the disjunctive set of all GPL licenses with a version greater than or equal to 2.

If licenses expressed their version relationships using dc:isVersionOf and dc:replaces we could leverage that information. Using the version relationships we could define a version based disjunctive license set. This set would specify the minimum acceptable version of the license, e.g. GPLv2. A license would be considered to be part of such a set if it "replaces" and "isVersionOf", either directly or indirectly, the minimum acceptable version.

[snip]

* Licenses with an alternative name or an associated project in
parenthesis after the name – some of these need a determination
and some may be superfluous, perhaps? Can we come up with a “rule”
for this?:
o See ISC License (Bind, DHCP Server)
o Lucent Public License v1.02 (Plan9)
o MIT (also X11)
o BSD licenses – currently include all naming variations “BSD
3-clause ‘New’ or ‘Revised’ License” à seems like we should
pick one naming protocol and stick with it, maybe putting
the others in parenthesis or omitting??
We could quite easily support an arbitrary number of name for any particular license. Perhaps that would be easier than trying to settle on just one name for these licenses.

[snip]


Peter Williams
www.openlogic.com


Tom Incorvia
 

Regarding the GPL / LGPL exceptions -- We formerly decided to treat each combination of license + exception as a separate license since the exception can change the terms materially. For instance GPL + Classpath is more permissive than LGPL. From a practical point of view, the exception creates a different license. Tom

Tom Incorvia
tom.incorvia@microfocus.com
Direct:  (512) 340-1336
Mobile: (408) 499 6850

-----Original Message-----
From: spdx-bounces@fossbazaar.org [mailto:spdx-bounces@fossbazaar.org] On Behalf Of Peter Williams
Sent: Thursday, November 04, 2010 9:39 PM
To: spdx@fossbazaar.org
Subject: Re: License List v1.2 wiki page created


On 11/4/10 11:15 AM, Jilayne Lovejoy wrote:

*Outstanding Issues/Questions:*

* How exactly are we handling all the GPL/LGPL exceptions?
We could just have a separate license for GPL+amendment for all the
common exceptions. This fits the current license model pretty well.
However, it means that an uncommon set of amendments would require a
custom license declaration in SPDX file.

Another approach that might be to have a LicenseAmendment concept and
allow a "composite" license to be defined as a base license plus a set
of amendments. This feasible but would require a bit of work in the
technical working group to nail down the specifics.

* How do we want to handle LGPL/GPL "vXor later" versus LGPL/GPL vX?
I think this should not be handled at license level. There is no such
license as "GPL v2 or later". Rather, content is licensed under the
disjunctive set of all GPL licenses with a version greater than or equal
to 2.

If licenses expressed their version relationships using dc:isVersionOf
and dc:replaces we could leverage that information. Using the version
relationships we could define a version based disjunctive license set.
This set would specify the minimum acceptable version of the license,
e.g. GPLv2. A license would be considered to be part of such a set if
it "replaces" and "isVersionOf", either directly or indirectly, the
minimum acceptable version.

[snip]

* Licenses with an alternative name or an associated project in
parenthesis after the name - some of these need a determination
and some may be superfluous, perhaps? Can we come up with a "rule"
for this?:
o See ISC License (Bind, DHCP Server)
o Lucent Public License v1.02 (Plan9)
o MIT (also X11)
o BSD licenses - currently include all naming variations "BSD
3-clause 'New' or 'Revised' License" à seems like we should
pick one naming protocol and stick with it, maybe putting
the others in parenthesis or omitting??
We could quite easily support an arbitrary number of name for any
particular license. Perhaps that would be easier than trying to settle
on just one name for these licenses.

[snip]


Peter Williams
www.openlogic.com
_______________________________________________
Spdx mailing list
Spdx@fossbazaar.org
https://fossbazaar.org/mailman/listinfo/spdx


This message has been scanned for viruses by MailController - www.MailController.altohiway.com


Peter Williams <peter.williams@...>
 

On 11/5/10 5:08 AM, Tom Incorvia wrote:
We formerly decided to treat each combination of license + exception as a separate license since the exception can change the terms materially. For instance GPL + Classpath is more permissive than LGPL. From a practical point of view, the exception creates a different license. Tom
Thanks for pointing that out. That agreement must have been reached before i joined the group. I agree that approach makes the most sense.

We could make the relationship explicit by defining a dc:hasPart property on the license+exception with the value of the original license. This would allow tools to more easily show how various license are related to one another.

Peter Williams
www.openlogic.com