In brief [LWN.net]

By Jonathan Corbet
July 8, 2009

VFAT. The VFAT patent workaround discussion continues, focused primarily on two points. The first is whether it is appropriate to put patent workarounds into the kernel. The main opposition comes from Alan Cox, who asserts that individual companies need to find ways to navigate around country-specific legal landmines; workarounds for these problems should not find their way into the upstream code. Besides, Alan claims that vendors who are worried about patent suits will not be satisfied with a kernel configuration option; they will hack out the code entirely.

Meanwhile, Andrew Tridgell continues to push for the use of workarounds - a strategy which has worked well for Samba. Tridge says:

The only weapon we have to fight patents right now is our collective ability to find smart solutions to problems. The "every vendor for themselves" approach that you seem to be so keen on makes that collective approach pretty much impossible.

How this side of things will play out remains to be seen. Meanwhile, there has also been an extensive technical discussion focused on interoperability problems caused by the patch. Some of these problems, as explained by Tridge, are really the result of various existing VFAT mount options; in some cases, even without the patch under discussion, Linux will create long name entries for names which appear to fit the 8.3 format. This kind of interoperability problem has existed for quite some time.

Mount options do not explain all of the problems, though. It seems that there are some music players out there which understand long names, but which still require that valid 8.3 names exist. There are also difficulties with Windows98 which may (or may not) be resolved by changes in how the patch fills the 8.3 information. Tridge suggests that Windows98 is old enough to not be worth supporting, but not all agree on that.

The checkpatch police. Alan Cox recently proposed the addition of a new event interface for the virtual terminal driver. Ingo Molnar responded with a list of errors from the checkpatch.pl script, requesting that they be fixed. Alan's reply was:

Given the code doesn't currently *work* yet but is a first draft its hardly important and there are better uses of time than playing checkpatch policeman.

What followed was an extensive discussion on the value of checkpatch.pl, whether code should be checkpatch-clean even before first submission, whether coding style problems should be fixed piece-by-piece as other work is done, and so on. Ingo would like to see coding style issues dealt with early on; among other things, consistent coding style makes reviewing the code much easier. Alan sees that sort of cleanup as a distraction, to be done after more substantial issues (which are not lacking in the TTY code) have been dealt with.

Consensus was not to be had in this discussion; expect this to be one of those themes which returns regularly to linux-kernel.

(Log in to post comments)

Patented code

Posted Jul 9, 2009 5:19 UTC (Thu) by jmorris42 (subscriber, #2203) [Link]

Logically Mr. Cox would be wrong. Patents by their nature disclose the patented tech so the presence in the source of what after all is only a description of the 'protected invention' until it is compiled into a working 'device' should not be a problem if the shipped binary package turns it off.

In reality RedHat was so terrified by this sort of thing they broke their 'pristine source' rule with xmms and shiped an 'original' tarball that had all support for mp3 playback excised. Even though xmms itself didn't support mp3, it called out to a library in another package for the actual codec, just having xmms know about mp3 files and have an option to link against the mp3 libs was enough to require edits.

Darned if a mere mortal such as myself can understand it but until we decide enough is enough and kill all the lawyers we are stuck living in the asylum they have made of the world.

VFAT

Posted Jul 9, 2009 15:49 UTC (Thu) by dmadsen (guest, #14859) [Link]

Because there are so many implementations of FAT-using code out there, I believe that any software "patent workaround" will break *some* device.

The discussion is not "Does this workaround break anything", but rather "how many things does this break (and how important are they)". If you're the owner of something that no longer works, I'd say you'd think it was pretty important!

While it's easy for a developer of new software to disregard old software (yes, I've done it myself but learned my lesson), we all know that there's quite a bit of old software that's still out there, running. <cough> COBOL. Old software does NOT just die regardless of manufacturer support. (Hint: tell me there's no Linux 2.2 out there anymore!). It would be nice to preserve at least data transfer from/to old platforms using a FAT filesystem as a vehicle. (BTW, I know of someone who just upgraded from Win 95 to Win 98 on a special-purpose machine. He's ecstatic!)

I am not "in the know" on these issues, but I can't help but wonder:

1) This is a legal issue, not a software issue. Addressing it via software is a broken process. Yes, I know, it's not the first time. That makes it even sadder.

2) While some issues aren't worth fighting for, given that this is relatively major, isn't *this one* worth fighting for? If reliable data exchange with a zillion devices out there isn't major, what is?

3) What happened to the FLOSS patent pools and the you-sue-me-and-I'll-sue-you-back strategy that was supposed to guard against major issues like this? Didn't Sun and IBM have patent pledges? Isn't it known that MS infringes some of these just as they claim Linux infringement on theirs?

VFAT

Posted Jul 12, 2009 0:31 UTC (Sun) by speedster1 (subscriber, #8143) [Link]

> The discussion is not "Does this workaround break anything", but rather "how many things does this break (and how important are they)". If you're the owner of something that no longer works, I'd say you'd think it was pretty important!

> 2) While some issues aren't worth fighting for, given that this is relatively major, isn't *this one* worth fighting for? If reliable data exchange with a zillion devices out there isn't major, what is?

Luckily, reliable data exchange is not lost with this patch; the workaround is being implemented as a config option.

So, people who are more concerned about reliable data exchange with their old devices or OS than about having a visit from Microsoft's laywers...

can just get a kernel with the patent workaround disabled!

I'm sure some there will be some community-supported distributions that ship kernels with workaround disabled, so such users won't even be forced to compile a custom kernel :)

That is not to say that Tridge's efforts to tune the workaround for greatest compatibility are not worthwhile; it will probably be on by default for users of vendor-supplied kernels (e.g. Red Hat, Mandriva, SUSE).

On the other hand, if eventually Microsoft starts sending threatening letters to kernel developers over this VFAT nonsense, it would certainly be time for Linux-friendly companies to join the fray with their patent pools...

VFAT

Posted Jul 12, 2009 2:54 UTC (Sun) by jlokier (guest, #52227) [Link]

If you copy some files on to a flash drive to take somewhere, then go there, then find you can't read those files on the recipient's device, it's too late to download and install a new kernel on the machine you left behind before you travelled...

VFAT

Posted Jul 12, 2009 2:15 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

1) This is a legal issue, not a software issue. Addressing it via software is a broken process.

It's a software issue: we're distributing software that gets people sued when they use it. It makes sense to look at whether we could engineer alternative software that doesn't.

2) While some issues aren't worth fighting for, given that this is relatively major, isn't *this one* worth fighting for?

We are fighting on that front as well. We got the VFAT patents invalidated at one point. (Unfortunately, they got revived). TomTom is defending its use of Linux VFAT facilities.

VFAT

Posted Jul 12, 2009 11:55 UTC (Sun) by willy (subscriber, #9762) [Link]

> TomTom is defending its use of Linux VFAT facilities.

Alas, no. TomTom and Microsoft settled on March 30th. TomTom ended up paying. http://www.theregister.co.uk/2009/03/30/microsoft_and_tom...

VFAT

Posted Jul 16, 2009 4:45 UTC (Thu) by efexis (guest, #26355) [Link]

"What happened to the FLOSS patent pools and the you-sue-me-and-I'll-sue-you-back strategy that was supposed to guard against major issues like this?"

IIRC, that's actually what sparked this... Tom Tom sued Microsoft, Microsoft used their patent pool "defensively" to sue back. That being the case, the biggest defense against MS suing for software patent infringement is simple: don't get in a patent war with them. In fact, you shouldn't be suing anyone for anything that you're doing yourself (heh, unless you're Wells Fargo of course!)

VFAT

Posted Jul 16, 2009 9:09 UTC (Thu) by Los__D (guest, #15263) [Link]

Errr, it's the other way around, AFAIK

Microsoft sued TomTom, TomTom countersued a month later. They settled a fortnight after that.

VFAT

Posted Jul 18, 2009 6:26 UTC (Sat) by efexis (guest, #26355) [Link]

Ah, yes, looks like you're correct... well that certainly invalidates everything I've said!

Compatibility

Posted Jul 12, 2009 3:14 UTC (Sun) by jlokier (guest, #52227) [Link]

even without the patch under discussion, Linux will create long name entries for names which appear to fit the 8.3 format. This kind of interoperability problem has existed for quite some time.

This is mistaken. It did not create too many long names; it created too few. It's a good thing to create long name entries for certain names which fit into 8.3, because the long name entry preserves the name's case when reading it, including reading by another Linux. Windows does the same thing.

The only old VFAT interoperability problem I'm aware of, until recently, is that Linux did not create long name entries in enough cases, with the default mount option, shortname=lower. It only affected Windows 95/98/ME (and maybe CE), not NT derivatives. With shortname=mixed, Linux was compatible with all different versions of Windows, which is better than Windows itself.

The interoperability concern found with Windows 98 likely applies to Windows ME too, as that's in the same family. That was released about the same time as Windows 2000. We don't yet know if it affects Windows CE, and that's being used in current devices - PDAs and phones.

Of course there's nothing that can be done for devices which only read 8.3 short names, when you create a file with a long name or mixed-case name. It's inherent in the patch that short file names are never created when a long name is created. The only way to interoperate is for applications to stick to the 8.3-compatible pattern (including case) when creating new files, which in most cases is reasonable.