The Problems With Software Patents (Forbes Cross-Post)
By Eric Goldman
The U.S. patent system largely treats all innovations equally, but innovation often works quite differently in different industries. In particular, the software industry differs from other major innovative industries–such as computer hardware and biotech/pharmaceuticals–in several key ways, and those differences can create (and have created) significant friction for the patent system.
Software patents have also created big–and expensive–problems for companies throughout all sectors of our economy. Pretty much as soon as they get venture financing, start-up companies are getting approached by “patent trolls” with offers they can’t refuse: pay me now or pay your lawyer many times that amount to prove you don’t have to pay me. And large companies, especially in the smartphone industry, are paying literally billions of dollars to acquire patent portfolios to keep those portfolios from falling into the wrong hands and with the hope that large patent portfolios will fend off competitor threats (i.e., provide the company freedom to operate its business without interference from competitors’ patents).
This post is the first of a two-part series recapping a conversation we had earlier this month at Santa Clara University entitled “Solutions to the Software Patent Problem.” In this post, I’ll explain how innovation in the software industry differs from other industries and some of the resulting problems associated with software patents. In a subsequent post, I’ll talk about possible fixes.
What’s unique about software? Three main differences:
1) Software Has Short Innovation Cycles
Software iterates quickly. Most software programs, and features of those programs, have an effective commercial life of only a few years. Then, new software developments quickly render prior innovations obsolete . Contrast this with mechanical innovations, some of which may have commercial lives of decades, and pharmaceutical innovations, which may retain commercial value indefinitely.
Some implications of the short innovation cycles in the software industry:
Software Has Significant First Mover Advantages. Software innovators can recoup some of their R&D investments simply through de facto marketplace exclusivity from being the first mover. An example: assume that a particular software innovation has a two-year commercial lifecycle and it takes competitors 6 months to bring a matching product to market. In a situation like this, the first mover gets 1/4 of the maximum useful exclusivity period simply by being first to market. In some cases–many cases?–the exclusivity period provided by the first mover advantage is more than enough to motivate software R&D without any patent protection.
Software’s Lifecycles End Before Patents Issue. As a practical matter, the commercial lifespan of a software program or feature (before being mooted by new innovations) is usually shorter than the time it takes the U.S. Patent & Trademark Office to resolve a patent application–a process that often takes 4 years or more. So invariably the patented innovation will be obsolete by the time the Patent Office decides if it’s worthy of a patent.
2) Software Will Be Produced Without Any Patent Incentive
We principally justify patent law on utilitarian grounds: that social welfare improves by providing innovators with an economic reward in the form of a limited-term marketplace exclusivity. The utilitarian argument leads to patent’s “quid-pro-quo”: society gives innovators something really valuable–monopoly-like rights to exclude competition–in exchange for a number of socially valuable deliverables from innovators: investments in R&D, public disclosure of those R&D results, and eventually the unrestricted rights to replicate the innovation.
It’s great when the quid-pro-quo model works as designed, but that’s not always the case. One way the quid-pro-quo model breaks down is if we give up the quid (the rights to exclude) when we would have gotten the quo (the R&D investments and public disclosure) in any case. In those circumstances, society “overpays” for the innovation.
There are several reasons to believe that society overpays when it provides patent protection for software.
Copyrights and Trade Secrets Provide Adequate Production Incentives. Multiple aspects of software can qualify for copyright protection: the source code, the compiled code, the visual layout, the documentation, possibly even the aggregation of menu commands (the “structure, sequence and organization” of the software). Copyright only protects the expression of ideas, not the ideas themselves, so the ideas may be freely reused by competitors and others. However, the line between ideas and expression in copyright is hardly clear (see, e.g., my posts about EA v. Zynga and the Spry Fox v. Lolapps disputes), giving even more berth to copyrights’ scope.
Trade secrets also protects software source code and sometimes other aspects of software, such as proprietary limited-distribution documentation. While trade secrets won’t prevent copying of widely available software, even in that case it can still slow down the competition (and thereby extend any first mover advantage) by preventing the competitors from obtaining shortcuts to facilitate knockoffs.
Thus, even if it’s not complete protection, the combination of copyright and trade secrets can provide substantial intellectual property protection for software. Historically, this combination has provided adequate incentives for the software industry. During the first several decades of the software industry–a period which saw explosive industry growth–software patents were rarely obtained and even more rarely enforced.
Software Vendors Can Restrict Competition Without Patents. Software can have substantial lock-in effects that can thwart competition without patents. For example, software users may become locked into one vendor’s offerings due to proprietary file formats, the difficulty of learning/re-learning menu commands or keystrokes, a developer community that creates valuable apps specific to the software, and user investments in their own proprietary customizations (such as the infamous example of macros in Lotus 1-2-3). We might lament the competitive distortions associated with these lock-in effects, but so long as the software vendor doesn’t break the law, they represent a crucial explanation for software innovation without patent incentives.
Software Gets Produced Without Any IP Incentives at All. The free and open source software community provides another example of software’s quo without patent’s quid. In those communities, people work collaboratively without any individual contributor getting any intellectual property protection for their contributions. In many cases, this is because the contributor has other ways of monetizing their efforts, such as offering maintenance or customization services or building a reputation for programming expertise that leads to job offers. (I explore these alternative monetization methods in my article comparing Wikipedia and the FOSS community). Further, some free and open source software contributions are purely altruistic, made without any financial expectations at all. Collectively, the free and open source software community has proven that lots of software–even large-scale enterprise-class software–will be produced without any patent incentives.
3) Other Problems
Software Gets Patented at Too High a Level of Abstraction. Stripped to its basics, software gathers, manipulates or displays data. There may be novel ways of accomplishing those goals, but the true novelty typically is limited to some arcane implementation in the software code, not the concept of gathering, manipulating or displaying data. Unfortunately, too many software patents claim protection at the highest level of abstraction (i.e., “moving data on a network”), not at a lower level like the more mundane implementation of that concept.
The result is overbroad software patents that overclaim their true novelty. The overclaiming should lead to patent application denials on numerous grounds, including failure to enable, failure to satisfy the written description requirement, and obviousness. But if the PTO doesn’t aggressively screen the patents on those grounds, bogus patents get through the system. That’s happened way too often.
The USPTO Mishandled Software Patent Applications. Furthermore, for a long time–a decade or more–the PTO did not adequately research the prior art applicable to software patents. Patent examiners typically focus their prior art searches on the database of existing patents. This means that when there’s a watershed technological change–like the initial wave of software patent applications–the examiners don’t see a lot of applicable prior art in their existing patent database. Therefore, they grant patents that don’t deserve protection. Eventually the patent database becomes rich enough with prior art to reach an equilibrium, but the errors in the interim produce a batch of legacy patents that never should have issued.
Software Is Too Hard to Describe Precisely. Related to the abstraction problem, the boundaries of many software “innovations” are too hard to describe precisely. (In contrast, the specific implementation methods would be much easier to describe). Because of the semantic challenges, the resulting patents are so opaque that no one can understand what they mean. This also means that the patent owner can adopt expansive interpretations of the patent boundaries and then use the threat of patent litigation over those ambiguous borders to extract cash from potential defendants–even those who would ultimately be outside the patent’s scope if they invested in challenging the patent owner.
Patent Research by Subsequent Innovators Is Too Costly. In theory, product developers can check the patent database to see if they are transgressing someone else’s patents. In practice, this doesn’t work in the software industry for at least two reasons. First, as mentioned, the imprecision of software patents makes it hard for developers to realize that the patent owner thinks the patent covers the developer’s efforts. Second, large software programs may have millions of lines of code, while it’s possible to obtain patents for functionality that can be expressed in only a few lines of code. The result is that a single software program could potentially implicate thousands, or even tens of thousands, of patents. The costs to find these patents, research their applicability, and then where appropriate negotiate licenses to even a small fraction of those patents, would vastly exceed the potential economic returns from most software applications. Thus, software developers rationally choose not to research the patent database at all and instead “fly blind.”
There are even more problems with software patents, but this brief summary lays the foundation for part two of this series, where I will examine some possible solutions to the problems associated with software patents.