
GPL Violations Related to Combining ZFS and Linux - dwc
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
======
ewindisch
Torvalds indirectly made a strong case for ZFS being a not-derived work all
the way back in 2003: [http://www.gossamer-
threads.com/lists/linux/kernel/401977#40...](http://www.gossamer-
threads.com/lists/linux/kernel/401977#401977)

He states: "having been developed totally independently of Linux: they
literally were developed before Linux even existed, by people who had zero
knowledge of Linux. That tends to strengthen the argument that they clearly
aren't derived."

He does continue to say that he believe it would be "hard to argue that any
new driver or filesystem was developed without any thought of Linux", although
in the specific case of ZFS (as opposed to, say, nvidia.ko), I think there
would be a strong argument that the ZFS module was originally written in whole
as a non-derived work.

(Obviously, Linus is not the only stakeholder here, and even his own opinion
may have changed since then. Still, it's not a new conversation and the
community hasn't been too ruffled by the status quo for the past 13 years)

~~~
bjornsing
For those of us that can read source code there are a couple of strong
indications that the Linux copyright holders still believe that Linux kernel
modules may not necessarily constitute derivative works:

1\. Every Linux kernel module can tell the kernel what license regulates its
use, using the MODULE_LICENSE() macro. The Linux kernel keeps track of which
modules are under GPLv2 (and a few other compatible licenses). When a module
under a presumably "proprietary" license is loaded the kernel will mark itself
as "tainted". (It could just as well refuse to load the module, but it
doesn't.)

2\. There are two macros used to export Linux kernel symbols: EXPORT_SYMBOL
and EXPORT_SYMBOL_GPL. The former will make the symbol available to all kernel
modules, while the latter makes it available only to GPL-licensed kernel
modules. The clear purpose and motivation is that a kernel module that needs
access to a symbol exported with EXPORT_SYMBOL_GPL must be a derivative work,
while a kernel module that only depends on symbols exported with EXPORT_SYMBOL
is not necessarily a derivate work.

Also, IANAL, but from a purely legal perspective I think it would be difficult
to get a court to agree that a user space program that talks to the Linux
kernel through system calls is never a derivative work, while a kernel module
(even one that accesses only symbols exported with EXPORT_SYMBOL) is always a
derivative work. The system call versus dynamic loaded module distinction is
simply not very relevant from a purely legal perspective.

~~~
caf
What this kind of analysis, which is very common, misses is this: there's
potentially two "works" that need talking about here, not just one.

One work is the module, considered in isolation. Is that a derivative of the
kernel? Possibly, but that's a reasonably high bar to clear. If it's not,
distributing the module by itself can be done entirely without reference to
the Linux kernel's license.

The other potential work though is the module-and-Linux-kernel (and possibly
many other bits too), delivered as one combined work. Is _that_ a separate
work as per copyright law? If so, is that work a derivative (of both the
kernel and the module)? This is a much lower bar, and means that the combined
work can only be distributed in accordance with the licenses of both the
kernel and the module.

~~~
bjornsing
> What this kind of analysis, which is very common, misses is this: there's
> potentially two "works" that need talking about here, not just one.

I agree this is only one side of the analysis (does zfs.ko fall under the
Linux kernel GPLv2?), but that's also the only question that the OP can
credibly address (because SFC is a copyright holder in Linux, not in ZFS).

> The other potential work though is the module-and-Linux-kernel (and possibly
> many other bits too), delivered as one combined work. Is that a separate
> work as per copyright law? If so, is that work a derivative (of both the
> kernel and the module)? This is a much lower bar, and means that the
> combined work can only be distributed in accordance with the licenses of
> both the kernel and the module.

That line of reasoning would upend pretty much all open source licensing as we
know it. E.g., paragraph 9 of the OSI's Open Source Definition [1] clearly
states that "The license must not place restrictions on other software that is
distributed along with the licensed software." The fact that the OSI has
accepted the GPLv2 [2] as an open source license implies that they (for one)
do not agree.

1\. [https://opensource.org/osd](https://opensource.org/osd)

2\.
[https://opensource.org/licenses/alphabetical](https://opensource.org/licenses/alphabetical)

~~~
jordigh
SFC isn't a copyright holder of Linux. They are just giving their opinion.

Also, as far as combined work, the OSD is not talking about that, but what the
GPL calls "mere aggregation". The GPL is quite clear that "mere aggregation"
is not under the scope of the GPL, thus OSD consider the GPL to be open
source. A module linked to Linux and distributed along with Linux, however, is
no longer "mere aggregation", but distributed as a single work.

~~~
caf
Some Linux copyright holders have assigned their copyrights to the SFC.

[https://sfconservancy.org/copyleft-
compliance/](https://sfconservancy.org/copyleft-compliance/)

~~~
jordigh
Oh, i wasn't aware. Thank you.

------
dragonwriter
I think what's cute is the part where they point out why citing lawyer's
(especially those employed by interested parties) opinions is not helpful
because of the biases lawyers have to aggressively represent the interest of
their parties, such that their opinions will generally reflect not the most
likely correct view of the law but the view of the law most favorable to the
interests of their clients -- and then, in the next paragraph, proceed to
present their lawyers' opinion of the key and fundamental determining factor
in the situation.

Which, of course -- as they've just telegraphed -- reflects SFConservancy's
vested interests in a maximalist interpretation of what is a "derived work",
since that is what maximizes the scope of works to which the necessity to
adhere to a license (like the GPL) applies.

~~~
SomeCallMeTim
In the case of Linux, Linus has a public position [1] that:

* A kernel module is _run_ by the kernel, not _incorporated_ in it,

* A kernel module only uses _LGPL_ interfaces, so full GPL compliance shouldn't be necessary,

* Binary modules should be legal (though he doesn't like them), and

* Projects (like filesystems developed for other platforms) with their own life outside of Linux shouldn't be required to re-license if they clearly weren't based on Linux.

I know Linus doesn't represent all kernel developers, but his opinion should
carry a lot of weight.

The SFConservancy is just practicing GPL overreach here, and is rattling a
saber in hopes that Oracle blinks. Ubuntu has been distributing NVidia binary
kernel modules for years and this hasn't resulted in a lawsuit, so it seems
like an empty threat.

[1] [http://linuxmafia.com/faq/Kernel/proprietary-kernel-
modules....](http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html)

~~~
carussell
> his opinion should carry a lot of weight

That's nice, but it's only one side. What about the opinion of the developers
who wrote the module and licensed it under CDDL?

The incompatibility between CDDL and GPL is well-known, and the authors at Sun
made it that way deliberately.

It's not kosher to just say, "Well the authors of the GPL software are okay
with it, so it's fine." You need to respect the wishes of the developers who
contributed the CDDL code to begin with.

~~~
cyphar
> > his opinion should carry a lot of weight

> That's nice, but it's only one side. What about the opinion of the
> developers who wrote the module and licensed it under CDDL?

The developers' opinions don't matter. All contributors used to have to sign a
CLA to give copyright to Sun. Then Sun was bought by Oracle. So you should
care about what Oracle thinks about copyright infringement.

> The incompatibility between CDDL and GPL is well-known, and the authors at
> Sun made it that way deliberately.

No, that's bullshit. CDDL (which is just the MPL) is a file-based copyleft
because _that 's what license fitted their requirements_. It's not their fault
that people have a completely fucked up interpretation of "derivative work"
that includes any combination of two completely separately developed works.

~~~
gillianseed
Oh please, even the author of the CDDL license states that this is so (Danese
Cooper).

And it's not as if that admission was ever needed, were you even around back
then ?

Solaris was being killed in the market by Linux, Sun decided to go open source
in an effort to better compete with Linux, but there was NO way that they
would give away their prized technology (ZFS, DTrace) under a license which
would allow their main competitor to whom they were losing, to integrate said
technology.

Hence CDDL, GPLv2 incompatible.

~~~
cyphar
> Oh please, even the author of the CDDL license states that this is so
> (Danese Cooper).

Wikipedia mentions several other authors. Maybe Wikipedia is wrong, but I am
doubtful only one person wrote the CDDL.

> Solaris was being killed in the market by Linux, Sun decided to go open
> source in an effort to better compete with Linux, but there was NO way that
> they would give away their prized technology (ZFS, DTrace) under a license
> which would allow their main competitor to whom they were losing, to
> integrate said technology.

That is one telling of the story. Other Sun employees have different tellings.
It's not as cut and dry as you claim.

CDDL is GPL incompatible in a very subtle way. The copyright of the CDDL
licensed code isn't infringed, it's technically the copyright of the GPL code
that's infringed. CDDL allows distribution of the binaries under a different
license (provided the license doesn't restrict the users' rights, which the
GPL doesn't), but the source files must always be under the same license. The
GPL requires the source files for the "dervied work" be under the same
license, which is where the incompatibility steps in.

------
dsp1234
_in this context, Oracle could make everyone 's life easier by waving their
magic relicensing wand._

Well, so could the linux developers by relicensing to MIT. That's not much of
an argument.

Additionally, I'd still love to see an actual court case with regards to the
GPL here. Licensing is always murky, because almost none of it has been tested
directly in the courts. Thus the only legal opinions we have are from people
who have a vested interest in the outcome one way or another. Let a court
solve it once and for all please. In particular, I'd love to have a 100% lock
on whether a binary module that links to the kernel is actually a derivative
work or not.

~~~
Avshalom
On one hand a court decision would solve it once and for all on the other hand
who the hell are we gonna find that A) is actually qualified to judge this
sort of thing B) doesn't have a vested interest in one way or another.

On the gripping hand it wouldn't actually solve anything because lawyers will
continually argue that _this_ case isn't covered by _that_ precedent.

~~~
mbreese
I think the hard part would be to find someone with standing to sue. Finding a
court would be easy.

Who really has standing in this case? Maybe Oracle could sue Canonical? Or
perhaps a kernel developer could sue Canonical? (although that seems unlikely
to me)

~~~
dragonwriter
In the very article here, the SF Conservancy claims both to have a legal basis
to sue _and_ willingness to do so, though the intention to do so only as a
last resort.

~~~
mbreese
I guess they would have standing here...

From: [https://sfconservancy.org/copyleft-
compliance/](https://sfconservancy.org/copyleft-compliance/)

 _In May 2012, Conservancy launched the GPL Compliance Project for Linux
Developers, which handles compliance and enforcement activities on behalf of
more than a dozen Linux copyright holders.

The GPL Compliance Project for Linux Developers is comprised of copyright
holders in the kernel, Linux, who have contributed to Linux under its license,
the GPLv2. These copyright holders have formally asked Conservancy to engage
in compliance efforts for their copyrights in the Linux kernel. In addition,
some developers have directly assigned their copyrights on Linux to
Conservancy, so Conservancy also enforces the GPL on Linux via its own
copyrights in Linux._

Although one wonders if copyright holders ever thought that they'd be suing a
Linux company like Canonical...

------
teddyh
It is my understanding that Sun's lawyers originally created the CDDL to be
GPL-incompatible, with the _specific desire_ that code under that license
should _not_ be able to aid their then-competitor, Linux. How Canonical can
suddenly decide that Sun's lawyers were wrong about this, I don't know. I
suspect wishful thinking.

~~~
DominoTree
I believe that Bryan Cantrill has stated that it was surprising to the people
at Sun when outside parties didn't start incorporating ZFS and other
technologies into Linux, because the original intention when the CDDL was
written was _not_ to be GPL-incompatible.

Edit: dwrensha posted a related comment
([https://news.ycombinator.com/item?id=11176361](https://news.ycombinator.com/item?id=11176361))
with a YouTube link of Bryan making the statement.

~~~
Dylan16807
If that was the intent, is it not something that can be clarified and fix the
problem? Or did they screw up too badly and it's unambiguously incompatible no
matter what they say?

~~~
the_mitsuhiko
The problem is not the CDDL but the GPL in that case. That's the same reason
GPL2 and GPL3 are incompatible.

~~~
belorn
That is easy to disprove. If CDDL did not care, then one could follow the
conditions in GPLv2 and the two licenses would be compatible.

License incompatibility can _only_ occur if two license has _conditions_ which
are _mutually_ exclusive. In this case, CDDL demands that source code must be
distributed only under the terms of CDDL, and GPLv2 require that the
distributed source code is made available under GPLv2. You can not comply with
one without breaking the other, and thus we have license incompatibility.

~~~
the_mitsuhiko
> That is easy to disprove. If CDDL did not care, then one could follow the
> conditions in GPLv2 and the two licenses would be compatible.

The entire point of the CDDL is that it's module local. The only way to
achieve GPL compatibility is to become the GPL. That would be impossible for
the CDDL to do.

------
kevin_b_er
Even if we ignore the ZFS license itself, the SF Conservancy appears to be
arguing that _all_ proprietary kernel modules are GPL violations.

~~~
bryanlarsen
Exactly. They're arguing the combined work clause, which would automatically
rule out all binary-only modules, such as nvidia.ko.

Most previous arguments about zfs.ko were about the derived work clause, which
is much more grey. I belive that nvidia.ko would be more likely to be ruled a
derived work than ZFS.ko, but that's hard to tell.

It does seem silly to argue about ZFS in this context. ZFS is open source and
much less offensive to kernel developers than nvidia.ko.[1]

If nvidia.ko is fine, then so is zfs.ko. If nvidia.ko isn't fine, zfs.ko may
or may not be fine. Ubuntu has been shipping nvidia.ko for years.

1:
[https://www.youtube.com/watch?v=iYWzMvlj2RQ](https://www.youtube.com/watch?v=iYWzMvlj2RQ)

~~~
snuxoll
Of course the argument to be had here is OpenZFS lives completely independent
of the Linux kernel, it runs on Illumos and FreeBSD and the availability of a
Linux kernel module in no way makes or breaks the project. As such, is it a
derived work since it is not dependent on the Linux kernel to exist?

This is the argument the Illumos developers make about including the GPL'ed
KVM code, KVM does not depend on Illumos to exist, as such does loading the
KVM module into an Illumos kernel constitute a derived work?

Conveniently, this is also precedent that could be set during the VMWare case
the SFC is also perusing - we could either see ZFS relegated to being
available anywhere but Linux and binary kernel modules totally banned (bad for
nVidia, good for AMD), or a total change in the landscape of open source
licensing (for better or worse).

------
mankash666
This article somehow implies a moral obligation on Oracle's behalf to either
modify their licence or code to be gpl compliant. I sincerely hope they don't
as the GPL brigade is getting louder in their intolerance of other licences.

~~~
chimeracoder
> the GPL brigade is getting louder in their intolerance of other licences.

I really don't see much evidence of this, certainly not from the FSF/SFC, who
specifically do _not_ discourage use of free licenses that are GPL-compatible,
such as the BSD and MIT licenses[0]. The anti-GPL crowd is much more vocal
about their distaste for the GPL, especially on forums like HN.

The issue at hand is the use of a license which is _not_ compatible with the
GPL. No matter which way you slice it, that's a massive inconvenience to
everyone, and pretty much nobody wins as a result.

(As for relicensing, it is literally impossible to change the license of Linux
at this point, because the rights are held by thousands of contributors
individually (some of whom are dead, and tracking copyright as it passes
across estates is a notoriously difficult task[1]). If there's ever going to
be a reconciliation between ZFS and Linux, it would require Oracle to
relicense ZFS under any one of the many GPL-compatible licenses.)

[0] They _do_ , incidentally, discourage the use of the terms "BSD license"
and "MIT license", arguing that those are ambiguous and should be deprecated
in favor of "3-clause BSD license" and "X11 license", respectively. But that
has nothing to do with the discussion at hand, which is about the use of the
actual licenses themselves and the terms they represent, not the names that
people use to call them.

[1] Even figuring out if a given book can be reprinted is prohibitively
difficult for publishers, and that's with works that only have _one single
author_.

~~~
Sleaker
I think you got it backwards, the massive inconvenience for everyone is that
Linux is using the GPL and people don't want to have to deal with all the re-
licensing compatibility bullshit just to be able to distribute a binary of
some other FOSS. seriously, CDDL is FSF/OSI approved.

Sure, Oracle could resolve it by switching to a GPL compatible license, but
the problem is not oracle's clearly free software. The problem is GPL forcibly
does not allow perfectly fine open source licensed software to be distributed
in binary form due to it's copyleft.

~~~
geofft
GPL is "clearly free software" too, and FSF/OSI approved too. The problem is
that the GPL and the CDDL _both_ have no-further-restrictions clauses, as
mentioned in the article:

> 6\. …You may not impose any further restrictions on the recipients' exercise
> of the rights granted herein.

> 3.4 … You may not offer or impose any terms on any Covered Software in
> Source Code form that alters or restricts the applicable version of this
> License

The situation would be exactly the same if, say, Linux were under the CDDL and
ZFS were under the 4-clause BSD license, or the OpenSSL license, or Creative
Commons, or the MPL 1.0, or whatever. The GPL and the CDDL both have exactly
the same "problem" here.

~~~
mioelnir
If both licenses only had no-further-restrictions clauses, they would be
perfectly fine. The issue is the imposing of further restrictions, which only
the GPL has in this case.

And if no-further-restrictions clauses are evil and have to go, well, then the
GPL's no-further-restriction clause has to go as well.

------
jbandela1
This is the kind of thing that could hurt Linux in the long term. If Linux
bans non-GPL kernel modules, what of the NVidia drivers? I think most of the
GPU compute code out in the world runs on NVidia GPUs. If NVidia starts
pushing a BSD distro as the distro for high performance GPU computing so it
would not have to deal with type of hassle, it might really change things.

Also, this is coming on the heels of the big glibc vulnerability. BSD with its
greater emphasis on security and less ideologicallyy driven licensing might
start to look more interesting to large corporations.

~~~
davexunit
Distributing a binary version of the nvidia kernel module is a GPL violation,
too.

~~~
icedchai
According to whom?

More accurately, some people _think_ it is a GPL violation. There is no clear
cut answer. You can get legal "opinions" either way.

My personal view is that it is NOT a GPL violation. This is implied for
reading the Linux source code, which explicitly _allows for non GPL kernel
modules_.

------
Sanddancer
At this point, oracle can't wave their magic wand, as the SFC implies, and
have the software be magically gpl-compatible. Since Oracle re-closed solaris,
a lot of other entities have branched and forked and merged code into the
openzfs codebase under the cddl. So you'd have to get in contact with all
those entities to get it relicensed, unless you want to work on an ancient
version of ZFS.

~~~
carussell
Not true. It doesn't matter who owns the copyright, because Sun has the keys
to the kingdom and can publish a revision to the CDDL whenever they want.
Forward compatibility is not something you opt-in to with the CDDL (unlike you
have to do with the GPL).

This is, for example, how Mozilla has been relicensed to MPL 2.0 from earlier
versions of the license—which the CDDL is based on, incidentally—even though
there are no "any later version" notices anywhere in the headers or other
files.

------
dognotdog
The amount of collective brainpower being burned on licensing issues for
supposedly free (as in speech) software is astonishing.

I do symphatize with the sentiment that an author does not want his work to be
a source of illicit gains for someone else, etc, neither do I, but at the same
time find that the usefulness of a piece of code for other open source
developers is (figuratively) inversely proportional to the length of the
license, while the real abusers don't give a damn.

------
tetraverse
"The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained
file system module — the kernel itself is quite obviously not a derivative
work of this new file system."

[https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-
lin...](https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-linux/)

------
laumars
> _Sun released the Z File System (ZFS) code under the Common Development and
> Distribution License, version 1 (CDDLv1) as part of OpenSolaris_

ZFS isn't an acronym. It _used_ to stand for Zettabyte File System (not Z File
System as the article states), but like BP (formally British Petroleum), ZFS
is no longer an acronym.

I wouldn't normally nitpick over something like this but that statement was
the first sentence under the heading "The Basic Facts" and they didn't even
get it's former name right.

~~~
ryao
It still stands for Zettabyte File System. That has never changed.

~~~
laumars
According to Jeff Bonwick, one of ZFS's lead developers, it did change. He
discussed this point in detail
([https://blogs.oracle.com/bonwick/en_US/entry/you_say_zeta_i_...](https://blogs.oracle.com/bonwick/en_US/entry/you_say_zeta_i_say)),
however I'll just quote the last couple of paragraphs for brevity:

" _But zettabyte wasn 't perfect, actually. We (we were a team by now) found
that when you call it the zettabyte filesystem, you have to explain what a
zettabyte is, and by then the elevator has reached the top floor and all
people know is that you're doing large capacity. Which is true, but it's not
the main point._

" _So we finally decided to unpimp the name back to ZFS, which doesn 't stand
for anything. It's just a pseudo-acronym that vaguely suggests a way to store
files that gets you a lot of points in Scrabble._"

~~~
ryao
I stand corrected.

------
devit
Why isn't Canonical using btrfs? (which is supposed to provide many or all of
the features that one would want to use ZFS for, and is GPLed)

~~~
DominoTree
Because it still doesn't have the stability and maturity of ZFS (which has
seen over a decade of production use)

~~~
LeoPanthera
OpenSUSE is using it for root, so I assume they think it is stable enough.

(Interestingly, they use XFS for /home)

~~~
DominoTree
Yeah, but is anybody using OpenSUSE? :P

Edit: Wow, I just checked DistroWatch and they've been #4 for some time now...

~~~
lmm
Most of Europe. At times it feels like there are almost parallel OSS
ecosystems on the two sides of the Atlantic.

------
jjawssd
Thank you Brian Behlendorf for your hard work on integrating ZFS into the
Linux ecosystem! Mad props!

------
alblue
This raises a whole bunch of questions, and none of the answers are good:

\- What's the difference between zfs and nvidia as binary blobs in the kernel?
Either they are both incompatible on principle or they are not.

\- If the file system just uses standard kernel file system APIs then isn't it
LGPL rather than GPL as per the exported symbols?

\- Given that relicencing either ZFS or Linux are prohibitively impractical
what exactly is the point of assuming that may happen?

\- Who exactly complained about this? AFAIK the software conservancy doesn't
have code themselves in the two products

\- If it goes to court the GPL may be harmed due to courts not understanding
the difference between static and dynamic linking; who wins then?

It seems like the beginning of the mother of nobody wins, and very little
upside in any case.

------
svckr
For reference, here's a previous HN post with Canonicals stand on the issue:
[https://news.ycombinator.com/item?id=11133676](https://news.ycombinator.com/item?id=11133676)

------
alkonaut
If I understand the issue correctly, it's not ok to distribute a Linux with a
zfs binary bundled, but it is ok to distribute a Linux with the zfs sources
that builds the zfs binary at install time?

~~~
bryanlarsen
A rules-lawyering engineer might see one as a combined work and the other as
separate works, but I highly doubt that any judge would find any difference
between those two cases. IANAL.

~~~
rcthompson
The GPL makes an explicit distinction between source distribution and binary
distribution. Are you saying a judge would reject that distinction? Would the
judge find that simply having the source code to both the Linux kernel and ZFS
on the same machine at the same time was a violation?

~~~
bryanlarsen
Yes, I forgot about that clause.

------
LeoPanthera
I was not aware of the subtleties regarding the ZFS license.

Would it be possible (read: legal) for someone to modify the ZFS source to be
more easily buildable into the Linux kernel, but then distribute it as source
code only, such that an end user can build a ZFS-enabled Linux kernel on their
own?

Surely as long as the end user didn't distribute the resulting kernel, that
would be OK?

Edit: I see that this has been done. Thanks. :)

~~~
dmm
> Would it be possible (read: legal) for someone to modify the ZFS source to
> be more easily buildable into the Linux kernel, but then distribute it as
> source code only

Yes and that has been done. The ZFS on Linux[0] distributes a DKMS source
package that each user of ZoL uses to build a binary kernel module. DKMS
automatically builds the module without manual interaction from the user,
similarly to installing a regular binary package.

This is legal but the resulting kernel/zfs module is non-redistributable.

[0] [http://zfsonlinux.org/](http://zfsonlinux.org/)

~~~
belovedeagle
Indeed, it's possible and even mostly-supported (at least on Gentoo) to
compile the code into the kernel; i.e., not as a module. I have a zfs system
without kmod support (reduces a huge attack surface and just seems cleaner).

------
ikeboy
GPLv2 contains the line

>This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.

So couldn't the FSF fix this by releasing a later version of the GPL that
allows for this combination?

[https://www.gnu.org/licenses/rms-why-
gplv3.html](https://www.gnu.org/licenses/rms-why-gplv3.html) seems to imply
that that wouldn't work, but I don't understand why. Can someone with more
experience with the GPLs enlighten me?

~~~
snuxoll
Linus removed that line from the kernel license because he disagreed with the
tivoization clause in GPLv3, so the Linux kernel will forever remain GPLv2.

~~~
bryanlarsen
Linus removed that line before GPLv3 was created because he didn't want to
give the FSF the ability to arbitrarily relicense his work to a license that
he didn't have a chance to vet.

If he liked the GPLv3 he may have added the line back in, but he hasn't done
so for the reason you mentioned.

~~~
yarrel
The FSF couldn't arbitrarily relicense his work or the work of any of the
other contributors to the Linux kernel that they don't hold the copyright to.

The GPLv3 had a long and comprehensive consultation phase. Linux contributors
were involved in that.

And there's more than just dislike preventing relicensing - it would require
contacting all the current Linux copyright holders and getting their agreement
(or removing their code if they decline).

On balance I'd rather Linux remained GPLv2 than relicensed to Apache 2, so
this is a good example of the definition of a compromise. :-)

~~~
bryanlarsen
That's exactly what happened to Samba. It was originally licensed with "GPLv2
or later", and now it's "GPLv3 or later". The main contributors to Samba were
leading the switch, but they didn't get explicit permission from every single
copyright holder, nor did they have to.

~~~
mikeash
They didn't need to contact the contributors because of that "or later"
clause. The license explicitly lets anyone relicense to GPLv3 without asking
anybody first.

Linux's license doesn't have that clause, so you're not automatically allowed
to relicense. Switching to GPLv3 would require the copyright holders to
explicitly do so. Since Linux doesn't require contributors to assign copyright
to some central organization, "the copyright holders" means all contributors,
past and present.

------
Licenser
I find it interesting that the SFConservancy argues 'Oracle has a magic wand
to make this all go away' by re-licensing ZFS but completely ignores that just
as much they could re-license the kernel under a CDDL compatible license.
Given that Linux (in the broader sense) is asking for something it'd sound
more reasonable for them to accomodate the other parties demands.

What they do is like saying "Hey I want to buy your house, what you don't want
to sell it? How about you make it cheaper then so I can afford it!"

~~~
hyperion2010
Um... re-licensing the kernel at this point has been deemed completely
impossible [0].

0\. [https://opensource.stackexchange.com/questions/1774/why-
does...](https://opensource.stackexchange.com/questions/1774/why-does-linux-
still-use-the-gplv2)

~~~
ipalreadytaken
Um... If they really cared about making a quality product they would fix their
existing problems, including their (apparently) poor choice of a license. Just
because it is hard doesn't mean their shouldn't fix it.

~~~
hyperion2010
It's not that it is hard, it is that there are literally thousands of
contributors that have contributed code under a gplv2 license that would have
to be hunted down and consulted about any license change. I'm sure if you're
up for it they would be happy to have someone give it a shot so that if a re-
license was needed in the future they could do it, but right now there is
simply no way to legally re-license the code without spending thousands of
hours getting people to sign little pieces of paper that could be used
improving the kernel (zfs or no).

~~~
ipalreadytaken
Right. So hard? Its a lot of work that is unplesant and nobody wants to do, I
think that qualifies as "hard". I do agree its impractical, but it seems that
for something as important as a function, working file system (and don't
suggest that butterface fs is a production ready alternative) that somebody
would put in the work to make it happen. After all the file system is
everything, if you can't safely store your data, whats the point?

~~~
ipalreadytaken
As an addition to the above, clearly ZFS is better than the common
alternative: raid cards running some unknown firmware (that is most definitely
open).

------
xenophonf
Why is Canonical bothering with the distribution of a binary ZFS module when
building it via DKMS at install-time is already very simple (although,
admittedly, time-consuming)? Their minimum system requirements, which gives
the live environment plenty of resources to support compiling a kernel module,
already weed out systems incapable of running ZFS. I just don't understand why
Canonical's willing to take the risk of a successful copyright infringement
suit involving the next Ubuntu release.

~~~
rando3826
Because canonical wants to be the os of light weight vm images and docker
images. You can't do that if the first step in distribution is always "boot
into a separate filesystem, compile a kernel module, then reboot", and then if
you want to distribute your image to anyone outside your organization, be sure
to first remove that kernel module, and have them do the same process again.

~~~
xenophonf
The engineering problems are tractable even in those cases: Don't put the root
file system on ZFS. Develop some kind of first-boot initrd that includes
enough of a toolchain to build zfs.ko. I'm sure there are other, better ways
to solve shipping ZFS in a virtual machine image, especially compared that to
the legal and business risks of having a LTS release deemed a copyright
infringement: Court costs, legal fees, fines, re-releasing Ubuntu, etc.

~~~
rando3826
I don't think they are tractable. They break the requirements.

------
hoistor
Am I missing something obvious here?

Is it a GPL violation to create a separate .deb which includes only the binary
kernel module for zfs which can be simply apt-get'd?

Or are canonical planning on including the zfs code in the base 'kernel-
blabla' package?

If the latter, why not just have a sep package for the module? I imagine
you'll need to install some 'zfs' package to get the userland tools anyway ?

~~~
rcthompson
The single "zfs.ko" file that contains the ZFS kernel module is derived from
both the ZFS sources and the Linux kernel sources, because you need the Linux
kernel sources to link a module with the Linux kernel.

(Actually I think you just need the headers, but those are GPLv2 anyway, so
the distinction is irrelevant.)

~~~
josteink
Actually they are LGPL, according to other posts in this thread. Which would
make it perfectly OK.

I'm not well enough traversed in the kernel source to find a direct reference
but you see commits like this every now and then:

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=09a77a885233e2a20dac2635a79c83ccf50a26a1)

Having parts of the kernel LGPLed doesn't seem like an unusual or odd thing,
from what I can tell:

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=lgpl)

~~~
ajdlinux
Of the 9 commits listed there, 2 are removing LGPL headers, 2 are adding LGPL
headers to scripts which aren't linked into the kernel, 1 is relicensing a
header file so it can be used outside the kernel, 1 is changing from linking
against an external GPL3 library to an LGPL2 library without changing the
licence of the tool that's in the kernel tree, 1 is an author noting that he's
bringing in some external LGPL code which he wrote and is relicensing, 1 is a
commit removing a driver and noting that an LGPLed userspace replacement
exists, and 1 is noting an external LGPL userspace tool in the MAINTAINERS
file.

So of all of those, literally 1 is changing the licence _to_ LGPL.

A better search is
[https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=%2...](https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=%22Lesser+General+Public+License%22),
which reveals 147 results in the code.

This is still _tiny_ , given that the kernel is a ~20 million LOC codebase, so
yes, I would call LGPL code in the kernel an unusual thing.

------
billpg
I ask having no idea...

Does Linux allow for a file system to be invoked at run-time using a general-
purpose interface? (If not, could one be added?)

If ZFS could be modified to use the general-purpose interface, people who
wanted to use it could download it and install it.

~~~
laumars
Yup. It's called FUSE and ZFS is available that way as well. The problem with
running file systems in the user space is that they're generally really slow
since you're chucking lots more data backwards and forwards between the user
space and kernel space. So kernel drivers are much preferred in this instance.

------
leni536
So the only people that could sue based on this supposed GPL violation are the
copyright holders of the Linux kernel, right? I doubt that they have the
intention to do that.

~~~
grifferz
Several copyright holders have assigned their copyright to SFC, so SFC can act
on their behalf. There is also at least one copyright holder that is unhappy
about Canonical distributing ZFS with the kernel:

[https://twitter.com/mjg59/status/700074164435091456](https://twitter.com/mjg59/status/700074164435091456)

------
shiftoutbox
Docker Docker Docker , who cares its Ubuntu Linux

------
hnbroseph
perhaps people should've stopped messing about with ZFS a long time ago. it's
always been known that licensing problems exist, yet people toil away as if
they'll magically disappear - all they do is make Oracle product offerings
stronger. if Oracle is happy to attack Google, they're sure as hell fine with
the much smaller Canonical.

------
swills
First they ignore you, then they laugh at you, then they fight you, then you
win.

