On Tue, 24 Mar 2020 19:25:49 -0700 Russ Allbery <r...@debian.org> wrote:
> Michael Lustfield <mich...@lustfield.net> writes: > > > One last thing to consider... NEW reviews are already an intense > > process. If this package hit NEW /and/ we allowed vendored libs, you > > could safely expect me to never complete that particular review. I doubt > > I'm the only one; that's essentially ~200 package reviews wrapped into > > 1. > > I'll repeat a point that I made earlier but put a bit of a sharper point > on it: We should thoughtfully question whether the current approach to > license review that we as a project ask ftpmasters to do is a correct > investment of project resources. > > The current approach to NEW license review is not a law of nature. It's a > choice. Other choices are possible, such as trusting license declarations > by upstream and then handling upstream mistakes that are later discovered > as RC bugs. The project is much better at sharing the load of handling RC > bugs than it is at sharing the load of NEW license reviews. > > Most of the ecosystems that make extensive use of vendored packages also > make extensive use of license metadata. Sometimes that license metadata > is wrong, and we will have to have a process for dealing with those > errors. But the purpose of Debian is not to be a license checking service > for the entire free software world. It's to build a distribution adhering > to a set of principles but with the understanding that we will sometimes > make errors and fix them later as bugs, not be perfect and error-free at > any of our principles, including our licensing principles. For everything > other than licenses, we accept the risk that we will incorporate upstream > errors in our distribution until someone points them out via a bug report. > > We do not *have* to do a detailed file-by-file review of the correctness > of upstream's license metadata when packaging. This is a choice. By > choosing to do this, we absolutely catch bugs... just like we would catch > bugs if we did a detailed file-by-file review of any other property of > upstream code. For many other types of bugs (including ones that arguably > have a more severe impact on our users than licensing bugs, such as > security bugs), we often make trade-off decisions in favor of accepting a > risk of upstream mistakes and having to fix them later. Scott K. reminded me that the policy in question is a "should" and not a "must." This is a pretty important distinction that I forgot about. In practice, it's useful for when a single file is taken from a large project, sometimes including weird build tools. Assuming d/copyright is actually correct (it's not..), then it's not a policy violation. However, for all of the reasons mentioned, and especially because most of that work was already complete, I have to agree with the term sloppy. We obviously need to continue the vendor/ discussion, but I think switching threads would be a good idea. -- Michael Lustfield