Bug#883950: Next steps on "[GPL-3+]" proposal
Hi Russ,
> > 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.
This is certainly true for validating parsers, which will need modification to
stop them complaining about the missing standalone License stanza; that's a
relatively simple modification to not complain if the licence key is within
the predefined list from /usr/share/common-licenses. Validating parsers we
have in the archive are lintian and cme; non-validating parsers such as
debian.copyright from python-debian and that in sources.debian.org require no
modification.
copyright-format/1.0 disallows misuse of licence tokens to point at things
that are not *exactly* the well-known licence and consequently, there is no
useful licensing information in the standalone License paragraph. I would
therefore expect that consumers of these data (they are not in the archive)
use these defined licence keys in the Files paragraph as a stop point of the
analysis in any case, so this change would be a noop for them too.
> 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
[... lots of other good reasons to contemplate copyright-format/2.0...]
I'm quite happy to accept this proposal (without the brackets) as a single
change. It's minimal work for the parser and is an incremental improvement to
the format; because it relaxes a requirement, we could even view it as
backwards compatible and not increment the version (although that has
potential for confusion in the output of validating parsers).
Alternatively, with a queue of potential improvements, I'm also happy with the
idea of taking a longer period to iterate on the design of the format and make
several (smallish) backwards incompatible changes all at once rather than
users and consumers of the format receiving on-going papercuts.
(The brackets, however, remain unnecessary.)
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: