LWN: Comments on "SFC: GPL Violations Related to Combining ZFS and Linux"

SFC: GPL Violations Related to Combining ZFS and Linux

davidstrauss — Tue, 08 Mar 2016 20:14:30 +0000

> Judges are generally skeptical of technical loopholes like this.

No judge (at least in the US and many other places) has yet determined linking to create a derivative work. It's only a "loophole" in the case where the FSF/SFLC legal theory is correct.

SFC: GPL Violations Related to Combining ZFS and Linux

paulj — Mon, 07 Mar 2016 09:11:35 +0000

It was a very small amount of not too central code - but still required code in Solaris that could not be released. The vast bulk of Solaris was open-sourced. However, that particular code wasn't the factor in the choosing of the licence AFAIK.

You're referring, I assume, to Simon Phipps stating the GPL was discounted because Sun didn't want to force other ISVs to have to GPL their code. By ISVs he meant things like hardware vendors and drivers (e.g. fibre-channel HBAs, whose drivers were often just as binary-only on Linux).

SFC: GPL Violations Related to Combining ZFS and Linux

mstone_ — Fri, 04 Mar 2016 19:14:56 +0000

DKMS compiles for the newly installed kernel before rebooting

SFC: GPL Violations Related to Combining ZFS and Linux

Wol — Tue, 01 Mar 2016 10:25:35 +0000

> OK. Now go and convince a judge that e.g. selling a photocopy of the Harry Potter books is "fair use".

Actually, this highlights a very big difference between copyleft and copyright.

Now go convince a judge that MAKING that photocopy is "fair use"! Good luck in pretty much any jurisdiction other than the US!!!

That's why the GPL makes it explicitly clear that "photocopying" is considered a necessary part of "using" and - where not explicitly permitted by law - is explicitly permitted by the licence.

Cheers,
Wol

SFC: GPL Violations Related to Combining ZFS and Linux

vonbrand — Tue, 01 Mar 2016 00:38:29 +0000

The loophole is that the binary can't be distributed at all.

SFC: GPL Violations Related to Combining ZFS and Linux

Wol — Sun, 28 Feb 2016 00:23:56 +0000

Because making the end-user compile from source ISN'T a technical loophole. It's a way of making sure the end user gets the source code, and has been recognised as being compliant with the GPL from pretty much back when the GPL was born.

If, after the compile completed, the script auto-deleted the source to prevent the end user from getting at it, then that really would be a technical loophole and a Judge WOULD frown on it.

Cheers,
Wol

SFC: GPL Violations Related to Combining ZFS and Linux

gdt — Sat, 27 Feb 2016 14:09:36 +0000

The nub of the issue is what source code remains after the Abstraction-Filtration-Comparison test of the module. Noting that the test would discard source code required to adapt the module to work with Linux rather than work with Solaris. Given that ZFS was written for Solaris an argument that a straightforward port to Linux brings elements which are not scènes à faire will be interesting to read.

On this point the analysis is mere assertion, and of the uninteresting case ('combined work', rather than 'derived work'):

our lawyers have analyzed these situations with the assistance of our license compliance and software forensics staff for many years, and we have yet to encounter a Linux module that — when distributed in binary form — did not, in our view, yield combined work with Linux

I wonder how many modules with a high count of non-Linux lines of source code and non-Linux function points SFC's lawyers have previously examined? There can't be that many of these modules in existence.

Because of the oddities of this case, if SFC do prevail before a court then the consequences may not be unicorns and rainbows. I'd be worried such a result would expand the application of 'derived work', with possible consequences on using the structure information in header files of products for which Linux is seeking to interoperate.

SFC: GPL Violations Related to Combining ZFS and Linux

Ed_L. — Sat, 27 Feb 2016 12:31:41 +0000

I doubt you'll get much argument from the embedded community.

SFC: GPL Violations Related to Combining ZFS and Linux

rahvin — Sat, 27 Feb 2016 06:16:03 +0000

Don't think you want to bring up something like that in court where there's no agreement. You'd just open a can of worms that would divert the entire issue. First rule in court is don't bring up issues like this where it turns on the opinion of groups because the other side will find just as much evidence that directly contradicts your filing while at the same time potentially biasing the judge against your argument.

SFC: GPL Violations Related to Combining ZFS and Linux

k8to — Sat, 27 Feb 2016 03:43:42 +0000

Maybe?
My current pessimistic worldview is that most companies are overrun by pointless internal squabbling by the majority of their lifetimes, and the majority of people inside know they're doomed from long before the music stops.

