Re: length of Debian copyright files
On Wed, 25 Mar 2020 at 15:32:20 +0100, Tomas Pospisek wrote:
> On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > Or you can look at the Redhat approach as a minimal working one.
> > You know it can be done much easier and still work: in Redhat.
>
> (in case it hasn't already been discussed in this thread, but don't
> bother rehashing...): What are they doing differently?
Here is a concrete example of a medium-to-large package with a relatively
typical licensing situation (LGPL plus some more-permissive bits): GTK 4,
for which I redid the copyright file somewhat recently in preparation
for getting it through NEW.
Debian:
https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1
plus we ship the LGPL in base-files' common-licenses.
Fedora:
one line in gtk4.spec "License: LGPLv2+", plus they ship these
files in their binary package:
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/AUTHORS
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING (it's the LGPL)
I'm pretty sure the long list of maybe-copyright-holders in the Debian
package is still incomplete; merge requests welcome. I'm also fairly sure
we are the only distribution that does this (not counting our derivatives
like Ubuntu), even though some of the others have lawyers.
If people have recommendations for how to make gtk+4.0's copyright file
more minimal, I'd be happy to review merge requests or otherwise receive
suggestions.
I think part of the problem might be this vicious cycle: the NEW queue
is an asynchronous gatekeeper/progress blocker, which gives maintainers
a strong incentive to get things accepted first time (because a NEW
rejection will double the delay), which means maintainers are incentivized
to dot every i and cross every t in the copyright file even if it isn't
strictly necessary, which means the ftp team are given larger and more
verbose copyright files to read, which presumably means the NEW queue
takes longer than it otherwise could.
smcv
Reply to: