On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote: > Jordan Justen <jordan.l.jus...@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.jus...@intel.com> > > Cc: Matt Turner <matts...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
