Date   

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

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

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

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

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


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


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


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

 


Re: updated license list

Jilayne Lovejoy <Jlovejoy@...>
 

See comments in ALL CAPS below. I will send an email when the latest
License List and Guidelines document has been uploaded to the Wiki so
everyone can just look at it there.

Jilayne

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of Bruno Cornec
Sent: Thursday, November 04, 2010 9:30 AM
To: Jilayne Lovejoy
Cc: spdx@...
Subject: Re: updated license list

Hello,

Jilayne Lovejoy said on Thu, Nov 04, 2010 at 09:19:54AM -0600:

Here is the next version of the license list (v1.2) that includes the
license text and some other changes discussed via email. I also
updated
the "guidelines" document and listed any changes in this spreadsheet
over License List v1.1 there.
I think there is a problem line 32 of the LicenseList v1.2 file:
Column A mentions version 1.0 wheresas column B says 3.0.
--> FIXED (good eye!)

I wonder if there shouldn't be a mention of the GFDL in this file as
well (with the multiple versions)? (CC are there)
--> GOOD PONT - ADDED FDL v1.2 AS IT IS THE ONE I'VE SEEN USED MOST
OFTEN EVEN THOUGH THERE IS A MORE RECENT VERSION. HOWEVER, THIS SPEAKS
TO ONE OF THE "OUTSTANDING ISSUES" - THAT WE DO NOT HAVE OLDER VERSIONS
OF A BUNCH OF COMMON LICENSES... (SEE NEXT EMAIL)

Speaking of versions, I wonder whether there should'nt always be a
version mentioned, to support easily future revisions of the license not
having multiple version yet.
--> MANY LICENSES ARE ONE-OFFS AND MOST LIKELY WILL NOT HAVE A NEW
VERSION. IF THE LICENSE DOESN'T INCLUDE THIS IN ITS TITLE, I DON'T THINK
WE SHOULD ADD A VERSION NUMBER

For dates, wouldn't it be more interesting (wrt sort, ...) to use the
ISO format: 2010-11-04 instead of the European one, which may be
confusing for non-european people.
--> SO FAR THE DATE IS JUST INCLUDED AS PART OF THE TEXT FIELD FOR
"NOTES" ABOUT THE LICENSE, SO PROBABLY DOESN'T MATTER EITHER WAY BEYOND
WHATEVER IS GOING TO BE EASIEST TO READ. SOME LICENSES ONLY HAVE A
MONTH-YEAR FOR RELEASE DATE INSTEAD OF A FULL DATE IN CASE THAT'S A
CONSIDERATION

HTH,
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
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


Python licenses

Jilayne Lovejoy <Jlovejoy@...>
 

I agree these licenses are a bit redundant seeming and not well differentiated.  However, I think when a license has been approved by the OSI, we need to just stick with the license name they use.  Although Tom’s list here is better than what we see “in the field,” I don’t think we should include which versions of the software the license covers (not sure if that is what you were suggesting, anyway).  

 

I have updated the License List (from this morning) to have the two python OSI-approved licenses and checked that the license name listed matches the name OSI uses.  If someone thinks the other iterations need to be added, let me know.  

 

Jilayne

 


From: Tom Incorvia [mailto:tom.incorvia@...]
Sent: Thursday, October 21, 2010 8:51 AM
To: Tom "spot" Callaway
Cc: Jilayne Lovejoy; kate.stewart@...; spdx@...
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)

 

Tom W, what do you think – some of the specificity in versions and release is removed as the licenses get newer.  I have not looked for language re self-superseding.

 

Thanks,

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

 

-----Original Message-----
From: Tom "spot" Callaway [mailto:tcallawa@...]
Sent: Wednesday, October 20, 2010 2:03 PM
To: Tom Incorvia
Cc: Jilayne Lovejoy; kate.stewart@...; spdx@...
Subject: Re: License List spreadsheet v1.1

 

On 10/20/2010 02:56 PM, Tom Incorvia wrote:

> -          The Python license may have versions – I am not certain --

> they take the time to restate the license with each release – however, I

> comparisons of some of the “official licenses” and they were the same.

> Anyway, we will need to dig into Python a bit in terms of versioning and

> relationship to CNRI – I don’t have the bandwidth for this right now,

> but hopefully there is someone on the team who is deep into Python licensing

 

To the best of my understanding, there have been several different

Python license versions, but the licenses are self-superseding, in that

as new versions arrive, they automatically apply.

 

~tom

 

 

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


Re: updated license list

Bruno Cornec <Bruno.Cornec@...>
 

Hello,

Jilayne Lovejoy said on Thu, Nov 04, 2010 at 09:19:54AM -0600:

