Slashdot Mirror
NetApp Threatens Sellers of Appliances Running ZFS
eldavojohn writes "ZFS is licensed under the CDDL and is considered to be open source, but NetApp is sending threatening legal letters to startups who look to offer ZFS on NAS appliances. This assault on Coraid has a few people worried about the future of ZFS as NetApp rears its ugly head yet again. The CEO of Coraid replied to NetApp's demands, saying, 'We made the decision to suspend shipment after receiving a legal threat letter from NetApp Inc., suggesting that the open-source ZFS file system planned for inclusion with our EtherDrive Z-Series infringes NetApp patents.' Will NetApp effectively destroy any future ZFS might have enjoyed?"
What you say is true for LOCAL storage, but EtherDrives are NAS (Network Attached Storage) as mentioned in the summary.
This means they come preformatted, but the machines that access the storage are using Samba or Windows File Sharing or whatever to access it, so the client PCs do not see the filesystem on the NAS box.
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
We need a site to organise boycotts of companies that abuse the patent, trademark, or copyright system. Not everyone would need to sign on to all of them, but anyone should be able to post a call and explain their reasoning. If we got enough techies onto it who would use it at work, it could have some muscle.
For every problem, there is at least one solution that is simple, neat, and wrong.
It's still ongoing, naturally: Sun/Oracle has a page with updates on the case over the last few years.
Chu vi parolas Vikipedion?
See the second post in the recent thread on zfs-discuss: Legality and the future of zfs...
It doesn't sound as if Netapp has a leg to stand on, so they are trying to shake down the companies while they can. Where have we seen this before?
The Wikipedia article on NetApp talks about them bringing a suit against Sun/ZFS and that Sun countersued, but doesn't mention the verdict.
Read all about it (the story so far, as presented by Sun/Oracle): http://www.sun.com/lawsuit/zfs, which provides links to a number of legal documents and patents and rulings from the PTO.
Basically, the patent which was central to NetApp's claim of infringement was found not to apply to ZFS. A second patent asserted to be infringed was rejected on reexamination by the PTO, but NetApp is still squirming through the appeals process. The current round of threats could be NetApp's last gasp/whimper on the topic.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
ZFS isn't *essential* to Apple so why would they fight a patent battle in court? There's plenty of other file systems in the sea.
No sig today...
Much as I hate these patent cases, perhaps this one has merit. NetApp built it's bussiness being a vendor of NAS systems that had extensible file systems that spanned clever raid structures, and automatic snapshoting and they did this long before ZFS. Those are the key features of ZFS. And when you pair that with NAS, well that's a NetApp in a box. I dont know what NetApps patents claim but what they did was not obvious at the time and they are actively a seller of that, not a patent troll.
Some drink at the fountain of knowledge. Others just gargle.
Except that the courts and the patent office are saying otherwise in NetApp's case against Sun.
We should all have learned by now that how people and companies react to legal threats doesn't have ANYTHING to do with so-called merits. 'The' SCOX case went on for about seven years and they had NOTHING. People paid them "linux tax" while they had NOTHING, could show NOTHING, made increasingly bizarre and outrageous claims and could in fact never WIN ANYTHING. People still paid.
The lesson from that of course is that being a tick on the ass of the system it's a perfectly valid way to lift a nice salary and appear important, so really, why not?
Belief is the currency of delusion.
Sun already does indemnify it's customers. Schwartz pointed this out when NetApp's rumblings against Sun first happened.
First, the basics. Sun indemnifies all its customers against IP claims like this. That is, we've always protected our markets from trolls, so customers can continue to use ZFS without concern for spurious patent and copyright issues. We stand behind our innovation, and our customers.
ZFS is a game changer in the storage industry. While people are buying $250,000 NetApp installations, the exact same hardware, performance and connectivity will go for $5000 of high-end hardware and a couple of hours work with ZFS. $250,000 will easily buy you a Petabyte worth of redundant ZFS storage. Even the reasons you would otherwise buy NetApp or another proprietary storage solution (compression, de-duplication, checksums) is all implemented by ZFS.
NetApp recently lost their patents based on prior art (they basically ripped off somebody's paper and put in a patent for it), appealed it of course and now they are trying to squeeze the last money out of small shops before they get the smack down from the patent office. This is a very similar case to the Caldera/SCO cases.
Custom electronics and digital signage for your business: www.evcircuits.com
Even though btrfs isn't in production yet, we really need a successor to it not just to replace the filesystem, but to replace the LVM layer. ZFS isn't just a filesystem, but also goes one layer lower, coordinating RAID.
I wish I had the cash to make an open source (GPL or BSD license preferably) bounty for the following in a filesystem/LVM replacement, since ZFS isn't going to be going past Sun hardware these days:
1: Deduplication on the block level. This would be selectable because in some cases, there would be performance issues to it... but a good filesystem would stick heavily duplicated blocks on fast media (flash or inner cylinders).
2: 64 bit CRCs. This way, a backup program just has to pull from the filesystem stored CRCs and it would know which files have been changed or not. This also helps with integrity checking.
3: Compression. Selectable levels would be nice, from a fast zip based to bzip2 -v9.
4: Encryption, perhaps like EncFS where encrypted directories can be cattached at will. Even better would be more elaborate (public key, smart card) key management.
5: Block device encryption. It would be nice to install the OS, set a flag that all further writes will be encrypted to a key, then proceed to copy data to the machine. This way, the machine can get set up and (ab)used without waiting for disks to encrypt.
6: TRIM support. Enough said.
7: Ability to move data so one directory might be on a three-way mirror, while the rest of the filesystem sits on a RAID-Z equivalent. This way, critical documents are protected.
8: Advanced snapshotting functionality. It would be great to be able to restore a machine by booting from a USB flash drive or CD, having the filesystem be configured to the hard disks at hand, then copy from a stored image, regardless of architecture or setup of the previous machine's drives were. This way, a machine could be snapshotted, it be moved to a completely different configuration, then restored. A good example of a nice way to restore would be IBM's Sysback utility for AIX, where one can completely redefine where data resides before kicking off a restore.
9: Advanced attributes, where files can be flagged where if they are unlinked, the OS does a manual TRIM or multiple overwrite, and so on.
10: Automatic repair of damage. Starting with Windows Server 2008, Windows does a background check to look for damage in mounted NTFS filesystems. This way, something like missing free space or other issues can be flagged before it bites someone in the next bootup. For example, when a machine is idle, it will compare written 64 bit CRCs to what is on disk to ensure that they match, and flag nonmatching files as possibly corrupt.
11: Ability to add varying amounts of ECC to a filesystem. This way, the volume can take a lot of damage, but the files are highly likely to be still readable. A good example of this is Nero's SecureDisk, where it writes invisible ECC information to burned CDs/DVDs which can be used to piece together damaged files. This way, volumes that are stored for long term archiving can sustain damage, but there is a good chance of recovering the files, or at least knowing the files were damaged.
using WAFL on a nas is not any more inventive than using ZFS on a NAS. Again, the parent is correct.
Using any filesystem for a NAS is not inventive. It's been around for quite some time. They're also going after distributors rather than attack the ZFS patents they purportedly precede.
It's also quite impossible to prove any sort of patent violation for using ZFS on a NAS simply due to the competing software being patented.
If I use a product X, of which is infringing upon product y, I am not liable for uses of product X. The patent system doesn't support 3rd party liability. it's just distributors buckling under legal threats.
And if I understood correctly, were not the patents involved in the lawsuit mostly invalidate?
I know you've already replied that you misunderstood, but just in case anyone else is confused by this...
This is a NAS, which is itself a server. Support for the filesystem is built into the NAS box. The NAS box then exposes the data it stores on that filesystem to the network using network-appropriate protocols.
Anyone wanting to access it would use a networking standard like Samba, Windows File Sharing, FTP, or whatever services the NAS box allows.
Of course, they'd also access the management tools (nowadays generally a small web server also built into the NAS box).
None of the clients would need to support the underlying filesystem that the NAS box uses. In fact, they wouldn't even be allowed to know what that filesystem is.
Back when I had Windows boxes at home, they had absolutely no problems reading shares I made on my Linux box. The Linux box could be formatted ext, Reiser, or anything I wanted that Linux supported.
As long as I never tried to take a hard drive out of the Linux box and put it in the Windows box, of course. Then it becomes local storage, and Windows would have to support the filesystem in order to read it.
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
Sorry buddy but the courts have ruled that ZFS doesn't infringe NetApp's patents. Read here and here. Cry more.
Screw NetApp and their overpriced, underfeatured, patented crap. Really. I mean that.
I totally and completely agree with that summary of NetApp
With that out of the way, how does NetApp have any authority to enforce a license/patent on a piece of software they did not invent, nor hold the licensing for? ZFS was created by Sun and released under the CDDL. I am confused as to where NetApp fits into this equation other than being a troll of something that isn't even theirs to begin to troll with. I will do some digging online, but this is just effed up.
ZFS is not encumbered by asshattery any more than Linux is.
It's encumbered by a patent dispute
While Linux is encumbered by the SCO mess, which is basically the same thing, except related to copyrights and ownership of codes, rather than ownership of the whole concept of copy on write.
NetApp is suing Sun (and now Oracle) over ZFS because they *claim* it violates patents they hold that they implemented in their own WAFL fs. WAFL does predate ZFS. NetApp was granted patents in WAFL that ZFS seems to also do, but prior-art may have caused those patents to be invalid.
They are suing vendors that also use ZFS probably because those vendors are either licensing from Oracle (in which case indemnification may just pass this on) or are using FreeBSD, which makes the link between the vendor and Oracle a bit more odd and possible has the vendor on the hook for liability.
XML is like violence. If it doesn't solve the problem, use more.
It might be worth reading through NetApp's original ZFS patent lawsuit vs Sun before making wild speculations. It seems to me that they are now trying to sue other, smaller companies after their original attempt to sue Sun had failed.
You would be very, very wrong. Your use of an infringing product still makes you an infringer. (35 U.S.C. Sec. 271(a))("whoever without authority makes, uses, offers to sell, or sells any patented invention...). Now, there are default rules that say that a purchaser of a good is "indemnified" from claims of infringement by the seller. (See UCC Art. 2 Sec. 312) This is typically how end user avoid litigation.
In addition, you're also wrong to think that the patent system doesn't support third party liability. It does. One party's can be sued for another person's direct infringement. It's called "indirect infringement." (35 U.S.C. Sec. 271 (b) and(c)). The rules on when this apply are stated in the statute and are not always so easy to discern. One way to think about it: a party cannot escape liability by simply knowing moving the infringement downstream.
And, just so that you know, it is a somewhat common strategy that a patent owner sues the end user, direct infringer. There is nothing worse as a supplier than receiving about 30 letters from angry customers seeking indemnification from the infringement suit. This is a great technique to annoy the party with deep pockets and drive home the advantages of settling early.