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

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



Russ,

On 25.03.20 03:25, Russ Allbery wrote:
> 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.

if I could +1000 just one post, ever, it's this one.

The vast majority of people developing Open Source Software nowadays
just publish stuff on GitHub and friends. They fork code, they merge
other people's contributions, etc.

And at no point can I see those people engage in even a fraction of the
bureaucracy that we follow when sharing, forking, publishing, and
contributing code.

This is not to say that licensing is an unimportant issue -- it clearly
is. But our analyze-and-document down-to-the-file approach is on the
other extreme end of the spectrum, and it causes lots of tiresome work
that nobody apart from us seems to care about.

> Other choices are possible, such as trusting license declarations
> by upstream and then handling upstream mistakes that are later discovered
> as RC bugs.

This would be fantastic. Just fantastic.


Reply to: