Re: only/or later and the goals of SPDX

[J Lovejoy]

> On Nov 9, 2017, at 12:54 PM, W. Trevor King  wrote:
> 
> On Wed, Oct 11, 2017 at 11:12:39PM -0700, W. Trevor King wrote:
>> The ambiguous operator (first floated as “unclear version” in [3])
>> and my OR-MAYBE proposal [4] are both attempts to allow an SPDX
>> License Expression authors to handle those situations they consider
>> too ambiguous for a complete conclusion, but where they can provide
>> more structure than NOASSERTION.  The ambiguous and OR-MAYBE
>> operators are both providing a way to express partial conclusions
>> *without* recourse to a full SPDX document and its unstructured
>> comment fields.  This may be useful in general, and David has said
>> he would be satisfied with:
>> 
>>  GPL-2.0 OR-MAYBE GPL-2.0+
>> 
>> most of the time [5].  I still don't have anyone stepping up to say
>> they'll produce such expressions though [6], and I doubt its worth
>> writing up a spec for it without someone saying “I (or my tool)
>> wants to write partially-concluded license expressions but there's
>> no syntax for it”.  But “nobody has told us they'd write this yet”
>> is a much narrower rejection than “the proposals are incongruent
>> with the goals of SPDX”.
> 
> On today's legal call, it sounded like Gary might have volunteered
> himself for the “I'd write partially-concluded license expressions,
> but there's no syntax for it yet” camp.  If so, we have both producers
> and consumers for some kind of partial-conclusion license expression
> syntax.  Do we need to collect further producer/consumer commitments,
> or is this enough to move forward with preliminary specifications for
> OR-MAYBE, AMBIGUOUS-VERSION, or one of those operators?

I don’t think “partially-concluded” is the right term here: the bit we are 
stuck on is a way to express: I found a copy of one of the GNU licenses, but no 
other information. Period.
- should that have it’s own license identifier? should that scenario have it’s 
own operator? TBD

Keep in mind: it doesn’t now. The license list and expression language 
currently provides for the “only” and “or later” options via GPL-2.0 and 
GPL-2.0+ 
To paraphrase Philippe’s earlier post: no one using SPDX has had a major issue 
with this and tool makers have managed to work with is. I believe David Wheeler 
was the first person to raise this as a potential gap (David, please correct me 
if I’m wrong), aside from the FSF.
> 
> There was a separate discussion in today's legal call about whether
> the versioning information should be an operator (GPL-2.0
> AMBIGUOUS-VERSION) or a separate license-list entry
> (GPL-2.0-ambiguous-version).  But from a technical perspective it's
> easy to switch between those approaches, so I don't think we need to
> block preliminary partial-conclusion spec work on that decision.
> 
> And John reraised the fact that concluding a license in the absence of
> an explicit grant based on the presence of license text is fairly
> shaky ground.  But it sounds like Gary is willing to stand on that
> ground, and that David would be happy to consume that stance.  I don't
> think the SPDX should stand in the way of folks expressing partial
> conclusions, even if some people are not going to be comfortable with
> the conclusions themselves.

From a legal point of view, concluding and acting thusly that the presence of a 
license alone is a license to use the accompanying copyrightable work, even in 
the absence of file-level notices is not really on shaky ground. It’s just that 
the GNU family of licenses strongly prefer and and provide instructions to use 
the standard headers in every source file. 

Anyone doing audit work can benefit from a way to specify that a license is 
found and be specific about what license was found. We do have that now. The 
question on the table is if/how to accommodate that in a different, preferably 
more specific way. 


> Am I misrepresenting anyone?

I don’t think David was on this call, not sure if you were implying that here, 
but sort of sounded like it ;)

Jilayne

> 
> Cheers,
> Trevor
> 
> [1]: https://github.com/spdx/tools
> [2]: 
> https://github.com/javierwilson/tonto/tree/75be0678be565872cbe7b99d5af4a1946393ee77
> 
>> [3]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002230.html
>> Subject: reminder: call Thursday
>> Date: Wed, 27 Sep 2017 16:49:46 -0600
>> Message-Id: <9216ca28-7f42-452a-913f-8bcc0cfe1...@jilayne.com>
>> [4]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002233.html
>> Subject: "unclear version" and OR-MAYBE operators (was: reminder: call 
>> Thursday)
>> Date: Wed, 27 Sep 2017 22:15:23 -0700
>> Message-ID: <20170928051523.gn20...@valgrind.tremily.us>
>> [5]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002235.html
>> Subject: RE: "unclear version" and OR-MAYBE operators (was: reminder: 
>> call Thursday)
>> Date: Thu, 28 Sep 2017 16:43:46 +
>> Message-ID: 

Re: only/or later and the goals of SPDX

[J Lovejoy]

> On Nov 9, 2017, at 10:48 AM, John Sullivan  wrote:
> 
> "Wheeler, David A"  writes:
> 
>> John Sullivan:
>>> A key part is missing in the description of the original FSF proposal here
>>> though -- which is deprecating the existing GPL-2.0 and similar "plain"
>>> identifiers for GNU licenses so that the identifiers used always indicate
>>> whether the version is "only" or "any later".
>>> 
>>> As I understand it, people had concerns with deprecating the plain
>>> identifiers because of situations where they (for example) find a copy of
>>> GPLv2, but no clear statement about whether the program is actually
>>> licensed under its terms.
>> 
>> Not exactly.  In many cases it's clearly licensed under GPLv2.
>> The issue is that often we don't know if "or any later version"
>> applies.
> 
> On this point, to me, if it doesn't say "or any later version", then
> it's "only" -- assuming a clear statement other than the license text
> itself specifying the version number of the GPL.
> 

John, when you say “other than the license text itself specifying the version 
number” - can you provide an example beside the usual recommended header? 
That is, do you mean, for example - there is a statement somewhere in a README 
saying “this is under GPLvX” or the like? - and such a statement, with no clear 
language to the effect of “or any later version” should be then considered 
“this version only”?



Thanks,
Jilayne
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: only/or later and the goals of SPDX

[John Sullivan]

"Wheeler, David A"  writes:

> John Sullivan:
>> A key part is missing in the description of the original FSF proposal here
>> though -- which is deprecating the existing GPL-2.0 and similar "plain"
>> identifiers for GNU licenses so that the identifiers used always indicate
>> whether the version is "only" or "any later".
>>
>> As I understand it, people had concerns with deprecating the plain
>> identifiers because of situations where they (for example) find a copy of
>> GPLv2, but no clear statement about whether the program is actually
>> licensed under its terms.
>
> Not exactly.  In many cases it's clearly licensed under GPLv2.
> The issue is that often we don't know if "or any later version"
> applies.

On this point, to me, if it doesn't say "or any later version", then
it's "only" -- assuming a clear statement other than the license text
itself specifying the version number of the GPL.

-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
.
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: only/or later and the goals of SPDX

[W. Trevor King]

On Tue, Nov 07, 2017 at 11:31:07AM -0700, J Lovejoy wrote:
> https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses

And they have an official position on the javierwilson/tonto case,
where the GPL-3.0 text is in LICENSE, but no other file in the
repository contains copyright or licensing information.  From the
Fedora wiki:

  Full Name: GNU General Public License (no version)
  Short Name: GPL+
  FSF Free? Yes
  GPLv2 Compat? Yes
  GPLv3 Compat? Yes
  Notes (stuffed into the “Upstream URL” column):
A GPL or LGPL licensed package that lacks any statement of what
version that it's licensed under in the source code/program
output/accompanying docs is technically licensed under *any*
version of the GPL or LGPL, not just the version in whatever
COPYING file they include.

so their position is that the presence of a particular version of the
text in the COPYING (or presumably LICENSE, etc.) does not count as
the program specifying a version of the license [2].

Cheers,
Trevor

[1]: 
https://github.com/javierwilson/tonto/tree/75be0678be565872cbe7b99d5af4a1946393ee77
[2]: 
https://github.com/spdx/license-list-XML/blob/4aac6f8459901a6061c243cbfa3970afb39e3879/src/GPL-1.0.xml#L169-L170

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


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: only/or later and the goals of SPDX

[J Lovejoy]

(top-posting, as this part isn’t directly related)

It just occurred to me that how SPDX currently has the identifiers: plain 
GPL-2.0 and GPL-2.0+ is the same pattern that Fedora uses: they have a slightly 
different nomenclature, but also have a “plain” identifier and the + version: 
GPLv2 and GPLv2+ - see: 
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses 


Point being, even though Fedora has not fully adopted SPDX identifiers, we have 
a long-standing effort of aligning as much as we can - so any change we make, 
we need to keep them in the loop as well.  I have emailed Tom Callaway to make 
him aware of the proposal over here.

Jilayne

> On Nov 6, 2017, at 10:21 PM, W. Trevor King  wrote:
> 
> On Mon, Nov 06, 2017 at 09:12:20PM -0800, W. Trevor King wrote:
>> On Mon, Nov 06, 2017 at 09:22:50PM -0700, J Lovejoy wrote:
>>> Adding option B.(as per my previous email):
>>> B. Add “only” to GPL-2.0, add GPL-2.0+ back to the license list as
>>> a separate line item. keep the + operator to be used with other
>>> licenses. This would effectively treat the GNU family licenses
>>> differently, and also makes it so the identifiers always indicate
>>> “only” or “any later version”.
>> 
>> I think the CDDL family is, like the GPL family, compatible with
>> both + and only [1].  I'm not excited about special-casing the GPL.
> 
> And a stronger agrument against this is that you cannot extend it to
> cover the PROXY case [1].  We're punting on that for now, but I think
> we need to stick with:
> 
> * a license identifier for the license and
> * versioning operators to produce the grants.
> 
> if we want to address the PROXY case later.

good point - it is more extensible all around.

> 
> Cheers,
> Trvor
> 
> [1]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002110.html
> Subject: Re: joint call legal/tech team - Tuesday, Aug 8
> Date: Fri, 04 Aug 2017 17:03:26 -0700
> Message-ID: <20170805000326.gw23...@valgrind.tremily.us>
> 
> -- 
> 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

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

Re: only/or later and the goals of SPDX

[W. Trevor King]

On Tue, Nov 07, 2017 at 10:19:31AM +0100, Philippe Ombredanne wrote:
> I think that whatever is done on the SPDX side to be
> precise vs. being accurate-enough and good-enough will unlikely ever
> be adopted as the magnitude of the education and changes required
> would be immense…

Backwards compat is certainly important, and the plan with a new ONLY
operator would be to have tooling warn, but not error, on ambiguous
declarations like ‘GPL-2.0’ for the next few years [1].  Then when
SPDX cuts a 3.0, we'd start erroring on ‘GPL-2.0’ and only support
‘GPL-2.0+’ or ‘GPL-2.0 ONLY’.  And depending on how the rest of this
works out, ‘GPL-2.0 AMBIGUOUS’ or ‘GPL-2.0 OR-MAYBE GPL-2.0+’.

Being able to warn/error on ambiguously versioned declarations is why
I want to compatibleWith… metadata.

And to keep supporting folks who will never update their declarations,
we just need to version the license-expression-consuming fields.  For
example, we could explicitly make ‘SPDX-License-Identifier’ [2] mean
“a 2.x SPDX license expression” and create a new field
(SPDX-License-Identifier-3?) for “a 3.x SPDX license expression”.

External consumers could do the same thing.  For example, npm's
package.json is already explicitly an SPDX 2.0 license expression [3].
That means they only have access to the 2.0 license list (2015-04
[4]), not SPDX 2.1's 2.5 license list (2016-07 [5]).  Which means they
cannot use 0BSD or other identifiers which were added between list 2.0
and list 2.5.  If/when the npm community wants to explicitly support
those newer expressions, they can bump their supported SPDX version.
And it will be up to them whether they decide to do that with a new
field or whether they'd rather change the semantics of their existing
field.  [3] discusses a previous ‘licenses’ which had different
semantics, so they've used the new-field approach in the past.

> … for minuscule benefits…

I think the FSF has a reasonable point that ‘GPL-2.0’ by itself isn't
immediately obvious to folks who don't bother to look it up in the
spec.  If they do look it up, they can see that we intend it to be
‘GPL-2.0 ONLY’.  But in 2015, you guessed it to be ‘GPL-2.0+’ [6].
Suggesting (and, in a few years and/or with SPDX 3.0, requiring) an
explicit versioning operator will make the semantics much more clear
to casual readers.  I think that's a more-than-miniscule benefit.

> … and hyper confusion.

Can you go into more details about the confusion you expect?  There
will certainly be a maintenance *cost*, as current ‘GPL-2.0’ users
update their strings to use the new ONLY operator (or another
versioning operator, if they hadn't realized that ‘GPL-2.0’ meant
‘GPL-2.0 ONLY’).  But I don't see a new source of confusion.

Cheers,
Trevor

[1]: https://wiki.spdx.org/view/Technical_Team/Minutes/2017-08-07
[2]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b
[3]: https://docs.npmjs.com/files/package.json#license
[4]: https://spdx.org/sites/cpstandard/files/pages/files/spdx-2.0.pdf#page=64
[5]: https://spdx.org/spdx-specification-21-web-version#h.1jlao46
[6]: https://lists.spdx.org/pipermail/spdx-legal/2015-November/001537.html
 Subject: Is "+" a valid character of a LicenseRef idstring?
 Date: Mon Nov 2 09:56:47 UTC 2015

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


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: only/or later and the goals of SPDX

[J Lovejoy]

Hi John, all,

Finally getting back to this important issue after 3 weeks of traveling.  As we 
have made some progress with preparations for the next release otherwise, I’m 
keen to try and sort out the final issues here, so we can include the resulting 
changes in this release as well.  As it’s been some time, here is a link to my 
original summary to which others responded: 
https://lists.spdx.org/pipermail/spdx-legal/2017-October/002258.html 


As to deprecating the plain identifier - functionally, the only way to do this 
- that I can see - is to have the “only” and “any later version” options 
hard-coded into the license list for the GNU licenses, as they used to be, that 
is:
- the current GPL-2.0 (which means “only) would be changed to GPL-2.0-only
- GPL-2.0+ which is currently created by using the + operator, would be added 
back to the license list as a separate line item.
I think we had discussed this prior, but the issue of losing the + operator to 
be used with other licenses could cause other problems.  What did not occur to 
me, nor did we discuss, was the idea of doing the above for the GNU family of 
licenses, but also keeping the + operator to be used with other licenses. This 
would effectively treat the GNU family licenses differently, and also makes it 
so the identifiers always indicate “only” or “any later version”.

As John notes below, the issue that seems to be preventing us from reaching a 
solution is the example of finding a copy of the license text and how to 
identify that accurately. At the file level, by way of example:
- COPYING.txt (text of GPL, version 2)
- source1.c (no license info)
- source2.c (no license info)
- source3.c (no license info)

In this case, I think everyone agrees that a scanning or human when identifying 
the “license info in file” (just the facts, no conclusions/interpretations) 
would use NOASSERTION for source1.c, source2.c, source3.c

