Will Oracle v. Google Mean The Death of the API economy?

Between the advents of mobile computing and the Internet of Things (IoT), the API is rapidly becoming the most important leverage point in the history of computing. Few, if any, profoundly scalable innovations are able to fully deliver on their potential without the employment of APIs. A possible threat has emerged in the form of the court case Oracle America, Inc. v. Google, Inc. centered on Oracle’s claim that their Java APIs are copyrightable.

At an APIcon panel discussing the U.S. Appellate Court's ruling that APIs are copyrightable, PW editor in chief David Berlind captured one of the more likely consequences to the now-burgeoning API economy should the courts ultimately rule that APIs are copyrightable. He broached the question that if one pattern or best practice, like that of each of the 37 Java APIs in question, are subjected to copyrighting, then are all API patterns subjected to that same copyrighting? He pointed out that the API industry is working toward repeatable best practices, so the technology behind one API could then be used to create the next ones. Should this happen, Berlind contends that “If one pattern can be copyrighted and the copyright holder chooses to protect that pattern, well then, if we can’t repeat that pattern, if we can’t repeat our best practices, then what ends up happening is we design APIs to work around a copyright and we end up in a place of friction that inhibits the growth of the industry and inhibits developer’s frictionless access to APIs.”

To the extent that Oracle’s lawsuit against Google could set a precedent for API copyrightability, the potential of APIs as well as the fate of the API economy now lies in the hands of the U.S. Supreme Court who will decide this week whether to hear Oracle America, Inc. v. Google, Inc., or remand it back to a lower court.

Oracle v. Google: An Overview

It all started when Java was just a mere teenager back in November 2007 when Google released the beta version of its Android mobile platform, which included the use of application programming interfaces or APIs built with the standard edition Java Platform (J2SE).

Then in January 2010, Oracle Corporation acquired Sun Microsystems for more than $7 billion. The renamed Oracle America, Inc. officially became the owner of the Java programming language and its licensing.

In August 2010, Oracle first sued Google for copyright and patent infringement. The U.S. District Court for the Northern District of California split the case into three parts:

1. copyright
2. patent
3. damage

The crux of the case was (and still is) copyright, infringement, and fair use. Despite the fact that Sun open-sourced J2SE (among other Java assets) in 2006, Oracle alleged infringement of 37 Java APIs and API documentation. This first trial began in April 2012. The jury found that yes, the Java API had been infringed, but could not determine if Google had a reasonable claim that it was fair use.

Fair use is legally defined by these four factors:

1. purpose and character of the use
2. nature of the copyrighted work
3. amount and substantiality of what is used
4. effect on the potential market

Next, in May 2012, the same jury reviewed the patent portion of the dispute, which covered two parts:

• Patent #US6061520: “An improvement over conventional systems for initializing static arrays by reducing the amount of code executed by the virtual machine to statically initialize an array.” Google countered that they had been parsing to optimize static initialization, not simulating that execution, as Oracle contended.
• Patent #USRE38104: This covers the method and apparatus for resolving data references in code. Google countered that the code they used didn’t include the “symbolic reference” that is the basis of the patent.

The jury found that Google had copied nine sections of code called rangeCheck, but neither the documentation nor the literal code was infringed. In general, the U.S. District Court judge ruled that the Java APIs weren’t protected by copyright in this particular circumstance. This ruling was really narrow, meaning that it should only count for this particular case and the 37 Java APIs discussed, not to set policy or influence other rulings.

The U.S. District Court acknowledged that the overall structure of Oracle’s API packages is creative, original, and resembling a taxonomy, which could allow it to qualify for copyrightability. However, the court found that the Java API“is nevertheless a command structure, a system or method of operation — a long hierarchy of over six thousand commands to carry out pre-assigned functions,” deciding it was not entitled to copyright protection under Section 102(b) of the Copyright Act.

So Google was responsible for a small portion, but “Still, it will be seen as a victory by many in the software industry, who feared that a ruling in favor of Oracle would stifle innovation in the software industry,” wroteNetwork World in its assessment of this result.

But, it didn’t stop there. Oracle agreed to accept zero statutory damages — which would have been around a few hundred thousand dollars — because it was going to appeal the decision, as it was seeking up to $6.1 billion.

Oracle then appealed the majority of the U.S. District Court’s judgment, while Google cross-appealed regarding the rangeCheck code and eight decompiled files.

On May 9, 2014, three judges from the U.S. Federal Court of Appeals released their 69-page decision after hearing both sides:
“Because we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection, we reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement finding as to the 37 Java packages. Because the jury deadlocked on fair use, we remand for further consideration of Google’s fair use defense in light of this decision. With respect to Google’s cross-appeal, we affirm the district court’s decisions: (1) granting Oracle’s motion for JMOL [Judgment as a Matter Of Law] as to the eight decompiled Java files that Google copied into Android; and (2) denying Google’s motion for JMOL with respect to the rangeCheck function. Accordingly, we affirm-in-part, reverse-in-part, and remand for further proceedings. “

To summarize, the Federal Appeals Court:

• Reversed the main decision, deciding that the 37 Java APIs could indeed be copyrighted and were infringed.
• Sent the “fair use” portion of the case back to a lower court for them to make a decision this time.
• Affirmed that Google was at fault regarding those nine pieces of rangeCheck code.

Not surprisingly, in October 2014, Google filed a petition to the U.S. Supreme Court on this basis:
“Congress specified that ‘original works of authorship’ are generally eligible for copyright protection, 17 U.S.C. § 102(a), but ‘[i]n no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work’.”

As the U.S. Supreme Court is winding down its season, offering its last opinions, and setting the docket for the 2015-2016 season, it should reveal by the end of June 2015 if it will take this case. If it does not, the Federal Appeals Court ruling on the Java APIs will stand; however the fair use case will still head back down to the lower courts for a clearer decision.

If the Supreme Court does take this case, about a year from now, they will be releasing a decision that will affect the future of the software industry.

Leading up to Google v. Oracle

If chosen, Google v. Oracle will come down to the battle of software copyrightability versus fair competition and interoperability in the software space. Was Google infringing on Oracle’s copyrighted Java? Or was it acting in fair use for the sake of interoperability? And does this matter if Java was originally intended to be open source anyway? We first need to look back at similar cases to consider this one through the appropriate lens.

In 1992, “fair use” in terms of software was decided at the Federal Circuit Court level.

Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. found that Galoob’s creation and selling of the Game Genie was not violating Nintendo’s video game copyrights, as Game Genie simply enabled users to alter parts of the games temporarily in a way that was clearly for non-commercial, private use.

InSega Enterprises, Ltd. v. Accolade, Inc., the court found that reverse engineering is “fair use” under copyright law when it’s the only way to get to the ideas and functional elements of the code, which Accolade had used to build its Sega games. The Sega case ruled this way because “the owner of the copyright gains a de facto monopoly over the functional aspects of his work — aspects that were expressly denied copyright protection by Congress.”

Probably the most significant Supreme Court ruling so far in the software space was 1995’sLotus Development Corporation v. Borland International, Inc., where one spreadsheet program was suing another for copying its macros. The central question surrounding this case is whether a computer program menu command hierarchy is a method of operation and not constitutionally protected under copyright law. The high court, with a ruling of four to four (one justice recused himself), agreed with the Appeals Court ruling that method of operation wasn’t copyrightable.

Perhaps the most interesting quote that arose from this was given by then Chief Justice Michael Boudin in his concurring opinion:

“Applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.”

Of course, there’s no doubt that this is a much more complex case about much more complex code, leaving a lot of expectation that the Supreme Court will take up this case, if they feel they can make an overarching policy rule on it.

Further adding to the likelihood that this case will go to the highest court, in January 2015, the U.S. Supreme Court asked the Solicitor General to create a report on it. While the Supreme Court only agrees to hear about five percent of the cases it considers, according to a 2009 statistical analysis, the Supreme Court is 46 times more likely to hear this case because it is both between two for-profit entities and the Court asked for the Solicitor General’s own amicus brief.

