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

Erik Faye-Lund erik.faye-lund at collabora.com
Thu Nov 29 09:28:55 UTC 2018


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.

IIRC this came from a lawsuit where the legality of some code came up
for question because it was hard to prove how it made its way into the
kernel.

So the idea is that everyone contributing to putting some code in the
kernel adds a s-o-b, and at least we can ask those people about things
afterwards (and the "legality" is supposed to chain; you can s-o-b a
change because the person before you s-o-b'ed, and you trust the way
you got that s-o-b).

I could imagine Mesa potentially being vulnerable to cases like this,
especially because it contains code based on reverse-engineering; some
GPU vendor might change their view on OSS, and try to claim things are
based on stolen code, for instance. I'm not saying it's likely, just
that it can. And it would really suck if it happened ;)

We also currently have multiple ways for code to get into mesa, but far
fewer ones that the kernel. So I somehow doubt we'd be having an as
hard time with this as the kernel does.

So all in all; I'm not sure it's worth it. But it might be, and it's
not a huge burden IMO.



More information about the mesa-dev mailing list