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

Ian Romanick idr at freedesktop.org
Fri Nov 30 21:22:28 UTC 2018


On 11/30/2018 12:07 PM, Eric Anholt wrote:
> Ian Romanick <idr at freedesktop.org> writes:
> 
>> 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.
> 
> That's an interesting legal theory.  I can't comment on it, not being a
> lawyer, and I haven't seen lawyers comment on it, either.  What I do see
> for the origin of the DCO is:
> 
> https://lkml.org/lkml/2004/5/23/10
> 
> which looks a lot more like what I was describing (an engineer trying to
> solve a social problem with engineering) than something that came out of
> a lawyers.

I just remember various lawyers at IBM explaining it to us, and they
seemed to think it was the best idea since beer in a bottle. *shrug*

Either way, it was all a long, long time ago, and I don't think any of
it really matters for Mesa.  Even though I've been doing 'git commit -s'
for years, I don't think there's a compelling to require it for Mesa.
It's just part of my work flow.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181130/dc5a5279/attachment-0001.sig>


More information about the mesa-dev mailing list