linux-kernel - Re: [GIT PULL] SPDX update for 5.2-rc1

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

Message-ID: <alpine.DEB.2.21.1905221210340.1637@nanos.tec.linutronix.de>
Date:   Wed, 22 May 2019 12:14:09 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Joe Perches <joe@...ches.com>
cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-spdx@...r.kernel.org
Subject: Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1

On Tue, 21 May 2019, Joe Perches wrote:
> On Wed, 2019-05-22 at 13:32 +0900, Masahiro Yamada wrote:
> > (Perhaps, checkpatch.pl can suggest newer tags in case
> > patch submitters do not even know that deprecation.)
> 
> I'd still prefer the kernel use of a single SPDX style.
> 
> I don't know why the -only and -or-later forms were
> used for this patch, but I like it.

Mostly because the underlying tools use the latest SDPX version.

> Is it agreed that the GPL-<v>-only and GPL-<v>-or-later
> forms should be preferred for new SPDX identifiers?

I have no strong opinion, but using the -only / -or-later variant makes a
lot of sense.

> If so, I'll submit a checkpatch patch.

No objections, but we please have to make it clear that this is not a new
playground for s/OLDSTYLE/NEWSTYLE/ scriptkiddies.

The compliance tools have to understand both anyway.

> I could also wire up a patch to checkpatch and docs to
> remove the /* */
> requirement for .h files and prefer
> the generic // form for both .c and
> .h files as the
> current minimum tooling versions now all allow //
> comments

Yes, that makes sense. The restriction is not longer relevant, but again we
are not changing all the existing files for no reason.

Thanks,

	tglx