Slashdot Mirror
Tridgell Recommends Reading Software Patents
H4x0r Jim Duggan writes "Andrew Tridgell rejected the common fears about triple damages: 'If you've got one lot of damages for patent infringement, what would happen to the project? It's dead. If it gets three lots of damages for patent infringement, what happens to the project? It's still dead.' Tridge then explains the right way to read a patent and build a legal defense: 'That first type of defence is really the one you want, it's called: non-infringement. And that is: "we don't do that. The patent says X, we don't do X, therefore go away, sue someone else, it's not relevant for us." That's the defence you want. [...] Next one, prior art: [...] Basically the argument is: somebody else did that before. It's a very, very tricky argument to get right. Extremely tricky, and it is the most common argument bandied about in the free software community. And if you see it in the primary defence against a patent, you should cringe because it is an extremely unsafe way of doing things.' There are even some tips in the talk specifically for Slashdotters."
In the same way that there is always a bigger fish.
And what you have to fear are overly broad patents and patent trolls.
Many patents are there not for suing the ass off the competition but to protect yourself from getting attacked.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
When I'm writing code, I don't have to worry about patent infringement, because the stuff isn't patentable. That way I can write code just like you write anything else; without looking over your shoulder.
Why is the legal system so fucked up that it's easier to win with "We don't do X" instead of "X has been done before" when it's extremely obvious that X has been done before?
The cost of searching for patents whenever you're doing something, anything, really, is a huge burden on any R&D department. By forbidding employees to look at patents, companies make then focus on the important stuff: making things.
To do list for Windows
Trademarks are very different from Patents.
What you describe is a Trademark infringement.
I think that the best overall defense is if someone can take a case all the way to the supreme court, and argue that the threshold for obviousness
is way out of whack in the granting of software and business process patents.
The goal should be to get a test mandated by the supreme court along the lines of: If three out of four average 3rd year comp sci students
could design and code it up in a month, having heard only the requirements and not the design, then it's f***ing obvious to a competent practitioner
in the field, and should be dismissed.
Who knows. There may actually be algorithms clever enough to deserve patent protection for 5 years or so. But right now those would probably be
1 out of 100 of the patents granted, so the whole system is in total disrepute and it is the duty of a responsible practitioner in the field, as a protest,
to ignore and not view and thus not heed any USPTO software or business process patents, until they entirely revamp the standards and
throw out all patents granted under the existing broken standards.
Where are we going and why are we in a handbasket?
Reading patents with an eye to identifying "Technologies" to use is an exercise in futility:
Most are stupidly obvious. The others written in leagalease.
Reading patents with an eye to identifying "technologies" to avoid is also an excercise in futility. Again, you need the mind of a lawyer, combined with the approach of a security researcher, to "see" the ways a patent could be exploited to somehow map to your own problem domain. That you were happily solving without resorting to the giant database of solutions to micro problems no one is interested in.
Next, theres just too damned many of them. If anyone took the time out to exhaustively read and analyse each patent enough to determine if the possibility for collision existed, well they wouldn't have a problem with patents as they'd never write any code.
Lastly, it takes courts a long time to determine if a particular product does conflict with a patent. This means theres a lot of grey area around the edges of a patent to determine if a particular approach is covered or not. Which means, of necessity, that, like Chinese ISPs, developers who read a patent would have to defensively eliminate huge swathes of potential solution space from their investigations, to avoid getting "too damned close".
'If you've got one lot of damages for patent infringement, what would happen to the project? It's dead.
Not necessarily, since the product may already be released, and the project to create it may be already completed. The damages award is typically made after lengthy legal proceedings, and it's not likely that the development project is still active. Those involved have probably moved on to other projects, been promoted, or changed employer. Paying tens or hundreds of millions in damages is not fatal to large companies, but the risk of such a cost is definitely a risk to be minimized.
If it gets three lots of damages for patent infringement, what happens to the project? It's still dead.
Not necessarily, if the product has already been released, and the project to create it has already been completed. But the court's interpretation of a patent is often baffling to an engineer, who cannot therefore assess whether a risk of infringement really exists. However, by being aware of the patent, the potential cost of an infringement is tripled. This is why large corporations do not encourage their developers to do exhaustive patent searches.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
You could have at least read the summary:
Next one, prior art: [...] Basically the argument is: somebody else did that before. It's a very, very tricky argument to get right. Extremely tricky, and it is the most common argument bandied about in the free software community. And if you see it in the primary defence against a patent, you should cringe because it is an extremely unsafe way of doing things.'
The reason why prior art is difficult to get right is explained in TFA: a patent consists of a number of (likely very long and complicated) interdependent claims which are likely to be interpreted quite narrowly. In order to work, a prior art defence has to exist for each and every one of those claims in the same interpretation as that intended when the patent was granted. So you have to go through the entire patent from beginning to end, look at each claim and think "Is there prior art for this? Is the prior art exactly the same idea or is it just roughly the same sort of thing? If the latter, that's a Very Bad Thing for the defence".
However, it's quite common for the patent to hinge on a handful of claims and if you can prove that you don't do just one of the independent claims, you're free.
I see several problems with Tridgell's approach.
1st, his talk assumes patents cover only a specific, narrow implementations of ideas. And if some patent troll challenges you, all you have to do is show your idea is slightly different. He says we've gotten it all wrong, because there isn't any such thing as an overly broad patent. I don't know. Isn't the point of a patent to cover an idea, no matter how it is implemented? What is a business method patent, if not that? But if he's right, then RIM really blew it. All they had to do was show that NTP's patents don't cover exactly, precisely what they did and the way they did it. That should have been easy, because they came up with their own system. Somehow, I think that if it had been that easy, RIM would have found the way. Instead RIM tried what he strongly recommends against, that is, they tried to show prior art. There was just this minor problem that their legal team foolishly hoked up some fakery on that point.
2nd, he assumes too much about the methods of the patent trolls. Sure, it all comes down to making money, but the straightforward approach of attempting to collect license fees isn't the only way to use a patent to that end. There's the use of patents to stifle competition. That's why MS supported SCO, not to profit off of licensing fees for Linux, but to hurt Window's biggest competitor. Then there's the shakedown, as IBM once did to Sun over 7 patents, including the infamous "fat lines" one. Sun did exactly what Tridgell says to do. They demolished IBM's claims of infringement. And it didn't work because IBM pointed out that they have over 10000 other patents. "Do you really want us to go back to Armonk and find 7 patents you do infringe?" Well, maybe Sun shouldn't have caved. And, there's harassment of the sort SCO did. They knew they didn't have a case-- they were just making a big legal stink in hopes their victims would decide it's cheaper to buy them off than fight them in court. How did PJ tear SCO's case apart? The way Tridgell recommends? Yes, but that was only a part of it. There was also effort to throw the validity of SCO's patents into question by showing prior art.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I think he's wrong equivocating the invalidity defense with the prior art defense. My understanding is a patent can be invalidated - and rendered completely ineffective - if you can show that it doesn't actually teach a practicable implementation of a way to achieve the claims.
I had experience with this. We received a cease and desist letter from a (large) company saying we were infringing a patent they had claiming synchronizing audio playback with the movement of a cursor. After carefully reading the description, we realized that they were actually describing doing this synchronization by assuming that the real-time clock signal was all that you needed to know how much of the wave file had been sent to the audio output ... and we knew that this could not actually work. It didn't account for processing delays owing to CPU/memory/bandwidth limitations. Our lawyer wrote a letter back to them saying this and we never heard from them again.
Note that the _claims_ themselves did not describe the synchronization method - they were claiming the generality of doing the synchronization. It was in the _description_ that they explained _how_ to do the synchronization and this is where we found the flaw which invalidated the entire patent. I should note also that the description included words indicating that the method they were describing was "essential" to the invention - so it was actually a badly written patent. If they had carefully qualified the description with words like "this is one possible method ... there are others known to those skilled in the arts", we might not have been able to make this defense. And, of course, this never went to court (probably because they realized how badly the description had been written). But, I've seen other such flaws in patent descriptions - you'd be surprised how often lawyers make stupid mistakes like this.
And, if you do find such a mistake, you will have helped to move toward invalidating the entire patent, as opposed to just avoiding the particular infringement suit. It is lots more work to wade through entire descriptions, and I wouldn't recommend doing it unless, as the speaker indicates, you are in the cross-hairs of an infringement suit. But, it can be a very good feeling if you succeed!
If humans are mostly water, and beer is mostly water, then humans must be mostly beer.
It is an example of a patent that is nothing more than pretty words that was not rejected in accordance with the patent code.
There is no proof, not even any viable evidence, that the described "invention" would function in any way at all, let alone that it would satisfy the claims made in the patent. We aren't even talking Marketability, we are talking "It just can't work".
If this sort of patent is being issued regularly by the patent office for the sake of collecting issuance fees, that would seem to indicate that the patent office itself is in habitual violation of the patent code for economic benefit.
In simpler days we would call such actions "corrupt".
Forget diamonds, copyright is forever.