However, on May 26, 2015, theUnited States submitted that amicus brief, which recommends that the Supreme Court does not accept this case because it believes the copyright debate is clear, while the idea of interoperability should be discussed under the topic of “free use,” which is already remanded to be discussed back at the lower court level:
“Despite the inherently functional character of all computer code, the Copyright Act makes clear that such code can be copyrightable. Nothing about the declaring code at issue here materially distinguishes it from other computer code, and petitioner has identified no genuine conflict of authority concerning Section 102(b)’s applicability to circumstances like these. Although petitioner has raised important concerns about the effects that enforcing respondent’s copyright could have on software development, those concerns are better addressed through petitioner’s fair-use defense, which will be considered on remand.”

According to the official blog, the Supreme Court will consider hearing Google Inc. v. Oracle America as part of the June 25, 2015 conferences.

Copyrightability v. Interoperability

Since the Supreme Court’s consideration of Google v. Oracle could dramatically change the way software is produced and interacted with, other big players in the space are joining in the argument, mostly in favor of Google’s case being chosen.

In November 2014, parties including Hewlett-Packard, Yahoo, The Open Source Initiative, and the Computer & Communications Industry Association (CCIA) filed six amicus curiae briefs in official support of the Supreme Court considering the case.

CCIA kicked off its amicus brief with: “Effective intellectual property protection gives developers incentive to create new applications. At the same time, improper extension of copyright law to functional elements will impede innovation and inhibit competition in the computer industry.”

Much of the software industry is in support of the high court considering to overturn the verdict against Google, not necessarily because it believes there shouldn’t be copyrighting in the space, but that there shouldn’t be copyrighting when it can negatively affect the interoperability between products and services.

Oracle has repeatedly argued that it’s covered under the U.S. copyright law as it compares each Java API to “a novel,” which is explicitly protected.

While being careful to admit that writing code takes a similar level of creativity as writing a novel, Oracle’s opposition in return argues that a novel is self-contained, while software can only perform in conjunction with other software and hardware.

The amicus brief expresses what the CCIA believes are the ramifications of the appellate ruling standing:
“If a company could exercise proprietary control over the interface specifications implemented by its products, that company could determine which products made by other firms — if any — could interoperate with its software. And should that company have a dominant position in a particular market, it could use its control over interoperability to expand its dominant position into adjacent markets. Moreover, such authority would extend the rights under copyright beyond what is necessary to protect the original expressive elements that have traditionally been offered protection under American copyright law, and it would override limitations on copyright crafted to protect the public good.”

The CCIA’s amicus brief goes on to talk about how too-broad intellectual property protection in the software industry will hinder innovation and competition, and how the market as a whole will suffer due to its inherent limitations on interoperability.

The other five amicus briefs offer similar arguments.

Oracle gave its own respondent amicus brief, again comparing coding to the writing of literary works and rather skirting the interoperability argument, citing that:
“Google copied at least 7000 lines of original computer source code that Oracle wrote, and included the copied code in its own software platform, even though Google could have written its own code, rather than copying Oracle’s, to perform the same functions.”

Oracle isn’t arguing that its code is inherently unique, but rather that Google saved time and money getting to market faster by using Oracle’s Java APIs instead of taking the time to write its own code, and did not do so under the proper Java licensing agreements.

If the Supreme Court accepts Google v. Oracle, it may also rule on the fair use discussion that is otherwise destined to go back to a lower court. Oracle’s case sits upon the argument that the first and fourth fair-use factors that were mentioned before have not been met. It argues that the purpose and character of Google’s use of the Java APIs is clearly commercial and that it negatively affected the potential market by creating an unlawful market domination that hurt companies that had Java licenses, while Google’s Android was built without meeting Java licensing standards, namely its requirement for compatibility.

Opponents to Oracle’s argument argue that, clearly, although Google’s use of Java was commercial, it had a positive and transformative effect on the marketplace overall. Also, since Java was originally intended to be open source, these opponents say that the compatibility factor shouldn’t be in play because compatibility negates the idea of open source.

The Software Freedom Law Center and Free Software Foundation turned in the only amicus curiae brief against the Supreme Court considering this case, on the same day Oracle delivered their response in December 2014. This amicus brief does not side with Oracle, but rather with the Appeals Court’s decision to overturn what the two parties believe was a poorly constructed decision at the District Court level:
“Judge Alsop made his decision on the basis of an educated understanding of the principles of computer programming not equally apparent in the opinion of the Federal Circuit below. The District Court’s decision was not only correct, but narrowly factbound, unsuitable as a vehicle for the clarification of broad principles by this Court that would justify a grant of certiorari.”

