OSDev.org

Hello all,

I have a question. If I was to implement any version of the FAT filesystem into my operating system,
and then sell my operating system commercially (for a tiny price), does Microsoft require a royalty?
Is FAT32 or earlier even copyrighted anymore?

I'm asking this because I don't want to get into a state where I have a working filesystem implemented into my OS,
I start selling it and I get a lawsuit from Microsoft a week later.

Thanks in advance,

Int13h

My question would be why bother with FAT when there are far better filesystems available. I honestly wouldn't worry about the position when you sell your OS. It's very unlikely that you will ever have this problem.

OK, thanks.

I guess I could worry about stuff like that later.

Hi,

int13h wrote:I have a question. If I was to implement any version of the FAT filesystem into my operating system,
and then sell my operating system commercially (for a tiny price), does Microsoft require a royalty?

As far as I know; all Microsoft's patents involved long file name support (and IBM had a patent for "extended object attributes" that nobody cares about), so if you don't support long file names (or "extended object attributes") there's no problem. If you do support long file names, some of the patents have expired but I don't think all of them have yet; which means that you might be able to find a "different but compatible" way of implementing long file names that doesn't infringe on whatever patents remain; and you might find that all patents have expired by the time you "finish" writing your OS.

int13h wrote:Is FAT32 or earlier even copyrighted anymore?

Copyrights are completely different to patents. Microsoft's code (for MS-DOS, Windows, etc) would still be under copyright; but that only prevents you from copying Microsoft's code (and doesn't prevent you from implementing your own code, like patents can).

iansjack wrote:My question would be why bother with FAT when there are far better filesystems available. I honestly wouldn't worry about the position when you sell your OS. It's very unlikely that you will ever have this problem.

The normal reasons are:

• "sneakernet" (to allow files to be transferred between different OSs and different devices - e.g. digital cameras, etc)
• to be able to work with UEFI's system partition
• to gain experience on something easier before tackling something more complex

For every other purpose (e.g. as the OS's main file system) the design of FAT is extremely poor.


Cheers,

Brendan

Thank you very much Brendan, this is very helpful information.

Brendan wrote:to gain experience on something easier before tackling something more complex

I just wanted to use FAT because it may not be the most efficient,
but it seems very simple and I just thought it would be easier to start out with.

Brendan wrote:"sneakernet" (to allow files to be transferred between different OSs and different devices - e.g. digital cameras, etc)

I also don't really mind about this because it is just going to be a Live CD kind of thing.
But I can see how this may need to be implemented later.

A thousand thanks,

Int13h

One thing to note is that FAT (16/32) support is the standard filesystem for SD cards and probably a few other types of storage. Such devices will almost certainly work with other filesystems, but they're not guaranteed to and may have certain optimisations in their design that improve performance specifically for FAT (e.g. having the FAT tables in faster storage or prioritised for caching, etc.).

While it's not something I'd really worry about and if you're ever in that position you'd have proper legal counsel to advise you, if your OS were ever to be used in a device that advertises SD card support, it would have to support FAT.

Microsoft can and does charge licensing fees for FAT support in commercial products; in fact, it was rumoured that the licensing fees charged to Android device manufacturers for FAT support were more than the total licence cost of Windows Mobile. However, they have never (to my knowledge) targeted non-commercial developers.

Brendan wrote:For every other purpose (e.g. as the OS's main file system) the design of FAT is extremely poor.

I have been thinking this. The basic idea is to use it as a thin layer and have all the real work done on database files (relatively big and fixed size). It is like a partition scheme and fragmentation should be a very minor problem when working "natively" on a system that is aware of this usage scenario. Allocation units should be as big as possible and time stamps for FAT files should be updated every now and then (but not too often).

• Layer 0: Raw blocks
• Layer 1: Disk partitions
• Layer 2: FAT
• Layer 3: DB files

In practice, the next layer would work on DB file blocks directly. This would be totally co-operation-friendly with existing operating systems when exchanging information because the file system layer is treated like a standard partition scheme and the native "file system functionality" is implemented elsewhere. Other operating systems could work on those databases in user space (if they support the format) without any special kernel support.

There are some problems, e.g. the maximum partition size for a FAT file system. This is just an idea and it is not actually very relevant whether the "real" file system is FAT or some other file system already available. The main point is to mostly ignore that layer altogether.