Here is the next version of the license list (v1.2) that includes the
license text and some other changes discussed via email. I also updated
the "guidelines" document and listed any changes in this spreadsheet
over License List v1.1 there.
I think there is a problem line 32 of the LicenseList v1.2 file:
Column A mentions version 1.0 wheresas column B says 3.0.

I wonder if there shouldn't be a mention of the GFDL in this file as
well (with the multiple versions)? (CC are there)

Speaking of versions, I wonder whether there should'nt always be a
version mentioned, to support easily future revisions of the license not
having multiple version yet.

For dates, wouldn't it be more interesting (wrt sort, ...) to use the
ISO format: 2010-11-04 instead of the European one, which may be
confusing for non-european people.

HTH,
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


updated license list

Jilayne Lovejoy <Jlovejoy@...>
 

Here is the next version of the license list (v1.2) that includes the license text and some other changes discussed via email.  I also updated the “guidelines” document and listed any changes in this spreadsheet over License List v1.1 there.

 

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

 


Update from OWF

Kim Weins
 

Sorry this is a little late, although I shared some of this data on previous calls.

The SPDX presentation at OWF went well.  We had about 40 people or so, and most of them stayed an hour over the allotted time to discuss.  There was a lot of interest and positive feedback on the whole idea of SPDX.  Much of the discussion centered around some of the challenges we might face when it rolls out.

The issues raised were mostly around whether this would be harder/easier for the OSS communities and Linux distros to produce an SPDX file for their projects.  We talked about the need for tooling to help automate this.  We also said that usage may start with companies who then start using SPDX files with their supply chains.  That in turn may incent OSS communities to adopt SPDX.

There was also some discussion about the issue of SPDX files becoming “out of date” as soon as any change was made to the underlying code or anytime there was a new release.  We pointed out that information in the SPDX file could stay the same for many files, assuming that not all files in the distro had changed.

Martin & Phillipe Ombredanne may be able to add to this.

Kim


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





Web for call

Philip Odence
 

Big power outage in the Black Duck neighborhood so I may not be able to start up the web session. I'll be on my cell phone for the audio part. Please try to log in but don't be surprised if it doesn't work.


Nov 4 SPDX Call Agenda

Philip Odence
 

Meeting Time: Nov4, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC. NOTE THAT EUROPE HAS TURNED CLOCKS BACK TO STD TIME, BUT THE US HAS NOT YET, SO THE TIME DIFF FROM US TO EUROPE IS 1 HR LESS THAN NORMAL. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:
Conference code:  7812589502
Toll-free dial-in number (U.S. and Canada):  (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be found: 
https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each meeting for purposes of taking attendance. When you login PLEASE INCLUDE YOUR FULL NAME IN THIS FORM: Phil Odence, Black Duck Software so I can just copy/paste into minutes. THX.


Administrative Agenda
Attendance
Outreach and evangelism:
Common Messaging/Presentation – PhilO
Industry Venues – PhilR
Website – PhilO/Martin
Roll Out Update - KimW/JohnE
Legal Update - Rockett
 
Action Items
Note: Drafting related action items are embedded in the Wiki. http://www.spdx.org/wiki/spdx/specification
• Dave - Clean up the WIKI to only have analysis visible that reflects current spec.  IN PROCESS
• Dave/JeffL - Update zlib based on new specification  IN PROCESS
• Peter - Mail out competing proposals for 5.6/5.7  IN PROCESS
• PeterW- Implement issue tracking system.  BLOCKED ON KATE
• Kate - submit ids to Linux Foundation so infrastructure setup can proceed - pending.
• Kate- Draft example for LF Member Counsel; include XML and corresponding spreadsheet (or spreadsheet-like) format. peinding
• Kim - list of questions from Open World Forum to form start of FAQ  - pending - will send mail to list with questions remembered,  request Phillipe O, add comments.
• Phil R - Update Industry Events.
• Kate - 10/14 minutes to be added to WIKI for review. - IN PROCESS.
• Bill S - Send Martin some examples of issue posting HTML.
• Rockett- Mail out trademark policy draft to SPDX list.
• Rockett- Query status of trademark application
• Kim- Update of plans for Face to Face
• Kim- Send out invite for next licensing meeting.
• All- Review 6 months mail and contrast against licensing group spreadsheet
• Peter- Write up formal proposals for 5.6/5.7 issue alternatives and mail to list.
• All- If you can't attend meeting, post feedback/vote to list on 5.6/5.7 proposals.
• Kate- Write up formal proposal on SHA field change and mail to list.
• All- Review SHA field change proposal for technical flaws; if so, discuss on list.
• Kate- Add back to SPEC page in WIKI preferred syntax for adding comments.

Technical Agenda
Well just be reviewing action items this meeting.


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

1421 - 1440 of 1591