Sean Whitton <spwhit...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
