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
References: <20230210164749.368998-1-nick.alcock@oracle.com>
        <20230210164749.368998-9-nick.alcock@oracle.com>
        <Y+aMh5e9bWaTphiZ@spud> <871qmx1fv5.fsf@esperi.org.uk>
        <Y+akw9VBjg9oZ7QV@spud> <Y+kx3fb2Lzlg+u5+@unreal>
Emacs:  more boundary conditions than the Middle East.
Date:   Mon, 13 Feb 2023 15:53:56 +0000
In-Reply-To: <Y+kx3fb2Lzlg+u5+@unreal> (Leon Romanovsky's message of "Sun, 12
        Feb 2023 20:37:17 +0200")
Message-ID: <87lel1y31n.fsf@esperi.org.uk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.91 (gnu/linux)
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OQpKN1InE06W1YBaJRKj8fTpVuPqsVDW1dLMvxBqufoPMmEaiS51ovd+qNQH?=
 =?us-ascii?Q?SlrX+kKE3w4RiyKy3Qe2hk93HDi/iIRu8ZJRpPCxlOiflDmN+8IKth6H/s6l?=
 =?us-ascii?Q?2nAQ5c2Y2EmrYofTDposJNey1/a+apKXWzjO3Nx3YuSWn0k/31vphwWzu7km?=
 =?us-ascii?Q?n0Ourqn57JaFZ4dgURo+vNiW93bPxhs2k5/+uTvtqpec28uyZ+iL7r7Z07aS?=
 =?us-ascii?Q?7izteu1Y2QEs/UOObZAUV6TVTtFC6uL0OoL7ywaymW52CdIWh1U5kDdNj2d9?=
 =?us-ascii?Q?BJ2aNlpA4aXNNlB2tDJlwE3BO+/q7bjMAithUBUpBZgwBWVXMjgmc+g+MXnu?=
 =?us-ascii?Q?UPIChFJzoXISJPdwWrh+PYb1dRWrnW6T/qgarTounJAmUVsd1rYjxjDNL0ae?=
 =?us-ascii?Q?I4YbJyMH16Ov7cLriF49tWH5iaSkBPZkMQK+8+tAiGcjVDAkFMT42tPgrlrl?=
 =?us-ascii?Q?2kw/Nj/XeGFvaiBD7SCteaB27KXJ/PH9CQVhatvYVpsCa8MfWPbvabz6i8p/?=
 =?us-ascii?Q?tVleMoXKZRWuJFwn/f4FuVSKEVu6WxAYnbc44mys2R39oilHyRqQe9dIdrxB?=
 =?us-ascii?Q?i2l7WALNhyh0/HrYxQr401SfD/KLURCKQUr6GdbVCy6pqVqIm2eav5QpuwJJ?=
 =?us-ascii?Q?SYH1FaiFD7tmWLzj7Yu2wGliCiCgmTZ3j6pFhfUtaHC26y2bV0R3Gx0H6zkH?=
 =?us-ascii?Q?Z1rLZS6s61B1audeT9KQKdb042Gu8zPQqRtfGR69YdPW2XVl26G+MBqv0E7c?=
 =?us-ascii?Q?AhQKmrO3lMA97FZmYmLPp2WNqyXeJlcexNPGPMwjKwLHV8jwJBh0M5tf73HZ?=
 =?us-ascii?Q?7Hgp0gBEOYrPVvhg5xGRuhpZfh5tdbr1HPSp1IatUvC/IYBWBnX9x3SFyiSi?=
 =?us-ascii?Q?/ALVSIvnHsuVQS364vMdLgoLSWKG5h913X+wie8YIqJMor3KfZIdXJI/BvoJ?=
 =?us-ascii?Q?Ikg69gOctEmNNxE4YO073M9UDyq6U2gw9N977QTIloaqc7Z7mKA1IbFylLiJ?=
 =?us-ascii?Q?JQrCd+i4g94CcYavO+8LMtEYdfFeZAtlzkllltKtyM4fsxUAU88T2eRcIUMa?=
 =?us-ascii?Q?hi9/J1PR/PDBvDXouPh1onX7leXEmG62FeWgskKFXe6hKBtadgh2GNHBNHGR?=
 =?us-ascii?Q?5agrAOLD/vz8+F8TuKca1k9Smau1ptaMW5jmrnvUalrzQy/ZRGrF1nmWamfb?=
 =?us-ascii?Q?Dak1lFGZ3LHcvm/WbOrg35mU268LoXZiB1Fc309OcfjqhpB1rGmSe1uE4b7Y?=
 =?us-ascii?Q?3HSaitWC+6kuOdpquAKOm3KitI5JlfsDbzrISYpMjiQHib5wGKToUugs9t0I?=
 =?us-ascii?Q?FPPUcMRYw4CUUuvMBkw98qQMCxgM9oBJFc2wymU3kPY0kSbkKn/9V5skiwCG?=
 =?us-ascii?Q?dbTNWuXO+AxGpsX5LEvDCecZUjdFSY9ZEcvBT41SgAS0cuqv8IXoP6q4P4OY?=
 =?us-ascii?Q?Yu1dO6QplnwWUe3b1j4rpcjs5CxINAG7s+4DNpYmbpxjSEQnnQgney6NV2GP?=
 =?us-ascii?Q?3EZIZBlHL3q1FRZquIK94HhEV+MS1ZsHkLXangXIGW6W6Pzs8cEwtqGVVOjb?=
 =?us-ascii?Q?SHa3YLx7p/G+CUqYtCcW2KIrGJPm3Kn6prSoyYNWH33k1ULlp4RUmoOCyqHp?=
 =?us-ascii?Q?2A=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: DFPHuRg7V0MVVslZz6713Izf3DK2O9ek/EErlIu35ZR7dXlvX47VE04KFyTXGqptVk9u0UJ42XdYasO5ZESfZfZw+Kqk0EwdSjK4JQwTrS8uleaNjL6wCTta8cLgGxAsW/nsNYLXr5Q44DunH16/YJIB484+NxSIlzLj5GMoEVTqzLh1jQAWx9J+kNflcncCm/ZHBdiXAomMNolkjFhvUbtQLO+oJl9BW3irqMeWm1wRif26qWeVlVdDSZahiMjvq0EOI4yfr6GJXCCbLIQSrIa44z0BpQINU0S1ryUhwT7qgEQgOEHm3NYC9W3HQ6uu1d399wZGSXGAm1AKyb82M8N4sLJLySQ50P+6xjPapHl5FGgZYunGhPbR4ObkQZgEexV4HmfXJH8I+Y4JWWx5Qj5aXIEUbVnj1KcdbKLG9J01vuDKTi20twXzE+ifG3/BYQx2jqmKp72XSK05MGd2FlkRMpqmrt7j6b6DTQJ62WHYG3KC67D3gSa5qjOBlHuCKbCbGbZm1BKxUscpgyILWVrHwhvwZ/WYcyFx+eEKiLV3BTHbDRfVGvPQ41RtCX9WcDaV4JGHodItvg5ynZkdF10QpeKjm8rqzKpwwp/1OgPxqEX3KO9CXI9nmn6qmKoiL+UIMh8Lo01xOCG3TJqIOwhD3inLQRFgtoEGx7bPa9JXewcVZr1Jbr07j+wuY5tAD+6BAQwNnQv6hXTYLAutVxhSDhxCArnpOwn9qt0CmT0AFJcOwHWJx8BVGm94kK7MR81+hL5s/78igZvq1uD5w94t4IQb9SSeNFLH8y1/KgmjFb2KGHn629BDIEu10mWMTUZAQaWVBWFTk8L0WSRLWQ==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 49bc284d-d1f0-4534-0854-08db0dda8627
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB6798.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2023 15:54:01.0762
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Oh1K519C4mJmFcli9cibplHnHkcUQCxDU+cK8IdpeMFs5RBd/1JB1bw4mPu3jZPs0WtrIRZx88Fe1rNUM/VCLA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB7213
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22
 definitions=2023-02-13_11,2023-02-13_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0
 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 adultscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2302130144
X-Proofpoint-GUID: qrcQZM6MDdhGNdwL5IChIRwgYw0eMKnj
X-Proofpoint-ORIG-GUID: qrcQZM6MDdhGNdwL5IChIRwgYw0eMKnj
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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)