[zfs-discuss] Summary of ZFS on Linux for Debian (was: zfs-linux_0.6.2-1_amd64.changes REJECTED)

Aron Xu aron at debian.org
Thu Aug 28 21:42:30 EDT 2014

Dear DPL and FTP Masters,

As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded
into the following summary for the situation, please see as follows.


CCDL is an Open Source License that is DFSG compliant, but happens to be
incompatible with the GPL. For the sake of our argument, we can consider
that the CCDL is similar to the proprietary license of the NVIDIA or AMD
proprietary kernel drivers: all are incompatible with the GPL requirements
for derived works.

There are 3 ways in which a kernel driver can be distributed:

1) Source code
2) Binary Linux loadable kernel module (LKM)
3) Built-in into a custom monolithic kernel image


1) Source code

Our current package only distributes the ZFS on Linux (aka ZoL) in the
form of source code. The module is built on the user machine with DKMS
at package configure time. Therefore we aren't distributing the ZoL ZFS
module in binary form.

Distributing the ZoL ZFS driver in source code form (in a different
package than the Linux kernel) doesn't make ZoL a derived work of the
Linux kernel in any case. Both source code bases are clearly independent.
So, for Debian, the distribution of the ZoL source code (that is what
our package distributes) should be free from licensing trouble.

2) Binary Linux loadable kernel module (LKM)

However, in an hypothetical situation, a user could have ZoL on a
fresh Debian installation and then image or copy that installation to
re-distribute it (for quick usage on the cloud or whatever). In such
case, the user would be the distributor (not Debian). So Debian
won't have any problem because we only distribute ZoL as source code.

In any case, we also want to be sure that this is OK for the user. Not
only because we want to keep our users free of any trouble when using
Debian, but because we may also want to distribute binary modules at
some point in the future (inside the Debian installer - prototype
code already written and provided for review for doing this).

The key question to answer here is:
Is a binary loadable kernel module a derived work of the Linux?

Short answer:
Only if the module uses any of the symbols that the kernel export as
EXPORT_SYMBOL_GPL(). The ZoL ZFS driver don't use any symbol marked as
such, so it is not a derived work of Linux kernel.

Full answer:
The controversy is about whether a module is a derived work of the
kernel when you link it in. Traditionally, some modules were not
considered derived works by a lot of people arguing that the Linux
kernel has a public module interface that acts as a barrier for the
license in the same way that the syscall interface lets you run
proprietary applications.

The EXPORT_SYMBOL_GPL is all about symbols that are too low-level to be
considered part of that public module API (assuming that this API
exists). The argument is that symbols which are not meant to be used in
third-party modules can never be a license barrier and anything using
them is a derived work even if you consider other modules not to be a
derived work of the kernel. [1]

This interpretation is shared by Linus Torvalds [2]. And since he is the
main author of the Linux Kernel, we think that -in spirit of both Linux
and the license he chose for it (GPL)- his interpretation should be the
one accepted of what a derived work of the kernel means.
Upstream ZoL project also has this question clarified on their FAQ [3].
Even if this is still not clear to some of you, keep in mind that Debian
already includes several proprietary kernel modules. To name a few:
NVIDIA, AMD, Broadcom wl, etc.

These proprietary modules have proprietary licenses far more incompatible
with the GPL than the CCDL and Debian ships these packages without
problem. Why is shipping ZoL a problem, but not the proprietary NVIDIA
driver? If distributing ZoL (either in source code form, or as a binary
LKM) was deemed unacceptable for Debian (or treated as violating the
spirit of GPL), then all the proprietary kernel modules that Debian
currently ships would have to be removed from the archive since the same
concerns would apply.

A thing that may need more explanation is the role of Solaris Porting
Layer (SPL) developed by ZoL project. SPL is released under GPL, it
implements some of the Solaris kernel functions to make original ZFS code
easier/possible to be ported. Since it was developed from the ground there
is no problem in the license, and Debian FTP Masters have accepted it into
the archive in July, 2013.

3) Built-in into a custom monolithic kernel image

We think that this point is open to discussion. Linus makes a very good
argumentation [4] on whether the simple fact of linking (statically or
dynamically) two programs don't make them derived works, but simply
"aggregate" works.

Upstream ZoL project [3] holds the view that in this case the combination
of the two in the same binary would create a derived work, so this is not
acceptable for redistribution. We accept the interpretation that this
last case is not acceptable for redistribution.

Therefore our package does not (and never will) ship or facilitate
building a custom kernel where the ZoL ZFS driver is built-in in a
monolithic binary, instead of built as an independent dynamic LKM.

 Aron, on behalf of Debian ZoL Maintainers

[1] http://thread.gmane.org/gmane.linux.kernel/1240534/focus=64498
[2] http://thread.gmane.org/gmane.linux.kernel/475654/focus=476049
[3] http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue
[4] http://thread.gmane.org/gmane.linux.kernel/476656/focus=476807

On Tue, Aug 26, 2014 at 09:00:30PM +0000, Paul Richards Tagliamonte wrote:
> Hello, ZFS on Linux maintainers,
> At a recent ftpteam meeting we discussed this package, and what to do about it.
> Our consensus was that this package appears to violate the spirit of the GPL at
> minimum, and may cause legal problems. Judges often interpret documents as they're
> intended to read, hacks to comply with the letter but not the intent are not
> looked upon fondly. This may be a hard thing for technical folks to accept, but
> in legal cases one usually isn't dealing with technical people.
> As such, this package has been rejected with the following notes:
>  * Please take care to fix your naming issues. Please talk with the kFreeBSD folks
>    on how to best handle the namespace. The kFreeBSD folks had these names
>    first, it's up to them how they're used.
>  * We recommend that the DPL put a question to our lawyers, providing a full and
>    complete background on the situation. (We are happy to help reviewing it before
>    it gets sent off). We will defer judgement on the legality of distributing ZoL
>    in Debian to them.
> Thanks,
>   Paul, on behalf of the ftpteam
> ===
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20140829/9a1d3d4c/attachment.sig>

More information about the zfs-discuss mailing list