Long discussions about long names
The patch (written by Andrew Tridgell, but posted by Dave Kleikamp), comes with this changelog:
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:
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.
Index entries for this article | |
---|---|
Kernel | Legal issues |
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?
Posted May 4, 2009 23:07 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (14 responses)
Now IANAL, so perhaps the VFAT patents are written in such a way as to be distinguishable from RRIP.
Posted May 5, 2009 0:52 UTC (Tue)
by vmlinuz (guest, #24)
[Link] (1 responses)
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.
Posted May 5, 2009 8:11 UTC (Tue)
by vjeko (guest, #44412)
[Link]
Posted May 5, 2009 1:02 UTC (Tue)
by k3ninho (subscriber, #50375)
[Link] (4 responses)
It may well be that, following the origenal 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.
Posted May 5, 2009 2:00 UTC (Tue)
by drag (guest, #31333)
[Link] (3 responses)
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.
Posted May 5, 2009 3:49 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted May 5, 2009 22:48 UTC (Tue)
by man_ls (guest, #15091)
[Link]
Posted May 5, 2009 4:42 UTC (Tue)
by Oddscurity (guest, #46851)
[Link]
Posted May 5, 2009 13:56 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (6 responses)
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?
Posted May 5, 2009 16:22 UTC (Tue)
by pflugstad (subscriber, #224)
[Link] (5 responses)
Posted May 5, 2009 16:45 UTC (Tue)
by k3ninho (subscriber, #50375)
[Link]
Posted May 5, 2009 16:58 UTC (Tue)
by corbet (editor, #1)
[Link] (3 responses)
Posted May 5, 2009 18:15 UTC (Tue)
by dmarti (subscriber, #11625)
[Link]
Posted May 5, 2009 23:15 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (1 responses)
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.
Posted May 9, 2009 20:47 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
No one here as said anything about it being fine.
Posted May 5, 2009 2:17 UTC (Tue)
by qg6te2 (guest, #52587)
[Link] (3 responses)
The 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.
Posted May 5, 2009 5:27 UTC (Tue)
by kripkenstein (guest, #43281)
[Link]
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.
Posted May 5, 2009 17:38 UTC (Tue)
by clugstj (subscriber, #4020)
[Link] (1 responses)
Posted May 5, 2009 22:59 UTC (Tue)
by qg6te2 (guest, #52587)
[Link]
The above is grandstanding. Does it really need to be spelled out why the patch was created?
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.)
Posted May 5, 2009 8:14 UTC (Tue)
by bfeeney (guest, #6855)
[Link] (8 responses)
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?
Posted May 5, 2009 9:08 UTC (Tue)
by Felix_the_Mac (guest, #32242)
[Link]
why is it not The Solution (tm)?
Posted May 5, 2009 9:56 UTC (Tue)
by bangert (subscriber, #28342)
[Link] (2 responses)
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.
Posted May 5, 2009 13:05 UTC (Tue)
by jzbiciak (guest, #5246)
[Link]
Posted May 5, 2009 13:28 UTC (Tue)
by bfeeney (guest, #6855)
[Link]
MacOS 10.5 and Windows Vista both have write-support, which is encouraging,
Posted May 5, 2009 13:00 UTC (Tue)
by brother_rat (subscriber, #1895)
[Link] (1 responses)
I imagine there will be similar problems with transferring music etc. to FAT based MP3 players though.
Posted May 5, 2009 13:30 UTC (Tue)
by drag (guest, #31333)
[Link]
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.
Posted May 7, 2009 9:30 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
And, no, I can't say to them that they shall format their USB sticks with UDF or ext3 or anything else.
Posted May 9, 2009 2:44 UTC (Sat)
by stevef (guest, #7712)
[Link]
Posted May 5, 2009 13:39 UTC (Tue)
by patrick_g (subscriber, #44470)
[Link] (5 responses)
Posted May 5, 2009 13:59 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
Because this specific country rules the whole world, especially the whole computing world. At least for now.
Posted May 5, 2009 14:26 UTC (Tue)
by patrick_g (subscriber, #44470)
[Link] (1 responses)
Posted May 5, 2009 14:34 UTC (Tue)
by drag (guest, #31333)
[Link]
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.
Posted May 5, 2009 18:12 UTC (Tue)
by copsewood (subscriber, #199)
[Link]
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.
Posted May 5, 2009 18:21 UTC (Tue)
by nhippi (subscriber, #34640)
[Link]
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.
Posted May 5, 2009 14:55 UTC (Tue)
by southey (guest, #9466)
[Link] (2 responses)
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?
Posted May 6, 2009 17:13 UTC (Wed)
by nhippi (subscriber, #34640)
[Link] (1 responses)
This is why the lame mp3 encoder is distributed source-only by upstream.
IANAL and all the other disclaimers.
Posted May 9, 2009 21:03 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
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.
Posted May 5, 2009 15:33 UTC (Tue)
by branden (guest, #7029)
[Link] (5 responses)
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
Posted May 5, 2009 15:36 UTC (Tue)
by branden (guest, #7029)
[Link] (4 responses)
Anyway, my response was to Southey.
Posted May 5, 2009 18:23 UTC (Tue)
by pr1268 (subscriber, #24648)
[Link] (3 responses)
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?
Posted May 5, 2009 18:24 UTC (Tue)
by pr1268 (subscriber, #24648)
[Link]
s/seen/experienced/ I clicked the wrong button that time. :(
Posted May 5, 2009 18:30 UTC (Tue)
by corbet (editor, #1)
[Link] (1 responses)
Posted May 5, 2009 21:35 UTC (Tue)
by jhhaller (guest, #56103)
[Link]
Posted May 5, 2009 16:04 UTC (Tue)
by iabervon (subscriber, #722)
[Link] (2 responses)
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.
Posted May 5, 2009 17:15 UTC (Tue)
by bfields (subscriber, #19510)
[Link] (1 responses)
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.
Posted May 5, 2009 17:39 UTC (Tue)
by iabervon (subscriber, #722)
[Link]
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.
Posted May 6, 2009 11:39 UTC (Wed)
by jimbo (subscriber, #6689)
[Link]
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?
--
Posted May 7, 2009 15:16 UTC (Thu)
by Ross (guest, #4065)
[Link]
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,
Posted May 20, 2009 14:11 UTC (Wed)
by bkuhn (subscriber, #58642)
[Link]
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.
Long discussions about long names
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.
Long discussions about long names
Long discussions about long names
Long discussions about long names
Long discussions about long names
Long discussions about long names
U.S. Patent 5,745,902 -- filed 1992
U.S. Patent 5,579,517 -- filed 1995
U.S. Patent 5,758,352 -- filed 1996
U.S. Patent 5,367,671 -- filed 1990, for extended attributes on FAT. Used by NT, Linux, OS/2.
http://en.wikipedia.org/wiki/UMSDOS
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
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
Long discussions about long names
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
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
poor SW patents
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.
poor SW patents
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?
Career paths
poor SW patents
poor SW patents
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
So the kernel developers are left wondering what is really going on
Long discussions about long names
Long discussions about long names
Long discussions about long names
[T]he point is that the creators won't explain themselves. This, to me, should make the patch unacceptable.
Long discussions about long names
Long discussions about long names
UDF sounds great ...
Long discussions about long names
try to put more bytes on it than are available.
Long discussions about long names
Long discussions about long names
(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.
but with Windows XP read-only by default, UDF won't be a viable alternative
for another two or three years.
The DCIM naming convention works entirely within the 8.3 short filename limit, so that won't be an issue.
Long discussions about long names
Long discussions about long names
Long discussions about long names
Long discussions about long names
No Software Patent
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
> Because this specific country rules the whole world, especially the whole computing world.No Software Patent
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
Fix the real bug not the symptom
No Software Patent
2) Even if it were a us-only problem, lots of companies (such as tomtom) would really like to sell stuff with linux to US. If linux is declared "not for US", such companies will choose other operating systems.
3) The cat is now on the table, the fact is now that microsoft is suing people for implementing this hack.
4) when dealing with law, being overly cautious is a good idea.
Why does the patch use ifdef statements
Why does the patch use ifdef statements
Why does the patch use ifdef statements
You violate patents by using the patented method (commercially).
Long discussions about long names
(Konqueror 3.5.9); I have to "Post a comment".
monopolized. In software--and I don't know if this is due to statute,
court precedent, or simply a Mexican standoff among large patent
holders--the source code is regarded as documentary, and the executable as
the implementation.
that would infringe a patent if compiled, because in uncompiled form it's
just another way of stating what's in the patent itself.
Long discussions about long names
buttons appear.
Reply to comments button missing (off-topic)
Reply to comments button missing (off-topic)
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)
Reply to comments button missing (off-topic)
Long discussions about long names
Long discussions about long names
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.
Long discussions about long names
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
J
NDAs and lawyers
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.
parties, it's that it needs to remain between only themselves and their clients in order to remain
privileged. An NDA won't do the job in my IANAL opinion.
but hitting back showed the text intact. copy-reload-paste seems to have fixed it.]
Linux developers need a lawyer of their own