Date   

VS: GPL vX or later issue

Martin von Willebrand
 

-
>> Which is only true at that moment of time. If/when GPLv4 is available,
>> you would miss that one. So it's important to keep the fact that the
>> author stated that it's GPLv2+ to cover this.
>> So it's not simply OR. It's OR with potential licenses that do not
>> exist.
>
>Yeah, it does have the issue that the members of the set change over
>time.  However, at any particular moment in time (i.e. any time you are
>doing anything with an SPDX file) it can be treat as a simple
>disjunctive set (all the members are known).
>
>> Making it IMHO a beast in itself.
>
>I agree.  It seems to me that this "or later version" scenario is
>something that should be handled explicitly.  Shoehorning it into the
>license model feels clumsy.

(I am restarting participation after a longer pause.)

Was the question on license attachment clauses decided in the teleconf last week? Are different attachment clauses classified as licenses for the time being or will SPDX be added with separate taxonomy for explaining different license attachments?

Looking at the spec, it is currently unclear for me how one should report a file (or package) with a license attachment clause allowing choosing between GPLv2, any later GPL version, MPL 1.1 or any later MPL version. This needs to be treated somehow, and preferably captured so that this information needs not to be rechecked (unless for quality control).

Is there a "declared license" in a package, if there is just the text of the license in a separate file, with no license attachment statements? Based on the spec, I assume yes, but the text in the spec is a little vague.

Also, the wiki on license texts currently holds placeholders for a number of "license+exception" licenses. What is the standing on this, should these be elaborated to contain the text of the exception so that misunderstandings are less likely?

Br,
Martin

PS. Some other comments on the standard:

1. Licenses detected information under section 3 of the standard seems to be something that repeats parts of information from section 5 of the standard. (With the exception that non-standard licenses are introduced with the help of section 3.)

2. I'm wondering how could the "license tree" of a package be better reflected in the standard. (It can be derived form sec 5. Perhaps that's enough.) E.g. We use a conclusion that a license.txt file containing e.g. LGPL 2.1 license text is concluded to apply to all files in that folder and subfolder, if the files do not contain any license attachment statements and there is no contradicting information. I believe others need to address the same question since files with no license information is a very frequent issue. Viewing licenses as a tree helps in this analysis. Recording licenses detected under section 3 with path information would actually mean even more repeating of information, thus not good. On the other hand, sec 5 is not well suited for information analysis, but for information storage. Hmmm...

PPS. Generic update: what is the timetable for the standard? What type of changes are anticipated or considered prior to release of version 1.0? What goes to future versions?


Martin von Willebrand, Attorney-at-law, Partner
HH Partners, Attorneys-at-law Ltd
Mannerheimintie 14 A
P.O. Box 232, 00101 Helsinki, Finland
Tel: +358 9 177 613, Fax: +358 9 653 873
GSM: +358 40 770 1818
martin.vonwillebrand@...
www.twitter.com/mvonwillebrand
www.hhpartners.fi
Validos ry, Chairman, www.validos.org
Have you checked our renewed web pages, at www.hhpartners.fi?
Privileged and confidential information may be contained in this message. If you are not addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, kindly notify us by reply e-mail and delete this message immediately. Thank you.


Re: GPLv3 Variants

Tom Incorvia
 

Hi Mark,

 

I agree that there could be many variants.  Since we will not be able to interpret the additional terms in any clean fashion (including a certainty that an included term is or is not a “further restriction” that may be removed), I suggest that:

 

1.       We leave GPL v3 with additions out of the Rev-1 license list

2.       In the event that we find a very frequently used GPL V3 with additions, perhaps we name it uniquely, for instance “GPL V3 Modified by [Organization] for [Component]. 

 

My logic on (1) initially leaving out and (2) naming uniquely when we must, is based on never having seen a GPL v3 with permitted additions.  I do, however, travel in the commercial world – perhaps it is different in open source centric environment – is anyone aware of frequently used GPL v3 with permitted additions so we can consider this approach with a bit more data?

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Radcliffe, Mark
Sent: Sunday, November 14, 2010 2:58 PM
To: spdx@...
Subject: GPLv3 Variants

 

