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: <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 +0000
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
