Re: Process for cherry-picking patches from other projects

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On 18 May 2022, at 08:38, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Stefano,
> 
> On 18/05/2022 04:12, Stefano Stabellini wrote:
>> On Tue, 17 May 2022, Jan Beulich wrote:
>>> Hmm. The present rules written down in docs/process/sending-patches.pandoc
>>> are a result of me having been accused of unduly stripping S-o-b (and maybe
>>> a few other) tags. If that was for a real reason (and not just because of
>>> someone's taste), how could it ever be okay to remove S-o-b? (Personally I
>>> agree with what you propose, it just doesn't line up with that discussion
>>> we had not all that long ago.)
>> This is the meaning of the DCO: https://developercertificate.org
>> The relevant case is:
>> (b) The contribution is based upon previous work that, to the best
>>     of my knowledge, is covered under an appropriate open source
>>     license and I have the right under that license to submit that
>>     work with modifications, whether created in whole or in part
>>     by me, under the same open source license (unless I am
>>     permitted to submit under a different license), as indicated
>>     in the file; or
>> IANAL but I read this as to mean that only the submitter Signed-off-by
>> is required. Also consider that the code could come from a place where
>> Signed-off-by is not used. As long as the copyright checks out, then we
>> are OK.
> 
> I don't think I can write better than what Ian wrote back then:
> 
> "
> Please can we keep the Linux S-o-b.
> 
> Note that S-o-b is not a chain of *approval* (whose relevance to us is
> debateable) but but a chain of *custody and transmission* for
> copyright/licence/gdpr purposes.  That latter chain is hightly
> relevant to us.
> 
> All such S-o-b should be retained.
> 
> Of course if you got the patch somewhere other than the Linux commit,
> then the chain of custody doesn't pass through the Linux commit.  But
> in that case I expect you to be able to say where you got it.
> "

So the thread in question is "[PATCH 1/7] xz: add fall-through comments to a 
switch statement” [1].

This effectively turned into a policy discussion that happened on a random 
thread about compression algorithms.  It’s likely a lot of people who might 
have had opinions didn’t read the thread; that’s why I started a new thread, to 
make sure people knew there was a policy discussion going on.

I was on parental leave when this discussion happened.  Looking at the thread, 
I agree with the request of Julien to just C&P the whole Linux commit message: 
It just seems both simpler and more… fitting? Respectful? Something like that; 
and additionally it saves the reviewer having to think too much about whether 
the removed S-o-b’s were necessary.  It’s something that we should just do 
because it’s easy and generally better, particularly as we now have a way of 
indicating “above this line is *their* way of doing things, which may have 
useless data in it; below this line is *ours*.”

However, the justification Ian put forward in that thread — that "S-o-b is ...a 
chain of *custody and transmission* for copyright/licence/gdpr purposes” — must 
be incorrect.  If it were true, then when we import a file from another 
project, we would have to check in *the entire git log for that file up to that 
point*, including all patches.  After all, we need to know *for each line*, the 
copyright provenance — even having a massive list of all S-o-b’s from the 
history of the file wouldn’t be of any use if a copyright dispute actually came 
up.  I think that shows the absurdity of the position.

What we need to be able to do is, for each line of code, to be able to track 
down where it came from and who originally asserted that it was GPL, in the 
event of some sort of challenge.  As long as we have the the Linux commit at 
the point of import, we can track everything else down.  In fact, it will be 
much easier to track down from a Linux git commit than from anything checked 
into the commit message.

I’ll double check with LF legal on this, but I’m pretty sure having a “pointer” 
to where the code came from (either a git commit or a message-id) should be 
fine.

 -George

[1] 
https://patchwork.kernel.org/project/xen-devel/patch/0ed245fa-58a7-a5f6-b82e-48f9ed0b6970@xxxxxxxx/

Attachment: signature.asc
Description: Message signed with OpenPGP