[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171108151121.GC10374@infradead.org>
Date: Wed, 8 Nov 2017 07:11:21 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Philippe Ombredanne <pombredanne@...b.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Theodore Ts'o <tytso@....edu>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Eric Sandeen <sandeen@...hat.com>,
xfs <linux-xfs@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Kate Stewart <kstewart@...uxfoundation.org>
Subject: Re: WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license
identifier to files with no license
On Wed, Nov 08, 2017 at 01:35:46PM +0100, Philippe Ombredanne wrote:
> The benefits now and later:
> - no distraction with licensing boilerplate cr*p in patches and files
> - no guessing licensing needed when sending a patch
> - anyone can grep the kernel tree for licensing, no extra tool needed
> - Greg must feel really good about deleting so much things for once
This patch didn't delete anything, it added random notes.
I see now Greg deletes things from files he maintains which is even
worse, given that the kernel tree doesn't document anywhere what these
tags actually mean.
So he deletes a lot of license tags and replaces them with tags he
puts a great significance on, but which aren't defined. A quick googles
shows some Linuxfoundation web page defines them, but they could change
them any time they want, nevermind that we don't even have a reference
to them either.
>
> The downsides:
> - folks can no longer express their creativity in licensing texts like
> licensing thermal code under the "therms" of the GPL [2]
I'd love something like that to happen. But for that we don't need a
sneaky patch that doesn't talk to kernel contributors.
For that we need to
a) agree on which licensing schemes we accept for future contributions
b) cleary document that policy in the kernel tree
c) reject anything that doesn't matter the above policy by manual
and/or automated review
An automated tag scheme might help with b) and c) above if done
properly. But for that we need to document it, agree on it, discuss
it with everyone involved, etc. None of that has happened. Instead
Greg farted arcane tags that he thinks have a legal singnificance
all over three three without talking to the people whos code he tagged,
without any RFC or public discussion, without documenting what his
tags mean or any future strategy towards making use of them.
Powered by blists - more mailing lists