Bug#829205: RFS: btrfs-progs/4.5.3-0.1
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 <kilobyte@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
Reply to: