Re: Nobody is THE one making contribution

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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?

> 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.

>> So I find this rather unlikely, but let's say I author a patch for
>> git.git and send it to this ML with a Signed-off-by.
>> 
>> If someone else then takes that patch and changes it in a way that I
>> vehemently disagree with and gets Junio to accept it into git.git in its
>> altered form, that altered patch should still carry my Signed-off-by, as
>> well as that of whoever altered it.
>
> I don't think so.
>
> Even if you disregard clause (d) of the DCO, in English you didn't "sign
> off" on that particular version of the patch.

[...addressed below...]

>> "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.

>> 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.

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.