X
Business

The patent nuclear weapon

SCO's actions reveal the conflictsinherent in trying to meld a development model based on shared code with a business model based on maximizing revenue
Written by John Carroll, Contributor
COMMENTARY--IT News goes in cycles, and those cycles seem to be defined by major legal conflicts. A year ago, the big news was the Microsoft antitrust case. You couldn’t visit ZDNet without having one or more articles about the case, and hell hath no fury like Talkbackers fighting over Microsoft. Today, that case is old news, displaced by legal turbulence surrounding SCO’s attempt to lay proprietary claim to parts of Linux. Hell hath something new to talk about.

After months of activity on SCO’s part, during which time they threatened not only IBM, but customers of Linux, and even Linus Torvalds, business proponents of open source have managed a counterattack. Red Hat has filed suit against SCO, and IBM, the original target of SCO’s case, has responded with a countersuit of its own.

IBM is certainly justified in responding to SCO’s challenge, given the threat that SCO poses to IBM’s Unix business as well as the open source product upon which IBM is building its future. However, the fact that IBM is fully justified in defending itself doesn’t change the fact that software developers should feel a bit queasy about the tactics it has chosen to use.

Days before the announcement of IBM’s countersuit, Bruce Perens gave a speech at Linuxworld where he singled out IBM (among others, such as Red Hat) as the greatest threat to Linux on account of their patent activities. He’s still right, even though Mr. Perens isn’t likely to say so, as IBM’s response is revealing of the dangers of a patent regime that permits algorithms and business processes to be "owned" by someone. Current patent law unfairly tilts the marketplace towards big companies with lots of resources, even if few would miss SCO should IBM’s defensive tactics succeed.

The cost of an arms race
As noted by Brian Ferguson, an attorney with McDermott, Will & Emery, in a recent ZDNet article, "The patent claims will be expensive to handle." From a tactical standpoint, that makes a lot of sense, since IBM knows it has far more resources than SCO, and is more capable of going the financial distance.

Still, the fact that IBM can pull out the patent nuclear weapon against SCO means they can use it against anyone, and that should be a frightening notion. I noted in a past article that most big companies build patent libraries as a form of defensive armor against external IP claims, and that certainly appears the case with IBM’s use of these patents against SCO. What can be used defensively, however, can also be used offensively. Faith is your only guarantor that a company won’t ever use those patents in an offensive capacity.

Building a defensive library, however, costs money. First, filing a patent application can take anywhere between $15,000 and $25,000, which isn’t within reach of many small businesses. Second, costs associated with defending against patent assaults dwarf the aforementioned application fees, making patents an expensive prospect.

Those most able to afford these costs are big companies, and those least capable are smaller companies with fewer resources. This skews the market in favor of large companies, leading to an environment where smaller companies have a harder time growing into bigger companies.

Anatomy of a nuclear weapon
I haven’t found any articles that cite the actual numbers for the patents used in IBM’s countersuit. This article provided the names, however, and using the US Patent Office’s online search tool, I narrowed them down to the following patents.

The first one, "Data Compression Method", refers either to patent number 5,010,345, granted in April, 1991, or patent number 4,814,746, granted in March, 1989. In both cases, they detail fairly specific tweaks to data compression.

The second patent, "Method of navigating among program menus using a graphical menu tree" refers to patent number 4,821,211, which was granted in April of 1989. This patent appears to be a patent on a particular twist on menu layout.

The third patent, "Self-verifying receipt and acceptance system for electronically delivered data objects," refers to patent number 4,953,209 and was granted in August of 1990. This patent appears to be patent on the standard process of downloading executable code through a user interface, which is baffling, to say the least.

The fourth patent, "Method for monitoring and recovery of subsystems in a distributed/clustered system," refers to patent number 5,805,785 and was granted in September of 1998. This patent appears to cover a fairly standard procedure involved in computer clusters.

What bothers me about these patents is that I could see myself easily stumbling into "infringement" in the course of normal software development (and I probably don’t need to mention this, but what company that offers software for download is NOT infringing on the third patent?). I come up with lots of constructs for data presentation and/or ways to tailor encryption of data. It would never occur to me, though, to claim that I am the ONLY one allowed to write software that uses the same techniques. That would be like saying I have exclusive rights to build a LEGO house with a sloped roof and a window in each wall.

If we’re lucky, IBM will only use these patents to squash the SCO threat. If we’re not lucky, the IT world could end up with another Unisys. Unisys probably didn’t originally intend to charge a licensing fee for the compression algorithm used in GIF images (a patent that has now expired). In Unisys’ case, though, GIFs became extraordinarily popular through the growth of the internet, and some executive at Unisys probably decided that the revenue potential was too big to pass up.

Conclusion
Markets tend to work around boulders in the economic stream, because modern markets are dynamic entities that respond to hindrances like cars moving around a stalled truck on the freeway. That doesn’t mean that the market wouldn’t work more efficiently if the hindrance weren’t there.

Governments play a very important role in a market economy. They define the stage upon which economic actors play. They supply laws governing property and business contracts, laws to enforce transparent accounting standards, and laws governing capital flows. Governments provide the structure within which economic activity takes place, and certain structures lead to more profitable and efficient economies than others.

Algorithm and business process patents are instances of a less efficient economic structure. Markets have managed to respond, but the resulting balance isn’t more efficient than a market that didn’t allow such legal stakes to be placed on abstract ideas in the first place.

As a final point of note, keep in mind that the only reason IBM is defending Linux is because it suits their business interests. As Mr. Perens pointed out at Linuxworld, however, many of IBM's business interests, specifically, the one's bound up in IBM's ever growing pile of software patents, run COUNTER to the interests of open source. IBM might be fighting on open source's behalf today, but what's to ensure that will remain true in the future?

I suggested in the past that SCO's actions reveal the conflicts inherent in trying to meld a development model based on shared code with a business model based on maximizing revenue. That will remain the case after armies of lawyers have picked over SCO's sun-bleached bones, so long as companies are entities created for the express purpose of making a profit.

SCO's case centered around copyright, because that's the only thing they could reasonably base a claim on. In contrast, I bet IBM could make a similar claim to Linux IP, and base it entirely on patents. The only thing stopping them is that they make plenty of money without resorting to such extremes.

Let's hope that IBM is always so profitable.

biography John Carroll is a software engineer now living in Geneva, Switzerland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.

Editorial standards