On Wed, 10 Aug 2016 at 22:51:47 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: copyright precision"):
> > Self-imposed policy of documenting copyright information:
>
> Personally, I think it would be much better if binary packages had
> accurate centrally findable statements of their authorship
> information. For the purposes of giving credit (which is something I
> _want_ us to be doing) rather than some kind of legal compliance.
For the stuff that "naturally" ends up on end-user systems (runtime
libraries, executables, runtime data) in principle the copyright file
does this, except that for work-for-hire it typically lists authors'
employers, not authors.
For the build-time tools without which Debian couldn't exist,
chasing Build-Depends (and then listing the infrastructure like
sbuild that runs them) is going to be the only way to get a list;
I don't think those deserve any more or less credit if (as Doxygen does)
they happen to copy part of themselves, or part of their dependencies,
into their output.
I suspect that a list of authors for any Debian system complete enough
to be interesting is going to be so intimidatingly large that the amount
of credit it gives to any individual author is negligible in practice. I
mentioned adwaita-icon-theme and its > 200 authors (if you count l10n,
which I do), and that's just one package; if you consider something the
size of GNOME (+ the kernel and library/service stacks that support
it), or even LXDE, the result is just going to be a giant wall of text
that nobody reads. If you want to pursue it anyway, it's sounding less
like a job for hand-curated data like debian/copyright, and more like a
job for the sort of git data-mining[1] that produces kernel contributor
stats.
> I certainly don't feel I personally want to put doing this
> work anywher enear the top of my personal Debian todo list list
I think what you've said implies this, but just so it's been said
explicitly: while this might be nice to have, I definitely don't
think we should use release-critical bugs and package removals
to coerce individual maintainers into doing this work.
S
[1] There are rumoured to be other VCSs, but they might be a myth.
