Linux: ZFS, Licenses and Patents

Submitted by Jeremy
on April 19, 2007 - 5:56am

A recent discussion on the lkml examined the possibility of a Linux implementation of Sun's ZFS. It was pointed out that the file system is released under the GPL-incompatible CDDL, and that Sun has filed numerous patents to prevent ZFS from being reverse engineered. Max Yudin pointed out, "according to Jeff Bonwick's blog Sun issued 56 patents on ZFS, but I have no idea what they patented. Sorry, binary compatible ZFS reimplementation with GPL license might not be legal." David Litwin noted that he had been told by a ZFS developer to talk to Linux developers to see about getting non-GPL'd code included with the kernel. Theodore T'so replied, "that was totally useless answer from the ZFS developers. What he should have told you is to contact Sun management, since they are the only ones who can decide whether or not to release ZFS under a GPL license, and more importantly, to give a patent license for any patents they may have filed in the course of developing ZFS."

Alan Cox [interview] suggested, "the real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad. Compare it to what the old Sun company did with NFS, which is now a standard used everywhere." Theodore T'so added, "given that Sun has reportedly filed a huge number of patents covering ZFS and has refused to make them available for anything other than Solaris --- and there are senior Sun programmers who have on record stated that one of the reasons why Sun picked the CDDL was precisely because it was incompatible with GPL and Sun fears Linux ---- I wouldn't bet on Sun being willing to making a patent license available to a hypothetical alternate implementation of the ZFS format for Linux." He went on to note, "of course, this is all open source. If someone wants to work on reimplementing ZFS from scratch, either in userspace or in the kernel, certainly the Linux community won't stop them. Given the patent issues Linus might not feel comfortable including it in the mainline sources without a promise from Sun that they won't sue the pants off of him and The Linux Foundation, but again, that's Sun's decision, and no one else can help you there."


From: "David R. Litwin" [email blocked]
To:  linux-kernel
Subject: ZFS with Linux: An Open Plea
Date:	Fri, 13 Apr 2007 19:18:41 -0400

Before I go on, let me appologise. I don't really know what I hope to  
accomplish, beyond trying to garner thoughts (and support?) for the topic.

Essentially: I want to use Linux and ZFS. I don't particularly care about  
licences or any of the rest of that nonsense. The code is there; it merely  
needs to be made to work with Linux. Done and done -- provided I can find  
some one to do this for me (I'd do it myself, but I haven't the foggiest  
notion how to go about such a feat).

By the way, forget about this FUSE business. I don't know why they're  
bothering: It's not real, it's slow and, in general, silly.

What are the thoughts of the Linux community?

I appologise right now for my intrusion. I am a Linux-nobody; I freely  
admit it. I haven't even subscribed to this list (so do CC me) because I  
don't want to be over-whelmed with the list's glorious posts. But, part of  
Linux is it's being a community. If a member of this community (that is, a  
user of Linux) can't ask the others their
thoughts and opinions, then the community has failed in a large respect.  
Take this letter as you will.

-- 
—A watched bread-crumb never boils.
—My hover-craft is full of eels.
—[...]and that's the he and the she of it.


From: Ignatich [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Sat, 14 Apr 2007 21:40:08 +0400 You might want to look at this discussion: http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/027041.html Let me quote my last letter: The problem is not with CDDL, GPL is the problem. ATI and nVidia do provide binary modules with GPL "adapters", but I don't think legality of this approach was proven in court. I see no parties interested in proving that it is not legal (Intel perhaps?), but Sun is another story. They are not interested in ZFS port for Linux, because Solaris and Linux are real competitors, and if winds change may decide to take legal action. Also, such port can never be included in mainline for obvious reasons and I really want to see storage system such as ZFS as "default" for Linux in future. To sum all of this I see a number of possible solutions for this situation: 1. Sun dual licenses ZFS as GPLv2 and thus gives green light for ZFS-Linux port. Personally I doubt that this will happen. 2. Linux changes it's license. The chance is near zero. 3. US and EU courts clearly state that it is legal to use non-GPL kernel modules in Linux. 4. GPL ZFS reimplementation project is started. I prefer that way until 1), 2) or 3) happen. I know Sun opened most if not all ZFS related patents for OpenSolaris community. So I repeat questions I asked in my first mail: 1. Are those patents limited to CDDL/OpenSolaris code or can by used in GPL/Linux too? 2. If GPL code can't use those patented algorithms, will you please provide list of ZFS-related patents? RAID-Z and LZJB are most obvious technologies which may be patent protected. <end> So far I've got no response from Sun. According to Jeff Bonwick's blog Sun issued 56 patents on ZFS, but I have no idea what they patented. Sorry, binary compatible ZFS reimplementation with GPL license might not be legal. If you know something about this or can help to get ZFS related patent list please send me a mail. Sincerely yours, Max V. Yudin
From: Nikita Danilov [email blocked] Newsgroups: gmane.linux.kernel Subject: Re: ZFS with Linux: An Open Plea Date: Sun, 15 Apr 2007 16:44:57 +0400 Ignatich writes: > You might want to look at this discussion: > http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/027041.html Licenses involved cover file system _code_, rather than storage format that is openly specified. Just stand up and implement driver for zfs format from scratch under whatever license you want. This is exactly how Linux supports "foreign" file systems (ntfs, fat, etc.). Nikita.
From: Alan Cox [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 15:14:07 +0100 On Sun, 15 Apr 2007 16:44:57 +0400 Nikita Danilov [email blocked] wrote: > Ignatich writes: > > You might want to look at this discussion: > > http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/027041.html > > Licenses involved cover file system _code_, rather than storage format > that is openly specified. Just stand up and implement driver for zfs > format from scratch under whatever license you want. This is exactly how > Linux supports "foreign" file systems (ntfs, fat, etc.). That leaves all the patents Sun have filed to prevent anyone doing so.
From: "David R. Litwin" [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Sun, 15 Apr 2007 04:54:13 -0400 On 14/04/07, Neil Brown [email blocked] wrote: It is generally expected that email conversations started on-list will remain on-list, unless there is a special reason to take it off list... though maybe it was an accident on your part. It very much was. I'm not used to not being subscribed to a mailing list. Example of odd commands? mkfs -j /dev/whatever usually does me. Admittedly it might be nice to avoid the -j, but that doesn't seem like a bit issue. Fair enough. > 2: ZFS provides near-platter speeds. A hard-drive should not be > hampered performance-wise by it's file system. That is claimed of XFS too. Really? I must have missed that one.... Any way, I use XFS so this news makes me like it even more. Immediate backups to tape? seems unlikely. Or are you talking about online snapshots. I believe LVM supports those. Maybe the commands there are odd... O fine, be that way with your commands. :-) As I said, though, I'm not an expert. Merely a Linux-user. You know far more about this sort of thing than I ever shall. > 4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some > day.... ext4 will probably cope with that. XFS definitely has very high limits though I admit I don't know what they are. XFS is also a few exobytes. > 5: ZFS has little over-head. I don't want my file system to take up > space; that's for the data to do. I doubt space-overhead is a substantial differentiator between filesystems. All filesystems need to use space for metadata. They might report it in different ways. Again, I'm simply reporting what I've heard. Well, read. > > It is possible that that functionality can be > > incorporated into Linux without trying to clone or copy ZFS. > > > I don't deny this in the least. But, there's good code sitting,waiting > to be used. Why bother starting from scratch or trying to > re-do what is already done? Imagine someone wanting some cheap furniture and going to a 'garage sale' at a light-house. All this nice second-hand furniture, but you can tell it won't fit in your house as it all has rounded edges... It is a bit like that with software. It might have great features and functionality, but that doesn't mean it will fit. XFS is a prime example. It was ported to Linux by creating a fairly substantial comparability interface so that code written for IRIX would work in Linux. That layer makes it a lot harder for other people to maintain the software (I know, I've tried to understand it and never got very far). I've heard of the horrors of XFS's code. But, is there really that much work to be done to port ZFS to Linux? This is one area for which I have no information, as no one has tried (save the FUSEy folk) due to Lisences. To inform me! - Hide quoted text - -- —A watched bread-crumb never boils. —My hover-craft is full of eels. —[...]and that's the he and the she of it.
From: Rik van Riel [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Sun, 15 Apr 2007 20:50:25 -0400 David R. Litwin wrote: >> 4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some >> day.... > > ext4 will probably cope with that. XFS definitely has very high > limits though I admit I don't know what they are. > > XFS is also a few exobytes. The fsck for none of these filesystems will be able to deal with a filesystem that big. Unless, of course, you have a few weeks to wait for fsck to complete. Backup and restore are similar problems. When part of the filesystem is lost, you don't want to have to wait for a full restore. Sounds simple? Well, the hard part is figuring out exactly which part of the filesystem you need to restore... I don't see ZFS, ext4 or XFS addressing these issues. IMHO chunkfs could provide a much more promising approach. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic.
From: David Chinner [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Mon, 16 Apr 2007 13:07:05 +1000 On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote: > David R. Litwin wrote: > > >>4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some > >>day.... > > > >ext4 will probably cope with that. XFS definitely has very high > >limits though I admit I don't know what they are. > > > >XFS is also a few exobytes. > > The fsck for none of these filesystems will be able to deal with > a filesystem that big. Unless, of course, you have a few weeks > to wait for fsck to complete. Which is why I want to be able to partially offline a chunk of a filesystem and repair it while the rest is still online..... > Backup and restore are similar problems. When part of the filesystem > is lost, you don't want to have to wait for a full restore. > > Sounds simple? Well, the hard part is figuring out exactly which > part of the filesystem you need to restore... > > I don't see ZFS, ext4 or XFS addressing these issues. XFS has these sorts of issues directly in our cross-hairs. The major scaling problem XFS has right now is to do with how long repair/backup/restore take when you have hundreds of terabytes of storage. > IMHO chunkfs could provide a much more promising approach. Agreed, that's one method of compartmentalising the problem..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group
From: Valerie Henson [email blocked] Subject: Repair-driven file system design (was Re: ZFS with Linux: An Open Plea) Date: Mon, 16 Apr 2007 15:34:42 -0700 On Mon, Apr 16, 2007 at 01:07:05PM +1000, David Chinner wrote: > On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote: > > > IMHO chunkfs could provide a much more promising approach. > > Agreed, that's one method of compartmentalising the problem..... Agreed, the chunkfs design is only one way to implement repair-driven file system design - designing your file system to make file system check and repair fast and easy. I've written a paper on this idea, which includes some interesting projections estimating that fsck will take 10 times as long on the 2013 equivalent of a 2006 file system, due entirely to changes in disk hardware. So if your server currently takes 2 hours to fsck, an equivalent server in 2013 will take about 20 hours. Eek! Paper here: http://infohost.nmt.edu/~val/review/repair.pdf While I'm working on chunkfs, I also think that all file systems should strive for repair-driven design. XFS has already made big strides in this area (multi-threading fsck for multi-disk file systems, for example) and I'm excited to see what comes next. -VAL
From: David Chinner [email blocked] Subject: Re: Repair-driven file system design (was Re: ZFS with Linux: An Open Plea) Date: Tue, 17 Apr 2007 11:09:32 +1000 On Mon, Apr 16, 2007 at 03:34:42PM -0700, Valerie Henson wrote: > On Mon, Apr 16, 2007 at 01:07:05PM +1000, David Chinner wrote: > > On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote: > > > > > IMHO chunkfs could provide a much more promising approach. > > > > Agreed, that's one method of compartmentalising the problem..... > > Agreed, the chunkfs design is only one way to implement repair-driven > file system design - designing your file system to make file system > check and repair fast and easy. I've written a paper on this idea, > which includes some interesting projections estimating that fsck will > take 10 times as long on the 2013 equivalent of a 2006 file system, > due entirely to changes in disk hardware. That's assuming that repair doesn't get any more efficient. ;) > So if your server currently > takes 2 hours to fsck, an equivalent server in 2013 will take about 20 > hours. Eek! Paper here: > > http://infohost.nmt.edu/~val/review/repair.pdf > > While I'm working on chunkfs, I also think that all file systems > should strive for repair-driven design. XFS has already made big > strides in this area (multi-threading fsck for multi-disk file > systems, for example) and I'm excited to see what comes next. Two steps forward, one step back. We found that our original approach to multithreading doesn't always work, and doesn't work at all for single disks. Under some test cases, it goes *much* slower due to increased seeking of the disks. This patch from the folk at Agami: http://oss.sgi.com/archives/xfs/2007-01/msg00135.html used a different threading approach to speeding up the repair process - it basically did object path walking in separate threads to prime the block device page cache so that when the real repair thread needed the block it came from the blockdev cache rather than from disk. This sped up several phases of the repair process because of re-reads needed in the different phases. What we found interesting about this approach is that it showed that prefetching gave as good or better results than simple parallelisation with a rudimentary caching system. In most cases it was superior (lower runtime) to the existing multithreaded xfs_repair. However, the Agami object based prefetch does not speed up phase 3 on a single disk - like strided AG parallelism it increases disk seeks and, as we discovered, causes lots of little backwards seeks to occur. It also performs very poorly when there is not enough memory to cache sufficient objects in the block dev cache (whose size cannot be controlled). It sped things up by using prefetch to speed up (repeated) I/O, not by using intelligent caching..... However, this patch has been very instructive on how we could further improve the threading of xfs_repair - intelligent prefetch is better than simple parallelism (from the Agami patch), caching is far better than rereading (from the SGI repair level caching) and that prefetching complements simple parallelism on volumes that can take advantage of it. We've ended up combining a threaded, two phase object walking prefetch with spatial analysis of the inode and object layouts and integration into a smarter internal cache. This cache is now similar to the xfs_buf cache in the kernel and uses direct I/O so if you have enough memory you only need to read objects from disk once. Spatial analysis of the metadata is used to determine the relative density of the metadata in an area of disk before we read it. Using a density function, we determine if we want to do lots of small I/Os or one large I/O to read the entire region in one go and then split it up in memory. Hence as metadata density increases, the number of I/Os decrease and we pull enough data in to (hopefully) keep the CPUs busy. We still walk objects, but any blocks behind where we are currently reading go into a secondary I/O queue to be issued later. Hence we keep moving in one direction across the disk. Once the first pass is complete, we then do the same analysis on the secondary list and run that I/O all in a single pass across the disk. This is effectively a result of observing that repair is typically seek bound and only using 2-3MB/s of the bandwidth a disk has to offer. Where metadata density is high, we are now seeing luns max out on bandwidth rather than being seek bound. Effectively we are hiding latency by using more bandwidth and that is a good tradeoff to make for a seek bound app.... The result of this is that even on single disks the reading of all the metadata goes faster with this multithreaded prefetch model. A full 250GB SATA disk with a clean filesystem containing ~1.6 million inodes is now taking less than 5 minutes to repair. A 5.5TB RAID5 volume with 30 million inodes is now taking about 4.5 minutes to repair instead of 20 minutes. We're currently creating a multi-hundred million inode filesystem to determine scalability to the current bleeding edge. One thing this makes me consider is changing the way inodes and metadata get laid out in XFS - clumping metadata together will lead to better scan times for repair because of the density increase. Dualfs has already proven that this can be good for performance when done correctly; I think it also has merit for improving repair times substantially as well. FWIW, I've already told Barry he's going to have to write a white paper about all this once he's finished..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group
From: "David R. Litwin" [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 02:54:32 -0400 On 15/04/07, Jesper Juhl wrote: On 14/04/07, David R. Litwin [email blocked] wrote: > Before I go on, let me appologise. I don't really know what I hope to > accomplish, beyond trying to garner thoughts (and support?) for the > topic. > > Essentially: I want to use Linux and ZFS. I don't particularly care about > licences or any of the rest of that nonsense. The license that protects the code we write is far from nonsense. I know. In the end, this is the reason this topic is being discussed. I suggest the first thing you do is contact the ZFS developers and convince them to release their code under a license that's GPL compatible, then we can start looking at a Linux port. I began by contacting them. One of the devs there told me to contact the Linux devs. > FUSE is nice for trying out new and interresting ideas in userspace - > it has its uses. Yes, but it is not really for the end-user. To paraphrase another, it is mostly academic. > What are the thoughts of the Linux community? > > Can't tell you that, all I can tell you is my own oppinion. You make up a member of the Linux community. > I believe > ZFS for Linux would be interresting, if not for any other reason then > for compatibility. For the greater glory of Linux? :-) > I'd personally like to see it - but, settle the > license issue first. And we've come full circle: The liconsinc issue. -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -- —A watched bread-crumb never boils. —My hover-craft is full of eels. —[...]and that's the he and the she of it.
From: Theodore Tso [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 09:10:45 -0400 On Tue, Apr 17, 2007 at 02:54:32AM -0400, David R. Litwin wrote: > > The license that protects the code we write is far from nonsense. > > I know. In the end, this is the reason this topic is being discussed. > > I suggest the first thing you do is contact the ZFS developers and > convince them to release their code under a license that's GPL > compatible, then we can start looking at a Linux port. > > I began by contacting them. One of the devs there told me to contact the > Linux devs. Well, that was totally useless answer from the ZFS developers. What he should have told you is to contact Sun management, since they are the only ones who can decide whether or not to release ZFS under a GPL license, and more importantly, to give a patent license for any patents they may have filed in the course of developing ZFS. This is not anything Linux developers can help you with. - Ted
From: Tomasz Kłoczko [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 15:47:32 +0200 (CEST) On Tue, 17 Apr 2007, Theodore Tso wrote: [..] > Well, that was totally useless answer from the ZFS developers. What > he should have told you is to contact Sun management, since they are > the only ones who can decide whether or not to release ZFS under a GPL > license, and more importantly, to give a patent license for any > patents they may have filed in the course of developing ZFS. This is > not anything Linux developers can help you with. Realy can't or don't want (?) So who is responsible for potential changing Linux code licensing for allow if not incorporate CDDL code correct interraction without breaking some law ? And/or what Linux can loose on follow this king changes ? And/or why Linux code licensing can't evolve ? Seems when Linux code was licensed noone was thinking about case like interraction with code under license like CDDL so why now it can be corrected and still many people try to think like "anything arond Linux must evolve .. but not Linux" (?) Why this can't be fixes ? If in this ponit in Linux "evniroment" can't be chaged .. sorry but is it not kind of hipocritics ? kloczek
From: Alan Cox [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 15:48:14 +0100 > So who is responsible for potential changing Linux code licensing for > allow if not incorporate CDDL code correct interraction without breaking > some law ? Every single contributor, individually. Which won't happen. The real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad. Compare it to what the old Sun company did with NFS, which is now a standard used everywhere. If Sun want ZFS to get used all over the place in free software then I'd have expected at the very least to see them throw out a copy of the code, docs and patent grant in a form that could be used, even if it came with no other assistance of any kind. Now would be a great time to do that, but I can't see it happening, instead they'll miss the boat just as microsoft did with Office XML (three years ago they'd have sailed it through ISO to the sound of fanfairs) Alan
From: Daniel Hazelton [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 12:22:19 -0400 On Tuesday 17 April 2007 09:47:32 Tomasz Kłoczko wrote: > On Tue, 17 Apr 2007, Theodore Tso wrote: > [..] > > > Well, that was totally useless answer from the ZFS developers. What > > he should have told you is to contact Sun management, since they are > > the only ones who can decide whether or not to release ZFS under a GPL > > license, and more importantly, to give a patent license for any > > patents they may have filed in the course of developing ZFS. This is > > not anything Linux developers can help you with. > > Realy can't or don't want (?) As it has been explained to you before it is "can't" > So who is responsible for potential changing Linux code licensing for > allow if not incorporate CDDL code correct interraction without breaking > some law ? If I've parsed this query correctly the answer is: Linux is licensed under the GPL and because a number of people that have contributed code to it can no longer agree to a change in the license because they have died this cannot be changed. That was explained quite clearly in several mails as well. > And/or what Linux can loose on follow this king changes ? > And/or why Linux code licensing can't evolve ? Seems when Linux code was > licensed noone was thinking about case like interraction with code under > license like CDDL so why now it can be corrected and still many people try > to think like "anything arond Linux must evolve .. but not Linux" (?) When Linux was licensed under the GPL there was only *ONE* real choice for licensing it. Linus released the code under the GPL and there it has remained, with Linus leading development. If Linux had *NOT* been released under the GPL it would not be as popular or as powerful as it is - and that is not an opinion but a statement of fact. > Why this can't be fixes ? See the previous statement and several previous mails in this thread. Linux is licensed under the GPL, it is the *only* license agreed to by everyone that has contributed code. If I remember the statistics, there have been something like 10,000 different people that have contributed code. Since each contributor holds the copyright on their code they are the *ONLY* people that could change the license on it. Anyone attempting to change the license without agreement from *everyone* that has contributed code to the kernel they are in violation of US and international copyright laws. > If in this ponit in Linux "evniroment" can't be chaged .. sorry but is it > not kind of hipocritics ? Nope. You've just ignored it when it was explained *why* the existing ZFS code cannot be simply be ported to Linux. If you really need ZFS on linux, might I suggest that you port the code on your own and maintain whatever patches are needed to use it? As it stands ZFS *might* show up in Linux as a from-scratch implementation, although I stress the "might" because there are patents involved. DRH (Now please, drop the subject - IMNSHO it is never going to happen)
From: Theodore Tso [email blocked] Subject: Re: ZFS with Linux: An Open Plea Date: Tue, 17 Apr 2007 13:50:55 -0400 On Tue, Apr 17, 2007 at 12:22:19PM -0400, Daniel Hazelton wrote: > Nope. You've just ignored it when it was explained *why* the existing ZFS code > cannot be simply be ported to Linux. If you really need ZFS on linux, might I > suggest that you port the code on your own and maintain whatever patches are > needed to use it? As it stands ZFS *might* show up in Linux as a from-scratch > implementation, although I stress the "might" because there are patents > involved. Given that Sun has reportedly filed a huge number of patents covering ZFS and has refused to make them available for anything other than Solaris --- and there are senior Sun programmers who have on record stated that one of the reasons why Sun picked the CDDL was precisely because it was incompatible with GPL and Sun fears Linux ---- I wouldn't bet on Sun being willing to making a patent license available to a hypothetical alternate implementation of the ZFS format for Linux. Again, this is is Sun's fault, and it's because they fear Linux, and it may have something to do with the fact that the vast majority of their Opteron boxes get Linux installed instead of Solaris. The bottom line is that people who would like ZFS need to understand that the code is Copyright by Sun, and there are almost certainly patents owned by Sun, and if they choose licenses that are explicitly designed to be incompatible with Linux, we should respect Sun's deep-seated fear of Linux, and we can continue trying to innovate around better filesystem and LVM storage technologies, as opposed to trying to chase the ZFS tail lights. Of course, this is all open source. If someone wants to work on reimplementing ZFS from scratch, either in userspace or in the kernel, certainly the Linux community won't stop them. Given the patent issues Linus might not feel comfortable including it in the mainline sources without a promise from Sun that they won't sue the pants off of him and The Linux Foundation, but again, that's Sun's decision, and no one else can help you there. - Ted

Related Links:

But the GPL incompatibilty

Anonymous-huh (not verified)
on
April 19, 2007 - 7:21am

But the GPL incompatibilty is only for distributing binaries.
Someone can still create a source ZFS patch for Linux, so that people can create the binaries themselves.

It's not the ideal sollution but still..

SNgnvZ

on
May 3, 2011 - 10:30pm

pxqSYdW SNgnvZ

FUD?

trasz (not verified)
on
April 19, 2007 - 8:10am

Alan Cox wrote:

> The real test of whether Sun were serious about ZFS being anywhere but
> Solaris is what they do to license it - they've patented everything they
> can, and made the code available only under licenses incompatible with
> other OS products.

Unfortunately, this is very far from truth. ZFS license is perfectly compatible with other
OS products - ZFS became part of FreeBSD few weeks ago, for example. The _only_ product
that ZFS cannot be ported to is Linux, and _only_ because GPL license prevents from linking
with non-GPLed code that cannot be relicensed under GPL, like BSD or MIT can.

So, the question is, why do the Linux developers spread FUD like this?

Are you stupid? Did you miss

Suzie Sixpack (not verified)
on
April 19, 2007 - 8:54am

Are you stupid? Did you miss it when Sun wrote the CDDL with the *explicit intention* of being GPL-incompatible (something also hinted at above)? The only reason that they don't mind ZFS being ported to the *BSDs is because those don't matter, anyway - they're not a threat to Solaris. Linux, on the other hand, is, and that's why Sun doesn't want ZFS to end up there and why they CHOSE to license it in a way that did indeed make it impossible to just port the code.

First, lets check the very

trasz (not verified)
on
April 19, 2007 - 10:05am

First, lets check the very simple fact: which license contains clause that makes it impossible to link CDDL and GPL code? Is it anywhere in CDDL? Nope. It's the GPL.

Second, licensing ZFS under GPL would make it impossible to include it in any operating system other than Linux. It would be impossible to port it to FreeBSD, MacOS X or even Solaris, since
GPL is incompatible with all these.

Third - sure, Sun doesn't really want to invest money in IBM and HP. This works both ways - IBM and HP does not allow their code to be included in any operating system other than Linux. It's
much more aggresive than in the case of Sun - code under CDDL can be included in FreeBSD or MacOS X, while code under GPL cannot.

Fourth: this may seem strange, but IMO there is _no_ real licensing problem with porting ZFS to Linux at all. The GPL license does not directly say that linking with non-GPL code is prohibited.
RMS says so, but many/most lawyers don't agree with that. Also, the patents problem is nonexistant - CDDL explicitly grants rights to use patented software. The problem is just with
NIH and attitude of Linux developers and IBM management. Can you imagine IBM marketing folks
advertising a breakthrough feature that was ported from their competitors' OS?

(Note: in this post i say 'Linux' when i mean 'any GPL-ed OS'. Since Linux is pretty much the only
serious operating system licensed under GPL, it's not that important.)

Hmmm....

on
April 19, 2007 - 2:15pm

First, lets check the very simple fact: which license contains clause that makes it impossible to link CDDL and GPL code? Is it anywhere in CDDL? Nope. It's the GPL.

It takes two to tango, and it takes two licenses to be incompatible. The CDDL came along after the GPL, and it was written specifically to be incompatible with the GPL. How hard is that to understand? It's not like the GPL chose specifically to be incompatible with the CDDL. The GPL laid out its terms, and the CDDL specifically chose to be incompatible with them.

Second, licensing ZFS under GPL would make it impossible to include it in any operating system other than Linux. It would be impossible to port it to FreeBSD, MacOS X or even Solaris, since GPL is incompatible with all these.

Non sequitur. ZFS could easily be dual licensed.

It's very easy for the

trasz (not verified)
on
April 19, 2007 - 10:57pm

It's very easy for the license to be incompatible with GPL - basically, it just needs to claim something that GPL doesn't, like, for example, that every modification has to be made available to the originating project. If you need that, then your code won't be compatible with GPL. It's because GPL was explicitly made to be incompatible with everything else.

Yes, it's technically possible to dual license ZFS. But why should Sun choose to make their code compatible with GPL, when the GNU guys tried very hard to make their code uncompatible with everyone else?

It's obvious you're no GPL fan

on
April 20, 2007 - 11:08am

FWIW, the GPL essentially does require that any distributed changes are made available to the original project. You need to make the source available for any changes you make to anyone you distribute the modified version to. So, the original project can always choose to take those changes.

Where GPL differs from other licenses is it does not compel you to sign over rights to code you contribute, so you can keep your copyrights to it. Because each individual retains the rights to their code, they can choose whether they want that code to be part of a proprietary product.

For example, contributors to Mozilla have multiple choices: They can contribute a GPL-only patch, which anyone can apply, but which the Mozilla folks will probably ignore, as is their prerogative. Or, they can choose to offer their patch under Mozilla's tri-license (NPL, MPL and GPL) at which point it becomes eligible for inclusion in the mainline sources. (I seem to recall some shifts in Mozilla's licensing rules. I'm probably out of date on the *current* situation, but that doesn't invalidate my point.) The point is, the GPL does not force contributors to relinquish their rights. Contributors can then decide what rights they're willing to waive on a case by case basis.

The GPL protects rights of the individuals. It protects the user's right to access the source code. It protects the copyrights of the contributors such that their code remains accessible to the end users and to other programmers.

Given that most licenses exist to restrict one's rights or to compel one to surrender rights, it's little wonder that a license that aims to protect rights is incompatible.

I have not read the whole of

Erik Wikström (not verified)
on
April 22, 2007 - 1:51pm

I have not read the whole of the MPL or NPL but I'm quite sure that neither of those licences require the creator to relinquish his rights. I'd suspect that they just like all other licences just define under what terms and how the copyrighted work might be used.

If the Mozilla Foundation (or whoever) requires that some additional rights be relinquish for the code to be included then that is totally up to each project to decide. It does not take much thinking to see why they might wish this either just look at the work needed to remove the advertisement clause from FreeBSD (don't know if they've got it all out). By making sure that one central organization owns all the rights such problems can easily be avoided plus it can be useful in other legal matters.

As for the matter of CDDL being designed specifically to be incompatible with GPL, I don't buy it, sure there might have been a wish for such a thing but I hardly believe that it had any influence on the wording. The simple fact is that it's hard to create a licence with more complexity that the BSD and MIT licences without being incompatible unless you aim specifically to be compatible. How many (popular) open source licences are there out there that are compatible with GPL compared to the total number of (popular) licences? I don't know but I think it's quite few.

Proof that CDDL *was* designed to be GPL-incompatible

Sum Yung Gai (not verified)
on
June 25, 2007 - 7:45am

Danese Cooper, the (at the time) Sun manager who wrote the CDDL, also made it quite clear at DebConf that it was chosen specifically because it is GPL-incompatible. Here is a link to the video proving it (very long URL, BTW).

Video times with Danese's speech is from:
http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/the...
27 minutes 27 seconds through 28 minutes 24 seconds

So for anyone saying that somehow the Linux dev team can magically fix the patent/licensing problem that Sun created here is clearly "smoking crack." Alan is right; it's up to Sun, since Sun owns both the code *and* the patents.

--SYG

The BSD license existed

Anonymous (not verified)
on
April 22, 2007 - 2:55pm

The BSD license existed before the GPL license, and the GPL license was specificly incompatible w/ the BSD license. Who chose to be incompatible?

GPL was not designed to be

Joshland (not verified)
on
April 25, 2007 - 11:43am

GPL was not designed to be incompatible with BSD, it was designed to protect the rights of users of software. GPL comes from the standpoint that users ought to have access to the source, permission to change it, and the ability to redistribute the changes to other people. Hence, there are reasons why some companies don't want to do that.

BSD is designed to allow software to perpetually exist in freedom, without stopping private developers from taking it for any and all commercial use.

CDDL was designed to allow Sun to release source, without the guarantees and freedoms granted by GPL. (Modification, redistribution, etc, etc.)

Re: GPL was not designed to be

markp (not verified)
on
April 30, 2007 - 9:14am

Yeah, sure the CDDL was designed so people couldn't release source, modify those sources and redistribute them. In that case the CDDL would be a Free license... Oh wait.

http://www.fsf.org/licensing/licenses/

Did you miss it when Sun

Insight (not verified)
on
April 19, 2007 - 10:10am

Did you miss it when Sun wrote the CDDL with the *explicit intention* of being GPL-incompatible

Funny, I remember Sun writing the CDDL to ensure that changes to OpenSolaris could always be folded back into non-source distributions, something the GPL explicitly forbids.

It's quite easy for Linux zealots to (deliberately) misinterpret this as meaning Sun wants OpenSolaris code to stay out of Linux. After all, why else would Sun avoid giving away half a decade of hard work? It couldn't POSSIBLY be because Linux devs using the GPL would work keep their code out of OpenSolaris by using the GPL, could it? Funny, that if Linux devs keep their code out of other OSes it's fine but if Sun does the same thing they're being uncooperative.


I'll let you in on a little secret. All the Linux kernel devs really care about is that the Single Master Version of code live in the Linux kernel. Then Linux kernel devs promise to stay standards-compliant, and everyone else keeps in sync with Linux. Linux devs are just upset that Sun wants to keep the Single Master Version in OpenSolaris. The license argument is just a legal manifestation of squabbles over ownership.

Uhm...

on
April 19, 2007 - 3:07pm

Did it occur to you that Linux attracts the developer community it has because they're interested in their contributions remaining in the open? That is, that the Linux kernel can never go "closed"? Sure, Linus himself was somewhat ambivalent on license back when he first uploaded Freax 16 years ago. The community that formed around it, though, came in part because of the license.

Sure, everyone rallies behind the Linus kernel, because the Linus kernel is good. But suppose Linus gets hit by a bus. Nobody can swoop in and take the kernel private. Someone else such as Andrew or Alan could easily step up with their branch and everyone could rally behind that. If someone wants to fork, go for it! If you get a lot of users, then people will rally behind your fork.

Sun's CDDL lets them take contributions private. They can go "closed" at any time, and many people aren't comfortable with that idea. Those that are can contribute to OpenSolaris or any of the BSDs. And, like Microsoft did back in the 90s and Apple did more recently, they can see the a proprietary product swoop up their code and say "Thank you!"

You seem to imply that after

trasz (not verified)
on
April 19, 2007 - 10:46pm

You seem to imply that after "closing" the software, peoples' contributions somehow stop being available "in open". That is not true - while it is possible to "close" the sources, it is not possible to prevent other people from distributing and developing the open version. In other words, Sun - or anybody else - can only close _their copy_.

Good example of that are the BSDs - they were closed many times, for example by Juniper to use in their routers. That never caused any problems to the developers or the users. Most of them even didn't notice that, since the only affected parties are closing vendor and its clients.

Yes and no

on
April 20, 2007 - 11:10am

When a party takes a snapshot of a non-GPL project and closes it, all the changes they do to the closed version can stay closed. We don't benefit from bug fixes, ports, new features, what-have-you. I see GPL as a quid pro quo. I share my changes with you, you share your changes with me. The BSD licenses lack that property.

HUH?

Azerthoth (not verified)
on
April 20, 2007 - 2:50pm

There is no provision in the GPL that says I have to share any changes I make to any code. I only have to share those changes if I actually distribute the changed package. I can have as many "in house" variants of whatever package as I want and not have to share a single thing.

Apple has contributed to open-source projects

Derek Morr (not verified)
on
April 20, 2007 - 12:44pm

Actually, Apple has contributed to open-source projects. They've released modifications to FreeBSD, GCC, and KDE for example. They've also ported Sun's DTrace and ZFS technologies to OS X 10.5. The latter was possibly only because DTrace and ZFS aren't GPL'ed.

I don't know how we got on to Apple

_Shade_JMS (not verified)
on
April 20, 2007 - 2:20pm

I don't know how we got on to Apple-- but in the case of KHTML there was much drama there. Apple basically did the bare minimum under the LGPL to turn KHTML into WebCore, then the Apple PR people revved up and said, "Look how nice we play", the KHTML people were left scratching their heads going, "The absolute bare minimum under the licence isn't 'playing nice'. That's when you actually, oh, you know communicate with us and present your code in a way that isn't reminiscent of the 'diff of doom' once per release of Webcore." Apple was basically shamed into playing 'nicer'.

Ultimately, large companies will scoop up whatever useful code they can, and give back as little as possible. The only time that isn't true is when the code in question could be considered a cornerstone of their future business. Even that's more of an exercise in externalizing costs and putting a nice PR gloss over it to establish credibility with those who are doing the work. Business plans change--

If it's not explicitly in the licence don't expect to get much more back from 'Business Interests'. That's the reason for all of the BSD-shame-a-thons over the years and why the KHTML folk did the same. 'Business has it's own interests, if it's not in the licence your only recourse is to hit them in their 'optics' :) That's why I prefer the quid pro quo of the GPL (and free software). Everything else turns open source developers in to beggars.

FUD FUD FUD.

gggggttt (not verified)
on
April 22, 2007 - 12:05pm

FUD FUD FUD.

D'oh! Which one was first:

Anonymous2 (not verified)
on
April 19, 2007 - 9:12am

D'oh!

Which one was first: Linux or ZFS?

which one was first: DOS or Linux

Anonymous (not verified)
on
June 18, 2007 - 9:51pm

Sun designed and created ZFS. They choose which license they want to use. FreeBSD doesn't have a problem with it. OpenBSD doesn't have a problem with it. Mac OS X doesn't have a problem with it.

ONE rogue state's patents on written works... AGAIN

AnonEmouse (not verified)
on
April 20, 2007 - 5:03pm

Sun can licence their legitimately copyrighted work however they please. It is their right. Their licence is quite generous. If Linux's licence isn't compatible, sit down as usual & re-implement something far better. THAT is why linux hosts the reference implementation of so many things. Host it in a country where politicians aren't pre-selected by corporations, and normal patent laws apply.

It is SOOOO frustrating when one big apple's disregard for international convention leads to discussions about why things can't be done by the rest of a global community. Yes Sun is a big US company. Their product is "red white & blue" with apple sauce on top. I live in a truly free, truly democratic country that truly respects international conventions on IP, & these patents (assuming they are patents on written works) are not recognised as valid.

(granted a handful of other countries now respect patents on written works too. ばかだな! I would suggest that it stems more out of an interest in assisting their companies to fight US patents covering their prior art, more a general problem)

GPL incompatibility is not an issue for Sun

Anonymous Coward (not verified)
on
April 19, 2007 - 5:28pm

As was repeatedly stated, Sun is not really interested in ZFS for Linux. So if Linux developers want ZFS in (which seems doubtful), they will have to move.

Concerning whether GPL incompatibility was a goal of the CDDL, there are lots of opinion statements. But nothing official from Sun. In any case, the FSF and Sun are working on having this resolved in the next version of the GPL.

The often repeated mantra that relicensing the Linux kernel is impossible, is not true. It would require the consent of the kernel developers or those who inherited the rights to the code. If rights holder disagrees, his code would have to be rewritten - note that major parts of the kernel get rewritten in each release anyway.

So it all comes down to the question whether integrating ZFS is worth the (admittedly huge) effort. Some kernel developers have already expressed disapproval of the RAID/LVM integration in ZFS, the license notwithstanding.

ZFS instead of Reiser4?

on
April 19, 2007 - 11:28pm

Why should ZFS be any more Linux "compatible" than Reiser4 was not?

ZFS instead of Reiser4?

XX (not verified)
on
April 20, 2007 - 9:14pm

ZFS instead of Reiser4?

Well Reiser4 already works, and works well:

You can read more here:

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm

.-------------------------.
| FILESYSTEM | TIME |DISK |
| TYPE       |(secs)|USAGE|
.-------------------------.
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
.-------------------------.
|REISER4     | 3462 | 692 |
|EXT2        | 4092 | 816 |
|JFS         | 4225 | 806 |
|EXT4        | 4408 | 816 |
|EXT3        | 4421 | 816 |
|XFS         | 4625 | 779 |
|REISER3     | 6178 | 793 |
|FAT32       |12342 | 988 |
|NTFS-3g     |10414 | 772 |
.-------------------------.

Column one measures the time taken to complete the bonnie++ benchmarking test (run with the parameters bonnie++ -n128:128k:0). The top two results use Reiser4 with compression. Since bonnie++ writes test files which are almost all zeros, compression speeds things up dramatically. That this is not the case in real world examples can be seen below where compression does not speed things up. However, more importantly, it does not slow things down either.

Column two, Disk Usage: measures the amount of disk used to store 655MB of raw data (which was 3 different copies of the Linux kernel sources).

OR LOOK AT THE FULL RESULTS:

.-------------------------------------------------.
|File         |Disk |Copy |Copy |Tar  |Unzip| Del |
|System       |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type         | (MB)| (1) | (2) |655MB|655MB| Gig |
.-------------------------------------------------.
|REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
|REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
|REISER4 tails| 673 | 148 |  63 |  78 |  33 |  65 |
|REISER4      | 692 | 148 |  55 |  67 |  25 |  56 |
|NTFS3g       | 772 |1333 |1426 | 585 | 767 | 194 |
|NTFS         | 779 | 781 | 173 |   X |   X |   X |
|REISER3      | 793 | 184 |  98 |  85 |  63 |  22 |
|XFS          | 799 | 220 | 173 | 119 |  90 | 106 |
|JFS          | 806 | 228 | 202 |  95 |  97 | 127 |
|EXT4 extents | 806 | 162 |  55 |  69 |  36 |  32 |
|EXT4 default | 816 | 174 |  70 |  74 |  42 |  50 |
|EXT3         | 816 | 182 |  74 |  73 |  43 |  51 |
|EXT2         | 816 | 201 |  82 |  73 |  39 |  67 |
|FAT32        | 988 | 253 | 158 | 118 |  81 |  95 |
.-------------------------------------------------.

Each test was preformed 5 times and the average value recorded.
Disk Usage: The amount of disk used to store the data (which was 3 different copies of the Linux kernel sources).
The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB.
Copy 655MB (1): Copy the data over a partition boundary.
Copy 655MB (2): Copy the data within a partition.
Tar Gzip 655MB: Tar and Gzip the data.
Unzip UnTar 655MB: UnGzip and UnTar the data.
Del 2.5 Gig: Delete everything just written (about 2.5 Gig).

http://lkml.org/lkml/2007/4/9/4

OpenSolaris moving towards GPL v3 License

Bill McGonigle (not verified)
on
April 20, 2007 - 11:05am

Several sources have suggested that Sun is likely to dual-license OpenSolaris under GPL v3 if it likes what it sees once GPL v3 is done.

OpenSolaris contains ZFS.

If that happens, the GPL v3 confers patent protection promises. I know Linux is unlikely to ever be re-licensed under GPL v3, but so long as linking in GPL v3 code with a GPL v2 kernel is acceptable, this will be a good outcome, as Linux won't get left behind in the storage arena.

Linux == Good, ZFS == Good. Linux + ZFS = 2*Good.

EXACTLY! Linux + ZFS would

Anonymous (not verified)
on
April 25, 2007 - 1:23pm

EXACTLY! Linux + ZFS would be a killer of Solaris. this is why Sun won't let it leak into Linux.

ZFS instead of Reiser4?

Anonymou (not verified)
on
April 20, 2007 - 9:17pm

ZFS instead of Reiser4?

Well Reiser4 already works, and works well:

You can read more here:

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm

.-------------------------.
| FILESYSTEM | TIME |DISK |
| TYPE       |(secs)|USAGE|
.-------------------------.
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
.-------------------------.
|REISER4     | 3462 | 692 |
|EXT2        | 4092 | 816 |
|JFS         | 4225 | 806 |
|EXT4        | 4408 | 816 |
|EXT3        | 4421 | 816 |
|XFS         | 4625 | 779 |
|REISER3     | 6178 | 793 |
|FAT32       |12342 | 988 |
|NTFS-3g     |10414 | 772 |
.-------------------------.

Column one measures the time taken to complete the bonnie++ benchmarking test (run with the parameters bonnie++ -n128:128k:0). The top two results use Reiser4 with compression. Since bonnie++ writes test files which are almost all zeros, compression speeds things up dramatically. That this is not the case in real world examples can be seen below where compression does not speed things up. However, more importantly, it does not slow things down either.

Column two, Disk Usage: measures the amount of disk used to store 655MB of raw data (which was 3 different copies of the Linux kernel sources).

OR LOOK AT THE FULL RESULTS:

.-------------------------------------------------.
|File         |Disk |Copy |Copy |Tar  |Unzip| Del |
|System       |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type         | (MB)| (1) | (2) |655MB|655MB| Gig |
.-------------------------------------------------.
|REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
|REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
|REISER4 tails| 673 | 148 |  63 |  78 |  33 |  65 |
|REISER4      | 692 | 148 |  55 |  67 |  25 |  56 |
|NTFS3g       | 772 |1333 |1426 | 585 | 767 | 194 |
|NTFS         | 779 | 781 | 173 |   X |   X |   X |
|REISER3      | 793 | 184 |  98 |  85 |  63 |  22 |
|XFS          | 799 | 220 | 173 | 119 |  90 | 106 |
|JFS          | 806 | 228 | 202 |  95 |  97 | 127 |
|EXT4 extents | 806 | 162 |  55 |  69 |  36 |  32 |
|EXT4 default | 816 | 174 |  70 |  74 |  42 |  50 |
|EXT3         | 816 | 182 |  74 |  73 |  43 |  51 |
|EXT2         | 816 | 201 |  82 |  73 |  39 |  67 |
|FAT32        | 988 | 253 | 158 | 118 |  81 |  95 |
.-------------------------------------------------.

Each test was preformed 5 times and the average value recorded.
Disk Usage: The amount of disk used to store the data (which was 3 different copies of the Linux kernel sources).
The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB.
Copy 655MB (1): Copy the data over a partition boundary.
Copy 655MB (2): Copy the data within a partition.
Tar Gzip 655MB: Tar and Gzip the data.
Unzip UnTar 655MB: UnGzip and UnTar the data.
Del 2.5 Gig: Delete everything just written (about 2.5 Gig).

http://lkml.org/lkml/2007/4/9/4

ZFS vs Reiser

Joshland (not verified)
on
April 25, 2007 - 11:56am

Well for one this: fsck. Rieser3 has some serious issues and there is no hope of addressing them. Reiser4 is bgged down in seriously bad personal issues, and then a small matter of criminal charges didn't help. ZFS is pushed by a corporation that has the ability to do things with the FS that Namesys just doesn't.

Also, hands-down ZFS is much more interesting than Reiser4.

You speak total crap.

Anonymous (not verified)
on
April 30, 2007 - 9:07pm

You speak total crap.

"Rieser3 has some serious issues and there is no hope of addressing them."

Maybe you want to back up these claims with statistics and then tell us why YOU think the Linux kernel developers are so stupid that they cannot fix the problem.

"... under the GPL-incompatible CDDL,"

Anonymous+ (not verified)
on
April 21, 2007 - 10:13am

Argument positions sometimes matter. I hope you know, that it is actually the GPL that is CDDL-incompatible - not the other way round. (Btw, the GPL only prevents redistribution. I as a user could still inject ANY code into MY kernel.)

And software patents are an U.S. internal problem. No need to make everyone else suffer.

*sigh* Come off it.

on
April 21, 2007 - 10:55am

Incompatiblity is a property of a pair of things considered together. GPL and CDDL are incompatible. CDDL and GPL are incompatible. It does NOT matter what order you say it in as the two statements are equivalent. X != Y is equivalent to Y != X.

Now, if you're saying the GPL was purposefully written to be specifically incompatible with the CDDL, then, well, RMS must be a modern day Nostradamus to have predicted the CDDL specifically when he wrote the GPL back in the early 90s. Otherwise, your distinction makes no sense.

I can think of tons of other licenses that aren't CDDL compatible. The Windows EULA doesn't let me put Windows code into Solaris, for instance, even in binary form. No NTFS.DLL for you, Solaris users!

RMS doesn't have to be

trasz (not verified)
on
April 23, 2007 - 12:22pm

RMS doesn't have to be Nostradamus - he didn't make GPL incompatible with just CDDL, he made GPL incompatible with _everything_ that is not subset of GPL.

As for EULA and CDDL - sure they are compatible. Microsoft can include ZFS in the Windows if they want; CDDL doesn't prohibit it. Linux, on the other hand, cannot - it's the GPL that prevents from linking with CDDL, not CDDL itself.

Dense Matter

Joshland (not verified)
on
April 25, 2007 - 12:11pm

trasz - you're kinda dense. If you hate the GPL, then everything about it sucks and everyone else is idiotic for using it. It's lame to try and present some sort of "compelling argument". You're just being combative at this point. You can STFU, we all and see that you dislike the license. You're not arguing about the merits.

You are taking the obvious point: GPL was written with a purpose - which the CDDL specifically is not compatible with. Furthermore, most licenses are incompatible with the /purpose/ and /intent/. Similarly the US Constitution is not compatible with many other countries similar documents.

While you may not legally take any files from a Windows Distribution and include them in anything else, ZFS could be legally ported to Windows. Due to CDDL it currently can't easily be done with Linux. AFAICT for Microsoft to distribute ZFS, it would need to work out licensing with Sun.

However, a third-party could integrate ZFS into Windows, and distribute it online w/ impunity.

Could Sun and Linux come to terms? D'uh. Would that mean a specific license for a specific use, or some specific rendition, etc, etc? Yeah, so?

The fundamental difference is the rights of the developer vs. the rights of the end-user. GPL is the only license I have seen that puts such high concern on the rights of the end user. Every other license is about the rights of the group developing it. That is the basic irreconcilable difference.

Not technical.

Anonymous-like (not verified)
on
April 21, 2007 - 3:40pm

This is not a tech comment. Sorry if this is the wrong forum and feel free to remove it.

Well, companies do strategic moves and, sometimes, they use whatever legal resources they have at hand for a better outcome -- for their shareholders!

That said, M$ has a lot of dough and is not very brilliant (see Vista); it has an (admitted) tradition of buying tech. A sound strategy would be to make things which are appetizers for product or company acquisition (you always have to look handsome... always).

What if it can also be used to explode Linux from the inside?

Very much looking like a trojan horse to me...

ignorance

Anonymous (not verified)
on
April 23, 2007 - 10:57am

I am sorry for sounding so ignorant, however can anyone point me to a document that shows just how much better ZFS is as a filesystem (besides addressing "ridiculously" large block devs) than linux with XFS, JFS or riser4 with LVM+Xen.

Again, i am not sure what i am missing out on by not having ZFS but just by what i have heard, i cannot see what is so great that i cannot get from Linux "now" (considering that i will not have need for a zettabyte sized partition).

TIA,

ANON

There was lots of info on

trasz (not verified)
on
April 23, 2007 - 12:29pm

There was lots of info on that in some blog of Sun's employee, but for me, two most important things are:

1. Durability. Disk hardware in most PCs - disks, cabling and controllers - is crap, and even in high end servers hardware (and firmware) problems do happen. ZFS checksums everything, so you will notice _any_ data corruption immediately. And, because of ditto blocks, even if you overwrite 1GB of your partition, the filesystem will still be usable. Sure, you will lose overwritten data, but the rest of the FS will be usable.

2. Space is allocated dynamically. With LVM your filesystems are still fixed in size; sure, you can grow them; but you need to do that manually. With ZFS, you don't have to - if you don't set any space reservations or something, then filesystems are 'grown' and shrunk as needed.

GPLv2 .vs CDDL .vs GPLv3

Jim Thompson (not verified)
on
April 23, 2007 - 8:05pm

I actually spoke to RMS about this. He asserts that the CDDL *is* a *free software license*, and acknowledges that the CDDL is not compatible with the GPLv2.

The FSF is attempting to make sure that GPLv3 is compatible with other Free Software licenses.

As others have noted, it is likely that Sun will dual-license its software (excluding Java, which is GPLv2) under a dual license, both CDDL and GPLv3.

If this happens, there will be even more pressure on the linux developers to figure a path toward moving the linux kernel to GPLv3, dead developers be damned. Its not only ZFS, but things like dtrace that are about to kick linux in the shins, hard. (dtrace is also available on FreeBSD, and dtrace is even more useful than ZFS.

Linus/linux was once about "let the best technology win", but perhaps that is changing.

I think Sun is about to hoist the "linux community" up by its on petard, even without the patents, and that it will be funny to watch the FUD show generated by the linux people. If Open Solaris goes GPLv3, then the real Free Operating System will be owned by Sun.

Also, remember that a patent is a "negative right"... Sun can (and quite likely would) simply choose to ignore any infringement in Linux, but prevent, say, Microsoft, from ever using something that infringes on their patents, even in the unlikely event that Microsoft shipped linux as part of a product.

let's wait until OpenSolaris

Anonymous (not verified)
on
April 25, 2007 - 1:18pm

let's wait until OpenSolaris and ZFS are GPL'ed. promises and talks are cheap.
it's also known that most Sun's customers want Linux. at same time they want ZFS.
so, ZFS is probably the last chance for Sun to save Solaris. I don't think they
licence ZFS under GPL anytime soon.

ZFS already ported to other OSen

Anonymous (not verified)
on
April 24, 2007 - 12:10pm

It's in FreeBSD. It's in MacOSX 10.5.

Someone mentioned fsck time being a limit on filesystem size. ZFS has no fsck. By design. It's the only file system that has error correction. If your controller or a bad cable is introducing errors, ZFS will detect it. Every other FS will blissfully write corrupt data.

LVM snapshots? They're not even close. ZFS snapshots are more akin to NetApp's.

ZFS has a RAID5 like setup that doesn't have the write penalty RAID5 does.
ZFS has compression built in that can be activated/deactivated.

One major thing I'd like to see in ZFS is the ability to change the number of devices in a RAID. You can increase their size, but not the number. NetApp lets you add devices as needed.

yeah. someone forgot to

Anonymous (not verified)
on
April 25, 2007 - 1:15pm

yeah. someone forgot to mention that fsck is also required to correct errors introduced by filesystem itself. ah, zfs has no bugs by design!

someone forgot to mention that when you overwrite 4KB in large file, he'd need to read 128K and write them in some new place. such a performance improvement!

someone forgot it has no direct I/O, thus it can't sustain high-end IO rates.

someone forgot ZFS doesn't support per-uid and per-gid quota.

>someone forgot to mention

Anonymous (not verified)
on
April 26, 2007 - 6:48pm

>someone forgot to mention that when you overwrite 4KB in large file, he'd need to read 128K and write them in some new place. such a performance improvement!
While linux just reads 64K for that? How inefficient the ZFS is!

are you idiot? regular linux

Anonymous (not verified)
on
April 27, 2007 - 3:42am

are you idiot? regular linux fs like ext3 reads nothing in this case.

only you forgot

Anonymous (not verified)
on
May 6, 2007 - 5:10pm

Everything has bugs, no self-respecting engineer claims otherwise. This includes every engineer I've ever met at Sun.

If you want to be overwriting 4k chunks in large files, set the ZFS recordsize to 4k. That's what it is there for.

ZFS has shown to achieve platter-speeds in a large variety of I/O applications without direct I/O. But, there is no silver bullet. ZFS isn't designed to be the fastest file system on the planet. It does respectably hold its own.

Quotas work differently. If you need those, use a different OS or adapt your usage scenario to embrace what ZFS is good at.

And I didn't realize someone forgot all these things. I think you forgot that it is possible to make a point without being an ass.

> Everything has bugs, no

Anonymous (not verified)
on
May 7, 2007 - 9:46am

> Everything has bugs, no self-respecting engineer claims otherwise. This includes every engineer I've ever met at Sun.

yeah, of course, this is why they've written fsck for it, yes?

> If you want to be overwriting 4k chunks in large files, set the ZFS recordsize to 4k. That's what it is there for.

excellent. now calculate metadata overhead for 4k recordsize and 1TB file.

> ZFS has shown to achieve platter-speeds in a large variety of I/O applications without direct I/O.

take Sun thumper with 48 SATA disks, try to achieve 1GB/s.

>Quotas work differently.

yeah, "think differently: quota for poors who can't buy enough disks"

> And I didn't realize someone forgot all these things. I think you forgot that it is possible to make a point without being an ass.

just a reaction to all bullshit we hear about ZFS.

fsck is a tool to correct

on
June 2, 2007 - 3:21am

fsck is a tool to correct errors in the filesystem. If the filesystem can fix those errors all by itself, what would be the purpose of separate fsck? Try to think about this as an fsck integrated into the filesystem.

As for recordsize - remember that it's _much_ faster to read 128KB than read 4KB two times: with the former you have one seek, in the latter - two. And with most workloads you don't really read 4KB once.

As for Direct IO - IIRC Linus wants it removed from the Linux kernel, so be sure to explain this to him.

And functionality for restricting disk space usage is there, you just need to think about it in a little different way than usual.

patents

David Magda (not verified)
on
April 30, 2007 - 7:55am

All the patent arguments that are used as a 'con' for incorporation are inaccurate. The CDDL explicitly gives a patent license:

What does the CDDL say about patents?

The CDDL provides an explicit patent license for code released under the
license. This means that you can use, modify, and redistribute code released under CDDL without worrying about any patents that the contributors of the code (including Sun) might have on the contributed technology. The license also includes a provision to discourage patent litigation against developers by revoking the rights to the code for anyone initiating a patent claim against a developer regarding code they have contributed.

http://www.opensolaris.org/os/about/faq/licensing_faq/#patents

If NVidia can link in a driver that is non-GPL, I don't see why ZFS can't be linked in via some kind of shim as well.

Large chunks of ZFS released under GPLv2?

Anonymous (not verified)
on
May 8, 2007 - 3:29pm

Check out this post by Sun employee Darren Moffat :: http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists check out the source files at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/grub/grub-... to be precise all files which match *zfs*. It seems a large chunk of ZFS is now licensed under GPLv2.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.