Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Apr 2023 13:24:15 -0700
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
Message-ID: <ZDhk79Ep0IrXxtL6@bombadil.infradead.org>
References: <ZAoGLhRpTr5f7AD/@kroah.com>
 <ZApf0iNOsSAUbhMz@bombadil.infradead.org>
 <ZArc0ib697JIwKou@kroah.com>
 <ZAuGE2ay3q0MT4Yi@bombadil.infradead.org>
 <CAMuHMdVZODAr77KSp3Yicoyjz=y8OqQB+z6zTLbxO1HMKoJMSA@mail.gmail.com>
 <ZB1p5zRp7rlGGuCP@kroah.com>
 <CAMuHMdVRXQupFEoU0EbSkBnS21QXGJQ4ZOYVy-Ntwjnw7er0nA@mail.gmail.com>
 <87h6uamdzw.fsf@esperi.org.uk>
 <ZB2zrHSzmi8FXABI@kroah.com>
 <ZB3mw4G8GdGwSP41@bombadil.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZB3mw4G8GdGwSP41@bombadil.infradead.org>
Sender: Luis Chamberlain <mcgrof@infradead.org>
Precedence: bulk

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