Difference between revisions of "Legal Team/only-operator-proposal"

Revision as of 03:35, 7 September 2017

Introduction to Issue

Background (SPDX)

Originally, the SPDX License List listed variations of licenses as separate "line items". Notably, various versions of L/GPL had two listed items: one for a specific version-only, and one indicating a version-or-later. This was indicated in the list via the inclusion of the words "only" and "or later" in the full name; and via the short identifier: GPL-2.0 and GPL-2.0+ respectively. (examples throughout this page use GPL-2.0, but this issue applies to the entire family of GNU licenses, i.e., GPL, LGPL, FDL, APGL).

For example, the pre-version-2.0 SPDX License List looked like this:

  GNU General Public License v2.0 only	  GPL-2.0	
  GNU General Public License v2.0 or later	  GPL-2.0+

When the license expression syntax was introduced in version 2.0 of SPDX, licenses with the "or later" indication were removed as separate listed licenses ("deprecated"), as the "or later" option could now be provided for via using the + operator. This enabled the use of the + operator with other licenses, as applicable.

The ability to create license expressions using the + operator along with the with operator also solved the issue of under-representation of license-exception combinations.

However, this also created a new issue whereby the standard header which is usually where the "or later" or "only" option is indicated in practice could no longer be differentiated or captured directly. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name where/when the +.

The original argument for the + 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.

Background (additional)

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. A list of the licenses with text related to later versions, relevant text, and an analysis of the licenses that have "or later version" type language are listed on this page: Legal Team/later-version-clauses

Notably, most licenses that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with an explicit notice prohibiting later versions. There's currently no only operator for the CDDL, although some code (e.g. parts of FreeBSD's ZFS implementation) do declare that prohibition while other code (e.g. some illumos userspace tools) do not (and are therefore presumably CDDL-1.0+).

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 +, only, or PROXY {TEXT} (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

The spec provides a way to distinguish between detected license files and the concluded package license. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. 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. Licensee, which is used by the GitHub license API). This approach will also fail to distinguish between MPL-2.0 and MPL-2.0-no-copyleft-exception, since that distinction is 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
• Don't completely break the meaning for current users

Proposed Solution