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."

Comments

Re:Hidden costs

[radtea]

How do you work around the Apple multi-touch patents?

Start by being specific about which patents you mean. "The Apple multi-touch patents" means nothing. Apple has a great many patents, 28 of which contain the words "multi-touch" in the text. Here's a likely candidate, #7656394, "User interface gestures".

All five independent claims refer to "proximity images", so the obvious work-around for this patent would be to begin with a system that does not use an image (a regular, contiguous array of pixels in two or more dimensions) as the primary data structure.

There's more to it than that, but the basic process is the same: be specific as to what patent(s) you are concerned with; read the CLAIMS (not the abstract) carefully and then the supporting material to ensure you understand the terms of art being used.

This patent doesn't actually define "image", but it is clear from context, and equally clear from common usage that a data structure that contains only a list of (mostly non-contiguous) points of contact is not an "image".