OSNews

Some of the great things about Solaris are ZFS, LiveUpgrade, dtrace, zones, SMF and SVM... in my view.

have zfs's stbility problems been fixed yet?

Long fixed.

ZFS has stability problems? I didnt knew that, and I have used ZFS since the very first beginning.

You are just Trolling, right?

Or you have been lucky not to encounter an issue yet.

Bah, until ZFS is made available by Oracle in a GPL-compatible license, I consider the port to be a waste of time: as long as ZFS isn't integrated into the kernel it won't have proper testing and it won't have enough users..
A good example of this is ReiserFS4: not being accepted in the main kernel did reduce its adoption.

... Presumably alongside these 'details' concerning ReiserFS author Hans Reiser's where abouts on Sept. 3, 2006:

http://www.wired.com/threatlevel/2008/08/its-the-least-p/

The ReiserFS 4 fiasko was mostly due to the whole design behind it being a big, unimplementable mess. Sure, for toy cases it did work; but for corner cases it just couldn't.

I wonder what corner cases you are thinking of? I used Reiser4 as the primary filesystem for my laptop for over two years and it did everything I needed.

Good idea, but impossible. This was suggested when GPL3 came out. Everyone who ever contributed to the linux kernel would have to give their consent to change the license.

The SunOS is not going to have a last version in OpenSolaris. It will definetly continue in Solaris. Oracle has no reasons to kill SunOS, even then if they want to stop OpenSolaris.

And Linux OS can not be relicensed, even if wanted. It is on GLPv2 and stays as such because there is just too many copyright owners for it to get them all accept the licesen change. That is one great thing what is keeping Linux not having GPLv3 even if Linus would wanted the OS have it. GNU need to have their own OS, the HURD to be the only GPLv3 licensed OS if wanted.

Think about it if Linux has over 50 000 copyright owners code in it. To change Linux OS license from GPLv2 to GPLv2 or later / GPLv3 (or later), it would need so massive job to get all 50 000 copyright owners to accept that change. And if there is very critical code what is only accepted to be in GPLv2, the code should be rewritten from scratch without using the old code at all, even as example.

Linux OS stays under GPLv2 and only way to get ZFS as native filesystem to it is to get it as module or use FUSE. The module is not problem because GPLv2 allows Linux OS being expanded with binary only modules. That is something what GPLv3 would not allow. And because Linux is modular, even it is a monolithic operating system, it is possible to do. Just like 3rd parties are doing it, like Nvidia.

i guess it similar to the case with binary drivers.

Well, binary drivers are a bit of a grey area anyway:

http://en.wikipedia.org/wiki/Linux_kernel#Loadable_kernel_modules_a...

Yes, and so have they:

http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists

Erm, can you clarify: You think both myself and the guys developing the port are missing the point because of the link you've supplied?

If that's what you're suggesting, then you've missed the point more than all 3 of us.
That link is the FUSE port which everyone has already acknowledged exists. However FUSE isn't native (as already mentioned in the article) and has it's own set of problems (performance being the biggest).

No, that link is the GRUB support for ZFS, which will yield read-only support for ZFS and is GPLv2. Surely, code can be taken from there to implement mainline- kernel ZFS which is free from license brouhaha.

Ahh yes sorry.
I don't know how the hell I missed that lol.


Interesting though. I'd forgotten that GRUB was GPL.

Only if you redistribute it. The GPL only put restrictions on distribution, not usage. If you add the ZFS module to your own system it's ok but then you may not, for example, distribute a HDD image of that system.

I see.

Thanks for the clarification

Yes. you miss the point. It is not allowed to distribute a Kernel that has ZFS build into it. The reason is that you can not mix CDDL and GPL code. But an end user can patch her/his Kernel with the ZFS code and compile a Kernel and use that Kernel without breaking the license.

So only the distribution of a build Kernel is not allowed but running a patched Kernel is no violation of the licensing terms.

> Correct me if I'm wrong, but isn't this still breaking the licensing terms?

No.

> I mean, is there not still CDDL code in a GPL kernel?

Yes.

And CDDL is incompatible with the GPL.

The reason it's legal is because GPL is a copyright license. Copyright is limited in scope, by constitutional law, to 'derivative works'.

"Derivative works" is a term encoded into copyright law that limits the rights of copyright owners to only items they created and items created from what they created.

That is if I write a poem and you write a poem my copyrights on my poem does not affect the copyrights on your poem.

'DUH', right?

That is what is happening here.

The code for the Linux ZFS driver is derived from Oracle's copyrighted code. The only legal grounds for using that code is under the CDDL license. So thus it's governed by the CDDL because it's derived work from the Solaris kernel.

But the process of modifying it for compatibility to the Linux kernel does NOT mean that the it's now derived from the Linux kernel. If there is no code from Linux in the Linux ZFS driver then the source code is legally distributable under the CDDL license and thus is not affected by the GPL license.

So it's legal to distribute in SOURCE CODE FORM. Its still pure CDDL licensed/derived.

Once you compile it into a kernel module, however, then the driver 'sucks in' Linux kernel code as part of the compilation process.

Thus, in binary format, because it incorporates both Linux and Solaris code then the actual finished driver will be derived from both CDDL'd and from GPL'd code.

Since they are incompatible there is no legal standing for you to redistribute it. Since they null each other out then there is no legal standing for your use of it. Hence it would be a violateion of copyright law for you to redistributed the finished binary driver.



The reason it's legal for you to USE the combined Linux/Solaris code and NOT be able to distribute it... is because the GPL only kicks in during distribution.

The GPL intentionally limits itself to situations were your distributing the code (in binary or source code format) to third parties.

As long as your only using it yourself then the GPL has ZERO affect over your usage. It's actually freer then the BSD license in this respect. You can treat it like it's public domain and combine it with whatever code you want. There is ZERO restrictions on GPL usage.

GPL ONLY AFFECTS DISTRIBUTION. Not usage.


TLDR:

* The driver is being distributed in source code format.

* The source code format does not include any GPL'd software or Linux derived software. It's only designed to be compatible with the Linux kernel.

* So the GPL does not restrict it because it does not affect it.

* GPL only affects distribution, not usage. There are ZERO restrictions at all on usage.

* Downloading the source code and compiling it with the Linux kernel makes it legally usable, but illegally distributable.

By the time they get a solid working module for the Linux kernel of ZFS (the FreeBSD-hackers took years to get it right), I'm pretty sure btrfs will already have matured quiet nicely. But with Linux betting on several horses isn't unusual.

Say "enterprise" ONE MORE TIME! I dare you!

"Enterprise" refers to software developed on a schedule with managers dictating the necessary set of features, and then engineers adapting to that. Functionality that there is no time to redesign will remain forever as kludges.

btrfs will succeed exactly because it isn't "enterprise". The software is evolved naturally, with no deadlines and no managers to dictate a set of features. Functionality that is consistent and sound from an engineering perspective gets implemented. Functionality that isn't, will be sent back to the drawing board until it is, or never implemented at all.

And yes, many btrfs developers have a long experience working with file systems.

tl;dr: btrfs is ZFS done right. btrfs is to ZFS as Linux is to Solaris.

My god, your post is so funny (and wrong in every sentence) I can't even think of what to respond. You know about Solaris because you read about it once in a Linux magazine, right?

Enter... Enterpr... Hm. No, I dont dare to say the Enterprise word again, because then you might get angry. And I dont want to make you angry for saying Enterprise.



Just like the horrible broken mess that Linux sound API is? If that is the case, then BTRFS will never succeed.



Yes, but not Enterprise experience. Oops, now I used that word again. Sorry for that.

Look. Let me explain some things to you, my young padawan learner. As someone explained: "A filesystem is far more sensitive than a kernel. If the kernel crashes, you will loose a couple of hours of work. If the filesystem crashes you loose several years of work. The filesystem is the nervous system, the skeleton of the OS. If that is bad, the rest sucks"



To get the filesystem bug free is very important. Everyone (including the Linux kernel hackers) agrees that Linux kernel is full of bugs and a mess. This approach can work on a kernel. But for a file system, it will not work. Then it has to be good coded and well designed. Which ext3, JFS, reiserfs, etc are not. You want proof?



This bad design shows up in Linux filesystem's abilities to detect and correct errors: they all suck badly. They can not even detect nor correct basic errors. Whereas ZFS detects and corrects everything. To do this well, takes lots of experience from Enterprise file systems. Those BTRFS amateur filesystem developers, know nothing about this problem "silent corruption". It is only faced in large Enterprise storage halls, just like Sun have vast experience from.

You can not just add some checksums here and there, and expect everything to be well. No, the filesystem must be built from the ground up, with respect to detect and correct all errors. This is EXTREMELY difficult to do well. If not careful, there are always errors you can not detect, if you just use a naive approach. For instance, raid-5, raid-6, ext3, jfs, reiserfs, etc - can not handle all kind of errors. Computer scientists have done research on this and proved it. They also tried to stress ZFS too, but ZFS detected every artificial error, and could have repaired all errors if the scientists had used raid. In the experiment, they ran ZFS on a single disc, so ZFS could not correct every error, but it detected them. Linux didnt even detect the errors, how can Linux then correct them? Impossible. You want proof and research papers on this?

Let me say this again. BTRFS is a cheap ZFS wannabe. It is not designed as well as ZFS. It has no focus on data integrity and silent corruption. It has nothing, just basic ZFS functionality. With Linux unstructured approach, BTRFS will not be stable. As usual, the code will be rewritten all the time, introducing new bugs. BTRFS will never catch up on ZFS. Do you really expect ZFS to stand still, and paus development? No. Instead of copying ZFS, why dont Linux guys try to make a new cool tech, instead of copying Solaris all the time? DTrace copies exist, but they are as bad as BTRFS is to ZFS. Every OS wants Solaris tech like DTrace, ZFS, etc.



If that is the case, then there are no worries. Because then BTRFS will be buggy and bloated and scale bad. Good to hear.

I wasn't saying it would catch-up, I was saying a stable filesystem, something people can rely on in a production environment as much as ext3 of ext4, but with more checksums.

Maybe not in as many places as ZFS yet, but it will be something which can be maintained by the same people that build the rest of kernel. And it can be distributed normally together with the rest of the kernel.

I really hope you are joking. Because you are a troll of the greatest order.

I really don't think that your post has a single fact in it. And you're also forgetting that Btrfs is from Oracle, who have plenty of experience in so called "enterprise storage".

yeah, those 'amateurs' over at f***ing ORACLE don't know how to make a filesystem.

Do your research before making a post like that.

Are you actually going to elaborate on that point or just leave it there in what some might view as a tolling argument?

Aside for better Linux support - I've not seen anything in BtrFS that's swayed my to switch from ZFS.

But I'm completely open to reason, so please explain away

Are you actually going to elaborate on that point or just leave it there in what some might view as a tolling argument?

Aside for better Linux support - I've not seen anything in BtrFS that's swayed my to switch from ZFS.

But I'm completely open to reason, so please explain away "

I do agree with the first poster, and these are my points: ZFS and BTRFS are very similar feature wise, but BTRFS is achieving a lot of attention and support from the Linux community (and some first appearence on the "enterprise" side with RHEL 6 as an "experimental" feature).

So, I'll guess that BTRFS will be accepted as a solid and reliable solution soon, while ZFS will be a lot behind.

So, who will need ZFS when it doesn't provide anything different from BTRFS and not being at the same production-level quality?

(note that this is a question, not a statement! if someone has good reasons to say that ZFS is better, than I'm open to hear it!)

Unfortunately your argument basically consists of "ZFS wont run on Linux therefore it will fall into insignificance".

Well I'm sorry but there is a whole world of OSs outside of Linux and I happen to consider Solaris and FreeBSD to be very relevant platforms.

So please, give me a real reason why people should choose BtrFS over ZFS (particularly given ZFS is still a few years ahead of BtrFS in terms of testing and development).

Erm, actually it is. ZFS has been "production-level quality" for a few years now.
Sure, new features are frequently making their way into development builds. But let's not confuse them with the excellent stable releases of ZFS.

Edited 2010-06-07 13:37 UTC

A real reaseon is indeed the same as not using NTFS - it doesn't really work well with my platform of choice, while btrfs is definitely getting there. There will never really be a choice between the two. In the end it's btrfs vs. ext4 vs ext3, really.

Who cares about your platform of choice?

How about giving it a little thought before replying about your platform of choice to "give me a real reason why people should choose BtrFS over ZFS"?

If the platform one is working with does not provide ZFS support then it's not really much of a choice for them regardless of what OS platform it is. But, maybe I read the example in more generic terms than was intended.

...



Er... I do?

Seriously speaking - I'm not a native English speaker, so I assumed that in the formulation above, "me" could be understood in a more abstract/passive sense than standing for myself (in a concrete fashion). I know I should have used "one's" instead of "my".

A real reaseon is indeed the same as not using NTFS - it doesn't really work well with my platform of choice, while btrfs is definitely getting there. There will never really be a choice between the two. In the end it's btrfs vs. ext4 vs ext3, really. "
You've still not answered my question and furthermore, NTFS is used extensively because of Windows - so that's a terrible example.

I couldn't give a toss about your personal platform of choice. You made a statement that ZFS was going to die and I want you to provide evidence to back up your opinion. Thus far all you've done is spout yet more personal opinion.

Yes, you're right and I do agree with you! What I really meant was that the Linux/ZFS integration will need time to get stable, not that ZFS itself does.

With reference to the fact that there are a world of other OS out there beside Linux, you're right again, but the topic was about Linux now, so talking about the relevance of ZFS is implicitly referred to the Linux world.

I'm a great estimator of ZFS and not particular fan of BTRFS, but it seems that, being myself a Linux user, the latter will be my future.

Edited 2010-06-07 20:16 UTC

Other than supporting in-filesystem snapshots, RAID-0, and RAID-1, they have very, very, very little in common. And BtrFS is missing over half of the features that ZFS supports. And BtrFS is still marked as "experimental, will eat your unicorns, don't use with live data". Hardly enterprise-ready.



Attention, maybe. Support, hardly. Right now, it's "just another of a thousand filesystems" that are semi-supported by the Linux kernel. No distro ships with it enabled by default. No distro recommends using it. No companies have sprung up with products that use it internally. It's barely off the drawing board.



Only if you mark "soon" as "at least 5 years from now". The way things are going, Linux 2.8 will be released by the time BtrFS is ready for use in places where ZFS is currently used.



Gee, I don't know, maybe people that want to manage multi-TB datasets today instead of waiting for "soon" to roll around.

The fact that zfs has no sane Linux support (and possibly never will have) makes it like betamax - it's probably reasonably good technology, but it's not something you have access to in the first place, unless you switch to Solaris. And, I don't think that's the way the tide of the world is turning these days.

Solaris or BSD you mean.
People in this thread are missing the significance though. This could be a useful bridge technology for shops that need their linux based systems to access Solaris/BSD ZFS partitions with decent performance (assuming the kernel driver is better than the FUSE solution).

btrfs doesn't support pooled storage.
btrfs doesn't support RAID levels above 1 (RAID10 is not higher than 1).
btrfs doesn't do end-to-end checksumming and self-healing.
btrfs doesn't do encryption (still an experimental feature in ZFS, but it's being worked on).
btrfs doesn't do deduplication.

Those are just some things I can think of off the top of my head. There's bound to be a lot more, considering the relative immaturity of the btrfs codebase compared to the ZFS codebase.

IOW, btrfs is where ZFS was 10 years ago. Explain to me again how btrfs is so much better, and will rule the storage world?

One of the ZFS features I think is coolest is L2ARC which let you put a fast SSD as a read/write-cache in front of a pool of slower mechanical disks. The blocks you use most frequently will have a copy on the SSD for quick access. IIRC the cache currently doesn't survive a reboot though (it will start caching from scratch again), but they are working on fixing that.

Yes, cache vdevs are very handy. And they are absolutely essential for dedupe to work correctly/quickly.

Even a lowly USB flash stick can be used as a cache vdev ... so long as the read speed of the USB stack/driver/port/disk is faster than the read speed of the harddrive.

I use 4 GB USB sticks at home to speed up my pokey 120 GB SATA (non-NCQ, 1.5 GB/s) drives.

There's even support for using SSDs for write caching (log vdevs), although it's a lot harder to find SSDs that are optimised for writes (SLC-based) that include onboard power (supercap, for example) and that honour cache flush/sync requests.

Duh, btrfs has pool storage, patches to support other raid levels and end-to-end checksumming. Self-healing, deduplication and encryption will be added later once other basic features (shich as direct-IO) are added and stabilized.

RAID 5/6 support has not been checked in yet, nor has it really been made available for testing beyond the two devs working on it. Thus, it doesn't support RAID levels above 1 yet.

Nor does it really support pooled storage, as you still have to specify the harddrives that will be used for each filesystem when you create the filesystem. There's no pool management yet, just filesystem management.

So, like I said, btrfs is where zfs was 10 years ago. It's not a replacement for zfs in any way at this time.

Maybe in 5 years, it'll be where zfs is now. But it's not there yet.

Duh (again). Btrfs does pool storage from day 1. Just because the command line tool doesn't autodetect where the pool storage is it doesn't mean it isn't there.

By the way, ZFS didn't exist 10 years ago. And Btrfs is 3 years old and it is powering my Fedora 12 install since November without oopses, data corruption or problems of any other kind. It sure isn't ready for enterprise adoption, but it's certainly stable enought to be adopted by geeks, and it already has some nice features that ZFS doesn't. So I don't think I'll have to wait that much to see it used in enterprise distros (did i mention that RHEL 6 will offer it as an experimental option?)

Hrm, so how does one take 6 harddrives, configure them as a storage pool, and then create 6 filesystems on top? From what I've read about btrfs, this isn't possible as two separate operations. Everytime you create a filesystem, you tell it which disks to use, and what RAID level to use.



Hrm, yeah, got my dates wrong, off by 1 year. ZFS originated in October 2001 (http://blogs.sun.com/bonwick/entry/zfs_the_last_word_in) and was integrated into Solaris 10 in October 2005.



While it's made a lot of progress in those three years, it's still far from being a ZFS replacement. Which is the point. Everyone is claiming that BtrFS (right now) is a drop-in replacement for ZFS (right now), and that there's no point in porting ZFS (or any other FS) for that reason. Doesn't matter that (right now) BtrFS is not a drop-in replacement, since it will be in a few years.

Convincing people to stop work on a competing product, because your incomplete product will blow it away when it's finished, but that could take a few more years, is the definition of what term in computing???

Everytime you create a filesystem, you tell it which disks to use, and what RAID level to use.

Everytime you want to create a fs you use "btrfs subvolume create <parameters>" and btrfs will create the fs from the pool.

and that there's no point in porting ZFS (or any other FS) for that reason.

There is no point in porting ZFS because, among other things, ZFS is not just a FS, but a complete IO stack, and I doubt very much the linux developers will accept a filesystem that does not use the Linux block layer.

There's nothing that stop it from using the Linux block layer. ZFS just needs access to a block device, whether it be via iSCSI, AoE, local, or a pseudo-block device via a file.

The FreeBSD port still uses the GEOM storage framework. And it's because of GEOM that you can add a lot of nifty features to ZFS (HAST, encryption, labelling, etc).

Linux doesn't have as nice of a storage stack as FreeBSD's GEOM, though, so it might be more difficult to port to. But ZFS just needs access to block devices, and then it manages those block devices for you.

BTRFS has end-to-end checksumming? I doubt it is well designed unless I see proof. BTRFS developers only recently understood that data integrity is important and decided to add that as an afterthought. What a fail. You need to design the whole file system from the ground up. For instance, reiserfs, JFS, XFS, etc nor raid-5 nor raid-6 does not give a good protection.

As I said, you need lots of experience from Enterprise storage to know how to tackle problems that arise from large scale storage.

Linux does not suffice for large scale storage. It sucks badly on Enterprise storage according to an storage expert:
http://www.enterprisestorageforum.com/sans/features/article.php/374...

http://www.enterprisestorageforum.com/sans/features/article.php/374...



BTW, ZFS was announced 2004. But it was prototyped and worked on, several years earlier. It is highly possible ZFS has existed 10 years today.

Boo. It was there from first day. You haven't documented yourself about the most basic design ideas of Btrfs, yet you want to preach that it sucks.

About the articles: Yes, Ext* suck for big storage, that's not news. That's why SGI uses XFS in their boxes.

Boo. Ive read an article where BTRFS developers only realised that data integrity is important after Sun talked a lot about it. I have googled but can not find that article again. I will post it here when I find it.


About Ext* sucks and XFS is the way to go. If you read the article that you talk about, you will see that the problems in not in the filesystem. The problems is within the Linux kernel. Even if Linux used ZFS, it would not suffice as large enterprise storage servers. Read the articles.


About XFS, well, it does not protect data sufficiently well. Researchers shows that it and ReiserFS, JFS, etc can not handle data corruption well. Your data is unsafe. Hardly suitable for Enterprise storage, heh?
http://www.zdnet.com/blog/storage/how-microsoft-puts-your-data-at-r...

Actually NTFS run's via FUSE too (just like ZFS already does).

At least NTFS-3G does. But if you know of a native NTFS driver that supports writes and runs inside the Linux kernel, then please tell me.

NTFS-3G is a GPL reimplementation of NTFS. it does not use microsofts GPL-incompatible code.

That maybe the case, but it is still a FUSE FS driver:
http://www.tuxera.com/community/ntfs-3g-faq/#useroption3

True, NTFS-3G uses FUSE, but only so it can run unmodified on a multitude of systems. It doesn't, however, use any proprietary Windows DLLs, like ZFS on FUSE uses proprietary Sun code.

Recently, december 2009, the court judged that NetApp has no claims to ZFS. Sun won that case. There is a web page on Sun that details every twist and turn. That case is closed.

NetApp sued Sun in another county, despite that both NetApp and Sun have the head quarters just a few miles a part. NetApp sued Sun in a county used by Patent Trolls. NetApp are nothing more than patent trolls. They are scared shit less about ZFS, which competes with their extremely expensive proprietary WAFL servers. ZFS can offer all that, for free. NetApp are soon doomed.

maybe someday Linux will switch to a more free license.

I'm not sure that you and I will agree on the definition of "free license".

So, no, will not happen.

- Gilboa

Great observation, Kittynipples. I had exactly the same reaction. Fix your own damn license. Obviously it's not giving problems to truly free licenses, so the problem is with you, GPL.

If you want to play with Apple, you'll have to do it there way.

If you want to play with Microsoft, you'll have to do it there way.

If you want to play with GPL, you'll have to do it there way.

If you hang out at your friend's house, you'll have to abide by there rules.

There isn't anything stopping Sun from dual-licensing, adjusting the single license or re-licensing. They could always stamp it with the BSD license (as an example from recent news).

In the end though; it's there ball and if they want to take it and go home, the rest of the kids at the soccer field don't really have a say in that.

It seems they arent to interrested in playing with the gpl?



Sun arent the one going home. It's the gpl kid. Blaming sun for not being willing to offer everything so it can be put into the linux kernel.

Why should Oracle/sun change the licens just because a the gpl camp wants them to do so?

Because Lawrence Livermore National Laboratory asks them to? Funny thing is if it were the other way around the gpl people would tell them to write their own code...

"Why should Oracle/sun change the licens just because a the gpl camp wants them to do so? "

That was my point. Sun/Oracle has chosen how the item is licensed. It can't be included into the kernel because the license conflicts. If they where interested in getting it into the kernel, they could choose to change the license. Since it's there "ball", they have the right to license it as they like even if that stops some other kids from being able to join in the game.

I see how the comment could be read in the reverse though as many seem to have done given the first few responses.

Linux arent the only kid and surely not all that important outside the linux camp so why would anyone use the gpl just to please the linux camp?



I might have read to much ínto your post.

This isn't about Oracle wanting to "play with GPL," this is about some Linux developers wanting Oracle to change its licensing terms to accommodate them. If it was the other way around, you could be sure that Oracle would be told to pound sand.

And if you want to play with Sun, you'll have to do it their way, too.

exactly. Oracle/Sun chose a license and it is either compatible or not but it's there choice.

My guess is that if Oracle decided to play nice and dual license it, the GPL kids would repay the favor by only contributing their patches to the GPL version. Showing their true appreciation.

It's not Snoracle's fault that Linux uses an incompatible license.

Considering Oracle are developing BTRFS, and seemingly did so as a competitor to ZFS which they also now own... It would make a lot of sense for them to re-release ZFS under GPLv2 or BSD and merge the feature sets in the two filesystems.

Yes, I've been wondering myself how that one will go - ZFS was Sun's baby, but what's Oracle's view on it?

I didn't know both filesystems where (now) from the same owner. I'd actually suggest BSD though if they where looking to expand ZFS adoption. Hopefully the MBAs don't get a hold of it and lock it up as part of Solaris or a future Oracle enterprise product.

I don't usually play grammar nazi but since you made the same error five times in the same post I just can't stay silent.

Their way, their rules, their ball. ("There isn't" is correct though)

Because they are ideologues.

It isn't quite that simple...

Do you not understand that it is a practical *impossibility* to change the license for the linux kernel?

Once you get your head around that, there is only one option when it comes to getting anything inside the kernel - it must be compatible with the kernel license.

Linus already commented a long time ago on this with respect to changing the kernel license to GPLv3, and those same arguments would only be that much stronger with respect to any other license.

I'm not saying this means that anyone else *should* change their license, I'm just saying that arguing that the license for the linux kernel could be changed is just plain ignorant.

CDDL is equally incompatible with both GPL versions.

Incompatibility is because GPL and CDDL are both copyleft licenses and neither permit re-licensing code to any other license; CDDL code is availabe under CDDL only and GPL code is available under GPL only. GPL's copyleft is wider and stronger, it requires all derivatives and extensions of GPL'd code to be under GPL-compatible license as well, while CDDL apply only to specific source files and allows proprietary extensions (or open source, as long it is not GPL). There are lot other differences, but this is biggest.

So, ZFS becomes part of kernel when is merged, and whole kernel is GPL. Since CDDL does not alow re-licensing to GPL, it can't be merged.


All this is not by mistake. Sun have chosen GPL incompatible license for OpenSolaris and ZFS on purpose. Danese Cooper is the one who actually wrote CDDL, and she said on Debian conference in 2006 that special requirement for was that license must be GPL-incompatible. Here is the link http://caesar.acc.umu.se/pub/debian-meetings/2006/debconf6/theora-s...

PS: Watch at 11:30 and later.

So whole crack-pot idea of changing Linux to CDDL is crazy. Day when Linux switches to CDDL would be the day when ZFS switch to something else and Linux would be stuck with oldish version.

Not like that is going to happen, Solaris is going proprietary anyway.

Edited 2010-06-08 08:56 UTC

Thanks for the explanation.

What makes you think this? What would it even mean to "go proprietary"? Scrapping the CDDL? Really? To me it seems like the open-source nature of Solaris is the only thing keeping it vibrant. HP/UX and AIX may still have plenty of customers, but the question is, what percentage are just legacy? With Solaris I actually see some potential for growth, precisely because it is open-source.

They can't scrap CDDL'd code, but they probably wont opensource parts which are closed now, like SCC, Xsun, fishworks and such.

OpenSolaris is not selfhosting, you can't compile it without some proprietary libraries and there is some of "valued add" (or better say: Freedom subtract) parts, like mentioned fishworks.

Sun had plans to opensource that, and they also had plans to fix CDDL and remove choice of law clause in v2, making it acceptable license (look video for details). Oracle probably wont bother.

There is also problem with developer community... or lack there of. How many of OpenSolaris fans do serious kernel development? All kernel developers are at Oracle. If Larry moves them to proprietary Solaris version, OpenSolaris is toast. There is nobody to pick up development. 2009.6 will stay available, but how long will people use that? Oracle already discontinued paid support for OpenSolaris, there is now only proprietary Solaris 10 on their agenda. Or should I say SoLarry's.

I really liked Sun, but they really screwed with OpenSolaris licensing. If they used GPLv3, they would still be incompatible with Linux in start, but they would look good and see developers coming into their community and no Larry Elison could kill OpenSolaris. This way, OpenSolaris will be abandonware.


To all GPL bashers: That is what happen when you use GPL-incompatible license on purpose.

I am usually one of the most skeptical people around when it comes to big businesses, but in this case I think you're being irrationally paranoid. First off, Oralce eliminating paid support for OpenSolaris was a perfectly reasonable strategic move that as far as I can tell has no bearing on whether OpenSolaris will be developed further. Larry Ellison may be ruthless, but he is also smart. And the thing is, there is simply no benefit to be had by closing down OpenSolaris. Just think of OpenSolaris as their Fedora and Solaris as their Red Hat. It's a fine business model that they really have no need to mess with.

Keep in mind also that Oracle has been one of the biggest open-source contributors when it comes to Java technology in the past decade. Just because they sell a lot of proprietary software as well does not mean they are averse to open-source stuff. Ex-Sun-supporters like yourself need to stop being overly paranoid and hyperventilating and have a little faith that Ellison is not going to ruin everything.

FUD! OpenSolaris support is still available today and in the future!

That is true. OpenSolaris FUD is everywhere. OpenSolaris is the basis for Solaris 11. If OpenSolaris is killed, how will Oracle deliver Solaris 11? Everyone agrees that Solaris 11 will be delivered, how is that possible if all OpenSolaris code is scrapped? Some people dont think at all, or they are just plain FUDers.