Rise of the Reformers

Imagine an early information-sector entrepreneur who wrote some code and developed a product, then hired an attorney and asked him whether she should seek patent protection or copyright protection.

Back in the early days of computing, say the 1950s, the PTO refused to grant software patents while the Copyright Office copyrighted soft­ware. But it’s not really their call. Congress took until 1980 to confirm that software was, in fact, copyrightable.¹⁵ Then, in 1981 the Supreme Court found a software patent that it liked¹⁶ but getting a software patent was still difficult. Software patents remained rare until the mid-1990s. In 1994, the Court of Appeals for the Federal Circuit, the appellate court uniquely charged with hearing all appeals in patent cases—and whose decisions about patent law only the Supreme Court can review— determined that the PTO had been too stingy in awarding software patents.¹⁷ The trickle of software patents gave way to a stream. Four years later, the Federal Circuit opened the floodgates when it ruled that “business methods” applying algorithms to specific problems, in finance for example, also qualified for patent protection.¹⁸

The confusion about software IP rights continued, and confused states are inherently unstable. When Amazon.com managed to convince a Dis­trict Court judge that it deserved the patent on one-click shopping,¹⁹ the Federal Circuit recognized that protections may have gone too far. It overturned that ruling,²⁰ but not before Barnesandnoble.com had to change its shopping software in the middle of the 1999 holiday season. In the meantime, Amazon’s one-click patent interfered with Internet retail development for fourteen critical months.

The challenge of categorizing software thus posed some serious defi­nitional problems that continue to cause controversy. But the underlying problem runs deeper than ambiguity at the edge of legal doctrine. Despite the availability of software patents, the combination of copyright and trade-secret law continues to protect most software. This protection has allowed software developers to exert their rights in new and disturbing ways.

Software just doesn’t fit into any pre-existing IP category. Sure, it’s somewhat like a book (in that it contains text that’s pretty easy to copy), and it’s somewhat like a machine (in that it does something), but it’s also emphatically not like a book and not like a machine. If we offer copy­right protection only when the source code is revealed, software devel­opers will have no real protection and little incentive to create software. After all, copyrights protect expression, not ideas. Put another way, while a reinterpretation of a Harry Potter novel would probably bomb, Java code based on someone else’s C code would probably run just fine. That renders the sort of protection that we normally offer to book authors worthless to software developers. But if we patent too many algorithms or business methods we risk shutting down the entire industry, and if we settle for the current combination of copyright and trade secret pro­tection we’re likely to be severely exploited in a marketplace laden with antitrust violations.

Patents and copyrights are what they are. No mechanism exists to allow a court to decide that the owners of a “software patent” possess a different sets of rights than the holders of a hypothetical alternative such as a “mechanical patent.” They would both hold patents—and any new rules established to help software patents make more sense had better not cause confusion in any other industries.

A number of people have proposed more moderate reforms that might actually work without changing too many existing laws, which is good because unless and until we manage to convince Congress that our IP system is broken, a patent is a patent and a copyright is a copyright. And it’s simply irrelevant that software is neither a book nor a machine.

But we pay our academics to shoot for the stars, and so their litera­ture is replete with suggestions for software-specific IP rights (including my own humble contribution).²¹ We owe perhaps the most significant of these contributions to a team of two IP scholars, Pam Samuelson and J. H. Reichman, and two technologists, Randy Davis and Mitch Kapor. Their grandiose Manifesto roused the faithful of Columbia University’s Law School at a 1994 symposium by “contributing] a basic framework for constructing a new form of legal protection for program innova­tions.”²² The Manifesto tackled a critical issue that computer scientists had deferred to their social science colleagues: how to motivate and reward software developers.

The team began its work on the horns of a dilemma. Most programs don’t meet the requirements for patents, so we need to give them copy­rights. But copyrights don’t protect ideas—such as the way that a com­puter program works—and programmers care about the ideas embodied in their code. So if we reward a programmer like we would any other author, we’re not providing much motivation. But if we allow both copy­right and trade-secret protection, then we’re cutting ourselves out of the bargain—we’re giving software developers legal protection without asking them to reveal anything.

The Manifesto proposed to parallel many of patent law’s important motivators, but in ways and within a time frame appropriate for the information sector. It proposed requiring software developers to disclose their programs—including their source code—in exchange for short-term exclusive legal rights to their program’s innovative behavior. So if, for example, you developed the first spreadsheet, the proposed IP rights would guarantee that you’d be the only spreadsheet vendor on the market—for a couple of years. By the time those rights expired, your source code and the idea it embodied would be in the public domain and you’d probably face competition.

In all honesty, disclosing source code makes enforcing any set of IP rights pretty difficult. But the challenge is not impossible to meet. For example, developers need not necessarily be forced to publish their source code immediately. We might be better off requiring developers to register their source code with the government in exchange for IP pro­tection and deferring government publication for long enough to permit commercial development. But that’s an implementation detail—critical no doubt, but tangential to the scheme’s inner workings. The funda­mental idea is to develop specialized software IP rights that mimic the patent system in many ways, but that differ from it in several others— notably the standards for granting protection and the timeframe of that protection. This radical proposal would command a great deal of Con­gressional attention, but it’s certainly worth pondering.

Not all recommendations are quite that radical. The National Research Council favored a more tempered approach. Its 2000 study, The Digital Dilemma, concluded that although a clear need for new forms of IP protection exists, legislation would be premature.²³ The study recommended that Congress observe the various “experiments” already underway. It noted that various businesses were relying on combinations of contracts and technology to protect software, and that some judges were reinterpreting parts of IP law to make it relevant to the informa­tion sector.

Even those of us who believe that our IP system will need a major overhaul someday soon, even those of us who believe that the current system hurts the information sector, even we don’t necessarily believe that we know exactly what the best answers are today.²⁴ What’s more, our certainty is irrelevant because until Congress is ready for an over­haul, our readiness, certainty, and necessity don’t matter. So while IP theorists may be a bit radical, we’re also realists in practice. And realism breeds moderation, which suggests looking at existing IP law to see which pieces of it may be useful with only a little bit of tweaking.

Julie Cohen and Mark Lemley, for example, argued that a large part of the problem with software patents today stems from the courts’ reading them broadly.²⁵ In other words, if a new program looks like it might infringe an existing patent, the courts have been ruling in favor of the patent holder. That makes the patent pretty potent. Cohen and Lemley would curb that potency by ruling the other way. They would say that if a new program might not infringe, the courts should rule against the patent holder. In their view, proving infringement of a soft­ware patent should be difficult. That would leave a patent with a fair amount of value, though less than it has now. It would also free up large areas of innovation that developers wary of an existing patent’s scope might otherwise avoid. Cohen and Lemley also made a few other sug­gestions about minor reinterpretations of existing laws that could help clear up difficult problems patent issues cause. They didn’t address, however, the broader issue of patent/copyright/trade-secret protection; they said nothing about the challenge posed by software developers who misuse their triple protection to exploit consumers.

An existing bit of law might help address that, too.

According to the Supreme Court, I do. It seems that you took your perfectly legal patent right and tried to leverage it to take over an inde­pendent market that was supposed to have been competitive. You tried to exceed your patent rights, and in so doing, you misused them. What can the courts do about it? They can be pretty tough. They can refuse to enforce your patent until you can demonstrate that you’ve undone the damage and restored competition to the market for independent movies. You reduced the amount of competition to the detriment of movie con­sumers? Fix it. Once you can show that you’ve set the market back to where it should be, the courts will enforce your rights again. Until then, don’t bother suing.

But that’s patent law. Is there such a thing as “copyright misue?” According to Brett Frischman and Dan Moylan, copyright misuse has existed for a long time, but no one talked about it much until fairly recently.²⁸ They explained that the courts couldn’t foresee how anything protected by a copyright could give its owner the awesome power needed to misuse it—at least until we invented software. After all, if you take away my patented projector, I’d have to shut my theatre. But if you pull your copyrighted movie, I’d just run someone else’s.

