linux-kernel - Re: [RFC v2] MEDIA: Driver for ON Semi AR0521 camera sensor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 24 Jun 2021 16:34:06 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Krzysztof Hałasa <khalasa@...p.pl>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2] MEDIA: Driver for ON Semi AR0521 camera sensor

On Thu, Jun 24, 2021 at 03:22:48PM +0200, Krzysztof Hałasa wrote:
> Hi Greg,
> 
> Greg KH <gregkh@...uxfoundation.org> writes:
> 
> > +// SPDX-License-Identifier: GPL-2.0
> 
> > Putting the above line on a file _IS_ a legal declaration that the file
> > is released under GPL-2.0.  It's pretty simple :)

Greg, on a side note, the discussion originated from
https://lore.kernel.org/linux-media/m3r1gt5hzm.fsf@t19.piap.pl/. I'll
quote Krzysztof so the discussion doesn't get split across multiple
places:

> > To spend time reviewing this code, I want to know it will be mergeable,
> > and that requires a SoB line. That's a blocker I'm afraid.
> 
> So how do you propose to solve the situation, in which my driver is
> rejected, but another persor takes it, makes changes (btw breaking it),
> and presents it as their own, and it's accepted? This is a paid work and
> I'm required to put in my employer's copyright over the code.
> I could have made this error once - but no more.
> 
> The code will be mergeable, as I already wrote. Why would I bother
> otherwise? But I cannot let that history to repeat itself.

Your opinion on this would be valuable too.

> Do you think putting this line anywhere, in any file, does it?
> That would be crazy.
> 
> How about a book, e.g. describing a patch submission process (but not
> a copy of kernel's Documentation). The same?
> 
> Also - in all countries? Most of them?
> 
> Come on.
> 
> Then why would we need the Signed-off-by?
> From my perspective, the SPDX-License-Identifier is only meaningful when
> the file is actually a part of the kernel, or if, at least, it's been
> presented for merge, with Signed-off-by etc.

Quoting Documentation/process/submitting-patches.rst:

Sign your work - the Developer's Certificate of Origin
------------------------------------------------------

To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
layers of maintainers, we've introduced a "sign-off" procedure on
patches that are being emailed around.

The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as an open-source patch.  The rules are pretty simple: if you
can certify the below:

Developer's Certificate of Origin 1.1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (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

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

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

then you just add a line saying::

        Signed-off-by: Random J Developer <random@...eloper.example.org>


The SoB line doesn't convey any license information, that's specified
separately and explicitly in each file (usually in the form of an SPDX
tag, which is just a machine-parsable, short-hand version of a full
license header in text form).

-- 
Regards,

Laurent Pinchart