Legal Team/or-later-vs-unclear-disambiguation - Revision history

Wking: Possibly obsolete in favor of the proposals listed in the 2017-11-09 minutes.

2017-11-14T09:16:17Z

Possibly obsolete in favor of the proposals listed in the 2017-11-09 minutes.

Wking: Obsolete this page in favor of Legal_Team/only-operator-proposal

2017-09-07T19:00:19Z

Obsolete this page in favor of Legal_Team/only-operator-proposal

Jlovejoy: /* Goals */

2017-08-17T21:00:40Z

‎Goals

Jlovejoy: /* Current Proposed Solution */

2017-08-17T20:44:20Z

‎Current Proposed Solution

Jlovejoy: /* Current Proposed Solution */

2017-08-17T20:44:09Z

‎Current Proposed Solution

Jlovejoy at 20:42, 17 August 2017

2017-08-17T20:42:56Z

Jlovejoy: /* Issue */

2017-08-17T20:22:20Z

‎Issue

Jlovejoy at 20:16, 17 August 2017

2017-08-17T20:16:30Z

Jlovejoy: /* Selected responses/ideas/commentary from mailing list */

2017-08-17T20:10:03Z

‎Selected responses/ideas/commentary from mailing list

Jlovejoy at 19:52, 17 August 2017

2017-08-17T19:52:57Z

← Older revision		Revision as of 09:16, 14 November 2017
Line 1:		Line 1:
−	Status: obsolete (See more recent discussion in [[~~Legal Team~~/~~only~~-~~operator~~-~~proposal~~]])	+	Status: obsolete? (See more recent discussion in [[Legal_Team/Minutes/2017-11-09]]

	==Introduction to Issue ==		==Introduction to Issue ==

← Older revision		Revision as of 19:00, 7 September 2017
Line 1:		Line 1:
		+	Status: obsolete (See more recent discussion in [[Legal Team/only-operator-proposal]])
		+
	==Introduction to Issue ==		==Introduction to Issue ==
	===Background (SPDX)===		===Background (SPDX)===

@@ Line 34: / Line 34: @@
 * Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
 * Ensure that there is some amount of consistency with what the short identifiers refer to
 ==Solutions==

@@ Line 47: / Line 47: @@
 * The + operator would remain with the same definition.
 * In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
-* * This avoids SPDX having to make an interpretation as to what the licenses mean/intend.
+** This avoids SPDX having to make an interpretation as to what the licenses mean/intend.
-* * Allows for use of GPL-2.0 when you find just the license file with the text of GPL-2.0 and still provides option for Concluded License to be GPL-1.0+ if no other info is found
+** Allows for use of GPL-2.0 when you find just the license file with the text of GPL-2.0 and still provides option for Concluded License to be GPL-1.0+ if no other info is found
 * Remove "only" from full name of GPL family.
 * This solution allows the license text to speak for itself and uses the 'only' and '+' operators to be explicit in intent. It also avoids conflicting operators by retaining the "plain" license identifier.

@@ Line 44: / Line 44: @@
 * Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use'.
-* * add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language
+** add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language
 * The + operator would remain with the same definition.
 * In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.

@@ Line 43: / Line 43: @@
 Based on the joint legal/tech call on 17  August 2017, we coalesced around a solution similar to "alternative option" from 8 Aug joint call:
-* Create an "only" operator defined as only the version of the license is intended for use.
+* Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use'.
 * The + operator would remain with the same definition.
 * In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
 ===Joint call 8 Aug 2017 proposed solution ===
@@ Line 70: / Line 80: @@
 Potential issues (in addition to those listed for the previous proposal):
 * If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not.  John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.
@@ Line 82: / Line 91: @@
 Potential issues:
 * This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
 * This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.

← Older revision		Revision as of 20:22, 17 August 2017
Line 30:		Line 30:
	The spec provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). This approach will also fail to distinguish between <code>MPL-2.0</code> and <code>MPL-2.0-no-copyleft-exception</code>, since that distinction is [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/MPL-2.0-no-copyleft-exception.xml#L43-L44 based on the blurbs]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.		The spec provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). This approach will also fail to distinguish between <code>MPL-2.0</code> and <code>MPL-2.0-no-copyleft-exception</code>, since that distinction is [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/MPL-2.0-no-copyleft-exception.xml#L43-L44 based on the blurbs]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

		+	===Goals===
		+	* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
		+	* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
		+	* Ensure that there is some amount of consistency with what the short identifiers refer to

	==Solutions==		==Solutions==

@@ Line 24: / Line 24: @@
 And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions.  The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant.  And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).
 ===Issue===
@@ Line 34: / Line 32: @@
 ==Solutions==
 ===Current Proposed Solution===
 Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
 * Create an "only" operator defined as only the version of the license is intended for use.
@@ Line 78: / Line 86: @@
 ===Alternative Solution - GPL-2.0-only license ID===
 Replace "GPL-2.0" identifier with "GPL-2.0-only"
 Potential issues:

@@ Line 103: / Line 103: @@
 == Selected responses/ideas/commentary from mailing list ==
 ''' NOTE:''' Please feel free to add/clarify below
 At the same time as conversations between SPDX leaders and FSF representatives were on-going, this topic bubbled up on SPDX mailing list. Below is a summary of such conversations.

@@ Line 14: / Line 14: @@
 The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family).  However, to anyone's memory we did not at that time conduct a full analysis of the other licenses with "or later" language or how they work in practice.
-The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions].  There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).
+Not all licenses that provide for later versions treat their application in the same way or as explicitly as the GNU family of licenses does.
 And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions.  The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant.  And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).
 ===Issue===
 In practice, practitioners are not always explicit about whether a license is a version only or or later option.  For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.
 ==Solutions==