​Billions at stake as Oracle beats Google in latest Android Java API legal dustup

The jury ruled that Google didn't owe Oracle any money for its use of Java's APIs in Android, but the US Court of Appeals for the Federal Circuit disagreed and overruled the jury. Software development as a whole and billions of dollars are now at stake.

Like it or not -- and most developers hate it -- the US Federal Circuit Court of Appeals ruled in 2014 that APIs could be copyrighted. Because of that decision, the legal battle between Google and Oracle over whether Google had the right to use Java APIs in Android without compensation has dragged on for years. In the last go-around, Google won again because a jury found that Google's use of Java APIs was allowed because it constituted "fair use". Done? Over? Not so fast. Now the US Court of Appeals for the Federal Circuit ruled Google's Java API work wasn't fair use.

Juries? Who needs them?

According to the Court, Google fair use was applicable because, "We find, therefore, that, to the extent we must assume the jury found Google's use of the API packages to be anything other than overwhelmingly commercial, that conclusion finds no substantial evidentiary support in the record." Further, "The fact that Android is free of charge does not make Google's use of the Java API packages noncommercial."

Pardon? Aren't open APIs, by their very nature, designed to be used by others?

Even Oracle admits its APIs are freely available for developers. Its objection is to how Google specifically used them. Or, as some have suggested, what Oracle really objects to is Google found a way to make money from Java, which Oracle has never managed to do.

Be that as it may, the court decided that because Google made money from its advertising on Android phones, it can't use the Java APIs under fair use.

Some of you may be saying, "But, APIs can't be copyrighted!" Like it or not, as was mentioned earlier, "the law of the case" is that the APIs are copyrightable. Given the "law of the case," the courts assumed the APIs were copyrighted.

There are many arguments on why APIs shouldn't be subject to copyright. As US District Court of Northern California judge William Alsup, a programmer in his own right, wrote in his original decision on Oracle v. Google, an API is merely "a long hierarchy of ... commands to carry out pre-assigned functions. For that reason, it cannot receive copyright protection -- patent protection perhaps -- but not copyright protection."

Most programmers would agree with the Electronic Frontier Foundation (EFF) in an earlier go-around of this case that this decision showed a complete "misunderstanding of both computer science and copyright law. APIs are, generally speaking, specifications that allow programs to communicate with each other, and are different than the code that implements a program. Treating APIs as copyrightable would have a profound negative impact on interoperability, and, therefore, innovation."

Be that as it may, that was not the issue at hand in this decision. Instead, the question was whether Google's use of Oracle code was fair use. The Court reversed the jury decision and remanded it for trial on damages. Their "mode" of reversal was based on several issues. These included the method for reviewing the "mixed question of fact and law" that is the fair use defense and whether an appellate court can better weight these factors.

Why did the court make this decision? Andrew "Andy" Updegrove, founding partner of the intellectual property (IP) law Gesmer Updegrove, speculated: "The question is therefore whether, as Google sought to assert, anyone should be able to recycle the lines of code in a commercial product under the 'fair use' doctrine. That's the same vague doctrine that takes into account four factors:"

1. The purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; [clearly, the use here is commercial]

2. The nature of the copyrighted work; [this is the interesting point]

3. The amount and substantiality of the portion used in relation to the copyrighted work as a whole; [small, but important]

4. The effect of the use upon the potential market for or value of the copyrighted work [Android wouldn't work without the code -- it, or something like it, is a "must have," not a "nice to have"]

Updegrove continued, "The exact parameters of fair use are subjective rather than objective, and constantly evolving. They also vary significantly depending on the type of work in question, and how it's used. The most interesting factor here is the second part of the test, and the question is whether an open API is different than, say, a systems call. APIs by definition have a reuse intention, as compared to a song lyric, which, as far as the writer is concerned, should never be copied, or a moral right in a painting that in some jurisdictions gives an artist an element of control after the work has been sold.

"The big question here," Updegrove continued, "is therefore how the fair use doctrine should evolve in this particular setting. In this case, for better or worse, the court decided that a narrow view rather than an expansive one was appropriate. One would expect that Google will appeal. It's harder to predict whether that appeal will be accepted."

The case has been remanded to a federal court in California. Oracle wants at least $8.8 billion.

We can safely expect Google will, once more, be appealing. This isn't just about the money. Given how damaging it would be to software development if APIs were to both be covered by copyright and unavailable for commercial use under fair use, I expect Google to file a cert petition, an appeal directly to the Supreme Court.

With luck, the Supreme Court will rule, once and for all, that APIs are not subject to copyright. Or, at the least, that using an API is indeed fair use. After all, APIs are meant to be used by their very nature.

Related Stories:

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All