Bug#883950: Next steps on "[GPL-3+]" proposal
Hi Sean,
On Friday, 29 December 2017 09:18:51 AEDT Sean Whitton wrote:
[...]
> We now know that we can go ahead with the main proposal to introduce the
> "[GPL-3+]" notation into our machine-readable copyright format.
My personal preference is for debian/copyright to record the facts Debian is
required to know rather than an increasingly verbose dosier of evidence that
supports those facts; that has a nice benefit of people spending less time
copying and reformatting text. I think there is merit in persuing this.
That said, I find the proposal that we should use "[GPL-3+]" (#883950) and the
proposal that a "License-Grant" field be added (#786470) to be largely
contradictory. I think accepting (or even pursuing) one should mean killing
the other:
* The "License-Grant" proposal is seeking to find a place in the copyright
file for yet more boilerplate so that we can record what is claimed to be very
important information that we should not be omitting ("This program is free
software; …").
* The "[GPL-3+] proposal" is seeking to remove what is claimed to be
completely unimportant boilerplate, including the licence grant text and more
("On Debian systems, …").
Recent discussions on other mailng lists have demonstrated that we don't
really know what we want from d/copyright and I guess these two contradictory
proposals illustrate that further.
> However, we still need to decide how we are going to hint to the local
> admin that "GPL-3+" means "GPL version 3 or any later version at your
> option". (The purpose is to keep the machine-readable copyright format
> basically readable without reference to the copy of the spec on the
> Debian web mirrors. So it's not the square brackets that we need to
> hint about. It's the '+'.)
Apart from /u/s/common-licenses/README, perhaps documenting the meaning of "+"
is as simple as adding /usr/share/common-licenses to /etc/motd since that is
what we already use that to point users to the existence of /usr/share/*/
copyright at present.
While recognising that you're asking about the "+" not the brackets at this
stage, a couple of comments on the format from the perspective of a maintainer
of code that looks at d/copyright.
TL;DR: I'd prefer we didn't use the brackets or bump version numbers, hence
challenging this now before it becomes too entrenched.
* In copyright-format/1.0, the tokens specifying the licences are entirely
opaque with the exception of the + at the end (and then these tokens are
concatenated with and/or/,/with(.*)exception etc). Opaqueness is a handy
property to maintain but is violated by the use of the brackets as [GPL-3+].
* A file with "License: [GPL-3+]" and a file with "License: GPL-3+" are under
the same licence and making it look different is no benefit. For the common
licences we are discussing, the important information is 'which licence', most
readers will already know what the tokens mean and there is no need to do
more; this seem pretty uncontroversial as it is, after all, pretty
foundational to the proposal to remove the "On Debian systems, …" text.
* For the casual reader, the brackets are apparently to signal that one should
look in /usr/share/common-licenses, but how would one know "[…]" meant to do
that in any case if one didn't already know to do that? There is no value in
them for communication to the user. Having accepted people should know to look
in /u/s/d/*/copyright and /u/s/common-licenses, then the brackets are
unneeded.
* For the completeness of the specification, the brackets only relax the
'must' in the last paragraph of §6.7 that says there will be either (a) more
lines of clarification for that licence in the current field or (b) a stand-
alone stanza to go with that licence key. This proposal is just changing that
'must' for a handful of common licences and this proposal could simply turn
into an exception being written into that paragraph. (Noting that the spec
doesn't use must/should as we would often do and that 'otherwise … should' is
really 'otherwise … must').
* If, as I believe, this proposal can be delivered with only a relaxation of
the copyright-format/1.0 requirement on expanding the License field, then it
could be done without incrementing the version number. A version bump gains
nothing for the reader but costs a lot for all the people writing parsers.
Worse, we'll end up with Lintian pestering every single maintainer to do a
useless s/1.0/1.1/.
A final more general comment -- please include the people who write code based
on the copyright-format specification in the discussion of specification
changes and include them early on. (cme, lintian, sources.d.o, python-debian
are the ones that come to mind; there are probably others) People who write
parsers are probably policy wonks who read the list anyway, but it's worth
checking.
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: