On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote: > 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 How about it enables the project to comply with license requirements? I may have missed it, but I don't see that on your list. Like it or not, copyright is a thing and licenses (and our compliance with their requirements) are the only things that give us the right to distribute the packages that make up Debian. Policy 4.5.1 did relax the requirements around listing copyright holders (from the upgrading checklist): > The copyright information for files in a package must be copied > verbatim into "/usr/share/doc/PACKAGE/copyright" when > > 1. the distribution license for those files requires that copyright > information be included in all copies and/or binary > distributions; > > 2. the files are shipped in the binary package, either in source or > compiled form; and > > 3. the form in which the files are present in the binary package > does not include a plain text version of their copyright > notices. While I think listing all the copyright holders is a good idea (for the reasons you mention above) and do so, even when legally it's not required, the Debian policy requirement is now the minimum needed to satisfy license requirements. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.