Re: copyright precision
On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote:
> > 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" ?
> > 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
> > (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.
IMO it is a very good example. To determine whether Perl's Configure
is preferred form for modification, I sent a patch. It turned out that
my patch couldn't be applied, because it touched generated parts and it
was concluded that Configure should be regenerated to fix the
reported issue. Demonstrably, Configure is not preferred form for
modification. Whether we call it source or not, the freedom to modify is
Another place where the inability to build from source has hampered
progress was blt #772590.
Other packages that don't build from source by default include bash,
dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc,
libatomic-ops, libbsd, libtasn1-6, lzo2, ncurses, nettle, patch,
readline6, and sed.
I believe that being able to build from source is more important than
copying copyright information from packages in Built-Using.
> I definitely don't think that popular packages should get a pass.
Now we're two, but that's still not project consensus as can be seen in
> Are you seriously suggesting that I actually propose a MBF ?
If you think that our current practice is wrong, isn't it logical to do
 Please try not to blame Perl maintainers for the mess. They really
took the issue seriously and tried hard to fix it. It really is an