The question we’ve been debating is how to identify the “license info in file” 
for the COPYING.txt file - to this end, I had asked the FSF whether the license 
alone has a default value of GPL-2.0-only or GPL-2.0+ (using the starting point 
of GPL-2.0 because the actual license text of GPL, version 2 is present and 
identifiable. 

One of the concepts I seem to hear from John’s post below and others is that 
the lack of any license notice in the files means those files are not licensed 
at all. This is not what a court would find. Consider how software in its 
common forms besides open source software specifically - I download a binary 
software blob that has a license accompanying it in some way (e.g., a click 
through or a license placed with the software, etc.) Just because the license 
information or a license notice is not in the actual “file” does not mean there 
is no license.  Likewise, in the example of above - if I found those files in 
one repository and the repository owner tried to later sue me for infringement 
based on the theory that the lack of license notice in each file meant I had no 
license to use the files even though a license was provided in the obvious 
place that licenses are provided - that argument would not hold legal water for 
a number reasons. 

If the FSF, as the license authors and stewards, stated that a “bare” license 
defaults to “only” or “any later” version of the license provided - which I 
think the FSF is entitled to do - then we could reflect that with the 
appropriate identifiers along the lines of my idea above - could we not?

But, if the FSF would rather not do so and then we need a way to specifically 
indicate “the license text was found in this file” - then I don’t understand 
why the plain identifier as per the proposal is problematic. Sorry John! I’m 
not trying to be difficult, but the plain identifier is needed to be able to 
add operators to it (“only”, “+” or anything else we might come up with) so I 
don’t see how we can completely deprecate it unless we “hard code” the “only” 
and “later version” options (as I suggested above).  Also, the plain identifier 
use in this case would be consistent with how every other license identifier is 
used: if I find a copy of MIT - be it in a LICENSE.txt file or sourceN.c file - 
it is identified as MIT, as the text of that license. 

I think the thing that makes the GNU family of licenses different from other 
licenses or potentially ambiguous in the case above is NOT what was found (the 
license text of a specific license was found), nor even what version of the 
license text was found, but the absence of specific additional statement 
explicitly.

not sure if this helps, but at least getting the conversation going again!  I 
think Trevor has a response with further info, which I’ll respond to in turn as 
well.


Thanks,
Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com


> On Oct 12, 2017, at 8:44 AM, John Sullivan  wrote:
> 
> Hi 

Re: only/or later and the goals of SPDX

[W. Trevor King]

On Thu, Oct 12, 2017 at 10:44:54AM -0400, John Sullivan wrote:
> I understand SPDX doesn't want to make legal judgments.  Which is
> why it should indicate when there is uncertainty.

While SPDX should avoid making legal judgements, I don't think it
necessarily follows that they need to enable others to avoid making
legal judgements.  Concluded licenses are really all about legal
judgements, and I think everyone agrees we want SPDX to continue to
specify ways to declare license conclusions [1,…].

> Situations like "found a copy of the license but not clear licensing
> statement" should be flagged as things to be fixed, if SPDX wants to
> achieve its goal of successfully communicating reliable license
> information.

And you can already do that in an SPDX document via
PackageLicenseComments [2] and similar.  What you can't do at the
moment is declare a partial conclusion in a structured way.

> We haven't changed our mind about what we do and don't support here;
> and I think we'd be open to other ways to indicate
> ambiguity/uncertainty, including possibly using NOASSERTION.

Allowing this in general license expressions [3] (vs. the current
special case in places where license expressions are used [1]) may be
a reasonable pivot.  Although note that license-expression consumers
don't always agree on the meaning of NOASSERTION [1,4].  In most
situations you can achieve effectively the same results as NOASSERTION
by just refusing to provide a license-expression.

> Can we get a list of all of the options on the table for dealing
> with the case of "found a copy of the GPLv2, but no licensing
> statement anywhere"?

a. Add an ‘ONLY’ operator, remove ‘only’ from GPL-2.0, etc. names,
   clarify that the absence of a versioning operator means that
   versioning was not explicitly addressed in the license grant [5].
   This would allow for ‘GPL-2.0+’, ‘GPL-2.0 ONLY’, and ‘GPL-2.0’,
   etc.

   a. Also add operator-compatibility metadata to each license, so
  tooling can tell if the lack of a versioning operator is a sign
  of an ambiguous grant (e.g. a bare ‘GPL-2.0’) or nonsense grant
  (e.g. ‘NPL-1.0 ONLYy’) [6].

   b. Also add an ‘AMBIGUOUS’ operator [7] so license-expression
  authors can mark in an obvious-to-casual-readers way that they
  were not comfortable making an unambiguous conclusion
  (e.g. ‘GPL-2.0 AMBIGUOUS’).  Or maybe 

   c. Also add an ‘OR-MAYBE’ operator so license-expression authors
  can mark in an obvious-to-casual-readers way the set of license
  expressions that are still in the running for their conclusion
  [8], even though they haven't narrowed that down enough to pick
  a single one (e.g. ‘GPL-2.0 ONLY OR-MAYBE GPL-2.0+’).

Mark's called for actual examples where you'd use these [9], so here
are some:

* Linux's block/bio.c is [10,11]:

GPL-2.0 ONLY WITH Linux-syscall-note

* public-inbox is [12]:

AGPL-3.0+ WITH LicenseRef-OpenSSL-linking-permission

* javierwilson/tonto is [13] (with just (a)):

GPL-3.0

  or with (a.b):

GPL-3.0 AMBIGUOUS

  or with (a.c):

GPL-3.0 ONLY OR-MAYBE GPL-3.0+

I don't hear anyone arguing against (a), excepting from a
backwards-compat standpoint.  And I think folks were on-board with
(a.a) and tooling that allowed folks to keep using ‘GPL-2.0’ with
“ambiguous version” warnings for a year or two, followed by errors in
strict parsers after the deprecation period ends

(a.c) seems more clear and more powerful than (a.b), but I haven't
heard much discussion comparing the two.  And while (a) alone is
sufficient to express these partial conclusions, without at least one
of the sub-options it's very hard to tell from the license expression
alone whether a missing version operator was an intentional statement
of ambiguity or an accidental mistake.  (a.a) allows tooling to warn
about such cases, which may make mistakes less likely.  And (a.b) or
(a.c) will allow the careful to type in some extra characters, making
both mistaken-writes and casual-read-misunderstandings less likely.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.ihv636
[2]: https://spdx.org/spdx-specification-21-web-version#h.41mghml
[3]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
[4]: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys
[5]: 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Proposed_Solution:_add_only_operator
[6]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html

 
 Subject: Re: minutes, summary, next steps  

 
 Date: Thu, 17 Aug 2017 14:37:22 -0700  

 
 Message-ID: 

RE: only/or later and the goals of SPDX

[Wheeler, David A]

John Sullivan:
> A key part is missing in the description of the original FSF proposal here
> though -- which is deprecating the existing GPL-2.0 and similar "plain"
> identifiers for GNU licenses so that the identifiers used always indicate
> whether the version is "only" or "any later".
>
> As I understand it, people had concerns with deprecating the plain
> identifiers because of situations where they (for example) find a copy of
> GPLv2, but no clear statement about whether the program is actually
> licensed under its terms.

Not exactly.  In many cases it's clearly licensed under GPLv2.
The issue is that often we don't know if "or any later version" applies.

> To address this, we suggested still deprecating the plain identifier but
> adding an ambiguous/unclear identifier that still indicates a copy of the GPL
> was found but does not mislead observers into thinking that there are
> sufficiently clear licensing statements along with it.

The proposal, as I understand it, is these license expressions have the 
following meanings:
1. GPL-2.0 ONLY : GPL version 2.0 only.
2. GPL-2.0+ : GPL version 2 or any later version
3. GPL-2.0 : At least GPL version 2.0 applies. It may or may not be "or any 
later version".  In practice, this is all most tools can report, because all 
they can report is the presence of this license file (there may not *be* any 
other information).

It'd be possible to report case #3 in other ways, e.g.:
* GPL-2.0 OR MAYBE GPL-2.0+
* GPL-2.0?
* GPL-2.0 AT LEAST
I *do* think it would be very odd to deprecate the license identifier 
"GPL-2.0", especially since this license is in such active use AND is a basis 
for many license expressions.  The proposal has the advantage that it 
acknowledges reality - when people or tools report "GPL-2.0", in practice we 
don't really know if "or later" applies (the SPDX spec, versus practice, 
sometimes diverge on this point).

> I understand SPDX doesn't want to make legal judgments. Which is why it
> should indicate when there is uncertainty.

I agree that SPDX should *not* require people and tools to make *false* claims. 
 So we need a way to not *force* people to make claims they don't believe.  
Interpreting "GPL-2.0" as "GPL version 2 at least, not sure if it 'or later' 
applies" seems like it gets there for the case under discussion.  I'd be happy 
with other solutions too.

...
> We haven't changed our mind about what we do and don't support here;
> and I think we'd be open to other ways to indicate ambiguity/uncertainty,
> including possibly using NOASSERTION.

I disagree with using NOASSERTION in this case; that loses important 
information.  99% of the time, knowing that it's licensed under the GPL version 
2 at least is *more* than good enough.  There are cases where I care, of course 
(e.g., if I'm linking it with Apache 2.0 licensed software).  But every legal 
analysis costs time & money; people only want to invest where they *must* do 
so.  If tools can report "I know GPL-2.0 at least is okay, and later versions 
might be okay", that'd be best.

I do agree that it'd be great if projects would provide better licensing 
information.  But I'm currently trying to convince people to add licensing 
statements at *all*, due in part to complete obliviousness.  Adding license 
files of *any* kind is a win right now.  Given that starting point, we should 
not expect perfect licenses any time soon :-).

Thanks for your time!

--- David A. Wheeler
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: only/or later and the goals of SPDX

[John Sullivan]

Hi Jilayne,

Thanks for writing this up.

A key part is missing in the description of the original FSF proposal
here though -- which is deprecating the existing GPL-2.0 and similar
"plain" identifiers for GNU licenses so that the identifiers used always
indicate whether the version is "only" or "any later". 

As I understand it, people had concerns with deprecating the plain
identifiers because of situations where they (for example) find a copy
of GPLv2, but no clear statement about whether the program is actually
licensed under its terms.

To address this, we suggested still deprecating the plain identifier but
adding an ambiguous/unclear identifier that still indicates a copy of
the GPL was found but does not mislead observers into thinking that
there are sufficiently clear licensing statements along with it.

I understand SPDX doesn't want to make legal judgments. Which is why it
should indicate when there is uncertainty. Situations like "found a copy
of the license but not clear licensing statement" should be flagged as
things to be fixed, if SPDX wants to achieve its goal of successfully
communicating reliable license information. Sure, determining when there
is uncertainty could be described as a legal judgment. So is acting as
though there is certainty. Some level of that is both unavoidable and
necessary. 

We haven't changed our mind about what we do and don't support here; and
I think we'd be open to other ways to indicate ambiguity/uncertainty,
including possibly using NOASSERTION.

Can we get a list of all of the options on the table for dealing with
the case of "found a copy of the GPLv2, but no licensing statement
anywhere"?

-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
.
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: only/or later and the goals of SPDX

[Gisi, Mark]

Hi Jilayne,

It would be helpful to provide actual source code examples of where the 
proposed operator would be applicable. This was done for each operator included 
in the first release of the license expression language which was very 
productive:
https://wiki.spdx.org/view/FileNoticeExamples
The examples would facilitate a healthy discussion while providing 
creditability to the final decision. We need to avoid using theoretical 
examples that have led to confusion in past discussions around how a proposed 
operator might be applied.

- Mark


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Wednesday, October 11, 2017 10:14 PM
To: SPDX-legal
Subject: only/or later and the goals of SPDX

Hi all,

I was reviewing the notes from our last call and discussion as to the “only/or 
later/unclear operators and GNU licenses and still have not posted them as it 
was hard to take notes that make sense to read later when there is that much 
discussion!  I’ll try to get some kind of summary up soon.

More importantly, I had to take a step back and think about why this had become 
so challenging, where we are, and how to move forward.  I found it helpful to 
recap some key principles as well as some things that have become clear to me 
based on the various discussion we’ve had on the topic:

1) Back to first principles! The mission of SPDX overall is:
Develop and promote adoption of a specification to enable any party 
in a software supply chain, from the original author to the final end user, to 
accurately communicate the licensing information for any piece of copyrightable 
material that such party may create, alter, combine, pass on, or receive, and 
to make such information available in a consistent, understandable, and 
re-usable fashion, with the aim of facilitating license and other policy 
compliance.
The purpose of the SPDX License List is to enable easy and 
efficient identification of such licenses and exceptions in an SPDX document 
(or elsewhere).
Also - SPDX does not make legal interpretations.

2) FSF ask: I believe the main issue is that the FSF does not like that 
“GPL-2.0” as a license identifier currently means GPLv2-only and would prefer 
something more explicit. We agreed that to moving to the use of "GPL-2.0-only" 
(or similar). I don’t think anyone has an issue with this part as it provides 
clarity for identifying when the “this version only” option is exercised.

3) The challenges we encountered: We ran into the issue of when it is not clear 
if the licensor meant “this version only” or “or any later version” (e.g. the 
Github scenario, as I call it) and how to deal with that, especially where just 
the license text is found, but no license notices. We also did an analysis of 
other licenses with “or later” or like options.

4) The proposal: As a result of those discussions, we came up with the proposal 
to add an “only” operator, as described here: 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Proposed_Solution:_add_only_operator
 and where the bare license identifier would signify the license text itself. I 
believe everyone was on board with this as the best option available.

We went back to the drawing board after I got a message that the FSF was not 
satisfied with this proposal and consequently we came up with a different 
proposal that included an “ambiguous/?” operator.

But this missed a key part of the core goals of SPDX:  Implicit in those above 
goals is that the SPDX License List (including the license short identifiers 
and the license expression language) aim to provide a “language” to identify 
what we know, what we find - not what we don’t know or find. Having some kind 
of “ambiguous” operator (however we might decide to express that) is 
incongruent with this and the goals of SPDX. The original proposal as we came 
up with allows for an accurate description of what is found, including in the 
case of finding only the text of a license.

So, I’d like to bring everyone attention back to the original proposal (see 
link above) and if there are any further concerns about it, now is the time to 
raise them.  Meanwhile, Kate and I will follow-up with John and Richard at the 
FSF to better understand their concerns as well.

Finally, my apologies for not being a stronger leader here in keeping our ship 
upright with the goals of SPDX; I hope people don’t feel that we have wasted 
(too much) time as a result.

Thanks,
Jilayne


SPDX Legal Team co-lead
opensou...@jilayne.com

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

Re: only/or later and the goals of SPDX

[W. Trevor King]

On Wed, Oct 11, 2017 at 11:13:56PM -0600, J Lovejoy wrote:
> But this missed a key part of the core goals of SPDX: Implicit in
> those above goals is that the SPDX License List (including the
> license short identifiers and the license expression language) aim
> to provide a “language” to identify what we know, what we find - not
> what we don’t know or find. Having some kind of “ambiguous” operator
> (however we might decide to express that) is incongruent with this
> and the goals of SPDX. The original proposal as we came up with
> allows for an accurate description of what is found, including in
> the case of finding only the text of a license.

This may be cutting it to cleanly.  For full SPDX documents, there are
comment fields (e.g. PackageLicenseComments [1]) for motivating your
concluded license.  I think that motivation is especially important
when you're stretching a bit to bridge a gap between a declared
license (or lack thereof) and your conclusion.  That all works fine in
SPDX documents, and I think we want to keep allowing SPDX authors to
explicitly say “this situation was confusing, but I've eventually
decided that the license is … based on …”.  And for the really hairy
situations, you can always bail to NOASSERTION [2], folks can still
read about your partial conclusion in the comments.

The ambiguous operator (first floated as “unclear version” in [3]) and
my OR-MAYBE proposal [4] are both attempts to allow an SPDX License
Expression authors to handle those situations they consider too
ambiguous for a complete conclusion, but where they can provide more
structure than NOASSERTION.  The ambiguous and OR-MAYBE operators are
both providing a way to express partial conclusions *without* recourse
to a full SPDX document and its unstructured comment fields.  This may
be useful in general, and David has said he would be satisfied with:

  GPL-2.0 OR-MAYBE GPL-2.0+

most of the time [5].  I still don't have anyone stepping up to say
they'll produce such expressions though [6], and I doubt its worth
writing up a spec for it without someone saying “I (or my tool) wants
to write partially-concluded license expressions but there's no syntax
for it”.  But “nobody has told us they'd write this yet” is a much
narrower rejection than “the proposals are incongruent with the goals
of SPDX”.

> So, I’d like to bring everyone attention back to the original
> proposal (see link above) and if there are any further concerns
> about it, now is the time to raise them.  Meanwhile, Kate and I will
> follow-up with John and Richard at the FSF to better understand
> their concerns as well.

I'm on board with that proposal (especially if it includes the
compatibility metadata mentioned on the wiki page and earlier on this
list in [7]).  And I think it can move ahead independently of any
ambiguous, OR-MAYBE, or PROXY [8] operators.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.41mghml
[2]: https://spdx.org/spdx-specification-21-web-version#h.ihv636
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002230.html
 Subject: reminder: call Thursday
 Date: Wed, 27 Sep 2017 16:49:46 -0600
 Message-Id: <9216ca28-7f42-452a-913f-8bcc0cfe1...@jilayne.com>
[4]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002233.html
 Subject: "unclear version" and OR-MAYBE operators (was: reminder: call 
Thursday)
 Date: Wed, 27 Sep 2017 22:15:23 -0700
 Message-ID: <20170928051523.gn20...@valgrind.tremily.us>
[5]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002235.html
 Subject: RE: "unclear version" and OR-MAYBE operators (was: reminder: call 
Thursday)
 Date: Thu, 28 Sep 2017 16:43:46 +
 Message-ID: <33f120c1096a4cada022389754cd4...@exch13-m1.ida.org>
[6]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002238.html
 Subject: Re: "unclear version" and OR-MAYBE operators
 Date: Thu, 28 Sep 2017 11:22:27 -0700
 Message-ID: <20170928182227.gp20...@valgrind.tremily.us>
[7]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html

 
 Subject: Re: minutes, summary, next steps  

 
 Date: Thu, 17 Aug 2017 14:37:22 -0700  

 
 Message-ID: <20170817213722.gk23...@valgrind.tremily.us>   

 
[8]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002110.html
 Subject: Re: joint call legal/tech team - Tuesday, Aug 8