Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules

From: Luis Chamberlain <mcgrof@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Nick Alcock <nick.alcock@oracle.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>,
	Jiri Slaby <jirislaby@kernel.org>
Subject: Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
Date: Thu, 13 Apr 2023 13:24:15 -0700	[thread overview]
Message-ID: <ZDhk79Ep0IrXxtL6@bombadil.infradead.org> (raw)
In-Reply-To: <ZB3mw4G8GdGwSP41@bombadil.infradead.org>

On Fri, Mar 24, 2023 at 11:06:59AM -0700, Luis Chamberlain wrote:
> On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote:
> > > On 24 Mar 2023, Geert Uytterhoeven uttered the following:
> > > > I (still) agree with that, and I saw similar comments from others as well.
> > > > Unfortunately these comments are spread across tens of threads :-(
> > > 
> > > Ugh. Should I do this sort of thing in one big commit next time? That
> > > would fix that problem, but at the cost of others. Lumping seems to me
> > > to be troublesome because it makes it harder to accept/reject different
> > > bits, but would it be *as* troublesome as this much splitting?
> > 
> > The problem is, some of us disagree that this should be done at all, so
> > reverting all of the individual parts is going to be hard now.
> > 
> > Please put back the license bits that you removed, as it is not a good
> > idea to remove that if the file does not have a SPDX entry at the very
> > least.
> 
> Nick, I've just dropped your series. Please only re-submit only for
> files where the license is clear. The effort of clarifying licenses
> on files where one doesn't have an SPDX tag is welcomed but can take
> time and we'll need this anyway in the future to help later strive to
> see if we can automatically generate the MODULE_LICENSE() from the
> SPDX tags.

I had not seen any effort to get a new series going for this so given
I realize this is a royal pain in the ass to, and Nick has *already*
done enough, I've done the sanity checks myself and dropped the patches
from Nick which lacked SPDX annotations.

One can verify if a patch you are modifying lacks SPDX annotations in
a commit series with:

./scripts/spdxcheck.py -f $(git diff --name-only commid-id | xargs echo)

And so I've dropped all the patches that did that from Nick's series
and pushed to modules-next only the ones that did have an SPDX
annotation.

There were only 11 files which *did not* have SPDX annoations, these can
be worked on with the community later to get SPDX annotations added:

drivers/bus/arm-cci.c
drivers/bus/imx-weim.c
drivers/gpu/drm/drm_mipi_dsi.c
drivers/irqchip/irq-mvebu-pic.c
drivers/reset/reset-axs10x.c
drivers/reset/reset-hsdk.c
drivers/video/fbdev/asiliantfb.c
drivers/video/fbdev/gbefb.c
drivers/video/fbdev/imsttfb.c
drivers/xen/xenbus/xenbus_probe.c
lib/glob.c

  Luis