Message-ID:
 <MW5PR13MB563264E8A6049B275B73E472FD9EA@MW5PR13MB5632.namprd13.prod.outlook.com>
Date: Thu, 29 Jan 2026 16:28:53 +0000
From: "Bird, Tim" <Tim.Bird@...y.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: "rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
        "greg@...ah.com"
	<greg@...ah.com>,
        "tglx@...nel.org" <tglx@...nel.org>,
        "linux-spdx@...r.kernel.org" <linux-spdx@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Tim Bird
	<tbird20d@...oo.com>
Subject: RE: [PATCH] kernel: adjust cpu.c SPDX id

> -----Original Message-----
> From: Peter Zijlstra <peterz@...radead.org>
> On Wed, Jan 28, 2026 at 01:04:33PM -0700, Tim Bird wrote:
> > From: Tim Bird <tbird20d@...oo.com>
> >
> > Rusty Russell's intent was to have his files licensed as
> > GPL-2.0-or-later.  Reflect that intent by adjusting the
> > SPDX-License-Identifier line for cpu.c
> >
> > Signed-off-by: Tim Bird <tbird20d@...oo.com>
> > Link: https://lore.kernel.org/linux-spdx/875x8yw4n6.fsf@rustcorp.com.au/
> > ---
> >  kernel/cpu.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index 5185c0be847a0..a7a1cf8ea8e08 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -1,4 +1,4 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> >  /* CPU control.
> >   * (C) 2001, 2002, 2003, 2004 Rusty Russell
> >   */

Hey Peter,

My apologies in advance for what is going to be a long response...

> 
> While seeing this fly by (and I really don't care too deeply), I did
> make me wonder to the purpose and efficacy of the SPDX header itself.

Indeed, it is an imperfect system.  More on this below.

> 
> That is; while Rusty prefers GPL2+, not many of the actual lines in that
> file are actually still authored by him. What if those authors prefer
> something else?

I understand.  Hopefully, there's not a lot of dissension between authors
on acceptable licensing, but it's bound to happen.  (And I get that you're
raising a hypothetical here.  So far, no authors of cpu.c have directly said
that they disagree with 'GPL-2.0-or-later' for this file, but you raise an
interesting point that I'll give my thoughts on.)

> 
> That is, why are we accounting copyright per file, rather than per
> author or even commit (git-blame FTW and all).

Well, to be precise the SPDX line asserts license per file, not copyright.
But copyright has the same problem.  You are right that the granularity
of the licensing should not necessarily follow file boundaries, but
rather author or contribution boundaries.  Copyright should also follow
different boundaries than file boundaries.  Both license and copyright
information for the kernel have a fair amount of ambiguity, for both
historical and practical reasons.  Over time developers have worked
to reduce the ambiguity for licensing through a number of actions (including applying
SPDX identifier lines).

The use of per-file copyright lines and licensing lines represents (IMHO) a
tradeoff between perfection and practicality.  The reality is that copyright law
(upon which the licensing is based) does not really handle collaborative works,
such as open source software, very well.

> 
> Most of the current lines (by a fair margin) seem to belong to Thomas,
> so lets throw him under the bus and ponder the hypothetical that he very
> strongly prefers GPL2 rather than GPL2+, how does the SPDX header make
> sense?

A single licensing line (just like a single copyright line, or even a small set of
copyright lines) will, in some cases, never perfectly and accurately reflect the intent of all
authors of a file.  In cases where there is dispute between authors, I would lean
towards resolving the dispute in the following manner:
 - try, as much as possible, to get as many authors as possible to come to an agreement they
   can all live with
 - absent such a consensus, rely on some 'fairness' doctrine, such as going with the decision
   of some majority of contributors.

In my own SPDX line application work, I try to understand the intent of the original authors and the current
maintainers to see what they think.  I could do something more exhaustive like try to contact
all contributors for current lines in the file (doing some kind of git blame conversion to authors),
or even all authors since the creation of the file.  Given the amount of time the kernel has been
in existence, and the nature of the involvement of contributors to the kernel, this is not guaranteed
to get the intent of everyone who might have a claim in the licensing decision.

I also weigh, as factors, 1) when the file was introduced, 2) whether the file already includes
licensing info, and how clear it is, 3) whether the overall project (ie Linux kernel) licensing was clear
to contributors, and 4) how likely subsequent contributors were to be aware of the license for the
project and individual file, at the time of their contribution.

This is the first time a potential dispute has been raised, and I don't want to burden the process
too much for what might be a rare case.  Otherwise, the whole process will get bogged down trying
to achieve perfection when only *advancement* in licensing clarity is desired.

I think in many cases, the parties involved don't have strong enough feelings to object to the licensing
that I have concluded to apply using my research.

As a side note, I believe that the difference between GPL-2.0 and GPL-2.0-or-later for a Linux kernel file is negligible.
There are multiple reasons for this, but one of the strongest, I believe, is that there is no operating
system kernel that is licensed GPL 3.0 where files from the Linux kernel would have any useful applicability.
If code from a GPL-2.0-or-later file from the Linux kernel was applied to a GPL-3.0 operating system,
I suspect it would have to be substantially modified sufficient to render a copyright claim (and license claim)
invalid (or at least weak).

Now, getting back to this specific case, if it would be helpful, I can do a contributor analysis on the file,
and try to get consensus among more contributors than are currently on this thread.  My strong preference
would be to have any developers who disagree with each other on the proposed SPDX license come to
a consensus with each other on a license they can all live with.  Absent that, I'll try to make a reasonable
and fair assignment, based on the facts at hand and additional analysis.  Please note that the original stated
license information was pretty clear in indicating that the license was "GPL", without any additional qualifiers
about current or future versions of the license.  The exact licensing line used in the original contribution, and
throughout the life of the file, was:

 * This code is licenced under the GPL.

Given that the kernel's license was GPL 2.0 at the time of original authorship, and that additional contributors likely
contributed code with that understanding, I'm inclined to stay with the 'GPL-2.0' license identifier for this
file.  But I'm happy to listen to additional arguments and information.  And I'm happy to do additional research
on the intent of as many authors and contributors as possible, if it would be helpful to resolve this issue.

If no one responds to this email with any objections, I'll interpret that as assent, and let the current patch
(applying a 'GPL-2.0-or-later' id) stand.  That gives Rusty, who is the only person to directly and affirmatively
object to 'GPL-2.0', the say.

Regards,
 -- Tim

Powered by blists - more mailing lists