[lkml]   [2019]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Wed, 2019-05-22 at 13:32 +0900, Masahiro Yamada wrote:
> On Tue, May 21, 2019 at 10:34 PM Greg KH <> wrote:
> > - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan
> > tools can determine the license text in the file itself. Where this
> > happens, the license text is removed, in order to cut down on the
> > 700+ different ways we have in the kernel today, in a quest to get
> > rid of all of these.
> I have been wondering for a while
> which version of spdx tags I should use in my work.
> I know the 'GPL-2.0' tag is already deprecated.
> (
> But, I saw negative reaction to this:
> Nor "-only" / "-or-later" are documented in
> Documentation/process/license-rules.rst
> In this patch series, Thomas used 'GPL-2.0-only' and 'GPL-2.0-or-later'
> instead of 'GPL-2.0' and 'GPL-2.0+'.
> Now, we have a great number of users of spdx v3 tags.
> $ git grep -P 'SPDX-License-Identifier.*(?:-or-later|-only)'| wc -l
> 4135
> So, what I understood is:
> For newly added tags, '*-only' and '*-or-later' are preferred.
> (But, we do not convert existing spdx v2 tags globally.)
> "
> Joe's patch was not merged, but at least
> Documentation/process/license-rules.rst
> should be updated in my opinion.
> (Perhaps, 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.

I believe the -only and -or-later are more intelligible
as a trivial reading of

SPDX-License-Identifier: GPL-2.0

would generally mean to me the original
GPL-2.0 license without the elision of the
(or at your option, any later version) bits


SPDX-License-Identifier: GPL-2.0-only

seems fairly descriptive.

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

If so, I'll submit a checkpatch patch.

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 //

 \ /
  Last update: 2019-05-22 08:35    [W:0.138 / U:26.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site