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

From: Giulio Benetti
Date: Sat Aug 19 2023 - 20:12:10 EST


Hi Laurent,

On 18/08/23 01:23, Laurent Pinchart wrote:
Hi Giulio,

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@xxxxxxxxxxxxxxxx>

(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@xxxxxxxxxxxxxxxxxxxxxx>

If I am the customer I'd really prefer the first option.

Kind regards
--
Giulio Benetti
CEO&CTO@Benetti Engineering sas

Signed-off-by: Giulio Benetti <giulio.benetti@xxxxxxxxxxxxxxxxxxxxxx>
---
Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
1 file changed, 38 insertions(+)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index efac910e2659..870e6b5def3f 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -600,6 +600,44 @@ process nor the requirement to Cc: stable@xxxxxxxxxxxxxxx on all stable
patch candidates. For more information, please read
Documentation/process/stable-kernel-rules.rst.
+Using Sponsored-by:
+-------------------
+
+A Sponsored-by tag gives credit to who sponsored the creation and/or the
+upstreaming process of the patch. Sponsored-by can contain a company name or
+a physical person name. If a company sponsored the patch this is the form::
+
+ Company Name <mail@xxxxxxxxxxxxxxx>
+
+where the Company Name must be a valid Business Name at the time of sending the
+patch until the confirmation of the Sponsored-by tag, while the e-mail can be
+either a generic e-mail the company can be reached out or an e-mail of a person
+who has the rights inside it to confirm the Sponsored-by tag.
+
+If a physical person sponsored the patch the form must be same used in
+Signed-off-by tag::
+
+ Physical Person <physical.person@xxxxxxxx>
+
+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@xxxxxxxxxxxxxxx>
+ Signed-off-by: Developer Name <developer.name@xxxxxxxxxxxxxxxxx>
+
+The result including the answer from the sponsor must be::
+
+ <changelog>
+
+ Sponsored-by: Company Name <mail@xxxxxxxxxxxxxxx>
+ Acked-by: Company Name <mail@xxxxxxxxxxxxxxx>
+ Signed-off-by: Developer Name <developer.name@xxxxxxxxxxxxxxxxx>
+
+This way the sponsor agrees to the usage of this tag using its name.
+
.. _the_canonical_patch_format:
The canonical patch format