[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171109164427.GA17265@flint.armlinux.org.uk>
Date: Thu, 9 Nov 2017 16:44:27 +0000
From: Russell King <rmk@...linux.org.uk>
To: Christoph Hellwig <hch@...radead.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
linux-kernel@...r.kernel.org,
Johannes Berg <johannes@...solutions.net>,
Takashi Iwai <tiwai@...e.de>, Jiri Kosina <jikos@...nel.org>,
Ciaran Farrell <ciaran.farrell@...e.com>,
Christopher De Nicolo <cdenicolo@...e.com>,
Jeff Mahoney <jeffm@...e.com>,
Vojtech Pavlik <vojtech@...e.cz>, Mel Gorman <mgorman@...e.de>,
Hannes Reinecke <hare@...e.de>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Theodore Ts'o <tytso@....edu>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Kate Stewart <kstewart@...uxfoundation.org>,
Philippe Ombredanne <pombredanne@...b.com>
Subject: Re: [PATCH 5/5] driver core: Remove redundant license text
On Thu, Nov 09, 2017 at 06:00:27AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 09, 2017 at 02:47:40PM +0100, Greg Kroah-Hartman wrote:
> > Was not what? Discussed? Yes it was. I think the lwn.net article even
> > says so.
>
> There is absolutely no public track record of any discussion. And if
> there was any it seems like a large number of the biggest contributors
> and copyright holders in the kernel were excluded.
Yes, and excluded I feel, and it is very alienating. The first I knew
about this was when I got a bunch of git conflicts. That's really not
an acceptable way to find out about this.
My interactions since with GregKH seems to be "I'm doing this, you don't
have any say in it." TBH, the idea of approaching a solicitor to review
whether GregKH's unilateral action is legal has crossed my mind.
> So please state what was decided, where it was deciced, who decided it
> and why as a start.
>
> This whole debacle is not how we normally communicate big changes in
> the kernel community, and that is double worrisome because it is
> an important area with legal implications.
>
> > "which" tag is just SPDX, that's easy. As for "when and how", I don't
> > understand the question.
>
> And where is our defintion of SPDX in our kernel tree? As said in
> another thread, yes I can google it. But that doesn't provide a stable
> defintion, nevermind that we do not even have a pointer to it from
> anywhere in the tree.
>
> If your use of SPDX is apparently fine because people must know I'll
> just invent my own tags and mandate them [1].
>
>
> [1] not that I have anything about the SPDX tags in particular, it's
> just the way you rush them in without even defining them for us.
Thank you, Christoph, for voicing my concerns. I'm very concerned by
the "indirection" problem, and I've mentioned that in a private email
to Linus. However, Linus omitted replying to that point.
We know that the SPDX tags are defined on some website, but by
switching to the tags, it gives that website a lot of power over their
meaning, and I really don't like that.
We can say "oh yes, it's obvious" but obvious doesn't come into it in
the court room when solicitors are arguing over the meaning of a term.
Consider what would happen if someone creates "Gerald's Philosophical
License v2" and the SPDX domain (for whatever reason) ends up being
owned by that person, and they put up a website that apparently
defines a new set of SPDX tags, where "GPLv2" means their own license.
Where is the legal definition that the "GPLv2" SPDX tag means the
license we know today?
I'd be more comfortable if we could have something in the kernel tree
that identifies the SPDX tags and their meaning, maybe with the
_standard_ file header for that license included, so there is no
argument about what any particular SPDX tag means.
Linus did an excellent job of explaining to me (privately) /why/ the
change is being done, but I strongly disagree that the way it is being
done and the timing of the first round of changes was ideal - I believe
the first round of changes happened at the worst possible moment.
However, that bit is now water under the bridge, and we have to live
with that change in terms of the git conflicts now.
--
Russell King
ARM architecture Linux Kernel maintainer
Powered by blists - more mailing lists