I'm a professor of electrical engineering and public policy
at UCLA and a nonresident senior fellow at the Brookings Institution in Washington DC. During fall 2014 I am a National Fellow at the Hoover Institution at Stanford. My work focuses on the nature and growing impact of digital information. I am particularly interested the intersection of digital technology with public policy and the law. You can follow me on Twitter (@johndvillasenor).

How Much Copyright Protection Should Source Code Get? A New Court Ruling Reshapes The Landscape

On May 9, the Court of Appeals for the Federal Circuit issued what will likely be a highly influential—and in many ways problematic—ruling on source code copyright, holding that a set of Java application programming interface (API) packages “are entitled to copyright protection.”

The decision is the latest chapter in a copyright and patent infringement lawsuit filed by Oracle against Google [see disclosure below] in the Northern District of California back in August 2010, seven months after Oracle completed the acquisition of Sun Microsystems. With the acquisition, Oracle acquired an interest in the Java platform.

The complaint from Oracle (or more formally, Oracle America, Inc.) asserted, among other things, that Google’s use in Android of several dozen Java API packages constitutes copyright infringement. In a spring 2012 district court trial, a jury agreed but was unable to reach a verdict on whether Google’s incorporation of those packages in Android constitutes “fair use.” However, Judge William Alsup, who had presided over the trial, then ruled that the Java API packages in question were not subject to copyright protection in the first place, in effect rendering the jury’s infringement determination moot. The “particular elements replicated by Google,” wrote Judge Alsup, “were free for all to use under the Copyright Act.”

Oracle appealed, and because the case originally included patent claims as well as copyright claims, the Court of Appeals for the Federal Circuit, as opposed to the Court of Appeals for the Ninth Circuit, had jurisdiction. In its May 9, 2014 ruling by a unanimous panel of three judges, the Federal Circuit reversed Judge Alsup’s decision, concluding that “the declaring code and the structure, sequence, and organization of the 37 Java API packages at issue are entitled to copyright protection.”

Before considering the specifics of Federal Circuit’s decision, it’s helpful to take a step back and consider source code copyright more broadly.

Writing source code can certainly involve creative expression, thus implicating copyright. But by its very nature source code also involves the execution of tasks. This combination leads to a fundamental tension: On the one hand, copyright protects “original works of authorship fixed in any tangible medium of expression;” on the other hand, it explicitly does not protect “any idea, procedure, process, system, method of operation, concept, principle, or discovery.”

In some circumstances, this tension is relatively easily resolved. Consider a programmer who writes source code to implement a complex weather forecasting model. Models for weather forecasting are not subject to copyright, but the programmer (or, if the programmer is an employee, his or her company) may nonetheless have an enforceable copyright interest in the specific code written to perform that task.

However, not all examples follow this pattern. Consider a line of code that adds two numbers together. There aren’t very many different ways of indicating addition. It would make no sense to allow an author who publishes a line of code like “z = x + y” in a book on programming to prevent all readers of the book from using a similar expression when writing their own code to add two numbers.

Copyright law addresses this problem through the “merger doctrine,” which recognizes that when there are limited ways to express an idea, using copyright to bar others from expressing that idea would be inappropriate. As a congressional commission charged with studying “new technological uses of copyrighted works” wrote in 1978, when “specific [computer] instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to an infringement.”

To sort through these sorts of issues in source code (and other) copyright infringement cases, courts typically engage in a “filtration” exercise, starting with a full body of work and then identifying those components of the work—material subject to the merger and other doctrines, processes, public domain material, etc.—that aren’t subject to a copyright holder’s exclusive control. (The specific analysis varies with circuit; in Oracle v. Google the Federal Circuit applied its interpretation of Ninth Circuit law.) Once the filtration is completed, an infringement analysis can be performed.

This is what both the district court in California and the Federal Circuit did in Oracle v. Google. But while the district court found the Java APIs ineligible for copyright protection, the Federal Circuit, which at this point has the last word, reached the opposite conclusion.

Here are some aspects of the Federal Circuit’s ruling that give rise to concern:

* Of the 37 API packages to which Oracle was found to hold the copyright, three are “core” packages that are considered essential to the use of the Java programming language. There is little likelihood that Oracle will attempt to use the Federal Circuit’s ruling to stop everyone from using these three modules, and thus, in effect, to stop using Java. But there is plenty of downside to a precedent that gives any one company that level of power, even when unexercised, over an entire programming language.

In the Federal Circuit’s defense, the ruling acknowledged that it “seems possible that the merger doctrine, when properly analyzed, would exclude the three packages identified by the district court as core packages from the scope of actionable infringing conduct.” In other words, an opportunity to argue for specifically excluding those three packages from an infringement finding was available, but, as the court wrote, Google “does not try to differentiate among the packages for purposes of its copyrightability analysis and does not appeal the infringement verdict as to the packages.” Reasonable people can disagree on whether Google should have raised stronger arguments regarding the three core packages. At this point, however, that’s water under the bridge; for better or (far more likely) for worse, those packages have been deemed copyrightable.

* The Federal Circuit overestimated the practical flexibility available to programmers when choosing names. The ruling discussed a Java method with a name ending in “max,” which, as any programmer will recognize, selects the maximum from among multiple numbers. The “max” of 5 and 8, for example, is 8. Citing an Oracle brief, the court wrote that Google could have chosen to use a name ending in “maximum” or “larger” for this portion of code. That is true. For that matter, Google could have chosen to name it something completely incomprehensible like “yhwpodzkqcoyw.”

But what end would these sorts of gymnastics really serve other than to confuse programmers and others who might read their code? There are certain terms that tend to be used for certain things in programming, and it makes little sense to use copyright law to scare programmers away from naming things in the most logical, understandable, and consistent way. Unfortunately, that is exactly what the Federal Circuit’s ruling may do.

Post Your Comment

Post Your Reply

Forbes writers have the ability to call out member comments they find particularly interesting. Called-out comments are highlighted across the Forbes network. You'll be notified if your comment is called out.