Guest post by Ubuntu’s announcement about inclusion of ZFS support in upcoming 16.04 LTS started an important discussion in opensource community: the license incompatibility between GPL and CDDL licenses may be an issue. Being a copyleft license, GPL requires that all works that are derived from GPL-licensed work are also distributed under terms of GPL. CDDL, the license of ZFS code, is also a copyleft license, and as such requires CDDL-licensed work be distributed “only under the terms of [CDDL].” Although Ubuntu’s ZFS code comes from OpenZFS project, Oracle is still one of the major copyright holders of the code base, and it does not seem likely to relicense its assets under GPL any time soon.
Dustin Kirkland of Ubuntu, the author of the announcement, explained Canonical’s position, albeit light on details:
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. And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.
Software Freedom Conservancy (SFC), a non-profit with self-assigned mission of carrying on a crusade against GPL violations, quickly pointed out that the “obvious” conclusions of Canonical are not really all that obvious:
[I]f ZFS were statically linked with Linux and shipped as a single work, few would argue it was not a “work based on the Program” under GPLv2. And, if we believe there is no legal difference when we change that linking from static to dynamic, we conclude easily that binary distribution of ZFS plus Linux – even with ZFS in a .ko file – constitutes distribution of a combined work.
Another non-profit organization – Software Freedom Law Center (SFLC) – provides yet another opinion on the matter. Eben Moglen points out that CDDL permits distribution of binaries under other licenses, so in case of Linux module GPL’s requirements in case of binary module may be fullfilled by distributing it under GPL. Admittedly, this does not solve the issue of the license incompatibility of the code bases. The proposed solution is basically to ignore the wording of GPL’s viral clause:
In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the “equity of the license,” or its “spirit.” As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of “equity.” This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders’ intention which determines which mode of interpretation is to be employed.
The issue of GPL compatibility and kernel modules’ licensing arised before. For example, Linus Torvalds already noted that kernel modules are in “gray area” when it comes to the issue of derived worked. Using an example of Andrew filesystem he stated that external code base that was designed on different system and only required minimal porting effort due to interface similarities, in his opinion, was not a derived work of Linux. Even more appropriate example is Nvidia’s infamous proprietary Linux driver, which interfaces the kernel via specially-crafted module that abstracts away Linux kernel implementation details, so that Nvidia’s binary blob may still considered to be a self-contained work targetting module’s interface, not the interfaces of Linux. This driver is widely used and generally tolerated by distributions.
The differences in these two positions reveal the two conflicting opinions on Linux copyright situation. SFLC is more concerned about the ability of opensource ecosystem to survive in face of fanatic GPL enforcement: their statements goes into painful details about difficulties that projects with permissive licenses are facing when they need to maintain the ports of their code in GPLed projects. If stictly enforced, GPL could hinder such projects to the point when whole ecosystem comes to net loss. Such situation could be particularly painful in cases like this, when the goals of GPL are met, but the legal mechanism that was chosen by opensource Foundation prevents both Linux and OpenZFS from cross-polination.
But on the other hand, making such excuses would open gates for projects that don’t really contribute to the opensource, but only use it to their own benefit. While proponents of permissive licenses (myself included) don’t find anything wrong with such outcome, GPL was specifically designed to prevent it, and that is why it is one of the most popular opensource licenses out there. Obviously, every concession weakens the position of those seeking GPL enforcement, including SFC, whose mission right now is endangered by both SFLC’s and Canonical’s views on ZFS integration into Linux. Being a self-styled GPL crusader with several battles already fought, SFC knows that the ZFS inclusion in Ubuntu may come at a price of legal actions lost, and potentially tolanted hackers driven out of opensource by frustration and disappointment.
There is another interesting angle to this situation: by now it is common knowledge that Sun Microsystems specifically designed CDDL to be incompatible with GPL, so that ZFS, while being opensource, could not be included with Linux. Shipping ZFS with Ubuntu would defeat this tactics and potentially remove motivation for such unfortunate choice of license for companies like Sun or Oracle, to benefit of all involved sides.
And yet another thing to consider: some (most?) jurisdictions explicitly require sticking with literal meanings of laws and contracts. This means that even if SFLC’s position is defendable in United States, it might be dismissed in other parts of the world, giving Linux copyright holders ability to sue Canonical over copyright infringement. Given that Oracle holds copyright in both Linux and OpenZFS, and that it already demonstrated willingness to take legal actions against opensource projects, Canonical might still be under significant risk.
At any rate, the outcome of this discussion, if any, have potential to settle a long-standing issue in opensource community, and to make legal implications of using GPL more transparent and clear.
1. The obvious: DKMS already exists, this means: build from source at installation time.
2. automatic download/install kernel module binary from an other source. Like the http://zfsonlinux.org/ project.
Edited 2016-02-29 23:03 UTC
Lennie,
“You can’t get ZFS from us, but I have a friend who can hook you up…”
They would have to coordinate with Ubuntu to get the kernel sources and compile a compatible ZFS kernel module. As a derivative of both GPL and CDDL sources, the legal status of this module by itself wouldn’t be clear to me.
Since they’re not distributed together, great care would have to taken to provide assurances that users always have access to the correct ZFS kernel module, it would be very bad if they lost access to their own ZFS file systems on an upgrade, for example.
I think Ubunto should avoid voodoo engineering work done solely to workaround GPL license restrictions, especially when those changes would make the OS more fragile. ZFS should really just be distributed as a normal kernel module, but then I’m not the one who’ll be answering when the legal brigade comes-a-knocking.
Nvidia already applies both solutions if I understand correctly: They have a binary module they download. And a small kernel/wrapper module they build from source to be compatible with the current installed kernels and the GPL.
Any workaround to Oracle suing the ever living crap out of ubuntu?
I kind of wonder if this is the exit strategy that Mark Shuttleworth came up with.
Exit strategy by Mark
1) Incorperate ZFS into Ubuntu
2) Get sued by oracle
3) Protest, countersue for something…
4) Negotiate a oracle buyout of ubuntu as a resolution of the lawsuits.
5) Retire to the south pacific.
😉
But no.
🙂
Not Oracle!
He’s rich enough that he could already do this several times over. Wouldn’t be any point bothering with the rest.
Sure, then he doesn’t have to live with a bunch of nerds upset that he just dropped the business. Plus just dissolving the company means he wouldn’t recoup nearly as much as a straight sale.
Canonical has never been profitable and the failure of the tablet/phone couldn’t have helped. With a lawsuit exit, he can avoid blaming his decisions and blame it on big bad oracle. Ubuntu would be remembered as a bold, noble experiment that was ultimately doomed by an evil 600 lb gorilla .
Ubuntu is Mark Shuttleworth’s hobby project, he already has the money to retire.
Unless he pissed it all away on Ubuntu. Now that I think about it, given how poorly it has done, this is quite possible.
I believe Mark put a large amount of money in a fund which funds Canonical.
They are doing a lot better than a couple of years ago though.
Ubuntu is the most used Linux distribution being deployed as guest on cloud-environments. And it’s also used to build cloud environments by companies like Deutsche Telekom. Especially that last category are paying customers. I don’t know how many organisations deploy it as private clouds.
Edited 2016-03-02 21:02 UTC
Isn’t this the same situation with Valve distributing Nvidia and Amd binary drivers with SteamOS?
Dynamic linking can’t constitute a derived work. A binary executable, somewhere down the chain, will be dynamically linking to kernel code and no one will argue a binary executable is a derived work. This applies whether the kernel is opensource or proprietary, otherwise Microsoft can claim all programs running on Windows are derived works. And it looks like zfs.ko is self-contained enough that it is essentially a standalone executable.
kwan_e,
The FUSE implementation of ZFS is a standalone executable and can be treated as such. But native kernel modules have to compile against and link into a specific kernel version. They are very tightly coupled with internal kernel structures. Note I wouldn’t necessarily say it’s “derivative” in GPL speak, but a lawyer could…
Edited 2016-03-01 03:51 UTC
There is also the VMware/GPL case that is currently in court:
http://laforge.gnumonks.org/blog/20160225-vmware-gpl/
VMWare case is very different: it is all about direct code usage, which is much more straight-forward.
One of the most important parts of the court case is:
“Are vmklinux + vmkernel one program/work or multiple programs/works?”
But that’s not the argument of the SFC. They are claiming that there is no difference between static linking and dynamic linking. I would argue that static linking is almost as different from dynamic linking as it is from a standalone.
A statically linked module can no longer exist on its own. With dynamic linking, it is not unreasonable to posit a completely different kernel with the same symbols that the module needs to link with and thus they can be switched. So it is much closer to a standalone and not dependent enough to be considered derived.
kwan_e,
Edited 2016-03-01 13:20 UTC
I am probably quite uninformed about this, but couldn’t one get around this with a legal trick (I am not a programmer, so excuse my probable lack of precision with the terminology):
– create a kernel module (perhaps even a filesystem one) that has the exact same interface as the zfs.ko module
– (possibly independently) create a wrapper that loads a module with this interface into the Linux kernel
And hey presto – you have something that can load the module into the kernel and you only require a component that is not technically a derivative of the zfs.ko module to load said module.
A bit over the top I agree, but it shows how the argument that any module that can interface with Linux becomes a derivative is flawed.
In any case, if you distribute them completely separately, it appears there is no non-compliance. Therefore this non-compliance seems to only arise when you distribute them in “close” proximity, which seems a nonsensical position.
mkone,
I’m not going to make any predictions that this couldn’t violate some provision of the DMCA, but just maybe this would do the trick!
Edited 2016-03-01 18:18 UTC
Which is precisely my point earlier about dynamic linking and positing the existence of some module that fulfills the linking criteria. The fact such a thing is reasonable to posit makes the argument that there is no difference between static and dynamic linking wrong – regardless of what those other people said about it.
kwan_e,
Whether it’s in a dynamic or statically linked, we’re still looking at the exact same executable code down to the byte, we’ve merely moved it into a different container. Can one avoid GPL compliance by shifting code around into different containers? I really don’t know. Would a court really make a distinction between an ISO file containing a vmlinuz binary built with ZFS and an ISO file containing vmlinuz + the same code in a shared kernel object? I really don’t know. Can someone introduce kernel wrappers just to circumvent the GPL license? I really don’t know. Can GNU enforce a license that prohibits linking to non-GPL code? I really don’t know.
If there’s a common theme here, it’s that I really don’t know because to my knowledge these haven’t been answered in court, which is why I’m perplexed that you state with such conviction that GNU is wrong about it’s own license. What do you know that I (and they) don’t?
Even though I don’t have my own made up, I do think any ruling on the GPL will depend on what judge gets the case and how well lawyers can make their case.
Edited 2016-03-02 06:59 UTC
Others have brought this up already: http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
While, in general, he considers binary kernel modules to still be derived from Linux kernel, he is also clearly amenable to the idea that if it can be reasonable shown that the software was not designed for Linux specifically then he doesn’t consider it derived.
kwan_e,
Well, ZFS is a perfect example. Based on Linus’ opinions in that link: you, Linus and I would probably all agree that Linux users should be able to have ZFS on linux without worrying about a license…however the inconvenient truth for all of us is that the GPL’s goal is to disallow redistribution of GPL code that links to non-GPL code, which is what Ubuntu wants to do. Nothing Linus says changes that – the question is how the GPL might be enforced by the courts. If Linus wanted to permit linux to have non-GPL modules, arguably he chose the wrong license for that. To be fair to him, he was just a young kid and never imagined how far this project would go. When I was working on my OS, I honestly didn’t think about such things.
Edited 2016-03-02 14:50 UTC
One thing that is puzzling is why is the SFC targeting the ZFS module and not the nVidia driver. Clearly it’s exactly the same situation.
kwan_e,
Yes, I agree. I feel the nvidia situation is much worse because it’s completely proprietary, whereas ZFS is merely under a different open source license, but license-compatibility-wise I think they’re in the same boat.
If building a thin kernel/proprietary code shim works for nvidia, then it should work for ZFS too.
In Linus’s words “it is not acceptable to make a small piece of GPL-code as a hook for the larger piece”, but since his words aren’t part of the license, it doesn’t really have any legal bearing.
Edit: I don’t want to miss the opportunity to post this photo of Linus giving nvidia the middle finger.
http://www.maximumpc.com/linus-torvalds-tosses-f-bombs-middle-finge…
Edited 2016-03-02 16:11 UTC
Then either those who argue such are idiots, or else they have an agenda. If dynamic linking could create a derived work, there would be not a single original work beyond kernels in any modern computing environment. The idea that linking constitutes a derived work is one of the stupidest things I’ve heard in recent times. If anything, statically linking would be more of a cause for this argument than dynamic as you’re actually including a copy of the library in your program. Ridiculous.
darknexus,
Respectfully, it doesn’t sound like you realize that most libraries have explicit linking exceptions for exactly that reason. I’m also not sure you understand the thinking that went into the GPL, which was created very carefully to limit the abuse by those who would exploit loopholes.
For example, one could bypass all GPL requirements just by building all said code as a DLL and then linking proprietary code in a separate executable. Voila, GPL completely circumvented even if it constitutes 99% of the code. Quite the opposite of being stupid, it took a lot of foresight to see this, which is exactly why linking to non-GPL code isn’t allowed.
It’s natural to ask just how much functionality needs to be brought in via linking to constitute a “derived” work, 50%? 10% 2%? But the intention behind the GPL was that any linking to GPL code, even if it’s only 1%, would be prohibited unless the entire codebase to be made available via GPL.
This isn’t always desirable, particularly with system libraries as you pointed out, so those are often licensed under LGPL or GPL with exceptions.
Right, as a technical matter it’s clear the FSF foresaw this and made a claim with the intention of preventing it. The FSF would very much like this claim to be substantiated, because the GPL would be seriously harmed if it wasn’t. But notwithstanding the FSF making the claim in many forms, it’s never been legally tested (AFAIK) and its basis is quite shaky.
Sticking with GNU Classpath, FSF’s position is that if I write some source code that uses zero lines of code from Classpath, then I compile that code and give it to you but give you zero bytes of Classpath itself, that I have created a derivative work. Although the FSF would like this to be true, there’s an inconvenient aspect which is that zero source code and zero binary code from Classpath were copied in the process, and yet that’s the basis for a copyright claim.
The good part about what Canonical are doing here is picking a fight with a litigious company such that this question is likely to be resolved and we can stop speculating about what the situation here really is.
malxau,
I very much agree. This is getting very much ahead of ourselves, but hypothetically speaking a case between Ubuntu and Oracle could be very helpful in clarifying the legal situation, assuming the court didn’t use some technicality to sidestep the issue.
I’d question whether a kernel is special in this respect. A usermode dynamic library is one where a process can marshal some parameters and call a function which does some processing. A kernel is a dynamic library where a process can marshal some parameters and call a function which happens to perform a ring transition. I can’t imagine that copyright would really consider the mechanics of the function as relevant in determining the outcome.
Copyright, in terms of this discussion, is simply the laws that make the license legally binding. Things like dynamic vs static linking have absolutely nothing to do with copyright law – they are only relevant because the license terms makes them relevant.
The terms of the license do not have to be logical or fair. It is perfectly legal to have illogical and/or unfair license restrictions, and they are still legally binding as long as they do not violate any other law.
I’m not weighing in either way, just pointing out that the clarity of the license terms are all that really matters in the end, not how logical or reasonable they are – i.e. they can be rather stupid and nonsensical as long as their meaning is clear.
Getting to the point, if the authors of the GPL intended for the mechanics to be relevant, then they are relevant. The question is whether the license really makes that intention clear…
Edited 2016-03-02 07:35 UTC
So, there’s the letter of the GPL, and the spirit of the GPL. The spirit, as manifested by many, including its authors, is “linking matters, regardless of how it’s linked”.
Not quite.
If I want to do something, copyright decides whether or not I need a license to do it. If I do, then I need a license and the terms of that license don’t need to be logical, fair, etc. But copyright decides whether I need a license.
I can write a license that says, “if you drink beer on Friday then you must pay me the price of the beer”, but unless you’re doing something that requires this license to be granted, you don’t owe me anything for drinking beer.
The issue here is whether dynamic linking constitutes a derivative work, and if it does, a license would be needed, and that license can impose any obligations it chooses. But if it doesn’t create a derivative work, no copying has occurred, no license is needed, and the whole issue is moot.
Although the FSF have had a position on this, that position isn’t really shared elsewhere. If creating a Mac program that dynamically links to Mac OS constitutes a derivative work of the OS, you’d need a license from Apple allowing that derivative work or developing the app would be unlawful. But where in the license do you have that right granted? Apple actually expressly forbids it (“2C. Except as and only to the extent permitted in this License and by applicable law, you may not…create derivative works of the Apple Software or any part thereof.”)
So if dynamic linking constitutes a derivative work requiring a license grant, all Mac OS users have a big problem. The GPL is much more permissive, because you’re allowed to create derivative works if those are also GPL; Mac OS just says it can’t be done, period. As you say, license terms don’t need to be fair; but if a court decides dynamic linking is a derivative work, that will have big implications on commercial licenses; if they decide it’s not a derivative work, that will have big implications on copyleft licenses.
malxau,
We can explicitly acknowledge that something (aka the beer) does not constitute a derivation of the licensed work (aka the software), and we can explicitly acknowledge that the developers are not entitled to any royalties over the non-derived work (aka the beer). Yet the software license CAN nevertheless dictate terms under which one can and cannot use the licensed work (aka pay the price of the beer). The fact that the beer does not legally derive from any of the developer’s work is not relevant to a developer’s right to restrict the software using illogical/unfair terms. (so long as they don’t break the law).
I hope I didn’t overly abuse the metaphor
Another way to put what galvanash said is this: maybe we can establish that ZFS.ko is not a derivation and is not subject to the GPL, but the same cannot be said about the linux kernel. We might liberate ZFS.ko from the GPL, but when it comes to the kernel itself, it still remains bound by the GPL’s terms (no matter how illogical they might be). “Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.”
I won’t make predictions about the GPL’s enforcability, but I don’t think the issue becomes moot if it turns out that ZFS is not considered a derived work by copyright law.
That license already exists. It is part of the SDK license agreement – much that same as for virtually all commercial software. Microsoft, Oracle, etc., do it pretty much the same way. To use the SDK you agree to the terms, and generally the terms are fairly liberal, letting you develop derivatives (i.e. applications) and do what you will with them for the most part (certain restrictions apply, yada yada).
Edited 2016-03-03 04:21 UTC
But the reins aren’t -by far- at the community hands. The linking interface has to be totally protocollary. The dual licenses could not be so much at an international environment.
Would you bet long term projects on it?
Yes, I am biased and I think the problem only exists on the eyes of extreme copy-leftists: mostly lawyers than make money without coding.
While they figure it out, just use FreeBSD.
is a situation which can create a precedent and start a slippery slope.
How are you enjoying those Apple and Sony contributions?
I really feel copyleft seems too strong in general. LGPL seems more reasonable.
I’ve been recommending using LGPL in many cases.
It adheres to the general ideas of GPL, but makes life easier to understand.
The Linux kernel also sort of does this: it’s GPLv2 with a binary module exception.
If we talk about what Ubuntu ‘may ship’, there is the possibility they will just ignore the controversy, ship the module and hope nobody will sue in the foreseeable future.
euh… if they are confident about the legal status they will ship it in some form. But only if they are confident I assume, because they might end up in court against Oracle which has a lot of money and a big bad legal department.
While the summary is interesting the following shows me that the author does fully grok the problem.
“Given that Oracle holds copyright in both Linux and OpenZFS, and that it already demonstrated willingness to take legal actions against opensource projects, Canonical might still be under significant risk.”
Oracle can’t sue because the CDDL is not the license that SFC alleges Canonical would infringe upon by shipping the zfs kernel module. It’s about the license that the Linux kernel uses, GPL v.2
Oracle does not hold copyright over the Linux kernel and furthermore they’ve already shipped “infringing” products like d-trace with their Unbreakable Linux product.
Sure, the SFC focuses on the GPL, but I would be surprised if the CDDL didn’t matter at least as much.
We know that the CDDL was specifically crafted by SUN’s IP lawyers to prohibit anyone from distributing ZFS with Linux, so they must have seen some legal leverage in case someone tried.
Sorry, but it is you who does not grok the problem.
No, they do. There is some Oracle code in Linux, and it is GPLed. So they are entitled to defending their copyright in Linux. Oracle’s copyright on OpenZFS is not that important, but it allows them to demonstrate that they never authorized third parties to distribute it under different terms, particularily under terms that would satisfy GPL in their view. That is: they can establish all the relevant facts in court without summoning any third parties at all.
Edited 2016-03-01 11:02 UTC
And the module is not distributed under a different license. The module is CDDL compliant as far as we know. Do you know otherwise? Got proof?
The issue is with GPL v2 compliance not with some imagined CDDL non-compliance.
ddc’s point is –as you are saying– that including the CDDL module as part of the GPL-2 Linux kernel infringes on the GPL-2. So, copyright holders that have contributed GPL code to the Linux kernel like Oracle are able to sue Canonical/Ubuntu for this.
Edited 2016-03-01 15:24 UTC
silviucc,
I agree with the emphasized part, it’s a GPL violation. But that doesn’t automatically make it safe.
Any of the linux contributors could theoretically sue over non-GPL usage of their code. It turns out that oracle contributes in the ballpark of 2% of linux changes (*), so if Oracle has a problem with Ubuntu violating the GPL, theoretically they might have a good case. I don’t think it’s relevant that Ubuntu would be violating the GPL with Oracle’s ZFS because Oracle is not violating it themselves.
* http://go.linuxfoundation.org/who-writes-linux-2012
That’s rich. Oracle legal is going to consult with SFC to see who it can and can not sue?
This is very close to the whole Google Oracle lawsuit in spirit. Oracle has cool tech that is open source, but wants people to pay for. Company uses it in an unapproved manner …. without paying!!!!
As per title, the owners of Linux can equally apply a linking exception to it and make it easier on everyone (although unlikely if it hasn’t happened so far). At that point would CDDL be violated though?
CDDL is not violated at all, only GPL is.
That is, more or less, what GPLv3 does. It is rather absurd (and actually double-faced) that GPLv3 “magically” makes Apache and Mozilla licenses compatible, but neither of those are acceptable in GPLv2. And then, CDDL is very similar to MPL2.
I don’t see why the FSF actively rejects a perfectly viable *copyleft* license like CDDL, other than to retain some control (which doesn’t belong to them IMO).
But, could it be preventing ‘flush backs’ of code rights?
**** happens.
Are the best ‘valve’ against ‘flush backs’ of rights.
I’m hardly a fan of mixing licenses.
OSNews usually reads like Daring Fireball, but this was a nice writeup. Good summary and analysis.
Shane,
Yes, I forgot to mention it myself, but it’s nice to have more detailed writeups!
I was going to say the exact same thing. Cudos to dcc for this. Wow, what a helpful article! I had to scroll back and check that I was indeed on OSNews..! No flamebait, but balanced analysis and overview. Please write more!
Thanks Thom and ddc_.
Lots of ‘open’ licenses are not adequately protected from ‘sinking’ decades of community work on the benefit of a few.
Many times those not so open projects -as found too late- nourish from all over the world commitment.
So discouraging. Those contributing communities -and not the interdicted lawyers- should be consulted about the spirit of the license, before any modification.
Could be the best language interface between Law Enforcers and Coders.
On a big guardian falling- Small, fragmented, dispersed community unable to sustain big blocks of code.
🙂 Learning here.
The whole issue seems overblown. Canonical’s lawyers looked into the situation and confirmed there is no copyright issue. They can ship Ubuntu with the ZFS module. Seems pretty open and shut.
The arguments against shipping with ZFS rely on ZFS being a derative work of the Linux kernel, which it is not. Modules that are loaded into the kernel are not subject to the kernel’s license,
Sorry, but couldn’t resist.
Problem is simply solved by using BTRFS instead of ZFS
Btw, why the heck kernel is not LGPL licensed which would prevent problems like this?
Sure, if you don’t give two shits for stability.
That’s what he’s saying. Canonical should throw some engineers at btrfs to bring it up to speed as a ZFS competitor instead of wasting time with this.
Except it’s Canonical, and they don’t have engineers.
Edited 2016-03-01 20:58 UTC
So they’re trying to be like Apple in more ways than one? ^_^
That doesn’t make any sense though. Why hire engineers to create a new solution when an existing, ready solution already exists? Polishing Btrfs would take a lot of resources, years of effort and a lot of money. Plus there are probably relatively few people who can improve the Btrfs code. ZFS is an already working, out of the box solution that has been stable and used in production for a decade. It can be deployed right away and it costs next to nothing to add it to Ubuntu.
Wasting resources on Btrfs gains Canonical very little and would take a lot more time and money to implement.
Because licensing, since that’s all anyone at the SFC care about?