
ZFS Licensing and Linux - rograndom
https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-linux/
======
tw04
I find it odd he uses the term "quite obviously" twice in his post. If it was
so obvious, why bother seeking legal counsel? I think he's doing Ubuntu a
disservice with that kind of response. It makes it seems as though they
haven't put in an appropriate amount of effort to vet this thing out.

I'm also curious as to why they'd have waited so long to include it if the
legal questions were so trivial.

~~~
jpgvm
I imagine the wait was mostly that it wasn't deemed necessary to have ZFS on
Ubuntu until now.

Containerisation has drastically increased interest in CoW filesystems.
Traditionally their only use-case has been for implementing livecds and
similar ro + rw layer environments.

For this AUFS has been the gold standard since basically forever. However AUFS
has some flaws and lack of features that make it undesirable to use in
production container workloads, hence looking to ZFS to fill this gap.

~~~
opk
Note that AUFS has been succeeded by overlayfs which, unlike the various
earlier union fs attempts, has actually been merged into the kernel. I'm not
sure where it stands with regard to flaws

~~~
mjg59
It's pretty flawed - for example, if you open a file read-only, open it again
read-write and the write to it, any read from the first file descriptor won't
show the writes. The corner cases don't bite people under most circumstances,
but when they do they're awful.

~~~
vetrom
That sounds like a fairly normal structured file/multiprocess workload, not
much of a corner case there :(

------
pilif
> Our conclusion is good for Ubuntu users, good for Linux, and good for all of
> free and open source software

I would say that your conclusion is bad for linux and bad for all of free
software. Because if linking your non-gpl-licensed binary blob with the GPLed
kernel is legal then linking any other non-gpl-licensed binary blobs with any
other GPL binary is also legal and thus the GPL is completely worthless.

Is it worth setting such a precedent over the ability to run ZFS on Linux?

~~~
ithkuil
Just some informative notes for those who are not familiar with the
intricacies of GPL. I'm not detracting your point.

Disclaimer: IANAL

The GPLv2 license governs the distribution of software licensed with said
license. It forces anyone who distributes a GPL binary to also distribute the
source code used to build that binary.

If in order to build that particular binary you had to include some other
code, then you have to provide the sources for that code as well. Furthermore,
that code you provide must be distributed in turn under the GPL license. Any
such "added code" becomes part of the thing you distribute and thus
constitutes "derivative work".

The key thing here is that it doesn't matter if the "added code" is just some
bit of extra functionality of if it's the "whole thing" while the GPL code is
just one header. When you build a kernel module, you have use some GPLd
headers at the very least.

This last point technically taints a binary kernel module and forces you to
release all the sources used to build it _and_ release those sources as GPL.

However there are two interesting points here:

1\. Distribution

Notice how the license only mentions distribution. You are allowed to do
whatever you want with a GPL source that you hold on your hands: you can
change it, add some code, link it with other code. There is absolutely nothing
forcing you to immediately release your derivate work to the public and thus
nothing forcing you to release the sources of your derivate work.

This means, that if you build a kernel module on your machine, from a mixture
of sources with GPL and an other licence; you didn't violate the GPL (whether
you violated the other license, it depends on that other license).

Please read very informative:

[http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue](http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue)

TL;DR: ^^^ In the case of the kernel, this prevents us from distributing ZFS
as part of the kernel binary. However, there is nothing in either license that
prevents distributing it in the form of a binary module or in the form of
source code.

2\. Exemptions

[http://www.gnu.org/licenses/old-
licenses/gpl-2.0.en.html](http://www.gnu.org/licenses/old-
licenses/gpl-2.0.en.html)

    
    
        However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
    

This has a much less clear interpretation in the context of kernel modules.
This clause is mainly intended to allow you to use GPL software on a
proprietary operating systems as well as running proprietary software on GPL
operating systems. You can compile it: which means you can include headers
provided by the compiler and OS. And you can run it: which means you can
invoke system calls and/or link it with possibly proprietary libraries that
make up the main interface.

