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

Re: copyright precision

Helmut Grohne writes ("copyright precision"):
> Dropping most of the Cc list as we move to general handling of similar
> issues.
> On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote:
> > ISTM that in situations where Built-Using is arguably relevant, there
> > is also often a requirement to make sure the copyright file(s) of the
> > .deb(s) contains information from the allegedly-Built-Using source
> > packages.
> Your expectation is so far removed from our current practise that I
> hardly see where to start. There are few packages that actually generate
> a copyright file for binary packages. The common case is to just copy
> the source copyright. Even for packages with Built-Using this is rare.
> By your measure, bash-static, busybox-static, cdebootstrap-static,
> ...[1] would all be rc buggy.

I was totally unaware of this..  I'm quite dismayed.

If I had ever written any package that did this kind of thing, I would
have arranged to copy the relevant parts of the copyright and
authorship notices into the binary package.

Consider bash-static.  bash-static contains copies of libncurses and
libc.  It however does not contain copies of their authorship and
copyright notices.  That is a clear breach of the normal standards of
attribution expected in a free software environmemnt, and it is of
course a breach of the licences of libc and libncurses.

> But it is actually worse than that. We don't even list copyright for
> what is contained in binary packages. For instance, libjs-sphinxdoc
Did you mean to write "source" ?

> contains css3-mediaqueries, which is mainly written by Wouter van der
> Graaf. There is no mention of his name in libjs-sphinxdoc's copyright
> (neither source nor binary) though. Again, I don't mean to blame
> individual packages or maintainers. This really is a common theme.
> It seems that doing this license tracking properly is beyond our
> capacity. And I actually see more pressing issues, such as actually
> building stuff from source instead of reusing pre-generated configure
> scripts or pre-minified javascript that nobody knows how to regenerate
> (e.g. perl's Configure, but again this really is a common theme).

Perl's Configure is not a very useful example and has IMO some
justification.  I think it's poor engineering to have edited the
output file, but that doesn't mean it's not now the source code.

> It seems to me that we are creating a gap between high quality niche
> packages and popular packages in bad shape.

I definitely don't think that popular packages should get a pass.

> On Tue, Aug 09, 2016 at 13:33:16PM +0100, Ian Jackson wrote:
> > 7 (lack of authorship and copright info in .deb for a file contained
> > in the .deb) is a release-critical bug and a proper reason for the
> > package to be REJECTED.
> By this measure, we'd gain hundreds of rc-bugs (at least all of
> Doxygen's build-rdeps). Please remember to consult d-devel@l.d.o before
> your mass bug filing.

Well, certainly I don't want to act precipitously.

Are you seriously suggesting that I actually propose a MBF ?

I'm not sure how I would automatically search for packages with
problems.  Searching for Built-Using will find the better, rather than
worse, examples...


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: