FAT32 and patent issues?

[mariuszp]

I want to implement FAT32 in my OS, partly to support UEFI soon. Are there still any non-expired patents regarding it and long filenames? Does UEFI require that I also support 8.3 filenames alongside long file names? In general, what do I need to do in order to implement FAT32 without infringing any patents?

[Brendan]

Hi,

I want to implement FAT32 in my OS, partly to support UEFI soon. Are there still any non-expired patents regarding it and long filenames?

Yes. See this page on FAT patents, which says that one of them ("Common name space for long and short filenames") is valid until 2021.

Does UEFI require that I also support 8.3 filenames alongside long file names? In general, what do I need to do in order to implement FAT32 without infringing any patents?

FAT requires 8.3 file names for all files (regardless of whether they also have long file names or not), and UEFI would be no different.

To implement FAT32 without infringing patents, don't use long file names. For UEFI this is fine - your boot loader can have an 8.3 file name (and for removable media your boot loader must have an 8.3 file name); and for everything else you probably shouldn't be using UEFI's system partition in the first place.


Cheers,

Brendan

[Octacone]

I’ve already asked this question once.
It is really simple, who cares?
Not important at all, do what you want, they won’t go after you (you are not important to them and you are not making any money out of it). That is what I’ve concluded. Just implement that and keep quiet (don’t advertise that feature). There was a thing about it not being valid in Europe (German court denied the patent...) Or you could just do it the “Linux way”.

[mariuszp]

I’ve already asked this question once.
It is really simple, who cares?
Not important at all, do what you want, they won’t go after you (you are not important to them and you are not making any money out of it). That is what I’ve concluded. Just implement that and keep quiet (don’t advertise that feature). There was a thing about it not being valid in Europe (German court denied the patent...) Or you could just do it the “Linux way”.

What is the "linux way"? Ive heard that they jusr suppprt long, but not short, filenames, but earlier in this thread Brendan said its required...

@Brandan: other than UEFI, i'd like to support removable media like USB sticks which are usually FAT32-formatted.

[zaval]

I want to implement FAT32 in my OS, partly to support UEFI soon.

You don't need to implement FAT32 in order to use UEFI. UEFI by itself supports it. You write an OS loader that uses UEFI FAT capabilities (through the load file protocol, device path protocol). And also, you can place in the UEFI system partition everything you want, just make sure to not clutter it with whatever else residing there, thus use your own "vendor" directory. This has an advantage*, that your OS loader doesn't need to have a FS specific code to fetch kernel and everything else from the media, - you again ask UEFI to read that.

* - and also it's good to have kernel, drivers and system configuration on such a partition, it makes it easy to enforce special access (restriction) on it, even though FAT doesn't have access control mechanism by itself.

[Octacone]

What is the "linux way"? Ive heard that they just support long, but not short, filenames, but earlier in this thread Brendan said its required...

Here is an article about it: https://www.geek.com/chips/clever-linux ... 951/?amp=1

I don’t know about the UEFI thing, maybe there is a way to cheat the system, to make it think you support what is needed or something. It all depends on what you need. (The only problem would be cross-OS compatibility).

[mariuszp]

I want to implement FAT32 in my OS, partly to support UEFI soon.

You don't need to implement FAT32 in order to use UEFI. UEFI by itself supports it. You write an OS loader that uses UEFI FAT capabilities (through the load file protocol, device path protocol). And also, you can place in the UEFI system partition everything you want, just make sure to not clutter it with whatever else residing there, thus use your own "vendor" directory. This has an advantage*, that your OS loader doesn't need to have a FS specific code to fetch kernel and everything else from the media, - you again ask UEFI to read that.

* - and also it's good to have kernel, drivers and system configuration on such a partition, it makes it easy to enforce special access (restriction) on it, even though FAT doesn't have access control mechanism by itself.

I have to support FAT32 in order to access the system partition from my OS (e.g. to install the bootloader in the first place). And also, of course, I want to support USB sticks and such.

[Sik]

What is the "linux way"? Ive heard that they jusr suppprt long, but not short, filenames, but earlier in this thread Brendan said its required...

The short filename is bogus if there's a long one:
https://lkml.org/lkml/2009/6/26/313

Code: Select all

+	  The field where a shortname would normally go is filled with
+	  invalid characters such that it cannot be considered a valid
+	  short filename.

