Regarding vendor/ libraries... [Was: Re: What to do when DD considers policy to be optional? [kubernetes]]
On Tue, 24 Mar 2020 19:25:49 -0700
Russ Allbery <rra@debian.org> wrote:
> Michael Lustfield <michael@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
Reply to: