PUBLISHED: Ritter, T. 1991. The Politics of "Software Patents." Midnight Engineering. May-June: 29-35.
What happens when patents apply to software? The somewhat hysterical article "Software Patents" by "The League for Programming Freedom" (in the Nov. 1990 issue of Dr. Dobb's Journal) might lead one to believe that we have found the end of software development as we know it. Yet other people, given mostly the same information, see the application of patents to software as a natural and welcome improvement to the current state of software secrecy.
"The League for Programming Freedom" has drawn the "software patents" argument as the freedom of programmers versus oppression by large software corporations. This argument is flawed in many ways, but perhaps the worst part is to assume that, if not for patents, most important software concepts would be free for use. We already know this is false: Important software ideas are now kept hidden in trade secret source code. Large software companies do have access to trade secret information because they have the resources necessary to disassemble all important systems, but individuals do not have similar resources. Thus, trade secret source code is a way for large software companies to share important techniques among themselves, to the exclusion of individuals and small companies. (For example, consider the early years of DOS.) In contrast, a patent is an economic tool which encourages the disclosure of new ideas.
I intend to show that "The League for Programming Freedom" has presented a biased argument which supports a particular point of view with selected facts. Observations they did not make include:
For the past couple of years I have supported, at my own expense, my own research and experimentation in the field of cryptography; I have published several papers and applied for patents on the results. On December 25, 1990, U.S. Patent 4,979,832 titled "Dynamic Substitution Combiner and Extractor" issued to me. This invention is a logic mechanism which may be realized in hardware or software, so I made it clear in the specification and claims that the patent does apply to a software implementation. If the patent would not protect against software infringement, few implementors would hesitate to realize the mechanism in software. Without software protection, I have no protection at all.
Of course, my patent may not really be the sort of "software patent" that "The League for Programming Freedom" is protesting. My invention is not confined to software, since it would make a fine integrated circuit. My invention is not just an improvement in detail, but instead is fundamentally new technology. And a general lack of "prior art" solutions for a well-known problem clearly indicates "unobviousness" in this case. But if "The League for Programming Freedom" is protesting some other type of patent, perhaps they will agree that patents like mine, which must apply both to hardware and software to obtain meaningful protection, are necessary and perhaps even desirable. This would mean that someone would have to draw a distinction between one sort of "software patent" and another.
Much confusion seems related to misunderstanding exactly what a patent is. In particular, "The League for Programming Freedom" gives us a number of instances in which "commonly used software techniques" were patented. They say that these patents were upheld despite testimony that the techniques had been developed years before. These events are not contradictory.
Most of us probably think that a patent is given to the first person to invent something, but this is not quite correct. A patent may be seen as a reward for the first public disclosure of an invention. Certainly, any inventor has the right to keep an invention secret, but those who do this also give up even future rights to the patent. By keeping the invention secret, they also risk the possibility that some other inventor may come up with the same invention, patent it, and apply the patent to the original inventor.
The problem with "commonly used software techniques" is that we may see their presence on a display screen, and yet still not know how the trick is done. The true description of an invention is not what it does, but how it does it, and in software systems, most such descriptions are kept hidden in secret source code. But an invention which is kept secret not only does not qualify for a patent, it also does not constitute a full public disclosure, or "prior art," which would inform the public, and also prevent someone else from getting such a patent. The problem is that many software inventions have been deliberately hidden in tightly-held source code instead of being patented or publicly disclosed.
By keeping our source code secret, we distribute the results of our work, but we fail to share the work itself, our actual insights into programming. Eventually, every product gets old and is retired, but the source code is still not revealed; the programming insights in it are thus lost forever. It is no wonder that programmers continually "re-invent the wheel," we have no choice! Certainly, a lot of software is distributed in source code form. But, just as certainly, very few economically important systems are distributed in source code, unless written trade secret covenants have been concluded. Obviously these people believe that they have something important to hide. Maybe they are right.
Hidden innovation which is eventually lost to society is exactly the situation which patents were intended to correct. In a sense, patents are an indication that society expects us not only to contribute products, but also to disclose our technology, and not just keep it hidden. Certainly, if a business folds completely, we do not want its accumulated expertise to be lost as well. The application of patents to software may eventually provide enough protection so that we can display source code, even for economically important systems. For the present, the problem is not that patents are too effective; the problem is that patents do not provide enough protection to encourage the public display of source code.
"The League for Programming Freedom" would have us believe that software invention is common; certainly, mediocre software is all too common. However, it seems obvious that an experienced, talented programmer generally produces superior programs. Why should the better individual not be able to claim that his or her work is "exceptional" and "superior"? And if we support this, how can we say that such work is not "rare and precious"?
A patent is a non-renewable 17-year legal monopoly on the manufacture, sale or use of an invention. Some think that a patent can be obtained on any solution to any problem. Such a solution could be called an "innovation" or "invention," but few of these would qualify for patent protection. To qualify for patent, an invention must be:
To some extent each requirement is subject to human legal judgement. But these judgements are not arbitrary; for example, there a number of factors which may indicate unobviousness, and these can be formally examined. Such factors include "unexpected results," "previously assumed insolubility," "long-felt and unsolved need," "new principle of operation," and so on. By examining the evidence of the "prior art" (previous patents and publications) with respect to the various factors of unobviousness, a reasonable and defendable legal opinion can be developed.
When we look at the requirements for obtaining a patent, we see that unobviousness and novelty are unlikely to be satisfied for most software innovations. This, of course, makes patentable software inventions all the more precious.
Yet another source of confusion is "the clarity of hindsight." After a problem has been solved, the solution is -- surprise! -- obvious. Using exclusive-OR to display a cursor on a computer screen may be obvious now; it may not have been nearly so obvious when such screens were rare and new. But the worry over this patent is just one more indication that true innovation is rare and precious: Apparently, "obvious" alternatives to the exclusive-OR cursor are not all that "obvious."
The idea that software is "fundamentally different" from hardware is normally a harmless conceit. But when this idea is proposed as a basis for public policy, it deserves considerably more attention.
Software is basically a convenient way to customize a generalized logic machine which was deliberately designed to be so customized. Software is not magic; it can only select among the hardware functions which were originally designed into the physical machine. A strictly hardware machine could be built -- without software -- to produce the same effects as any particular program; but without hardware, software can produce no effect at all. When it comes to results, software is not equal to hardware, but is instead strictly dependent on hardware.
So called "low level language" or assembly-language software consists mainly of symbols or specific words, each of which directly selects a particular operation for the physical machine to perform. Such software can scarcely differ in intent from the sequencing performed by a piano roll, a music box cylinder, a clothes washer selector or dishwasher selector, or any other machine sequencing device which is normally considered a part of the machine.
So called "high level language" software consists mainly of names for sequences of machine operations; controlling such a sequence is normally the task of a sequencer, which is clearly part of a machine. It does seem clearly unreasonable that simply naming a sequence of operations, and then using that name in a lexical work somehow makes the sequencing operation not a part of the machine.
Virtually every criterion which has been advanced to establish differences between hardware and software simply establishes a similarity: Software development is not cheap (good software is almost unbelievably expensive to develop); software performance is not and (in general) cannot be mathematically guaranteed (it is too complex); software does fail (disturbingly often); software does interfere with other software (e.g., MSDOS TSR programs). It is obviously much easier to reproduce software than integrated circuits, but this means that software needs more legal protection, not less. Software can seem more ideal than hardware because, by itself, software does not -- and can not! -- do anything; it is the controlled machine which must deal with reality. And real machines are often designed by assuming mathematically ideal mechanical or electrical components.
Software is a useful fiction to describe an area of human endeavor and the business of the customization of the generalized logic machines which we call computers. Certainly, written software is a form of human expression like literature, art, or poetry, and should be protected by copyright. But if software has productive worth, this occurs only by and in a physical machine, and that software must be present in some machine-readable physical storage. The resulting changes in machine state are the "transformation of matter from one physical state to another" as expected under patent law. Since software must be present in a physical form (generally not as text printed on paper), and produces an effect which is only the equivalent of a machine constructed solely of hardware, software deserves patent protection as an expected part of a logic machine.
It is easy to understand how software can be used to "replace" hardware: Software customizes a logic machine which was designed to be customized; the customized machine can produce different effects at different times; producing those various effects would otherwise require separate hardware.
But if software cannot infringe patents, then there is substantial motive for manufacturers to move infringing hardware logic designs into software. Given the availability of fast microprocessors, much previously protected hardware might be implemented as software (perhaps even as microcode). This would obviously weaken, and perhaps even destroy, the currently existing protection for some types of hardware. Thus, the simple proposal that software not be considered infringing may, in practice, imply a radical reform of the entire structure of patent protection.
Moreover, when software replaces hardware, the entire reason for the existence of the software is to produce the same effect as the replaced hardware. In order to perform its intended function, software must be executed, and when it is, it functions as a sequencer, which would otherwise be considered just a part of the larger machine. If software is just a part of the machine, why should it not be protected by patent?
. . . is there a way to prevent someone else from getting it? Sure. All you have to do is to make the invention public. A year after you publish a complete description of an invention, it should be firmly in the public domain. (Of course, if someone applied before a year after your publication, and could document that they had made the same invention before your publication, they might still obtain the patent.) Remember that you must disclose how the thing is done: In software, this generally means actual working source code. But even source code, by itself, may not be sufficient for disclosure; documentation and a discussion of the particular techniques probably will be required as well.
Publication does not necessarily mean that you need to write an article or paper and get it printed in a periodical. Generally speaking, "publication" means an open and widely available public disclosure of the way the invention works. In the present day and age, disclosure on a computer network or even a bulletin board system may qualify, although this would be a topic for legal council. You should arrange for witnesses who could testify as to the date of public disclosure.
No. Most conventional software techniques were publicly disclosed many years ago, and are in the public domain. For example, one should expect that most of the procedures in Knuth's The Art of Computer Programming series are freely available for use (with RSA public-key encryption being a notable exception). Various other books and journals disclosed most of the general techniques long ago. Any new patents which would affect software would have to be something rather unusual.
And a patent is an economic tool. Although it could be applied to individuals, the whole point of a patent is to control economically significant infringements. Individuals generally do not make worthwhile economic targets.
Of course, when you manufacture and sell software, you do run some risk of lawsuit. But in the day-to-day operation of business, lawsuits are not uncommon; a patent lawsuit is just one risk among many. If you are unwilling to accept the possibility of lawsuit, you probably should not be in business at all. If a patentee believes that you are infringing a patent, you will be informed; in many cases it will be more profitable (for both sides) to negotiate some sort of license agreement than to proceed to court. In other cases, you may have to re-design your product. Very, very few patents are so powerful as to prohibit any other way of producing the same result.
But if you basically have the idea that you can do anything you want, that nobody can tell you what to do, and that you will not pay anybody anything, a patent lawsuit may be the least of your problems.
Alas, no. Patent searches are both difficult and unreliable, although this situation is hardly unique. Real estate, for example, is often encumbered with various sales of rights and liens. Real estate title searches are complex and unreliable, making title insurance necessary.
Most of us are located within a reasonable distance of a patent deposit library. It is certainly possible for an individual to perform an in-depth patent search in such a library, although this is an arduous task. The first time you search a particular topic, expect to spend at least several full weeks at it. The main difficulty is the process of physically finding and retrieving the patent abstract (among huge shelves of such abstracts), or the patent itself (one among hundreds in a film taken from a wall of microfilms), along with the large number of patents which generally must be inspected. Because actual paper patents are physically collected by class at the Patent and Trademark Office in Washington, D.C., an equally effective search might be made there in only a day or two.
Although technology may eventually reduce the difficulty of a patent search, such a search is always going to be imperfect. A searcher must judge essential similarity based on only few minutes of reading a complex patent; some of those judgments will be wrong. And, in any case, one can only research granted patents; pending applications are secret until they issue.
When we are young and in school, information is provided for us, and the vehicles of such information are freely available. But as mature individuals we must understand that we are part of a capitalist society, and all of the information we have was found, accumulated, and paid for, through the direct effort and expense of previous generations. It seems a bit too clever to assert that "information is free" when it was paid for by someone else. Even libraries must purchase books (which were published to make a profit), then store them at huge expense; the fact that such expenses are hidden from individual library users does not mean that the expenses do not exist. Libraries are not free.
Whenever information is free for use, it is because someone who found or created it (and who thus "owned" it) decided to make it available to society at large. Probably the owner released the information to in some way make a profit (perhaps to publish a book or enhance a reputation), or perhaps this was just the expected return for an academic salary (which is certainly an individual profit). Encouraging inventors to reveal their work (in return for a limited term monopoly) is the whole point of the patent system.
Many software ideas are available in texts. But other software ideas have not been made public, and are instead kept secret. By applying the patent system directly to software, we may be able to make some of these ideas available for a negotiated fee in the near term, and for free use by the next generation. Maybe that generation will not have to continually "re- invent the wheel," but can instead get on with extending the limits of software design.
One aspect of patents is that they can provide an economic basis to support research and development. Patents generally provide rewards only when they are actually applied in a product, when that product is actually produced, and when it competes successfully in the marketplace. Patents return royalties only when research is actually translated into results; patents thus cost society virtually nothing, unless and until buyers freely pay for an improved product. Compare this with the usual bureaucratic approach of government sponsored research.
Another important aspect of patents is that they provide a way to capitalize the invention. New businesses are extremely risky. A new business with a strong patent position is in a better position to acquire capital and build itself to the size necessary to become an effective competitor. The results are that the consumer gets innovative products, from a stronger company, which may provide more competition in the marketplace. This is what we want.
In some sense, ideas are free. But the time and effort involved in verifying and improving the idea into an invention, reducing it to practice and testing it, then formally reporting on it; these things are certainly not free. Recognition of the importance of a new invention, comparing it to previous inventions, and extending old theories to fit the new situation are also not free. Designing a product using a new invention, building the product, finding and informing buyers, and selling the product -- all this is not free! And a successful product may have to fund many other less-than-successful developments. If some other company can simply copy your original "free" idea after you have invested in bringing it to the market, you are not going to do this very often. Such a situation is not what we want.
Patents are a limited-term monopoly, and they can be used to prevent any size of business from producing a competing product. But there is not much point in applying a patent against a tiny business which is neither an economic threat nor a significant source of royalties. Thus, patents are most effective against large businesses.
In the present software business environment, small companies already cannot compete directly against a large company. The advertising, production and marketing resources of a large software firm can make even dull products dominant in the marketplace. And because a large software company generally has more programming resources, their product may even be better designed, with more features than one produced by a small company. One of the few things which might allow a small firm to compete directly against a large one is a strong patent position.
"The League for Programming Freedom" cites the "X Window" project as an example of "public service" software which may infringe several patents. They say "dozens of companies and hundreds of thousands of users who accepted software from MIT with the understanding that it was free are now faced with possible lawsuit."
Note that this is the very same MIT which in 1983 received U.S. Patent 4,405,829 for the RSA Public Key Cryptosystem, a patent which is generally considered to cover software implementations. That a software project connected with MIT is itself inconvenienced by patent protection would seem to be simply a matter of everyone having to play by the same rules. Should we now be able to freely distribute RSA programs, as long as they may be a "public service"?
The real question here is why the X Window software was not quickly modified so that it did not infringe. If "public service" software projects do not have sufficient resources to work around issued patents, perhaps they are not as much of a public service as they claim to be. The horrible truth about "free" software is that, without continuing support, the software is often more trouble than it is worth. But only the continuing business of software is financially able to provide such support.
Although patents may be new to the software industry, the need to respect intellectual property is old indeed in most forms of manufacturing. Modern computer manufacturers must contend with patents as a matter of course, yet they still manage to produce many new designs. In most cases, competition and general economic conditions are far more of a threat to the survival of a manufacturing business than petty patent disputes. Now software patents make a few waves, and the call goes out to exempt the software business entirely. It does not make sense.
First, the main reason that "commonly used software techniques" can be patented is that these techniques have been selfishly retained by their inventors as trade secrets. Not only were the techniques not patented, they also were not made available for public inspection and use. It does seem a bit hypocritical to argue that society should not enforce patent protection for those who would reveal their techniques, when society has already supported trade-secret protection for those who would hide them.
Second, the range of patents which must necessarily cover software implementations may be far larger than "The League of Programming Freedom" expects. And it may be difficult, both legally and economically, to differentiate such software from the pure hardware logic machines (e.g., computer hardware itself) which we do expect to enjoy patent protection. A decision that software could not infringe patents might effectively eliminate protection for a large class of logic designs, including computer hardware.
Third, if good programming is actually "rare and precious," then (providing it fulfills the various requirements for a patent) it also deserves the historic reward for the disclosure of new techniques. An invention is not just an idea, it also includes reduction to practice, testing, and formal disclosure, and may well include extensive research and development as well. Even recognizing a patentable technique can be an important service! Unless we can argue that all software concepts are necessarily trivial (thus requiring no research, experimentation or testing), society should support the marketplace recovery of software development expenses and profit.
Fourth, although the process of recognizing that software can infringe patents may be difficult, the difficulty should not be overly exaggerated. Hardware businesses have always had to recognize patents, yet they manage to survive and prosper. Most patented techniques have alternatives, and sometimes the alternatives are actually superior. It is a sign of the importance of the software industry to society that we must now begin to recognize, record, and reward true advances in our technology.
And, finally, a patent provides one of the few tools which might allow a new business to compete in a mature industry. The natural application of patent concepts to software has the potential for improving the situation for individuals and small businesses, by allowing them to restrain the giants. Of course, large companies may see this as a threat. Perhaps they will even support "The League for Programming Freedom" to try to keep this threat at bay.
Mr. Ritter is a registered Professional Engineer, who is also known as Blue Jean Computer Engineering and Blue Jean Software. He built a working "Mark 8" 8008-based computer in October, 1974. He has experience in both hardware and software, having done microprocessor design for Motorola, and written the software for a dedicated multi-processor local area network for industrial control applications. He has recently concentrated on the design of cryptographic systems.
Last updated: 1996-05-28