Date   

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

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


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


Re: License List v1.2 wiki page created

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


Minutes from 11/4 call

Philip Odence
 

They are now up on the website.
L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502


Re: GPL + exceptions issue

Jilayne Lovejoy <Jlovejoy@...>
 

So, for purposes of the license list - am I to add a new line item for
each GPL + exception?

If so, does anyone want to help me generate a list of the various
commonly used exceptions with some attention to how they are named? The
exceptions tend to be associated with a specific project, but the text
of the exception has to do with what is being excepted from the GPL
copyleft license requirement. For the purposes of matching the correct
exception to what's found in an actual file - both pieces of information
(name and substance of exception) can be useful... Does anyone have any
thought on how to handle this in terms of the actual list?

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of Peter Williams
Sent: Friday, November 05, 2010 9:25 AM
To: spdx@...
Subject: Re: License List v1.2 wiki page created

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

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


Re: GPL vX or later issue

Jilayne Lovejoy <Jlovejoy@...>
 

I would agree with Peter's assessment below. To be clear, my
interpretation of this would be that this would remove the various "or
later" instances from the actual license list and then that option would
be handled elsewhere.

Does anyone else have any thoughts on this?

This is an easy update to make and I was hoping to upload a new license
list version with various updates this week, just prior to Friday's
license meeting.

Jilayne

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


Re: GPL + exceptions issue

dmg
 

The list will grow n^2 to the number of GPL licenses. Why not consider
the exception as a conjunction of two licenses for the purpose of the
spec? One the GPL, and the other the exception. This will also help to
simplify new exceptions as they appear.

--dmg

On Tue, Nov 9, 2010 at 10:13 AM, Jilayne Lovejoy <Jlovejoy@...> wrote:
So, for purposes of the license list - am I to add a new line item for
each GPL + exception?

If so, does anyone want to help me generate a list of the various
commonly used exceptions with some attention to how they are named?  The
exceptions tend to be associated with a specific project, but the text
of the exception has to do with what is being excepted from the GPL
copyleft  license requirement.  For the purposes of matching the correct
exception to what's found in an actual file - both pieces of information
(name and substance of exception) can be useful... Does anyone have any
thought on how to handle this in terms of the actual list?

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of Peter Williams
Sent: Friday, November 05, 2010 9:25 AM
To: spdx@...
Subject: Re: License List v1.2 wiki page created

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

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

--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: GPL vX or later issue

dmg
 

This again, could be handled as a conjunction of the license plus the
clause that allows the upgrade.

Licenses for a given file: GPLv2 _AND_ Any_NEWER_VERSION or something like thatl

--dmg

On Tue, Nov 9, 2010 at 10:16 AM, Jilayne Lovejoy <Jlovejoy@...> wrote:

I would agree with Peter's assessment below.  To be clear, my
interpretation of this would be that this would remove the various "or
later" instances from the actual license list and then that option would
be handled elsewhere.

Does anyone else have any thoughts on this?

This is an easy update to make and I was hoping to upload a new license
list version with various updates this week, just prior to Friday's
license meeting.

Jilayne

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

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

--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: GPL vX or later issue

Mark Radcliffe
 

I think that this approach will create confusion. First, I estimate that 99.9% of all GPL licenses are version or later, so most users of SPDX will assume that GPLv2 is GPLv2 or later. Unless we can make this very clear, it will be very confusing. I am open to other ways of solving this problem. Second, I think that this distinction is very important now and will increase in importance as GPLv3 becomes more important and some GPLv2 and later programs are forked to GPLv3.

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Tuesday, November 09, 2010 10:17 AM
To: Peter Williams; spdx@...
Subject: RE: GPL vX or later issue


I would agree with Peter's assessment below. To be clear, my
interpretation of this would be that this would remove the various "or
later" instances from the actual license list and then that option would
be handled elsewhere.

Does anyone else have any thoughts on this?

This is an easy update to make and I was hoping to upload a new license
list version with various updates this week, just prior to Friday's
license meeting.

Jilayne

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

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
</PRE><font face="Arial" size="2" color="#008000">Please consider the environment before printing this email.</font>
<br>
<br>
<font face="Verdana" size="1" color="#808080">
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.


<br>
</font><PRE>


