mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: aelior@marvell.com, bharat@chelsio.com,
	kernel-janitors@vger.kernel.org, leon@kernel.org,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	mkalderon@marvell.com, selvin.xavier@broadcom.com,
	yishaih@nvidia.com, zyjzyj2000@gmail.com
Subject: Re: [PATCH] headers: Remove some left-over license text in include/uapi/rdma/
Date: Mon, 26 Sep 2022 21:32:28 +0200	[thread overview]
Message-ID: <7cbe6ea7-3d05-449f-ea06-c98b9078d1df@wanadoo.fr> (raw)
In-Reply-To: <YzHttWsmFSMR8vCY@nvidia.com>

Le 26/09/2022 à 20:21, Jason Gunthorpe a écrit :
> On Sun, Sep 25, 2022 at 03:39:58PM +0200, Christophe JAILLET wrote:
>> There is already a SPDX-License-Identifier tag, so the corresponding
>> license text can be removed.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org>
>> ---
>> Changes in the 2 files under rdma/hfi/ is a bit more than just removing
>> the license text. There were some Copyright(c) for GPL and BSD licence.
>> I have simplified it to what look logical to me.
>> But in case it matters, review with care.
> 
> Did you use a script or something to verify that the text being
> removed is word for word identical to the text in LICENSES/ ?

Hi,

Short answer:
============

You are likely right, and patches for BSD like license should certainly 
be left as-is to keep as-is.



Longer answer:
=============

I spot potential candidate with:
   grep -r --include=*.[ch] -A50 SPDX | grep -v SPDX | grep -v staging | 
grep -v usr\/include\/ | grep -C10 License

Then I manually check that the included license is consistent with the 
SPDX-License-Identifier tag.

If they don't match, I propose to change the SPDX tag (see [1] for an 
example)

My grep is not optimal. Looking for GNU or GPL or BSD or... also gives 
some decent results. But all what is done is done.


Honestly, I don't look word by word the text itself.
My point is that if a file states that it is usable under a given 
license, then it should use the term of this license. Otherwise it looks 
pointless to refer to it, no?

Moreover, in the BSD license, some parts of the text can be adjusted to 
the context. (in red in [3]

In "bnxt_re-abi.h", the BSD-2-Clause "THE COPYRIGHT HOLDER OR 
CONTRIBUTORS" has been replaced by "THE AUTHOR AND CONTRIBUTORS".


Giving a 2nd look at it (see [4]), when boilerplate have been removed, 
it was mostly (only?) for GPL-2, which don't have such "red" parts in 
the license text.


So you are likely right, and patches for BSD like license should 
certainly be left as-is to keep this "red places" as-is.

> 
> I had understood this was the reason the original SPDX conversion left
> the license text around?

I don't know. It looks to me that Greg has done some mass update, 
especially in the uapi directory, only adding the 
SPDX-License-Identifier tag.
See [2].

> 
> It looks OK to me, but I didn't check it word for word :)
> 
> Is there a reason this series is coming up now around the uapi
> headers? Are we doing them all or something?

No specific reason for it to happen now.

I chose uapi directory because it is .h files. This is my own 
contribution to the Ingo Molnar's "Fast Kernel Headers".
Smaller header files, faster compilation :)
(even if my clean-ups should be just noise in the overall building time)

I try to send patches in small hunks of related files. This avoids the 
"please split the patch in a serie by maintainer" answer.

I've send ~10 or 15 patches yet. I'll see the enthusiasms (or lack of) 
for such patches before continuing.

> 
> Jason
> 

CJ

[1]: 
https://lore.kernel.org/all/a57505bf6c8ddbd68ff5a320aaf5922ec431e00e.1664117249.git.christophe.jaillet@wanadoo.fr/

[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e2be04c7f9958dde770eeb8b30e829ca969b37bb

[3]: https://spdx.org/licenses/BSD-2-Clause.html

[4]: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=boilerplate%2Freference

      reply	other threads:[~2022-09-26 19:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 13:39 Christophe JAILLET
2022-09-26 18:21 ` Jason Gunthorpe
2022-09-26 19:32   ` Christophe JAILLET [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7cbe6ea7-3d05-449f-ea06-c98b9078d1df@wanadoo.fr \
    --to=christophe.jaillet@wanadoo.fr \
    --cc=aelior@marvell.com \
    --cc=bharat@chelsio.com \
    --cc=jgg@nvidia.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mkalderon@marvell.com \
    --cc=selvin.xavier@broadcom.com \
    --cc=yishaih@nvidia.com \
    --cc=zyjzyj2000@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®