SFC: GPL Violations Related to Combining ZFS and Linux
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. We have written this statement to answer, from the point of view of many key Linux copyright holders, the community questions that we've seen on this matter. Specifically, we provide our detailed analysis of the incompatibility between CDDLv1 and GPLv2 — and its potential impact on the trajectory of free software development — below. However, our conclusion is simple: Conservancy and the Linux copyright holders in the GPL Compliance Project for Linux Developers believe that distribution of ZFS binaries is a GPL violation and infringes Linux's copyright. We are also concerned that it may infringe Oracle's copyrights in ZFS. As such, we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license."
Posted Feb 25, 2016 17:23 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (18 responses)
Posted Feb 25, 2016 17:52 UTC (Thu)
by clump (subscriber, #27801)
[Link] (9 responses)
Posted Feb 25, 2016 19:11 UTC (Thu)
by armijn (subscriber, #3653)
[Link] (8 responses)
I guess that the easiest solution would be to just avoid ZFS on Linux for now if you intended to distribute.
Posted Feb 25, 2016 19:52 UTC (Thu)
by clump (subscriber, #27801)
[Link] (6 responses)
Per your second point, nobody does anything "enterprise" with Linux and ZFS. Sure you can get the two to work together, but you're on your own. If Ubuntu ships a compiled ZFS kmod that could create trouble for downstream distros (and Ubuntu), but would be the closest Linux+ZFS has approaching real support.
It's not looking good for ZFS on Linux if Oracle is to be counted on to make things right.
Posted Feb 25, 2016 20:44 UTC (Thu)
by armijn (subscriber, #3653)
[Link] (1 responses)
So I am just going to sit back and see what happens. It will be interesting.
Posted Feb 25, 2016 21:29 UTC (Thu)
by clump (subscriber, #27801)
[Link]
ZFS is cool, no doubt about it. That said, LVM isn't too shabby. Will ZFS continue to be relevant if Oracle keeps holding it back?
Posted Feb 25, 2016 23:50 UTC (Thu)
by ldo (guest, #40946)
[Link]
The average lifetime of a company on the Fortune 500 is now down to 18 years. Innovation stands still for no-one, least of all the “enterprise”.
Posted Feb 26, 2016 13:23 UTC (Fri)
by kloczek (guest, #6391)
[Link] (1 responses)
Posted Feb 26, 2016 15:09 UTC (Fri)
by clump (subscriber, #27801)
[Link]
Oracle can make this right. Per my comment, I don't think they wish to.
Posted Feb 26, 2016 14:25 UTC (Fri)
by drag (guest, #31333)
[Link]
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.
Posted Feb 25, 2016 21:42 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Feb 25, 2016 21:29 UTC (Thu)
by GhePeU (subscriber, #56133)
[Link] (3 responses)
ZFS on Linux is not Oracle's ZFS, it's a different project (http://open-zfs.org/) based on the last open source release of OpenSolaris, before Oracle killed it and made Solaris closed source again, which has been developed independently for the last 5+ years.
So even if Oracle decided to change the license, either all the developers who contributed to it (including those working on Illumos and FreeBSD) agree to relicense their contributions or someone else has to replicate all the work needed to port it to Linux, starting from a different codebase that's probably incompatible with OpenZFS.
Posted Feb 26, 2016 22:43 UTC (Fri)
by armijn (subscriber, #3653)
[Link] (2 responses)
Posted Feb 26, 2016 23:04 UTC (Fri)
by armijn (subscriber, #3653)
[Link]
Posted Feb 27, 2016 3:40 UTC (Sat)
by k8to (guest, #15413)
[Link]
Posted Feb 26, 2016 2:23 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Feb 26, 2016 12:35 UTC (Fri)
by pboddie (guest, #50784)
[Link] (1 responses)
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!
Posted Feb 27, 2016 3:43 UTC (Sat)
by k8to (guest, #15413)
[Link]
Posted Mar 7, 2016 9:11 UTC (Mon)
by paulj (subscriber, #341)
[Link]
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).
Posted Feb 25, 2016 17:53 UTC (Thu)
by pranith (subscriber, #53092)
[Link] (13 responses)
"we find no specific clause in either license that prohibits source-only redistribution of Linux and ZFS, even on the same distribution media."
Why doesn't Ubuntu follow Debian: compile the module from source instead of insisting on distributing the compiled binary ko?
Posted Feb 25, 2016 18:32 UTC (Thu)
by clugstj (subscriber, #4020)
[Link] (1 responses)
Posted Feb 27, 2016 2:05 UTC (Sat)
by flussence (guest, #85566)
[Link]
Posted Feb 25, 2016 19:25 UTC (Thu)
by ay (guest, #79347)
[Link] (5 responses)
Posted Feb 25, 2016 21:22 UTC (Thu)
by Ed_L. (guest, #24287)
[Link] (4 responses)
Posted Feb 25, 2016 22:02 UTC (Thu)
by fandingo (guest, #67019)
[Link] (3 responses)
Posted Feb 26, 2016 9:44 UTC (Fri)
by sourcejedi (guest, #45153)
[Link] (1 responses)
Posted Feb 27, 2016 12:31 UTC (Sat)
by Ed_L. (guest, #24287)
[Link]
Posted Mar 4, 2016 19:14 UTC (Fri)
by mstone_ (subscriber, #66309)
[Link]
Posted Feb 26, 2016 2:26 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Feb 26, 2016 14:43 UTC (Fri)
by mattdm (subscriber, #18)
[Link] (3 responses)
Posted Feb 28, 2016 0:23 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Mar 1, 2016 0:38 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link]
The loophole is that the binary can't be distributed at all.
Posted Mar 8, 2016 20:14 UTC (Tue)
by davidstrauss (guest, #85867)
[Link]
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.
Posted Feb 25, 2016 18:30 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (13 responses)
Oracle's ZFS has clearly been modified to adapt it to Linux. The adaptations depend both on Linux and ZFS, and thus can not be distributed (unless somebody convinces a judge that there was no creative content in the part taken from Linux, nor the files
Posted Feb 25, 2016 20:34 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (7 responses)
That said the legal standard in the United States is that a derived work is "based upon" another protected work. No court has ever determined that merely consuming an API makes for a derivative work, let alone a derivative work not protected by fair use. The courts have yet to determine whether even cloning and implementing an entire API is allowed under fair use or not.
Whether something has been adapted and what those adaptations are intended for is legally irrelevant. Purpose, use, and dependency have nothing as such to do with whether one work is "based upon" another. Someone out there is perpetrating the greatest legal rumor of all time. It is wishful thinking at best. Until there is actual statutory text or actual case law in favor of any conclusion of the kind it is more like collective self-delusion.
Posted Feb 25, 2016 20:48 UTC (Thu)
by pizza (subscriber, #46)
[Link] (5 responses)
There's worlds of difference between an internal interface (subject to considerable change over time) versus an explicitly standardized external interface.
Posted Feb 25, 2016 21:25 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (4 responses)
What possible argument could be made in favor of the proposition that the difference has anything to do with copyright law?
Posted Feb 25, 2016 22:03 UTC (Thu)
by fandingo (guest, #67019)
[Link] (3 responses)
Posted Feb 26, 2016 1:06 UTC (Fri)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Feb 26, 2016 1:59 UTC (Fri)
by fandingo (guest, #67019)
[Link] (1 responses)
Posted Feb 27, 2016 6:16 UTC (Sat)
by rahvin (guest, #16953)
[Link]
Posted Feb 25, 2016 21:40 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
We are talking internal interfaces here. Not the system call interface, far from it.
Posted Feb 25, 2016 21:24 UTC (Thu)
by spotter (guest, #12199)
[Link] (2 responses)
Posted Feb 25, 2016 21:33 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (1 responses)
Posted Feb 25, 2016 23:03 UTC (Thu)
by spotter (guest, #12199)
[Link]
if Google wins, could one still claim that a non GPLd usage of a GPLd interface is not a fair use usage of said API and hence doesn't fall under the GPL's ability to restrict usage via copyright?
It really feels like the community as as whole is on both sides of this issue in difference cases.
Posted Feb 25, 2016 21:50 UTC (Thu)
by paulj (subscriber, #341)
[Link]
I.e., if you took the unmodified CDDL ZFS core, and you wrote a translation/adaption layer between Linux APIs and the ZFS ones, then only the translation layer would be subject to the GPLv2 of Linux. The CDDL would not extend to the adaption layer, as the CDDL is a "weak" copyleft licence and restricts itself to covered files and "modifications" (exactly what that means may not be 100% clear).
That would be no different to the initial argument for NVidias' binary driver not being derived from Linux.
The key question is: Has the 'core' indeed been left unmodified, and free of changes to accommodate Linux?
Posted Feb 26, 2016 14:26 UTC (Fri)
by drag (guest, #31333)
[Link]
Modifying something to work on Linux doesn't mean it's a derivative work.
Posted Feb 25, 2016 21:21 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (7 responses)
The latter isn't remotely true. GPLv2 obligations are only incurred on someone who wants to distribute a derivative work in a manner that is not permissible under fair use. There is no virus. If party A distributes a dubious derivative work it has absolutely no effect whatsoever on the original code, the obligations of the copyright holders of the original code, or the license to the original code one way or another.
> "The FSF, stewards of the GPL, have stated many times over the past decades that they believe there is no legal distinction between dynamic and static linking of a C program and we agree."
Here the SFC engages in a just so statement without a trace of an actual argument. In the United States it is not an infringement of copyright to make a copy or adaptation of a computer program if it is an "essential step in the utilization of the computer program in conjunction with a machine".
That is a blanket license to adapt, combine, and link - even statically link - any number of programs with incompatible licenses into a unified whole if necessary to run a program on "a" machine. The FSF position which the SFC refers to more as a matter of community norm rather than legal authority is without foundation. It doesn't even try.
The SFC goes on to suggest that Canonical should comply with community norms lest the cause of copyleft be weakened. They want people to engage in wishful thinking in other words, agree to be bound by it, and pretend it has something to do with the law.
Posted Feb 25, 2016 21:42 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (6 responses)
OK. Now go and convince a judge that e.g. selling a photocopy of the Harry Potter books is "fair use".
Posted Feb 25, 2016 21:51 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (4 responses)
e.g. under GPLv2 is joint distribution permissible as a "mere aggregation" or is it distribution of a "collective work" not allowed by the license.
Posted Feb 26, 2016 1:43 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
I'm talking ZFS module for Linux here. That clearly isn't a "mere aggregation" of Linux and ZFS code, and as such can't be distributed at all (unless you convince a judge the pieces going into it aren't creative enough, on one of both sides).
Posted Feb 26, 2016 6:45 UTC (Fri)
by butlerm (subscriber, #13312)
[Link] (2 responses)
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 //
Posted Feb 26, 2016 9:12 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Feb 26, 2016 13:20 UTC (Fri)
by pizza (subscriber, #46)
[Link]
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.
Posted Mar 1, 2016 10:25 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 25, 2016 23:29 UTC (Thu)
by zx2c4 (subscriber, #82519)
[Link] (17 responses)
Posted Feb 25, 2016 23:54 UTC (Thu)
by ldo (guest, #40946)
[Link] (2 responses)
Sure people are. But it doesn’t have the brand recognition of a mega-corporate-backed product like ZFS.
It’s like OpenOffice versus LibreOffice.
Posted Feb 26, 2016 0:08 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
ZFS on Linux is a hacked version of a few year old code, adapted to work with Linux without the benefit of integration, bug fixing, and checking by the regular kernel crowd. I.e., a few years simmering before it reaches production quality.
Posted Feb 26, 2016 16:17 UTC (Fri)
by clump (subscriber, #27801)
[Link]
Posted Feb 26, 2016 1:05 UTC (Fri)
by smckay (guest, #103253)
[Link] (1 responses)
Posted Feb 26, 2016 14:32 UTC (Fri)
by drag (guest, #31333)
[Link]
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."
Posted Feb 26, 2016 9:34 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (8 responses)
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.
Posted Feb 26, 2016 10:26 UTC (Fri)
by ceplm (subscriber, #41334)
[Link] (7 responses)
Posted Feb 26, 2016 10:34 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (6 responses)
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?).
Posted Feb 26, 2016 11:37 UTC (Fri)
by ceplm (subscriber, #41334)
[Link] (5 responses)
Posted Feb 26, 2016 12:00 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (4 responses)
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.)
Posted Feb 26, 2016 13:54 UTC (Fri)
by ceplm (subscriber, #41334)
[Link] (3 responses)
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
Posted Feb 26, 2016 21:13 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (2 responses)
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.
Posted Feb 26, 2016 22:25 UTC (Fri)
by ceplm (subscriber, #41334)
[Link] (1 responses)
Posted Feb 26, 2016 22:28 UTC (Fri)
by ceplm (subscriber, #41334)
[Link]
Posted Feb 26, 2016 10:23 UTC (Fri)
by ceplm (subscriber, #41334)
[Link] (2 responses)
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.
Posted Feb 26, 2016 15:41 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Posted Feb 26, 2016 22:21 UTC (Fri)
by dtlin (subscriber, #36537)
[Link]
Unmounting is not required; filesystems support freezing to a consistent state and dm/LVM automatically use it.
Posted Feb 26, 2016 19:05 UTC (Fri)
by atai (subscriber, #10977)
[Link]
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.
Posted Feb 27, 2016 14:09 UTC (Sat)
by gdt (subscriber, #6284)
[Link]
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
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
Re: nobody does anything "enterprise" with Linux and ZFS
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
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
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
I haven't played with such myself. But what is hacky about including a compiler on the distribution media that is executed early at install time, but is not itself installed by default?
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
Wol
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
#included, nor the functions (or their prototypes and functionality) filched from Linux, neither the other way around).SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
SFC: GPL Violations Related to Combining ZFS and Linux
Wol
Several years ago, while folks realized ZFS was awesome and also incompatible with GPL, there wasn't too much neurosis, because btrfs was supposed to be coming around the corner fast, which promised ZFS-like features and more. Fast-forward to today... What's the status of btrfs? Is anybody actually using it in production? Why has it still never become the ZFS-killer it was promised to be?
btrfs still hasn't come through
Re: Is anybody actually using [btrfs] in production?
Re: Is anybody actually using [btrfs] in production?
Re: Is anybody actually using [btrfs] in production?
There are people who run btrfs still hasn't come through
emerge -e world on production systems. Whether something is used in production isn't a very good yardstick, unfortunately.
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
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?
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
btrfs still hasn't come through
$ 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.
Oracle's own position:
"There is no plan to include ZFS in Oracle Linux. "
SFC: GPL Violations Related to Combining ZFS and Linux