Software Patents and Software Copyrights

Some readers will be surprised to learn that as of 2019, despite the rise of Facebook, Google, and Amazon, and despite decades of the explosive growth of Microsoft and Apple, the Supreme Court of the United States has declined to decide whether software is patentable, instead deciding every software patent case on narrower grounds. It is settled and statutory that software is copyrightable, but the test for copyright infringement and the extent of copyright protection are questionable.

Here I will explore a Law and Economics Approach to questions about whether and to what extent software can be protected by patent or copyright.

One might ask why it would even be questioned whether software can be patented. After all, patent law protects technology, and software is technology. However, patent law was created in the 19th century and solidified in the 20th, and the paradigm of patent law, in which its legal doctrines make sense, is to protect a physical device with a specific structure and physical elements of the object arranged a certain way. Patent law protects structures and elements, not functions or features. Also, patent law has always held that abstract ideas are not protected. Every invention it dealt with during its formative era was a physical invention. One thinks of the cotton gin as a good example of an early achievement of patent law. Lastly, patent law evolved for investigations in physics, biology, and mechanical engineering in which scholarly research led to lab experiments that yielded inventions — all of which was very expensive and hard to duplicate, although productive of discoveries that greatly benefited society.

Software does not fit this paradigm. Software is an abstract idea with no physical existence essential to its operation. The same software can usually run on any hardware, so hardware is not necessary to it conceptually. As such, it should not be, and is not, patentable. Software patent attorneys recite hardware in patent claims to try to create a jurisdictional nexus in the physical world, but this is merely a legal fiction. What makes software profitable is usually its features and function, not how the elements of its source code were structured. It is black letter law that you can patent structures, but not features.

Software generally takes preexisting computer program language syntax, software frameworks, software OS features (operating systems), SDKs (software developer kits), and software APIs (application programming interfaces, a set of syntax for software systems to interact with other software systems), and uses them to do new and useful or extraordinary things. All software essentially uses the same sort of syntax, such as logical and arithmetic operations and conditional statements and loops and variables, and the same framework features, such as user authentication and database reads and writes, and merely rearranges these into new and useful features for end users — a calendar, for example, or photo sharing, or music playing. Front-end designs, such as what web pages or apps look like, usually take a set of given elements (colors and shapes or rounded corners or shadows or progress bars) and find new ways to arrange old components. Software engineers usually do not reinvent the wheel.

Software development is relatively cheap, does not require lab research, and does not rely on academic research. Indeed, a person could, in theory, learn how to code by reading books and, for no more than the cost of buying a laptop, use a free, open source framework to write software that made millions of dollars. Essentially anyone can learn to code, and scientific or mathematical skill of academic caliber are not requisite. Contrast the knowledge of biology or electrical engineering that is required to patent a drug or a microchip.

The paradigmatic Silicon Valley startup is three 20-year-old computer science majors who hack around one night and make some software and release it — whereupon it snags 2,000 users in a matter of weeks. The inventors raise a million dollars of venture capital, promote the product, get a million users, and get acquired for a billion dollars. That story resembles that of Instagram and many other “unicorns” (the slang term for a software startup valued at over a billion dollars). These young people who know code at a very high level and get very rich from it are called Silicon Valley Geniuses.

In contrast, the paradigm for a patent is a lab that spends a ton of money on Ph.D. researchers who are looking for a cure for cancer. This lab must have the promise of a patent to justify the millions spent on research that may ultimately strike out. For this reason, trying to fit software into patent law is like trying to fit a square per into a round hole. The round hole did not expect and was not designed for a square peg.

Again, the abstract idea doctrine of patent law holds that abstract ideas and scientific principles are not eligible subject matter for patents. On the basis of the abstract idea doctrine alone, software is not patentable, and arguments that hardware gives it physical existence is a legal fiction. The actual statement of the software in a computer programming language does physically exist as bit values in computer memory or instructions in a processor, but language expression is copyright subject matter, whereas inventions are patent subject matter. Software, considered as an invention, is simply an idea implemented by a computer or device.

There is a path forward from this impasse: register software patents, but give them special rules. This path is especially attractive because it does not require new legislation and all the lobbying and hand-wringing that come with a political process, but it is more honest than legal fiction. The abstract idea doctrine should simply be retired as a patent doctrine that failed to keep pace with the evolution of technology. The abstract idea doctrine can be replaced by a distinction between theoretical knowledge and practical knowledge, which is a plausible distillation of the abstract idea law, wherein software patents that yield practical knowledge, as opposed to merely theoretical knowledge, can be patentable subject matter.

But this leaves the question of what software should be patentable.

There exists a certain basic set of patentability subject matter requirements that every patent lawyer knows: novelty, nonobviousness, utility, adequate disclosure, and claims defined by a specification. The key is two patentability subject matter requirements, as interpreted by Law and Economics. First, a patent must be novel. Second, it must be nonobvious.

From a Law and Economics point of view, monopolies are horrible, because they raise prices and stifle competition. Yet a patent is a 20-year monopoly on an invention. So why grant a patent? A patent is a trade whereby society gives a monopoly to an inventor in return for his disclosing his invention, which then becomes part of the knowledge possessed by society. For this trade to be justified for society, the benefit to society of acquiring the knowledge must exceed the loss from higher prices during the monopoly. Novelty and nonobviousness are two guarantees of this. If the knowledge is not new, society has no need to buy it, because it already possesses it. The underlying intent of the nonobvious requirement is that other inventors would be unlikely to invent the same thing during the 20-year life of the monopoly, because otherwise society could gain that knowledge without paying out a full 20-year monopoly, even if society might wait five years for the invention to be disclosed by other inventors. This analysis replicates the patent law doctrine that combining old parts into a new configuration is not patentable unless the new whole is more than the already known sum of its parts. If A, B, and C are already known, then combining them into ABC might be new, but if there is no new knowledge above what was known from A, B, and C before, then society does not gain any new knowledge and has no reason to award a monopoly.

From this we arrive at a new test for whether a unit of software should be eligible for a patent: the Silicon Valley Genius Test. A patent should be awarded for something that a Silicon Valley Genius does not already know and could not figure out and is unlikely to think up during the next 20 years.

The Silicon Valley Genius knows every element of source code syntax and every feature already available to end users, so a new combination or configuration of those, absent something new that he does not know, will fail the test. The invention must be innovative and creative enough that, even with actual billions of dollars as motivation, the real geniuses of Silicon Valley are not likely to invent it within 20 years. The Silicon Valley Genius is smart, he is a genius, and if something could make a profit and could be cobbled together from the prior art, he will find a way to make it. But to pass the test, the knowledge involved must be new to the SVG. It must look like a lightbulb turning on in his head. After all, he is the representative member of society who actually gains the knowledge disclosed in the patent and is able to monetize it after the monopoly ends.

The Silicon Valley Genius Test is a very high standard to meet, but from the Law and Economics point of view there is otherwise no real reason to grant a patent — because real Silicon Valley Geniuses do exist in large numbers with venture capital funding and low development costs, so they will likely discover whatever the invention is and society will get it at a lower cost than by paying a monopoly. It is conceivable that most software patents would be struck down under the SVG test. Yet that would be the correct result, lowering prices by busting monopolies while only paying for true genius inventions that benefit society most.

As with any test, we arrive at this question: how to pass it? Any inquiry using the SVG test must begin by identifying what is the knowledge that society gains in return for the proposed monopoly. From a Law and Economics point of view, if society does not take a profit on the trade of knowledge for monopoly, a patent should not issue. We can ask what new knowledge about how to do or accomplish something the disclosure teaches, and without which it may be merely theoretical knowledge, not practical knowledge. Having identified practical knowledge, we then ask whether an SVG knows or will soon know this.

The SVG test can demonstrate this in several ways. Expert testimony from real established SVGs can be taken on the issue of whether they think this would be novel and nonobvious to SVGs. Polls and surveys and focus groups can show the knowledge to groups of 20 to 100 SVGs plucked from Silicon Valley or the talent pool of software developers and ask them to vote on whether they have seen this or they think someone would have thought of this within the next 20 years. And there can be a factual analysis of the prior art to see if the patent is merely a reconfiguration of old known elements into new features, which is essentially not even novel, let alone non-obvious.

