Re: What to do when DD considers policy to be optional? [kubernetes]
On March 25, 2020 1:43:26 PM UTC, Christian Kastner <ckk@debian.org> wrote:
>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.
This is basically what we do now, so don't get too excited.
The FTP Team review of debian/copyright is about DFSG and upstream license compliance. Most licenses require things like copyright statement preservation in binary distribution and debian/copyright is how we do that. Occasionally, in the process of evaluating if Debian would be in compliance with the upstream license and if the license meets our DFSG requirements, we detect larger issues.
When I'm reviewing something for New I take upstream's copyright/license statements at face value unless there's something too obvious to be ignored. I certainly don't go hunting for reasons not to like upstream licensing statements, but sometimes they slap you in the face.
By far the most common case for rejections is incomplete debian/copyright and that's unrelated to trusting upstream. Personally, I don't think the problem is that the bar is too high. Almost all debian/copyright issue I find could have been located before upload if the maintainer had simply grep -ir copyright * | less and checked the results before uploading.
Scott K
P.S. Speaking only for myself, no hats
Reply to: