Delivering a talk titled "Patent defense for FOSS developers" at the 11th Australian national Linux conference in Wellington, Tridgell, who is best known for creating Samba and rsync, provided a walkthrough of some basics which needed to be learnt by all developers.
Before he got going, he cautioned those assembled that he was not a lawyer.
Buying time with patent lawyers was difficult and expensive and hence, "patent defence starts with developers, and a patent attorney is there to validate and guide software engineers," he said.
Additionally, one could not expect a patent attorney to look at a mass of code and understand it quickly. "You are the coder, you know all about the spaghetti you create," Tridgell (below, left) said.
He agreed that it was tough to get started as one had to learn to read patents, "and not merely the abstract".
Wasn't it dangerous for coders to read patents? "Some companies discourage employees from reading patents but most of the arguments for this attitude do not apply to FOSS," Tridgell said, answering his own question.
Elaborating, he explained that the majority of FOSS projects would die if they were hit with just one patent claim; they did not need to die more than once to disappear off the face of the earth.
Hence, he said, one would be better off stepping through the minefield and avoiding the mines, rather than putting on a blindfold before stepping into the minefield.
As to the type of defence, Tridgell said non-infringement ("we don't do that") was the best. Prior art ("done before") was tricky while invalidity ("you can't claim that") was almost impossible.
Any patent contained both independent and dependent claims, with the dependent claims referencing an earlier one(s). "For non-infringement, one has to deal only with independent claims while for prior art or invalidity one has to deal with all claims," Tridgell pointed out.
He provided examples of a fictitious patent and a real one and explained how a developer should approach the task of finding out what the patent was trying to claim as an invention.
And he warned against following the masses on sites like Slashdot where "they read the abstract and tend to get stuck there".
Tridgell's advice was that it was better to read the claims and then come back to the descriptive part of the patent. Each claim would have a preamble and elements. The first claim would be independent and subsequent claims would be dependent ones, he pointed out.
For example, in his fictitious patent, the preamble was "a transport system consisting of..." and the elements were "a red car" and "with shiny plastic panels." The dependent claims followed: "system of claim 1 with multicoloured wheels" and "system of claim 2 driven by a green dinosaur".
"Try to knock off the claim elements and the dependent claims will disappear," he advised.
After a suitable warning, he then used a real patent to offer more advice: "Do not stop with the abstract, don't depend on the scanned version as OCR software can often play up, read the PDF, and look at earlier patents which are cited in the patent under examination."
After finding out what the claim was (which, he added, wouldn't be in big type as expected), he said one should start defining terms and highlighting sequences of words which could be used in a non-infringement claim.
"And use terms that a patent attorney, who is most likely to be an engineer, can understand," Tridgell advised.
He pointed out that prior art was not a panacea as it was very hard to kill all claims; these were often interpreted much more specifically than engineers expected.
But if one was using this defence, then the homegrown version was the best: "The best prior art is your own code. Dates matter so keep good source code repositories. The precise day of a commit matters surprisingly often."
Tridgell said invalidating patents was hard. "They can come back from the dead as happened with the VFAT patents," he said. "And when resurrected, they can be even harder to kill."
He advised developers to read the file wrapper of a patent as it contained all the records of discussions between the patent office and applicants. "The wrapper serves to narrow the meaning of words."
Tridgell touched on what claims meant and said one should create a claim chart and send it to the patent attorney.
He then turned to what FOSS developers could do to avoid patent traps. "We need to be tough targets and hit aggressors where it hurts most - licensing revenue."
Building workarounds and publicising them was a good idea because a patent holder would then realise that making claims on a proprietary vendor stood a better chance of yielding revenue.
"They will realise that if they come after a FOSS project, we will try to build workarounds and make them publicly available for use by everyone; if proprietary companies build workarounds, they will not share it," he explained.
"Encourage others to adopt the workarounds," was his advice.
Tridgell finished by dealing with possible problems ("technical expertise is our best weapon but how do we coordinate?") and pointing to possible solutions (an online course on patent analysis, coordination between companies, etc). But independent developers were still exposed, he added.