SFC: GPL Violations Related to Combining ZFS and Linux

k8to — Sat, 27 Feb 2016 03:40:42 +0000

Regardless, it was helpful to highlight this fact here. I wasn't aware initially.

SFC: GPL Violations Related to Combining ZFS and Linux

flussence — Sat, 27 Feb 2016 02:05:43 +0000

Are Canonical already violating the GPL by shipping pre-compiled nvidia drivers too? I was under the impression compiling on the end user machine was already a commonplace, well-optimized and package-managed procedure...

SFC: GPL Violations Related to Combining ZFS and Linux

armijn — Fri, 26 Feb 2016 23:04:36 +0000

Ah. SFC mentions it in its blog post, but it is rather hidden, so I missed it at first. Meh.

SFC: GPL Violations Related to Combining ZFS and Linux

armijn — Fri, 26 Feb 2016 22:43:50 +0000

I did not look at what Canonical ships, but I looked at the "ZFS on Linux" Git repository and indeed there are pieces by other companies (Nexenta, Delphix and Joyent, and probably others too). If that is indeed what Canonical ships, then it seems to me that SFC is barking up the wrong tree.

btrfs still hasn't come through

ceplm — Fri, 26 Feb 2016 22:28:14 +0000

Sorry, what I wanted to say that it is perfectly possible and cheap to make number of fast snapshots on thinp volumes. No, snapshots of subvolumes is not available AFAIK.

btrfs still hasn't come through

ceplm — Fri, 26 Feb 2016 22:25:54 +0000

It is perfectly possible and easy with LVM thinp (it is not your dad's LVM anymore).

btrfs still hasn't come through

dtlin — Fri, 26 Feb 2016 22:21:23 +0000

Unmounting is not required; filesystems support freezing to a consistent state and dm/LVM automatically use it.

$ man 8 fsfreeze
fsfreeze is unncessary for device-mapper devices. The device-mapper (and LVM) automatically freezes filesystem on the device when a snapshot creation is requested. For more details see the dmsetup(8) man page.

btrfs still hasn't come through

anselm — Fri, 26 Feb 2016 21:13:58 +0000

We don't know much about how to create very solid operating system, but it seems that modular design is one of the nice things to have. We have proven reliable modular system in LVM/DM-* and now we should throw it away for a monolithic blob?

I agree that modularity is usually a good thing, but it is also a fact that the tight integration of “volume management” and the filesystem itself in btrfs enables various things that the more strictly separated approach espoused by LVM and the device mapper don't support well. For example, with LVM you get to make snapshots of whole block devices only, and since LVM knows nothing about file systems it is up to you to make sure that the snapshot actually contains a consistent file system. In btrfs, OTOH, you can make snapshots of arbitrary subvolumes, and btrfs will take care of the consistency issue for you. In certain configurations, SLES makes btrfs-based snapshots of its root file system at a rate of one per hour (more if you're installing or configuring stuff), and that would quickly become unmanageable based on LVM.

"There is no plan to include ZFS in Oracle Linux. "

atai — Fri, 26 Feb 2016 19:05:21 +0000

Oracle's own position:

https://blogs.oracle.com/linux/entry/oracle_linux_7_is_now

There is no plan to include ZFS in Oracle Linux. The Oracle Linux 7 installer allows you to select either XFS (the default) or btrfs. If you're familiar with ZFS, I recommend taking btrfs on Oracle Linux 7 for a spin.

Re: Is anybody actually using [btrfs] in production?

clump — Fri, 26 Feb 2016 16:17:35 +0000

Legalities aside, your point is what everyone should be concerned about.

btrfs still hasn't come through

nybble41 — Fri, 26 Feb 2016 15:41:54 +0000

With block-level LVM snapshots you need to first ensure that your filesystem is in a consistent state (unmounted, or remounted read-only), or you risk a corrupted snapshot just as if there was an unclean shutdown. The scope of the snapshot is always the entire block device. BTRFS (and presumably ZFS) can take a read-only or read-write snapshot of a live subvolume without first shutting down everything dependent on the filesystem; a subvolume can include the entire filesystem or only a select portion. Consequently, LVM snapshots are not really a substitute for BTRFS/ZFS snapshots outside of certain narrow use-cases.

SFC: GPL Violations Related to Combining ZFS and Linux

clump — Fri, 26 Feb 2016 15:09:44 +0000

Are you sure ZFS isn't a network driver? You sure are clever.

Oracle can make this right. Per my comment, I don't think they wish to.

SFC: GPL Violations Related to Combining ZFS and Linux

