Weekly Edition
Return to the Kernel page
| |||||||||||||
Long discussions about long names
When Microsoft filed its lawsuit against TomTom, it named two patents which
cover the VFAT filesystem. That, naturally, led to a renewed push to
either (1) get those patents invalidated, or (2) move away from
VFAT altogether. But some participants have advocated a third approach:
find a way to work around the patents which retains most of the VFAT
filesystem functionality while, with luck, avoiding any potential infringement of the
claims of the patent. But, as a recently-posted patch and the ensuing discussion
show, workarounds are not a straightforward solution even after the lawyers
have been satisfied.
The patch (written by Andrew Tridgell, but posted by Dave Kleikamp), comes with this changelog:
Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
When this option is enabled the VFAT filesystem will refuse to create new files with long names. Accessing existing files with long names will continue to work. Note that the changelog gives no clue as to why one might want this particular configuration option. What it probably comes down to is this: all of the claims in the VFAT patent refer to the creation of long file names. Reading filesystems with such names is not addressed by the patent. So the apparent thinking is that, even if the named patents really read on the Linux VFAT implementation, they will not read on a version which cannot create files with long names. It looks like a reasonable hack. Interoperability with all existing VFAT filesystems is retained, as long as one does not need to create files with long names on the Linux side. But systems which run kernels with this option enabled have a much lower probability of being found to infringe on the VFAT patents. It could, maybe, be an optimal solution. That said, the patch has been poorly received in the kernel development community. One of the reasons for this chilly reception, certainly, is general hostility to the software patent system and an associated lack of willingness to capitulate to it. Add in a generous helping of contempt for the VFAT patents - and their owner - in particular, and it is not surprising that some developers would rather not entertain "solutions" to this problem. The bigger issue, though, is that the patch does not describe the real problem that it is trying to solve. There has been a lot of fairly weaselly discussion from IBM developers on the lists, but none of them are willing to just come out and say what is going on. The closest, perhaps, is this message from Tridge:
However, if you are willing to concede that there are good
non-technical arguments for wanting to "get the VFAT out" then
choosing the best way to achieve that is most definitely a
technical decision, and that is what we can discuss here.
Unfortunately I am unable to discuss any of the non-technical reasons for why "get the VFAT out" might be a good idea in the first place. That is damn frustrating, but it is just how things are. All of this talk creates a certain feeling of patches being sent out to the list from some smoke-filled room deep within IBM headquarters. But, more importantly, the lack of information makes it impossible for the development community to determine whether the patch works. To make that decision, developers need to know what problem is being solved, and how the proposed solution makes the problem go away. But they don't have that information; instead, they simply have a patch which makes it possible to remove some functionality from the kernel. The subtext of the conversation is that some lawyers at IBM have, presumably, determined that a potential problem exists. That problem could be as simple as "this feature may attract infringement suits," independently of whether the patents are valid or whether Linux infringes on them. For any number of Linux users, the simple fact that the probability of being sued might go up is enough to inspire a search for alternatives. Also, presumably, these same lawyers have concluded that this particular workaround can resolve these worries. So now they believe it should be a part of the Linux kernel. But if the lawyers have really come to these conclusions, they are not saying so in any public forum. So the kernel developers are left wondering what is really going on. Are there really lawyers involved, or is this patch the work of a couple of programmers who have tried to create a solution (to a problem perceived by them) on their own? Why can't a company like TomTom just patch out the long-name functionality on their own if they are truly worried about it? Might the inclusion of this patch open the kernel up to other potential legal difficulties that we don't know about? Tridge's suggestion is that a prominent kernel developer needs to have a conversation with a lawyer before making the decision on this patch. That approach might lead to a correct outcome, but it will still leave most of the community in the dark and unhappy about it. It would appear that a better way is required. Currently, it is difficult for developers to determine whether a patent really applies to an algorithm in the kernel or not. If they conclude that there is a patent problem, these same developers are poorly placed to figure out what a minimal workaround might be. We need some help in this area. This particular problem is likely to come up again in other contexts; if we can put some sort of process in place for addressing legal issues, life will be easier in the future. IBM is said to have extensive documentation on the process of working around patents; for some strange reason, this information has never been released to the public. Unfortunately, determinations by lawyers are also unlikely to be released to the public, for any number of reasons. But developers need all of this information to respond properly to legal problems. There may be no alternative to some sort of process where a limited group of developers is given access to information under non-disclosure agreements. Such processes are distasteful, but they also are fairly common; many device drivers are created under non-disclosure agreements. The Linux Foundation currently has an NDA program intended to connect developers with hardware documentation. Perhaps a similar program (under the auspices of the Linux Foundation, or of another group like the Software Freedom Law Center or the Open Invention Network) could be created for access to legal information. As it is, we have a situation where some developers are talking to their employers' lawyers and nobody else has any real idea of what is going on. That will lead to slow, loud, and contentious attempts to solve legal problems. Given that we're almost certain to have more of these problems in the future, we might want to put some thought into finding a better way. (Log in to post comments)
Long discussions about long names Posted May 4, 2009 21:43 UTC (Mon) by martinfick (subscriber, #4455) [Link] There may be no alternative to some sort of process where a limited group of developers is given access to information under non-disclosure agreements. Such processes are distasteful, but they also are fairly common; many device drivers are created under non-disclosure agreements. Yeah, but how many are removed this way?
Long discussions about long names Posted May 4, 2009 23:07 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] I don't understand why the Rock Ridge Interchange Protocol (for storing long names on a CD-ROM file system) isn't considered prior art that invalidates the VFAT patents. The VFAT patents are written very broadly, and appear to cover essentially any mechanism that lets you store long names in a database with a name length limit. But this is exactly what Rock Ridge does. The standards documents have 1994 dates, and Microsoft didn't file until 1995.Now IANAL, so perhaps the VFAT patents are written in such a way as to be distinguishable from RRIP.
Long discussions about long names Posted May 5, 2009 0:52 UTC (Tue) by vmlinuz (guest, #24) [Link]
And here, ladies and gentlemen, we see an example of the species homo engineerius, displaying one of his typical traits by defining a problem, specifying a solution, and thereby declaring that the problem no longer exists.
The parasitical species homo lawyerus enjoys hunting alongside homo engineerius, because it is they who benefit from the gap in perception between problem+solution and solved-problem.
In other words, yes, you're absolutely right. The VFAT patents are almost certainly not valid, should not have been granted in the first place, and should be 'trivial' to defeat - 'trivial' in an engineering sense. In a legal sense, they are currently valid, and can therefore be used to generate millions of dollars in legal fees, intimidate smaller competitors, their engineers, customers, and investors, and generally cause expensive trouble.
Long discussions about long names Posted May 5, 2009 8:11 UTC (Tue) by vjeko (guest, #44412) [Link]
Fully agree. :D
Long discussions about long names Posted May 5, 2009 1:02 UTC (Tue) by k3ninho (subscriber, #50375) [Link]
The USPTO allows people to start using an invention publically, even selling it, before filing for a patent as much as a year later. Then also, they allow people to apply and say that they were the first to invent the thing in a patent owned by someone else.
It may well be that, following the original nullification of the LFN patents, Microsoft showed that they had invented and used privately (maybe for testing purposes) their long file name technology. Perhaps they showed proof that their invention was before the publication of Rock Ridge. Maybe there was some way that they could argue that the parallel development of Rock Ridge didn't render their method obvious to a person having ordinary skill in the art. But we'll never know because the hearing was private and so my (perhaps unreasonable) assumption is that the convicted monopolist cheated again.
Long discussions about long names Posted May 5, 2009 2:00 UTC (Tue) by drag (subscriber, #31333) [Link]
> The USPTO allows people to start using an invention publically, even selling it, before filing for a patent as much as a year later. Then also, they allow people to apply and say that they were the first to invent the thing in a patent owned by someone else.
Ya.. but in this case RockRidge is a extension to allow POSIX compatibility with the ISO 9660 file system. Its draft is RRIP 1.1.2 has copyright references from 1993.
So.. we are dealing with multiple patents here:
Then IBM holds a patent on FAT, too..
So only IBM and one of the patents exist prior to 1993... (I would of expected that one to be cross-licensed years ago with Microsoft from the OS/2 days)
But even possibly more important then RockRidge is UMSDOS. Which I remember quite fondly because that was used by the first Linux system I ever used.. which would be Zipslack.
UMSDOS is a method for making FAT POSIX-compliant filesystem for the sake of Linux compatibility. Quite nice for booting Linux from Zip drives.
It was started in 1992 and was accepted into the Linux kernel in 1994 with 1.1.36 until it was dropped in 2.6.11. If I remember correctly it stored extended information in extra hidden files.
-----------------------
So at least with UMSDOS it pre-dates all of Microsoft's patents. With Rockridge it only certainly pre-dates 2 of them.
-----------------------
Now everybody knows there are dozens and dozens of different manners to do stuff in software. This is one of the problems with software patents. To any problem there are thousands of solutions. (and each one is patentable)
So even though Rockridge and UMSDOS cover one way to have long file names it's likely that they do not do it in the same manner that is described in Microsoft's patents. Just a guess, I am not going to try to pretend to understand any of the patent language. So I suppose that would be why they don't immediately invalidate the patents.
----------------------
Probably the read-long-only patch would work great for embedded developers. Since they do not write to the FAT flash, generally, then it's only the users that really care about long file names. When you plug in a device to a PC then it's that PC's software that writes to the flash media and not any software on the device.
Just guessing, but it seems reasonable.
Long discussions about long names Posted May 5, 2009 3:49 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] But Microsoft didn't patent their own way of storing long names in a length-restricted system. None of the claims refers to anything in particular about their system. Rather, they patented pretty much the very idea of storing long names in a length-restricted system by encoding the filenames.
Long discussions about long names Posted May 5, 2009 22:48 UTC (Tue) by man_ls (guest, #15091) [Link] This same concept appears in Kernighan and Plauger's "Software Tools" as early as 1980. And in this text it is proposed as an exercise! Surely the obviousness test is not passed either.
Long discussions about long names Posted May 5, 2009 4:42 UTC (Tue) by Oddscurity (guest, #46851) [Link] So even though Rockridge and UMSDOS cover one way to have long file names it's likely that they do not do it in the same manner that is described in Microsoft's patents. Just a guess, I am not going to try to pretend to understand any of the patent language. So I suppose that would be why they don't immediately invalidate the patents.Still, reexamination in that case ought to have the effect of significantly limiting said patent's scope.
Long discussions about long names Posted May 5, 2009 13:56 UTC (Tue) by marcH (subscriber, #57642) [Link]
> The VFAT patents are written very broadly, and appear to cover essentially any mechanism that lets you store long names in a database with a name length limit.
Even when accepting that software patents make sense at all, how can such low level and poor engineering hacks be seriously considered as "non-obvious, inventive steps"? Does your electrician file a patent everytime he finds a clever wiring trick to workaround a badly designed panel? How can honest patent examiners and judges be fouled so easily and so persistently? Why is fixing this problem not as simple as bringing independent university professors in front of a court so they can affirm: "If one of my student had 'invented' this patented solution in a exam, he would have got an average or bad mark".
Has the whole world really gone insane? Or is just a minority of people incredily dragging everyone else in their insanity? In the latter case, can we please all come back to our senses and just ignore them instead of granting them way too much time and credit?
poor SW patents Posted May 5, 2009 16:22 UTC (Tue) by pflugstad (subscriber, #224) [Link] It's very simple: up until very recently, the US PTO assumed that anything worth must had been patented. So if a new patent application came in and it doesn't directly cover something already patented, then ergo, it must be "non-obvious and inventive". Couple this with SW patent examiners that were fresh out of college (or very inexperienced) and you have a recipe for all kinds of completely obvious and crap patents like pretty much all SW patents in the last 15 years.
poor SW patents Posted May 5, 2009 16:45 UTC (Tue) by k3ninho (subscriber, #50375) [Link]
I totally disagree. The case law describing the boundaries of patentability changed and explicitly allowed software patents, but the USPTO examiners completely forgot to look at non-patent textbooks and documentation when deciding what the 'state of the art' was. That meant that the bar for novelty and obviousness are way lower than they should be, resulting in many rubbish patents.
poor SW patents Posted May 5, 2009 16:58 UTC (Tue) by corbet (editor, #1) [Link] Interestingly, one of the things that came up at the software patent conference I attended in March is that, as patent examiners gain more experience on the job, they tend to approve more patents. It's the new, green ones who ask the hardest questions. It's not a matter of inexperience; it's more one of being sucked into a system which sees its mission as the granting of patents.
Career paths Posted May 5, 2009 18:15 UTC (Tue) by dmarti (subscriber, #11625) [Link] I have met former patent examiners now working for applicants. How many examiners go on to jobs at firms seeking patents? Is approving a patent a way to apply for a job in the private sector, like approving a big contract for DoD is a way to apply for a job at a military contractor?
poor SW patents Posted May 5, 2009 23:15 UTC (Tue) by marcH (subscriber, #57642) [Link]
> It's not a matter of inexperience; it's more one of being sucked into a system which sees its mission as the granting of patents.
So, even if immoral and barely legal, it is still fine as long as the "system" and the "mission" want it. Translation: we are doomed.
poor SW patents Posted May 9, 2009 20:47 UTC (Sat) by giraffedata (subscriber, #1954) [Link] It's not a matter of inexperience; it's more one of being sucked into a system which sees its mission as the granting of patents.So, even if immoral and barely legal, it is still fine as long as the "system" and the "mission" want it. Translation: we are doomed No one here as said anything about it being fine.
Long discussions about long names Posted May 5, 2009 2:17 UTC (Tue) by qg6te2 (guest, #52587) [Link] So the kernel developers are left wondering what is really going onThe intent of the patch and what it works around is as clear as a summer's day. I seriously doubt the kernel developers are living under a rock. Any whining along the lines of "patents are evil and hence we're not going to capitulate" is missing a big dose of (current) reality. Sure it would be nice to invalidate the VFAT patents, but until this is done the further adoption of Linux (by device makers such as TomTom) is in jeopardy.
Long discussions about long names Posted May 5, 2009 5:27 UTC (Tue) by kripkenstein (subscriber, #43281) [Link]
I agree that it should be obvious that the issue at hand is patents. But that is just part of the relevant information.
One question is, does this legally solve the problem? If it is on very shaky ground, maybe it isn't worth adding the code.
Anther question is, what downsides are there? IANAL, but perhaps including this patch - which has no purpose but one related to patents - signifies implied agreement that the VFAT patents are valid (or at least such an argument can be made by the other side). Which might make any infringement 'willful', with significantly higher penalties.
All of this information is unavailable to the kernel developers.
Long discussions about long names Posted May 5, 2009 17:38 UTC (Tue) by clugstj (subscriber, #4020) [Link]
The point isn't that we don't know why the patch was created, the point is that the creators won't explain themselves. This, to me, should make the patch unacceptable. Full disclosure is essential for "Open Source" (or any collaborative endeavor) to be successful. Accepting this patch would be like having a loaded gun pointing at yourself and then fiddling with the trigger.
Long discussions about long names Posted May 5, 2009 22:59 UTC (Tue) by qg6te2 (guest, #52587) [Link] [T]he point is that the creators won't explain themselves. This, to me, should make the patch unacceptable.The above is grandstanding. Does it really need to be spelled out why the patch was created? Accepting this patch would be like having a loaded gun pointing at yourself and then fiddling with the trigger.I'm not sure I follow. Is there an implication that by accepting the above patch we're implicitly accepting there is a patent problem? I seriously doubt this falls into the arena of a lawyer -- does every patch that goes into the Linux kernel go through a lawyer first? We're free to modify the kernel however we see fit, and some people would like functionality where long filenames are not created. The reasoning as to why they need it is an orthogonal matter -- the fact that there is a need is sufficient in itself. (It could be argued that things like TOMOYO are a waste of time, yet some people still want it in the kernel.)
Long discussions about long names Posted May 5, 2009 8:14 UTC (Tue) by bfeeney (guest, #6855) [Link]
Why don't people use the UDF filesystem? It's originally for DVDs, but can be used on any device, and Linux, Mac and Windows all support it. I once had a UDF formatted USB memory stick and it worked fine.
In the short term though, no FAT access presumably means not being able to use any currently available digital camera with Linux without violating some patent somewhere. Are all the kernel developers about to sell off their cameras and go back to film? Or are they going to ignore the law, and let Microsoft ignore the law and copy and paste useful bits of the kernel into Windows?
UDF sounds great ... Posted May 5, 2009 9:08 UTC (Tue) by Felix_the_Mac (guest, #32242) [Link]
why is it not The Solution (tm)?
Long discussions about long names Posted May 5, 2009 9:56 UTC (Tue) by bangert (subscriber, #28342) [Link]
have you tried it?
because it doesnt have write support on windows XP, MacOSX 10.4 and linux eats your disk, when
vfat sucks - but UDF isn't close to be a solution.
Long discussions about long names Posted May 5, 2009 13:05 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
Not to mention that it doesn't solve the problem of using J. Random Person's USB stick that's handed to you and that you otherwise don't control. I can't imagine a dialog saying "This device has an incompatible filesystem format. Convert to UDF? [Y] [N]" going over particularly well.
Long discussions about long names Posted May 5, 2009 13:28 UTC (Tue) by bfeeney (guest, #6855) [Link]
Ah, I just had a look on Wikipedia
(http://en.wikipedia.org/wiki/Universal_Disk_Format#Native...), and I think the reason I could write under Windows XP was because Dell had installed SonicDLA, which adds write-support to Windows XP machines.
MacOS 10.5 and Windows Vista both have write-support, which is encouraging,
Long discussions about long names Posted May 5, 2009 13:00 UTC (Tue) by brother_rat (subscriber, #1895) [Link] The DCIM naming convention works entirely within the 8.3 short filename limit, so that won't be an issue.I imagine there will be similar problems with transferring music etc. to FAT based MP3 players though.
Long discussions about long names Posted May 5, 2009 13:30 UTC (Tue) by drag (subscriber, #31333) [Link]
Well it depends. If the customer is writing files themselves to the device, like over USB mass storage, then it'll work fine... It'll be their OS that does the long filename writing. Reading long filenames isn't covered in the patents.
If they are transmitting filenames over wireless, MTP (media transfer protocol), Pictbridge, or something like that then the system can write to a non-FAT filesystem easily enough that supports long filenames.
Trouble comes when you want to support a combination of things.. like support USB Mass storage AND MTP.
Long discussions about long names Posted May 7, 2009 9:30 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Because the USB sticks that I get from my customers/colleagues/friends are VFAT formatted and I need to copy files from and to these sticks.
And, no, I can't say to them that they shall format their USB sticks with UDF or ext3 or anything else.
Long discussions about long names Posted May 9, 2009 2:44 UTC (Sat) by stevef (subscriber, #7712) [Link]
Experimenting with UDF on USB storage devices shows that many (perhaps all) Windows and even Linux don't make it easy to format this type of device as UDF. This may be just bugs in various operating systems, but they are common. I think we are stuck with FAT32 until the volume limit becomes unacceptably small.
No Software Patent Posted May 5, 2009 13:39 UTC (Tue) by patrick_g (subscriber, #44470) [Link]
This problem is a US problem only (well at least it's not an european problem because we don't have software patent here).
Why the kernel should be modified for a problem in one country ? If there is another country with a more stupid law we have to modify the kernel one more time because of the lowest common denominator ?
No Software Patent Posted May 5, 2009 13:59 UTC (Tue) by marcH (subscriber, #57642) [Link]
> Why the kernel should be modified for a problem in one country ?
Because this specific country rules the whole world, especially the whole computing world. At least for now.
No Software Patent Posted May 5, 2009 14:26 UTC (Tue) by patrick_g (subscriber, #44470) [Link] > Because this specific country rules the whole world, especially the whole computing world.I've googled for "map kernel linux world" and the result is here : http://labor-liber.org/images/developers.map.jpeg According to this map (Ok this is Debian devs and not kernel hackers) it's difficult to conclude that US rules the whole computing world.
No Software Patent Posted May 5, 2009 14:34 UTC (Tue) by drag (subscriber, #31333) [Link]
Well..
A) Most countries are not the USA, but most developed countries have patent treaties with the USA. Most companies producing software and hardware have USA as a big hunk of their target market.
B) The discussion coming from IBM and friends is adding a kernel option to disable long file name write support. Nobody is talking about eliminating it completely or by default.
Fix the real bug not the symptom Posted May 5, 2009 18:12 UTC (Tue) by copsewood (subscriber, #199) [Link]
Perhaps a more global compile time option is needed so that US Linux users or distributors who are paranoid about being sued could compile a kernel with anything anyone claims as a software patent compiled out of it, or even a milder compile option which removes only what is claimed as patents by technology companies or trolls likely to sue.
The rest of the world and those in the US willing to take the risk can continue to have kernels compiled without this option based upon sound technical as opposed to broken legal considerations. As Linux and related computing and electronics jobs migrate to saner countries without broken patent regimes, the real bug can then be fixed: by unemployed US engineers demanding amendment of patent laws of their representatives which don't result in the export of US jobs.
No Software Patent Posted May 5, 2009 18:21 UTC (Tue) by nhippi (subscriber, #34640) [Link]
> This problem is a US problem only (well at least it's not an european problem because we don't have software patent here).
1) Unfortunately we do have a patent problem in EU. Lots of software patents are granted (notice where mp3 patents were filed first) and nobody has dared to try them in court.
instead of crying on the loss of the ridiculous hack called vfat, we should be creating the PNG equilavent of removable storage filesystems.
Why does the patch use ifdef statements Posted May 5, 2009 14:55 UTC (Tue) by southey (subscriber, #9466) [Link]
The patch uses a lot of ifdef statements so does that mean that the code to create the long names still present in the code?
If so, then what is the point since under the GPL you will have to distribute the code that appears to violate the patent anyhow?
Why does the patch use ifdef statements Posted May 6, 2009 17:13 UTC (Wed) by nhippi (subscriber, #34640) [Link]
You don't violate patents by copying or distributing. You violate patents by using the patented method (commercially). Thus if the object code doesn't implement the patented method, you can still distribute the sourcecode (that you don't compile).
This is why the lame mp3 encoder is distributed source-only by upstream.
IANAL and all the other disclaimers.
Why does the patch use ifdef statements Posted May 9, 2009 21:03 UTC (Sat) by giraffedata (subscriber, #1954) [Link] You violate patents by using the patented method (commercially). You also violate patents by making or selling a device that uses the method. And the use doesn't have to be commercial. The point is that if I sell you a GPS device that can read VFAT, I need a license for any patents that cover VFAT. I don't even think ifdefs are necessary. Anything that prevents the VFAT code from running is probably just as effective at making VFAT patents irrelevant. But a kernel build configuration option might make a manufacture more confident that he isn't accidentally violating a patent.
Long discussions about long names Posted May 5, 2009 15:33 UTC (Tue) by branden (subscriber, #7029) [Link]
Hmm, replying to specific messages in the thread is broken in my browser
(Konqueror 3.5.9); I have to "Post a comment".
Patent claims are in the public domain; it is implementations that are
Thus, for compiled languages at least, it's perfectly okay to IFDEF code
Long discussions about long names Posted May 5, 2009 15:36 UTC (Tue) by branden (subscriber, #7029) [Link]
...and after posting one reply, magically the "Reply to this comment"
buttons appear.
Anyway, my response was to Southey.
Reply to comments button missing (off-topic) Posted May 5, 2009 18:23 UTC (Tue) by pr1268 (subscriber, #24648) [Link] I, too, have seen missing "Reply to this comment" buttons on LWN pages (for the past several years now, using various releases of Firefox). I think that refreshing the page restores these buttons. Any idea what's going on?
Reply to comments button missing (off-topic) Posted May 5, 2009 18:24 UTC (Tue) by pr1268 (subscriber, #24648) [Link] s/seen/experienced/ I clicked the wrong button that time. :(
Reply to comments button missing (off-topic) Posted May 5, 2009 18:30 UTC (Tue) by corbet (editor, #1) [Link] My guess is that this happened immediately after you logged into the site. It's a matter of getting the right stylesheet; the old, anonymous-user sheet doesn't time out for a minute or so after login. I know how to fix it, I think; it just kind of fell off the list. Putting it back now.
Reply to comments button missing (off-topic) Posted May 5, 2009 21:35 UTC (Tue) by jhhaller (subscriber, #56103) [Link]
It's not just after logging into the site, as I remain logged in over browser sessions. I must still be logged in, as this was subscriber-only at the time I read it. I needed to refresh the page to see the comment button. Perhaps the anonymous style sheet gets pushed early in the visit before anything verifies the login cookie and changes the style sheet.
Long discussions about long names Posted May 5, 2009 16:04 UTC (Tue) by iabervon (subscriber, #722) [Link]
It seems to me like the particular patch is kind of overly subtle. It looks to me like the option doesn't remove the kernel's ability to create such filenames (using the patented technique), but rather just makes the kernel return an error instead of actually deciding to create such a filename. I can't really see a point to such a patch; sure, it makes it impossible to prove that your device violates the patent by demonstrating that it actually creates such files, but with the code that would do it in the source, compiled, and installed, and just unreachable, I think it's unlikely that this detail would affect whether a patent suit could get filed and not get dismissed. And, since everybody seems to agree that, if someone were willing and able to get to a final judgment, the patents wouldn't hold up, there's no point in also not infringing them for a subtle reason.
What I don't understand is why the option isn't there to drop the code that interacts with the long filename content entirely; it seems like it should be easy to make Linux treat these files like DOS did, where files seem to have odd short names (but are otherwise normal), and the hidden files are left alone. I can't think of any device that doesn't need to create files with arbitrary names but does care about the names of existing files with arbitrary names (MP3 players often want to use files that do have arbitrary names, but they identify the files with metadata from the files themselves, not from the filesystem).
I think this would also be cleaner in the code, and make it easy enough to show that the source you compiled to put on your device didn't contain any code that infringes the patent.
Long discussions about long names Posted May 5, 2009 17:15 UTC (Tue) by bfields (subscriber, #19510) [Link] I can't really see a point to such a patch; sure, it makes it impossible to prove that your device violates the patent by demonstrating that it actually creates such files, but with the code that would do it in the source, compiled, and installed, and just unreachable, I think it's unlikely that this detail would affect whether a patent suit could get filed and not get dismissed. I think of a patent as a monopoly on the commercial exploitation of an invention. It would be difficult for someone to argue that your GPS device's unreachable long-filename-creation code is really a selling point of the device.
Long discussions about long names Posted May 5, 2009 17:39 UTC (Tue) by iabervon (subscriber, #722) [Link] It would be difficult for someone to argue that your GPS device's unreachable long-filename-creation code is really a selling point of the device. I suspect that the TomTom GPS's long-filename-creation code was actually unreachable, simply because it probably wouldn't create files for direct human use, and developers would tend to pick something simple to save configuration in. But my point was that someone could sue you over having a long-filename-creation feature, and it would require arguing back and using evidence to demonstrate that it was unreachable, at which point you've wasted a bunch of money, which is what this exercise is intended to prevent. It's not about being right or not, it's about being so obviously right that there's no way the other side can claim that they even thought that they had a case, and the court blames them for wasting its time.
Long discussions about long names Posted May 6, 2009 11:39 UTC (Wed) by jimbo (subscriber, #6689) [Link]
Couple of Questions I'd like to be considered.
If a different algorithm were used in the Linux VFAT fs driver to generate the short filename, would the patent no longer be infringed?
Failing this:-
Who will bell the VFAT cat?
--
NDAs and lawyers Posted May 7, 2009 15:16 UTC (Thu) by Ross (guest, #4065) [Link]
> The Linux Foundation currently has an NDA program intended to connect developers with
hardware documentation. Perhaps a similar program (under the auspices of the Linux Foundation, or of another group like the Software Freedom Law Center or the Open Invention Network) could be created for access to legal information.
But the problem isn't that the information the lawyers might have needs to be kept from third
[There seems to be a bug with posting. LWN kept saying I was trying to post an empty comment,
Linux developers need a lawyer of their own Posted May 20, 2009 14:11 UTC (Wed) by bkuhn (subscriber, #58642) [Link]
Ultimately, the Linux developers should have good legal counsel that represents their interest as individual developers to answer these questions. It probably wouldn't yield the full disclosure corbet is calling for, but it will give the Linux developers assistance from lawyers representing their interests.
It's worth noting here that the Linux Foundation legal team has been quite clear that they don't represent the individual Linux developers. So, Linux developers should seek legal counsel elsewhere, presumably. SFLC (an organization that employees me, BTW) is available, but it is certainly not the only option for this.
|
|||||||||||||
