linux-kernel - Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

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]

Message-ID: <8ebb9e45-a69e-783b-3c93-30a7c27bdbc6@benettiengineering.com>
Date:   Thu, 24 Aug 2023 01:19:15 +0200
From:   Giulio Benetti <giulio.benetti@...ettiengineering.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Jonathan Corbet <corbet@....net>, workflows@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to
 give credits to who sponsored the patch

Hello Geert, All,

On 21/08/23 09:40, Geert Uytterhoeven wrote:
> Hi Giulio,
> 
> On Sun, Aug 20, 2023 at 2:35 AM Giulio Benetti
> <giulio.benetti@...ettiengineering.com> wrote:
>> On 18/08/23 01:23, Laurent Pinchart wrote:
>>> On Fri, Aug 18, 2023 at 12:09:57AM +0200, Giulio Benetti wrote:
>>>> Sometimes it happens that a Company or a Physical Person sponsors the
>>>> creation and/or the upstreaming process of a patch, but at the moment
>>>> there is no way to give credits to it. There are some commit that include
>>>> a sort of tag "Sponsored by" without the dash to avoid
>>>> scripts/checkpatch.pl to complain but a real standard has not been defined.
>>>> With this patch let's try to define a method to give credits consistently
>>>> including an acknowledge from the sponsor. The goal is to improve
>>>> contributions from companies or physical persons that this way should gain
>>>> visibility in Linux kernel and so they should be more prone to let the
>>>> work done for them for to be upstreamed.
>>>
>>> Just adding one data point here, without judging on the merits of this
>>> proposal. I've been requested previously by customers to increase their
>>> visibility in the kernel development statistics, and the way we found to
>>> do so was to sign-off patches with
>>>
>>> Laurent Pinchart <laurent.pinchart+customer@...asonboard.com>
>>>
>>> (where "customer" is to be replaced with the customer name).
>>
>> this approach works good for the developer because of the +customer
>> mailbox capability but in term of appeal for the final customer I've
>> been told(by the customer) he would really like more the "Sponsored-by:"
>> way. To tell the truth while I was looking for an existing alternative
>> I've found the commits with "Sponsored by:" pseudo-tag that look cooler.
>>
>> This is my taste of course and the taste of one of my customers, but
>> to me it's like having a brand shown:
>> Sponsored-by: Sponsoring Company
>> vs:
>> Signed-off-by: Giulio Benetti
>> <giulio.benetti+sponsor.company@...ettiengineering.com>
> 
> Personally, I would respond "I'm sorry, but the only advertising
> space we offer are Copyright headers (for employees) and
> "user+customer@..." or "name (customer) user@..." (for contractors).

This is a good answer. So these are the 2 possible ways to give credits
to sponsors.

Does it make sense if I send a patch describing exactly this?
This is because my finding was only "Sponsored by" that looked good
to me. So I can avoid other possible pain for the future.

> And this is a separate tag, so it's harder for the analysis tools
> (whose output your customers must be interested in, too?) to
> match the tag to the actual Author/Reviewer/...

Right

>> If I am the customer I'd really prefer the first option.
> 
> You are aware this will cause lots of work for the customer, too?
> (See below).

[ SNIP ]

>>>> +In both cases, to prevent fake credits, either the company or the person should
>>>> +send an Acked-by tag placed right under Sponsored-by tag using the same form
>>>> +described above. So for example if the patch contains::
>>>> +
>>>> +    <changelog>
>>>> +
>>>> +    Sponsored-by: Company Name <mail@...panyname.com>
>>>> +    Signed-off-by: Developer Name <developer.name@...elopername.com>
>>>> +
>>>> +The result including the answer from the sponsor must be::
>>>> +
>>>> +    <changelog>
>>>> +
>>>> +    Sponsored-by: Company Name <mail@...panyname.com>
>>>> +    Acked-by: Company Name <mail@...panyname.com>
>>>> +    Signed-off-by: Developer Name <developer.name@...elopername.com>
>>>> +
>>>> +This way the sponsor agrees to the usage of this tag using its name.
> 
> This is also causing more work for maintainers: now they have to check
> if any Sponsored-by tags are present, and track if there is a response
> with a matching Acked-by tag...
> 
> And obviously they should postpone applying the patch until a
> confirmation response is sent... which may never happen...

Yes it came into my mind and I wanted to rely only on DCO dropping the
part of acked-by tag. But there are too many cons for Sponsored-by approach.

So I will go for one of the 2 ways I've been pointed.

Thank you
Best regards
-- 
Giulio Benetti
CEO&CTO@...etti Engineering sas