Legal scholars point to a handful of philosophical theories as the basis for the moral judgment that patents on technology are just and beneficial to society. Are these theories valid in the context of the modern software industry? In particular, do the unique characteristics of software, in contrast to other forms of technology, make the traditional rationales used to justify patents less valid for software patents?
The “Natural Rights” Justification
John Locke, a 17th century English philosopher, developed the intellectual foundation for the natural rights justification for patents. Put very simply, this argument posits that individuals have a right to ownership of their own labor, and when people apply their labor to create things of value, they obtain ownership of those things. As applied to patents, this theory argues that inventors have invested their labor to design a process or machine, and are entitled to own that process or machine.
Does this theory hold up in practical terms, when viewed in the context of the modern software industry? For the most part, yes: there are very few who question whether software engineers deserve to own the fruits of their labor.
One problem, however, with applying the natural rights rationale to software patents is that it doesn’t take much effort to imagine an abstract computer program that does something useful that no one has done before; all the hard work is in making it work well. Thinking of what you want a program to do is much easier than making it reliable, scalable, user-friendly, and so on. If “inventing” doesn’t require actually implementing the program in a way that has measurable quality, people don’t actually need to do much work to obtain a software patent.
The patent law contains a requirement for “enablement” that is supposed to ensure that inventors disclose how to make their inventions without undue experimentation. But enablement only requires that a person be able to implement the invention as claimed. If the patent claims don’t specify that the invention must be reliable, scalable, and user-friendly, there’s no need for the patentee to disclose how to make it so — but the patent still covers all products and devices that do have these properties.
Patent law also has a “utility” requirement to ensure that a patented invention is useful; for software, this means being reliable, scalable, user-friendly, and all the other properties of valuable software. But as a matter of practice, the threshold for the utility requirement is relatively low, and the vast majority of patents are never challenged as lacking utility. And even if we put those considerations aside, I have never personally seen a software patent held to the standard that the enabling disclosure must specify a design with any of those properties. Codifying such a standard would further strengthen the natural rights justification for software patents, as it would ensure that patent applicants have actually invested time and energy to create a useful invention.
The “Monopoly Profits Incentive” Justification
The monopoly profits incentive justification accepts as self-evident that inventions benefit society, and argues for a special financial inducement (i.e., monopoly profit) to foster the creation of more inventions than would otherwise exist. In the absence of this special right, exercising a monopoly would be an illegal restraint of trade. While many economists agree that the term of the monopoly ought to differ according to the field of the technology, under the U.S. patent system, all patents are given a twenty year term.
Does the twenty year term make sense for software patents? And does such a term stimulate greater innovation in the software field? Most software innovators do not view patents as a reliable mechanism to prevent copycat competitors. Software entrepreneurs expect that, if anything resembling a monopoly is to be obtained, it must be done so the old-fashioned way, by stomping out the competition in the marketplace.
We have, in recent years, witnessed Apple’s inability to prevent widespread imitation of the iPhone through patents. Despite a tenacious campaign of patent litigation by Apple against Android device manufacturers, Android rapidly gained market share and is now dominant internationally. Apple earned enormous profits by being the first to market, and continues to innovate in an effort to stay ahead of Android, but Apple’s patents didn’t accomplish much. And in the end, that’s probably good for consumers (at least in the near term).
All of this serves to illustrate that, in the software world, being the first to market with a new technology is far more important than holding a patent to that technology. Software engineers innovate at a furious pace to stay ahead of their competitors, not to obtain patents. This stands in stark contrast to the pharmaceutical industry, where patents are the name of the game. It’s not at all clear that reducing the patentability of software, or limiting the rights of software patent holders, would reduce the pace of innovation in the software industry.
On the other hand, software start-ups do regularly use patents as a way to reassure investors that their technology, if successful, can’t merely be copied by one of the established tech giants. Although enforcing a patent against a large company with its own arsenal of patents is a tall order, a patent may persuade the large company that it will be easier just to acquire the start-up rather than imitate the patented technology. Regardless, software technology venture capitalists do value patents.
One possible conclusion from the above discussion is that software patent protections should be strengthened because if software engineers did view patents as a more effective way to block competition, they would innovate even faster than they do today (fast though the current pace may be). Either way, the monopoly profits incentive doesn’t appear to be as big a factor in the software industry as it is in other industries.
The “Exchange for Secrets” Justification
The final justification explored in this article is the exchange for secrets rationale. This justification argues that, absent the patenting system, many inventions would remain secret. The patent system promotes the public disclosure of knowledge, which later inventors and product suppliers can (eventually) leverage. In other words, the rights conferred by a patent are the inventor’s compensation for teaching society how to make and use the invention.
But is it true that inventors of software patents disclose anything of value in their specifications? And do software engineers consult patents to learn how to implement anything? First, since most software entrepreneurs don’t expect a patent to actually result in a monopoly, they keep “secret sauce” within their products — a special algorithm, for example — as confidential trade secrets. Second, you would be hard-pressed to find a software engineer who considers patent disclosures to be a useful source of information: since software patents are written in the stilted language of intellectual property attorneys, they are incomprehensible to most ordinary programmers.
To the extent that a patent specification does contain an actual software system design, in most cases it glosses over all the low-level design details where the magic happens. A cynical view would be that, in cases where the patentee has actually implemented the system, this omission is by design, and in cases where the patentee hasn’t implemented anything, this omission is from ignorance.
In any event, as any experienced programmer knows, the biggest challenges in implementing a high quality software system don’t become apparent until you start writing code. And you’re unlikely to find solutions to those challenges in a patent specification. A compounding problem is that the written description of the invention only needs to bear a “reasonable correlation” to the scope of the claims. As a result, society may not be getting a great deal in the exchange for secrets bargain.
Conclusions
The three justifications for patents discussed above — natural rights, monopoly profits, and exchange for secrets — all make perfect sense for the software industry in theory, but can be problematical in practice when examined in the context of the American patent system. Many criticisms of software patents arise because of the application of one-size-fits-all rules, such as patent disclosure requirements, to heterogeneous industries. I don’t believe there’s anything inherent in the nature of software that makes it unpatentable, as others have argued.