Re: GPL + exceptions issue

Tom Incorvia
 

Hi DMG,

I was off traveling a bit, so if I may have missed some interim conversations -- hopefully I am addressing the same topic that you are. I don't see how the conjunction of 2 licenses will work with our model -- we track "a license". I thought that we had previously agreed that the licenses would be distinct (resulting in, say, "GPL 2.0 with Classpath Exception" as a single license). I am in the commercial world, and we need to treat the License + exception as a distinct "agreement".

Thanks,

Tom

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

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of dmg
Sent: Tuesday, November 09, 2010 12:25 PM
To: Jilayne Lovejoy
Cc: spdx@...
Subject: Re: GPL + exceptions issue

The list will grow n^2 to the number of GPL licenses. Why not consider
the exception as a conjunction of two licenses for the purpose of the
spec? One the GPL, and the other the exception. This will also help to
simplify new exceptions as they appear.

--dmg

On Tue, Nov 9, 2010 at 10:13 AM, Jilayne Lovejoy <Jlovejoy@...> wrote:
So, for purposes of the license list - am I to add a new line item for
each GPL + exception?

If so, does anyone want to help me generate a list of the various
commonly used exceptions with some attention to how they are named?  The
exceptions tend to be associated with a specific project, but the text
of the exception has to do with what is being excepted from the GPL
copyleft  license requirement.  For the purposes of matching the correct
exception to what's found in an actual file - both pieces of information
(name and substance of exception) can be useful... Does anyone have any
thought on how to handle this in terms of the actual list?

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of Peter Williams
Sent: Friday, November 05, 2010 9:25 AM
To: spdx@...
Subject: Re: License List v1.2 wiki page created

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

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



--
--dmg

---
Daniel M. German
http://turingmachine.org
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


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


Re: GPL vX or later issue

Michael J Herzog <mjherzog@...>
 

I strongly agree that we need to clearly distinguish between "GPL v2" and "GPL v2 or Later" and that both should be in the primary license list, although we may also want to keep more precise semantics about versions in the background. I suppose that this case could be construed as a type of Dual License such as "MPL 1.1 or LGPL 2.1" - e.g. "GPL v2 or GPL Later".

Regards, Michael

Michael J. Herzog
+1 650 380 0680 | mjherzog_at_nexB.com
nexB [Open by Design] http://www.nexb.com

CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.

On 11/9/2010 10:28 AM, Radcliffe, Mark wrote:
I think that this approach will create confusion. First, I estimate that 99.9% of all GPL licenses are version or later, so most users of SPDX will assume that GPLv2 is GPLv2 or later. Unless we can make this very clear, it will be very confusing. I am open to other ways of solving this problem. Second, I think that this distinction is very important now and will increase in importance as GPLv3 becomes more important and some GPLv2 and later programs are forked to GPLv3.

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Tuesday, November 09, 2010 10:17 AM
To: Peter Williams; spdx@...
Subject: RE: GPL vX or later issue


I would agree with Peter's assessment below. To be clear, my
interpretation of this would be that this would remove the various "or
later" instances from the actual license list and then that option would
be handled elsewhere.

Does anyone else have any thoughts on this?

This is an easy update to make and I was hoping to upload a new license
list version with various updates this week, just prior to Friday's
license meeting.

Jilayne

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

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
</PRE><font face="Arial" size="2" color="#008000">Please consider the environment before printing this email.</font>
<br>
<br>
<font face="Verdana" size="1" color="#808080">
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.


<br>
</font><PRE>

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


Re: GPL vX or later issue

Peter Williams <peter.williams@...>
 

On 11/9/10 11:28 AM, Radcliffe, Mark wrote:
I think that this approach will create confusion. First, I estimate that 99.9% of all GPL licenses are version or later, so most users of SPDX will assume that GPLv2 is GPLv2 or later.
I think we have a slight mis-match it terms. There is not even one GPL license that is "version or later". Each version of GPL is that version, and no other version, of GPL. "

A lot of content is licensed under some version of GPL or any later version. IOW, a lot of content is licensed under GPLv2 or GPLv3 (or GPLv4 or 5 should such licenses ever be created). In the "or later version" scenario the user get to choose which of those licenses they prefer.

Unless we can make this very clear, it will be very confusing. I am open to other ways of solving this problem.
We definitely need to make it clear what licenses are in play. But we also need to be precise. Conflating the relationship between a file and it's licenses with the licenses themselves reduces both clarity and precision.

I think having an "version or later" license set is best way to handle this. Perhaps we could predefine some common "version or later" license sets (such as GPv2OrLater) to improve the simplicity and clarity.

Peter


Re: GPL vX or later issue

dmg
 

On Tue, Nov 9, 2010 at 10:54 AM, Michael J Herzog <mjherzog@...> wrote:
I strongly agree that we need to clearly distinguish between "GPL v2" and
"GPL v2 or Later" and that both should be in the primary license list,
although we may also want to keep more precise semantics about versions in
the background.   I suppose that this case could be construed as a type of
Dual License such as "MPL 1.1 or LGPL 2.1" - e.g. "GPL v2 or GPL Later".
Don't confuse a conjunction of terms with a disjunction. GPLv2 and
"ANY later version" is a conjunction of
licensing terms, while 'MPL1.1 or LGPL 2.1' is a disjunction.


--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: GPL vX or later issue

Peter Williams <peter.williams@...>
 

On 11/9/10 11:54 AM, Michael J Herzog wrote:
I suppose that this case could be construed
as a type of Dual License such as "MPL 1.1 or LGPL 2.1" - e.g. "GPL v2
or GPL Later".
Exactly. However, i don't think this requires construing. The two seem very much the same to me.

Peter Williams
www.openlogic.com


Re: GPL vX or later issue

Richard Fontana
 

On Tue, Nov 09, 2010 at 12:10:13PM -0800, dmg wrote:
Don't confuse a conjunction of terms with a disjunction. GPLv2 and
"ANY later version" is a conjunction of
licensing terms, while 'MPL1.1 or LGPL 2.1' is a disjunction.
<delurking>

Actually, it is not inherently clear whether "GPLv2 or any later
version" licensing is meant to be conjunctive or disjunctive, but it
is my sense that the majority view in the open source developer
community is that it is disjunctive. By that I mean, if I get some
"GPLv2 or later" code, I can redistribute it under "GPLv2 or later"
(which is what is done 99% of the time), or (by revising the license
notices) "GPLv2 only", or (by revising the license notices) "GPLv3
only" [or "GPLv3 or later"]).

As a historical example, in ~2006 active developers of BusyBox acted
on the assumption that "GPLv2 or later" was disjunctive, and made some
effort to alter license notices to say "GPLv2 only". Bruce Perens, one
of the early developers of BusyBox, objected to this, arguing that
GPLv2, in requiring preservation of license notices, prevents the
removal of the "or later" choice. See:
http://lwn.net/Articles/367058/

The FSF's position is that "GPLv2 or later" is disjunctive, precisely
like a "MPL 1.1 or LGPL 2.1" dual license, and there was some effort
in GPLv3 to clarify that.

- RF


Re: GPL vX or later issue

dmg
 

I should be more explicit.

I think we are combining two issues into one and that yields some confusion.

Let us assume "GPLv2 or any newer version"

From a practical interpretation point of view, the user is allowed to
choose one license or another, and it is not different than any other
disjunction.

But from a modeling point of view, I see the statement "any newer
version of the license" as a licensing statement
that gets conjuncted to the GPL. In other words, the license is the
concatenation of the clauses of the GPL plus the "any newer version of
the license".

gplv2+ => (GPL and "the relicense with any newer license")

The trilicense, in the other hand, is:

(MPL1.1 or GPL v2+ or LGPL v2.1+) and (the ability to drop any two
licenses from the file--relicense)

I know it does not sound practical, but one one has to logical
assertions on the licenses, it makes senses.

--dmg

On Tue, Nov 9, 2010 at 12:10 PM, dmg <dmg@...> wrote:
On Tue, Nov 9, 2010 at 10:54 AM, Michael J Herzog <mjherzog@...> wrote:
I strongly agree that we need to clearly distinguish between "GPL v2" and
"GPL v2 or Later" and that both should be in the primary license list,
although we may also want to keep more precise semantics about versions in
the background.   I suppose that this case could be construed as a type of
Dual License such as "MPL 1.1 or LGPL 2.1" - e.g. "GPL v2 or GPL Later".
Don't confuse a conjunction of terms with a disjunction. GPLv2 and
"ANY later version" is a conjunction of
licensing terms, while 'MPL1.1 or LGPL 2.1' is a disjunction.


--
--dmg

---
Daniel M. German
http://turingmachine.org
--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: GPL vX or later issue

Kim Weins
 

I think that we need to treat the v2 and later as a separate license in the
list. Although it would be nice from a purely technical point of view to
factor that into a conjunction or disjunction of two licenses, it is clear
just from the opinions on this list that doing so may cause some loss in
fidelity. Given the many differing opinions here, it seems leaving it as a
separate license would be the most conservative approach.

I also can't see any significant downside to making the "and later" as
different licenses except a very slight amount of overhead in having a
couple more licenses in the list.

Kim


On Tue 11/9/10 1:22 PM, "Richard Fontana" <rfontana@...> wrote:

On Tue, Nov 09, 2010 at 12:10:13PM -0800, dmg wrote:
Don't confuse a conjunction of terms with a disjunction. GPLv2 and
"ANY later version" is a conjunction of
licensing terms, while 'MPL1.1 or LGPL 2.1' is a disjunction.
<delurking>

Actually, it is not inherently clear whether "GPLv2 or any later
version" licensing is meant to be conjunctive or disjunctive, but it
is my sense that the majority view in the open source developer
community is that it is disjunctive. By that I mean, if I get some
"GPLv2 or later" code, I can redistribute it under "GPLv2 or later"
(which is what is done 99% of the time), or (by revising the license
notices) "GPLv2 only", or (by revising the license notices) "GPLv3
only" [or "GPLv3 or later"]).

As a historical example, in ~2006 active developers of BusyBox acted
on the assumption that "GPLv2 or later" was disjunctive, and made some
effort to alter license notices to say "GPLv2 only". Bruce Perens, one
of the early developers of BusyBox, objected to this, arguing that
GPLv2, in requiring preservation of license notices, prevents the
removal of the "or later" choice. See:
http://lwn.net/Articles/367058/

The FSF's position is that "GPLv2 or later" is disjunctive, precisely
like a "MPL 1.1 or LGPL 2.1" dual license, and there was some effort
in GPLv3 to clarify that.

- RF


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

Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic

650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic

OpenLogic, Inc.
Headquarters, Broomfield, Colorado


Re: GPL vX or later issue

Peter Williams <peter.williams@...>
 

On 11/9/10 2:57 PM, Kim Weins wrote:
I think that we need to treat the v2 and later as a separate license in the
list. Although it would be nice from a purely technical point of view to
factor that into a conjunction or disjunction of two licenses, it is clear
just from the opinions on this list that doing so may cause some loss in
fidelity. Given the many differing opinions here, it seems leaving it as a
separate license would be the most conservative approach.

I also can't see any significant downside to making the "and later" as
different licenses except a very slight amount of overhead in having a
couple more licenses in the list.
If we did have a "GPLv2OrLaterVersion" license what would its license text be?

Peter
www.openlogic.com


Re: GPL vX or later issue

Bruno Cornec <Bruno.Cornec@...>
 

Peter Williams said on Tue, Nov 09, 2010 at 12:25:40PM -0700:
I think having an "version or later" license set is best way to
handle this. Perhaps we could predefine some common "version or
later" license sets (such as GPv2OrLater) to improve the simplicity
and clarity.
I think we should not re-invent the wheel here. In .spec files for RPMs
packages, there is already tags for GPLv2 and GPLv2+. Why not indeed
reuse that approach ?

Bruno.
--
Open Source & Linux Profession Lead EMEA / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net
http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org


Re: GPL vX or later issue

Bruno Cornec <Bruno.Cornec@...>
 

Radcliffe, Mark said on Tue, Nov 09, 2010 at 10:28:17AM -0800:

I think that this approach will create confusion. First, I estimate that 99.9% of all GPL licenses are version or later, so most users of SPDX will assume that GPLv2 is GPLv2 or later. Unless we can make this very clear, it will be very confusing. I am open to other ways of solving this problem. Second, I think that this distinction is very important now and will increase in importance as GPLv3 becomes more important and some GPLv2 and later programs are forked to GPLv3.
I can confirm I'm the maintainer of a project which is mostly GPLv2 (and
not or later). So that does exist and should be differentiated (Linux is
a more famous example ;-)

Bruno.
--
Open Source & Linux Profession Lead EMEA / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net
http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org


Re: GPL vX or later issue

Jilayne Lovejoy <Jlovejoy@...>
 


Hi All,

I think I created a bit of a mess with what was intended to be a simple question, but sort of opened a can or worms!  Let me try to re-center a bit, if possible…

I think it can be said that everyone agrees that there must be a clear way to capture the difference between code that is licensed under GPL v2 and code that is licensed under GPL v2 or later (for example).  The former situation is a straight forward, single license situation, whereas the latter provide a choice of licenses, the choice being among various versions of the GPL license.

I started out by asking how, if at all, this difference should be reflected on the actual license list.  However, the subsequent discussion seems to illustrate that we must first determine how to capture this in the SPDX file, which will then dictate what is listed on the actual license list.  From a broader perspective, we need to decide how SPDX will accurately capture any licensing situation that involves multiple licenses.  Perhaps the answer to this question is really more aptly left up to the technical team.

To be clear, I think we have identified two different multiple licensing situations:

1)      Where the licensee has a choice.  This is sometimes referred to as disjunctive licensing and creates an “OR” situation, in that the code is licensed under one of the choices, but not multiple licenses.  Examples of this include:

a.      Code is licensed under GPL v2 or later – this essentially creates a licensing choice of GPL v2 OR GPL v3
b.      Code is licensed under MPL/GPL/LGPL – this creates a licensing choice of one of the three licenses (or if the GPL and LGPL options indicate “or later,” then the choice would be among 5 different licenses)

i.      In either situation, this information is usually indicated in the header, but the actual license text itself remains the same.  In other words, there is no MPL/GPL/LGPL license but only these individual licenses and a way to indicate the choice of one of them. 

ii.     GPL v2 or later creates the same scenario in that there is a licensing choice.  In this case, the individual licenses are GPL v2, GPL v3 (and perhaps one day, GPL v4, etc.)

iii.    There is potentially the further distinction of where there is a default license if no “choice” is affirmatively identified, but in this case as well, each license remains an individual license.

2)      Where multiple licenses cover the same code.  This is sometimes referred to as dual (or tri, etc.) licensing and creates an “AND” situation.  For example:

a.      Code is licensed under Apache and BSD.  In this case, there is no choice; the licensee must comply with both licenses for that code.

(if there is another licensing scenario that involves more than one license (or license version) or anything else I missed here, please add)

This then begs the question of not only how will an SPDX file denote multiple licenses, but also how it differentiates between the above two scenarios (OR, AND)?

Once this has been determined (probably by the more technical folks in the group), I presume the license list protocol will follow.   

Sorry for not realizing this proper order of events!  In the meantime, I’ll leave the license list as is as regards to those licenses.

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


-----Original Message-----
From: Bruno Cornec [mailto:Bruno.Cornec@...]
Sent: Tuesday, November 09, 2010 4:34 PM
To: Radcliffe, Mark
Cc: Jilayne Lovejoy; Peter Williams; spdx@...
Subject: Re: GPL vX or later issue

Radcliffe, Mark said on Tue, Nov 09, 2010 at 10:28:17AM -0800:

> I think that this approach will create confusion. First, I estimate that 99.9% of all GPL licenses are version or later, so most users of SPDX will assume that GPLv2 is GPLv2 or later. Unless we can make this very clear, it will be very confusing. I am open to other ways of solving this problem. Second, I think that this distinction is very important now and will increase in importance as GPLv3 becomes more important and some GPLv2 and later programs are forked to GPLv3.

I can confirm I'm the maintainer of a project which is mostly GPLv2 (and

not or later). So that does exist and should be differentiated (Linux is

a more famous example ;-)

Bruno.

--

Open Source & Linux Profession Lead EMEA           / http://opensource.hp.com

HP/Intel/Red Hat Open Source Solutions Initiative  / http://www.hpintelco.net

http://www.HyPer-Linux.org  http://mondorescue.org http://project-builder.org

La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

161 - 180 of 1591