Hi Adam, Thank you for taking the time to help me along the way and to produce higher quality work.
On 5 July 2016 at 22:12, Adam Borowski <kilob...@angband.pl> wrote: > >> * Fix serious errors in debian/copyright. This is not a GPL2+ package. >> Cme was used to generate a machine-readable copyright file, then > > I'm afraid the new debian/copyright is a good deal _worse_ than before. > > For example, you claim there's a file under GPL3, which would make the > package undistributable. That file's license would be GPL3+ (not =3), > still bad, if not for an exception "... you may include it under the same > distribution terms that you use for the rest of that program". Ie, GPL2. I consulted #debian-mentors on this, and was advised that GPL-3 referred to /usr/share/common-licenses/GPL-3, and yes, I found this counter-intuitive. I was also advised to paste the short form into the debian/copyright, and it includes the "or (at your option) any later version" qualifying clause. At any rate, can I just drop the GPL3+ sections, because they are being distributed as GPL2 and thus fall under the GPL2 "Files: *" glob, yes? > > Except for some specific projects with tightly controlled copyright notices, > Cme produces output indistinguishable from noise. And knowingly providing > obviously incorrect copyright data is bad. This Cme-produced output claims > every file has a single copyright holder who last touched the file years > ago -- easily disproven by "git log" on any file I looked at. This is my first time time a copyright review, and it's a learning process :-) As for "knowingly providing obviously incorrect copyright data", I'm uncomfortable with "contracting" date ranges, because a, list, of, dates with separate copyright holders has a meaning that is distinct from a-date_range with a list of contributors; summarising makes me similarly intellectually and ethically uncomfortable... Short of: > > * you do a massive work of archeology on every file to find the set of > copyright holders. Every file will have a long list. any approach is compromise... Legally and academically speaking, the copyright file seems to be more of a non-authoritative at-a-glance overview of significant contributors. > And btrfs-progs is a massively cooperative project, with a core gang each of > whom holds copyright to most of files (or rather, their companies do -- but > those change) and a gaggle of minor contributors (including you and me). :-D thank you for noticing! I was surprised cme didn't find any of the regular patch contributors to linux-btrfs@vger... > * a blanket statement, listing maybe some major holders but with a stress on > "and others". > > I'd say the important points to convey are "1. many contributors, 2. GPL2". Could you please point me towards a good model? Since learning that machine-readable copyright files are still not useful, I've also been wondering what rules should be used to order the contributors. Does it go by alphabetical corporation, then by individuals, then by date? Should related subsections of code be grouped? (eg: contributors to send|receive functionality). I'd prefer to follow rules than group things according to patterns that might not be self-evident to others. Best regards, Nicholas