Prior art analysis should not be limited merely to academic scholarship and published patents. It should look to the documentation of every computer programming language, framework, and API, as well as analyzing the source code in every repository of free open source software, such as GitHub.

Now let’s look at copyrights. The Copyright Act defines software as a literary work, and courts have developed a test for software copyright infringement that is essentially the Hand Test applied to source code. The Hand Test, named after Judge Learned Hand, is a popular test for deciding idea-expression dichotomy issues in a copyright infringement case. The idea-expression dichotomy is a copyright doctrine that holds that literary expression is copyrightable subject matter, but ideas (and facts) are not.

Let us be honest: it is a legal fiction that a computer program is a literary work. As with patents, software doesn’t really fit the mold. But let us consider a computer program and take seriously the position that it is a literary work. A computer program, in the copyright sense, is a unit of source code. Source code is composed of words, written in a computer programming language, that tell a computer what to do (leaving aside the detail that it is compiled to machine code, which is a series of ones and zeroes loaded into the processor, and the machine code is what actually tells the processor what to do). So it is text written in a language, and could be protected under copyright like any book or article.

But what makes software special, and what makes people want to protect it, is precisely the thing that normal literary works lack: technological functionality and computer operational execution. If the basis of software copyright is that software is a literary work, then it should be protected as a literary work. Assume that an author writes a short story. Under the idea-expression dichotomy, copyright could protect literal copying of her words and also her voice, her style, her idiom, and the details of her plot and story and characters, although not the abstract ideas of her plot or her character archetypes. Copyright would also not protect the effect her story might have upon her readers.

Now assume that a chef writes a recipe in a cookbook. Literal copying of the cookbook would be copyright infringement, but when chefs use it to bake cakes, copyright would not normally give the author ownership over the cakes or any right to infringement damages. Selling pirated copies of a cookbook could lead to legal remedies, but baking a cake would not. If one chef buys a cookbook and bakes a cake and sells slices which compete against the author's cakes, absent some contractual license as a condition of buying the book, that is not copyright infringement.

I believe that copyright should protect the literary aspect of source code: its word choice, style, and idiom, the voice of the author as a writer of software, and any structural extensions of such, but should not protect functionality, which is properly within the scope of patent, not copyright. If the cake itself, or the reader enjoyment, is not copyright infringement, neither should be any source code elements, to the extent that they have an effect on computers.

A doctrinal basis for this position exists within the idea-expression dichotomy, which holds that where the copyright is the only possible expression of an idea, or one of a small finite set of potential expressions, then it merges with the idea and is a defense to infringement. From this we may infer the Functional Merger Test, which holds that features and functionality are facts about what software does or are simply ideas, and that where functionality merges with the expression of the source code under Merger Doctrine, the functionality is an idea for purposes of the idea-expression dichotomy, and the software as a functional entity cannot be protected.

Some examples may help to explain this. Assume that a feature requires software source code to take user input ten times in sequence and each time compare the input to a value, outputting a message if and only if the messages match. Assume that this must be done in one specific programming language. There is probably a small finite number of syntactic ways to do this. Declaring a variable, putting user input into it, comparing it to a string literal, and using a loop to do this ten times would suggest certain syntax to an SVG who was, for example, experienced in Java, or in Python. How to code this naturally emerges from the function or feature that is the end goal. The expression has therefore merged with the idea under Merger Doctrine, because there is either only one or a discreet finite number of expressions that is capable of correctly expressing the non-copyrightable idea.

Where the copyright would spoof a patent and grant a de facto monopoly on a technology, which Merger Doctrine in copyright law explicitly rejects, there should be a defense to copyright infringement. But the same argument would apply to most software copyrights, in the absence of actual copying of source code or the use of someone else's source code verbatim without permission. Languages, frameworks, SDKs, and APIs have a finite set of syntax to accomplish common jobs, and any common feature, or any feature conceivable by combining or reconfiguring known components, will suffer this syndrome of any one solution necessarily resembling other solutions. Writing source code takes a lot of work and investment, and copyright properly protects unauthorized use or literal verbatim copying of source code, but all copyright infringement litigation that comprises or touches upon functionality must fail, under Functional Merger Doctrine, because ideas are not copyrightable subject matter and the copyright would grant a monopoly on the idea and therefore the copyright is invalid to the extent that it is directed at protecting functionality. A software writer’s voice, style, and idiom could be protected, but these have no financial value, so enforcement would be rare.

To extend the cake hypothetical: assume that the recipe calls for flour, sugar, chocolate, eggs, butter, and honey. Assume that the chef writes the recipe in a cookbook and publishes it. What if it is impossible for another chef to write a recipe for that cake without using those six words: flour, sugar, chocolate, eggs, butter, honey? To judge infringement, one might try to grade the text on the scale of abstract idea to specific expression. But that would not be my approach. If the copyright would grant a monopoly on noncopyrightable subject matter, namely the cake, then there should be no infringement. There does not even need to be any deep analysis to find infringement. The copyright itself should be held invalid to the extent that it owns the cake recipe.

By contrast, the current test for software copyright infringement seeks to remove all unprotected elements and then be left with the core structure and elements of the software, which other software can infringe if there is substantial similarity. This is essentially a version of the Hand Test for copyright infringement. The Hand Test posits a spectrum or continuum of the idea-expression dichotomy with unprotected idea at one extreme end and full protection as 100% expression at the other end. The judge applying the Hand Test then hears arguments and draws an arbitrary line and points to an arbitrary spot on the spectrum, above which is “protected” and below which is “idea.” Judge Hand famously said that no judge can know where he should draw the line, and no judge ever will, and the Hand Test is as much an acknowledgement of an arbitrary decision as it is an actual test applied by a judge. The copyright software infringement test inherits all the flaws and weaknesses of the Hand Test, with the decision of what to protect being arbitrary, unpredictable, and without rigorous rational justification. The test removes unprotected elements to find what is protected, but absent a test on top of it, this is circular reasoning: an element was removed because it was not protected, and it was not protected because it was removed.

In a novel you can have the plot in general (say, forbidden love), plot details (forbidden love between young Italian nobles), and fully defined textual detail (Romeo and Juliet). You can have a spectrum on which you begin with Romeo and Juliet, then move to their story but with different names, then not in Italy, then not in the Renaissance, then they aren’t from warring families but just from groups that hate each other, then they don’t both die at the end, and you can then arrive at just the abstract idea of forbidden love with a tragic ironic ending. To analyze whether West Side Story would infringe Romeo and Juliet (which could have been a real case, if copyrights had been started centuries ago and never expired), a judge would need to look at every point on the line from idea to expression, choose an arbitrary point, then assess whether West Side Story contains enough of the protected elements of Romeo and Juliet to infringe.

In contrast, source code is fully defined, and every item of syntax and every code structural organization and source code design exists only for the purpose of achieving a result; so there are really two discreet entities, the source code on the one hand, and features and functionality on the other hand, and there is no spectrum or continuum between them. Current software copyright law applies a Hand Test Romeo and Juliet approach instead of the either-or, all-or-nothing approach that I am recommending.

My position is that the test for software copyright infringement should be that literal copying or the unauthorized operational and actual use of source code by infringing hardware is liable but any allegation of infringement of non-identical source code fails, to the extent that it would protect (and grant a monopoly on) features or functionality. A Law and Economics analysis of infringement sheds light here.

Writing source code costs money: resources are consumed to pay the salary of the software developers while they write the code, and to hire coders who are technically competent to do so. By granting a copyright, copyright law gives the authors a monopoly on the source code and its usage for the life of the copyright, so that they can recover their investment. If infringers come along and sell copies of the source code, they can make the same revenues as the author but without the cost of authorship, and are hence stealing the money paid to make the source code. Copyright law properly prices the cost of creation into the sale price of the software, so that the purchaser pays the cost of its creation by the manufacturer (plus whatever profit the market will bear).

On the other hand, assume that someone writes source code that has a specific feature, and someone else writes a second computer program in the same computer programming language, implementing the same feature. The task, and the available syntax, defines and specifies certain optimal ways of coding the feature, so the second person's software ends up substantially similar to the first software. The first person sues for copyright infringement. The software is substantially similar, but damages are not for recovering the author’s cost of writing source code; instead he is trying to own the feature. This grants a monopoly and raises prices and eliminates the second person as a competitor and a substitute in the marketplace. The difference in price between what the software would cost in a world with price competition between the first and second persons, compared to what the software costs with the monopoly, is the amount of economic surplus that society loses by granting the monopoly.

It may or may not be economically efficient for society to grant a monopoly in return for technology, but to the extent that it does, patent law is the regime that does so. The details of patent law have been carefully calibrated by Congress to consider the costs and benefits of monopolies paid by society in return for technology given to society, both in eligibility and in duration of the monopoly, and copyright law should not be doing this. Judges have explicitly recognized that copyright law should not usurp patent law in Merger Doctrine cases, and the Functional Merger Doctrine for software copyrights will correctly eliminate infringement for features and functionality.

The Functionality Merger Doctrine is confirmed both by logic and by pursuit of the Law and Economics question: why is the copyright owner suing for infringement?

A lawsuit costs money, and the litigant must expect to get more out of it than what he spends, or as a rational economic actor he would not choose to litigate. If literal copying or unauthorized use of source code happens, and if his cost of having made the source code exceeds his loss through litigation, then he can gain something, the protection of his investment. Otherwise, if he sues, and only nonfunctional elements are protected, he gains nothing, because purely stylistic elements of source code have no financial value. Software is not poetry, and one does not write it for beauty. He would not sue unless he could monetize his lawsuit, for which he would have to take some of the money made by the functionality away from the competitor he sues. From a Law and Economics point of view, something must make the money to pay the damages, otherwise they would be unfunded.

Thus, absent literal copying, no software copyright infringement litigation would ever be initiated, unless it was to attack competing functionality in different yet similar source code, which is precisely what copyright as a literary work of authorship should not protect, and which is within the scope of patent, not copyright. Functional Merger Doctrine can eliminate all such lawsuits.

The test for whether software copyright infringement should be found will follow this inquiry: did literal verbatim copying of source code or actual unauthorized use of source code by hardware occur? If yes, copyright infringement. If no, there must be a presumption that the plaintiff seeks to protect functionality and must fail, rebutted by a showing that the asserted protected elements are nonfunctional — for example, voice or style.

Return to the example of the chef. Assume that the recipe says, “Mix flour, butter, eggs, chocolate, honey, and sugar; then bake.” If some publisher reprints this text in a rival cookbook, that is theft of the text as a literary work of authorship. But a chef cannot say the recipe without using the six words that name the ingredients, so they merge with the functionality. Now what if someone copies the structure, listing savory ingredients first and sweet ingredients last? Could the chef sue for infringement then? Scholars and judges may think this is a tough question, but really it is easy. Who cares in what order the ingredients are listed?

No lawsuit will ever get funded unless it is to protect something that makes enough money to pay the legal fees — in software, functionality. So the Functional Merger Doctrine test will apply and answer this question. The chef owns the cookbook but not the cake. No one cares about the recipe; people only care about the cake and what it tastes like. A chef’s recipe is the perfect analogy for software, because source code is a set of instructions that tells a computer what to do, and the functionality, the cake, is the operation of the computer executing that set and series of instructions, which does or accomplishes something useful. (It is interesting to wonder whether a chocolate honey cake would be surprising and unexpected enough to deserve a patent, although as a mere combination of already known elements it probably should not.)

To conclude: it is a legal fiction that software is not an abstract idea for the purposes of patent law, and it is a legal fiction that software is a literary work. But, lacking the political and legislative will to reform and create a new regime for software, we must make patent and copyright law work for software, through tests that are better suited for it. The Silicon Valley Genius Test and the Functional Merger Doctrine Test are clear, bright line tests that are easy for judges to use and that will clean up and refine the law of intellectual property for computer source code.