[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Copyright file granularity



+++ Steve Langasek [2015-11-13 10:51 -0800]:
> On Fri, Nov 13, 2015 at 04:10:14PM +0000, Wookey wrote:
> > I've been helping package a load of stuff recently for Robot OS and in
> > checking the copyright files I've come up aginst the question of exactly
> > how much segmentation there should be in copyright files

...

> Do we need to list all copyright holders?  Yes.  Do we need the copyright to
> be listed at the granularity of individual source files?  No.
> 
> And we should have better tools to generate debian/copyright files - this
> shouldn't be an intensive manual process.  Unfortunately the only tool I'm
> aware of that does this is coupled to cdbs.

I was recently pointed to debmake -cc which does a reasonable job of
searching (only source by default) files and making a draft copyright
file. However it's not perfect by any means, and missed a set of
non-free test files in a package I did recently. (fortunately spotted
by ftmaster review to my embarassment)

Also it's not in stable, only testing, although it builds there
unmodified quite happily.
 
> And if we want the debian/copyright file to be readable afterwards, the
> tools are going to need to make some smart decisions about grouping of
> copyright stanzas, and not just list one for each (license, copyright
> holders, copyright dates) tuple.

debmake -cc does some sensible grouping.
 
> > I just uploaded rosdistro
> > (https://tracker.debian.org/pkg/ros-rosdistro) and got a comment from
> > the reviewing ftpmaster that combining the two different copyright holders
> > for BSD-3-clause files into one stanza was not really right:
> 
> Was this comment from the ftpmaster given as a reason for rejecting an
> upload?

No, it was a 'I'll let this through, but' comment. So no complaint
from me, it just prompted me to actually start this thread for
clarification.

In fact, reading it more carefully, I see that it was actually
referring to the point Maxy made, about slightly modified licences not
to the copyright-holder concatenation itself:

"I marked the package for accept, but strictly speaking you have two BSD-3 
licenses, one with Willow Garage and one with OSR Foundation in clause 4."

> The lack of transparency and accountability around rejects from the NEW
> queue is an unfortunate problem.  Since reject notifications are only sent
> to the uploader, 

I guess public rejects would give us a useful corpus of work to refer
to over time, and would help ftpmasters be collectively consistent.

I should say here that I've been getting _really_ quick (but also very
thorough) reviews of stuff in NEW recently, so kudos to Thorsten
Alteholz.

> > So, after thinking about this for a while I decided that it was not
> > clear to me what best/acceptable practice is, and that it would be
> > best to ask here.
> 
> Thanks for doing so.
> 
> I absolutely agree with your interpretation.  There is no requirement in
> policy that debian/copyright separately detail the copyright statements of
> individual source files; it is perfectly acceptable (legally and under
> policy) to aggregate these, e.g. "these five source files are under this
> license, and are under some combination of copyright by these 10 authors and
> these ranges of years".
> 
> (With the caveat that Maxy raised, that in the case of a BSD license, you
> may find the names of different copyright holders embedded in the text of
> the license itself.  In that case, it's not obviously true that you can
> aggregate them under a single license stanza.)

Right. Agreed.
 
Unfortunately I probably have lots of cases of this
BSD-with-different-entity-in-licence issue in this project, which is
tedious. The argument that we should be reproducing the exact licence
text does suggest that one should really put both in, even though it
really is just $copyright-holder so doesn't really add anything.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Attachment: signature.asc
Description: Digital signature


Reply to: