News for hackers. Stuff that matters.
Re:A straight talk about btrfs by josteink on Thursday August 24, 2017 @04:46AM (#15088546)
> ZFS is very much in a grey area

Really? How so?

And if so, what about all those proprietary GPU-driver kernel-modules from AMD and Nvidia which definitely are not compatible with the GPL? Are they a gray area too?

And if they're not a gray area... Why is it suddenly a problem that the ZFS kernel-module is not licensed in a GPL-compatible manner?

I'm not trying to sound facetious, but I honestly can't see the distinction here. And Linux distros left and right have been distributing closed-source kernel-modules for GPUs for a long time now. So what's the problem? What am I missing?

Re:A straight talk about btrfs by cyphar on Thursday August 24, 2017 @07:11AM (#15089123)
Yes, the proprietary drivers have always been an ethical and legal grey area. However, the way a proprietary driver is distributed is different to how ZFS is distributed. Proprietary drivers are distributed as object code that is then built to be a kernel module on the user's machine. This means that at no point does Nvidia or AMD distribute a Linux kernel module with proprietary code. There are arguments however that distributions which distribute this auto-build scheme by default may also be in violation of the GPL. ZFS is distributed by Canonical as a fully functional kernel module.

There's a lot of gray areas because there have not been many legal cases on derived works and the GPL. The GPL itself has held up in court on copyleft grounds, of course.

Also, you've got the fact that in the case of proprietary graphics drivers, the threat is that the Linux kernel community would sue Nvidia or AMD. The threat with ZFS is that Oracle (who is a member of the Linux kernel community) would sue people using ZFS (they could also then sue for patent infringement).

Re:A straight talk about btrfs by wizeman on Thursday August 24, 2017 @07:35AM (#15089212)
I know in the past NixOS did the same for the ZFS kernel module: prior to NixOS installation, it was able to download the ZFS source code, build it and then load it from inside the installer Live CD/USB while it was running, and this would require just a couple of commands. I don't know if this is still true nowadays or if they just distribute the ZFS kernel module directly in the Live installer.
Re:A straight talk about btrfs by jdboyd on Thursday August 24, 2017 @11:03AM (#15090660)
If combining gpl and cddl in a redistributed file is a violation of gpl but not cddl, then what would the holder of the copyright of the cddl code be able to sue about? I think the concern is that a contributor to Linux might sue, just like in the Nvidia/and case.
Re:A straight talk about btrfs by cyphar on Thursday August 24, 2017 @01:39PM (#15092233)
Oracle is a contributor to Linux, so they could sue from the GPL side. While Nvidia and AMD also are Linux contributors, the fact they ship proprietary modules would make it hard to argue that they aren't implicitly permitting users to redistribute it (and thus they would be forced to license their drivers under GPLv2).

Not to mention that ZFS is covered by Oracle patents. CDDL provides a patent license, but it might be possible for Oracle to sue you for patent infringement if you're distributing code in a way that complicates the licensing. Not that I'm saying that's likely, but Oracle has enough money to ruin you if they want to.

Re:A straight talk about btrfs by vetinari on Thursday August 24, 2017 @06:08AM (#15088857)
The crucial difference is in distribution, not in usage.

AMD and Nvidia distribute a binary module with a thin shim. It is the user who builds this shim and inserts into his kernel. Neither AMD, Nvidia nor any Linux vendor[1] distribute any binary, that links into GPL-ed kernel. The combination is done by the user.

And so does the ZoL project. They have the same trade-offs as AMD and Nvidia. It is just much more difficult to install Linux on a filesystem not supported by the installer, than not have working 3D acceleration at setup time though.

[1] the distributions take care to have them in separate, third party repos and if you look more closely, you will find they are being build on the user machine using dkms, akmod or similar mechanism. That also trows a wrench into things if you want to use Secure Boot too.

Re:A straight talk about btrfs by riffraff on Thursday August 24, 2017 @05:04AM (#15088614)
Closed GPU drivers are made by the companies, which have interest in graphic cards being sold, and not sueing linux users.

ZFS on the other hand is owned by Oracle which has no interest in people using linux, nor ZFS if it's not on their proprietary stuff.

Re:A straight talk about btrfs by wizeman on Thursday August 24, 2017 @06:57AM (#15089058)
The license incompatibility is on the GPL side, not on the ZFS / closed GPU side. The only ones which could sue are the Linux kernel developers.
Re:A straight talk about btrfs by belorn on Thursday August 24, 2017 @07:16PM (#15094904)
Publish the source code files only under GPL and Linux kernel developers will be happy.

You might get intro trouble with the ZFS side however, since the CDDL license says: "must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License".

If the Source Code form is only under the terms of the GPL, then the above condition is not met. The law suit would thus come from the ZFS side.

Re:A straight talk about btrfs by Manozco on Thursday August 24, 2017 @08:40AM (#15089579)
Which includes Oracle, so they could sue Canonical and/or zfs users if I understand everything correctly
Re:A straight talk about btrfs by kayfox on Thursday August 24, 2017 @11:11AM (#15090736)
Doesn't Oracle provide a version of ZFS on its Linux?
Re:A straight talk about btrfs by riffraff on Friday August 25, 2017 @04:02AM (#15096922)
they don't
Re:A straight talk about btrfs by yellowapple on Thursday August 24, 2017 @10:07AM (#15090203)
This is resolvable if you think of a driver "shim" that's a derivative work of both a GPL'd codebase (e.g. Linux) and a non-GPL'd codebase (GPU drivers). It's possible for the GPU driver's proprietary license to permit linking without license restrictions, meaning that a "shim" kernel module which loads the binary blob can be under the kernel's copyleft license without problem (since while it's a derivative work of both the module and the blob, only one license is copyleft).

(I don't know if this is what AMD/Nvidia actually do ToS-wise, but it's at least feasible).

Doing this for ZFS is harder, since the shim would have to be a derivative work of both a GPL'd codebase and a CDDL'd codebase, neither licenses of which are compatible with one another. Dual-licensing is probably illegal, as is just picking one over the other.

IANAL, though, and I might be grossly misunderstanding the problem.

Re:A straight talk about btrfs by belorn on Thursday August 24, 2017 @11:07AM (#15090699)
Using a shim to do a legal workaround seems to me as a trick that is unlikely to ever get past a judge. In all other form which people try to do legal workaround in order to turn illegal to legal, it seems that the law don't generally take kindly to it and either explicitly forbids it or just treat the trick as inconsequential to the end result.

For example, we have shims in form of dummy organizations, straw owners, money launderer and so on. Neither of those kind of shims work to turn something illegal to legal. Why would some dummy code that sits between two incompatible software work any better in the legal system?

Re:A straight talk about btrfs by yellowapple on Friday August 25, 2017 @01:30AM (#15096328)
"Neither of those kind of shims work to turn something illegal to legal."

There's nothing illegal here to try to turn legal, though. If the blob's license permits other software to interface with it without restriction, then the shim is free to be under the GPL per the terms of the other work from which it's derived (Linux).

The only way there'd be anything illegal here would be if the blob itself is a derivative work of Linux, and if that's the case, then the blob itself is illegal (since it would be subject to the GPL), regardless of the shim and regardless of whether or not it's distributed as part of a Linux distribution.

Re:A straight talk about btrfs by belorn on Friday August 25, 2017 @05:11AM (#15097136)
Take a dummy organization that is used to avoid taxes. There is nothing illegal to pay someone to form a company located in a different country. A company can also sell assets to an other for what ever price they want, and there is nothing illegal to declare that as a result one of the companies now have zero profits and zero assets.

But if something is legal or illegal depend more than just on each set piece. If combining a blob with the kernel creates a derivative, then just adding a shim to the mix won't turn it legal. Judges are trained to look at the big picture rather than the individual parts, and this is especially true in civil-law. Court systems are generally interested in:

What is the kernel authors intention by their copyright license.

What is the blob authors intention by their copyright license.

What is the distributor intention when combining the two works and what understanding did the distributor have about the other copyright authors and their wishes in regard to derivatives.

The existence of a shim that has no other purpose is a sign that something shady is going on, similar to dummy organizations. The question a judge is likely to ask is why such obfuscation was used since that can help establishing intention. If the end result is a de-facto derivative, and the intention was to create a single work out of two seperate works, and the creator knows that they are not allowed to create a derivative work, then a shim is not going to save the day.

Re:A straight talk about btrfs by yellowapple on Saturday August 26, 2017 @02:36PM (#15106728)
"Take a dummy organization that is used to avoid taxes."

See, that right there is where the analogy falls apart. Tax evasion is (usually) illegal. Writing software to translate between two independently-developed programs is not, last I checked.

"If the end result is a de-facto derivative"

You'd need to prove the blob is derived from Linux. If it's not, then there's literally nothing illegal happening here. If it is, then - again - the shim is not the illegal thing; the blob is, and the shim is entirely irrelevant in that illegality.

The usual reason for the shims, by the way, has very little to do with licensing terms (at least not directly) and very much to do with the fact that Linux does not provide a stable API (let alone ABI) for kernel modules. The intent of the shim is therefore almost always technical rather than legal in nature.

Re:A straight talk about btrfs by cyphar on Sunday August 27, 2017 @05:26AM (#15109919)
> See, that right there is where the analogy falls apart.

You're missing the point. That's the _goal_. If they hadn't mentioned that was the goal, would it still be illegal?

> Writing software to translate between two independently-developed programs is not, last I checked.

It is illegal if the license doesn't permit you to do that. Copyright owners can place restrictions on usage of their works.