* Re: [PATCH v5 2/2] module: Block a module by TUXEDO from accessing GPL symbols [not found] ` <wnfqe7q2aby76zokkh77jhlwc2dbr243kycmejc4wj5wflywgi@6sox742ip22g> @ 2024-11-18 9:05 ` Daniel Gomez 2024-11-18 14:03 ` Greg Kroah-Hartman 0 siblings, 1 reply; 2+ messages in thread From: Daniel Gomez @ 2024-11-18 9:05 UTC (permalink / raw) To: Uwe Kleine-König, Daniel Gomez, Thomas Gleixner, Greg Kroah-Hartman Cc: Werner Sembach, mcgrof, petr.pavlu, samitolvanen, linux-modules, linux-kernel, linux, vv, cs, linux-spdx On Sat Nov 16, 2024 at 6:20 PM CET, Uwe Kleine-König wrote: > On Sat, Nov 16, 2024 at 09:15:55AM +0100, Daniel Gomez wrote: >> On Fri Nov 15, 2024 at 7:50 PM CET, Werner Sembach wrote: >> > From: Uwe Kleine-König <ukleinek@kernel.org> >> > >> > TUXEDO has not yet relicensed a module for GPLv2+ as a reply from former >> > contributers the committed code under GPLv3+ is awaited. >> >> FYI, the SPDX identifier GPL-2.0+ is deprecated as of 2.0rc2 [1]. I think you'd >> need to use GPL-2.0-or-later [2] instead. And when using the SPDX identifier, >> you don't need to include the full text boilerplate in the source of every file >> as long as you include a LICENSE file or COPYRIGHT file with a copy of the >> license. One example upstream here [3] commit 1a59d1b8e05ea ("treewide: Replace >> GPLv2 boilerplate/reference with SPDX - rule 156"). >> >> [1] https://protect2.fireeye.com/v1/url?k=86f7819c-e78c2b15-86f60ad3-74fe48600034-4f48619e45d5b211&q=1&e=7cb2448b-7ab2-415e-b77d-ad14970bc0a0&u=https%3A%2F%2Fspdx.org%2Flicenses%2FGPL-2.0%2B.html >> [2] https://protect2.fireeye.com/v1/url?k=939eb0bf-f2e51a36-939f3bf0-74fe48600034-b542784fecbfce13&q=1&e=7cb2448b-7ab2-415e-b77d-ad14970bc0a0&u=https%3A%2F%2Fspdx.org%2Flicenses%2FGPL-2.0-or-later.html >> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.12-rc7&id=1a59d1b8e05ea > > If you're convinced that "GPL-2.0-or-later" is the right string to use > (and the following somewhat agrees with you: Thomas and Greg may have decided not deprecating the old identifiers [1] to avoid modifying thousands of files. I think it was expected the SPDX to mark them as equivalent? But I'm not entirely sure if this is the correct approach though as SPDX marks them as deprecated as I mentioned earlier. Thomas, Greg, are we using any specific SPDX version for kernel license identifiers? Why the new identifiers where amended as valid and not replacing [2] the old ones? Was it to avoid replacing all files with the old id? [1] https://lore.kernel.org/all/alpine.DEB.2.21.1804240953460.5261@nanos.tec.linutronix.de/ [2] 9376ff9ba298c983062a12cbbafde506a4eaea71 ("LICENSES/GPL2.0: Add GPL-2.0-only/or-later as valid identifiers") Daniel > > linux$ git rev-parse next/master > 744cf71b8bdfcdd77aaf58395e068b7457634b2c > > linux$ git grep -l -F 'SPDX-License-Identifier: GPL-2.0+' next/master | wc -l > 3640 > > linux$ git grep -l -F 'SPDX-License-Identifier: GPL-2.0-or-later' next/master | wc -l > 9005 > ) > > you can consider patching Documentation/process/license-rules.rst which > currently reads: > > License identifiers for licenses like [L]GPL with the 'or later' option > are constructed by using a "+" for indicating the 'or later' option.:: > > // SPDX-License-Identifier: GPL-2.0+ > // SPDX-License-Identifier: LGPL-2.1+ > > Best regards > Uwe ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v5 2/2] module: Block a module by TUXEDO from accessing GPL symbols 2024-11-18 9:05 ` [PATCH v5 2/2] module: Block a module by TUXEDO from accessing GPL symbols Daniel Gomez @ 2024-11-18 14:03 ` Greg Kroah-Hartman 0 siblings, 0 replies; 2+ messages in thread From: Greg Kroah-Hartman @ 2024-11-18 14:03 UTC (permalink / raw) To: Daniel Gomez Cc: Uwe Kleine-König, Daniel Gomez, Thomas Gleixner, Werner Sembach, mcgrof, petr.pavlu, samitolvanen, linux-modules, linux-kernel, linux, vv, cs, linux-spdx On Mon, Nov 18, 2024 at 10:05:27AM +0100, Daniel Gomez wrote: > Thomas, Greg, are we using any specific SPDX version for kernel license > identifiers? Why the new identifiers where amended as valid and not > replacing [2] the old ones? Was it to avoid replacing all files with the > old id? Yes it was. Let's worry about getting all files in the kernel properly tagged before even considering moving to newer versions of the SPDX specification. When we started this, we used the most up to date tags, but then they changed, and we didn't want to change all of the kernel while half-way in the middle of the conversion. Just leave it as-is please. thanks, greg k-h ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-11-18 14:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20241115185253.1299264-1-wse@tuxedocomputers.com>
[not found] ` <20241115185253.1299264-3-wse@tuxedocomputers.com>
[not found] ` <D5NGCPSP7EO8.28YI337NY203X@kruces.com>
[not found] ` <CGME20241116172026eucas1p2ae18643501640a7c6a3a796c30b60fed@eucas1p2.samsung.com>
[not found] ` <wnfqe7q2aby76zokkh77jhlwc2dbr243kycmejc4wj5wflywgi@6sox742ip22g>
2024-11-18 9:05 ` [PATCH v5 2/2] module: Block a module by TUXEDO from accessing GPL symbols Daniel Gomez
2024-11-18 14:03 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox