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   

  
 Date:

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

[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

[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

[W. Trevor King]

   

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

 
[7]: 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> 

 
[8]: 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>   
                        
 
[9]: https://lists.spdx.org/pipermail/spdx-legal/2017-October/002260.html
 Subject: RE: only/or later and the goals of SPDX
 Date: Thu, 12 Oct 2017 07:25:06 +
 Message-ID: 
<01813e194c768044a6486db30b5338cc0112836...@ala-mbc.corp.ad.wrs.com>
[10]: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/block/bio.c?h=v4.13.6#n4
[11]: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-07-06
[12]: https://public-inbox.org/README.html
[13]: 
https://github.com/javierwilson/tonto/tree/75be0678be565872cbe7b99d5af4a1946393ee77

-- 
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 Jilayne,
> 
> T

Re: only/or later and the goals of SPDX

[J Lovejoy]

gt;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: <20170817213722.gk23...@valgrind.tremily.us>  
>   
> 
> [7]: 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>
>   
> 
> [8]: 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>  
>   
> 
> [9]: https://lists.spdx.org/pipermail/spdx-legal/2017-October/002260.html
> Subject: RE: only/or later and the goals of SPDX
> Date: Thu, 12 Oct 2017 07:25:06 +
> Message-ID: 
> <01813e194c768044a6486db30b5338cc0112836...@ala-mbc.corp.ad.wrs.com>
> [10]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/block/bio.c?h=v4.13.6#n4
> [11]: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-07-06
> [12]: https://public-inbox.org/README.html
> [13]: 
> https://github.com/javierwilson/tonto/tree/75be0678be565872cbe7b99d5af4a1946393ee77
> 
> -- 
> 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

___
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 Mon, Nov 06, 2017 at 09:22:50PM -0700, J Lovejoy wrote:
> > On Oct 12, 2017, at 11:31 AM, W. Trevor King  wrote:
> >   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].
>
> JL: I’m not sure what this means, or specifically how we would do
> this - are you suggesting we go through the entire license list and
> add some kind of info that indicates whether, for example, the
> “only” or “+” operators should be used?

Yup.  There aren't all that many of them, and we've mostly collected
the list already [1].  For the GPL-3, which supports both, I expect
something like:

  $ cat src/GPL-3.0.xml
  
  http://www.spdx.org/license";>
 
   …
 
  

Or instead of separate compatibleWith* attributes, you could have a
single:

  compatibleWith="+ only"

I'm fine either way.
 
> >   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
>
> JL: this idea still makes me really squeamish: if I saw “GPL-2.0
> AMBIGUOUS” what would I think?  I don’t think this would be clear at
> all as to the meaning and could potentially cause more confusion. I
> think we are all aiming to avoid that! Plus, it’s not ambiguous that
> GPL, version 2 exists, it’s only unclear as to if the copyright
> holder meant to indicate only version 2 or any later version - it’s
> a narrow kind of ambiguity… which brings to c:

Yes, I'm personally much happier with (c) than with (b).  I only
listed (b) because it's been proposed before, and it would narrowly
solve the “I'm not comfortable applying a versioning operator here,
but this license needs one for an unambiguous grant”.

> >   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+’).
>
> JL: this seems better than b , but I’m not sure how this is
> significantly different than simply: GPL-2.0 ONLY OR GPL-2.0+ ? It’s
> one of the other, isn’t it?

OR means “I understand exactly what the licensor wants.  You, the
downstream consumer, are allowed to use this content under either of
these licenses”.  So you could legally use it under the GPL-2.0.  Or
under the GPL-3.0+.  Or under the GPL-3.0.  Etc.

OR-MAYBE means “I couldn't figure out exactly what the licensor wants.
You, the downstream consumer, may be allowed to use this under the
GPL-2.0+.  Or maybe you're only allowed to use the GPL-2.0, and the
author will sue you if you try and use it under the GPL-3.0.”

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

> (this only works if FSF can provide guidance as to the bare license
> default intent of the license, though).

Despite my lack of excitement, I disagree with this point.  You can,
in the absence of a FSF position, still come to your own conclusion on
this case, and I've heard people make cases for GPL-1.0+, GPL-2.0
ONLY, and GPL-2.0+.  With either (b)'s AMBIGUOUS or (c)'s OR-MAYBE,
you can also represent the “I'm not comfortable making a complete
conclusion” sitatuation, while still making it clear that folks who
want to use the GPL-2.0 are going to be pretty safe, because it's
covered by all the possible conclusions.  An official FSF position
just lends more weight to one of those conclusions; you can still
conclude whatever you want to conclude with or without the FSF.
If/when you get a lawsuit, whoever is deciding the case gets to figure
out who's most convincing.

Cheers,
Trevor

[1]: https://wiki.spdx.org/view/Legal_Team/later-version-clauses

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

[W. Trevor King]

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.

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


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

[Philippe Ombredanne]

On Tue, Nov 7, 2017 at 5:06 AM, J Lovejoy  wrote:
> 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”.
[...]
> 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.

Jilayne:
Thank you for the detailed write up and hard work you are pouring into
this!

John and all:
I find this whole discussion quixotic: noble but pointless!
This ship has sailed IMHO long ago and GPL-2.0 means GPL-2.0 and no
later version to most everyone.

This has been the case pre-SPDX in Linux and Linux distros.
This is the case now that we see major adoption of SDPX licenses
identifiers in U-Boot, Linux, Eclipse, NPM, Rubygems and more.
e.g. 100K+ projects, programmers and files are using GPL-2.0 as
meaning GPL-2.0 and only!

FWIW we had a discussion on this in 2015 [1] in the thread
"Is "+" a valid character of a LicenseRef idstring?"

I was then on the side of making this precise and stating that GPL-2.0
meant any later version by default. David Wheeler quite rightly
dismissed my arguments then and I fully agree with him now.

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 for minuscule benefits and hyper confusion.

Furthermore, this futility may hinder SPDX adoption and our less
noble quest to simplify licensing statements in a good enough way.

In recap, I find it futile and pointless and there are zero benefits
for SPDX and zero benefits for the vast majority of programmers.
I am really sorry folks are wasting their time discussing this.
Therefore, I wish we could just stop discussing this distracting topic
as there are so many other more important things to deal with.

[1] https://lists.spdx.org/pipermail/spdx-legal/2015-November/thread.html
-- 
Cordially
Philippe Ombredanne
___
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]

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

[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

[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

[W. Trevor King]

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?

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.

Am I misrepresenting anyone?

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: <33f120c1096a4cada022389754cd4...@exch13-m1.ida.org>

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

> 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: <33f120c1096a4cada022389754cd4...@exch13-m1.ida.org>
> 
> -- 
> T