Re: Nobody is THE one making contribution

[Felipe Contreras <felipe.contreras@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, Dec 24 2020, Felipe Contreras wrote:
> 
> > Ævar Arnfjörð Bjarmason wrote:
> >> On Wed, Dec 23 2020, Felipe Contreras wrote:
> >> 
> >> > When I express my dissenting opinion I'm not saying nobody should write
> >> > a patch on top of mine. Of course they can. Anybody can take my code and
> >> > do whatever they want with it (as long as they don't violate the license
> >> > of the project).
> >> >
> >> > What they cannot do is add my Signed-off-by line to code I don't agree
> >> > with.
> >> 
> >> I don't think that's what Signed-off-by means, per SubmittingPatches:
> >> 
> >>     To improve tracking of who did what, we ask you to certify that you
> >>     wrote the patch or have the right to pass it on under the same
> >>     license as ours, by "signing off" your patch[...under the DCO:
> >>     https://developercertificate.org/]
> >
> > Yes, but the DCO requires (d):
> >
> >   d. I understand and agree that this project and the contribution are
> >      public and that a record of the contribution (including all personal
> >      information I submit with it, including my sign-off) is maintained
> >      indefinitely and may be redistributed consistent with this project or
> >      the open source license(s) involved.
> >
> > We can narrow down the part I'm talking about:
> >
> >   d. I *agree* that a record of the contribution is maintained
> >      indefinitely.
> >
> > I don't agree with that.
> 
> I don't understand you here. You don't agree that we retain
> Signed-off-by lines indefinitely, or just in the case of amended
> patches?

The DCO requires that I agree that a record of my contribution is
maintained indefinitely.

If I don't agree that a record of a particular contribution is
maintained indefinitely, the DCO says you shouldn't use it.

> > Moreover, the relevant definition of "sign off" in English in my opinion
> > is [1]:
> >
> >   to approve or acknowledge something by or as if by a signature (sign
> >   off on a memo)
> >
> > If I didn't put my "signature" in a commit, then it's not signed off by
> > me.
> 
> I think this use of 'signed off" makes perfect sense if you interpret
> the sign-off to mean "I signed off on the copyright eligibility of this
> work for inclusion" which is what I think it means.
> 
> Not "I signed off on my subjective approval of this patch & what it's
> for etc.", which seems to be closer to your interpretation.

Why does it have to be only one meaning?

Junio doesn't sign off on a patch that he doesn't think is good.

Same happens with all the lieutenants of Linux.

> >> "No Discrimination Against Fields of Endeavor" is an integral part of
> >> free software & open source. In our case it means that when you
> >> contribute code under our COPYING terms someone else might use in a way
> >> you don't approve of.
> >
> > Yes, you just have to make the record straight; do your changes in a
> > separate commit without my "sign off".
> 
> We like to maintain "make test" passing for every commit, and sometimes
> we have patches on the ML with a SOB that don't even compile yet, let
> alone pass tests, because they were provided by their authors as "maybe
> try this" or other near-pseudocode.
> 
> We also like to optimize patch order/size/splits/etc. for the benefit of
> reviewers. Sometimes someone might send a patch with a SOB that's better
> squashed into another one, or refactored into N commits spread across a
> series etc.

Yes. And most of the time that's fine, because the original author is
not objecting to the clause (d).

> >> E.g. I'm sure that arms contractors, totalitarian regimes etc. or other
> >> entities some might disapprove of are using git in some way.
> >
> > Yes, and you can modify my patch and keep my s-o-b, I'm not going to sue
> > you.
> >
> > I just don't think that's right.
> >
> >> That non-restriction on fields of endeavor also extends to individual
> >> patches licensed under a free software license & the necessity to
> >> maintain a paper trail about who their authors are and if they certified
> >> them under the DCO.
> >
> > Sure, so if you need to keep a paper trail about the copyright of the
> > code, why would you risk that simply because the author didn't agree on
> > the further changes.
> >
> > Just do them on a separate commit. Problem solved.
> 
> I don't understand how the copyright paper trail is at risk just because
> we combine N patches into one.

It's not just a copyright paper trail, the DCO clearly states that the
author should:

  d. I *agree* that a record of the contribution is maintained
     indefinitely.

> The important part is that we have a declaration that the sum of the
> work (and whatever it's derived from) is properly licensed, that the
> authors had the right to license it for inclusion etc.

That's the important part, yes. It's not the only part.

Cheers.

-- 
Felipe Contreras