Re: Process for cherry-picking patches from other projects

[Julien Grall <julien@xxxxxxx>]

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

Cheers,

--
Julien Grall