I think that we need to take into account the fact that GPLv3 permits six "additional terms" (see below). Since they you could have many variants, perhaps the best approach is to have a category for "GPLv3 with Permitted Additions". I am open to other suggestions.

 

7. Additional Terms.

“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

  • a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
  • b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
  • c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
  • d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
  • e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
  • f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

Please consider the environment before printing this email.

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.

 

 

Click here to report this email as spam.

This message has been scanned for viruses by MailController.


GPLv3 Variants

Mark Radcliffe
 

I think that we need to take into account the fact that GPLv3 permits six "additional terms" (see below). Since they you could have many variants, perhaps the best approach is to have a category for "GPLv3 with Permitted Additions". I am open to other suggestions.
 

7. Additional Terms.

“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

  • a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
  • b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
  • c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
  • d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
  • e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
  • f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

Please consider the environment before printing this email.


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.


Re: License List spreadsheet v1.1

Tom Incorvia
 

Originally sent 2010-Oct-21.  For discussion at today’s License Review Meeting, agenda item, “Python Licenses”.  Tom

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Tom Incorvia
Sent: Thursday, October 21, 2010 9:51 AM
To: Tom "spot" Callaway
Cc: Jilayne Lovejoy; spdx@...; kate.stewart@...
Subject: RE: License List spreadsheet v1.1

 

FYI, I did a compare of Python 3.2 LICENSE to the much earlier 2.0.1 AFTER removing the history information – so the compare started with the statement “TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON”. 

 

The licenses are the same other than adding to the list of copyright years and changing the title “CWI PERMISSIONS STATEMENT AND DISCLAIMER” TO “CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2”.  I have attached the compare.

 

I also noticed that the license link for particular versions of the Python software don’t always match.  For instance the link http://www.python.org/download/releases/2.4.6/license/ links to a license titled 2.4.4 license.  Similarly the URL for 3.0.1 points to a license titled 2.6.1.  There are others.

 

Between versions 2.4.4 and 2.5 “Version 2” is added to the license.  But the changes continue to be limited to extensions of the copyright years.

 

I believe that the discrete licenses are:

 

-          CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2

-          CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1

-          Python Version 1 (Covers Python after 1.6.1 and prior to 2.5)

-          Python Version 2 (Covers Python 2.5 and after)

 

 

Thanks,

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850


Agenda for License Review Meeting

Kim Weins
 

GPL “or later” issue
-
        is there consensus on list around leaving as is in terms of listing “GPL v2 only” separately from “GPL v2 or later” with differentiation showing in header text and then links to all “or later” license texts ??
 
GPL & LGPL exceptions
-
        seems like there is general agreement that each exception should be listed as a separate license on the list
-
        need help generating a list of the commonly used exceptions and how they are named with some kind of consistency in naming
 
Python licenses
-
        currently we have just the two OSI approved licenses, using the OSI long titles for the licenses – Tom I found some other versions, but the naming is a bit inconsistent (in terms of what they are referred to in the field, Tom’s email included some practical clarification on this in terms of matching the license to the software version)
-
        do we need to add others?  If so, which ones and how to name?
 
older license versions that are missing:
-
        we don’t have EUPL v1.0, MPL v1.0, NPL v1.0, other OSL versions, AFL, etc.
 
 
license-specific issues:
-
        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 <http://www.libpng.org/pub/png/src/libpng-LICENSE.txt>
 
 


Re: Reminder: SPDX License Review Meeting Friday - Time 11-12 ET

Kim Weins
 

Hi guys, for some reason mywhen I sent the reminder from my calendar, it
didn't show time zone. The meeting is 11ET, 9MT, 8PT, etc

Kim


On Thu 11/11/10 9:13 AM, "Kim Weins" <kim.weins@...> wrote:

Reminder -- for people that want to attend

------ Original Appointment

From: kim.weins@...

