* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-12 18:37 ` Leon Romanovsky
@ 2023-02-12 19:52 ` Nick Alcock
2023-02-13 15:53 ` Nick Alcock
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Nick Alcock @ 2023-02-12 19:52 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Conor Dooley, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
On 12 Feb 2023, Leon Romanovsky uttered the following:
> On Fri, Feb 10, 2023 at 08:10:43PM +0000, Conor Dooley wrote:
>> On Fri, Feb 10, 2023 at 07:26:38PM +0000, Nick Alcock wrote:
>> > On 10 Feb 2023, Conor Dooley said:
>> > > FYI $subject seems wrong, this is a PCI patch AFAICT.
>
> <...>
>
>> > kbuild is present in every patch in the series because this is a
>> > kbuild-driven change (the thing it disturbs is part of the build system,
>> > the construction of modules.builtin*). This seems to be common practice
>> > for kbuild-related treewide changes.
>>
>> Okay, I'll take your word for it. It just looked/looks odd to me!
>
> It looks odd to me too. Please add SPDX tag in modules which don't have
> it already, instead of commenting code.
OK, I now have two votes for removal-and-SPDX (you and Luis) and nobody
suggesting that keeping it in but commented out is actually a good idea:
I'll respin with removals instead, and add SPDX to anything so adjusted
that doesn't already have it (if anything).
(I'll stick both the removal and addition in the same commit, so there
is no point at which such files have no declared license at all.)
--
NULL && (void)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-12 18:37 ` Leon Romanovsky
2023-02-12 19:52 ` Nick Alcock
@ 2023-02-13 15:53 ` Nick Alcock
2023-02-13 16:13 ` Nick Alcock
2023-02-13 17:30 ` Jonathan Corbet
3 siblings, 0 replies; 14+ messages in thread
From: Nick Alcock @ 2023-02-13 15:53 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Conor Dooley, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
On 12 Feb 2023, Leon Romanovsky told this:
> On Fri, Feb 10, 2023 at 08:10:43PM +0000, Conor Dooley wrote:
>> On Fri, Feb 10, 2023 at 07:26:38PM +0000, Nick Alcock wrote:
>> > On 10 Feb 2023, Conor Dooley said:
>> > > FYI $subject seems wrong, this is a PCI patch AFAICT.
>
> <...>
>
>> > kbuild is present in every patch in the series because this is a
>> > kbuild-driven change (the thing it disturbs is part of the build system,
>> > the construction of modules.builtin*). This seems to be common practice
>> > for kbuild-related treewide changes.
>>
>> Okay, I'll take your word for it. It just looked/looks odd to me!
>
> It looks odd to me too. Please add SPDX tag in modules which don't have
> it already, instead of commenting code.
Alas... nearly all of them *do* have it already, and in most cases it is
different. Usually not *very* different, but different. In most cases it
is more specific, e.g. drivers/soc/fujitsu/a64fx-diag.c, where we have
MODULE_LICENSE("GPL") but SPDX says it's GPL-2.0-only, but then there
are things like lib/packing.c, which throughout its history in the tree
has combined // SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
and MODULE_LICENSE("GPL v2"); which are just not the same thing.
I commented the MODULE_LICENSEs out specifically because I wanted to
avoid getting into hundreds of simultaneous license flamewars while
trying to get *a different thing entirely* into the kernel (kallmodsyms,
which depends on modules.builtin.objs being correct).
I still don't want to get into hundreds of simultaneous license
flamewars, so I think I'll leave things commented out and let
individual maintainers decide whether they want to reconcile
contradictory info or not.
And if I'm not doing that, I feel I shouldn't really be adding SPDX
headers to files that lack them, given that I demonstrably cannot use
MODULE_LICENSE to tell me what the license is meant to be. But if we
can't rely on MODULE_LICENSE to specify the license, and it seems like
we can't, I'd say that it is truly redundant in those files that have
SPDXs, and should probably emit a series that removes MODULE_LICENSE
when files have SPDXes, and comments them out otherwise.
Does that sound reasonable to everyone?
--
NULL && (void)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-12 18:37 ` Leon Romanovsky
2023-02-12 19:52 ` Nick Alcock
2023-02-13 15:53 ` Nick Alcock
@ 2023-02-13 16:13 ` Nick Alcock
2023-02-13 16:51 ` Conor Dooley
2023-02-13 17:06 ` Leon Romanovsky
2023-02-13 17:30 ` Jonathan Corbet
3 siblings, 2 replies; 14+ messages in thread
From: Nick Alcock @ 2023-02-13 16:13 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Conor Dooley, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
[Modified resend: my MTA claimed not to send it but then sent it to some
recipients anyway, and then I was asked not to do some of the things
I'd offered after I sent it.]
On 12 Feb 2023, Leon Romanovsky told this:
> On Fri, Feb 10, 2023 at 08:10:43PM +0000, Conor Dooley wrote:
>> On Fri, Feb 10, 2023 at 07:26:38PM +0000, Nick Alcock wrote:
>> > On 10 Feb 2023, Conor Dooley said:
>> > > FYI $subject seems wrong, this is a PCI patch AFAICT.
>
> <...>
>
>> > kbuild is present in every patch in the series because this is a
>> > kbuild-driven change (the thing it disturbs is part of the build system,
>> > the construction of modules.builtin*). This seems to be common practice
>> > for kbuild-related treewide changes.
>>
>> Okay, I'll take your word for it. It just looked/looks odd to me!
>
> It looks odd to me too. Please add SPDX tag in modules which don't have
> it already, instead of commenting code.
Alas... nearly all of them *do* have it already, and in most cases it is
different. Usually not *very* different, but different. In most cases it
is more specific, e.g. drivers/soc/fujitsu/a64fx-diag.c, where we have
MODULE_LICENSE("GPL") but SPDX says it's GPL-2.0-only, but then there
are things like lib/packing.c, which throughout its history in the tree
has combined // SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
and MODULE_LICENSE("GPL v2"); which are just not the same thing.
I commented the MODULE_LICENSEs out specifically because I wanted to
avoid getting into hundreds of simultaneous license flamewars while
trying to get *a different thing entirely* into the kernel (kallmodsyms,
which depends on modules.builtin.objs being correct).
I still don't want to get into hundreds of simultaneous license
flamewars or get my employer into legal hot water, so I think I'll leave
things commented out and let individual maintainers decide whether they
want to reconcile any contradictory info that may exist or not (and as
noted *most* of these are conflicting.)
This email is the closest thing I have to indicating what Luis would
prefer (and the only reason I'm doing this is because I need it before
Luis's modules.builtin.objs change can work):
<https://lore.kernel.org/linux-modules/Y5AgMuMu75gne6Ka@bombadil.infradead.org/>
Yes, Luis thinks we can just use SPDX, but given that they are usually
different, making such a change seems well beyond my pay grade. Even in
the PCI domain, we see (second column, MODULE_LICENSE: third: SPDX,
sorry about the line lengths).
drivers/pci/controller/dwc/pcie-histb.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/controller/pci-tegra.c: GPL // SPDX-License-Identifier: GPL-2.0+
drivers/pci/controller/pci-versatile.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/controller/pcie-hisi-error.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/controller/pcie-microchip-host.c: GPL // SPDX-License-Identifier: GPL-2.0
drivers/pci/endpoint/pci-ep-cfs.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/endpoint/pci-epc-core.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/endpoint/pci-epc-mem.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/endpoint/pci-epf-core.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
drivers/pci/hotplug/acpiphp_core.c: GPL // SPDX-License-Identifier: GPL-2.0+
drivers/pci/hotplug/shpchp_core.c: GPL // SPDX-License-Identifier: GPL-2.0+
Not much in the way of consistency here: GPL sometimes means 2.0+ but
sometimes it means 2.0. GPL v2 appears to consistently mean GPL-2.0, but
if you look at other affected modules you soon see inconsistency:
drivers/powercap/powercap_sys.c: GPL v2 // SPDX-License-Identifier: GPL-2.0-only
drivers/firmware/imx/imx-scu.c: GPL v2 // SPDX-License-Identifier: GPL-2.0+
arch/x86/crypto/blake2s-glue.c: GPL v2 // SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/iommu/sun50i-iommu.c: Dual BSD/GPL // SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
We even have
drivers/gpu/drm/drm_mipi_dsi.c: "GPL and additional rights" (header is
non-SPDX -- a BSD license header with advertising clause!)
So SPDX is usually more precise than the MODULE_LICENSE, but is it more
*accurate*? I have no idea, and I don't see how I could possibly know:
going by the presence of advertising clauses that obviously nobody is
obeying it doesn't seem like we can trust header comments to be any more
accurate than MODULE_LICENSE. Best to just leave both in (and comment it
out so it has no side-effects on the build any more, which is all I'm
after).
--
NULL && (void)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-13 16:13 ` Nick Alcock
@ 2023-02-13 16:51 ` Conor Dooley
2023-02-13 17:06 ` Leon Romanovsky
1 sibling, 0 replies; 14+ messages in thread
From: Conor Dooley @ 2023-02-13 16:51 UTC (permalink / raw)
To: Nick Alcock
Cc: Leon Romanovsky, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
[-- Attachment #1.1: Type: text/plain, Size: 5335 bytes --]
On Mon, Feb 13, 2023 at 04:13:00PM +0000, Nick Alcock wrote:
> [Modified resend: my MTA claimed not to send it but then sent it to some
> recipients anyway, and then I was asked not to do some of the things
> I'd offered after I sent it.]
>
> On 12 Feb 2023, Leon Romanovsky told this:
>
> > On Fri, Feb 10, 2023 at 08:10:43PM +0000, Conor Dooley wrote:
> >> On Fri, Feb 10, 2023 at 07:26:38PM +0000, Nick Alcock wrote:
> >> > On 10 Feb 2023, Conor Dooley said:
> >> > > FYI $subject seems wrong, this is a PCI patch AFAICT.
> >
> > <...>
> >
> >> > kbuild is present in every patch in the series because this is a
> >> > kbuild-driven change (the thing it disturbs is part of the build system,
> >> > the construction of modules.builtin*). This seems to be common practice
> >> > for kbuild-related treewide changes.
> >>
> >> Okay, I'll take your word for it. It just looked/looks odd to me!
> >
> > It looks odd to me too. Please add SPDX tag in modules which don't have
> > it already, instead of commenting code.
>
> Alas... nearly all of them *do* have it already, and in most cases it is
> different. Usually not *very* different, but different. In most cases it
> is more specific, e.g. drivers/soc/fujitsu/a64fx-diag.c, where we have
> MODULE_LICENSE("GPL") but SPDX says it's GPL-2.0-only, but then there
> are things like lib/packing.c, which throughout its history in the tree
> has combined // SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
> and MODULE_LICENSE("GPL v2"); which are just not the same thing.
>
> I commented the MODULE_LICENSEs out specifically because I wanted to
> avoid getting into hundreds of simultaneous license flamewars while
> trying to get *a different thing entirely* into the kernel (kallmodsyms,
> which depends on modules.builtin.objs being correct).
>
> I still don't want to get into hundreds of simultaneous license
> flamewars or get my employer into legal hot water, so I think I'll leave
> things commented out and let individual maintainers decide whether they
> want to reconcile any contradictory info that may exist or not (and as
> noted *most* of these are conflicting.)
>
>
> This email is the closest thing I have to indicating what Luis would
> prefer (and the only reason I'm doing this is because I need it before
> Luis's modules.builtin.objs change can work):
>
> <https://lore.kernel.org/linux-modules/Y5AgMuMu75gne6Ka@bombadil.infradead.org/>
>
> Yes, Luis thinks we can just use SPDX, but given that they are usually
> different, making such a change seems well beyond my pay grade. Even in
> the PCI domain, we see (second column, MODULE_LICENSE: third: SPDX,
> sorry about the line lengths).
>
> drivers/pci/controller/dwc/pcie-histb.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/pci-tegra.c: GPL // SPDX-License-Identifier: GPL-2.0+
> drivers/pci/controller/pci-versatile.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/pcie-hisi-error.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/pcie-microchip-host.c: GPL // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-ep-cfs.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-epc-core.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-epc-mem.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-epf-core.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/hotplug/acpiphp_core.c: GPL // SPDX-License-Identifier: GPL-2.0+
> drivers/pci/hotplug/shpchp_core.c: GPL // SPDX-License-Identifier: GPL-2.0+
>
> Not much in the way of consistency here: GPL sometimes means 2.0+ but
> sometimes it means 2.0. GPL v2 appears to consistently mean GPL-2.0, but
> if you look at other affected modules you soon see inconsistency:
>
> drivers/powercap/powercap_sys.c: GPL v2 // SPDX-License-Identifier: GPL-2.0-only
> drivers/firmware/imx/imx-scu.c: GPL v2 // SPDX-License-Identifier: GPL-2.0+
> arch/x86/crypto/blake2s-glue.c: GPL v2 // SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/iommu/sun50i-iommu.c: Dual BSD/GPL // SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
See bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2"
bogosity") for more information on the contents of MODULE_LICENSE.
I don't really have a comment on the rest of this, other than thinking
that, for the microchip one, you should leave it as is & the driver be
changed to be module capable.
>
> We even have
>
> drivers/gpu/drm/drm_mipi_dsi.c: "GPL and additional rights" (header is
> non-SPDX -- a BSD license header with advertising clause!)
>
> So SPDX is usually more precise than the MODULE_LICENSE, but is it more
> *accurate*? I have no idea, and I don't see how I could possibly know:
> going by the presence of advertising clauses that obviously nobody is
> obeying it doesn't seem like we can trust header comments to be any more
> accurate than MODULE_LICENSE. Best to just leave both in (and comment it
> out so it has no side-effects on the build any more, which is all I'm
> after).
>
> --
> NULL && (void)
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-13 16:13 ` Nick Alcock
2023-02-13 16:51 ` Conor Dooley
@ 2023-02-13 17:06 ` Leon Romanovsky
2023-02-15 19:06 ` Nick Alcock
1 sibling, 1 reply; 14+ messages in thread
From: Leon Romanovsky @ 2023-02-13 17:06 UTC (permalink / raw)
To: Nick Alcock
Cc: Conor Dooley, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
On Mon, Feb 13, 2023 at 04:13:00PM +0000, Nick Alcock wrote:
> [Modified resend: my MTA claimed not to send it but then sent it to some
> recipients anyway, and then I was asked not to do some of the things
> I'd offered after I sent it.]
>
> On 12 Feb 2023, Leon Romanovsky told this:
>
> > On Fri, Feb 10, 2023 at 08:10:43PM +0000, Conor Dooley wrote:
> >> On Fri, Feb 10, 2023 at 07:26:38PM +0000, Nick Alcock wrote:
> >> > On 10 Feb 2023, Conor Dooley said:
> >> > > FYI $subject seems wrong, this is a PCI patch AFAICT.
> >
> > <...>
> >
> >> > kbuild is present in every patch in the series because this is a
> >> > kbuild-driven change (the thing it disturbs is part of the build system,
> >> > the construction of modules.builtin*). This seems to be common practice
> >> > for kbuild-related treewide changes.
> >>
> >> Okay, I'll take your word for it. It just looked/looks odd to me!
> >
> > It looks odd to me too. Please add SPDX tag in modules which don't have
> > it already, instead of commenting code.
>
> Alas... nearly all of them *do* have it already, and in most cases it is
> different. Usually not *very* different, but different. In most cases it
> is more specific, e.g. drivers/soc/fujitsu/a64fx-diag.c, where we have
> MODULE_LICENSE("GPL") but SPDX says it's GPL-2.0-only, but then there
> are things like lib/packing.c, which throughout its history in the tree
> has combined // SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
> and MODULE_LICENSE("GPL v2"); which are just not the same thing.
>
> I commented the MODULE_LICENSEs out specifically because I wanted to
> avoid getting into hundreds of simultaneous license flamewars while
> trying to get *a different thing entirely* into the kernel (kallmodsyms,
> which depends on modules.builtin.objs being correct).
>
> I still don't want to get into hundreds of simultaneous license
> flamewars or get my employer into legal hot water, so I think I'll leave
> things commented out and let individual maintainers decide whether they
> want to reconcile any contradictory info that may exist or not (and as
> noted *most* of these are conflicting.)
>
>
> This email is the closest thing I have to indicating what Luis would
> prefer (and the only reason I'm doing this is because I need it before
> Luis's modules.builtin.objs change can work):
>
> <https://lore.kernel.org/linux-modules/Y5AgMuMu75gne6Ka@bombadil.infradead.org/>
>
> Yes, Luis thinks we can just use SPDX, but given that they are usually
> different, making such a change seems well beyond my pay grade. Even in
> the PCI domain, we see (second column, MODULE_LICENSE: third: SPDX,
> sorry about the line lengths).
>
> drivers/pci/controller/dwc/pcie-histb.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/pci-tegra.c: GPL // SPDX-License-Identifier: GPL-2.0+
> drivers/pci/controller/pci-versatile.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/pcie-hisi-error.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/controller/pcie-microchip-host.c: GPL // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-ep-cfs.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-epc-core.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-epc-mem.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/endpoint/pci-epf-core.c: GPL v2 // SPDX-License-Identifier: GPL-2.0
> drivers/pci/hotplug/acpiphp_core.c: GPL // SPDX-License-Identifier: GPL-2.0+
> drivers/pci/hotplug/shpchp_core.c: GPL // SPDX-License-Identifier: GPL-2.0+
>
> Not much in the way of consistency here: GPL sometimes means 2.0+ but
> sometimes it means 2.0. GPL v2 appears to consistently mean GPL-2.0, but
> if you look at other affected modules you soon see inconsistency:
>
> drivers/powercap/powercap_sys.c: GPL v2 // SPDX-License-Identifier: GPL-2.0-only
> drivers/firmware/imx/imx-scu.c: GPL v2 // SPDX-License-Identifier: GPL-2.0+
> arch/x86/crypto/blake2s-glue.c: GPL v2 // SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/iommu/sun50i-iommu.c: Dual BSD/GPL // SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>
> We even have
>
> drivers/gpu/drm/drm_mipi_dsi.c: "GPL and additional rights" (header is
> non-SPDX -- a BSD license header with advertising clause!)
>
> So SPDX is usually more precise than the MODULE_LICENSE, but is it more
> *accurate*? I have no idea, and I don't see how I could possibly know:
> going by the presence of advertising clauses that obviously nobody is
> obeying it doesn't seem like we can trust header comments to be any more
> accurate than MODULE_LICENSE. Best to just leave both in (and comment it
> out so it has no side-effects on the build any more, which is all I'm
> after).
You are overcomplicating things.
First, GPL == GPL v2.
Second, SPDX is the right one. License in module is needed to limit
EXPORT_SYMBOL* exposure.
Third, we have git log and git blame to audit and revert any change.
There is no need in leaving (even as commented) dead code.
Thanks
>
> --
> NULL && (void)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-13 17:06 ` Leon Romanovsky
@ 2023-02-15 19:06 ` Nick Alcock
0 siblings, 0 replies; 14+ messages in thread
From: Nick Alcock @ 2023-02-15 19:06 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Conor Dooley, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
On 13 Feb 2023, Leon Romanovsky said:
> On Mon, Feb 13, 2023 at 04:13:00PM +0000, Nick Alcock wrote:
>> So SPDX is usually more precise than the MODULE_LICENSE, but is it more
>> *accurate*? I have no idea, and I don't see how I could possibly know:
>> going by the presence of advertising clauses that obviously nobody is
>> obeying it doesn't seem like we can trust header comments to be any more
>> accurate than MODULE_LICENSE. Best to just leave both in (and comment it
>> out so it has no side-effects on the build any more, which is all I'm
>> after).
>
> You are overcomplicating things.
>
> First, GPL == GPL v2.
> Second, SPDX is the right one. License in module is needed to limit
> EXPORT_SYMBOL* exposure.
> Third, we have git log and git blame to audit and revert any change.
> There is no need in leaving (even as commented) dead code.
Agreed. I audited the lot anyway -- all those files I'm touching that
lack SPDXes (14 of them) have copyright headers at the top of the file
anyway, so there is *definitely* no legal implication from dropping
this. Moving to just dropping them in the next round.
--
NULL && (void)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-12 18:37 ` Leon Romanovsky
` (2 preceding siblings ...)
2023-02-13 16:13 ` Nick Alcock
@ 2023-02-13 17:30 ` Jonathan Corbet
2023-02-13 19:23 ` Leon Romanovsky
3 siblings, 1 reply; 14+ messages in thread
From: Jonathan Corbet @ 2023-02-13 17:30 UTC (permalink / raw)
To: Leon Romanovsky, Nick Alcock
Cc: Conor Dooley, mcgrof, linux-modules, linux-kernel, linux-pci,
linux-riscv
Leon Romanovsky <leon@kernel.org> writes:
> It looks odd to me too. Please add SPDX tag in modules which don't have
> it already, instead of commenting code.
So I'm just a bystander here and should probably be ignored, but ...
From what I can see, Nick is attempting one of those cross-tree cleanups
that's painful enough to do on its own. This request is asking him to
perform a different, unrelated, and potentially fraught cleanup that the
maintainers of the code in question have not yet managed to get around
to taking care of. This will impede an already prolonged process and,
IMO, unnecessarily so.
Wouldn't it be better to let this work proceed while making a note
of the files still needing SPDX tags?
I'll shut up now :)
Thanks,
jon
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-13 17:30 ` Jonathan Corbet
@ 2023-02-13 19:23 ` Leon Romanovsky
2023-02-16 12:05 ` Nick Alcock
0 siblings, 1 reply; 14+ messages in thread
From: Leon Romanovsky @ 2023-02-13 19:23 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Nick Alcock, Conor Dooley, mcgrof, linux-modules, linux-kernel,
linux-pci, linux-riscv
On Mon, Feb 13, 2023 at 10:30:44AM -0700, Jonathan Corbet wrote:
> Leon Romanovsky <leon@kernel.org> writes:
>
> > It looks odd to me too. Please add SPDX tag in modules which don't have
> > it already, instead of commenting code.
>
> So I'm just a bystander here and should probably be ignored, but ...
>
> From what I can see, Nick is attempting one of those cross-tree cleanups
> that's painful enough to do on its own. This request is asking him to
> perform a different, unrelated, and potentially fraught cleanup that the
> maintainers of the code in question have not yet managed to get around
> to taking care of. This will impede an already prolonged process and,
> IMO, unnecessarily so.
>
> Wouldn't it be better to let this work proceed while making a note
> of the files still needing SPDX tags?
Please see a note from Nick, who said that these tags were already
in-place for most of the files. If it is hard for him, he can skip
adding new tags. However, the proposed solution is to comment code
and leave dead code is not a right solution.
Thanks
>
> I'll shut up now :)
>
> Thanks,
>
> jon
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
2023-02-13 19:23 ` Leon Romanovsky
@ 2023-02-16 12:05 ` Nick Alcock
0 siblings, 0 replies; 14+ messages in thread
From: Nick Alcock @ 2023-02-16 12:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jonathan Corbet, Conor Dooley, mcgrof, linux-modules,
linux-kernel, linux-pci, linux-riscv
On 13 Feb 2023, Leon Romanovsky told this:
> On Mon, Feb 13, 2023 at 10:30:44AM -0700, Jonathan Corbet wrote:
>> Wouldn't it be better to let this work proceed while making a note
>> of the files still needing SPDX tags?
Since I have this list anyway, I might as well emit it, even if I
believe the general consensus is now to not add SPDXes but leave that up
to individual maintainers (phew).
The files (otherwise touched in the full series) that don't have SPDX tags:
drivers/bus/arm-cci.c
drivers/bus/imx-weim.c
drivers/bus/simple-pm-bus.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/soc/sunxi/sunxi_sram.c
drivers/video/console/vgacon.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
--
NULL && (void)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread