Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
Hi Joe, On Wed, May 22, 2019 at 3:37 PM Joe Perches wrote: > > 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. > > (https://spdx.org/licenses/GPL-2.0.html) > > > > But, I saw negative reaction to this: > > https://lore.kernel.org/patchwork/patch/975394/ > > > > 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, 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. > > 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 > > whereas > > SPDX-License-Identifier: GPL-2.0-only > > seems fairly descriptive. > > Is it agreed that the GPL--only and GPL--or-later > forms should be preferred for new SPDX identifiers? > > If so, I'll submit a checkpatch patch. Could you send a patch to update checkpatch and doc ? Similar discussion here too. https://lkml.org/lkml/2019/5/31/456 We need better documentation to stop wasting time for this. This should be separated from the /* ... */ vs // discussion. Thanks. > 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 > . > > -- Best Regards Masahiro Yamada
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
HI all, Sorry I didn’t jump in here sooner. Just a bit of additional background info to what Thomas and Alexios have already provided below: > On May 29, 2019, at 8:16 AM, Zavras, Alexios wrote: > > >> -Original Message- >> From: linux-spdx-ow...@vger.kernel.org >> On Behalf Of Alexandre Belloni >> Sent: Wednesday, 29 May, 2019 15:13 >> Subject: Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1 >> >> Hello, >> >> On 21/05/2019 15:32:57+0200, Greg KH wrote: >>> - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan >> >> I'm very confused by those two tags because they are not mentioned in the >> SPDX 2.1 specification or the kernel documentation and seem to just be from >> https://spdx.org/ids-howi which doesn't seem to be versionned anywhere. >> While I understand the rationale behind those, I believe the correct way of >> introducing them would be first to add them in the spec and documentation >> and then make use of them. > > The "GPL-2.0-only" and "GPL-2.0-or-later" are license short identifiers. > They do not belong to the SPDX spec, but rather on the license list. > They were introduced in the SPDX License List v3.0 (current version is 3.5): > https://spdx.org/licenses/ > > It seems the examples in the kernel documentation use identifiers > from earlier versions of the license list. As Thomas mentioned in another part of this thread, the identifiers for the GNU family of licenses was changed as of v3.0 of the SPDX License List in Dec 2017. See https://spdx.org/news/news/2018/01/license-list-30-released for a explanation and https://www.gnu.org/licenses/identify-licenses-clearly.html for the impetus of the change. (Note, the SPDX License List has its own versioning separate from the SPDX Spec.) We don’t change the license identifiers lightly and have only done so for very specific and limited reasons, so you can be sure there was a LOT of discussion over this change. Unfortunately, the lengthy discussion happened to coincide with the beginning of the work here on using the SPDX identifiers in the kernel. In a perfect world, we would have completed that change before you all started this, but sometimes things don’t go according to best timing! > > >> Now, what should we do with all the GPL-2.0 and GPL-2.0+ tags that we have? > > These are still valid identifiers (albeit deprecated), > so there is no urgent need to have them replaced. This is correct. It would be nice if any new identifiers used the current ones. If the old identifiers get updated as other patches are done to those files or something organic like that, that would be great, but no rush. We’ve got plenty to focus on with getting the identifiers in there, sorting out the “messy” files and so on! Thanks again for all the work on this! Jilayne SPDX legal team co-lead > > -- zvr - > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Gary Kershaw > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928
RE: [GIT PULL] SPDX update for 5.2-rc1 - round 1
> -Original Message- > From: linux-spdx-ow...@vger.kernel.org > On Behalf Of Alexandre Belloni > Sent: Wednesday, 29 May, 2019 15:13 > Subject: Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1 > > Hello, > > On 21/05/2019 15:32:57+0200, Greg KH wrote: > > - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan > > I'm very confused by those two tags because they are not mentioned in the > SPDX 2.1 specification or the kernel documentation and seem to just be from > https://spdx.org/ids-howi which doesn't seem to be versionned anywhere. > While I understand the rationale behind those, I believe the correct way of > introducing them would be first to add them in the spec and documentation > and then make use of them. The "GPL-2.0-only" and "GPL-2.0-or-later" are license short identifiers. They do not belong to the SPDX spec, but rather on the license list. They were introduced in the SPDX License List v3.0 (current version is 3.5): https://spdx.org/licenses/ It seems the examples in the kernel documentation use identifiers from earlier versions of the license list. > Now, what should we do with all the GPL-2.0 and GPL-2.0+ tags that we have? These are still valid identifiers (albeit deprecated), so there is no urgent need to have them replaced. -- zvr - Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
Alexandre,
On Wed, 29 May 2019, Alexandre Belloni wrote:
> Hello,
>
> On 21/05/2019 15:32:57+0200, Greg KH wrote:
> > - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan
>
> I'm very confused by those two tags because they are not mentioned in
> the SPDX 2.1 specification or the kernel documentation and seem to just
> be from https://spdx.org/ids-howi which doesn't seem to be versionned
> anywhere.
https://spdx.org/licenses/
is versioned. It's at version 3.5 and the -only/-or-later tags have been
introduced in version 3.0. See
https://spdx.org/licenses/GPL-2.0
> While I understand the rationale behind those, I believe the correct way
> of introducing them would be first to add them in the spec and
> documentation and then make use of them.
Well, the problem was that people started to use them and argued that they
are the new standard, which is true. So we decided to allow both. See:
9376ff9ba298 ("LICENSES/GPL2.0: Add GPL-2.0-only/or-later as valid
identifiers")
> Now, what should we do with all the GPL-2.0 and GPL-2.0+ tags that we
> have?
Nothing. Leave them alone. Both are valid and tools have to deal with them
anyway.
Thanks,
tglx
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
Hello, On 21/05/2019 15:32:57+0200, Greg KH wrote: > - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan I'm very confused by those two tags because they are not mentioned in the SPDX 2.1 specification or the kernel documentation and seem to just be from https://spdx.org/ids-howi which doesn't seem to be versionned anywhere. While I understand the rationale behind those, I believe the correct way of introducing them would be first to add them in the spec and documentation and then make use of them. Now, what should we do with all the GPL-2.0 and GPL-2.0+ tags that we have? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Wed, 22 May 2019, Joe Perches wrote: > On Thu, 2019-05-23 at 11:49 +0900, Masahiro Yamada wrote: > > On Wed, May 22, 2019 at 3:37 PM Joe Perches wrote: > [] > > > 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 > > > . > > > > We have control for minimal tool versions for building the kernel, > > so I think // will be OK for in-kernel headers. > > > > > > On the other hand, I am not quite sure about UAPI headers. > > We cannot define minimum tool versions > > for building user-space. > > Perhaps, using // in UAPI headers causes a problem > > if an ancient compiler is used? > > Good point. Thanks. Indeed. Did not think about the UAPI part at all. Thanks, tglx
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Thu, 2019-05-23 at 11:49 +0900, Masahiro Yamada wrote: > On Wed, May 22, 2019 at 3:37 PM Joe Perches wrote: [] > > 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 > > . > > We have control for minimal tool versions for building the kernel, > so I think // will be OK for in-kernel headers. > > > On the other hand, I am not quite sure about UAPI headers. > We cannot define minimum tool versions > for building user-space. > Perhaps, using // in UAPI headers causes a problem > if an ancient compiler is used? Good point. Thanks.
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Wed, May 22, 2019 at 3:37 PM Joe Perches wrote: > > 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. > > (https://spdx.org/licenses/GPL-2.0.html) > > > > But, I saw negative reaction to this: > > https://lore.kernel.org/patchwork/patch/975394/ > > > > 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, 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. > > 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 > > whereas > > SPDX-License-Identifier: GPL-2.0-only > > seems fairly descriptive. > > Is it agreed that the GPL--only and GPL--or-later > forms should be preferred for new SPDX identifiers? I agree. > If so, I'll submit a checkpatch patch. That will be nice. > 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 > . We have control for minimal tool versions for building the kernel, so I think // will be OK for in-kernel headers. On the other hand, I am not quite sure about UAPI headers. We cannot define minimum tool versions for building user-space. Perhaps, using // in UAPI headers causes a problem if an ancient compiler is used? BTW, if we allow to use // in header files, we have no reason to forbid // in assembly files either. We use *.S files (assembly that should be preprocessed) instead of *.s files. So, comments are ripped off by CPP anyway whichever comment style is used. -- Best Regards Masahiro Yamada
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Tue, May 21, 2019 at 12:56:54PM -0700, Linus Torvalds wrote: > On Tue, May 21, 2019 at 6:33 AM Greg KH wrote: > > > > Thomas Gleixner (24): > > treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 1 > > I thought rule 1 was that we don't talk about SPDX replacement? Oh if only that were the case, there's been too much talk, and not enough action over the years. Finally we are trying to fix that... thanks for taking these, greg k-h
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--only and GPL--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
Re: [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. > (https://spdx.org/licenses/GPL-2.0.html) > > But, I saw negative reaction to this: > https://lore.kernel.org/patchwork/patch/975394/ > > 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, 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. 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 whereas SPDX-License-Identifier: GPL-2.0-only seems fairly descriptive. Is it agreed that the GPL--only and GPL--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 // comments .
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Tue, May 21, 2019 at 10:34 PM Greg KH wrote: > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > tags/spdx-5.2-rc2 > > for you to fetch changes up to 7170066ecd289cd8560695b6f86ba8dc723b6505: > > treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 25 > (2019-05-21 11:52:39 +0200) > > > SPDX update for 5.2-rc2, round 1 > > Here are series of patches that add SPDX tags to different kernel files, > based on two different things: > - SPDX entries are added to a bunch of files that we missed a year ago > that do not have any license information at all. > > These were either missed because the tool saw the MODULE_LICENSE() > tag, or some EXPORT_SYMBOL tags, and got confused and thought the > file had a real license, or the files have been added since the last > big sweep, or they were Makefile/Kconfig files, which we didn't > touch last time. > > - 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. (https://spdx.org/licenses/GPL-2.0.html) But, I saw negative reaction to this: https://lore.kernel.org/patchwork/patch/975394/ 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, checkpatch.pl can suggest newer tags in case patch submitters do not even know that deprecation.) Thanks. > These patches have been out for review on the linux-spdx@vger mailing > list, and while they were created by automatic tools, they were > hand-verified by a bunch of different people, all whom names are on the > patches are reviewers. > > The reason for these "large" patches is if we were to continue to > progress at the current rate of change in the kernel, adding license > tags to individual files in different subsystems, we would be finished > in about 10 years at the earliest. > > There will be more series of these types of patches coming over the next > few weeks as the tools and reviewers crunch through the more "odd" > variants of how to say "GPLv2" that developers have come up with over > the years, combined with other fun oddities (GPL + a BSD disclaimer?) > that are being unearthed, with the goal for the whole kernel to be > cleaned up. > > These diffstats are not small, 3840 files are touched, over 10k lines > removed in just 24 patches. > > Signed-off-by: Greg Kroah-Hartman -- Best Regards Masahiro Yamada
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Tue, May 21, 2019 at 6:33 AM Greg KH wrote: > > Thomas Gleixner (24): > treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 1 I thought rule 1 was that we don't talk about SPDX replacement? Linus
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
The pull request you sent on Tue, 21 May 2019 15:32:57 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > tags/spdx-5.2-rc2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2c1212de6f9794a7becba5f219fa6ce8a8222c90 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