In short, they strongly avoid agreeing with the prevailing decision, but think that the decision is so narrow that it doesn’t warrant the Supreme Court potentially basing an overarching decision on it.

So, if APIs are copyrightable, how can we protect ourselves?

After the Appeals Court ruling, software powerhouse Cisco Systems, Inc. already brought two lawsuits against Arista Networks, Inc. over Ethernet switch manufacturing and selling, claiming patent infringement in one and accusing Arista of copying proprietary computer commands and instruction manual language in the other.

This is just one example of how the Appeals Court decision has already affected the marketplace. There’s no doubt that, at least for the next year and — depending on whether the Supreme Court makes a decision and what that decision will be — quite possibly for the foreseeable future, the application programming interface is copyrightable.

So what should the software community be aware of? Should we worry that 95-year copyrights will stifle innovation and lead to tech monopolies? Or should every API engineer be rushing to copyright his or her work to protect against the next lawsuit?

About a year ago, right after the Appeals Court ruling protecting Oracle’s copyrighted Java APIs, ProgrammableWeb brought together a panel at APIcon San Francisco to talk about whether APIs can be copyrighted and, if so, what legal actions should the software community be taking to make sure it is protected. Moderated by PW editor in chief David Berlind, the panelists were Annette Hurst, partner at Orrick, Herrington, and Sutcliffe LLP, the law firm representing Oracle in the appellate courts; Larry Rosen from Rosenlaw and Einschlag, who was a lawyer for the Open Source Initiative; Pamela Samuelson, distinguished professor of law at U.C. Berkeley who led one of the amicus briefs in favor of Google’s position; and Mike Linksvayer, a Creative Commons senior fellow.

Linksvayer suggested that engineers and developers should use an open-source license instead of a Creative Commons license. “The Apache license is the most obvious one. It’s a permissive license; it doesn’t pose any conditions other than copyright code and a patent grant. And that patent grant is actually quite important because copyright is not the only threat around implementing APIs.”

Should every owner of an API now protect him or herself by copyrighting it? Hurst argued that, while it’s a hot topic now, most everyone already is copyrighting his or her APIs. She said she went through many of the APIcon attendees and saw that “Every single one of them has a terms of use on their websites describing both their sites and their APIs as copyrightable subject matter in which they claimed an interest.”

Hurst continued, “There’s not this cultural phenomenon of no copyright here, quite the opposite if you are looking at how people are actually behaving.”

However, Rosen warned that “Legally, putting a copyright notice on something doesn’t prove much. It certainly isn’t the end all for a copyright case.”

An audience member asked if the cleanroom development practice of recoding to implement an API at a reliable standard was negated by this ruling. Samuelson says she thinks no and that the cleanroom practice should continue as before. “I think that the likelihood is that anyone who tries to extract interface information and then reimplement it is less likely to run the risk of being viewed as an infringer, and there are certainly cases where people have done cleanrooms that are still valid precedents for reimplementation so I think that’s still something to say is a good thing to do,” She continued that she thinks “it’s quite likely that even if this appellate court decision stands that courts will distinguish the kind of cleanroom situation from the Oracle v. Google case.”

This is all based on the assumption that “APIs are not all one thing” and, no matter what the final ruling will be, it’s liable to be interpreted in different ways.

“It’s a very broad category so I think it’s a mistake that even if you think the Court of Appeals was right in this instance, it doesn’t mean that all APIs automatically are protected by copyright law,” Samuelson said. “The distinction between the specification and implementation is one that’s going to continue to be important so that even [if] a specification document may be copyright-protectable, reimplementing the specification in code is still going to either be a fair use or something that simply doesn’t infringe the copyright.”

If the Supreme Court moves ahead with the case, since there is little in the way of precedents for this kind of fair use, there is very little that can be done to predict who will win. As we wait, please tell us below what kind of copyright you have on your APIs and how you think this ruling may or may not affect your life and your work.