ZDNet UK News
Stallman: Three ways to deal with software patent threats
Thursday 28th March 2002
Matt Loney

Part II: There are three ways to get around the problems of software patents, says Richard Stallman. But it's a minefield, and the chances of making a wrong step are high

In the second part of Richard Stallman's speech at the Cambridge Computer Lab, the free software guru explains how software developers can avoid software patents.

Tackling software patents I: Avoidance
Stallman: The best way to avoid a software patent is to not use the idea that is covered by the patent. In some cases a feature is patented, so you avoid it by not implementing the feature.

But of course you then have to ask yourself how important is that feature? In some cases you can live without it. For instance, users of the xyWrite word processor once got a downgrade through the mail, removing a feature that let you define abbreviations for long words and phrases. The developers of xyWrite had tried negotiating with the patent holder, but finally decided to remove the feature. For a single feature this might be acceptable, but as various features start getting hit (by patent claims) you end up with a program that is no good.

For instance, what do you do with the BT patent on traversing hyperlinks together with dial-up access? Traversing hyperlinks is essential. How do you do without this feature? Then there is the public key encryption patent. In the US, this largely blocked public key encryption for ten years because the patent holders imposed restrictions. There was no way around that patent, and there was nothing else you could do if you wanted to use public key encryption in your products.

In some cases of course you might be able to find a better algorithm. Because we could not use the compress algorithm in the GNU project, we started looking for a better data compression algorithm. We ended up with GZIP. As an algorithm to use in a program for data compression GZIP worked fine, but when we started saying to tell people to stop using gif files (which used the patented LZW compression), people said we can't switch, the browsers don't support it yet, and browser companies said nobody's using it yet. There was so much inertia that we have not been able to switch people in ten years.

So avoiding software patents may be easy, but it may also be impossible. And where it is easy, it may make a program useless; it varies depending on the situation.

And sometimes a company can take a format and make it a de facto standard, and then if that is patented it is a real disaster. There was uproar recently when the W3C proposed to start adopting standards that were covered by patent. The community objected and the W3C reversed its decision.

Tackling software patents II: Licensing
Licensing a patent is not necessarily an option, because the patent holder does not have to offer you a licence. A lot of patent holders do offer licences, but sometimes they demand a lot of money. Some demand 5 percent -- you might be able to afford this, but what if you have licence 20 patents to make a program? Practically speaking two or three licences will make any business plan unfeasible.

However, there is a situation where licensing patents is a good idea: if you are a multinational mega corporation that owns lots of patents and cross-licenses them.

An IBM employee published an article in Think magazine in 1990, saying it got two kinds of benefits from patents: the first benefit was from collecting royalties, and the second benefit was in getting access to the patents of other companies. He also said that this second benefit was an order of magnitude greater then the first.

So the benefit of being able to license patents from others was ten times the benefit of licensing its own patents. Being able to do this meant IBM was excused from the trouble the patent system can cause you.

This phenomenon of cross-licensing refutes a common myth: the myth of a starving genius; the myth that patents protect small inventors (and protect is a propaganda term).

Suppose there is a brilliant inventor who spent years starving and designing a new whatever, and he now wants to manufacture it. For a start, people in high-tech fields do not generally work on their own, and these people have pretty good chances of getting a job anyway, so the scenario of one starving person working alone is unrealistic. But it is conceivable; they could have a good idea. So what happens if the inventor tries to use a patent to stop a big company? IBM simply says: "Let's look at your product; we have these patents that parts of your patent infringe -- can you fight these in court? Why don't you cross-licence with us?" The small guy says OK, and he goes away and makes this stuff, and IBM goes away and gets access to his patent, and competes, so patent did not ever really "protect" him.

Big corporations mainly see the good side of patents; that is why they want patents. IBM can almost always make you cross-licence, but the small companies can only occasionally do this.

Tackling software patents III: Litigation
Supposedly for a patent to be granted, something has to be new, useable and non-obvious. But when the patent office gets into the game, "new" means "we don't have it in our files", and "unobvious" means unobvious to someone with an IQ of 50.

The US Patent Office does things that are so obviously foolish: for instance, the famous Harvard mouse patent, dealing with a strain of mouse that had a cancer-causing gene. The gene was already known, the insertion technique was already known, and the strain of mouse was already known. The patent essentially covered inserting any gene into any creature. Such over-broadening is common.

When programmers look at a lot of software patents they may say they are obvious, but the patent officers say you have to consider it in the context of 10 years ago. What happens is that if they talk enough you lose your bearings. Then they describe the patent holders as brilliant inventors, so we cannot question their entitlement to power over what we already do. In a court a judge may be a little more stringent, but it costs millions of dollars to do that.

The courts are an option, but because of the expense they incur they are often out of the question, even if you can find prior art. As a result, an invalid patent is a dangerous tool.

So all three of these possibilities are things that you might sometimes be able to use, but if you face patent after patent after patent, it gets like crossing a minefield. With each design decision you might not have a problem, but as you take each step your chances of getting all the way through the minefield get less and less.

Next page: Solutions for software patents

Previous page: Why software patents are a bad idea

ZDNet UK's Developer News Section delivers the latest headlines together with the best UK jobs, right to your browser.

Have your say on all developer topics. From j2ee, to C++, from Visual Basic to Javascript plus much more. Share your experience with others on the Developers Forum.

Let the editors know what you think in the Mailroom.