Bug#883950: Next steps on "[GPL-3+]" proposal

[Russ Allbery <rra@debian.org>]

Sean Whitton <spwhitton@spwhitton.name> writes:

> We now know that we can go ahead with the main proposal to introduce the
> "[GPL-3+]" notation into our machine-readable copyright format.

I'm going to reiterate my objection to the brackets.  I'm opposed to
introducing this new syntax; I believe it serves no purpose.

A set of files under the license GPL-3+ and [GPL-3+] are under exactly the
same license, so it is confusing and strange to use different identifiers
based on a technical point about what information is included elsewhere in
the copyright file.  Furthermore, the brackets are entirely opaque.  They
convey no meaning to a person who hasn't read the specification, which
seems inappropriate for a specification that's supposed to still be
human-readable.

I understand the intent here is to provide some signal that there will not
be any stand-alone License paragraph elsewhere in copyright, but this
still doesn't provide backward-compatibility and will still break parsers
because they will need to add support for this bracket syntax and will
otherwise expect a standalone license paragraph for [GPL-3+].

Given that, I think the right way forward here is to bump the version to
1.1 or 2.0 and introduce a new field, maybe License-Identifier following
the very similar SPDX-License-Identifier field, that is defined to contain
only the short license identifiers and will not include supporting
information about the license.  And then, in Policy proper, specify that
the License-Identifier field in 1.1/2.0 copyright-format files can only be
used for licenses in common-licenses.

Yes, it's a little irritating to introduce a new version of the
specification and a new field, and some tools will break and need to be
fixed, but I think anything else is too ugly of a hack, and has
backward-compatibility issues.

> 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 '+'.)

I personally think it's reasonable to expect people to be able to read the
copyright-format specification for information like this, but I respect
the concern here.

My preference there would be to add a README file to
/usr/share/common-licenses that explains this syntax.  This is simple and
I think uncontroversial, but there's some concern that it will be too hard
to find and people won't know to look there.  I think that concern could
be addressed by also referencing this in /etc/motd and in the Debian
Release Notes.

Remember, we're already talking about the people who cannot easily follow
the URL at the top of the file specifying the format, which will explain
all of this.  That's already a small portion of our users.  They also need
to be users who care about this specific feature of the licenses.  I think
that if you care about licenses in Debian, you're likely to know about or
be able to find /usr/share/common-licenses one way or another, at which
point you'll see the README and all of this will become clear.  Or you'll
have some way of asking someone else.  This syntax is also common with
SPDX, so it's going to be (hopefully) increasingly familiar.  And, more
broadly, most people who are familiar with the GPL and the details about
how it's applied to packages are familiar with the "or latest version"
concept and will be able to make a reasonable conceptual leap about what
the "+" might mean.

There may still be a tiny number of users who fall through those cracks,
but I think it would be very, very few.

> I suggested shipping the copyright format in base-files and referring to
> it using the Format: header.  Joerg thinks that a shorter/smaller hint
> would be adequate and better than "duplicating" the copyright format --
> though do note that we might be able to find a way to ship it that
> avoids any inconvenient duplication.

I'm not a huge fan of shipping a copy of the specification because it
requires coordinating updates with base-files or adding some portion of
Policy to the essential set, both of which aren't horribly appealing to
me.  And it feels like overkill, since most of the content isn't that
important.

If we *really* want a more explicit pointer than the Release Notes and
/etc/motd, my preference would be to add a second required field in
copyright-format 1.1 (which I think we need anyway for the reasons stated
above) that points to /usr/share/common-licenses/README.  Perhaps a
"Distribution-Conventions" or some similar field whose definition is
a pointer to a file with supplemental information about how licenses are
handled in that distribution.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>