Hello Steve, On Wed 09 Feb 2022 at 01:26pm -08, Steve Langasek wrote:
> The fact that the FTP team applies license/copyright review as part of their > review of source packages has grounding in a number of goals of Debian as a > project. The existence of a binary NEW queue is also sensible, as the FTP > team have to manage the namespace of the packages in the archive. But the > application of license/copyright review by the FTP team for existing > source packages as part of binary NEW processing /and at no other time/ is > arbitrary. It is, at best, a historical accident that has taken on the > authority of precedent. > > Guarding against debian/copyright drift is a useful goal. But it is harmful > to the velocity of the project to either block or reject new binary packages > in the archive because of this linkage to license review. > Actively-developed library packages with ABI changes are not fundamentally > more likely to have license drift than any other package in the archive, so > focusing FTP team time on reviewing the licenses of these packages in > particular is a misapplication of resources. > > The responses I've seen from the FTP team to this can, I believe, be roughly > paraphrased as "we would like all debian/copyright in the archive to be > clean, but we don't have capacity to do that, so we're doing this instead". > I assert that it is much, much worse to continue doing this than to do *no* > license/copyright review as part of binary NEW. It does not achieve the > goal of having clean debian/copyright across the archive; it slows down the > binary NEW queue due to (self-imposed) workload of the FTP team; and it > deters developers interested in this problem space from innovating better > (and more systematic) solutions outside the small FTP team. I'm sorry to be responding only a month later, but I think there are some reasons why binNEW is not the worst place to be doing these extra checks: packages with SONAME bumps are typically C or C++ projects and these are (i) large, such that d/copyright is more likely to drift simply because of the volume of files; and (ii) often contain embedded code copies with different copyright and licensing. My own NEW experience is that I've consistently found more problems in binNEW packages than anywhere else. -- Sean Whitton
