On Tue, 08 Feb 2022 at 08:59:23 -0500, Scott Kitterman wrote:
From my point of view, treating something like other common classes of RC bugs
means that the project is producing tools and processes to make detection of such bugs more automated to remove them from the archive, that developers are actively looking for them, and that they are routinely fixed in the normal course of Debian development.
I think part of the problem here might be that copyright information is "social", not "technical": software authors can claim copyright and/or authorship in various forms of human-readable, free-form text, which means
any automated detection is necessarily going to be imperfect, and as long
as our policy demands perfection, there will be a reluctance to automate
this (or at least a reluctance to say that we are automating it).
Another part of the problem is that licensing and copyright-information
bugs are not something that we are realistically going to find through
normal use of software: if GTK crashes when you print on a Tuesday, one
of our users will eventually notice, but if we have missed a copyright
holder, it's unlikely that anyone is going to notice that omission from
the list of around 400 potential copyright holders in <
https://tracker.debian.org/media/packages/g/gtk4/copyright-4.6.0ds1-3>
unless they repeat the time-consuming process of collecting possible
copyright claims from the source code (as the ftp team presumably do). I
have no idea how the maintainers of larger and more complicated packages
manage to do this, or how the ftp team manage to review larger and more complicated packages in a finite time.
I think the copyright file is doing several things which are perhaps in conflict:
* It lets consumers of packages know what restrictions apply to their
use of a package
- This requires *most* of the license information, although not
necessarily all of it: for example if a package like Linux is licensed
under a mixture of GPL, LGPL, BSD and MIT licenses, it's usually
sufficient to be aware of the most restrictive of those licenses, in
this case GPL
- Having too much information, however, well-intentioned, actually works
against this by making it harder to find what you need
- I would argue that requiring the text of licenses like the CC family
to be inlined into the copyright file works against this goal, by
reducing the signal-to-noise ratio: if you are not familiar with a
particular license, then obviously you will need to read its text
to see what it means, but if you are looking at packages that have
content under various semi-common licenses, you only need to read
each license once
- I would argue that requiring lists of copyright holders in the same
file to be inlined into the copyright file also works against this
goal, again by harming the signal-to-noise ratio
* It lets consumers of packages know that the package is DFSG-compliant
- Same requirements as above
* It's a place to reproduce information that licenses require us to, like
a comprehensive set of copyright notices (if our interpretation of the
applicable licenses is that pointing to nearby source code and calling
it extremely comprehensive accompanying documentation is insufficient)
- In this role, it's essentially write-only: we're doing this because
we have been required to do it, more than because it's practically
useful, and I don't expect anyone to actually read this, except for
the maintainer when collecting it and the ftp team when verifying
that it has been collected
- In another subthread, Stephan Lachnit suggests using the SPDX format
for this write-only information, which I think might be intended as
a way to eventually separate it from the other roles of d/copyright
* It gives authors due credit (which we are not *required* to do, but
in previous discussions of d/copyright I've seen this cited as a reason
why we *should* do this in order to be good citizens)
- Note that collecting copyright holders is not necessarily actually
helpful here, because that often means we are required to "credit"
an employer, rather than mentioning the actual author
- In a medium-sized package like GTK, it's not clear to me that a list of
about 400 possible copyright holders is actually serving this purpose,
because any individual contributor is lost in the noise
* It lets us meet our self-imposed rules
- This is circular, so I'm inclined to disregard it when discussing what
the rules should be: we should set rules because they help us to
achieve a goal, rather than for the sake of having rules
* It lets the ftp team (or other interested reviewers) duplicate the
info-collecting process to check that all of the above have been done
- This is somewhat circular, because this is a way to support the other
goals, not really a goal in its own right
* Are there other relevant goals that I've missed here?
I don't think conflating those goals and assuming they all need to be
satisfied by a single file is necessarily going to lead to meeting any
of those goals in an efficient way, let alone meeting all of them in
an efficient way.
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)