FSF Issues Fresh Statement Over ZFS On Linux With GPL Enforcement

[Awesomeness]

If I caught my employee stating an embarrassing fact, I'd counter her, too. I see absolutely no convincing argument on why she would make such thing up and OTOH find it very convincing why her statement would be discredited at a Debian conference.
Fact is that ever since GPL incompatibility of the CDDL came up (at the latest at a very public discussion in Debian around Joerg Schilling's cdrecord and the subsequent cdrkit fork), Sun and later Oracle did NOTHING to address it. The only move they made was making Solaris fully closed source again.
Therefore I'm inclined to believe Danese Cooper.

[chithanh]

@anda_skoa
It escapes my comprehension how in the face of so many indicators that only the GPL blocks the combining, you still think there is legal standing from Oracle against this.

CDDL is just MPL 1.1 with minor modifications. The MPL family of licenses is rather succesful by license count. Neither Mozilla nor any of the others can be said to intentionally want to sue anyone who distributes their code together with GPL code.

CDDL being a weak copyleft means there is a total lack of viral clauses in the license. Weak copylefts usually don't have a problem combining with code under different licenses.

In almost all cases when the GPL was incompatible with other licenses, it was the GPL which disallowed combining the code. FSF worked actually very hard to increase compatibility in GPL-3, most prominently they achieved this with Apache License 2.0.

[Awesomeness]

CDDL is just MPL 1.1 with minor modifications. The MPL family of licenses is rather succesful by license count. Neither Mozilla nor any of the others can be said to intentionally want to sue anyone who distributes their code together with GPL code.

Mozilla does not use the MPL 1.1 any longer.
Mozilla programs are multi-licensed under GPL as well, simply because it's even Mozilla's assertion that the MPL is not compatible with the GPL without multi-licensing: https://www.mozilla.org/en-US/MPL/2.0/FAQ/ (Q14)

[unixfan2001]

If I caught my employee stating an embarrassing fact, I'd counter her, too. I see absolutely no convincing argument on why she would make such thing up and OTOH find it very convincing why her statement would be discredited at a Debian conference.
Fact is that ever since GPL incompatibility of the CDDL came up (at the latest at a very public discussion in Debian around Joerg Schilling's cdrecord and the subsequent cdrkit fork), Sun and later Oracle did NOTHING to address it. The only move they made was making Solaris fully closed source again.
Therefore I'm inclined to believe Danese Cooper.

There is seldom a reason for people behaving erratically/irrationally.
People in the health community have no reason to lie either, yet there is at least one idiot who came out to discredit vaccines (someone who, I hope, is at least heavily invested in tiny caskets).

By your logic that means we should trust that insane person as well because "Why. He has no reason to lie!".

[chrisb]

See, here's the thing: They don't need to do that. GPL over the kernel has nothing to do with including something in a Linux distro. GPL does not apply to the distro as a whole. A module that is not part of the kernel is a module that is not part of the kernel regardless of whether it's included in the distro install or not.

One issue is bundling with the kernel on the installer ISO. The bundle may be a derived work. The consensus is that a distribution can't bypass the GPL requirements of the kernel by putting proprietary modules on the installer ISO. That is one of the reasons why distributions like Ubuntu have a fully open source installer and then prompt the user after install for closed source modules.

The module argument, is irrelevant as Linus Torvalds clarified:

On Wed, 3 Dec 2003, Kendall Bennett wrote:
>
> I have heard many people reference the fact that the although the Linux
> Kernel is under the GNU GPL license, that the code is licensed with an
> exception clause that says binary loadable modules do not have to be
> under the GPL.

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard
system call interfaces aren't considered derived works, but even that
isn't an "exception" - it's just a statement of a border of what is
clearly considered a "derived work". User programs are _clearly_ not
derived works of the kernel, and as such whatever the kernel license is
just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same.
The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that
leads to any gray areas. There are areas that are not gray at all: user
space is clearly not a derived work, while kernel patches clearly _are_
derived works.

But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.

Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem
module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to what other UNIXes did? Personally, I didn't feel that I could make that
judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
area.

Personally, I think that case wasn't a derived work, and I was willing to
tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work?
HELL NO! It has nothing to do with modules per se, except that non-modules
clearly are derived works (if they are so central to the kernel that you
can't load them as a module, they are clearly derived works just by virtue
of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just
one sign that _maybe_ it might have other arguments for why it isn't
derived.

So if the Linux ZFS code was originally written for another operating system, and doesn't depend on internal Linux behaviour, then Linus considers it may not be a derived work. afaics the native Linux ZFS module was written specifically for Linux (?) and I don't know how much code it shares with the original ZFS implementation from Sun.

Also from Linus:

Similarly, historically there was a much stronger argument for things like
AFS and some of the binary drivers (long forgotten now) for 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.

In contrast, these days it would be hard to argue that a new driver or
filesystem was developed without any thought of Linux. I think the NVidia
people can probably reasonably honestly say that the code they ported had
_no_ Linux origin. But quite frankly, I'd be less inclined to believe that
for some other projects out there..

The Software Freedom Conservancy has concluded that Ubuntu's distribution of ZFS would violate the GPL:

We are sympathetic to Canonical's frustration in this desire to easily support more features for their users. However, as set out below, we have concluded that their distribution of zfs.ko violates the GPL... Our lawyers, in conjunction with our GPL compliance and software forensics experts, have analyzed the Linux+ZFS that Canonical includes in their Ubuntu 16.04 prereleases. Conservancy has determined, with the advice of both inside and outside law firm legal counsel, that the binary distribution constitutes a derivative and/or combined work of ZFS and Linux together, and therefore violates the GPL, as explained above. We also know from Canonical's blog post that they have found other lawyers to give them contradictory advice. Such situations are common on groundbreaking legal issues, and, after all, copyleft is perhaps the most novel legal construction for copyright in its history.

There is a lengthy explanation of their reasoning in the link.

[k1l_]

Funny how you cite the Text and marking the Text around the exact quote telling the exact opposite of what you try to make it look like.

> Historically, there's been things like the original Andrew filesystem
module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to what other UNIXes did? Personally, I didn't feel that I could make that
judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
area.

Personally, I think that case wasn't a derived work, and I was willing to
tell the AFS guys so.

/quote


ZFS was written only for Solaris. And after that they made ports for BSD and then Linux.

[SystemCrasher]

Sounds like you don't know much about the advantages of using ZFS. On demand, zero cost snapshotting is a game changer. The ability to group different storage devices into a single logical pool of storage is another. The list goes on.

Ironically, btrfs could do all that, can you imagine it? Just without silly ZFS shortcomings, in even more convenient and pragmatic ways. Without licensing woes. And without being resource hog. It even got used on SMARTPHONES. I wish ZFS good luck, but it seems Sun outsmarted themselfves. Then Oracle proven to be really nasty company either. So they fucked up Solaris and fragmented ZFS development. Not sure what they were trying to ahieve. Best achievement to the date is showcasing why it suxx so hard to rely on single proprietary-minded vendor. Sure, Oracle showcased it really good.

ZFS solves an awful lot of systems administration problems that are way more complicated to solve without ZFS.

This is true... but btrfs does similar things. Yet it lacks some nasty ZFS properties. Btrfs could easily remove drive from pool. It could change RAID level on the fly. It could disable CoW where it hurts, like long-running write-intense DBs. Should it get slow due to fragmentation (in CoW everything is a fragment) - it could be defragmented. It so flexible in allocation it could even place self over existing EXT4 in place, pretending ext4 is a "snapshot". Even if my laptop HDD would eventually face bad sectors and I've been stupid enough to lack backups, btrfs at least got tools to conduct non-destructive recovery. ZFS only got lame words "it shouldn't happen". Which is cool, works in enterprise when one creates 10-drive pool, but not a realistic assumption for use case like my laptop, where I only have room for 1 drive. Things like cp --reflink make me wildly efficient when dealing with large disk images and VMs, but it isn't something ZFS could offer me. At the end of day, btrfs better integrated with rest of Linux system, ranging from core tools to kernel internals.

The CDDL isn't being violated, it is the GPL.

Not a big deal. Sun had idea to thwart use ZFS on Linux. They could do it in infinite numbers of ways. They can even demand everyone to wear pink pants if they want to use their code. Then, according to copyright laws, you either have to wear pink pants or GTFO and stop using code in question. Code author(s) could demand anything, as long as it does not clashes with laws. I guess it is even possible to explicitly forbid to use particular code in Linux (not sure if it going to be legal in all jurisdictions, etc, but its technically possible).

[unixfan2001]

Ironically, btrfs could do all that, can you imagine it?

I can't, actually. Because that's an obvious lie.

It even got used on SMARTPHONES.

Which is a great benchmark for its productivity and reliability on full blown servers/inside data centers, of course *sarcasm*

Sun had idea to thwart use ZFS on Linux.

'cept they didn't. Not according to reality anyways. But feel free to believe conspiracy nutters instead!

[Awesomeness]

ZFS was written only for Solaris. And after that they made ports for BSD and then Linux.

And how did the port to Linux happen? Unless Linux is source compatible with Solaris filesystem modules and ZFS needed only simple recompiling, porting a kernel module to Linux means that the porter has to study the GPLed Linux code first to implement the Linux kernel APIs in the ZFS module. Therefore it's derived work, duh.

Personally, I don't get Canonical's insistence to ship the diver in binary form. Linux has akmod since ages to compile kernel modules when needed.

[SystemCrasher]

I can't, actually.

Sure, because it missing in Windows you seems to be using most of time. Er, wait, someone has actualy wrote driver, though it is alpha quality obviously.

Because that's an obvious lie.

Dare to point some major feature ZFS has got which is missing in btrfs? Sure, there're some shortcomings, but I'm actually using btrfs in like a dozen and half places already and it basically worksforme. I can imagine there could be some gotchas left, but it seems it fine for production use, at least with 4.x Linux kernels.

Which is a great benchmark for its productivity and reliability on full blown servers/inside data centers, of course *sarcasm*

It is a great benchmark of resource consumption, smartphones are relatively modest hardware, due to thermal & battery life concerns.

When it comes to productivity, cp --reflink inceases my productivity by like an order of magnitude in some cases. I can bring up new instance of container or VM disk or experimental disk image in virtually no time, initially sharing blocks on disk with its predecessor. Then CoW would unshare changed blocks as needed, storing differences somewhere else. It makes VMs/containers/disk images activities wildly efficient, allowing one to instantiate like a dozen of distinct versions of fairly large files/hierarchies without taking time to actually copy it, without CPU costs to dedup it, and without disk space needed to store dozen of independent copies in "usual" way. Perfect version of overcommit and dedup, where you hint CoW explicitly. Somehow, ZFS does not implements it to the date.

'cept they didn't. Not according to reality anyways. But feel free to believe conspiracy nutters instead!

Negative. I can't imagine other sane reason to select some really exotic license. Which is also copyleft-style, yet incompatible with other copyleft style. Of course it could be extreme stupidity but I doubt company could achieve things Sun did by being terminlly stupid to THIS degree. But whatever, this company no longer exists and Oracle proven to be quite a troublesome entity who has caused ZFS fragmentation. Now there is Oracle's ZFS and community's ZFS and these aren't same. Seems it would be like UFS where every *nix around thrown own improvements, without giving slightest fuck what others do. The result is a half dozen of semi-(in)compatible UFS versions floating around.