Microsoft to Charge for FAT File System

pario writes "According to Microsoft, the Redmond company is going to charge a license fee for any product that is formatted in FAT by the manufacturer. Any manufacturer of compact flash memory cards or digital cameras may end up paying Microsoft as much as $250,000 for the use of the file format. The FAT File System is covered by several US patents."

The future?

Litigation: The Business Model of the Future!(TM)

(Disclaimer: The above statement is the intellectual property of Uberm00 Corp. and may not be used without prior written permission.)

re: the future?

isn't patent barratry a patented business process held by SCO? if so, i believe you're infringing upon their IP rights... :>

seriously though: this is an inducement for people to use other file systems. is NTFS similarly protected? if not, is this the objective of this move?

ed

Re: the future?

isn't patent barratry a patented business process held by SCO? if so, i believe you're infringing upon their IP rights... :>

Maybe Microsoft and SCO can be left to kill each other off...

Re: the future?

Well, with one difference. Microsoft (in this case) own and developped the technology they want to license. That should make a different between the two issues, don't you think so?

People have been apparently blinded by Open Source Software, if they thought they could use a proprietary technology freely.

For once, Microsoft is doing what they should do. And still, the slashdot community is bashing them. I guess it is hopeless then.

Re: the future?

People have been apparently blinded by Open Source Software, if they thought they could use a proprietary technology freely.

No, OSS people have been blinded by Megalosoft's 20+ year failure to enforce rights regarding FAT. It's an old tactic - introduce a feature, wait until it becomes a defacto standard, and *then* demand a pound of flesh.

Re: the future?

Aside from the fact that software patents in and of themselves should not be acknowledged as having any validity. Software after all is covered under copyright law, not patent law.

Microsoft has allowed the fat file system to propogate for free until becoming a standard, and now is slamming charges on it's use for everything that should grandfather this. Microsoft has every right to do it (again if you believe software patents are legitimate and therefore give right) but they shouldn't impose this on existing applications of the technology. Rather on whatever comes out of the gate from this day forth.

Besides that, the fat filesystem is only unique in the sense that it never occured to anyone to write a filesystem so blatantly weak and crippled.

I believe the real reason microsoft is doing this is because fat is the only filesystem which can easily be used to exchange data between windows and other operating systems.

Re: the future?

Even more reason to get ext2/3 drivers ported (and ported well) to Windows.

MS White Paper on FAT Contains Non-Sue Clause

http://www.microsoft.com/whdc/hwdev/download/hardw are/fatgen103.pdf [microsoft.com]

Just discovered this link in a comment over at Groklaw. Section 1.e. of this document would seem to indicate that MS has already granted the right to use FAT for hardware and operating systems:

(e) Each of the license and the covenant not to sue described above shall not extend to your use of any portion of the [FAT 32/VFAT] Specification for any purpose other than (a) to create portions of an operating system (i) only as necessary to adapt such operating system so that it can directly interact with a firmware implementation of the Extensible Firmware Initiative Specification v. 1.0 ("EFI Specificaation"); (ii) only as necessaary to emulate an implementation of the EFI Specification; and (b) to create firmware, applications, utilities, and/or drivers that will be used and/or licensed for only the following purposes: (i) to install, repair, and maintain hardware, firmware, and portions of operating system software which are utilized in the boot process; (ii) to provide to an operating system software runtime services that specified in the EFI Specification; (iii) to diagnose and correct failures in the hardware, firmware, or operating system software; (iv) to query for identification of a computer system (whether by serial numbers, asset tags, user or otherwise); (v) to perform inventory of a computer system; and (vi) to manufacture, install and setup any hardware, firmware or operating system software.

It doesn't seem like they could actually sue anyone for using FAT under this covenant, which is copyrighted 2000.

Re: the future?

yes NTFS is indeed covered under many patents and trademarks.

the format has not fully been determined, nor has it been fully released by MS. ...as witnessed by the article yesterday on using windoze DLLs in *NIX to get write access to NTFS media...

Re: the future?

You say, NTFS not fully documented. But then you say patents?

(I'm not disputing your assertions, btw.)

Now correct me if wrong, but isn't a requirement to get a patent that you disclose EVERYTHING necessary so that a person "skilled in the art" can recreate the patented work? If such a patent exists, then wouldn't (shouldn't?) it have everything necessary to make a Linux NTFS driver work?

Re: the future?

Educated guess: The patents cover methods and algorithms, not the particulars of NTFS implementation.

So someone "skilled in the art" could create a filesystem using the techniques in NTFS described by the MS patents, but this wouldn't necessarily be compatible with NTFS.

Re: the future?

...but isn't a requirement to get a patent that you disclose EVERYTHING necessary...

Maybe in theory, but it's not like the patent guys have time to verify complete documentation by sitting down and re-implementing each and every application using only the applicant's docs. Considering the way the patent system has been bent, folded, spindled, and mutilated in recent years (e.g., Amazon's one-click, Netflix's business model), less-than-complete disclosure starts to look like the least of the patent office's worries.

Re: the future?

Patents require disclosure of everything necessary for a skilled person to recreate the invention.

But, NTFS uses several inventions, and some code to tie them all together. Whereas you should be able to determine all the patentable bits, it may be REALLY tough to figure out all the details.

I read the Sorenson video codec patents once, to see how they encode video. It was a nearly useless endeavor.

Re: the future?

Your not exactly wrong, but...

Not everything inside NTFS is patented. A patent for a "means to store a filename in an inode" doesn't tell you a whole lot about anything.

Once again, look to abuse by the patent system. Patents and Copyright were supposed to superceed trade secrets. Either Or, was supposed to be a choice you had to make. Now you can use both, thus the entire point of the patent system has been corrupted.

Patents were supposed to cover "inventions", not mear discoveries or things that could be produced by anyone skilled in the art as a matter of need. Thus something like NTFS may be subject to patent, and thus made available to the public at the end of the term. But, again, the system has been corrupted such that one NEVER patents the invention itself, but as many individual acts of routine as possible. Thus, your "invention" remains opaque and your "patents" can cover all sorts of routine.

FAT is a "filesystem" that any not-so-good programmer might throw together if so asked to store files. It is hardly an "invention" under the intent of the patent system.

Imagine the Light bulb. Prior, nothing even remotely like it was in existed. That's an invention. Putting a metal base on it, using blue glass, or shaping it like a christmas tree bulb is not (well, was never supposed to be). Those little improvements are somthing anyone skilled in the art of glassblowing would take for granted.

Re: the future?

While these formats might work out OK, they certainly aren't optimized for small hard drives the way that fat is. More importantly, perhaps, Windows can't read them without extra drivers, so one could easily argue this is just Microsoft taking advantage of their monopoly status: have an OS that only reads file systems patented by themselves. How convenient.

Re: the future?

Not optimized for small drives. Okay, then for small media, maybe we should look elsewhere. What format did CP/M use?

Another point is: please define "small" media. When FAT was invented and optimized for small media, the definition of "small" was 360K floppy disks. FAT was unsuitable for a Big Hard Di_k of 2 GB or more. So is a 256 MB flash card really "small" media? Isn't, say ext3 suitable for such a "small" media? It seems to me like that that long ago people talked up how you could install Linux on older systems with tiny hard disks that are smaller than some flash memory cards.

Re: the future?

The *only* nice thing about FAT is that all the Windows machines in the world can read it without installing drivers.

More important is that every electronic gizmo taking flash memory cards (digital cameras and MP3 players) can read/write it without installing drivers!

Because although installing a filesystem driver may be painful on Win98, it's one thousand times worse on solid-state electronics.

Re: the future?

...The *only* nice thing about FAT is that all the Windows machines in the world can read it without installing drivers...

Yes, but how hard is it to implement a windows DLL which allows reading ext2 (for example)? At http://uranus.it.swin.edu.au/~jn/linux/explore2fs. htm [swin.edu.au] there is such a program. Have whatever program/DLL included with the digital device install program. End of problem and paying M$ royalties. After all, ext2 is fully documented and (to the best of my knowledge) patent free.

And for those who will claim, "But that is an extra step!": Yes, but the drivers only need be installed once, and the ability to save about $250,000 per license term (a year maybe???) will be hard to resist for manufacturers. I've seen manufacturers skimp on things which cost a lot less.

Re: the future?

The *only* nice thing about FAT is that all the Windows machines in the world can read it without installing drivers.

More important is that every electronic gizmo taking flash memory cards (digital cameras and MP3 players) can read/write it without installing drivers!

Because although installing a filesystem driver may be painful on Win98, it's one thousand times worse on solid-state electronics.

It's a chicken and egg thing - the cameras are designed to use FAT because they're made to interface with Windows machines.

MS isn't going after Sony for the cameras they made yesterday, they're gunning for license fees for cameras they are *going* to build.

The cameras don't talk to each other, so it won't matter if the camera I buy next year doesn't speak FAT. Unfortunately, no other filesystem is as well supported on the desktop as FAT.

Re:But isn't this a circular argument?

>So now that you'll either not "have a positive experience or put[s] a
>lot of pressure on [y]our support systems" trying to install a digital
>camera or flash media under Windows, do you think that Microsoft will
>have to drop their desktop distribution?

This fear of "negative experience" will cause the camera vendor to bend over and pay the license fee, because they (rightly) fear their customers are not capable of installing extra drivers.

Re: the future?

the cameras are designed to use FAT because they're made to interface with Windows machines.

Once, but not any more. Originally cameras used FAT for Windows compatibility (Even though it wasn't really needed back then... at that time, consumers needed new drivers to recognize flashcards, so they could've installed a new filesystem at the same time). But today, cameras need to be compatible not only with Windows desktops, but also other digital cameras, media on store shelves, Kodak photo-kiosks.

MS isn't going after Sony for the cameras they made yesterday, they're gunning for license fees for cameras they are *going* to build.

That's painfully obvious, and changes nothing.

The cameras don't talk to each other, so it won't matter if the camera I buy next year doesn't speak FAT.

Oh really? You've never moved a memcard from one camera to another? You don't enjoy the convenience of tearing an SD Card out of its package and immediately jamming it into your camera, without reformating it first? (Which would erase any data already on the card)

It is precisely because all current digital cameras use FAT that future cameras will need to- otherwise, those future cameras will be at a competitive disadvantage because sticking a memory-card into them doesn't "just work".

From a domineering-industrialist standpoint, Microsoft has played this very well: they allowed FAT support to seem free long enough for all digital cameras to use it, even though initially filesystem didn't matter. Now that the manufacturers are addicted, they can start to bring up the price. A textbook submarine patent.

Re: And it's not just digital cameras either...

I'd be willing to buy a digital camera that's just a little less convenient in order to take this and rub it in Billy's face.

Admirable. And non-representative of the typical consumer's response.

PS. Slashdot had better not allow editing of posts. That's inimical to a threaded message system. You can't have a coherent discussion if the comment you were replying to can be totally redone, leaving a response floating after it that now seems irrelevant.

If editing is allowed, it should always leave an option to see the earlier version(s)... and if someone responds to the pre-editing version of the post, then that version should be the default one displayed (With a small link going to the new version).

The first thing Slashdot should do to modernize its comment system is to create an official way to quote the preceding message, instead of relying users to manually paste it and insert italic tags.

Re: the future?

I believe that to save money, eventually we'll see devices use a patent-free filesystem. If necessary, to read their media on Windows, they will install a filesystem driver into Windows. Assuming that doing so is cheaper than licensing Microsoft's filesystem. Depending on the license cost, it may well turn out that Microsoft is the one who ends up having to support other filesystems for compatibility.

Re: the future?

While these formats might work out OK, they certainly aren't optimized for small hard drives the way that fat is.

Uhhh, neither is FAT.

FAT has fixed size directory indexes. If you have half a dozen files in a directory, you are discarding most of the directory index. If you make the directory index small then you can't store lots of files in a single directory. It's a no-win tradeoff. A space efficient filesystem would use dynamically resizable directory indexes.

The FAT itself is a bitmap (one FAT entry for every single block) with each entry referencing the next entry (like a linked list). You find the first block of the file from the directory index. Imagine how inefficient this is when the file has contiguous blocks. Why not use extents? That would greatly reduce the space requirements for the FAT.

The original FAT16 limited you to only 65536 possible block numbers. If you have a 512MB USB key then that means every block is 8kB. So on average you waste 4kB per file; 1000s of files means many megabytes of wasted space. Another glaring example of FAT inefficiency. A space efficient filesystem would offer variable sized blocks.

For FAT to perform efficiently you must load the entire FAT into memory (otherwise traversing the list of blocks is a nightmare of head seeks). This makes it vulnerable to files being corrupted or lost if there is sudden power failure or the disk is removed. The "saving grace" is that the FAT is protected because it never had the chance to be flushed out of RAM, so the filesystem is at least consistent. Whether this behaviour is good or bad seems to be a matter of debate; my opinion is that the data is more important than the damn filesystem and FAT fails in that regard.

The only thing FAT has going for it is incredible simplicity which made sense on the woefully underpowered and underfeatured IBM PC of 1980. But in terms of efficiency it is exactly the same as many other bitmap-based filesystems. FAT was also heavily optimised for 320kB (that's not a typo) floppy disks because the FAT would fit into a single 512 byte sector. It makes no sense in a modern world with gigabyte removable media.

These USB keys should be using something clever like CRAMFS but with journalling and "balanced writes" (each block gets roughly equal write time) to preserve the life of the key.

And the mac...

Mac's HFS and HFS+ are another alternative. There's PC (pay) software to read them already in at least 3 flavors, and I believe Linux supports them, too. Of course, these may be covered by Apple patents.

Of course, this might explain why it's such a bitch to format to FAT on a OS X Mac....

Re: the future?

Yep, if killing the FAT file system isn't the objective, it will be the result. It's probably aimed at preventing Linux interoperability with Windows machines. I don't know how that will play out, in court or otherwise, but if MS has patents on FAT, then presumably they may want, or be able, to prevent people from distributing free code to access FAT files systems.

Certainly, any company using FAT for its products will switch to a different file system. SCO may want to sue MS for infringing on its patented "Cock Pistol, Shoot Foot" algorithm.

Overall, I kind of think it might be a good thing that MS is doing this. It provides yet another reason for tech companies to consider embedded Linux for their devices. And the more prevalent Linux becomes in that sector, a) the sooner Linux driver support will improve, and b) the more home users will consider Linux.

Linux & FreeDOS Compatibility

Responsding to myself, but this just occurred to me: I wonder how this will affect the FreeDOS project. My first guess would be that they'll have to rewrite the project to use ext2 or some other file system.

Software patents have been commonly regarded as the "nukes" of the software world. I'm beginning to think that MS has decided it has nothing to lose by going nuclear on the free software world.

Re:Linux & FreeDOS Compatibility

I don't think so. Programs that use the FAT filesystem have been out there for several coon's ages or the age of a really old coon.

FreeDOS does not distribute in the FAT filesystem, interestingly: the official distribution is a CD-ROM ISO image only. They also don't distribute product or media preformatted with FAT. I don't even think Microsoft is going after programs that can create a FAT filesystem, so FreeDOS can format a hard disk and you're good to go.

However, I wouldn't mind if they did make it ext2. If you're booting with FreeDOS, it doesn't really matter what the filesystem is. Just allow reading of FAT partitions and floppies, and you can copy over all the old DOS software you wanted to run. Might be a few bugs here and there, but I guess when Microsoft wants to play rough, you just get out of the way.

Re:How long do patents last?

The Microsoft article pointed to by the story claimed that the first version of the FAT file system appeared in 1976. Any 1976 patent has, as you say, expired.

But the FAT design was such a half-assed pile of crap that it became obsolete very quickly, and Microsoft patched it up several times. Presumably, they patented the fixes.

It is difficult to understand how even the notoriously permissive US Patent Office could grant a patent to something as far behind the state of the art as the FAT file system. Its only original features were steps backwards from the state of the art. Not only the Unix filesystem, but several proprietary minicomputer filesystems which have since died, were significantly better than the FAT filesystem.

Re:How long do patents last?

Kind of a moot point. The patents MS lists in the notice are related to FAT 32, which is easily the most widely used implemetation of FAT now. FAT 16 only supports up to 2GB, whereas FAT 32 supports 32GB. Anyone who sets up a FAT partition on a dual-boot system as a common file storage area will be using FAT 32.

Those patents were granted in the mid-90's, and short of invalidating them via prior art claims, they won't expire for another ten years or so.

Re: the future?

Ok, I'll bite. IMHO, NTFS is about as different from FAT as any Real file system.

FAT is very simplistic, there's essentially two structures. One is the File Allocation Table, which keeps track of which blocks are used in what way (e.g. part of a file, last block in a file, bad block, free block). Then there are the directories, which are just arrays of inodes, which also contain the file names. The inode points to the first block, the FAT tells which blocks follow. There are no permissions, hard links, symlinks, file types (other than regular vs. directory). The FAT and root directory are stored at the beginning of the volume.

Now to NTFS. (Disclaimer: NTFS is complex and I don't claim to fully understand it.) NTFS Has a Master File Table, which has inodes for every file on the volume (which are seperate from filenames, like on Unix file systems). NTFS supports hard links, symlins, attributes, permissions (based on Access Control Lists), and sparse files. File names are looked up in b-trees rather than sequential lists. Instead of listing every single block occupied by a file, it uses start, length pairs (AKA extents). NTFS uses journaling and supports transparent compression and encryption. Several structures are stored in the middle of the volume to minimize seek times.

Compare this to traditional Unix file systems (UFS, FFS, ext2). There's an inode table at the beginning of the volume. Inodes encode ownership, permissions (based on owner and group), a few attributes (e.g. setid bits), often part of the block list or the content of the file. Directories are sequential lists of (inode number, file name) pairs. Hard links and symlinks are supported, as are special files like devices and FIFOs. No extended attributes, no B-trees, no ACLs, no compression, no encryption, no journaling. (although many/all of these have been added at one point or another to ext2 and FFS, sometimes preserving compatibility). Important structures are replicated in various parts of the volume to enhance speed and reliability.

As you can see, NTFS is a very advanced filesystem, supporting many features that Linux filesystems are now beginning to have. FAT is hardly any more advanced than the very minimum required to store and retrieve data. Unix filesystems are somewhere in between, supporting features important to Unix systems such as permissions and device nodes, while at the same time keeping it simple. Personally, I think a the traditional Unix filesystems are much closer to FAT than NTFS is.

Re: the future?

You obviously don't know anything about modern Unix systems. Directories have not been sequential lists in a LONG time. Get your head out of the sand. B-trees and lots of other data structures have been used before Mr Bill started working on DOS!

To be honest I think the abilities of NTFS and current Unix files systems are about equal.

And I would very much like to know how to convince stupid Windows to make one of those "symbolic links". I have NEVER seen this work (by "work" I mean that when I call open() and read, I get the contents of the pointed-to file, not gibberish!)

Re: the future?

As you can see, NTFS is a very advanced filesystem, supporting many features that Linux filesystems are now beginning to have.

You are confusing feature bloat with being advanced. NTFS is a feature-bloated file system, but none of the features they crammed into that file system are anything new, and many of them will never make it into mainstream UNIX file systems because they are just not a good engineering tradeoff.

Compare this to traditional Unix file systems (UFS, FFS, ext2).

Your comments imply an incorrect timeline. By the time NTFS came out, there were already several UNIX file systems with a comparable feature set. Furthermore, a number of key NTFS features existed in name only for several years, until Microsoft finally got around to implementing them.

Re:FAT Chance!

I wasn't trying to be funny, I was serious. It is however funny that you thought, that I thought, that it was funny....

Re:FAT Chance!

Not true. Many embedded devices could use FAT with no "standard interface" for you to know about it.

For example, I have a digital multitrack recording studio with an embedded 20GB IDE HDD. It just happens to be formatted FAT32. I know this because the manufacturer was polite enough to sell a USB add-in card for me to connect the device to a PC or MAC for importing/exporting tracks.

Now, had the manufacturer chosen not to offer a USB port...and only allowed me to import/export tracks via the built-in CD-ROM burner, they could've still used FAT32 for the internal HDD format, and I'd have no way of knowing without cracking the thing open and plugging the HDD into a PC.

I'm certain any manufacturer of embedded products could use FAT32 for embedded drive formats, but use some kind of reverse-engineering crap in the DMCA to prohibit you from knowing it's FAT32.

Re:FAT Chance!

But a real point is...if you can't tell that they're using FAT, then they could use ext2 (journalling doesn't seem appropriate) or something else.

OTOH, if they can depend on this being a one-time charge, it's probably cheaper for them to pay the extortion than to convert.

Re:FAT Chance!

if they can depend on this being a one-time charge...

Well, with Microsoft involved, what you can depend on is an area of concern in my mind.

And if you can't tell what they're using, ext2 or any number of filesystems may be usable. But, if you're a manufacturer selling through a channel, you may want to offer diagnostic and repair licenses to resellers. FAT32 may be a better choice merely for the simplicity of unplugging the drive from the device and plugging it into a PC that will in most cases be running Windows for diagnostic/repair work. And it is likely perceived as easier by the manufacturer to train certified repair shops on Windows-based tools as opposed to Linux ones.

Re:FAT Chance!

Insightful? How about retarded? How else can you write a post directly contrary to all evidence?

A product using ext3 wouldn't have to be open sourced, any more than a product running on Linux. Any changes made to the filesystem would, but it's highly unlikely that you're going to have so grand an idea for a filesystem that your product hinges on it, and then have to implement it on top of someone else's filesystem.

Besides, using GPLed components basically prevents patent issues. By intentionally releasing something that requires you to agree that it is patent encumbered you pretty much give implicit free licenses to any patents that you may have on that code. Otherwise you didn't honor the contract you entered into with the original author of the software.

What would you prefer? Having to open source some tiny filesystem component you added to ext3, or having to pay Microsoft up to $250,000?

Re:FAT Chance!

The purpose of the DMCA is for situations like Adobe's ebook, where if someone cracks the encryption they'd get free ebooks. In that situation the DMCA is a Good Thing. Coporations can't use the DMCA to cover up illegal activity or to stifle competition

Prohibiting the creation of Free Software PDF readers is undeniably stifling competition.

Re:FAT Chance!

I'm still wondering how this will affect the Linux kernel, since it has support for FAT file systems. I wonder if Linux is going to have to drop the support, of if we'll be able to slip in under the "interoperability" loophole.

That's easy. Red Hat will not include the precomiled module in their binary kernel packages, but 40 new sites will pop up with incompatible RPMs of the module for various kernels. Debian will probably move it to a separate set of packages in non-free or non-US. Mandrake and Suse will do fuck-all, since they're in Europe. Gentoo users will say 'what's a binary package?' and continue compiling it into their kernels. Slackware users will say 'tgz kicks ass, dependencies are teh sux0r.'

;)

Re:FAT Chance!

Except, the linked webpage clearly states:

"Microsoft's FAT file system license offers limited rights to issued and pending Microsoft patents on FAT file system technology, as well as rights to implement the Microsoft FAT file system specification."

It appears that Microsoft is selling a liscense to implement their filesystem. However, the liscense is for manufacturers of consumer electronics and removable media. It's unclear, based on my lack of knowledge of this legal area and the ambiguity of this document, whether (e.g.) writers of software targeting non-consumer electronics products (such as personal computers) would need to approach Microsoft for liscensing.

However, the patents all have to do with VFAT long filenames. Thus, it appears that a manufacturer may only have to refuse to deal with anything other than valid 8.3 filenames to avoid the patent liscensing hassle. I don't know how Microsoft could claim to enforce a restriction on implementing anything on FAT that's not patented; I don't believe they can, under US law, but like I said, I have a very incomplete understanding of US law in this respect.

Re:The future?

Litigation: The Business Model of the Future!(TM)

What do you mean of the 'future'? suing has been the new GOLD RUSH for some time now.

Re:The future?

But on a serious note: I thought that if one didn't vigersously enforce a pattent then after a while as the idea covered in the pattent has been in whide use then that pattent is legally in the public domain. besides don't pattents expire after 17 years ? and Hasn't FAT been around since the early 80's ? Its pattent has surely run out by now.

Microsoft's licensing agreement lists 4 patents that it covers. All were filed since 1992, and all were granted within the last 8 years or so.

However... if you look at the materials patented, all refer to long file name support. ("Method and system for accessing a file using file names having different file name formats," "Common name space for long and short file names," etc.) If one develops a device that utilizes FAT without using long file names, I'd imagine that they'd be safe.

Re:The future?

So, like the gold rushes, it will be a huge waste of time and money for almost everyone involved?

Re:The future?

Litigation: The Business Model of the Future!(TM)

For a failing economy, in a country that has no prospects for true innovation due to its self-imposed corporate protection measures.

Patents WERE put in place

That was the intent, and I suspect to some extent it still works that way. But I suspect that there's far more happening of a different sort with patents - and that's the creation of a club. Remember the phrase, "stand on the shoulders of giants?" Well, the shoulders are patented. If you want to stand on those shoulders and reach higher, you have to let the giant reach that high, too.

In essence, patents have created a club, and while you can still get a patent and make money, you probably can't disrupt an existing technology, because you need to license existing technology to make your patent work, and the most likely license term is to cross-license your technology back to the would-be disruptees. They can either take advantage of the technology, or you'll find that the license prevents you from disrupting their business - unless you're excessively lucky.

I recently heard about a guy with some sort of chemical/drug/food (forget which) patent that's running out. NONE of the industry has agreed to license it, they're just waiting for it to expire. In the meantime he's losing all of his development and attempted marketing money. Maybe he was asking absurd terms, maybe he deserved them, but the industry felt we could get along without the new product, the guy couldn't commercialize without more money than he had, so they could afford to wait.

Come to think of it, I've got a friend in the very same situation.

Re:FAT and CP/M and DR DOS Prior Art

It's not an issue that a clean-room implementation would fix. The patent in question isn't on the code, but rather on the file format. Remember all the shit that Compuserve put people through over the GIF file format? This would be similar. Microsoft is saying "Hey! We should be making money off that!". I don't know what this means for FreeDOS, PC-DOS, syslinux-based boot disks etc, but it can't be good...

Re:FAT and CP/M and DR DOS Prior Art

The GIF file format isn't patented. You can't have a patent on file formats, the order of fields in a sector, etc. There is nothing innovative in that.

The hardware process of the LZW compression algorithm was what as patented. You can write GIF files without using compression (literal, clear dictionary, literal, clear dictionary ... instead of following the compression algorithm.

Here, Microsoft's patents relate to algorithms for fitting long filenames onto a file system that only supports short filenames. They do NOT have a patent on the (V)FAT filing system. However, in working with those filing systems you may need to use algorithms which Microsoft managed to patent.

Re:FAT and CP/M and DR DOS Prior Art

Here, Microsoft's patents relate to algorithms for fitting long filenames onto a file system that only supports short filenames.

Innn-teresting...
Do the Rock Ridge extensions for ISO 9660 count as prior art?

Re:FAT and CP/M and DR DOS Prior Art

Let me remind you, this is the kind of B.S. that can happen when you rely on proprietary software (I'm guessing that FreeDOS and friends do rely on MS standards in order to maintain compatibility with MS-DOS programs). Someone can pull the rug right out from under you whenever they want to.

So MS is going to nickle and dime people to death. Who would have guessed...

Going up...

Gotta love submarine patents.

Is there a win32 ext2/3 filesystem driver out there anywhere?

Re:Going up...

Is there a win32 ext2/3 filesystem driver out there anywhere?

Searching for "win32 ext2" yields this [swin.edu.au] as the first link.

Read AND write ext2 on wondpws

There's always: http://sys.xiloo.com/ [xiloo.com]

Which seems a bit improved on the very useful expore2fs.

I want NATIVE file system integration, VFS is NOT DEEP ENOUGH.

http://sys.xiloo.com/

Sam

That's not a driver

That's not an NT file-system driver, it's just a program that can read files and looks like Explorer. A proper driver is an NT IFS (installable file-system) driver, like this [partition-manager.com] one.

Re:Going up...

This one isn't really submarine --- They created FAT in 1976, according to the microsoft.com page ... but the earliest patent was filed in 1995.

We need a public domain minuxfs implementation now, to be the standard.

Something must have been updated...

This one isn't really submarine --- They created FAT in 1976, according to the microsoft.com page ... but the earliest patent was filed in 1995.

That can't possibly be right. In the US (but nowhere else) you have a 1 year's grace period from the time of publishing an invention such that you are still allowed to patent it. Even with the USPTO's track record (!!) I honestly can't see them granting a patent based just on 1976 technology. MS must have included new ideas... or something like that.

Re:Something must have been updated...

yeah they added "over the internet" somewhere.

Tom

The abstract from the earliest cited patent:

Just to follow up, the first patent that MS list as protecting FAT (US5,579,517) has this as the abstract:

An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.

Do these devices really need compatibility with "dead" operating systems?

The second patent seems to another concerning filename formats. I haven't bothered to look at the other 2.

Demise of FAT

"Personally I think MS is simply trying to quicken the demise of FAT so they can drop it quicker. About time, too -- there's simply no need for it anymore."

I respectfully disagree. OSX, OS9, Linux, BSD, and almost any other OS that you can think of can read and write FAT. Any device that is to be cross-platform compatible with read/write works very well with FAT. The only other filesystem that I know of that these all read and write is ISO9660, which last time I checked didn't include long filename support without Microsoft Joliet extensions or some other after-spec hack anyway.

Microsoft isn't going to support a filesystem that makes it easier to use devices on a competitor's platform, plain and simple. OS implementers have had to reverse engineer Microsoft's ways of doing things for a long time, and if Microsoft is allowed to litigate FAT out of use, they'll use it to try to force everyone else out.

They're talking about things like long filenames..

The problem with it is, their implementation of long filenames for FAT was in the hands of people outside of Microsoft well before the one-year prior drop-dead date for the application. Before it was Windows 95, it was codenamed Chicago and it was available to ISV's beginning of 1994 (as in it was available to developers outside of the company BEFORE April 24 1994...) - I know, I was part of that beta program. It does not matter WHAT you have with those people in the way of non-disclosure, they're customers and the moment you put an improvement in the hands of anyone outside of your company, the clock on the filing date starts ticking because you've revealed it to the world as far as the law is concerned.

The first patent, at least, is invalid by their OWN prior art.

ext2 for Windows

http://ext2.yeah.net [yeah.net]

Re:Published in BYTE in 1980 or so

If you looked it up, [uspto.gov] you'd see that the patents listed on microsoft's page are not for FAT itself, but for long filename extensions to it.

The patents listed were filed in '92, 95, 96, and 97. I haven't looked into the details of the patents, but I assume the date those features were published would be during the mareting of windows 95, so the first 2 at the very least are within the 1 year publish-file grace period.

Dammit, more Linux impact

Is there a win32 ext2/3 filesystem driver out there anywhere?

Forget that -- there is FAT code in the Linux kernel. More IP that smacks Linux and means that it cannot be distributed (and interoperate with windows, as FAT-based systems were the only major filesystem that both Linux and Windows can read and write out-of-box. Very bad juju.

FWIW, it is *damned* hard to write Windows filesystem drivers -- compare a small Linux filesystem -- RAMFS, at 342 lines of source -- with even a minimal Windows driver. There is an ext2 implementation with read support, though.

Oh, yes. The embedded community uses FAT all over the place. They are going to absolutely go bonkers when this hits the news.

Re:Dammit, more Linux impact

As I read the license options, this applies only to devices that come pre-formatted as FAT. No mention of software. Limiting the ability of others to write FAT-compatible software would be a bad strategic move on MS's part - anyone who currently has another OS interoperating with Windows via FAT may be just as likely to ditch Windows as they are the "other" OS.

Re:Dammit, more Linux impact

I'm not attacking you personally, but why is Slashdot's reaction to this sort of thing always "host it outside the U.S." or similarly sneaky tactic?

First, this issue involves DEVICES, not code. The Linux kernel doesn't appear to be at risk at all, just embedded systems. Bear in mind, of course, that these systems knowningly used a system that's copyrighted and patented. Microsoft needs to defend this patent lest they lose it. Second, the best solution to this sort of thing is to fight by the rules. If Microsoft suddenly decides to kill interoperability with thier own systems, that's fine - a lot of people would ditch Windows for Linux. Probably as many as would ditch Linux for Windows. Just yank the code from the kernel and go about your business while Microsoft loses more dual-boots to nix-only boots.

Part of the beauty of OSS is that it's a lot easier for it to lose ground on servers or desktops or whatever than it is for a corp to do the same. It hurts Microsoft a lot more to lose a Fortune 500 company to Linux than it is for Linux to lose one to Windows. Microsoft loses face AND money, we just lose a little face and go about our business - usually, nobody loses any significant money (except the sucker that switched to Windows :p ). There are far fewer people with big stakes in OSS, and, fortunately, the folks that have their fingers in it (Novell, IBM, etc.) will be willing to go to bat for it to protect themselves. Just go about your business. Microsoft is hanging themselves slowly. If we keep doing what we've been for the last several years and stay vigilant, we'll come out on top.

Dammit, would people stop saying this?

"Microsoft needs to defend this patent lest they lose it."

You're confusing Trademark law with Patent law; Trademarks must be defended lest they be abandoned, patents can be enforced against some, all, or none of those infringing on the patent at the patent-holder's whim. The entire practice of "defensive patents" rests on this.

The Patents don't specify devices or software.

A Patent, in and of itself, doesn't care about those things. So, in actuality, Microsoft could ask for royalties on each and every Patent on this list and legitmately so unless each are invalidated or your implementation is somehow found to not infringe.

Let's go over the Patents one by one, shall we?

5,579,517 - Common name space for long and short filenames. Filed for on April 24, 1995. This one only impacts you if you're using a Common Name Space for long and short filenames. Basically, the scheme they deployed for Chicago- references a preferred embodiment for MS-Dos 5.0 that was apparently handed to the USPTO as part of the application. Very much likely to be invalidated, though, by their OWN prior art release of Chicago to the world in December of 1993. This describes a scheme for handling long and short filenames correctly. If it's not invalidated, you might run afoul of it trying to do a VFAT type implementation.

5,745,902 - Method and system for accessing a file using file names having different file name formats. Filed for on July 6, 1992. Reading the abstract of this one, you'd have to allow renaming of just the name and preserving the extention for the purposes of keeping track of the filetype. Abstract explicitly mentions the use of a B-tree (Limits the scope of what they're claiming- you can possibly sidestep things by using red-black, AVL, etc...). They don't appear to have troubled this application with a possible prior art release, but unless you're doing the exact same thing for handling renames, etc. I don't think you're impacted by this one.

5,758,352 - Common name space for long and short filenames. Filed on September 5, 1996. A cursory reading of the Patent filing made by Microsoft leads one to believe that this is a re-application of the 5,579,517 Patent. While I'm not an IP lawyer, they appear to be claiming the same basic things in both documents. If this, in fact, the case, the 5,579,517 Patent's invalidation would likely invalidate this one. You would probably run afoul of this Patent if you attempted to implement a VFAT style filesystem.

6,286,013 - Method and system for providing a common name space for long and short file names in an operating system. Filed on January 28, 1997. This one is an EXPLICIT Patent-style description of how Windows 95/98/Me handles long filenames on an x86-32 platform. Cute. The applicablity of this Patent to anything other than an exact clone of Windows 95/98/Me is doubtful at best. They explicitly mention things like BIOS interrupts and x86 register names in their claims. Better yet, the preferred implementation was deployed to the World at large in Windows 95- TWO YEARS PRIOR to the filing date.

You should consult a Patent attorney before making any decisions regarding this request for royalties from Microsoft. However, having said this, I'd feel fairly comfortable about the situation overall based on the observations made above.

No problem for embedded uses

As long as they don't use both long and short filenames in their implementation, they won't violate those patents. At least that's what the abstracts make me believe. See my other post [slashdot.org], where I put the abstracts.

Re:Ximian next.

When you look at the bigger picture, it sure doesn't look like there's any growth left in the company. For me, the telling signs were:

1) first put up when Microsoft started mentioning the word "Linux". They don't do that normally since it validates the product.

2) when they started mentioning it in their financial statements.

3) when LAMP took away most of the MS Windows server growth.

4) more and more mentioning of the word "Linux" by Bill and Steve.

5) recently when Prudentials financial analysts start asking about Microsoft Windows growth prospects against Linux and Linux desktop growth.

6) Microsoft trying to pedal it's patents for $$$.

It may not be visible as a death spiral but it sure looks like there is a massive amount of "concern" in Redmond. And with all of their profits in the OS and office applications, they have nothing but cash to help them get out of this. Even giving away their software will not KILL Linux. It would only slow it down momentarily and they know this. IMHO.

There is concern in Redmond. You can be sure of that. Is the Coriolis Effect in action here? There's probably some movement already and there is no sign of an opposing force. Surely, not this patent claim.

LoB

For your delight: the patents

It's not like they provide very much information, but here are the patent abstracts, plus links to the full patents. They sure don't seem interesting, and they all seem to deal with the coexistence of long and short filenames. All of this wouldn't be patentable in Europe.

United States Patent 5,579,517 [uspto.gov]
Reynolds , et al. November 26, 1996
Common name space for long and short filenames

Abstract

An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.

United States Patent 5,745,902 [uspto.gov]
Miller , et al. April 28, 1998
Method and system for accessing a file using file names having different file name formats

Abstract

A multiple file name referencing system stores multiple file names in a file. These multiple file names include an operating system formatted file name and an application formatted file name. When an operating system formatted file name is created or renamed, the multiple file name referencing system automatically generates an application formatted file name having a potentially different format from, but preserving the extension of, the operating system formatted name. The multiple file name referencing system similarly generates an operating system formatted name upon creation or renaming of an application formatted name. A B-tree is provided which contains an operating system entry for the operating system formatted name and an application entry for the application formatted name, each entry containing the address of the same file to which both names refer. The multiple file name referencing system converts the operating system formatted file name to the application formatted file name by accessing the B-tree with reference to the operating system entry, and vice versa. As a result, either file name can be used to directly reference the file without requiring additional file name translation.

United States Patent 5,758,352 [uspto.gov]
Reynolds , et al. May 26, 1998
Common name space for long and short filenames

Abstract

An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.

United States Patent 6,286,013 [uspto.gov]

Selling unformatted

What if you just sell the cards and usb sticks unformatted and have it formatted under windows? That way you could evade this kind extortion?

Re:Selling unformatted

Presumably so - they are using the FAT technology, and hence would need to license the IP. It's not that bad, actually - if you follow the link, you'll see that the license fee is only $0.25 per unit, up to a max of $250,000 per licensee. Rather than a lucrative money grab, this looks like they're establishing a precedent for other licensing opportunities, such as (perhaps) 3rd party hardware/software that uses Microsoft file formats.

Re:Selling unformatted

if you follow the link, you'll see that the license fee is only $0.25 per unit, up to a max of $250,000 per licensee

I've been party to meetings and technical design exercises where we struggled to remove mere pennies from the build price of a product, and were elated when we managed to do so. 25 cents is a huge cost delta for the build price of a piece of hardware.

Re:Selling unformatted

I think that might be the point that Microsoft is trying to make manufacturers use... Basically, force people to use Windows, otherwise they won't be able to format the memory in question.

Re:Selling unformatted

I doubt it. Devices can be just as easily used in other OSs with other filesystems.

And the "buy it blank and format it yourself" theory only works for things like USB drives. It's not as easy to format other devices -- like a PDA or any other device that has to come with some amount of software already installed.

Why Windows?

Disclaimer: I've worked with the FAT12, FAT16 filesystems in assembly language.

FAT is relatively well documented. IIRC, one can already format a FAT filesystem from Linux, and even if they can't, writing the drivers wouldn't take long.

But why would you use FAT in the first place? It's a very inefficient filesystem, built for ancient hardware.

Since static memory sticks have no problems with random access, it doesn't make sense to use traditional filesystems which were designed to minimize seek latency involving mechanical components. In fact, due to the block access factor, most filesystems are very inefficient when it comes to data storage.

One would think that instead of using a filesystem per se, the memory of a memory stick should be managed in a fashion similar to malloc. The difference would be named allocation - a "filename" would be associated with every section of memory allocated.

Flash memory is a block device.

While flash is random access and doesn't have a physical seek latency, it is indeed a block device. On reads this isn't evident, but on writes it is. You can only overwrite whole blocks at a time. This is why it actually does make some sense to use traditional file systems on flash devices.

what we've got here is...

Failure to litigate...

heh...

no seriously, FAT was convenient and fairly standard.. all microsoft is going to do is drive manufacturers to other (hopefully free software) schemes.... That's when we all win! THANKS MICROSOFT!

Re:what we've got here is...

If you RTFA (Wait, what was I thinking! This is /.) you would find that this only applies to consumer electronics (DVD players, TV's, etc.) and portable memory devices, like Compact Flash and those little USB memory sticks. At least for right now. And it only counts if it comes preformatted from the mfr.

I suspect this will drive most manufacturers to not format their media, or it will drive them to an open format, like jffs.

Re:what we've got here is...

If you RTFA (Wait, what was I thinking! This is /.) you would find that this only applies to consumer electronics (DVD players, TV's, etc.) and portable memory devices, like Compact Flash and those little USB memory sticks. At least for right now. And it only counts if it comes preformatted from the mfr.

If you read the patents, you'd notice that they are not specific to hardware implementations. What Microsoft does or does not currently demand is irrelevant -- the fact is that they *could* demand Linux royalties.

I suspect this will drive most manufacturers to not format their media, or it will drive them to an open format, like jffs.

JFFS is an unacceptable alternative. The two filesystems have wildly different goals. FAT is simple and can be implemented in a small amount of space.

Re:what we've got here is...

and why is that exactly? the FAT code in the kernel is *not* microsoft's, it was written by the linux programmers themselves.

That's irrelevant as far as patents are concerned. This is a big difference between copyright and patents. You only infringe on someone's copyright, if it can be shown that what you wrote/created is very similar to what someone else did and if it can be proven that you have had access to this other person's work. I.e., if you, completely independent from someone else, come up with exactly the same thing and you can prove this, then you will not infringe on their copyright.

Otoh, patents do not make this discrimination. The only exception is that if you used a patented technique before it was patented (but you never published it, so your work cannot be considered as prior art), then you can continue to use this technique *for personal use* even after the patent has been granted (which excludes any commercial use afaik, though I'm not certain of this). If you independently came up with it after the patent was granted, you're completely out of luck.

The reasoning is that patents exist to protect big investments in R&D, which generally wouldn't have occurred if there was no way to safeguard the results from imitation with patents. So patents are considered as some kind of necessary evil (temporary monopolies), required to promote innovation and disclosure. Of course, in case of software patents this reasoning is almost never true [ffii.org.uk] and you are pretty much stuck with only the negative sides.

WTF?

Whats going on here, they cant want more money, are they just trying to kill FAT and push NTFS or what?

Re:WTF?

they cant want more money

Are you familiar with capitalism? Shareholders? There is no such thing as 'enough money' for a corporation.

Re:WTF?

10:1 says that they're trying to push everyone to WinFS to get DRM embedded into the filesystems of portable devices. Wonder if they're licensing and making WinFS available for free....
-B

Re:WTF?

Not such a bad idea. Suppose my digital camera's memory card was NTFS. Well, then, I'd be out of luck under Linux unless I had the NTFS driver in my kernel. Last time I really compiled a kernel (ages ago) that driver still said experimental, or some such, and as I recall didn't have write access, just read. Furthermore, any other drive formatted with NTFS that I wanted to access, like a USB or Firewire hard drive, would be similarly difficult with a Linux machine.

And, while I'm rambling, what about the FAT driver in the Linux kernel? Is it in violation of the patent? I really don't know, and I'm too lazy to research it myself. (Isn't that what /. is for? Shouting questions into the void to see what answers come back? ;^)

What's really funny....

Furthermore, any other drive formatted with NTFS that I wanted to access, like a USB or Firewire hard drive, would be similarly difficult with a Linux machine.

I had a computer at work die recently. The motherboard popped a chips as it turns out. The problem was that it messed up the hard drive (NTFS) in the process. I couldn't get the drive to mount on any other NT machines so I tried running a Linux distro from CD. It mounted the drive without problem and was able to read most of the contents (some of it was still gone but I was able to recover my work from that day at least). So in this case Linux was better at handling NTFS than Win2K was.

good

If they charge people, then they have to support it.
I'll bring them my broken SD-card directories so that they fix their bugs.

Apple Disk Utility

Hm...since Apple's Disk Utility will let you format pretty much any writable media in FAT, will Apple have to pay Microsoft for that privilege? Will they choose to do so, or will they drop the ability?

Note to manufacturers: this will make your Mac formatted media actually cheaper to produce, so even if you don't give the consumer a discount, that's just one more reason to continue to produce Mac-compatible product...

Charging for their IP

I see nothing wrong with it. They own the patents, so they have the right to sell it to whoever pays. BTW, slashdot post is a bit misleading.

"Pricing for this license is US$0.25 per unit with a cap on total royalties of $250,000 per licensee."

The $250K is the cap; that means, that is the maximum amount they will charger per license holder for the use of the FAT. Just thought it came across incorrectly.

What about Europe ?

Can they enforce their patents in Europe ? What will be the consequence for Euro-based device manufacturers ?

Re:What about Europe ?

Whether or not they can enforce the patents in Europe is really dependent on what form the European Directive on Computer Implemented Inventions gets passed in (if at all). Lots of info about it available at the Foundation for a Free Information Infrastructure [ffii.org].

Regardless of the eventual European stance on software patents, manufacturers would still be hit by the patent when marketing in US or Japan.

The problem is timing

Anybody has the right to file a patent and attempt to license its technology (as long as the patent makes sense, which is not always the case with software patents, but that's another story).

The right way to do it: get the patent, announce the technology and licensing terms for it, sell licenses to however's interested. This way, manufacturers can decide whether they want to invest into that particular technology or find an alternative.

The wrong way to do it: get the patent, wait for a large number of manufacturers to widely use the technology, then announce licensing terms. This way, manufacturers have already invested a lot of resources into the tech and have no choice but to pay for the license, because switching to an alternative would cost them even more.

In an ideal world, the wrong way should be illegal and carry criminal sentences for extortion.

Long File Names

All [uspto.gov] four [uspto.gov] listed [uspto.gov] patents [uspto.gov] deal with the problem of having both short and long file names. None of my digital cameras use long file names.

Prior Art for all 4 patents

It's possible there's prior art in GEOS. Search down the page for "VFAT":

http://www.vcnet.com/bms/departments/innovation.ht ml [vcnet.com]

Rich.

Re:Prior Art for all 4 patents

Here's some details on that, coming from a long time GEOS user and programmer.

PC GEOS was originally released in 1990. Native GEOS files could have 32 character filenames, along with a bunch of extended attributes such as file type and creater info. This was accomplished by putting a 256 byte header onto every GEOS file. The header was transparent to GEOS applications - for all the apps knew, the header did not exist and the info was stored in the file system.

The filename stored in FAT was created by taking the first 8 letters of the filename, and changing any character not legal in a DOS filename to be an underscore. The extension would be .000, or if that name was already used, .001 or whatever was the first free number.

GEOS 2.0, released in 1993 (I think) added support for directories with long names and extended attributes. It also added support for symbolic links. This was done by creating a file called @dirname.000 in any directory that used any of these features. This file was completely invisible to GEOS apps. The file was 256 bytes, and contained the same information as a standard GEOS file header. If you used links the file was longer to store that info.

The whole longname process was transparent within GEOS - even the kernel didn't know about it. It was done entirely within the FS drivers.

The abstract for the first patent mentions providing a common namespace for long and short filenames, with files with long names also being assigned a short name. GEOS is definately prior art on that, but I haven't read the full patent to be sure. Odds are though that their patent includes the ~1 thing or some stupid detail to make it unique.

Doesn't that just remind you

Of the friendly folks at Unisys (GIF) or the Fraunhofer Institut (MP3)?

The point why I think such a scheme is totally fucked and dishonest is not the fact that such patents exist, but because of the following business model:

1. Create valuable idea

2. Wait until it's a defacto standard

3. PROFIT !!! (no ??? required)

It looks more and more like RMS is a true visionary.

Re:Doesn't that just remind you

Whats so wrong with creating a valuable idea and expecting to profit from it.....?

Re:Doesn't that just remind you

Whats so wrong with creating a valuable idea and expecting to profit from it.....?

Nothing.

But there is something wrong with creating an idea, waiting for it to become so standard that even our keychains come pre-formatted with this technology, and such that any number of 3rd parties provide support for this technology in order to conform with the "norm" (apple, linux, etc), and *THEN* expecting people to pay for it, once it's been entrenched in the economy as irreplaceable and free.

Especially when said technology was created in the '70's and patented in the '90's.

~Will

Re:Doesn't that just remind you

Nothing. Now, what part of step 2 are you having trouble understanding?

A risky move...

This will probably make MS a little money, until the embedded industry moves en masse to a free file format. If they do, the file formats for PDA's et al move away from MS's (FAT) standard - something that mas long-term repercussions for MS.

The profit margin isn't that great on PDA's et al as it is - why would the industry want to cede a further chunk of that margin to MS? All you'd have to do is include a driver for a free file format with the PDA cradle, card reader, and/or desktop application.

What will happen

A license for removable solid state media manufacturers to preformat the media, such as compact flash memory cards, to the Microsoft FAT file system format, and to preload data onto such preformatted media using the Microsoft FAT file system format. Pricing for this license is US$0.25 per unit with a cap on total royalties of $250,000 per manufacturer.

All manufacturers will grumble (some louder than others), pay up the money and then add an additional $5-$10 on their products to compensate for this licence.

I'm wondering though, if they supplied the products unformatted, would that still mean they have to pay the licence? Upon insertion, Windows would helpfully offer to format the drive for you and then you'd be ready to go.

Re:What will happen

The problem, I think, is that most people don't want to have to format their media before first use. It's convenient to just insert any card and start snapping pictures.

The behavior you suggest is exactly what would happen, but I doubt that any media manufacturer would do this because it would represent a substantial barrier for most people.

Shooting themselves in the foot again

Thickheadedness helps the process of moving away entrenched companies. And this case is no different. MS is still very much entrenched, no doubt about that. But hardware manufacturers are now that much more likely to support other standards and filesystems (like ext3) natively, and perhaps as their primary system.

They'll get away with this because they're big enough. And they'll make some money. But this, and similar practices, will work against them in the long run.

Re:Shooting themselves in the foot again

I don't see how this is shooting themselves in the foot. Right now:
-Media comes preformatted FAT, and software is written to manipulate FAT. MS gets no money. Any platform is equally capable of manipulating FAT, so MS doesn't even enjoy a platform advantage for this media. They get absolutely nothing.

Future with this policy:
-Most media will stay preformatted FAT, software stay the same, and MS collects money.
-Some high volume companies will decide they can beat the 250k price point by moving to something like ext3 or jfs or something proprietary. If they use any existing FS technology, the companies will port that FS to Windows if not already there, because Windows is essentially a requirement for mass-market media. Other option is they will invent a proprietary filesystem and likely only write software for it under MS Windows and *maybe* OSX, which will give MS a boost in supported hardware under Windows. So MS either gets money, gets more filesystem support for free, or gets hardware that works better with Windows than other platforms, hardly shooting themselves in the foot.

Compatibility with lack of freedom!

The first FAT file system was developed by Microsoft in 1976. That system was based on the BASIC programming language and allowed programs and data to be stored on a floppy disk. Since that time, the FAT file system has been improved upon multiple times to take advantage of advances in computer technology, and to further refine and enrich the FAT file system itself.

Today, the FAT File system has become the ubiquitous format used for interchange of media between computers, and, since the advent of inexpensive, removable flash memory, also between digital devices. The FAT file system is now supported by a wide variety of operating systems running on all sizes of computers, from servers to personal digital assistants. In addition, many digital devices such as still and video cameras, audio recorders, video game systems, scanners, and printers make use of FAT file system technology.

Microsoft is offering to license its FAT file system specification and associated intellectual property. With this license, other companies have the opportunity to standardize the FAT file system implementation in their products, and to improve file system compatibility across a range of computing and consumer electronics devices.

Nice guys. Create a standard, realize its being used for a lot of devices after 27 years, see the chance for even more money you don't need, and then charge for it.

It's not worth 250k for a license. We had to use it in devices to remain compatible with an OS that was forced upon us.

Give me a break.

Licensing now, after all this time?

I must be missing something here....

How can they enforce this, if memory cards/sticks for cameras have been doing this for years now? If they haven't be pursuing the patents enfringement before this, can they now?

What about pre-formatted floppies?

Digital Research?

I thought Digital Research was the company that had developed the FAT system?

Is this the other shoe?

Is it unreasonable to think that the logical next step is for MS to demand payments from any and all developers of software written to run on the Windows platform? Can a Windows application run without needing to access or use any patented Windows code?

Which FAT? Older patents must have expired by now

The earliest versions of the FAT file systems were around in 1981. (Actually probably 1979 or 1980 if you count Seattle Computer's QDOS). Those patents must've expired by now, right? Or does Microsoft get a perpetual patents the same way Disney gets perpetual copyrights?

Re:Which FAT? Older patents must have expired by n

They didn't file any till 1995. Kinda clever, really - don't even bother patenting it untill you see if it's going to be popular. All the benefits of the submarine patent, but without the up front patent fee!

(subject)

Does this mean the Linux kernel will be dropping FAT support? And BSD for that matter?

Finally...

Perhaps now we'll see manufacturers adding [ext2/3/your favorite flavour of a fs] to their products.

Esp with camera's gaining support for the picture tranfer protocol (PTP), they are becomming more and more filesystem agnostic. Other devices may as well...

Re:Well, DUH!

It's a good business decision, sure. But see, MSFT is a convicted monopoly. Their business decisions are supposed to be limited to those things which don't stifle competition. However, since our government is owned by corporations, and the people who are supposed to be enforcing this are ignorant of technology, the monopoly rating has no meaning. That's what we bash.

As noted elsewhere...

It's dishonest and unacceptable for them to attempt
to start charging after so many years, for something
noone has ever charged for before, after it has
become something which has become a de facto standard,
often implemented in hardware. Like GIFs were, their
patent should be ignored, and more ideally, legally
shot down.

Was FAT really innovative anyway? The patents just
cover modern issues probably not even implemented
on 95% of the FAT-handling devices (e.g. my
digital camera). From what I remember of CP/M's
filesystem, FAT didn't seem to be markedly
different.

On another node, as IBM and Microsoft had
cross-licensing for most of their early
DOS-related stuff (remember PC-DOS?), should
their claim not be invalidated, could they simply
grant the world an open license for it?

ESR predicted this

Eric S. Raymond predicted that Microsoft would force the patent issue on its file formats in The Cathedral and the Bazaar [catb.org].

This is very worrying. Let's hope MS didn't get this idea from there.

While I support ESR, I can't help but wonder if outlining Linux's strengths provides M$ with a plan of attack on Linux.

Not a big surprise

I do not believe this is a big surprise move by MS. They are, after all, the devil :-)

But seriously, I have wondered for a long time how long RedHat and other companies would get away wiht providing tools that help people transition to Linux. Such as the tools that mount ntfs or fat filesystems. Microsoft knows nothing of the spirit of cooperation as proven by the way they treat their business "partners." Instead of working together to achieve something great as in a partnership, Microsoft waits til they think its profittable and normally competes head to head with their partners by buying out one of their competitors.

Now, in the same fashon, they will charge for something that was free. Compnaies are hooked into using the FAT filesystem. And, like a drug dealer, they start charging for the drugs that keeps the user flying high now that they are hooked by the first freebies.

Intelligent companies will figure a way to not be exploited by MS. Of course, if they were intelligent, they should have seen this coming from MS.

Hmmm sounds like GIF

Thanks to royalties on the .GIF format after years of being royalty free, the .JPEG REALLY, and I mean REALLY took off, plus PNG came about as well. Lots of programs dropped .GIf support completely and I didn't blame them. Maybe this will make another standard take precedence on new camera's and flash devices, $250k is a HUGE price to pay for a little startup trying to push a new product

Sounds like a gentle? push towards embedded Win

I can just see the maketing material from MS to the embedded developers? Using other embedded OSes puts you at risk of patent violation. We're just trying to help you avoid expensive litigation or licensing. (Nevermind that it's our patents.)

Hey, if they can't compete on quality and features, why not force their way into the market using patents.

DR-DOS , 20 years, and floppies

How strange. They couldn't stop DR-DOS, which clearly could format FAT partitions, but now (even after the loss of a Federal court case that proved they abuse their monopoly power) they can stop people from using FAT? And FAT is well over 20 years old, Microsoft's own site states The first FAT file system was developed by Microsoft in 1976. Stranger still, they didn't get the first FAT patent until 20 yaers later, in 1996! (Applied for in 1995.) This is wrong in so many ways.

And if they can stop a manufacturer from delivering a product such as a USB drive pre-formatted with FAT, then can't they do the same with a pre-formatted floppy disk? For that matter, can't they do the same with a floppy disk that contains software? Anyone who sells PC software on floppies will owe Microsoft money! (There are less today than there were just five years ago, thanks to CD's, but there are still many small businesses out there. I just got a driver on a floppy last week with something I bought).

Long file name stuff

The four patents cited all relate to Microsoft's kludge for shoehorning long file names into a filesystem that can only take 8+3 names. You know, Microsoft -> Micros~1.

First I'm going to get obligatory whinges out of the way. It's ludicrous that this is patentable. The patent is stupidly long and verbose, probably to make this 'innovation' seem more significant than it actually is. The patent is also worded to sound as though this is a useful general idea, rather than something that you'll only ever see in FAT because everyone else is sane enough to just use a better filesystem.

On a more practical note, these patents cover only the long name -> 8.3 stuff. Those digital cameras that write 8.3 names (DSC00001.JPG, DSC00002.JPG, ...) should be fine. Shipping blank but FAT-formatted media should also fall clear of the patent's grasp - the patents don't cover the FAT filesystem itself, just the 'VFAT' Win9x method of fitting long filenames into FAT. Furthermore, the patents seem to cover algorithms for inserting long filenames into the directory tables - implementations that don't write, but only read data, might be okay.

Simple blank FAT, might I add, has been around for at least 17 years, so any patents on it should have expired by now.

Ob-disclaimer: I've only skimmed the patents, and I'm not a lawyer. I'm probably wrong.

ISO 9660

OK, so we format it in ISO 9660 and the drivers are written to treat it like a CD-RW. Microsoft just makes companies move to standards. (Or they ship it unformatted, and the users choose how to format it according to their OS of choice.) Put the driver on the device (small ISO 9660 file system) set to auto install, and you're set.

Talk about submarine patents. Floppies have been shipping FAT for *decades*!

Seems to me...

It seems to me that Microsoft is granting licenses for their FAT code and what-not. They make no mention of not being able to make your own FAT-system (which what everyone has been doing up 'till now).

The only reason you'd really care about this is if you run a large company that makes FAT devices and want to insure that your FAT-system is 100% compatible with specs (which are controlled by Microsoft). Otherwise, you wouldn't care... You'd just look up the well published info already available for free on the 'net.

Re:Seems to me...

They make no mention of not being able to make your own FAT-system (which what everyone has been doing up 'till now).

Patents don't cover a particular implementation. They cover the right to implement an idea. Mentioning their patents at the end of the article is most definitely sabre rattling aimed at *all* implementations of FAT IO.

Flash-card filesystems

That brings forward an interesting detail: filesystems for flash-memory devices should be optimized to avoid writing often to the same memory area (the FAT for example) because the memory position may fail after a few thousand writes to the same position, or is this taken care at the memory controller level and the filesystem need not to care?

It may be the case that one FS is more or less adequate for flash devices given this restriction holds true ...

Can someone explain

Does this apply if you develop your own FAT-formatting software?

Or does it just apply if you sell media that is formatted with FAT?

I'm guessing here, but I expect that if you sell your media unformatted, you'll be OK of course, but what MS is trying to do is prevent anyone from selling MEDIA that is FAT-formatted, but they can't stop you from using something like let's say FreeDOS or Linux to format the media once you've bought it?

Is that right?

Patents appear to concern VFAT

The four patents listed appear to be to do with VFAT, and specifially the way it simultaneously has a short (8.3) and a long name for each file.

The earliest patent was granted in 1996 - what then of the Rock Ridge CD format [cam.ac.uk] which offers a somewhat similar mechanism for long Unix filenames over the standard short ISO9660 length, and was adopted in 1994?

RTFA and be careful with the FUD

From the webpage:

Microsoft is offering to license its FAT file system specification and associated intellectual property. With this license, other companies have the opportunity to standardize the FAT file system implementation in their products, and to improve file system compatibility across a range of computing and consumer electronics devices.

Reading this and the rest leads me to believe that they are NOT preventing people from reverse engineering FAT. Rather, they are selling their 'true' implementation of the filesystem. Nowhere does it say that companies providing their own 'clean room' implementation of the FAT filesystem will have to pay.

That doesn't mean they won't go there, just that they haven't yet. Still, the typical knee-jerk reactions here are as yet unwarrented.

Very good move!

It's very good move by MS.

FAT is a terrible format for Flash media, because it constantly updates some variables in first several sectors of the disk. The effect was mentioned some time ago on /. -- when you're done writing around 200k files to flash media it was already past erasure limit for those sectors at the beginning i.e. media was destroyed.

So it might actually give some incentive for vendors to move to JFFS or similar FS _designed_ with this flash-specific limitation in mind.

rrw

Re:Very good move!

It's very good move by MS.

FAT is a terrible format for Flash media, because it constantly updates some variables in first several sectors of the disk. The effect was mentioned some time ago on /. -- when you're done writing around 200k files to flash media it was already past erasure limit for those sectors at the beginning i.e. media was destroyed.

So it might actually give some incentive for vendors to move to JFFS or similar FS _designed_ with this flash-specific limitation in mind.

rrw

Nope.

As far as I know, all Flash media that use FAT have Flash Translation Layers (FTLs) such as M-Systems NFTL or the PCMCIA FTL that does wear-leveling, i.e. writing the same sector 1000 times will actually write 1000 different sectors.

FreeDOS not free?

Just where does this put FreeDOS [freedos.org]? I'd think, not free anymore. How can you have DOS without FAT?

Sure, you could have it use another FS (ext2) but can you imagine a DOS not using FAT?

can someone look over the patent please

here's [uspto.gov] the fist of the patentes in question. Filed for only in 1995, granted in 1996. I've looked at it, but I don't have a good understanding of how claims in a patent work. If each claim represents something they own then I don't see any way they can makes claims as broad as claim 1. If the patent is only for something that matches each and every claim, then it would seem that a very minor (even compatable) varient on one part of any these claims would allow an alternate file system to co-exist that would not infringe the m$ patents. But then it doesn't make much sense for this (or any) patent to go into extreme detail in making claims that would limit what the patent applies to.

Re:can someone look over the patent please

The validity of one claim typically does not invalidate the others. My patent lawyers call this a layered approach, where the first claims are purposely broad in an attempt to grab as much IP ground as possible. Subsequent numbered claims in the patent are become more specific. They take this land grabbing approach essentially because they can.

Cleanroom implementation not an option with patent

I thought there were similar filesystems, and besides FAT is so simple, a cleanroom implementation would not take long, hence no need to licence

This is certainly not true. With copyright law, it's illegal to copy code. With patent law, ideas are patented. Wheter it's implemented in a 'clean room' or not, that really doesn't matter.
THAT's the reason why we detest software patents in the first place!

To be able to bring out preformatted FAT flash devices without paying the Microsoft license, one would have to claim rights to 'prior art'.
In contrary with copyright law, however, it's the responsability of the IP holder to come down on the infridger (so as long as you don't get a letter from MS, you aren't obligated to take action).

Yet IANAL but in my past businesses talked about these issues alot with lawyers.
Regarding the question wrt European manufacturers usage of the FAT filesystem. First needs to be seen if these patents are also valid in Europe or not. After initial issuing a patent in Europe, US or Japan it's automatically valid for 3 years in all of these regions. After this period it needs to be registered in the specific region. As I presume these are quiet old patents, one should look into this.

However, there still is controversy regarding software patents and its enforcebility in Europe. European software patents should also have a hardware part. This license has a hardware part, but the patents themselves not.
You might want to consult a patent lawyer to verify this, but I would bet that it's unenforceable in Europe. However, I wouldn't bet on this for 250k USD ;-)

A lot of smaller device vendors will probably sell the unformatted version after they receive letters from MS (which is a pity as FAT is readable/writable by Win/Mac/Linux).

A lot of users will now unknowingly format their cards using NTFS making it harder to exchange data with non-Windows users...

Regarding the FAT driver in Linux; as this MS license only speaks of preformatting digital media in the FAT filesystem, this is not an issue today.
Could Microsoft ask money for inclusion of the FAT driver in the Linux kernel?
Remember, patents are about ideas, not about the actual implementation or even in which language certain algoritms are written (it's about what is accomplished, not about how it's actually done). So as the FAT filesystem is patented technology, they could theoretically take action.
However, the action needs to be taken by them first. If 'prior art' can prove that the Linux implementation is based upon technology very simular than the patents issued, a case in court might prove the patents to be not really valid.

Such a thing would also destroy all possible revenues from licensing programs such as these (it's higly unlikely that device manufacturers will try to prove they had access to prior art, the long-bearded fs developers in the OpenSource community are probably less easy to convince - especially since the patents where only filed in 1995).

If the outcome of a legal case would be different, chances are higher that distributions would just drop the filesystem driver instead of paying money to Microsoft.

So, to me it seems that Microsoft would have more to loose than to gain from going after the FAT driver in Linux.

copyright.

Stop using FAT and use GINF (GINF Is Not Fat)

GINF is a filessytem structurally similar to FAT and just by coincidence happens to be compatible, but is not FAT. Would some crazy idea like this work to dodge a patent? If you have a clean implementation of the filesystem that differs in specs from another fs are they really the same? I think it would really only be FAT if you use the microsoft driver. If you don't use the MS driver it must not be true FAT. LAME seems to use this idea; everyone knows LAME Aint an MP3 Encoder, it just so happens that by pure coincidence the files it outputs are compatible in an mp3 decoder.

This should be easy to get around

These patents, as has been mentioned before, cover only long file names.

Based on my cursory reading of the patents:
A device that merely formats a storage device so it can be used by an infringing writing device would not by itself infringe these patents.

Similarly, if a camera (for instance) does not contain logic capable of writing long file names it would also not infringe these patents.

Microsoft probably set the maximum at $250,000 because it would cost more than that for a company to litigate the issue.

Prior Art: Novell

I recall that Novell's Netware 3.x had the ability to use multiple namespaces, and would automatically produce truncated versions from long file names for DOS machines. Used to run a Novell server that had Mac, Unix and DOS/Windows clients.

What about Samba?

Do they own enough patents to shut that project down? If they make sure we lose both FAT and SMB, I'm afraid that will do a lot of damage to Linux. Both dual-boot and fileserver Linux will disappear.

I bet they are particularily interested in pushing aside Samba, since that would automatically mean more 2003 licenses.

slashdot effect

open source letter to Microsoft:

Dear Sirs:

I'm a computer professional. On rare occasions I still used floppy disks that I have formatted and put business product on. I might distribute two or three a year to business contacts this way. It has come to my attention that Microsoft now wishes to enforce it's patents on the FAT file system and I believe that the floppies that I distribute might fall under this extension of you monopoly power. Therefore I would like to request that you provide me with the proper paperwork and licensing agreements so that I can pay my 25 cents each time I do distribute a FAT formatted floppy with my product on it.

If we can take down web sites, perhaps the Microsoft legal department should receive a few million requests from people who want to be sure they don't cheat bill out of his two bits when they format and distribute a floppy.

What type of FAT?

Ever wondered why you have to step down through an unnecessary folder when browsing your digital camera's memory card? It's because FAT16 can't have more than 512 files in the root directory.

So are MS enforcing the patent on the crappy FAT16 - some cheek there! - or the improved FAT32?

Karma whoring?

Here are the patents' abstracts. They all relate to long filename support, so if you were willing to limit yourself to 8.3 names, you don't need a license. This is easly done with dedicated devices, since you just implement your own index file on top of the 8.3 names; this was a common technique back in the old FAT16 days.

U.S. Patent #5,579,517 [uspto.gov] Common name space for long and short filenames

An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.

U.S. Patent #5,745,902 [uspto.gov] Method and system for accessing a file using file names having different file name formats

A multiple file name referencing system stores multiple file names in a file. These multiple file names include an operating system formatted file name and an application formatted file name. When an operating system formatted file name is created or renamed, the multiple file name referencing system automatically generates an application formatted file name having a potentially different format from, but preserving the extension of, the operating system formatted name. The multiple file name referencing system similarly generates an operating system formatted name upon creation or renaming of an application formatted name. A B-tree is provided which contains an operating system entry for the operating system formatted name and an application entry for the application formatted name, each entry containing the address of the same file to which both names refer. The multiple file name referencing system converts the operating system formatted file name to the application formatted file name by accessing the B-tree with reference to the operating system entry, and vice versa. As a result, either file name can be used to directly reference the file without requiring additional file name translation.

U.S. Patent #5,758,352 [uspto.gov] Common name space for long and short filenames

An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.

U.S. Patent #6,286,013 [uspto.gov] Method and system for providing a common name space for long and short file names in an operating system

An operating system provides a common name space for both long filenames and short

Gadgets Don't Need It

Static, EEPROM (flash) and all other memory chips allready have a built-in filesystem. RAM means random access and voltages on the pins select the exact points on the chip. FAT is used because just about every OS supports it and cheap card readers can be made.

Using no filesystem will get the best usage of the memory chips. Please note that a 1440k floppy won't give you that but perhaps 10% less. As usual M$ shoots itself in the foot and camera makers can advertise 10% more pictures to a card. Tar would work nicely as a 'filesystem' and as far as I know that is free and even Windows understands it. Tar is very efficient but not exactly 'random access' something not usually needed in a camera.

No filesystem or minimal formatting works well on all removable media. That includes DVDs and CDs which will hold considerably more if you don't use cd9660 or UDF. If you have Unix (and SCSI) try it if media is intended to be streamed. Any further discussion of this is offtopic.

Charging to be "WIndows compatible"?

Of course this is stupid, bad, mean, blah blah blah. You guys have already covered that. What's interesting to me though is that Microsoft needs device makers to make devices that favor (or atleast are compatible with) windows. iPOD (used to) prefer Macs, and so someone in love with iPods would probably prefer a mac. If Microsoft discourages manufacturers from making devices compatible with windows, they will end up hurting their popularity (duh.)

Microsoft is blowing smoke

The FAT file system format was never patentable to begin with, since there was nothing particularly novel about it when it was created. What's more, it has been in use for more than 20 years (the lifetime of a patent) and nothing about it was patented within a year of its implementation and release to the public. So, Microsoft has no rights here. Its claims to the contrary are absurd.

maybe this is good

While Microsoft's patents on something as broken and trivial as FAT are silly, they are presumably valid. The more serious problem here isn't Microsoft, it's other companies that didn't do their homework before choosing a Microsoft "standard". Maybe once it costs them significant amounts of money, they'll start paying more attention. But $250k may not be enough.

And there are a few open alternatives that even Windows understands out of the box: ISO9660 and UDF come to mind (although Windows may not apply them to flash devices by default).

Knee-jerk that hurts M$:memory with bootable Linux

Microsoft should have considered one further option which is also left to the manufacturers of "formatted blank media" such as USB/CompactFlash/etc. memory:

Of course, just as Microsoft may have assumed, manufacturers could either use FAT and pay up, or sell their media unformatted, in which case the customer needs a M$(-licensed) product to format it to FAT.
However manufacturers will probably want to test an initial write/read cycle, but if (for the sake of quality control) they simply format their media to something else (let's call it FOSFS, the hypothetical Free and Open Source File System ;-/, in order not to express any preference for one of the solutions in existence), most customers could not read it and/or would have to reformat it to FAT - with someone owing royalties to M$ as above.

If this has been Microsoft's reasoning, they have neglected to consider another possibility:

On current removable media of 256 megs and up, an entire Linux distribution takes up less than 10% of capacity:
Unless the boot process from USB memory requires more than a rudimentary, non-infringing "allusion to FAT", such media could not just be formatted in an empty FOSFS, but it might rather be sold with preinstalled software such as this (compiled without FAT support of course):

"(...) tiny Linux (...) distributions containing all the software to boot (...) and play multimedia files through the MPlayer, the best multimedia player in the Unix world [sourceforge.net]
(...)
MoviX is now able to boot also from (...) USB pen, CF card and from the net."

Cameras etc. could switch to the new FOSFS immediately, for PCs would not need to support it "out of the box", as the removable media itself would actually "be its own driver" (and media viewer, and provide network connectivity, etc.).

In this case, such "not-so-blank media" should certainly bear the penguin logo as a "seal of quality".
To justify adding a Creative Commons mark next to it, one could even fill the remaining space with some free and open (motion) pictures and/or audio to be played on first use.

Microsoft itself would have to catch up and release Windows support for the FOSFS before everyone sends and serves pictures from some sort of "USB Linux".
If only one major manufacturer of removable memory takes an approach like this, at M$ the employee who came up with that "bright idea" of a FAT license but failed to see this option may have a hard time explaining...

I've said it before, and I'll say it again...

UFS dammit! As far as filesystem support goes, the only modern OS that doesn't support it is Windows, and for that, a driver could be made by anyone with decent Windows programming skills.

Source Code is BSD-licensed, it does not have the filesystem size limits that FAT does (which flash card manufacturers will be nearing, sooner rather than later) or the file size limits. It has always had support for long filenames. You do NOT need to ever defragment it (much better than even Ext2/3 in that regard). It is incredibly stable, and does not loose data in any cases (unlike Ext2). It is also very high performance (unlike just about any other filesystem).

Just about every modern OS supports it:

FreeBSD

OpenBSD

NetBSD

Linux

Mac OS (v.X and up)

Tru64/Digital Unix

AIX

HP/UX

Solaris/SunOS

And many more I can't think of off the top of my head. So why doesn't one company put a little effort into writing a Windows filesystem driver (Open Source it and they won't even have to maintain it) and then reaping the rewards of finally having a universal filesystem for their storage devices?

If it wasn't for filesystem incompatibilities, removable hard drives would be a major, major threat to optical media like CD/DVD-Recordables.

Re:Well...

Where do you get your information? That number is inaccurate:

NTFS, FAT, FAT32 [microsoft.com]

Re:Well...

RTFA. (Go ahead, give me the old "You must be new here" - joke. :)

The linked article does not mention home computers. Microsoft wants license fees from:

1) Manufacturers of solid state removeable memory devices

and

2) Manufacturers of certain types of consumer electronics that use the FAT file system:

portable digital still cameras
portable digital video cameras
portable digital still/video cameras
portable digital audio players
portable digital video players
portable digital audio/video players
multifunction printers
electronic photo frames
electronic musical instruments
standard televisions

Do you think you'll ever buy one of those? Then it'll affect you. :)

Re:SCO like

Because it's harder and harder to innovate with respect to hardware, and provide backward compatibility with your existing client base.

What's more, each new 'major' release of (Windows at least) doesn't really provide much in the way of 'must-have' capabilities for enterprise customers, who are the bread & butter for companies like microsoft. Adoption of software upgrades since Win2000 have been slow in the market, because . . .

Computers and gear tend to work 'well-enough' for most business uses - so sales of new gear has stagnated for several years (though there are signs of a turnaround).

And Free offerings are becoming more and more viable alternatives for forward-thinking organizations.

So Microsoft is really in a bind here - declining sales, difficulty in setting the technological standards that used to grant them monopoly pricing power, and increasingly viable alternatives for customers leave them forced to consider revenue streams such as licensing technology. And to try like hell (witness their latest DRM efforts and attempts to make it a standard that would guarantee them sales and licensing revenues) to use whatever vestiges of their monopoly power to twist a few more years of control out of their franchise.

Re:HPFS

Bdoh! JFS is open source... Available at your closest ftp.xx.kernel.org mirror in recent linux-kernels, and possibly in *BSD too (at least I've got a vague recollection of someone doing a port). And to preempt a possible question, yes, it's IBM's own code, not reverse engineering.