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. 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