Again, if you want to be really sure then you must consult a patent lawyer (especially if you're a business), but yeah the solution is out there already if you wonder. I'm not sure if there are any devices in widespread use left that still insist on 8.3 filenames.

[zaval]

I have to support FAT32 in order to access the system partition from my OS (e.g. to install the bootloader in the first place). And also, of course, I want to support USB sticks and such.

Of course, I meant, at the OS loader level, where interaction with UEFI happens, you don't need to implement FAT code. And installing OS loader might have been done with the help of UEFI as well by the way, - your UEFI installer application could do it.
For the kernel driver, it would be better off to follow the official documentation forgetting about both the "linux way" or "patents". imo.)

[Brendan]

Hi,

I have to support FAT32 in order to access the system partition from my OS (e.g. to install the bootloader in the first place). And also, of course, I want to support USB sticks and such.

Of course, I meant, at the OS loader level, where interaction with UEFI happens, you don't need to implement FAT code. And installing OS loader might have been done with the help of UEFI as well by the way, - your UEFI installer application could do it.

Yes. Apart from the OS installer (and possibly OS updates, if the boot loader is updated), the OS shouldn't touch (and shouldn't mount) the UEFI system partition at all. The OS installer can use UEFI's services (and can/should use 8.3 file names anyway).

For boot loader updates; before loading the kernel from your native file system, the boot loader can check for a "boot loader update" (in your native file system) and copy it to the UEFI system partition (using UEFI's services and UEFI's FAT) and adjust any "UEFI variables" so the new boot loader is used next time, and then start the new boot loader.

Also note that some UEFI systems (from Apple) don't follow the UEFI specs properly and use HFS+ instead of FAT; and if you always use UEFI's "simple file system protocol" for reading and writing files in the UEFI system partition you won't have a reason to care if the UEFI system partition is FAT or not.

For the kernel driver, it would be better off to follow the official documentation forgetting about both the "linux way" or "patents". imo.)

For the OS's FAT file system code; the main question is whether or not you're going to release a "finished" OS within the next 3 years. For anyone asking about FAT now; it's very likely that there's no problem - they can add support for LFN now without caring about patents (because the software isn't released), and then release the software later without caring about patents (because the patents would have all expired by then).

If you are going to release an OS soon; I'd just use 8.3 file names initially (and add support for LFN later), and if anyone complains that file names aren't very pretty (which is the only valid reason to care about LFN in the first place - it is a "decoration only" feature) just explain to them that it's Microsoft's fault (I'd even have a "Why are file names ugly when Microsoft's extremely inferior file system is used" page in the OS's documentation to inform people that Microsoft sucks).

Note: I suspect that as long as your code doesn't create files that have long file names you can use existing long file names (created by other software) without violating the remaining patents; but this ruins your ability to inform people that Microsoft sucks, so (partly to avoid the hassle of asking a lawyer about this possibility) I wouldn't bother.


Cheers,

Brendan

[simeonz]

Can't it be renewed before it expires for another millennia or such? (I am not competent to say if the renewal option can be/has been exhausted.)

There is an article circulating about a German court ruling from 2013, which however apparently (besides concerning only Europe) is of ambiguous legislative impact. I cannot understand how such legal dissonance can be achieved even on purpose.

Also, the USB sticks are getting larger and the 4GB file size limit becomes impractical. If exFAT comes into foray, it involves even longer patent lifespan

I genuinely cannot understand why USPTO has no responsibility, neither to justify, nor to revise their decisions - through court or otherwise. I mean, I kind-of understand that this has been left to civil proceedings after the fact, but this is such a bail-out. I don't understand why the US government shies from making USPTO more formally accountable for negligence and the review process stricter. I mean, issuing patents with such haste is not protecting invention investments, it is actually hurting the independent research and promotes patent trolling. May be it is done to better protect domestic R&D or to promote more rapid business scaling, but at what cost.

[mallard]

Firstly, Microsoft (along with most tech companies) makes no effort to "enforce" patents against non-commercial projects. It's extremely unlikely that they ever will (why waste time and money suing someone when your costs will exceed their entire net worth by a few orders of magnitude?)

Secondly, the unfortunate fact is that a general-purpose OS pretty much has to support FAT (-16,-32,ex-). Users will expect their other-OS-formatted storage devices to work and FAT is the standard filesystem for certain common storage devices (most notably SD cards) which are not guaranteed to work and may suffer reduced performance when using other filesystems.

If you ever get to the point where your OS is being used commercially in any serious way, you'll have access to professional legal advice. Licencing FAT is one of the easiest potential legal issues (and there are a great many others that you'll inevitably have to deal with) to resolve in this situation.

In summary; as usual with this sort of issue, there's no point in worrying.