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

Re: Has Copyright summarizing outlived its usefulness?



Firstly, I suspect you are going to disagree wth much of what I'm
about to say.  Perhaps I have misunderstood you or you have
misunderstood me.

I feel I am in danger of repeating myself.  So it would help me if you
could try to find the specifics where you disagree with me, and
disagree with me in my language, if you see what I mean.  If that's
possible.

Steve Langasek writes ("Re: Has Copyright summarizing outlived its usefulness?"):
> On Thu, Dec 07, 2017 at 05:28:12PM +0000, Ian Jackson wrote:
> > From what I've seen of the ftp review process, the file-by-file
> > information is invaluable to ftpmaster review.  As in, the ftpmaster
> > review would probably be impractical without it.  ftpmaster review
> > necessarily focuses on the contents of the source package.
> 
> The debian/copyright isn't valuable as input to the ftpmaster review, it's
> treated as the /object/ of the review and the ftp team imposes an artificial
> requirement, not grounded in either Debian Policy or the requirements of our
> licenses, that debian/copyright align with their analysis of the copyright
> of the source package in order to clear the NEW queue.

I'm not sure I follow precisely.

> So the ftp NEW process is auditing the wrong things, for the wrong reasons.
> The purpose of debian/copyright is not to duplicate the copyright and
> license information already included in the upstream sources; it's to
> provide the relevant information to users who only have the binary package.

It seems to me that the ftp NEW process and the copyright file don't
have the same ostensible purposes; even though, historically they have
been conflated.

The ostensible purpose of the copyright file is to (i) comply with the
licence requirements to provide copyright notices (ii) tell the user
what the licence of the package is.

The ostensible purpose of the NEW process is to ensure that what we
distribute is properly licensed.  That means (a) all the source code
has an "appropriate" licence.

Clearly (a) requires checking all the source files.  In practice the
upstream source usually contains copyright notices file-by-file.  It
would in theory be possible for the ftp team to check property (a)
without the file-by-file information from the maintainer.  (By
"file-by-file information" in this message I mean not only the
purported licence for each file, but the purported authors.)

However, the maintainer should have actually looked at all the files
in the source package already, because the ftp team review is supposed
to be a double check, not the first-line research into the status of
an upstream package.  Given that, asking the maintainer to prepare
file-by-file information (even including the lists of authors) doesn't
seem too much extra work.  It allows the ftp team to check that the
maintainer has made what seem to be true assertions.

So one _actual_ purpose of the file-by-file information in d/copyright
is for the maintainer to document, for ftpmaster review, their
understanding of the source package copyright.  This is for the
purpose of (b) demonstrating that the maintainer has actually done a
copyright review, (c) recording the detailed findings of that review,
assisting ftp team audit and any future re-reviews.

And, given that this file-by-file information needs to be examined and
audited, it seems that collating it into a file-by-file report is not
an unreasonable approach.  Once we have that file-by-file report it
can generally satisfy the requirement (i) above.

Currently we consider requirement (ii) satisfied if we provide
information that allows the user to reconstrust the overall package
licence by intersecting the licences of the relevant components.  That
is not ideal as an output, but providing a condensed licence is extra
work as I suggest.

> > That the information for ftpmaster review has ended up being shipped
> > as the user-facing copyright notice in the binary is arguably not
> > ideal for some of the reasons we have explored here.
> 
> Yes; and the way to fix this is to correct this misconception (rooted in the
> historical policy error to specify copyright as a source-level file) that
> debian/copyright *should* document the source copyright instead of the
> binary copyright.

In practice, you seem to be suggesting that we should arrange to
actually try to determine a unified licence for each binary package.
We don't currently do that.  This is extra work.

The work of reviewing each source file, first by the maintainer, and
then by ftpmaster when auditing, would still have to be done, I think.

Or do you think we can avoid both the maintainer and then ftpmaster
looking at every source file ?

Do you think the work of writing down the source-file-by-source-file
information (ie, the result of the maintainer's copyright review and a
main input to the ftpmaster review) is wasted ?

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: