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.
--
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: