Date   

Re: update on only/or later etc.

David A. Wheeler
 

Brad Edmondson [mailto:brad.edmondson@...]
I think your points are good ones, but it seems to me they go to the separate issues of "file:detected license" and "package:concluded license." 
The clarity of the spec argument is aimed at making the "file:detected license" case more explicit, and if it leaves tools with NOASSERTION for "package:concluded license," then I think that's OK, no?
No, it fails to work for multiple reasons:
1. "NOASSERTION" is basically useless, because it provides no information. In many cases, all I need to know is "there's a version of the GPL here", and I can make a decision. Being able to provide *some* information is often all that's needed , while providing *no* information creates a lot of unnecessary work for tool users.
2. Tools, lacking sentience, often cannot determine whether or not "or later versions" applies. So they're unable to be "more explicit" in package:concluded. The current structure requires that conclude either "only 2.0" or "2.0 or later"... even though tools typically CANNOT make that determination. SPDX should make it possible report the information *actually* available.
3. The majority of SPDX users do not use SPDX files. Instead, they *only* use SPDX license expressions (as available in package managers, file content declarations, etc.). So there's no "file:detected" vs. "package:concluded" entries to compare anyway.

--- David A. Wheeler


Re: update on only/or later etc.

John Sullivan
 

J Lovejoy <opensource@...> writes:

Hi All,

Kate and I just had a call with Richard Stallman of the FSF to try and
come to a resolution everyone can be happy with, taking into
consideration the ask from the FSF and the many thorough discussions
we’ve had on the mailing list and calls. This is similar to an
approach we discussed on the last call, with one variation. As such,
I’d like to propose the following path forward (again, using GPL-2.0
but for all GNU licenses):
Thanks to everyone for working with us on this!

-john

--
John Sullivan | Executive Director, Free Software Foundation
GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
https://status.fsf.org/johns | https://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<https://my.fsf.org/join>.


Re: update on only/or later etc.

Brad Edmondson
 

Hi David, 

I think your points are good ones, but it seems to me they go to the separate issues of "file:detected license" and "package:concluded license." 

The clarity of the spec argument is aimed at making the "file:detected license" case more explicit, and if it leaves tools with NOASSERTION for "package:concluded license," then I think that's OK, no?

Best,
Brad

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Fri, Nov 17, 2017 at 10:35 AM, Wheeler, David A <dwheeler@...> wrote:
J Lovejoy:

> Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause

I disagree, sorry.

> - we don’t need to solve this right now and we can always add this option later
> - without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change. 

No, this is the *reason* that there's a problem.  The *reason* that "GPL-2.0" isn't working is, in part, because it overloads two notions.  "GPL-2.0" is supposed to mean "Only 2.0" (per the spec) .  But tools only know "I saw a GPL-2.0 license", so how can they represent that information?  The obvious way is "GPL-2.0", so that same identifier can mean "2.0 at least, and I don't know if there are other versions allowed".  That's not good.

If we wait to "add this option later", "GPL-2.0-only" will probably have morphed in *practice* into "GPL-2.0 at least, and I don't know if it's the only version".  So while everyone can congratulate themselves about the clarity of the spec, very soon it will predictably be *unclear* in practice.  If we want to be able to express "exactly this version", we also need to be able to represent "at least this version".

--- David A. Wheeler

_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal


Re: update on only/or later etc.

David A. Wheeler
 

J Lovejoy:

Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause
I disagree, sorry.

- we don’t need to solve this right now and we can always add this option later
- without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change. 
No, this is the *reason* that there's a problem. The *reason* that "GPL-2.0" isn't working is, in part, because it overloads two notions. "GPL-2.0" is supposed to mean "Only 2.0" (per the spec) . But tools only know "I saw a GPL-2.0 license", so how can they represent that information? The obvious way is "GPL-2.0", so that same identifier can mean "2.0 at least, and I don't know if there are other versions allowed". That's not good.

If we wait to "add this option later", "GPL-2.0-only" will probably have morphed in *practice* into "GPL-2.0 at least, and I don't know if it's the only version". So while everyone can congratulate themselves about the clarity of the spec, very soon it will predictably be *unclear* in practice. If we want to be able to express "exactly this version", we also need to be able to represent "at least this version".

--- David A. Wheeler


Re: update on only/or later etc.

David A. Wheeler
 

Jilayne Lovejoy <opensource@...>:
Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause 9 
This "resolution" doesn't solve the problem.

Since tools are not yet sentient, tools often *cannot* determine if "or later" was intended. Yet "don't know" makes a tool useless, and it *did* see a copy of a license, so the tool *will* report something. Tools will probably report "GPL-2.0-only" when they only see the GPL-2.0. As a result, soon "GPL-2.0-only" will not IN PRACTICE mean "only GPL-2.0".

I'm fine with "GPL-2.0-only" and special-casing "GPL-2.0+", but we *STILL* need a way to indicate "GPL-2.0 at least and I don't know if later versions are okay".

People depend on automated tools, and automated tools often CAN'T figure out the "or later" question. There are a million ways to indicate "I don't know if a later version is okay", e.g., "AT LEAST" or "?" suffix, MAYBE operation, etc. But if SPDX can't represent this common case, then people will overload *other* expressions with this alternative meaning, meaning that the "only" soon won't have that meaning.

--- David A. Wheeler


Re: update on only/or later etc.

Philip Odence
 

Great. We will start calling you two Kings Solomon.

 

From: <spdx-legal-bounces@...> on behalf of Jilayne Lovejoy <opensource@...>
Date: Thursday, November 16, 2017 at 7:38 PM
To: SPDX-legal <spdx-legal@...>
Subject: update on only/or later etc.

 

Hi All,

 

Kate and I just had a call with Richard Stallman of the FSF to try and come to a resolution everyone can be happy with, taking into consideration the ask from the FSF and the many thorough discussions we’ve had on the mailing list and calls. This is similar to an approach we discussed on the last call, with one variation. As such, I’d like to propose the following path forward (again, using GPL-2.0 but for all GNU licenses):

 

Deprecate the "GPL-2.0" identifier and add the word “only” for GPL version 2 only, e.g., "GPL-2.0-only"

- this should not be problematic as it does not change the meaning of the identifier. GPL-2.0 has meant ‘version 2 only’ since the SPDX License List was born. We are simply adding explicit language for the identifier. No backwards compatibility issues in terms of the meaning.

- we can do a “warning” for people using the deprecated identifier for a period before “GPL-2.0" becomes invalid to give people a chance to update. This will also encourage people who have been sloppy to fix their sloppiness.

 

Add GPL version 2 or later back to the SPDX License List as it’s own entry with the short identifier of “GPL-2.0+” or “GPL-2.0-or-later” 

- This would essentially put us in the same position we are now: with two options - “only” and “or later” - it just alters how one gets there, where one finds it

- this would also put both options back on the license list thus highlighting that the GNU licenses provides these options more obviously and hopefully providing a more overt encouragement to using one or the other

- the identifier here could be “GPL-2.0+” (same as always) or “GPL-2.0-or-later” (differentiation from the + modifier might be better for tooling?) - we can discuss which is better, FSF is fine with either. 

- if we go with “GPL-2.0-or-later”, can take same approach with warning re: “GPL-2.0+” then invalid?

 

Keep the + modifier in the license expression language

- this allows use of + with other licenses as always, no change, no backwards compatibility

 

Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause 9 

- on the last call, we came up with two proposals that both incorporate 3 options for each GNU license, see: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09 - the above proposal is the same as “Paul’s alternative” / hard-coded proposal but omits adding the ‘text alone” option

- we don’t need to solve this right now and we can always add this option later

- without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change. 

 

 

I am really hoping we can all get behind this approach and spend the time on Tuesdays’ call discussing the specifics of implementation, whatever else needs to be done for the next release (for this change and generally), and then get the next release out in time for a nice Christmas present to us all :)

 

 

Thanks,

Jilayne

 

SPDX Legal Team co-lead
opensource@...

 


Re: update on only/or later etc.

Gary O'Neall
 

I think this is a good overall solution.

It solves the issue raised by the FSF and is reasonably compatible. On the last legal call, I raised a concern that it didn't handle the case where the version may be ambiguous. After the call, I realized that we have this issue today and we don't really need to solve this in this release of the license list. Probably better to solve one issue at a time, and I have no problem starting with the issue raised by Richard and the FSF.

Thanks Jilayne for moving this forward.

Additional thoughts on the '+' operator below:

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-
bounces@...] On Behalf Of W. Trevor King
Sent: Thursday, November 16, 2017 4:53 PM
To: J Lovejoy
Cc: SPDX-legal
Subject: Re: update on only/or later etc.

Keep the + modifier in the license expression language
- this allows use of + with other licenses as always, no change, no
backwards compatibility
I am strongly against having both a ‘GPL-2.0+’ license ID and a ‘+’
operator. I think committing to a ‘GPL-2.0+’ license ID is an unfortunate but
tenable postition. And if we go that way, I'd rather remove the ‘+’ operator
entirely.

I'd be ok with ‘GPL-2.0-or-later’ while preserving the ‘+’ operator for other
licenses. But if a ‘+’ operator is deemed not good enough for the GPL, which
licenses would it be good enough for? This feels like “we don't know when
we'd recommend ‘+’, but didn't have the heart to kill it”.
I agree with Trevor that we should not have both the + modifier and the GPL-2.0+ as a license ID as it makes the parsing ambiguous.

My preference would be GPL-2.0-or-later and preserving the '+' operator. The '+' operator could be useful for licenses where they do not explicitly handle the 'or later' versions in the license text and it maintains better compatibility.

Cheers,
Gary


Re: update on only/or later etc.

Brad Edmondson
 

Wow! Hopefully this resolves this issue for the foreseeable future (as I think it should). I echo Karen's sentiments -- great work!


As far as the next release, to my mind, the biggest open issue is adding XML for the recently added licenses, which I think should be 2.6+. I haven't done a careful check, but based on a quick scan of the Google Sheets document, that looks like it could be:
  • EPL-2.0
  • EUPL-1.2
  • BSD-2-Clause-Patent (done)
  • W3C-Software-2015
  • Unicode-DFS-2015 (done)
  • Unicode-DFS-2016 (done)
  • TCP-wrappers (done)
  • Net-SNMP (done)

And perhaps also some/all of the licenses still under review:
  • CDLA-Permissive-1.0
  • CDLA-Sharing-1.0
  • OSCAT

Then we should add the accepted exceptions:
  • Linux-syscall-note (done)
  • Bootloader-exception
And perhaps the same for exceptions under review, although I'm not as familiar with these and they may be stale at this point. But as marked, these are "under review":
  • aptana-exception-3.0
  • Cygwin-exception-2.0
  • FOSS-License-exception
  • MySQL-Connector-ODBC-exception-2.0
  • OCaml-exception
  • rrdtool-floss-exception-2.0
  • sencha-exception-3.0
  • trolltech-gpl-exception-1.2
  • wolfcms-exception-2.0
  • Zarafa-trademark-exception-3.0

Best,
Brad

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Thu, Nov 16, 2017 at 8:35 PM, Copenhaver, Karen <kcopenhaver@...> wrote:
There are so many things I admire about the people involved and the process that has been followed to get to this proposal for consensus.  Many thanks for all Jilayne and Kate and so many others have done to bring SPDX to a point that exceeds all of our expectations.

________________________________
From: spdx-legal-bounces@....org [spdx-legal-bounces@lists.spdx.org] on behalf of J Lovejoy [opensource@...]
Sent: Thursday, November 16, 2017 7:37 PM
To: SPDX-legal
Subject: update on only/or later etc.

Hi All,

Kate and I just had a call with Richard Stallman of the FSF to try and come to a resolution everyone can be happy with, taking into consideration the ask from the FSF and the many thorough discussions we’ve had on the mailing list and calls. This is similar to an approach we discussed on the last call, with one variation. As such, I’d like to propose the followingath forward (again, using GPL-2.0 but for all GNU licenses):

Deprecate the "GPL-2.0" identifier and add the word “only” for GPL version 2 only, e.g., "GPL-2.0-only"
- this should not be problematic as it does not change the meaning of the identifier. GPL-2.0 has meant ‘version 2 only’ since the SPDX License List was born. We are simply adding explicit language for the identifier. No backwards compatibility issues in terms of the meaning.
- we can do a “warning” for people using the deprecated identifier for a period before “GPL-2.0" becomes invalid to give people a chance to update. This will also encourage people who have been sloppy to fix their sloppiness.

Add GPL version 2 or later back to the SPDX License List as it’s own entry with the short identifier of “GPL-2.0+” or “GPL-2.0-or-later”
- This would essentially put us in the same position we are now: with two options - “only” and “or later” - it just alters how one gets there, where one finds it
- this would also put both options back on the license list thus highlighting that the GNU licenses provides these options more obviously and hopefully providing a more overt encouragement to using one or the other
- the identifier here could be “GPL-2.0+” (same as always) or “GPL-2.0-or-later” (differentiation from the + modifier might be better for tooling?) - we can discuss which is better, FSF is fine with either.
- if we go with “GPL-2.0-or-later”, can take same approach with warning re: “GPL-2.0+” then invalid?

Keep the + modifier in the license expression language
- this allows use of + with other licenses as always, no change, no backwards compatibility

Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause 9
- on the last call, we came up with two proposals that both incorporate 3 options for each GNU license, see: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09<https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09> - the above proposal is the same as “Paul’s alternative” / hard-coded proposal but omits adding the ‘text alone” option
- we don’t need to solve this right now and we can always add this option later
- without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change.


I am really hoping we can all get behind this approach and spend the time on Tuesdays’ call discussing the specifics of implementation, whatever else needs to be done for the next release (for this change and generally), and then get the next release out in time for a nice Christmas present to us all :)


Thanks,
Jilayne

SPDX Legal Team co-lead
opensource@...<mailto:opensource@...>


Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP.  It is intended exclusively for the individual or entity to which it is addressed.  The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure.  If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it.  If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com

_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal


Re: update on only/or later etc.

Karen C.
 

There are so many things I admire about the people involved and the process that has been followed to get to this proposal for consensus. Many thanks for all Jilayne and Kate and so many others have done to bring SPDX to a point that exceeds all of our expectations.

________________________________
From: spdx-legal-bounces@... [spdx-legal-bounces@...] on behalf of J Lovejoy [opensource@...]
Sent: Thursday, November 16, 2017 7:37 PM
To: SPDX-legal
Subject: update on only/or later etc.

Hi All,

Kate and I just had a call with Richard Stallman of the FSF to try and come to a resolution everyone can be happy with, taking into consideration the ask from the FSF and the many thorough discussions we’ve had on the mailing list and calls. This is similar to an approach we discussed on the last call, with one variation. As such, I’d like to propose the followingath forward (again, using GPL-2.0 but for all GNU licenses):

Deprecate the "GPL-2.0" identifier and add the word “only” for GPL version 2 only, e.g., "GPL-2.0-only"
- this should not be problematic as it does not change the meaning of the identifier. GPL-2.0 has meant ‘version 2 only’ since the SPDX License List was born. We are simply adding explicit language for the identifier. No backwards compatibility issues in terms of the meaning.
- we can do a “warning” for people using the deprecated identifier for a period before “GPL-2.0" becomes invalid to give people a chance to update. This will also encourage people who have been sloppy to fix their sloppiness.

Add GPL version 2 or later back to the SPDX License List as it’s own entry with the short identifier of “GPL-2.0+” or “GPL-2.0-or-later”
- This would essentially put us in the same position we are now: with two options - “only” and “or later” - it just alters how one gets there, where one finds it
- this would also put both options back on the license list thus highlighting that the GNU licenses provides these options more obviously and hopefully providing a more overt encouragement to using one or the other
- the identifier here could be “GPL-2.0+” (same as always) or “GPL-2.0-or-later” (differentiation from the + modifier might be better for tooling?) - we can discuss which is better, FSF is fine with either.
- if we go with “GPL-2.0-or-later”, can take same approach with warning re: “GPL-2.0+” then invalid?

Keep the + modifier in the license expression language
- this allows use of + with other licenses as always, no change, no backwards compatibility

Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause 9
- on the last call, we came up with two proposals that both incorporate 3 options for each GNU license, see: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09<https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09> - the above proposal is the same as “Paul’s alternative” / hard-coded proposal but omits adding the ‘text alone” option
- we don’t need to solve this right now and we can always add this option later
- without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change.


I am really hoping we can all get behind this approach and spend the time on Tuesdays’ call discussing the specifics of implementation, whatever else needs to be done for the next release (for this change and generally), and then get the next release out in time for a nice Christmas present to us all :)


Thanks,
Jilayne

SPDX Legal Team co-lead
opensource@...<mailto:opensource@...>


Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com


Re: update on only/or later etc.

Paul Madick
 

This is really great news.  This was a difficult issue that sparked a lot of folks to join our SPDX Legal/Technical calls to the point we needed more con call space.  We are fortunate to have such a vibrant community concerned with the particulars of the SPDX License List. 

 

