All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Conor Dooley <conor@kernel.org>,
	mcgrof@kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
Date: Wed, 15 Feb 2023 19:06:46 +0000	[thread overview]
Message-ID: <873576wxx5.fsf@esperi.org.uk> (raw)
In-Reply-To: <Y+puA2V5BoH/Cbr2@unreal> (Leon Romanovsky's message of "Mon, 13 Feb 2023 19:06:11 +0200")

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)

WARNING: multiple messages have this Message-ID (diff)
From: Nick Alcock <nick.alcock@oracle.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Conor Dooley <conor@kernel.org>,
	mcgrof@kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 8/8] kbuild, PCI: microchip: comment out MODULE_LICENSE in non-modules
Date: Wed, 15 Feb 2023 19:06:46 +0000	[thread overview]
Message-ID: <873576wxx5.fsf@esperi.org.uk> (raw)
In-Reply-To: <Y+puA2V5BoH/Cbr2@unreal> (Leon Romanovsky's message of "Mon, 13 Feb 2023 19:06:11 +0200")

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

  reply	other threads:[~2023-02-15 19:07 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10 16:47 [PATCH 0/8] MODULE_LICENSE removals, first tranche Nick Alcock
2023-02-10 16:47 ` [PATCH 1/8] kbuild, PCI: generic,versatile: comment out MODULE_LICENSE in non-modules Nick Alcock
2023-02-10 16:47   ` Nick Alcock
2023-02-10 17:36   ` Rob Herring
2023-02-10 17:36     ` Rob Herring
2023-02-10 18:43     ` Nick Alcock
2023-02-10 18:43       ` Nick Alcock
2023-02-13 22:57   ` Bjorn Helgaas
2023-02-13 22:57     ` Bjorn Helgaas
2023-02-14 15:41     ` Nick Alcock
2023-02-14 15:41       ` Nick Alcock
2023-02-14 17:20       ` Bjorn Helgaas
2023-02-14 17:20         ` Bjorn Helgaas
2023-02-16 13:34         ` Nick Alcock
2023-02-16 13:34           ` Nick Alcock
2023-02-10 16:47 ` [PATCH 2/8] kbuild, PCI: mobiveil: " Nick Alcock
2023-02-10 16:47 ` [PATCH 3/8] kbuild, ARM: tegra: " Nick Alcock
2023-02-10 16:47 ` [PATCH 4/8] kbuild, PCI: endpoint: " Nick Alcock
2023-02-10 16:47 ` [PATCH 5/8] kbuild, PCI: hip: " Nick Alcock
2023-02-10 16:47 ` [PATCH 6/8] kbuild, shpchp: " Nick Alcock
2023-02-10 16:47 ` [PATCH 7/8] kbuild, PCI: dwc: histb: " Nick Alcock
2023-02-10 16:47 ` [PATCH 8/8] kbuild, PCI: microchip: " Nick Alcock
2023-02-10 16:47   ` Nick Alcock
2023-02-10 18:27   ` Conor Dooley
2023-02-10 18:27     ` Conor Dooley
2023-02-10 19:26     ` Nick Alcock
2023-02-10 19:26       ` Nick Alcock
2023-02-10 20:10       ` Conor Dooley
2023-02-10 20:10         ` Conor Dooley
2023-02-12 18:37         ` Leon Romanovsky
2023-02-12 18:37           ` Leon Romanovsky
2023-02-12 19:52           ` Nick Alcock
2023-02-12 19:52             ` Nick Alcock
2023-02-13 15:53           ` Nick Alcock
2023-02-13 15:53             ` Nick Alcock
2023-02-13 16:13           ` Nick Alcock
2023-02-13 16:13             ` Nick Alcock
2023-02-13 16:51             ` Conor Dooley
2023-02-13 16:51               ` Conor Dooley
2023-02-13 17:06             ` Leon Romanovsky
2023-02-13 17:06               ` Leon Romanovsky
2023-02-15 19:06               ` Nick Alcock [this message]
2023-02-15 19:06                 ` Nick Alcock
2023-02-13 17:30           ` Jonathan Corbet
2023-02-13 17:30             ` Jonathan Corbet
2023-02-13 19:23             ` Leon Romanovsky
2023-02-13 19:23               ` Leon Romanovsky
2023-02-16 12:05               ` Nick Alcock
2023-02-16 12:05                 ` Nick Alcock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873576wxx5.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=conor@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mcgrof@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.