On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > But since when did out-of-tree modules use __kernel_fpu_begin? It's an
> > x86-only thing, and shouldn't really be used by anyone, right?
>
> ZFS on Linux uses it for checksums. Its removal is currently breaking ZFS builds against 5.0:
So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
Well the crypto API is GPL only exported so that won't work. crc32c() is
EXPORT_SYMBOL() so it would work.
On the other hand it does not look right to provide a EXPORT_SYMBOL
wrapper around a GPL only interface…
Sebastian
On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > > But since when did out-of-tree modules use __kernel_fpu_begin? It's an
> > > x86-only thing, and shouldn't really be used by anyone, right?
> >
> > ZFS on Linux uses it for checksums. Its removal is currently breaking ZFS builds against 5.0:
>
> So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
> Well the crypto API is GPL only exported so that won't work. crc32c() is
> EXPORT_SYMBOL() so it would work.
> On the other hand it does not look right to provide a EXPORT_SYMBOL
> wrapper around a GPL only interface…
Yes, the "GPL condom" attempt doesn't work at all. It's been shot down
a long time ago in the courts.
My tolerance for ZFS is pretty non-existant. Sun explicitly did not
want their code to work on Linux, so why would we do extra work to get
their code to work properly?
greg k-h
On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> > want their code to work on Linux, so why would we do extra work to get
> > their code to work properly?
>
> ZoL facilitates seamless r/w cross-mounting with macOS, something no
> other filesystem allows, and that feature is critical for me to work
> on Linux drivers for Mac hardware. Please don't make life harder than
> necessary for developers like me. Your "extra work" argument seems
> disingenuous to me, Sebastian's patch is causing extra work for
> ZFS developers, not the kernel community. The maintenance burden
> for the kernel community to retain the export is zero.
Sorry, no, we do not keep symbols exported for no in-kernel users.
greg k-h
> Yes, the "GPL condom" attempt doesn't work at all. It's been shot down
> a long time ago in the courts.
SFLC maintains there is no kernel licensing issue[1].
As a side note, even Hellwig's suit against VMware was dismissed (he may
appeal)[2].
Debian and Canonical base their decision to ship DKMS source for ZFS on
Linux[3].
The GPL does not disqualify a user from compiling ZFS or Linux however
they see fit.
It is only the users' distribution rights that come into question.
No one is combing ZFS into Linux or even distributing binary modules here;
we're following the terms of GPL.
> My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?
1. Should your personal feelings affect the quality of the Linux kernel?
I say no.
2. Did Sun or Oracle ever release any statement of any kind that backs
your statement?
3. What extra work is being done here aside from the dropping of a
pseudo-protection,
the "GPL ONLY" symbol export? Something tells me, even if someone else
did "the work"
and submitted patches, you would find a reason to tell them to get
stuffed and leave
it "as-is".
With all of that... why have ANY kind of tolerance for out of tree
kernel modules at all?
[1] https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html
[2] https://opensource.com/law/16/8/gpl-enforcement-action-hellwig-v-vmware
[3] https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html
On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?
ZoL facilitates seamless r/w cross-mounting with macOS, something no
other filesystem allows, and that feature is critical for me to work
on Linux drivers for Mac hardware. Please don't make life harder than
necessary for developers like me. Your "extra work" argument seems
disingenuous to me, Sebastian's patch is causing extra work for
ZFS developers, not the kernel community. The maintenance burden
for the kernel community to retain the export is zero.
I respectfully ask for 12209993e98c to be reverted, or alternatively
amended to keep ZoL working.
Thanks,
Lukas
[cc += Ingo]
On Fri, Jan 11, 2019 at 06:40:58AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> > On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > > My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> > > want their code to work on Linux, so why would we do extra work to get
> > > their code to work properly?
> >
> > ZoL facilitates seamless r/w cross-mounting with macOS, something no
> > other filesystem allows, and that feature is critical for me to work
> > on Linux drivers for Mac hardware. Please don't make life harder than
> > necessary for developers like me. Your "extra work" argument seems
> > disingenuous to me, Sebastian's patch is causing extra work for
> > ZFS developers, not the kernel community. The maintenance burden
> > for the kernel community to retain the export is zero.
>
> Sorry, no, we do not keep symbols exported for no in-kernel users.
AFAICS the only other alternative would be to remove the _GPL from
the export of kernel_fpu_begin()/end(). Those functions were static
inlines until v4.2 when Ingo uninlined them with commit d63e79b114c0
(x86/fpu: Uninline kernel_fpu_begin()/end()).
Ingo, why did you choose _GPL back then, given that the functions
were not restricted to GPL before? Any objections to making them
available to non-GPL again?
As it stands, v5.0 removes the ability from non-GPL modules to use
the FPU or SIMD instructions and that kills ZFS on Linux. This isn't
hurting Oracle, they're not using OpenZFS, it's only hurting ZoL users.
Thanks,
Lukas
On 10.01.19 19:24, Greg Kroah-Hartman wrote:
Dear Greg!
> My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?
I'm not a kernel developer. I'm an application developer and system
administrator. I'm also an Open Source advocate who regularly holds
talks at Austrias biggest Linux conference in Graz.
Usually i'm not too interested in the internals of Linux kernel
development, but this issue affects me on many levels.
ZFS brings me a lot of features, convenience and, most important of all,
stability and reliability that i'm missing in other Linux filesystems.
ZFS on Linux is open source, made by people who invest their time and
money into creating and maintaining a great filesystem. How can you say
they are wrong in doing so?
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.
I understand that different open source licenses have different
mindsets. But that doesn't make those other licenses any less valid.
They still give us developers the freedom to learn, the freedom to build
great systems, the freedom to change the world for the better. Not every
project is able, or willing, to adopt the GPL. (I, for one, release my
software under Perls Artistic license, because the GPL is too
restrictive for my purpose).
So, please try to understand that non-GPL open source is still a useful
resource for many of us out there. Maybe it helps to remember that Linux
might never have existed if Linus Torvalds had never had the ability to
experiment with the Minix source code and got inspired by it to write
something more capable.
As for ZFS and me, ZFS is rather important to my work. If push comes to
shove, i'm more inclined to switching to FreeBSD than to switch to
another filesystem at this point in time. But i'm really hoping that
this issue will get resolved by allowing to continue using non-GPL open
source in Linux.
Sincerely,
Rene Schickbauer
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.
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?
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.
best of luck!
greg k-h
Hi Rene,
please switch to FreeBSD instead of advocating to violate the copyright
and licensing rule on my and others work.
Thanks you!
> Yes, the "GPL condom" attempt doesn't work at all. It's been shot down
> a long time ago in the courts.
SFLC maintains there is no kernel licensing issue[1].
As a side note, even Hellwig's suit against VMware was dismissed (he may
appeal)[2].
Debian and Canonical base their decision to ship DKMS source for ZFS on
Linux[3].
The GPL does not disqualify a user from compiling ZFS or Linux however
they see fit.
It is only the users' distribution rights that come into question.
No one is combing ZFS into Linux or even distributing binary modules here;
we're following the terms of GPL.
> My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?
1. Should your personal feelings affect the quality of the Linux kernel?
I say no.
2. Did Sun or Oracle ever release any statement of any kind that backs
your statement?
3. What extra work is being done here aside from the dropping of a
pseudo-protection,
the "GPL ONLY" symbol export? Something tells me, even if someone else
did "the work"
and submitted patches, you would find a reason to tell them to get
stuffed and leave
it "as-is".
With all of that... why have ANY kind of tolerance for out of tree
kernel modules at all?
[1] https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html
[2] https://opensource.com/law/16/8/gpl-enforcement-action-hellwig-v-vmware
[3] https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html
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
imagined.
>
> 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.
Kash
On Tue, 15 Jan 2019 14:42:21 +0100
Greg Kroah-Hartman <[email protected]> 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.
>
> 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?
>
> 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.
>
> best of luck!
>
> greg k-h
Hi Greg,
I'd say this is in fact more a moral question than a technical or legal issue.
The true background is the simple question what the project (i.e. linux) is in
fact all about, is it about helping people with lower skills or is it about
ruling people. A company (more or less every company) is more about ruling,
its aim is to move people into buying and using its products. Me (and quite
surely Rene at least) think that the linux _community_ is more about helping
others and hopefully less about legal and technical ruling.
So your argument "go to the company XYZ and blame them" isn't really
targetting in the right direction - as long as you see linux still as a
community thing and not as a cash-cow company-alike. Maybe it would be a lot
better to think about why there are people using ZFS and not some GPLed fs
instead. Me too being a ZFS user I can tell you the simple fact that there is
no GPL fs with equal features and stability (eh BTRFS). In fact quite some of
us would probably use HAMMER2 (thanks Matt) instead if sure that it equals ZFS
in terms of stability, still not BTRFS. So all you promote currently is the fs
deficit linux actually still has (and had for years, or say decades). I doubt
that this is/was helping the linux community a lot...
Sure maintainers have to rule sometimes, but it only makes sense if you are
able to present a working equal alternative. If you have none (and in this case
you have no alternative to offer) you will only push people away from the
community and that's probably not the right path for a community maintainer.
--
Only my 2ct,
Stephan
On Fri 2019-01-11 06:40:58, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> > On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > > My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> > > want their code to work on Linux, so why would we do extra work to get
> > > their code to work properly?
> >
> > ZoL facilitates seamless r/w cross-mounting with macOS, something no
> > other filesystem allows, and that feature is critical for me to work
> > on Linux drivers for Mac hardware. Please don't make life harder than
> > necessary for developers like me. Your "extra work" argument seems
> > disingenuous to me, Sebastian's patch is causing extra work for
> > ZFS developers, not the kernel community. The maintenance burden
> > for the kernel community to retain the export is zero.
>
> Sorry, no, we do not keep symbols exported for no in-kernel users.
Killing ZFS is _not_ nice. Its not like ZFS is closed source...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html