I have no idea whether in the context of a kernel module, the kernel internal
API can fall under this category, given that it's arguable that it doesn't
make up the "main interface" of the linux OS.

\----

How does this relate to the article from canonical ?

They are claiming something entirely different. They claim that the ZFS kernel
module is "evidently" not a derivate work on the grounds that it's self
contained and they cite existing exemptions for other binary drivers such as
those by nvidia.

They don't explicitly mention the exemption on the aforementioned point in the
GPLv2 license text.

Thus, it's not clear how this will affect the observation of the GPL license
and whether it will set a precedent at least for all cases where one can argue
that the binary blob is linked against an well define interface that is meant
to provide an "execution environment". (e.g. plugins, kernel modules, binaries
running inside an OS). Not sure if setting this precedent will eventually
erode the general case of linking though.

The line is thin, but I would have preferred some more explicit reasoning
instead of "we have concluded that we are acting within the rights " and "is
clearly not a derivative work", and finishing with a "As we have already
reached the conclusion, we are not interested in debating license
compatibility".

~~~
jbooth
I wonder what a legal engineering solution looks like.

Clearly ZFS is open source, Linux would profit by including it, but both ZFS
and Linux have licenses that are, at this point, impossible to change for
various reasons.

It seems that the people opposing this move by Ubuntu claim that by linking
against the VFS stuff in Linux, that particular ZFS distribution becomes a
derivative of Linux (weak claim IMO but argiuable) and therefore must be
GPL'd. But it can't be. And we (or I at least) would like to see ZFS on Linux
become easier.

I wonder if some brave soul could make a new, completely superfluous layer of
glue on top of ZFS that's both GPL and CDDL? And then could link that glue to
linux/vfs while leaving ZFS itself in a completely underived state? Would that
satisfy people?

Ultimately we're talking about open source code with nice engineering, here. I
think the whole computing community could benefit from a solution.

Sidenote: I wonder how many people here who claim copyright of an API (vfs)
prohibits this integration felt the exact opposite way when it was Oracle v
Google.

~~~
mkesper
CDDL is not compatible with GPL. So this won't work.

~~~
ithkuil
Not sure it wouldn't work.

Imagine you have a small GPL program, that all it does is to load plugins,
e.g. with dlopen and invokes some function, let's call it "main".

It clearly doesn't care what license the binary loaded that way has.

What i does is to load a binary in memory, locate an address and transfer
control to it. If the GPL didn't allow this kind of thing to happen, then the
GPL linux kernel couldn't possibly load any proprietary program.

Now, let's allow those "plugins" to do something more interesting: request
some action by the plugin host. The "main" function receives a function
pointer that serves as an entry point for "system calls". Again, it's
perfectly legal to invoke such a function, regardless of whether you can see
this as "dynamic linking", you can also see this as "providing an operating
system system call".

If you're not convinced, let's call this "plugin host" an novel operating
deepcloudstrumpfkernel operating system.

Now, this is a pretty hard to use interface. You probably want a library
linked to your "plugin"/"program" that provides a more natural interface on
top of this basic "syscall" interface. This library and it's headers will
contain functions, constants etc.

This library doesn't have to be licensed with GPL; any license compatible with
your "plugin" will do. Let's make it CDDL (or MIT).

Now, it would be very useful that this library, or parts of it (e.g. constant
definitions), is shared with the "plugin host" a.k.a deepcloudstrumpfkernel;
No problem again, whoever owns the copyright for this library can release it
with both MIT and GPL license.

You can use the same trick to implement a loadable kernel module that doesn't
violate the GPL. However there is a lot of work.

