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
