THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Legal Team/Minutes/2017-11-09"

From SPDX Wiki
Jump to: navigation, search
(Add the “operator metadata proposal”, since I think it addresses the concerns which motivate (2) while still allowing for a future ‘PROXY {text}’ operator)
(Mention that the “license text but no grant” case will need an additional AMBIGUOUS or OR-MAYBE operator)
Line 23: Line 23:
 
* current proposal is easier for tooling and also leaves room for extensibility or other operators (discussion of how proxy clause would work, for example)
 
* current proposal is easier for tooling and also leaves room for extensibility or other operators (discussion of how proxy clause would work, for example)
  
'''Net sum of call: two possible proposals, both of which accommodate 3 options: '''
+
'''Net sum of call: possible proposals, all of which accommodate 3 options: '''
 
* this version only
 
* this version only
 
* this or any later version
 
* this or any later version
Line 32: Line 32:
  
 
1b) “operator metadata proposal”
 
1b) “operator metadata proposal”
* Like “Gary's proposal”, but [https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html add] [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002308.html <code>compatibleWith…</code>] [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html metadata] so we can warn in tooling and on the license list that a bare <code>GPL-2.0</code> is ambiguous and that valid license-expressions SHOULD (and [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002311.html later, with SPDX 3.0, MUST]) supply a versioning operator.
+
* Like “Gary's proposal”, but [https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html add] [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002308.html <code>compatibleWith…</code>] [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html metadata] so we can warn in tooling and on the license list that a bare <code>GPL-2.0</code> is ambiguous and that valid license-expressions SHOULD (and [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002311.html later, with SPDX 3.0, MUST]) supply a versioning operator.  In this case, the “license text but no grant” case would be require an explicit [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html <code>AMBIGUOUS</code> or <code>OR-MAYBE</code> operator].
  
 
2) “Paul’s alternative proposal: provide 3 “hard-coded” options on the license list as follows:  
 
2) “Paul’s alternative proposal: provide 3 “hard-coded” options on the license list as follows:  

Revision as of 22:10, 9 November 2017

Attendees

  • Kate Stewart
  • Bradley Kuhn
  • Bradlee Edmondson
  • Alexios
  • John Sullivan
  • Dennis Clark
  • Paul Madick
  • Steve Winslow
  • Mike Dolan
  • Trevor King
  • Gary O’Neall
  • Alan Tse
  • Jilayne

Agenda

1) revisit the only/or later/? topic - see discussions from mailing list: https://lists.spdx.org/pipermail/spdx-legal/2017-November/thread.html The notes below includes key points, but not all the discussion:

  • John: issue with plain identifiers is if there is just a copy of license with no statement, then there’s statement in license itself that any version of GPL can be used; the copy of a version does not specify the version by itself. in response to Jilayne’s comparison to the license w/binary blob example (where the license would prevail with no other info needed in the “files”) - GPL is more specific, so not a comparison
  • tension in how license list is used and different fields in spec - info in file v. conclusion; and outside an SPDX document - need to address both/all
  • Trevor proposed enhancement to XML to flag error if use plain identifier (e.g., GPL0-2.0) which might only apply to conclusion fields
  • could also add/make NOASSERTION as something that can be used as part of license list/expressions (not just within the spec/SPDX docs) - this would be helpful for more than this scenario.
  • current proposal is easier for tooling and also leaves room for extensibility or other operators (discussion of how proxy clause would work, for example)

Net sum of call: possible proposals, all of which accommodate 3 options:

  • this version only
  • this or any later version
  • I found the license text (of a version) only and no other information

1a) “Gary’s proposal” (same one as we’ve been talking about since beginning of this discussion):

  • keep plain identifiers on license list (remove the word “only” in full name); add “only” operator; provide documentation that the plain identifier is meant to be used in the instance to show you found the text of that license

1b) “operator metadata proposal”

2) “Paul’s alternative proposal: provide 3 “hard-coded” options on the license list as follows:

  • change current GPL-2.0 to GPL-2.0-only
  • add GPL-2.0-or-later
  • add GPL-2.0-text-alone (or something along those lines) to be used in the instance to show you found the text of that license)

Note: the use of people’s names is only to attribute who initiated the idea and aide in referring to the proposals :)

Need to carry on discussion of next release preparations, as well as this topic on mailing list.

Note: next call falls on Thanksgiving, so we will use tech team’s call time on Tuesday, Nov to carry on discuss so too much time does not pass!