On Sat, Mar 25, 2017 at 04:25:38PM +0100, Guillem Jover wrote: > Hi! Thanks for your feedback! Been a while since we've chatted. :)
> On Fri, 2017-03-24 at 14:02:49 -0400, G. Branden Robinson wrote: > > In returning my attention to current Debian packaging practices and > > conventions I took my first serious look at good old DEP5, and brought > > the debian/copyright file for my first-ever package, xtrs[1], into > > conformance with the new[2] standard[3]. > > > > However, in doing so, I encountered some use cases that are not covered > > by this standard. Happily, all of them triggered lintian warnings as > > well, which gives me a framework within which to present my problems. > > > > The attached debian/copyright file may also illuminate these matters. > > I think all your concerns are already mostly covered by the spec, > except notably for the license namespacing. Thanks! I did completely overlook the section "Stand-alone License Paragraph", which you brought to my attention through your patches. However, I still think the copyright file specification could be clearer with respect to what is deliberately left unspecified, rather than leaving it implicit. > Something that is also a common source of confusion, is that because > it specifies a Files field, it seems it compels people to do very > fine-grained splitting. Personally I have no issue with coalescing > copyright notices, as long as they are all for the same license, etc. > I even coalesce copyright years for the same owner. See for example > the libbsd copyright file, being more fine-grained would be madness > IMO. And it is my understanding that ftpmasters find this to be fine. I agree that this is a maintainer discretion issue; perhaps ultimately an ftpmaster discretion issue, at least at the lower bound of precision. That such discretion is available to the maintainer should be made more clear by the spec. If we said this clearly, you might find fewer people picking nits below your threshold of attention-worthiness. xtrs is small enough that I could go atomic on it without much effort; it's only 24k lines in 37 *.[ch] files. I once did a license enumeration deep dive on glibc that surprised me. Packages that are large and old (like glibc) or in languages that encourage rampant cut-and-paste of source snippets (JavaScript) make exhaustive analysis more challenging, and I would not mandate that my peers undertake such without good reason, such as a hostile copyright holder. > So instead of going over all your fine points, I've taken the liberty > instead to fix the copyright file in what I'd consider to be correctly > formatted; in two ways, first following the original spirit, of very > detailed listing, and then another condensed one which is what I'd > have done. They are incremental patches over your original one. I was a little confused by this because your first diff is against the xtrs debian/copyright file currently in the archive. I.e., it's against xtrs 4.9c, not the one for 4.9d which I attached in my mail. I don't see much to distinguish our approaches: 1. You use forward references to license short names; my preference would be to use backward references. 2. You put nothing on the first line of a multi-line Files field; I do. But I'll change that. 3. You don't use bracket notation in your globs. Re-reading the copyright format doc, I see I'm out of spec on this. I'll fix that. 4. You (in your condensed form) always put the contents of the Copyright field on the subsequent line, even if it would fit on the first. 5. You place importance on the varying renditions of the copyright sign ( (c), ©, etc.); I don't. My lay understanding of U.S. copyright law and the various international treaties on the subject is that copyright notices do not require any particular rendition of this symbol to be effective. Either of the foregoing, or "(C)" or the word "copyright" in any case rendition is adequate, even leaving aside the implicit copyright that attaches to any copyright-eligible work that goes into "fixed form", as which a text file surely qualifies. But I'm not quite ready to wade back into debian-legal yet... I don't find any of the foregoing to be hills worth dying on; certainly not #3, where I am surrendering the field. ;-) I'm attaching my latest revision of debian/copyright based on your guidance. It still reflects a degree of wild card phobia, but that's mainly because I had already done the work to categorize things. My file (and the whole package, for that matter) is lintian-clean now--thank you! In my view, two questions remain: A. Does the debian/copyright file format spec require an update to improve clarity and guidance? My opinion is that it does. What do other folks on the list think? B. What shall we do about the namespace problem? I'm inclined to start a new thread on that. Regards, Branden [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