The solution addresses the primary concerns raised by Richard Stallman and the FSF while preserving the effectiveness of the SPDX License List for multiple use cases.  There are still additional opportunities to further refine the SPDX License List to address situations that were not previously handled.  I look forward to revisiting those issues in the future.

 

Paul

 

 

From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of J Lovejoy
Sent: Thursday, November 16, 2017 4:38 PM
To: SPDX-legal <spdx-legal@...>
Subject: update on only/or later etc.

 



Hi All,

 

Kate and I just had a call with Richard Stallman of the FSF to try and come to a resolution everyone can be happy with, taking into consideration the ask from the FSF and the many thorough discussions we’ve had on the mailing list and calls. This is similar to an approach we discussed on the last call, with one variation. As such, I’d like to propose the following path forward (again, using GPL-2.0 but for all GNU licenses):

 

Deprecate the "GPL-2.0" identifier and add the word “only” for GPL version 2 only, e.g., "GPL-2.0-only"

- this should not be problematic as it does not change the meaning of the identifier. GPL-2.0 has meant ‘version 2 only’ since the SPDX License List was born. We are simply adding explicit language for the identifier. No backwards compatibility issues in terms of the meaning.

- we can do a “warning” for people using the deprecated identifier for a period before “GPL-2.0" becomes invalid to give people a chance to update. This will also encourage people who have been sloppy to fix their sloppiness.

 

Add GPL version 2 or later back to the SPDX License List as it’s own entry with the short identifier of “GPL-2.0+” or “GPL-2.0-or-later” 

- This would essentially put us in the same position we are now: with two options - “only” and “or later” - it just alters how one gets there, where one finds it

- this would also put both options back on the license list thus highlighting that the GNU licenses provides these options more obviously and hopefully providing a more overt encouragement to using one or the other

- the identifier here could be “GPL-2.0+” (same as always) or “GPL-2.0-or-later” (differentiation from the + modifier might be better for tooling?) - we can discuss which is better, FSF is fine with either. 

- if we go with “GPL-2.0-or-later”, can take same approach with warning re: “GPL-2.0+” then invalid?

 

Keep the + modifier in the license expression language

- this allows use of + with other licenses as always, no change, no backwards compatibility

 

Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause 9 

- on the last call, we came up with two proposals that both incorporate 3 options for each GNU license, see: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09 - the above proposal is the same as “Paul’s alternative” / hard-coded proposal but omits adding the ‘text alone” option

- we don’t need to solve this right now and we can always add this option later

- without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change. 

 

 

I am really hoping we can all get behind this approach and spend the time on Tuesdays’ call discussing the specifics of implementation, whatever else needs to be done for the next release (for this change and generally), and then get the next release out in time for a nice Christmas present to us all :)

 

 

Thanks,

Jilayne

 

SPDX Legal Team co-lead
opensource@...

 



itevomcid


Re: update on only/or later etc.

W. Trevor King
 

On Thu, Nov 16, 2017 at 05:37:50PM -0700, J Lovejoy wrote:
Deprecate the "GPL-2.0" identifier and add the word “only” for GPL
version 2 only, e.g., "GPL-2.0-only"
- this should not be problematic as it does not change the meaning
of the identifier. GPL-2.0 has meant ‘version 2 only’ since the
SPDX License List was born. We are simply adding explicit language
for the identifier. No backwards compatibility issues in terms of
the meaning.
- we can do a “warning” for people using the deprecated identifier
for a period before “GPL-2.0" becomes invalid to give people a
chance to update. This will also encourage people who have been
sloppy to fix their sloppiness.
I think this “deprecation with an eventual removal” approach is part
of all of the proposals, and is not unique to the “coin new
per-version license identifiers” approach.

Keep the + modifier in the license expression language
- this allows use of + with other licenses as always, no change, no
backwards compatibility
I am strongly against having both a ‘GPL-2.0+’ license ID and a ‘+’
operator. I think committing to a ‘GPL-2.0+’ license ID is an
unfortunate but tenable postition. And if we go that way, I'd rather
remove the ‘+’ operator entirely.

I'd be ok with ‘GPL-2.0-or-later’ while preserving the ‘+’ operator
for other licenses. But if a ‘+’ operator is deemed not good enough
for the GPL, which licenses would it be good enough for? This feels
like “we don't know when we'd recommend ‘+’, but didn't have the heart
to kill it”.

