Announcement

Collapse
No announcement yet.

Linus Torvalds Doesn't Recommend Using ZFS On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by k1e0x View Post
    And XFS is trying -trying- to bolt on it's feature set. I've seen some of the hoops they are trying to do to make that happen and it's terrifying.. like loopback volumes and extents. ugh no thanks.
    There is a problem here what if XFS is not in fact bolting on new features but implementing old lost features xfs. This will come clear latter.

    Originally posted by allquixotic View Post
    Calling something enterprise doesn't make it stable. Having it run successfully in mission-critical applications on expensive hardware for many years without falling over, is what makes a filesystem earn the name "enterprise". I do believe XFS has also earned the moniker "enterprise" just like ZFS has, and that's totally fair. But XFS also does not compete with ZFS on features -- at least not by itself.
    XFS was the first todo tiered storage but not by it self. IRIX xvm allowed to teired storage with XFS with ram drives we are talking before ZFS and WAFL was even a idea. When XFS was ported to Linux on top of LVM2 these features were lost.

    In features XVM and XFS was a lot closer to ZFS than Stratis today. So a lot of what is happening to XFS today is implementing what the XVM/XFS combination had but now with a lvm2/xfs combination.

    Originally posted by allquixotic View Post
    The only way the current block layer can be said to satisfy that criterion is because it's so feature-deprived that it literally implements the lowest common denominator, and is extremely simplistic in design. But it then puts a huge burden on filesystems to build on top of it for any non-trivial features, like tiered storage.
    This is absolutely correct. Lot of the block storage layers have been absolute crud.


    Originally posted by allquixotic View Post
    ZoL will continue to fill that gap, until the Linux community at large settles on a proper solution.
    The reality here is sun put hell lot of marketing into ZFS the result was btrfs cloning ZFS way with no one really looking into what had been done before. By filling the gap people also did not have to look.

    With ZoL license issues maybe the long term plan should be ZoL extermination.


    Originally posted by k1e0x View Post
    Stratus entire introduction was about how sad RedHat was it can't use ZFS due to licencing. (something that isn't true as Canonical has shown)
    This is not a good point Canonical is in fact registered in the Isle of Man and Redhat is registered in the USA this makes quite a huge difference. Canonical goes ahead and disregards how USA courts might read CDDL and GPLv2 this may or may not come back and bite you but will not come back and bite Canonical. Linux Distributions are not created equal by legal liability.

    Originally posted by k1e0x View Post
    ZFS's development isn't on making it work.. it's on making it work better, faster and leveraging it in new ways.
    This is exactly describing what the XFS lead developer is up-to as well.

    Originally posted by k1e0x View Post
    I wonder if RedHat even did a legal review on this outside the FSF lawyers? Or maybe they are one and the same?
    Yes they did have reviews outside the FSF they had already done a set for MPL 1.1 because back in the day there was a kernel driver licensed under MPL 1.1 yes your CDDL is not different same problems exist in it as MPL 1.1.

    Originally posted by k1e0x View Post
    And the argument that the second largest Linux vendor "isn't big enough" for Oracle to sue
    The odd of Oracle getting any money out of Canonical even if they win is almost zero due to the legal status of the Isle of Man. Correct answer from collectable money pool Canonical is not big enough for Oracle to go after. Redhat on the other hand would be.

    Really its about time you stop bring out Canonical as why ZFS is safe. Canonical themselves are safe because of their country of registration. Anyone as like a end user in the USA or Australia if Oracle does sue is basically left holding the bag while Canonical walks away scott free. Lot of ways Canonical don't care about their customer liability only their own.

    It would be better to target like Azure or AWS for ubuntu usage than go after Canonical over ZFS.

    Leave a comment:


  • k1e0x
    replied
    Stratus entire introduction was about how sad RedHat was it can't use ZFS due to licencing. (something that isn't true as Canonical has shown) and how btrfs sucks too much to develop. So they looped a bunch of technologies together in userspace and glued them together with dbus. I don't have a lot of faith for this. It has a lot of moving parts and they have to herd technologies heading in different directions. Gluster on ZVOLS seems far better.. and it works today.

    ZFS's development isn't on making it work.. it's on making it work better, faster and leveraging it in new ways.

    I wonder if RedHat even did a legal review on this outside the FSF lawyers? Or maybe they are one and the same? lol

    And the argument that the second largest Linux vendor "isn't big enough" for Oracle to sue doesn't hold water either from a company that will threaten to take you to court over a $5 Virtual Box license.
    Last edited by k1e0x; 15 January 2020, 03:23 AM.

    Leave a comment:


  • allquixotic
    replied
    Originally posted by oiaohm View Post
    Now you are in trouble with logic. RHEL dropped Btrfs but did not give up on the idea of tiered storage.
    I read about Stratis before. I actually like what Red Hat is doing. Unfortunately, Stratis right now is about as mature as ZFS was in 2002 or so. It has some years to go before it's ready for prime time. For those not eager to wait 3+ years, ZFS is the only option.

    If Stratis had been started, I don't know, in 2007, and already had 13 years of varied workload testing under its belt, ZFS on Linux might not even exist, because nobody would have bothered to port it. They'd be using Stratis with XFS.

    Now you might be saying "But wait, Stratis is layered on top of existing technologies, so it won't take 10 years to be ready." Maybe so -- I've seen successful "lightweight" projects that build on a combination of userspace and kernel primitives that hit the enterprise in a few years; Podman and LXD come to mind. But for people who use Ubuntu LTS or RHEL/CentOS releases only (for their stability and long support lifecycle), realistically those releases are not going to retroactively add in something like Stratis after release... probably. Or if they do, it will require a proprietary paid subscription until the next major release of the OS.

    Looks like RHEL 8 has Stratis as a "tech preview" -- that's all well and good, but tech previews generally would not get the Authority To Operate in a production environment. I might consider doing that on my home servers, but... it'd be like using LXD in Ubuntu 16.04. Rough around the edges. Plenty of gotchas and missing features. ZFS has none of these problems.

    Originally posted by oiaohm View Post
    XFS lead developer has taken a different route to the tiered storage problem. Btrfs started as clone of the ZFS idea and ZFS started as something after the WAFL idea. All these have the idea that you integrate the block layer stuff into the file system layer.
    I am aware of the technical reasons why it has been argued to keep the block layer and FS layer separate, and some of them are pretty compelling. But from what I've seen, this layering also creates performance problems with certain types of behaviors, and makes certain features extremely difficult to implement efficiently. If they can figure out how to keep these layers decoupled, or just very loosely coupled at best, while maintaining the same level of performance as a filesystem that tightly integrates block layer and FS layer concepts, great. But that's a development task, meaning it's probably months or years away from hitting Linux git master, and another couple years later until it's debugged, tested, and ready for enterprise distros to build on.


    Originally posted by oiaohm View Post
    Yes the wheel so called tiered storage file systems are all reinventing is the block layer. Maybe just Maybe we should improve the block layer API/ABI to file system so that all file systems Linux supports with min code can come tiered storage file systems.
    I think this is kind of the "Storage Spaces" idea from Windows. The closest equivalent Linux has today is LVM2, but that has a lot of problems, not the least of which is performance. Storage Spaces on Windows isn't a great implementation, either. It seems that whenever someone tries to implement a block layer that can handle tiered storage on its own, there are major limitations and performance gotchas, but whenever a filesystem tightly integrates the block and FS layers, it turns out great. Compare LVM2/Storage Spaces with ZFS/APFS. Which one is faster, least buggy, and more relied upon?

    The other problem is, to get this totally right and really nail down this problem, the block layer solution needs to be absolutely immaculate -- as in, perfect. It needs to be so good that any conceivable filesystem concept can use it. The only way the current block layer can be said to satisfy that criterion is because it's so feature-deprived that it literally implements the lowest common denominator, and is extremely simplistic in design. But it then puts a huge burden on filesystems to build on top of it for any non-trivial features, like tiered storage.


    Originally posted by oiaohm View Post
    Problem ZFS and WAFL in performance does not compete well with many file systems. Also no single file system is going to be perfect for every single workload.
    ZFS is fast enough for the people who use it. In fact, being able to take advantage of tiered storage probably results in a faster overall experience compared to having to directly write to the HDDs. Using ARC, L2ARC and ZIL when you have this kind of hardware (big HDDs + fast/small SSDs) will probably get you the highest total system performance (real-world, not microbenchmarked) for that given hardware. Obviously, for a single NVMe SSD in a laptop, a filesystem that doesn't do checksums like ext4, or one built for flash devices from the ground up like f2fs, will probably be faster.

    Originally posted by oiaohm View Post
    Please note saying that ZFS is a enterprise file system does not really mean much thinking that XFS is one of your oldest enterprise file systems. More interesting xfs leadership has had the least change out of any file system.
    Calling something enterprise doesn't make it stable. Having it run successfully in mission-critical applications on expensive hardware for many years without falling over, is what makes a filesystem earn the name "enterprise". I do believe XFS has also earned the moniker "enterprise" just like ZFS has, and that's totally fair. But XFS also does not compete with ZFS on features -- at least not by itself. Maybe in a few years, once Stratis is out of tech preview in RHEL 9 (??? maybe?) it will be a viable replacement for ZFS.

    Can you see the problem here? People have been needing to launch tiered storage solutions into production for years. Some people have said they've been using ZFS on Linux in production for almost 10 years now. And we're looking at maybe-possibly-soon (1 to 3 years) Linux coming up with some kind of an answer to tiered storage just now, in the early 2020s. Sure, hindsight is 20/20, and going forward with a green field project today the answer might be easier, but the need for tiered storage went unanswered by the mainline Linux developers and OS distros for many, many, many years, and ZoL filled the gap.

    ZoL will continue to fill that gap, until the Linux community at large settles on a proper solution.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by oiaohm View Post
    Problem ZFS and WAFL in performance does not compete well with many file systems. Also no single file system is going to be perfect for every single workload. The Redhat/IBM backed route is interesting. In time we may remember ZFS as this biggest historic design mistake.

    Please note saying that ZFS is a enterprise file system does not really mean much thinking that XFS is one of your oldest enterprise file systems. More interesting xfs leadership has had the least change out of any file system.
    What are the design mistakes, That it wasn't written by RedHat? lol.

    You're such a shill oiaohm. Please stop.

    ZFS only changed how people thought about filesystems and moved the entire landscape to copy it. No filesystem created since hasn't taken inspiration from it. And XFS is trying -trying- to bolt on it's feature set. I've seen some of the hoops they are trying to do to make that happen and it's terrifying.. like loopback volumes and extents. ugh no thanks.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by allquixotic View Post
    the ability to efficiently use tiered storage.
    This is the problem.

    Originally posted by allquixotic View Post
    You would think that Linux would have a stable, mature, tested, highly optimized filesystem in-house for handling Tiered Storage properly, but it actually doesn't. Not at all. None of the solutions available with Btrfs, XFS, Ext4, LVM2, MD, and family even come close to the performance and feature-set of ZFS with tiered storage. Not to mention that the closest feature competitor, Btrfs, is still such a boondoggle stability-wise that Red Hat is abandoning it as a supported filesystem in RHEL. They also don't have any engineers to work on it, but if it were stable, they wouldn't need to.
    Now you are in trouble with logic. RHEL dropped Btrfs but did not give up on the idea of tiered storage.
    https://stratis-storage.github.io/faq/


    Originally posted by allquixotic View Post
    I will continue to use ZFS on Linux (at my own peril? Fine.) until Linux offers an in-kernel alternative that matches its performance, featureset and maturity. LLNL has the right idea -- they knew what they were doing when they invested so many dollars into the development of ZoL. They needed a tool that didn't exist, so they built one.
    To be correct is unlikely to be a complete in kernel alternative to ZFS. Its likely to be something like stratis.

    XFS lead developer has taken a different route to the tiered storage problem. Btrfs started as clone of the ZFS idea and ZFS started as something after the WAFL idea. All these have the idea that you integrate the block layer stuff into the file system layer.

    XFS developer route is more interesting. https://lwn.net/Articles/747633/ it starts here with a simple question. Why do I need a loopback device to mount a file system image in a file? the answer is it does not. One of the alterations of XFS was the means to pass though the blocks of a file to a file system driver without using a loopback. So over time all Linux file system drivers could be updated and render loopback useless.

    You have the enospace handling chnage. Something that is being worked on the means to see block level check-sums from general file system operations. Yes software raids do put checksums all all the blocks so do hardware raid controllers.

    There is a trend here.

    Why are so called tiered storage file systems reinventing the wheel? And is this right?

    Yes the wheel so called tiered storage file systems are all reinventing is the block layer. Maybe just Maybe we should improve the block layer API/ABI to file system so that all file systems Linux supports with min code can come tiered storage file systems.


    Originally posted by k1e0x View Post
    Well.. yeah.. ? FreeBSD is a server OS.. so is Linux really (at least it use to be..) And ZFS is an enterprise filesystem.. It has some cool uses in the home but ZFS runs 100 petabyte arrays, ZFS dosen't compeate with Ext4.. it competes with NetApp's WAFL filesystem. People don't really want it in Linux tree as ryao has said. Most people are pretty happy with where it is.. they just want it to work well with Linux so they can use it to free their enterprise infrastructure from the likes of EMC, NetApp and DDN.
    Problem ZFS and WAFL in performance does not compete well with many file systems. Also no single file system is going to be perfect for every single workload. The Redhat/IBM backed route is interesting. In time we may remember ZFS as this biggest historic design mistake.

    Please note saying that ZFS is a enterprise file system does not really mean much thinking that XFS is one of your oldest enterprise file systems. More interesting xfs leadership has had the least change out of any file system.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ryao View Post
    As far as I know, Oracle was able to settle the lawsuit without giving very much. They did not want to divert resources from the Java lawsuit and Netapp did not want to be in the lawsuit. Netapp did get what they originally wanted though, which was not having to pay royalties over the ZFS patents.
    We are talking about legal here. As far as I know is not good enough. We need either Oracle or Netapp to state what was done in that settlement.

    Originally posted by ryao View Post
    There is no court higher than the US Supreme Court in the US according to the US constitution. It’s decisions are final. If you look at “international courts’” decisions, you would find the decisions are non-binding (and are often ignored by the losing parties).
    No this is the problem. International court rules on copyright are binding if they happen to be based on a trade agreements as breaching international trade agreements trigger international sanctions. By the way trade agreements signed off by the President of the USA has a higher authority than the US Supreme Court by the constitution. If Oracle if GPLv2 implied patent license gets ruled against in the International court and gets ruled in favour in the US court the result is Oracle can only sell product in the USA until they obey the GPLv2 implied patent license. The section of international law that creates GPLv2 implied patent license in fact automatically triggers International sanctions on the losing party no matter what they judge says.

    I will give you that there are many international court decisions that are not binding. Problem the ones that are binding from the international court hit hard. Yes is safer to take on GPLv3 declared patent license than end up in the international court because you are disputing if patents over rule copyright or copyright over rules patents. International court says copyright overrides patents and if you disagree with that point except not being able sell globally.

    Please note it would be highly unwise for the US supreme court different to the international court on GPLv2 implied patent license because the worst the international court could do is a full ban/International sanction on exports of a particular class of product from a particular country in the case of GPLv2 this would be all software that you buy with money from the USA. Basically death to the USA software industry.

    Basically international court is anywhere between completely toothless to I will kill you and everyone know just because I can. When comes to the implied patent license in copyright is the worst one. Yes it based on something that is a higher authority than the US Supreme court by US Constitution .

    https://en.wikipedia.org/wiki/Treaty_Clause
    Basically you are forgetting the effects of the Treaty Clause. And part of some treaties is that the case can be heard and rules in the international court with all countries agreeing to enforce the ruling. So technically with treaties over copyright that the USA has agreed to if Oracle was ruled against the USA would have to stop them from exporting and possibly everyone else in the paid for software field

    US Supreme court is not always the highest court in the USA. Treaty Clause at times put the international court above the US supreme court. GPLv2 is one of those horrible cases.


    Originally posted by ryao View Post
    We have the SFLC and plenty of companies willing to work together if there is an issue. Why do you think we have OpenZFS?
    Problem is you are not really reading what the SFLC people have told you. They gave you a lot of possible untested solutions and also told you without question CDDL and GPLv2 are incompatible.


    Originally posted by ryao View Post
    As for Oracle losing, they would lose if they went after ZFS too. That is what my legal counsel believes anyway.
    The reality is you have none of the documents/prior precedents you need to win for sure with CDDL. Has you legal counsel done a proper devil advocate test on your position.

    Reality once you do that on CDDL you find yourself in trouble. Devil advocate means you drop all the straw-man arguments that don't have proper backing.


    Originally posted by k1e0x View Post
    I'm convinced that the reason Oracle hasn't already gone after commercial implementations of OpenZFS already is that they would lose. They pay people 24/7 to look at issues like this.
    Really if Oracle currently sued the parties using ZFS and won there would be a good chance Oracle would spend more money fighting the legal case than they would get. So it does not make any sense at this time. This is one thing about Oracle case track record they go after people who they can make a profit from. So it makes perfect sense that Oracle will be sitting and waiting for ZFS.
    Last edited by oiaohm; 15 January 2020, 12:57 AM.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by blackiwid View Post

    Of course when I speak about Users I speak about their own machines / Desktop, I don't go around and say hey "Linux" is on most computers because, it drives the Internet and all 10 quadrilliards of smartphones use it. The desktop is what matters and there Linux has like 2% or something und BSD like 0.1% if not less.
    Well.. yeah.. ? FreeBSD is a server OS.. so is Linux really (at least it use to be..) And ZFS is an enterprise filesystem.. It has some cool uses in the home but ZFS runs 100 petabyte arrays, ZFS dosen't compeate with Ext4.. it competes with NetApp's WAFL filesystem. People don't really want it in Linux tree as ryao has said. Most people are pretty happy with where it is.. they just want it to work well with Linux so they can use it to free their enterprise infrastructure from the likes of EMC, NetApp and DDN.

    Desktop is.. whatever floats your boat.

    Leave a comment:


  • allquixotic
    replied
    I posted this on Slashdot, but I'll reiterate it here. I have nothing to say about licensing; the situation is what it is. This is a purely technical argument for why ZFS is still unique, and fills a common need in a way that no in-tree FS does.

    There are a lot of comments asking "why ZFS" but most of them don't really understand the main killer feature of ZFS (and ZFS on Linux): the ability to efficiently use tiered storage.

    See, there's currently a problem overall with the storage industry. Flash storage, aka SSDs, is hideously expensive per gigabyte. Magnetic storage, aka HDDs, is hideously slow in terms of IOPS. For difficult workloads that require an optimization of server purchase price, high IOPS, and large quantities of local storage, Tiered Storage is the only real option.

    This allows you to buy both: (1) relatively inexpensive, high write endurance but fairly low capacity SSDs -- usually on the order of 128 to 512 GB, depending on the size of the HDDs behind them; and (2) relatively inexpensive, high capacity but slow HDDs -- usually 8 TB or larger -- and combine them into one logical block device that *behaves* as if it were an SSD with many terabytes of storage. You get about 98% of the IOPS performance of the SSDs, while all the data ultimately persists to the HDDs behind the scenes. This is remarkably good for large databases and file storage servers, and the price of building all of that capacity in datacenter-grade SSDs is going to run you about $1000 more per terabyte of capacity, assuming RAID-1 redundancy.

    With ZFS, you can set up your ZFS Intent Log (ZIL) -- basically a write buffer for the HDDs -- on a partition about 25-50% of the SSD capacity (depending on how write-intensive your workload is), and set up the ZIL in RAID-1 mode for data safety. ZFS will then efficiently create large batch sequential writes to the HDD that convert what could be thousands of SSD IOPS (small writes from a database, for instance) into a few dozen HDD IOPS. This allows your storage array to absorb even tens of gigabytes of random writes at hundreds of megabytes per second into the SSDs, which then get reorganized, optimized, and streamed to the HDDs sequentially in a way that optimizes throughput for the HDDs. And program-level calls to sync() or fsync() can legitimately return after completing the writes to the ZIL, even if the writes are still pending to the HDDs, because the data is genuinely on persistent storage that will survive a power outage.

    You can also have an L2ARC (Level 2 Adaptive Replacement Cache) with ZFS, which is basically a page cache for *reading* from the HDDs that sits on a partition in the SSDs. For my servers, I set up the L2ARC to consume about 75% of the space of the SSDs because I don't tend to get very large bursty writes on my workload, but for those with a much higher write workload they will want to increase the percentage of ZIL vs. L2ARC.

    Once again, like the ZIL, the advantage of L2ARC is to reduce the workload on the HDDs and reduce the IOPS demanded of them. The ARC algorithm has also been mathematically proven to be generally more efficient at common page cache workloads than the page cache algorithm the Linux kernel uses for other filesystems, so there's a "Layer 1 ARC" in RAM, too. And it's adjustable in size so you can tune whether you want to suck up lots of RAM with ARC, or leave more RAM for application data.

    For those who would just have HDDs and use RAM buffers to insulate the storage from high IOPS, RAM has three major limitations: one, it's volatile, so it can't safely cache writes for very long; two, using RAM for filesystem caching competes with applications that want to allocate RAM for their own purposes; and three, RAM is very expensive. Also, it's much easier to expand the amount of storage in a server than to expand the amount of RAM: if you have the max. amount of RAM your motherboard supports, you'd have to buy an entire new system to get more. With storage, you can usually just attach another drive, pair of drives, or worst case attach another SATA, SAS, or NVMe card onto the PCIe bus using a spare slot for even more storage. Long story short, you can have a much smaller scale system with terabytes upon terabytes of HDD or even SSD storage, but servers with a couple terabytes of RAM are absolutely enormous, come at a massive cost premium, and require special planning for power, rack space, and system administration, which usually isn't required if you just add a few storage devices.

    So, if you want the best of all worlds, being able to use relatively inexpensive commodity hardware (like single-slot Xeon, or even desktop-grade hardware like Threadripper) but have excellent performance for workloads like databases, game servers and so on -- anything that demands a lot of small writes -- your most affordable path is to use Tiered Storage.

    You would think that Linux would have a stable, mature, tested, highly optimized filesystem in-house for handling Tiered Storage properly, but it actually doesn't. Not at all. None of the solutions available with Btrfs, XFS, Ext4, LVM2, MD, and family even come close to the performance and feature-set of ZFS with tiered storage. Not to mention that the closest feature competitor, Btrfs, is still such a boondoggle stability-wise that Red Hat is abandoning it as a supported filesystem in RHEL. They also don't have any engineers to work on it, but if it were stable, they wouldn't need to.

    I will continue to use ZFS on Linux (at my own peril? Fine.) until Linux offers an in-kernel alternative that matches its performance, featureset and maturity. LLNL has the right idea -- they knew what they were doing when they invested so many dollars into the development of ZoL. They needed a tool that didn't exist, so they built one.

    And no, running a Solaris or BSD kernel probably isn't a viable alternative, when most all software is designed and tested for Linux, and the BSD and illumos compatibility layers for Linux are sketchy at best.

    For Linux laptops and home gamers, using XFS on a single HDD or SSD is fine, and even if you have a system with both HDDs and SSDs, tiered storage probably isn't of major benefit to you, because you don't have a workload that justifies it. A lot of people do, though, so they're either paying out the nose for way more SSD storage than they need, way more RAM than they need, way bigger servers than they need, ... or they're smart and they use ZoL.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by ryao View Post

    Linus does not find that to be an issue from what he has told me in person. He already has stuff in his tree under licenses other than the GPL.
    And are those other licenses incomaptible with GPLv2? No they are not so what the point of this argument???

    Originally posted by ryao View Post
    By the way, for what it is worth, I hold copyright over part of OpenZFS. You do not have any standing to be telling me about OpenZFS’ copyright situation, especially after the years of arm chair remarks by guys like you led me to speak to several attorneys on this topic. You also just dismissed a legal opinion by the most preeminent legal scholar on OSS as strawmans. It is rather ridiculous.
    No I didn't dismiss the legal opinion of the "most preeminent legal scholar on OSS", I quoted him verbatim. The strawman is you bringing up that article in connection with including ZFS in the Linux Kernel source code tree when it's all about the legal possibilities of including ZFS as a binary distribution together with the Linux kernel.

    And what does your copyright on parts of OpenZFS matter? We are talking about the license that code is licensed under, and how that license is incompatible with GPLv2. We are not arguing over your contributions or code.

    If you one day own the copyright to 100% of the ZFS code then it does matter because then you have the legal right to relicense it, but we are not there now are we.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by ryao View Post
    There are no rulings over the GPL and patents. The GPLv2 also has no patent grant, unlike the CDDL. Oracle is also holding plenty of patents from Sun on UNIX in general. If they wanted to use the nuclear option, ZFS is in a much better position than Linux due to the patent grant of the CDDL.

    Your remark “without SUN legal information that Oracle holds how many more parties are there like this” is FUD that can be applied to *anything*. Microsoft has a few patents that it has used against the Linux kernel to collect $1 billion in annual royalties from Android phone makers, so it is clear that such FUD could be easily applied to Linux too. Oracle has enough UNIX patents that they likely could do the same or worse with Linux if they tried.
    This.

    The GPLv3 was written for this exact case. And it isn't just Oracle. IBM (RedHat), AT&T, Novell, Microsoft and others own huge amount of Unix patents.

    I'm convinced that the reason Oracle hasn't already gone after commercial implementations of OpenZFS already is that they would lose. They pay people 24/7 to look at issues like this.

    If they really wanted to pull the nuclear option one could also challenge the assumption software warranty exceptions are valid.
    Last edited by k1e0x; 14 January 2020, 04:23 PM.

    Leave a comment:

Working...
X