linux-kernel - Re: [PATCH 10/17] tty: remove MODULE

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] [day] [month] [year] [list]

Date:   Thu, 13 Apr 2023 13:24:15 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Nick Alcock <nick.alcock@...cle.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
        Hitomi Hasegawa <hasegawa-hitomi@...itsu.com>,
        Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules

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