Personally, I think the ‘+’ operator *is* good enough for the GPL, but
if that view was universal we wouldn't be adding an or-later license
ID. If we cannot build a consensus around using ‘+’ for the GPL, I'd
rather drop it entirely. My concern with coining license identifiers
for ‘GPL-2.0-or-later’ and similar is the combinatoric increase in
license identifiers, and that's more of an aesthetic concern than a
technical concern (although there are some technical impacts, e.g. the
size of license-list-XML and license-list-data will grow).

Cheers,
Trevor

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


update on only/or later etc.

J Lovejoy
 

Hi All,

Kate and I just had a call with Richard Stallman of the FSF to try and come to a resolution everyone can be happy with, taking into consideration the ask from the FSF and the many thorough discussions we’ve had on the mailing list and calls. This is similar to an approach we discussed on the last call, with one variation. As such, I’d like to propose the following path forward (again, using GPL-2.0 but for all GNU licenses):

Deprecate the "GPL-2.0" identifier and add the word “only” for GPL version 2 only, e.g., "GPL-2.0-only"
- this should not be problematic as it does not change the meaning of the identifier. GPL-2.0 has meant ‘version 2 only’ since the SPDX License List was born. We are simply adding explicit language for the identifier. No backwards compatibility issues in terms of the meaning.
- we can do a “warning” for people using the deprecated identifier for a period before “GPL-2.0" becomes invalid to give people a chance to update. This will also encourage people who have been sloppy to fix their sloppiness.

Add GPL version 2 or later back to the SPDX License List as it’s own entry with the short identifier of “GPL-2.0+” or “GPL-2.0-or-later” 
- This would essentially put us in the same position we are now: with two options - “only” and “or later” - it just alters how one gets there, where one finds it
- this would also put both options back on the license list thus highlighting that the GNU licenses provides these options more obviously and hopefully providing a more overt encouragement to using one or the other
- the identifier here could be “GPL-2.0+” (same as always) or “GPL-2.0-or-later” (differentiation from the + modifier might be better for tooling?) - we can discuss which is better, FSF is fine with either. 
- if we go with “GPL-2.0-or-later”, can take same approach with warning re: “GPL-2.0+” then invalid?

Keep the + modifier in the license expression language
- this allows use of + with other licenses as always, no change, no backwards compatibility

Do NOT add a identifier or operator, etc. for the found-license-text-only scenario where you don’t know if the intent of the copyright holder was “only or “or later” and are thus left to interpret clause 9 
- on the last call, we came up with two proposals that both incorporate 3 options for each GNU license, see: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09 - the above proposal is the same as “Paul’s alternative” / hard-coded proposal but omits adding the ‘text alone” option
- we don’t need to solve this right now and we can always add this option later
- without adding a third option, we are in the same position we have been in since the birth of the SPDX License List. incremental changes have always been our go-to strategy; let’s take a first step to clarify the current identifiers in a way that the FSF can get behind. If, for a later release, we think we need this third option, then we can discuss that further once we have some time under our belts with this change. 


I am really hoping we can all get behind this approach and spend the time on Tuesdays’ call discussing the specifics of implementation, whatever else needs to be done for the next release (for this change and generally), and then get the next release out in time for a nice Christmas present to us all :)


Thanks,
Jilayne

SPDX Legal Team co-lead
opensource@...



Re: Jilayne Lovejoy invited you to “SPDX tech/legal call”.

W. Trevor King
 

On Wed, Nov 15, 2017 at 02:56:00PM +0000, Jilayne Lovejoy wrote:
UID:F31FBFD4-9300-4B60-BEC6-81CB9A3EFDCD
DESCRIPTION:Web conference: http://uberconference.com/SPDXTeam\n Optional
dial in number: 415-881-1586\n No PIN needed
SEQUENCE:0
SUMMARY:SPDX tech/legal call
DTSTART;TZID=America/Denver:20171121T110000
Instead of creating a new event for this joint session, folks who have
imported the legal-team meeting may find it more convenient if we add
the new time to an existing, recurring legal-team meeting. RFC 5545
provides RDATE for that [1], and an update to drop Thanksgiving and
add the 21st to the legal-team meeting looks like [2].

On the other hand, importing a new, one-off meeting from email isn't
that hard either, so perhaps an RDATE entry is over engineered ;).

Cheers,
Trevor

[1]: https://tools.ietf.org/html/rfc5545#section-3.8.5.2
[2]: https://github.com/spdx/spdx-spec/pull/42/commits/bb7ee2c9f9b7fed6cbff8d748b375bd199fb878b

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


Jilayne Lovejoy invited you to “SPDX tech/legal call”.

Jilayne Lovejoy <noreply@...>
 


Jilayne Lovejoy invited you to “SPDX tech/legal call”.
when Tuesday, November 21, 2017, 11:00 AM MST - 12:00 PM MST
invitees You
note Web conference: http://uberconference.com/SPDXTeam Optional dial in number: 415-881-1586 No PIN needed
Accept
Decline
Maybe
Don’t recognize this sender? Report Junk.
 


Re: SPDXTeam - new dial in number for meetings, same web link.

J Lovejoy
 

Hi all,

In light of the LF getting our main conference line fixed to not be limited to 10 people, I have updated the calendar invite for the rest of the year, as I”m not sure if that will populate for everyone correctly, please note that the info on the legal wiki landing page has now been updated and use that as your definitive source (thanks Kate!): https://wiki.spdx.org/view/Legal_Team

Note, I have also cancelled the next regular scheduled call on Nov 23 as it is the US Thanksgiving holiday.

We will have a legal call during the tech team’s call time of Tuesday, Nov 21 at 10am Pacific time.

Thanks,
Jilayne

SPDX Legal Team co-lead
opensource@...


On Nov 12, 2017, at 6:44 AM, Kate Stewart <kstewart@...> wrote:

Hi,
    We were able to get the SPDXTeam Uberconference updated
last Thursday to remove the limit on number of people attending
the call.  Yay!!!   However,  as a result of this,  we had to change the dial in number.

New dial in number: 415-881-1586
No PIN needed

The weblink for screenshare will stay the same at:
http://uberconference.com/SPDXTeam

Meeting times for teams will remain the same, as indicated 
on the page for each Team Work Area on https://wiki.spdx.org

Please let me know if you have any questions.

Thanks, Kate



_______________________________________________
Spdx-biz mailing list
Spdx-biz@...
https://lists.spdx.org/mailman/listinfo/spdx-biz


Jilayne Lovejoy invited you to “SPDX Legal call”.

Jilayne Lovejoy <noreply@...>
 


Jilayne Lovejoy invited you to “SPDX Legal call”.
when Thursday, November 10, 2016, 11:00 AM MST - 12:00 PM MST
Repeating event.
invitees Kris Reeves and you.
See replies…
note Join the call: https://www.uberconference.com/spdxteam Optional dial in number: 857-216-2871 PIN: 38633
Accept
Decline
Maybe
Don’t recognize this sender? Report Junk.
 


“SPDX Legal call” has been updated.

Jilayne Lovejoy <noreply@...>
 

“SPDX Legal call” has been updated.
time changed Thursday, December 7, 2017, 11:00 AM MST - 12:00 PM MST
Repeating event. (View details…)
invitees Kris Reeves and you.
See replies…
note changed New dial in number: 415-881-1586
No PIN needed
The weblink for screenshare will stay the same at:
http://uberconference.com/SPDXTeam
updated by Jilayne Lovejoy


“SPDX Legal call” has been canceled.

Jilayne Lovejoy <noreply@...>
 

“SPDX Legal call” has been canceled.
when Thursday, November 23, 2017, 11:00 AM MST - 12:00 PM MST
note Join the call: https://www.uberconference.com/spdxteam
Optional dial in number: 857-216-2871
PIN: 38633
deleted by Jilayne Lovejoy


FSFE Recommends use of SPDX License Identifiers

Manbeck, Jack
 

We were excited to see this and wanted to share. As part of Project REUSE the FSFE is recommending use of SPDX License Identifiers.

 

https://spdx.org/news/news/2017/11/fsfe-recommends-license-identifiers-part-project-reuse

 

(Click the link for the page with the Video)

 

 

 

 

 


SPDXTeam - new dial in number for meetings, same web link.

Kate Stewart
 

Hi,
    We were able to get the SPDXTeam Uberconference updated
last Thursday to remove the limit on number of people attending
the call.  Yay!!!   However,  as a result of this,  we had to change the dial in number.

New dial in number: 415-881-1586
No PIN needed

The weblink for screenshare will stay the same at:
http://uberconference.com/SPDXTeam

Meeting times for teams will remain the same, as indicated 
on the page for each Team Work Area on https://wiki.spdx.org

Please let me know if you have any questions.

Thanks, Kate



1221 - 1240 of 3281