[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What to do when DD considers policy to be optional? [kubernetes]

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.

Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

Reply to: