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/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
