On 15.08.2016 21:50, Scott Kitterman wrote: > On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote: >> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote: >>> The problem we're having here is clearly about *tooling*. If we had a >>> good toolchain to compile and audit machine-readable debian/copyright >>> files without sweating, nobody would complain. >> >> I have three slightly devil's-advocate responses to that: >> >> * If we had a good toolchain to compile and audit this stuff, people >> and companies who want to know the copyright holders could just use >> that to inspect the upstream source code and cut out the middle-man. >> >> * Our copyright files are only correct inasmuch as upstream's copyright >> attribution is correct. I would guess that a large majority of patch >> submitters, even implementors of somewhat major features that are >> certainly copyrightable, don't actually add a copyright notice to the >> files they touched. I certainly don't do that 100% consistently for my >> own contributions; I'm careful to preserve *other people's* copyright >> notices and license grants if I incorporate someone else's code into a >> project, but I think I can confidently say that not all upstreams >> are even that conscientious. >> >> * I will continue to complain as long as my "source" packages are >> expected to contain 87kB monsters like >> >> <https://sources.debian.net/src/adwaita-icon-theme/3.20-3/debian/copyright/ >>> , which is fairly clearly not anyone's preferred form for modification, and >> if we're being honest probably not really anyone's preferred form for >> consumption either. (That file is actually generated, by the slightly less >> offensive 11kB >> >> <https://sources.debian.net/src/adwaita-icon-theme/3.20-3/debian/copyright. >> pl/>, because I really didn't want to insert the CC licenses by hand; but >> Policy and ftp-master practice require the generated file to be part of the >> source upload. See also <https://bugs.debian.org/768292>.) > > Personally, I think the bulk of the reason we should care about > debian/copyright is to achieve license compliance. For license compliance we > need to reproduce the upstream copyright notice and license, so even if it was > easy to download source and inspect with better tool, it does nothing to help > what we need to do to keep the binary parts of the archive legal to > distribute. We would also achieve license compliance if we did it the way Fedora/Red Hat have been doing it for years now. Not a single DFSG-approved license requires us to reproduce its full license text in a new file called debian/copyright, not even the BSD-licensed ones. > I think your points are orthogonal to the reasons we do debian/copyright. > > Yes, copyright files are hard and unfun and we could use better tools, but I > don't think anyone is writing or reviewing debian/copyright because they enjoy > it. I would like to take this opportunity to thank Simon McVittie for contributing to this thread. I completely agree with everything he has written so far especially with the points presented at [1] So yes, copyright files are hard and unfun but why should we continue to write them the way we do if we are not legally bound to do so? Sure I agree that a machine-readable copyright file that lists every contributor and license would be preferable but in reality those files get outdated very quickly and only a few maintainers really care about updating this file after importing a new upstream release. I still don't understand why we punish ourselves by reproducing every license text verbatim if we could easily add every DFSG-approved license to /usr/share/common-licenses and simply refer to it. Some people argue that a Creative Commons license is not a common license but apparently they have never packaged a game or multimedia application before. Get rid of the distinction between common-licenses and DFSG-approved licenses. Every DFSG-free license should be available on a Debian system. Full stop. Don't require that people have to quote the same license text over and over again in their packages. That would be a step forward. Regards, Markus [1] https://lists.debian.org/debian-devel/2016/08/msg00181.html
Attachment:
signature.asc
Description: OpenPGP digital signature