In order to properly abide by the GPL rules, you must be able to build a fully
working kernel module without touching any line of GPL code (except header
files and library objects provided by the compiler and your OS "primary
interface").

This last part is what is tricky. If you want to create a kernel module, you
need to include some helpers. If linux had a stable "driver API", somebody
else could write a library that helps you build a compliant kernel module, but
in order to be more agile, IIRC the linux kernel module subsystem is designed
to be source compatible and not binary compatible between releases and the
layer exposes a lot of linux internals, which are part of the kernel and it
would be very hard to duplicate all this without being caught in a copy paste.

jbooth's suggestion was to write such a dummy layer that bridges the linux VFS
interface with something else; thus not requiring the kernel module to use the
internal linux API. However there is more to it than the VFS API: you also
need the bare minimum to make your kernel module actually loadable by the
kernel not depend on any GPL library that helps you adhere to that ABI.

------
ajross
> And zfs.ko, as a self-contained file system module, is clearly not a
> derivative work of the Linux kernel but rather quite obviously a derivative
> work of OpenZFS and OpenSolaris

I don't see at all why that follows. Why not both? Building a kernel module
requires including headers and writing glue code to conform to the kernel API,
which is licensed only under the GPLv2. It strains reason to argue that a ELF
binary with Linux metadata and Linux module entry points registering functions
to implement a Linux filesystem is "clearly not" derivative of Linux.

~~~
dsp1234
_It strains reason to argue..._

So then the question is, why is "nvidia.ko"'s binary blob not a derivative of
Linux? What's the logic that says one binary blob is a derivative work, and
the other is not when they both are 'ELF binary with Linux metadata and Linux
module entry points'.

~~~
wnoise
Many people think it is, but apparently no one with authority to go to court
over it has done so.

~~~
dsp1234
It certainly would be interesting to see a "Software Freedom Law Center" vs
"Free Software Foundation" legal battle. But if no one wants to fight over a
clearly more egregious graphics blob, then why would they go after Canonical
for something seemingly less of an issue.

------
geofft
Wouldn't the same logic let you conclude that, say, CLISP under a proprietary
license + readline under GPL can be distributed together, if readline is
distributed as a loadable module instead of a static binary? readline is
"quite obviously" not a derivative of CLISP, or vice versa.

[http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...](http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-
CLISP-is-under-GPL)

~~~
snuxoll
The definition of a derivative work comes into play here. An argument has been
made by Illumos who ported the KVM module from Linux that since they did not
have to make any changes to Illumos to support KVM, and they only made minor
modifications to allow KVM to be loaded into the Illumos kernel that it does
not constitute a derived work since it in no way depends on Illumos to
function and that there was no changes made to Illumos to support it. Illumos
gets to stay as CDDL and KVM remains GPL.

A program that functionally _requires_ libreadline to function is very
obviously a derived work in copyright law, calling dlopen() isn't going to
save you from that.

------
tkinom
What is the worst case can happen in this use case?

Let's say a NAS company (WD?) takes the linux + zfs and build a NAS
incorporate all the zfs features.

Who will/can/should file a lawsuit against them and on what probable cause?

Would/should EFF do it? Why?

~~~
lmm
> Who will/can/should file a lawsuit against them and on what probable cause?

A copyright holder for the linux kernel, on the grounds that they are
distributing an unlicensed derivative work thereof (there would be no need to
show damages, there are statutory damages; it's definitely unlicensed, the
part that's not clear is whether it's a derivative work). It's not really in
the EFF's wheelhouse; mjg59 (who holds at least some kernel copyrights)
claimed to be talking to the software freedom law center about his options.
I'm unsure why he'd regard zfs.ko as more problematic than nvidia.ko (I mean
fundamentally end users have the access they need to fix bugs in the ZFS
source, the CDDL is basically the same as the GPL, whereas end users cannot
fix bugs in the NVidia video drivers, not in some theoretical legal sense but
in actual practice), and if the legal theory is correct then it surely applies
equally well to both, but he's the one with standing to sue so it's his call.
IANAL.

~~~
ploxiln
Theoretically, nvidia.ko never comes in the same dvd / usb-stick / download as
the kernel, it's always a separate piece installed by the user later (even if
with a helper program). "Super Easy" derivatives of mainstream distros may
include nvidia.ko (and libdvdcss etc) in the initial install, but mainstream
distros including ubuntu do not. So they could say, if there was some
violation of license going on, it wasn't them doing it, because they were not
_distributing_ something derived from the linux kernel. They may separately
offer some "shim" code and binary under a separate license that the user then
combines with the linux kernel headers on their own machine, and does not
distribute the combination.

That's one of the attempted justifications anyway. So what's more "audacious"
here is Ubuntu distributing zfs.ko included in the initial install, and not
requiring a dkms-like setup.

There's disagreement, even among core kernel developers, about whether
nvidia's binary kernel module is OK. The fact that they've gotten away with it
for a long time doesn't mean that it's OK, just that it's somewhere between
hard and impossible to enforce copyleft (for various reasons worth of a
separate post). ref:
[https://lkml.org/lkml/2012/8/1/411](https://lkml.org/lkml/2012/8/1/411)

~~~
anon4
Then, theoretically, how about distributing the zfs-on-linux source code with
the NAS and present a button in the web interface "Install ZFS" which pops up
a big "this will install a non-GPL-compliant module" message which everyone
just clicks "OK" on and we're done?

~~~
lmm
This is essentially what DKMS does and how Debian is shipping ZFS. I can only
imagine that Ubuntu wants to make it easier that (perhaps it would be hard to
have the installer support ZFS as root filesystem without having the binary
ZFS module - you'd have to ship a full compiler toolchain as part of the
installer?)

------
vbit
Interesting that it took so long to reach this conclusion. I thought Linux
devs stayed away from ZFS mainly due to the licensing which leads me to
believe it's not quite as 'obvious' as this post mentions.

~~~
shmerl
Linux stayed away from including it into the shipped kernel, which is indeed a
derivative work. Their argument is that kernel module loaded into kernel
separately is acceptable to avoid GPL violation.

~~~
davexunit
If this is acceptable then the GPL is useless. This behavior is _not_ in the
spirit of the GPL and copyleft.

~~~
shmerl
GPL defines what is supposed to be the subject to its limitations. And
apparently this use case isn't part of it. So how do you define what's in
spirit and what is in the letter of the law here?

------
protomyth
Can someone explain the circumstances around nvidia.ko and why that has been
allowed?

~~~
rogerbinns
I believe the claims are along the lines that the core of the Nvidia blob is
actually the Windows driver, which is then not a derived work of Linux. They
do provide the source for the bit that adapts between the Linux kernel and
their blob.

If you are being most charitable, you could consider this like NDISWrapper
which doesn't make the driver used become part of the kernel from a license
point of view. The least charitable is that Nvidia are circumventing /
violating the kernel GPL by their stunt.

Ultimately it would likely take some lawyers, time and money to get a strong
decision, which no one seems willing to do, yet.

------
cjbprime
> Equivalent exceptions have existed for many years, for various other stand
> alone, self-contained, non-GPL and even proprietary (hi, nvidia.ko) kernel
> modules.

If your conclusion depends on asserting the obvious legality of nvidia.ko and
saying that you're just doing what they are, you're in a super bad place.

~~~
ealexhudson
That, plus at least one of the authors in question (Oracle, nee Sun) appears
to have picked a license deliberately to ensure that ZFS couldn't be
distributed with Linux. They were otherwise happy to dual-license with some
form of GPL where it suited them; Apple dropped the thing like a hot rock too.

A read of the license text is one thing, the intent of the author is quite
another...

------
shiftoutbox
Why not just use FreeBSD or OmniOS ? Why do I want to use Ubuntu. So I can say
"Bro we use the ubuntu it rocks" ?

------
silveira
Oracle America, Inc. v. Canonical Ltd. (2020).

~~~
ivl
If one group were to sue Canonical, it would likely be the Conservancy, as the
issue is the GPL not allowing for ZFS to be included.

------
freebasedgirl
The CDDL is an anti-forking license. It requires spooning.

