Stuart Prescott <stu...@debian.org> writes: > From my perspective, the brackets are only making work for people who > will have to rewrite parsers because the license short names are not the > opaque tokens originally given in copyright-format/1.0.*
To be clear, I don't believe there's a way forward here that doesn't require at least some rewriting of parsers. Currently, copyright-format 1.0 requires either that every License stanza in a Files paragraph contain some "license text" in the copyright-format text (which may just be the common-licenses pointer) or that there be a later stand-alone License paragraph with the same short license identifier that has that text. This proposal breaks that property by introducing the possibility of a short license identifier with no accompanying text. This will require parser changes. The silver lining is that this allows us to fix a long-standing wart in copyright-format in which the License field could take two different forms with complex semantics: either a first line with short license identifiers followed by full license text, or only the first line. The latter indicated an implicit reference to a later license pargraph. We can now define two separate fields: License-Identifier, which contains only the short license identifiers, and License, which contains the short license identifiers plus the license text. Every Files paragraph must then contain *either* a License-Identifier field *or* a License field. A standalone license paragraph can be provided for identifiers given in a License-Identifier field, or may be omitted based on the rules of the distribution. For Debian, we would say that it may be omitted if the lienses in question are in common-licenses. This is not a backward-compatible change, but it's semantically cleaner and cleans up the semantics of the dual-purpose License field. One remaining question in my mind is whether we should take the opportunity of a format change to achieve a few other goals. The most obvious one would be to reconcile our short license identifiers with SPDX (probably by making our identifiers a superset of the SPDX ones). Note that this would introduce the GPL-2-or-later and GPL-3-or-later (and friends) identifiers, which are a bit of a wart in the SPDX list since they're defined to be equivalent to GPL-2+ and GPL-3+, but were requested by the FSF, and could be used to make the meaning of "+" a lot clearer. (It would also mean picking up MIT as a synonym for what we call Expat. We had arguments against that, but I think the argument of convergence with SPDX is stronger.) I haven't checked to see if we have any conflicts with SPDX (license identifiers we define to mean something different than they do). Hopefully not. Anyway, that's just an aside -- SPDX convergence will be a separate bug and discussion if we decided to go down that path. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
