On 11/30/2018 12:07 PM, Eric Anholt wrote: > Ian Romanick <i...@freedesktop.org> writes: > >> On 11/29/2018 03:53 PM, Eric Anholt wrote: >>> e<#secure method=pgpmime mode=sign> >>> Erik Faye-Lund <erik.faye-l...@collabora.com> writes: >>> >>>> 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. >>> >>> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
