[Mesa-dev] [PATCH] docs: Document and *require* usage of Signed-off-by

[Ian Romanick]

On 11/29/2018 03:53 PM, Eric Anholt wrote:
> e<#secure method=pgpmime mode=sign>
> Erik Faye-Lund <erik.faye-lund at collabora.com> writes:
> 
>> On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote:
>>> Jordan Justen <jordan.l.justen at intel.com> writes:
>>>
>>>> This adds the "Developer's Certificate of Origin 1.1" from the
>>>> Linux
>>>> kernel. It indicates that by using Signed-off-by you are certifying
>>>> that your patch meets the DCO 1.1 guidelines.
>>>>
>>>> It also changes Signed-off-by from being optional to being
>>>> required.
>>>>
>>>> Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
>>>> Cc: Matt Turner <mattst88 at gmail.com>
>>>
>>> What problem for our project is solved by signed-off-by?  Do you
>>> think
>>> that it has actually reduced the incidence of people submitting code
>>> they don't have permission to submit in the projects where it's been
>>> used?  I know the behavior in the kernel is that people submit a
>>> patch,
>>> it's missing s-o-b, so it gets bounced, then they maybe add s-o-b or
>>> just give up.  I don't think anyone stops and says "Wow, that's a
>>> good
>>> question.  Maybe I don't have permission to distribute this after
>>> all?"
>>>
>>> /me sees s-o-b as basically just a linux kernel hazing ritual
>>
>> I don't think that's the purpose of s-o-b in the Kernel. AFAIK, the
>> reason for the s-o-b is to have a paper-trail for how a patch landed in
>> the kernel; who it went through etc.
> 
> I get the *idea*, I just believe the idea fails in practice.  The S-O-B
> idea came from "wouldn't it be nice if we could make everyone think
> about this issue that is important to us" but what we actually got
> instead is "your patch gets bounced if you don't have a s-o-b on until
> you slap one on and resend."

You're thinking like an engineer, but the s-o-b is the spawn of lawyers.
 Supposedly, having someone say "I had the rights to contribute this
code," even if they didn't think about what that meant, enables you to
pass that blame along because that person showed intent.  You may not
have read and thought about every page of your mortgage, but you can
still be held accountable for every word.  Having an author tag or a
committer tag does not show that same intent.  In a legal context, the
s-o-b shifts the onus of auditing code ownership from the distributor to
the submitter.  When a distributor, like IBM in the SCO case, get sued,
they can plausibly claim that all of the code they distributed was
vouched for.  If someone submits code that they do not have the right to
submit and provides false testimony, then that's on the submitter.

S-o-b for that purpose always seemed pretty lame to me (from any
perspective) because patches aren't digitally signed.  Anyone can add
any s-o-b to any patch, spoof the sending address, etc.

The s-o-b is also mostly an anachronism of taking patches via mailing
list.  Projects that exclusively use GitHub or similar have everyone
sign an SLA, and every patch that comes in through the submission
mechanism, guarded by a login, is implicitly signed.

> We've already got 1-2 people to contact if there's a question about
> authorship, from the committer and author fields.

That's one thing that annoys me from time to time about git.  Five
people may have worked on a patch, but it only shows one author.

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev