VFAT patent avoidance and patent workarounds

Back in May, the proposed "no long file names" patch got a hostile reception on the linux-kernel mailing list. This patch, presumably aimed at working around Microsoft's VFAT patents, made the kernel unable to create long file names on VFAT filesystems. It was seen by many as a reduction in functionality without any sort of well-explained justification, and it was not merged. Now there is a new patch which takes a different approach on both the technical and political fronts. Its fate remains to be seen, but it demonstrates a method for dealing with patents which is worthy of wider consideration.

The VFAT format is undeniably a hack. It allows the FAT filesystem to be extended beyond its traditional 8.3 upper-case file name limit by creating additional file entries - which look invalid to older filesystem implementations - containing a longer name. Depending on the length of the name, several of these additional entries may need to be placed in the directory ahead of an entry holding a traditional short file name. The first patch simply disabled the ability to create these long name entries; since the relevant patents all make claims about the creation of long file names, a system which does not create them cannot infringe. A Linux kernel with this patch in place (and enabled at configuration time) would be able to read filesystems with long names, but it would be unable to add any more long names to it.

The new patch takes an entirely different approach based on a close reading of the patent. In truth, it's not the creation of long file names which is covered; instead, the patent claims the technique of creating both long and short names. So the current patch takes away that ability; it can create a long name or a short one, but never both for the same file. The result is almost complete interoperability with other systems using long names; the one exception is archaic systems which only have short name capability. Such systems are relatively rare, though.

There is an interesting trick required to make all this work. The FAT format requires that the short-name directory entry be present, so Linux cannot simply leave it out. Instead, that entry is created with a name which is clearly invalid. The "short name" starts with a space and a NUL byte, continues with some random characters, and finishes with an extension containing a slash. The end result cannot be listed as part of the directory, cannot be used to open the file, and may not even be unique within the directory. It is, thus, not a name for the file.

Assuming that reasoning holds up in court, this patch creates a kernel which cannot be said to infringe upon the VFAT patents. Given that the patch has clearly seen some legal review (see the associated FAQ), and given that it comes from a source (IBM) with extensive experience and expertise in patent law, its chances are probably best described as "better than average."

There are still those who will question this whole approach, though. Changing the kernel in a way which reduces interoperability looks like an acknowledgment of the validity of the patents; wouldn't it be better, some ask, to put those resources into fighting the patents instead? For those who do not wish to play this game at all, putting hackish-looking workarounds into the kernel seems like the wrong way to go.

The problem is that invalidating a patent is a long, expensive, and uncertain undertaking. "Long" means years, "expensive" means potentially millions of dollars, and "uncertain" means exactly that. The US patent system (which is of the most relevance in situations like this) is unwilling to invalidate patents in general; even when it does, the patent is merely put back into the review process from which it can arise, zombie-like, to terrorize again. In the mean time, companies subject to attacks under that patent are suffering under extreme legal costs and potential injunctions which keep them from selling their products. For most companies, that's a death sentence. It is unsurprising that most companies lacking a massive patent portfolio of their own quickly settle when subjected to patent attacks.

[PULL QUOTE: If we choose not to make use of patent workarounds, we will clearly increase our chances of losing the larger fight. END QUOTE] Workarounds are a worthwhile alternative to settling and long battles of attrition. A proper workaround effectively invalidates a patent without all of the associated costs. This is especially true if the workaround so clearly avoids the target patent that any attacks can be disposed of quickly via summary judgment. In any long fight, one must choose battles carefully; workarounds can allow us to avoid numerous costly battles and focus our energies on truly disruptive patents. If we choose not to make use of patent workarounds, we will clearly increase our chances of losing the larger fight.

The FAQ makes an important point related to workarounds that the community should hear: publicly questioning the effectiveness of a workaround can have fatal results. The goal of a good workaround is to avoid a patent infringement trial altogether. If a patent holder can point to email from prominent community members suggesting that a given workaround might, in fact, not avoid the patent, said holder may create enough doubt in a judge's mind to defeat a summary judgment motion and force a case to go to trial. Most defendants cannot afford that, and will thus be forced to capitulate. The right way to express concerns of this nature is via private communication.

We have been hearing warnings about software patents for many years, but, for most of those years, the threat seemed distant. During that time, it is said, numerous companies have been quietly shaken down for patent money. The TomTom suit brought that process out into the open, making it clear that powerful companies are willing and able to press patent infringement claims against companies using Linux. The sad fact is that we cannot opt out of playing this game, so we're simply going to have to get good at it. This patch is part of the process of figuring out how this game - so much of which is played via secret maneuvers - can be handled in an open community. It also represents a serious attempt by a large player in the patent game to help the community avoid a couple of threatening patents. Perhaps it's not the patch we want to merge in the end, but it (and its goals) deserve serious consideration.

---

(Log in to post comments)

Perhaps it could be fruitful to recall the origin of the
authority for Congress to create patent and copyright law.
It's only a few lines in the Constitution:

That's all. Clearly (to me), this was not intended to allow
Congress to create laws that license neo-luddites to abuse
said laws to impede the "Progress of Science
and useful Arts" for any reason -- perhaps least of all
as a means of hobbling competition with their own outdated
and/or inferior technology.

Nor, it seems clear to me, was this provision of the Constitution
meant to permit or nurture the existence of patent-trolls, who if
anything impede rather than "Promote the Progress of Science and
useful Arts," and who are generally neither Authors or Inventors.

Exclusive Right can not be interpreted as a right to enforced
dis-use and be consistent with Promotion of Progress!

I am against software patents, but a practical way to "Promote
the Progress of Science and the useful Arts" might be to provide
legal immunity against patent infringement claims for non-profits
and academic and research entities, as well as entrepreneurial
businesses grossing less than say a million dollars.

After some product containing a patented entity is making real
money in the market, then the first to achieve this could have special
rights to a cap on royalties, and others would have to negotiate with
the patent owner or stay under the million gross limit.

This would provide incentives Promoting Progress through competition.
And FLOSS could promote progress as it does now, through cooperation.