mattdm — Fri, 26 Feb 2016 14:43:59 +0000

This is covered in the article. Judges are generally skeptical of technical loopholes like this. If this kind of compilation is made seamless, judges are unlikely to view it any differently from just shipping the binary. And if it's _not_ seamless — well, why bother?

btrfs still hasn't come through

drag — Fri, 26 Feb 2016 14:32:38 +0000

All software is shit. Do you want your shit sandwich old or do you want it heavy and fresh?

That is the difference between 'production ready' and 'development'. Often all it really amounts to is the difference between the "desire to have the bugs you run into more predictable" versus "does the business benefit of adopting newer technology more then it costs to recover from problems."

SFC: GPL Violations Related to Combining ZFS and Linux

drag — Fri, 26 Feb 2016 14:26:41 +0000

> Oracle's ZFS has clearly been modified to adapt it to Linux.

Modifying something to work on Linux doesn't mean it's a derivative work.

SFC: GPL Violations Related to Combining ZFS and Linux

drag — Fri, 26 Feb 2016 14:25:05 +0000

> How often does dual licensing create incompatible forks due to one of the licenses?

Right now the Oracle ZFS shipped with Solaris is incompatible with the OpenZFS implementation. Oracle didn't stop developing ZFS after they stopped doing code releases.

btrfs still hasn't come through

ceplm — Fri, 26 Feb 2016 13:54:08 +0000

I really didn’t want to say much against BTRFS. I am not a super filesystems master (not even C developer), so I cannot argue about the details. What I wanted to say is that periodically somebody posts something like http://blog.dustinkirkland.com/2016/02/zfs-is-fs-for-cont..., then certainly somebody else reacts "The sky is falling! Solaris/Oracle Unbreakable Linux/Ubuntu will eat Linux alive because we don't have ZFS!". Then series of responses follows suggesting various hacks making ZFS working on Linux (zfs.ko, ZFS over FUSE) followed by thorough explanations why all these are not useful for mass use. And then as the last hope, somebody shouts "We should get BTRFS into production!".

What I wanted to say is:

a) ZFS on Linux is no-go (not only copyright issues, but BTRFS with all advanced options would be sooner enterprise-ready than ZFS on Linux),

b) Neither BTRFS or ZFS are such revelation from heavens to heathens living in darkness as many of its proponents seem to suggest, because most of its functionality is achieved on LVM/standardFS or can be achieved soon with battle-tested-enterprise proven solution instead of throwing away half of the storage stack in Linux and replacing it with something less proven and battle tested (ZFS on Linux is not the same as ZFS on Solaris).

We don't know much solid about stability of BTRFS on enterprise-size storage with all advanced features switched on (neither SLES nor RHEL issue trackers are available, RHT does not support BTRFS at all). We don’t know much about CPU/memory requirements of either of these on enterprise-size storage (hundreds of TBs) … I heard nasty rumors, but nothing certain. By advanced settings I mean in this case for example check-summing of all sectors.

c) We don't know much about how to create very solid operating system, but it seems that modular design is one of the nice things to have. We have proven reliable modular system in LVM/DM-* and now we should throw it away for a monolithic blob? Hmmm.

Matěj

SFC: GPL Violations Related to Combining ZFS and Linux

kloczek — Fri, 26 Feb 2016 13:23:19 +0000

Seems you really don't understand that ZFS it is not network driver but huge piece of technology which is still evolving and comparing ZFS case to any previous dual licensing cases is not correct way of thinking about this case.

SFC: GPL Violations Related to Combining ZFS and Linux

pizza — Fri, 26 Feb 2016 13:20:48 +0000

> I don't think the licence can decide what counts as a derivative work. That is determined by copyright.

And when the powers that be push for ever-stronger copyright, it has the side-effect of strengthening copyleft.

Of course, without enforcement, it's rather moot.

SFC: GPL Violations Related to Combining ZFS and Linux

pboddie — Fri, 26 Feb 2016 12:35:29 +0000

At last, someone gives the most likely reason for the odd licensing of Solaris: the murky, not-particularly-well-managed heritage of the code, emerging from the corporate swamp where the players forgive each other's behaviour until scores need settling. (I am reminded also of Java and the sudden need for Kodak to go after Sun for patent infringement when both parties were probably "cool" with the situation until Kodak needed the money.)

Of course, cooking up another licence probably also satisfied the Solaris faction within Sun: their impending glory wouldn't be stolen by those upstart Linux people after all if they licensed all the valuable Solaris code incompatibly. It's interesting to see companies who could have bought up numerous competitors at the height of their success ending up as acquisition targets in free fall, and yet those doing the internal squabbling that led to the strategy vacuum at the centre of the corporate malaise still probably think they were right. Oh well!

btrfs still hasn't come through

anselm — Fri, 26 Feb 2016 12:00:51 +0000

That may be perfectly true (and more power to RHEL users) but has no bearing whatsoever on whether the people at SUSE consider btrfs usable for their purposes.

It's also worth mentioning that LVM-thinp and btrfs snapshots seem to address different use cases, and that, while I'm not an expert on how SLES does things with their configuration rollback system, LVM-thinp doesn't appear to be hugely useful in that context. (According to the SUSE web site, they are looking at supporting the same functionality based on ext4fs, but for now this requires a custom kernel, so is probably not production-ready.)

btrfs still hasn't come through

ceplm — Fri, 26 Feb 2016 11:37:35 +0000

Certainly 'advanced' is a matter of struggle, but easy snapshots are available in LVM-thinp as well (supported in RHEL-7).

btrfs still hasn't come through

anselm — Fri, 26 Feb 2016 10:34:20 +0000

SUSE at least supports btrfs snapshots because that's what they're using in their system administration tool in order to be able to roll back configuration changes. Whether that counts as an “advanced” feature of btrfs is probably a matter of definition (I'd guess so but who am I to say?).

btrfs still hasn't come through

ceplm — Fri, 26 Feb 2016 10:26:04 +0000

Except that SUSE doesn't *support in SLES* almost any advanced features of BTRFS, only using it as more or less the same as traditional file systems. Having said, I believe BTRFS has a way more chance to be relevant in the Linux world than ZFS.

btrfs still hasn't come through

ceplm — Fri, 26 Feb 2016 10:23:20 +0000

The official stance of RHT is, if I am not mistaken, that LVM (with all the improvements which happened lately ... e.g., thin-pool for cheap and fast snapshots) and XFS can be used now as replacement for majority cases of what ZFS provides especially for enterprise uses and missing parts.

Even if Oracle tomorrow release ZFS under GPL (or dual license; and no I am not holding my breath), the situation in the Linux world would hardly change. Filesystem development is a super conservative sport (how much would you like a bug in FS destroying your data?) and before all the changes between various Linux forks of ZFS would merge, before all the missing parts support for Linux would materialize (not mentioning all tools like fsck.zfs), it would take couple of years at least. And even then I think that large filesystem users (e.g., enterprise) would be hesitant to submit their data to it. I believe improvements to LVM/XFS, or even final completion of BTRFS are more immediate options.

SFC: GPL Violations Related to Combining ZFS and Linux

sourcejedi — Fri, 26 Feb 2016 09:44:32 +0000

"building modules for kernels not currently running also is a viable option", AIUI.

btrfs still hasn't come through

anselm — Fri, 26 Feb 2016 09:34:42 +0000

IIRC, SUSE Linux Enterprise Server uses btrfs by default for its root filesystem. The SUSE folks probably wouldn't do that if they thought it was unreliable.

I have a Netgear NAS that also uses btrfs. As far as I'm concerned it works very nicely indeed.

SFC: GPL Violations Related to Combining ZFS and Linux

epa — Fri, 26 Feb 2016 09:12:38 +0000

I don't think the licence can decide what counts as a derivative work. That is determined by copyright. At most the licence could grant exemptions so that even if something might be considered a derivative work under copyright law, distributing it under other terms is still permitted.

SFC: GPL Violations Related to Combining ZFS and Linux

butlerm — Fri, 26 Feb 2016 06:45:43 +0000

The ZFS module consumes an API for technical compatibility reasons. That has never been determined to create a derivative work, let alone a derivative that isn't allowed under fair use. Even if there were inline functions of substantial complexity that arguably would create a derivative work, the problem could be worked around by constructing a shim more or less as Nvidia does.

Canonical's problem (if it has one) seems much more likely to do with the interpretation of the GPLv2 license, a license it needs to comply with to distribute the Linux kernel, rather than any requirement of copyright law as such. That license, however, doesn't seem to be quite specific enough to disallow joint distribution of a non-derivative work, or a derivative shim plus a non-derivative work at all.

As you can see, the GPLv2 authors punted the entire question of what is a derivative work under the license to what is a derivative work under copyright law:

// The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language //

SFC: GPL Violations Related to Combining ZFS and Linux

pabs — Fri, 26 Feb 2016 02:26:59 +0000

Debian got caught doing the same thing Canonical are doing, but with nvidia.ko:

https://bugs.debian.org/815060