When: 9:00 AM - 10:00 AM November 12, 2010
Subject: License Review Meeting
Location: Dial in below

We will review the license list and address issues.


US 866-740-1260
Int'l http://www.readytalk.com/support/international-numbers.php

ID 2404502

Web Meeting
Www.readytalk.com
ID 2404502

------ End Of Original Appointment


_______________________________________________
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


Reminder: SPDX License Review Meeting Friday

Kim Weins
 

Reminder -- for people that want to attend

------ Original Appointment

From: kim.weins@...

When: 9:00 AM - 10:00 AM November 12, 2010
Subject: License Review Meeting
Location: Dial in below

We will review the license list and address issues.


US 866-740-1260
Int'l http://www.readytalk.com/support/international-numbers.php

ID 2404502

Web Meeting
Www.readytalk.com
ID 2404502

------ End Of Original Appointment


Re: GPL vX or later issue

dmg
 

On Tue, Nov 9, 2010 at 10:08 PM, Don Armstrong <don@...> wrote:
n Tue, 09 Nov 2010, dmg wrote:
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".
No, it's not. GPLv3 and v2 conflict with each other, so a license
which is the conjunction of both v2 and v3 is nonsensical. There's a
reason why the full language of the recommended licensing clause for
GPL'ed works is
you are misreading my clause. When I say "any newer version" it
means I give you the choice to use any newer version.
Just that. The license is the concatenation of the GPL license plus
this statement.

--dmg


--
--dmg

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


Re: GPL vX or later issue

Peter Williams <peter.williams@...>
 

On 11/10/10 1:47 AM, Bruno Cornec wrote:
Jilayne Lovejoy said on Tue, Nov 09, 2010 at 07:53:12PM -0700:

a. Code is licensed under GPL v2 or later - this essentially
creates a licensing choice of GPL v2 OR GPL v3
Which is only true at that moment of time. If/when GPLv4 is available,
you would miss that one. So it's important to keep the fact that the
author stated that it's GPLv2+ to cover this.
So it's not simply OR. It's OR with potential licenses that do not
exist.
Yeah, it does have the issue that the members of the set change over time. However, at any particular moment in time (i.e. any time you are doing anything with an SPDX file) it can be treat as a simple disjunctive set (all the members are known).

Making it IMHO a beast in itself.
I agree. It seems to me that this "or later version" scenario is something that should be handled explicitly. Shoehorning it into the license model feels clumsy.

Peter


Re: GPL vX or later issue

Bruno Cornec <Bruno.Cornec@...>
 

Jilayne Lovejoy said on Tue, Nov 09, 2010 at 07:53:12PM -0700:

a. Code is licensed under GPL v2 or later - this essentially
creates a licensing choice of GPL v2 OR GPL v3
Which is only true at that moment of time. If/when GPLv4 is available,
you would miss that one. So it's important to keep the fact that the
author stated that it's GPLv2+ to cover this.
So it's not simply OR. It's OR with potential licenses that do not
exist. Making it IMHO a beast in itself.

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

Don Armstrong
 

On Tue, 09 Nov 2010, dmg wrote:
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".
No, it's not. GPLv3 and v2 conflict with each other, so a license
which is the conjunction of both v2 and v3 is nonsensical. There's a
reason why the full language of the recommended licensing clause for
GPL'ed works is

This program is free software: you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.

not

[...] and any later version.

The use of GPLv2+ and similar terms is just a shorthand to indicate
that you can use the work under one of GPLv2 or GPLv3 (and some later
version of the GPL when/if it comes out).

This is an entirely separate situation from a codebase which forms a
derivative work which has some code under GPLv2 and other code under
GPLv3. [Such a derivative work is generally considered to be
undistributable, because the terms of GPLv2 (§6 and §7) cannot be
satisfied.]


Don Armstrong

--
For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
-- Douglas Adams

http://www.donarmstrong.com http://rzlab.ucr.edu


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


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

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

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

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

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

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

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

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

1401 - 1420 of 1591