Software changed all that; it was both copyrighted and functional. Somewhere around 1990, the courts decided to start applying a doctrine of copyright misuse in the same way that they had long addressed patent misuse. The first few cases tread somewhat lightly and looked at narrow, specialized software for Computer-Aided Design and Computer-Aided Manufacturing (CAD/CAM), for medical practice management, and for technical equipment diagnosis and repair. The courts concluded that the companies that made the dominant software packages in each of these markets had tried to force their customers to either accept terms or to buy products that they didn’t want. The courts ruled that these actions constituted copyright misuse and that they wouldn’t enforce the copy­rights until the misusers fixed the broken markets.²⁹

While most IP scholars, and every court that’s considered the issue, believe that copyright misuse is both important and real, we still haven’t heard from the Supreme Court—who has final say on the matter. However, assuming that the Supreme Court notices that copyright misuse is a useful doctrine needed to cleanup potential problems, the voices of moderation appear to be correct. While after-the-fact tweaking and cleanup are hardly a substitute for aligning IP rights with technological and economic imperatives, they’re not bad in the short run.

But maybe we could do better still—again without requiring Congres­sional action. An entire community of software developers actually refuses to maintain its source code as a trade secret; its members publish their source code where all can see it. Most people never notice this “open” source code, because most users just want software that works. But programmers and software developers can inspect this source code, extend it, modify it, and use it as a model for future software develop­ment. Open source developers, like proprietary software companies, circulate their software subject to licenses outlining conditions to which the “buyer” must agree. For most users, these terms are quite liberal. Not only is the software free, but you can do virtually anything you want with it as long as you don’t distribute it. If you do distribute soft­ware, though, you’d better pay attention to the license’s specifics. Some open-source licenses, notably the General Public License (GPL),³⁰ try to enforce the community ethos through a clever “copyleft” clause. Devel­opers who incorporate any GPL-licensed code into their own software must release their new products under the GPL. Anything else would violate the terms of their license. But even the GPL isn’t all that fierce. It reinforces an unusual business model, but it tends to be much less restric­tive than most software licenses. And many other open-source licenses are less restrictive than the GPL; they even allow developers to incorpo­rate open source code into their own products with secret source code.³¹ Fierce or not, copyleft represents a truly clever reassertion of the Con­stitutional bargain. Copyleft keeps knowledge in the public domain using only existing IP laws—a moderate approach that’s somehow more radical than what the radicals propose. At least, so things appear; no one has yet tested copyleft in court. And though copylefting resolves the problem of dual copyright and trade secret, what of patents? Even if I had access to patented source code, I couldn’t do anything with it. I couldn’t use it without permission, I couldn’t customize it, and I certainly couldn’t sell my own interpretation of it. Software patents are power­ful—and increasingly common. By some counts, the PTO has awarded hundreds of thousands of them over the past decade. How does the PTO know which ones to grant? The sad truth is, it doesn’t. Patent examin­ers have a hard time determining which applications truly represent novel advances to the state of the art—the basic requirement for patent pro­tection. And to make matters worse, the PTO isn’t hiring enough com­puter scientists, mathematicians, or statisticians to allow them to make better decisions; applications to join the Patent Bar favor traditional sci­entific or engineering training.³² The preponderance of improvidently awarded software patents alone could do more than simply complicate the free circulation of open source code; it could stunt the information sector’s overall growth.

But that problem has yet to materialize fully—and perhaps, if we’re lucky, it never will. In the meantime, we can add copyleft to a radical manifesto, a number of moderate modifications to current law, and the moderate application of misuse remedies as after-the-fact fixes. Our IP priests have thus met half of the challenge set for them by suggesting ways to cut public IP costs. Their proposals’ likely impact on software quality will be addressed in a later discussion of the information sector’s future in chapter 8.