LKML Archive on
 help / color / Atom feed
From: Kash Pande <>
Subject: Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
Date: Tue, 15 Jan 2019 10:51:18 -0800
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 3208 bytes --]

On 2019-01-15 5:42 a.m., Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 02:01:48PM +0100, Rene Schickbauer wrote:
>> To be frank, your argument, which boils down to "GPL is the only correct
>> open source license", makes me ashamed to have been advocating people
>> switching to Linux. This is exactly the kind of argument that made me switch
>> away from closed source operating systems like Windows, only then it was
>> Steve Ballmer using it against open source.
> What?
> No, my argument is, "If you want to interact directly with Linux kernel
> code in kernel-space, then you have to abide by it's license, which is
> GPLv2".  That's it.  If you wish to use open source code by another
> license, wonderful, I'm not telling you what you can, and can not do,
> but please, do not violate the license of the code I contributed under
> GPLv2.

You mean "if you want to interact directly with arbitrary Linux kernel
functionality that we deem GPL-only, then you have to abide by its license"

Because the GPL-only symbol export makes it seem like most symbols are
NOT GPL-only. Why is there any distinction at all?

Why does the Linux kernel allow loading of non-GPL modules? Maybe it's
because the end user is ALLOWED to load non-GPL modules?

ZFS is ALLOWED to exist in the Linux ecosystem. It is not ALLOWED to be
distributed with the Linux kernel in binary form. The source trees can
not be merged without patent issues. No one is debating this.

What the issue here, is that previously a non-GPL module was working,
and now is not. NVIDIA is running GPL code?

> ZFS could be the best filesystem ever to grace this planet, that's
> fantastic, but given that the creators of that code placed it under a
> license that was specifically designed to not be compatible with Linux
> to prevent it from ever being used on Linux, well, you can see why I
> really don't care about it.  Why would I?

Asked last week for a source on this and you haven't provided any.
However, the SFLC plainly disagrees with you.

> Those copyright owners (well license owner at this point in time) could
> fix this all tomorrow if they wanted to.  But they do not, so _THEY_ are
> the people you should be upset at.  Not at the Linux kernel developers
> who are giving you a kernel on which to use on your systems, for free,
> under the GPLv2.  Our position has always been very clear and upfront.
> And really, so has the ZFS license creators.  So why is anyone upset
> about all of this?  Nothing new has changed here with the license of
> anything.

The previous situation was the STATUS QUO for years. Since 2012 we had
working ZFS on Linux with SIMD extensions, and now suddenly being told
that it is a license violation.

This is why people are upset at you, because you stand here waving a big
stick and telling us that we are breaking some rule you have merely

> best of luck!
> greg k-h

Message received, loud and clear. We will go back to wrapping GPL-only
exports in our SPL (GPL licensed) kernel module. The Condom Works!

Best of luck with your windmills, Don Quixote.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-01-07 22:08 ` Marc Dionne
2019-01-09 11:19   ` Sebastian Andrzej Siewior
2019-01-09 16:52     ` Greg Kroah-Hartman
2019-01-09 17:09       ` Sebastian Andrzej Siewior
2019-01-09 17:40         ` Marc Dionne
2019-01-10 13:13           ` Greg Kroah-Hartman
2019-01-10 13:11         ` Greg Kroah-Hartman
2019-01-10 17:32           ` Hutter, Tony
2019-01-10 18:07             ` Sebastian Andrzej Siewior
2019-01-10 18:24               ` Greg Kroah-Hartman
2019-01-11  3:18                 ` Kash Pande
2019-01-11  5:04                 ` Lukas Wunner
2019-01-11  5:40                   ` Greg Kroah-Hartman
2019-01-11 18:06                     ` Lukas Wunner
2019-01-23 15:58                     ` Pavel Machek
2019-01-15 13:01                 ` Rene Schickbauer
2019-01-15 13:32                   ` Christoph Hellwig
2019-01-15 13:42                   ` Greg Kroah-Hartman
2019-01-15 18:51                     ` Kash Pande [this message]
2019-01-21 12:30                     ` Stephan von Krawczynski
2019-01-15 18:26                 ` Kash Pande
2019-01-11  3:07 Kash Pande
     [not found] <20190111054058.GA27966 () kroah ! com>
2019-01-11  6:24 ` Kash Pande

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone