Re: Unaddressed use cases for machine-readable debian/copyright files
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/
Reply to: