Re: License List v1.2 wiki page created

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
Direct:  (512) 340-1336
Mobile: (408) 499 6850

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peter Williams
Sent: Thursday, November 04, 2010 9:39 PM
To: spdx@...
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.


* 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.


Peter Williams
Spdx mailing list

This message has been scanned for viruses by MailController -

Join { to automatically receive all group messages.