From: Fred . <eldmannen@...>
Subject: Please add ZFS support (from GPL sources)
Date: Jul 17, 3:13 pm 2008
Previously we have not been able to have ZFS support due to it being
licensed under the CDDL and the kernel under the GPL.
Sun have contributed ZFS support to GRUB under the GPL license. We
could now use that code to implement support for ZFS in the Linux
kernel.
http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists
--
From: Alan Cox <alan@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 17, 2:55 pm 2008
On Thu, 17 Jul 2008 21:13:55 +0200
"Fred ." wrote:
> Previously we have not been able to have ZFS support due to it being
> licensed under the CDDL and the kernel under the GPL.
>
> Sun have contributed ZFS support to GRUB under the GPL license. We
> could now use that code to implement support for ZFS in the Linux
> kernel.
No we can't. The GPL ZFS bits don't include the various methods that
would violate the patent so there is no grant. I've several times asked
Sun to simply give permission and they don't even answer. I can only read
the Sun motiviation one way - they want to look open but know that ZFS is
about the only thing that might save Solaris as a product in the data
centre so are not truely prepared to let Linus use it.
This is now further complicated by the fact Sun and NetApp are in
litigation so ZFS is basically "toxic" for the moment and we'd need
permission from both sets of patent holders to proceed.
Alan
--
From: Jeff Garzik <jeff@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 17, 3:45 pm 2008
Fred . wrote:
> Previously we have not been able to have ZFS support due to it being
> licensed under the CDDL and the kernel under the GPL.
>
> Sun have contributed ZFS support to GRUB under the GPL license. We
> could now use that code to implement support for ZFS in the Linux
> kernel.
>
> http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists
Linux needs btrfs upstream more than it needs ZFS...
Jeff
--
From: Christoph Hellwig <hch@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 20, 6:57 am 2008
On Thu, Jul 17, 2008 at 03:45:07PM -0400, Jeff Garzik wrote:
> Fred . wrote:
>> Previously we have not been able to have ZFS support due to it being
>> licensed under the CDDL and the kernel under the GPL.
>>
>> Sun have contributed ZFS support to GRUB under the GPL license. We
>> could now use that code to implement support for ZFS in the Linux
>> kernel.
>>
>> http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists
>
> Linux needs btrfs upstream more than it needs ZFS...
Don't be so harsh. Adding a read-only for the start zfs driver for
Linux would be useful for various purposes. And adding read-only
filesystems to Linux is really easy. So if Fred really cares about it
I'd be very happy to mentor him implementing it. IT should be a very
good learning exercise for him.
--
From: Kevin Winchester <kjwinchester@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 20, 8:35 am 2008
On Sun, Jul 20, 2008 at 7:57 AM, Christoph Hellwig wrote:
> On Thu, Jul 17, 2008 at 03:45:07PM -0400, Jeff Garzik wrote:
>> Fred . wrote:
>>> Previously we have not been able to have ZFS support due to it being
>>> licensed under the CDDL and the kernel under the GPL.
>>>
>>> Sun have contributed ZFS support to GRUB under the GPL license. We
>>> could now use that code to implement support for ZFS in the Linux
>>> kernel.
>>>
>>> http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists
>>
>> Linux needs btrfs upstream more than it needs ZFS...
>
> Don't be so harsh. Adding a read-only for the start zfs driver for
> Linux would be useful for various purposes. And adding read-only
> filesystems to Linux is really easy. So if Fred really cares about it
> I'd be very happy to mentor him implementing it. IT should be a very
> good learning exercise for him.
If Fred declines, is anyone free to take you up on the offer? I have
no filesystem experience and almost no experience with kernel code in
general, so I would not be anyone's first choice for a task like this.
However, since it mainly appears to be an integration exercise (using
the code from GRUB and making it work in linux), it might well be
doable for me. As a bonus, being highly inexperienced, I have no
expectations of doing anything correctly, and thus would not react
badly to lots of criticism.
So to summarize - if anyone else would like to undertake this work,
they probably should. But if no one has the time/will, then I would
be happy to give it a try.
Thanks,
--
Kevin Winchester
--
From: Christoph Hellwig <hch@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 21, 3:28 am 2008
On Sun, Jul 20, 2008 at 09:35:45AM -0300, Kevin Winchester wrote:
> If Fred declines, is anyone free to take you up on the offer? I have
> no filesystem experience and almost no experience with kernel code in
> general, so I would not be anyone's first choice for a task like this.
> However, since it mainly appears to be an integration exercise (using
> the code from GRUB and making it work in linux), it might well be
> doable for me. As a bonus, being highly inexperienced, I have no
> expectations of doing anything correctly, and thus would not react
> badly to lots of criticism.
>
> So to summarize - if anyone else would like to undertake this work,
> they probably should. But if no one has the time/will, then I would
> be happy to give it a try.
Yes, this offer is of course up to everyone interested. But it's not
purely an integration effort in the traditional sense, the grub
filesystem interface is quite different from the Linux one, and the code
structure and style is quite different. But if you're willing to learn
it should be very interesting.
--
From: Kevin Winchester <kjwinchester@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 21, 7:39 am 2008
On Mon, Jul 21, 2008 at 4:28 AM, Christoph Hellwig wrote:
> On Sun, Jul 20, 2008 at 09:35:45AM -0300, Kevin Winchester wrote:
>> If Fred declines, is anyone free to take you up on the offer? I have
>> no filesystem experience and almost no experience with kernel code in
>> general, so I would not be anyone's first choice for a task like this.
>> However, since it mainly appears to be an integration exercise (using
>> the code from GRUB and making it work in linux), it might well be
>> doable for me. As a bonus, being highly inexperienced, I have no
>> expectations of doing anything correctly, and thus would not react
>> badly to lots of criticism.
>>
>> So to summarize - if anyone else would like to undertake this work,
>> they probably should. But if no one has the time/will, then I would
>> be happy to give it a try.
>
> Yes, this offer is of course up to everyone interested. But it's not
> purely an integration effort in the traditional sense, the grub
> filesystem interface is quite different from the Linux one, and the code
> structure and style is quite different. But if you're willing to learn
> it should be very interesting.
>
No one else seems to have volunteered, so I would certainly like to
give it a try. I guess I need to get the ZFS grub code, create a ZFS
filesystem, and start looking around for information on linux
filesystem development and ZFS (obviously without looking at any CDDL
licensed code).
Once I get a handle on that, I'll see where I can get before I need to
ask a thousand questions.
--
Kevin Winchester
--
From: Dave Kleikamp <shaggy@...>
Subject: Re: Please add ZFS support (from GPL sources)
Date: Jul 20, 12:56 pm 2008
On Sun, 2008-07-20 at 09:35 -0300, Kevin Winchester wrote:
> As a bonus, being highly inexperienced, I have no
> expectations of doing anything correctly, and thus would not react
> badly to lots of criticism.
That's definitely the right attitude to take. When I ported jfs to
linux, I was completely new to Linux and open source, so tried to defer
to the experienced developers whenever possible. Christoph was a
terrific help, offering a lot of suggestions and patches. JFS is a much
better file system because of his help.
There have been others contributing code that have not taken criticism
so well, and what started out as an offer of help turned into emotional
arguments and personal attacks. This really hampers getting your code
accepted into the kernel and your ability to work within the community.
> So to summarize - if anyone else would like to undertake this work,
> they probably should. But if no one has the time/will, then I would
> be happy to give it a try.
Thanks for offering. I don't know who else may be interested in this,
but good luck and thanks to you or whoever takes this up.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
--
Leopard support read-write
Leopard support read-write ZFS :)
http://zfs.macosforge.org/trac/wiki/
So does Linux, with
So does Linux, with zfs-fuse, for about 1 year now...a lot of people are using it..
But ZFS is totally overhyped, it's not the holy grail, and shure has problems, be it in zfs-fuse, OSX, FreeBSD or even Solaris.
I'm more looking forward (and testing) BTRFS
http://btrfs.wiki.kernel.org
Go btrfs, go!
Miguel Sousa Filipe
What does BTRFS do (or plans
What does BTRFS do (or plans to do) better than ZFS?
As for problems - every filesystem has them. The problems with ZFS are minor compared to e.g. losing files with XFS on crash or losing files on reiserfs for a variety of reasons. Also, technically ZFS offers features no other linux filesystem has. It's not a reiser4 kind of hype, where the filesystem itself was not technically interesting at all, if you looked at the actual code and not vaporware ('plugins') and carefully selected benchmarks.
XFS loosing files on crash? Another FUD by trasz
XFS loosing files on crash? Another FUD by trasz.
XFS does not loose files on crash; on crash, it was simply filling the "unwritten" part of a file with zeroes just to make sure a file in question does not contain any sensitive information (i.e., a part of an old version of a shadow file that happened to be on that part of the disk several days or months ago).
As it was questionable by some (and a lengthy process in certain scenarios), as of 2.6.18, XFS no longer fills the whole "unwritten" part of a file with zeroes, but rather "cuts" the size of a file.
But I bet trasz will now find a report of a file lost with an early port of XFS to Linux 2.4.
There was a problem some
There was a problem some time ago that manifested in XFS losing files that were open (not written, just opened) at the time of the crash. Cannot find that right now, but it was about one year ago.
That bug is probably fixed by now. What's important, however, is that this data-destroying bug was not detected by testing done by SGI, RedHat or any other company or team of developers that should do quality control - it was spotted by an user and found to be easily reproduceable. What's important is not the bug itself, but the fact that it was a result of improper (or lack of) testing. That bug may be fixed, but I don't think the approach of Linux developers and vendors to quality has changed in any way.
"But ZFS is totally
"But ZFS is totally overhyped, it's not the holy grail, and shure has problems, be it in zfs-fuse, OSX, FreeBSD or even Solaris."
right, because there are so many holy grails on linux that don't have absolutely any problems...
there are no holy grails, just things close to it... like ZFS... and Dtrace... that's why everyone wants them
It's sad that people like
It's sad that people like Alan Cox spread FUD in attempt to mask Linux' problems, like NIH syndrome, which is the only real reason ZFS wasn't ported to Linux.
Specifically:
1. The CDDL license, which covers ZFS, is more liberal than GPL. That's why ZFS was ported to several other operating systems. Porting it to Linux could be problematic, because of the "derived works problem", which is said by some (FSF) to prohibit linking code under GPL and other, incompatible (i.e. not a subset of GPL) licenses. In other words, GPL prohibits linking with non-GPL. However, this is not a real problem - nVidia, for example, doesn't have any problems with doing that.
It's important to make it clear that the full responsibility for the above lies in the GPL license. It was deliberately written in such a way to create this problem, by not clarifying what does not constitute derived work - CDDL, for example, says explicitly that code merely linked with CDDL code does not constitute derived work.
2. Solaris is much more technically advanced than Linux. There are lots of features Linux simply does not have, like ZFS or DTrace. There are lots of things Solaris does much better - take a look since when they have proper threads support, or ACLs, or priority inheritance. There are lots of things Solaris does better from the "organisational" point of view - standards compliance, backwards compatibility. And Solaris doesn't have exploitable kernel bug every month. Pretty much the only thing Linux does better is device support - and even that only in terms of quantity, not quality.
It's important to make it
And the CDDL was deliberately made incompatible to the GPL. Linux was GPL for years before that. So any code deliberately released under the CDDL was not supposed to be used in Linux. Saying "Oh, Linux is released under a free license, ZFS is released under a free license, so there's no problem combining the two" is pure hypocracy when the licenses are incompatible.
And even if the GPL did contain a definition of what constitutes a derived work - who says that'd be the same as the CDDL's (or the other way round, since the CDDL was written later)?
"Linux's problem", as you call it, is that it is released under the GPL and thus can't include code not compatible with that license. The CDDL isn't, and that is the only reason ZFS wasn't ported to Linux.
GPL was made deliberately
GPL was made deliberately incompatible with everything else. It's impossible for the GPL code to be linked with code under BSD (without effectively GPL-izing the whole thing), Mozilla, Apache, Postfix or anything not-GPL. Given that, accusing Sun for making CDDL "deliberately incompatible" seems silly. It was impossible for their license to be GPL-compatible, unless it's a subset of GPL.
It doesn't matter what came later. What matters is what license contains clause that prohibits linking.
As for derived work - it wouldn't need to be the same as with CDDL. It would be enough to just said 'software merely linked with GPL does not constitute derived work'. That would solve the compatibility problem completely. Mozilla does that. CDDL, which is a more liberal Mozilla license, does that too. GPL does not - and it seems it's the only license that has this problem.
GPL Linking
The licenses application to linking is by design. For cases were you want to be able to link and not be subject to derived works you would use LGPL - that's what it's for. For that reason most of the Gnome libraries are LGPL so you can make proprietary apps that use gnome facilities. However it's plainly not the intention of the Linux kernel authors to be able to make a Linux+Extra blob which is more restricted than just Linux.
--
Alex
CDDL was made deliberately incompatible with GPL
No CDDL was made deliberately incompatible with GPL. We have a SUN engineer saying so.
See http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/the...
It's impossible for the GPL
Not entirely true. There are licenses that are deemed GPL compatible because they don't impose any additional restrictions. BSD being one of them. If you link GPL and BSD code the aggregate does become GPL'd but the BSD code is still usable under the BSD license. It's just anything in the GPL'd code and anything new that is a derivative of the aggregate is GPL'd.
Of course it matters. The creators of the CDDL knew the restrictions of the GPLv2 and the fact that Linux was released under the GPLv2 when they created and chose to apply the CDDL to Solaris. If they really wanted their code to be incorporated into Linux they would have chosen or created a compatible license.
Now you're just making
Now you're just making things up. There's no problem incorporating BSD code in GPL projects.
You just may not use code which has ANY restrictions that the GPL does not have together with GPL. If you want to know if a certain license than be intermixed with GPL code, FSF has a web page with detailed information.
Viral
I think the grandparent poster was confused by the viral nature of the GPL with respect to BSD licensed code. However, it does bring up the interesting issue that the GPL's viral nature places extra restrictions on more freely licensed code (such as that released under BSD or MIT X11 style licenses). My understanding of the Sun's motivation with the CDDL was that they wanted to avoid the viral nature of the GPL.
Sheesh, how naive can you
Sheesh, how naive can you be?
The one and only point about the CDDL was to be GPL incompatible, otherwise they would've chosen a BSD like licence.
If you need further proof: Linux cannot implement a clean room ZFS implementation due to patents: you can use ZFS only if you use the CDDL version. If you care about "freedom", don't use it.
You seem to be suggesting
You seem to be suggesting that CDDL is just a BSD done in a way that is GPL-incompatible. That is untrue, however. It would be impossible to guarantee the receivers (users and contributors) of the CDDL code the amount of patent protection it does without making it GPL-incompatible, for example.
Now THAT is an accomplishment!
GPL anticipates all licenses in order to be incompatible with any license written after the GPL. That's quite an accomplishment! It's also laughable.
You're confusing things. A GPLed work is always a GPLed work. Other licenses are compatible with GPL when they can be linked with a GPLed work and the result distributed as a GPLed work without violating the terms of either license. This doesn't work with "BSD with advertising clause", because the "advertising clause" adds a restriction that the GPL doesn't permit. It does work with "BSD without advertising clause."
The CDDL explicitly includes provisions that make it so that CDDL-licensed code can not be linked into and distributed as a GPL licensed work. This was done deliberately by Sun, and they've openly admitted it.
The GPL deliberately sets out its rules of engagement. Sun, when crafting the CDDL, sought specifically to make its license incompatible with those terms. The FSF did not (and could not!) make the GPL deliberately incompatible with a license they had not yet seen.
BTW, the prohibition isn't against linking. It's against distributing the result. You can link ZFS into your Linux kernel all day long and it's permitted by the GPL. Just don't distribute the combined result.
--
Program Intellivision and play Space Patrol!
Regarding GPL being
Regarding GPL being incompatible with everything else - what I mean is, GPL was designed in a way to make sure that GPL can take code from BSD or MIT, but it prohibits doing the reverse. It's kind of "selfish" license.
The statement that "CDDL explicitly includes provisions that make it so that CDDL-licensed code can not be linked into and distributed as a GPL licensed work" couldn't be further from the truth. CDDL contains nothing resembling that. Actually, CDDL says explicitly that merely linking with CDDL code does not constitute derived code, to make sure it cannot be interpreted as "viral".
The whole problem with linking CDDL with GPL - or linking anything that is not a subset of GPL with GPL - is the lack of definition of "derived work" in the GPL. FSF says that linking code with GPL results in a "derived code" - thus, linking GPL with license that is not a subset of GPL (so called "GPL-incompatible") results in a breach of the GPL. The whole problem lies entirely in GPL, not CDDL.
It's important to mention that the above is FSF interpretation. Many lawyers don't agree with that, saying that GPL is not viral in any way and linking code under GPL with code under any other license - including GPL-incompatible - is OK.
As for "linking vs distribution" - yes, that's true. Usually one does want to distribute his work, though, so it doesn't really matter if license prohibits creating something, or distributing that something.
Btw, that's another thing that confirms that "license incompatibility" is not the true reason for the lack of ZFS port.
It would help if the CDDL-bashers actually read the license. It's short (not as short as BSD, but way shorter than GPL) and written in a fairly simple language.
The statement that "CDDL
Then why does Sun, the author of that license, say that that's the case? If the author of the license says that that was an explicit goal, who are you to deny it? Specifically, Danese Cooper (whom Simon Phipps of Sun says was the actual Sun employee that authored the CDDL) has said publicly:
So I don't see how it could be any closer to the truth.
As for the derived work aspect: The FSF states their intentions and their interpretation, indicating that it is precisely that, an intended interpretation. The burden is on the integrator and/or distributor to demonstrate that a given work is not a derived work if it links with a GPLed work. That's basic copyright law, not something the FSF invented. The FSF are doing folks a favor by offering a reasonably clear threshold that they won't cross. The real issue is that copyright law does not define what a derived work is, and that the GPL relies on copyright for its foundation.
--
Program Intellivision and play Space Patrol!
Is it FUD
Is it FUD? The licences are what they are and you can't wish away the problems that may occur mixing them up. Whatever the respective benefits of CDDL vs GPL you can't go mixing that code. I'm fairly sure when Sun developed a new license they knew such mixing would be impossible. If Alan Cox has asked Sun to make the patent grant for ZFS to be implemented in GPL code then I would say the ball is in their court.
I don't see Linux as having a NIH syndrome. It has over the years imported many technologies, filesytems and new ideas into the kernel. However the kernel community is understandably careful about adding stuff that may expose Linux to known legal risks.
The nVidia kernel module is a bad example. nVidia may think it's OK but plenty of people think it's not. However until it's tested in court we will never know where the law stands on derived works. It's not for the license to define that, it's for the legal system.
On whether Solaris is more technically advanced than Linux I think it's highly debatable. Sure ZFS and DTrace are big pluses in it's feature arsenal, however there are many areas Linux has the lead (outside of device drivers). If it comes to choosing between the two for some app I would expect to benchmark them both and choose which was better for the workload.
The kernel exploit statement is an apples and oranges comparison. You want to track Solaris kernel exploits against a Linux distro kernel rather than the development tree. Last I checked you don't really see the day to day development of the Solaris kernel.
--
Alex
yes, trasz is known for spreading FUD about Linux
yes, trasz is known for spreading FUD about Linux, was effectively banned from several forums, looks like he found kerneltrap now.
BTW, he's also a maintainer of some lesser-used FreeBSD ports: http://portsmon.freebsd.org/portsconcordanceformaintainer.py?maintainer=...
Actually, I'm not aware of
Actually, I'm not aware of any forum I've been banned from. ;-)
You're from OSNews.pl, right? It was explained several times to you and others by
that site' owners that merely saying things you do not want to know does not
constitute trolling, if it's backed by rational, technical arguments. ;->
Yes, I maintain several ports. I'm also FreeBSD Ports commiter, computing history
passionate, unix-related in particular, physicist, GSoC student and several other
things. What's your point?
>If it comes to choosing
>If it comes to choosing between the two for some app I would expect to benchmark them both and choose which was better for the workload.
faster == better
Re: How many servers with
So how many servers with 4096 CPUs or greater do you see running Solaris? None. Why? Because it can't.
SGI runs Linux on those beastly machines and it runs like a champ. Solaris has 3 main things over Linux:
- A stable kernel API
- Dtrace
- ZFS
ZFS is pretty awesome, but it is not the holy grail or without problems. See this article for a good example: http://kerneltrap.org/FreeBSD/ZFS_Stability
Dtrace is hands down something that sets solaris apart from everything. Eventually... utrace and tracehooks will be merged into Linux. These will allow user and kernelspace tracing of applications with systemtap. This is "good enough".
Btrfs will be doing things ZFS can not such as snapshots of snapshots. It won't be a "ZFS killer" so much as a ZFS competitor. They will both be exceptionally good.
That leaves Solaris with a stable Kernel API. This is a doubled edged sword in that it makes true innovation difficult in the Solaris kernel. All in all, I'll take Linux.
The reason ZFS wasn't ported to Linux was because the CDDL was designed to prevent it being ported to Linux. If Sun _truly_ wanted ZFS in Linux, they would license it gplv2+ so that it could be in Linux also. Since they own the code, they can do that you know.
scalable os
Being able to use 4096 processors means nothing, what matters is how much more work can be done when you start adding processors.
Dtrace and ZFS are already production ready in solaris and people are using them, many people are using it already and administrators have accepted it. Do you even know how much time it takes for something like that to gain acceptance?
The problem with whatever linux replaces dtrace with is not the technology per se. Sun is already integrating probes in things like Xorg, firefox, mysql and postgres, that also takes time, and it will take a LOT more time for other dtrace like solutions if people are happy with how Dtrace works.
Give it up, trasz. Everybody
Give it up, trasz. Everybody sees right through your trolling.
My take on this issue
Let me make my own take on the licensing issue of ZFS vs GPL. The intentions by Sun were twofold: create a linces thats not compatible with GPL so that you cannot include it in LInux which is its main competitor, and its understandabl. If you look at Sun they have been a proprietry software company for a majority of its existence and ofcourse they want to protect their technology against its main competitors. But at the same time, they wanted to allow sharing. thus its compatible with BSD. The GPL is in my opinion an extreme license. The Linux kernel would be much better off using LGPL or the Apache license in my opinion.
The second reason is that GPL is I believe Sun believes a bad license in general(because its incompatible with almost everything else). Im fond of the BSD license myself, although im aware that the license itself is quite naive (ie OpenBSD openHAL vs Linux).
GPL
I think linux is succesfull because of GPL. A lot of contributors want their code to stay open and not let proprietary vendors take without giving back. GPL makes you give back, without gpl - why bother giving back, it will only mean extra legal expences and will give the code away to competitor who can keep the imrovement without releasing theirs. With GPL competitors are forced to work together, they get some of the improvements for free without being afraid the other vendor will get an edge by keepeng their improvements. To get an advantage they have to compete on another level, like support/integrating/some special niche.
If your theory were true,
If your theory were true, then projects like PostgreSQL, OpenSSH, BIND or FreeBSD (all under BSD license) or Xorg (MIT license) would all be dead years ago.
Agreed
And that is without mentioning other projects like Apache... each one is free to use the license of his liking, GPL is just another one on the list.
yey Apache.
yey Apache.