Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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
"The ones who are crazy enough to think they can change the world, are the ones that do." - Steve Jobs
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.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
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.
