Here’s the problem: Absolutely every component of computer code is intended to be interoperable with something — usually, another such component. And most everyone who has ever composed such code would retain the right to decide what should be done with it, including whether that code is freely given away.
Let’s say you build your business model around how your customers use your code. Supposedly, that’s what the industry of “open APIs” is all about — the “I” in “API” stands for “interface.” If some other company builds a competing business using your business model for the use of code, has that company violated your rights?
That’s the real issue at hand in the case of Oracle v. Google, easily the most important challenge to the legal definition of “fair use” with respect to code.
In what could be considered the first peal of the midnight chimes for this case, yesterday morning, US Solicitor General Donald Verrilli filed an amicus brief on behalf of the Justice Dept., urging the Supreme Court to deny Google’s petition for appeal.
That petition urges the high court to reconsider the finding last year by the Federal Circuit Court of Appeals, which reversed a jury’s decision and found that the APIs for Java, which Oracle now owns, are protected by copyright.
If the court sides with the Solicitor General next month, then Google may find itself owing back royalties for the use of code it copied from Sun Microsystems — more to the point, code that Sun willingly let Google copy.
In a statement to CMSWire, Deborah Hellinger, Head of Global Corporate Communications at Oracle, said the company is pleased the US Solicitor General has recommended that the Supreme Court deny Google's cert petition. "In 2014 the Court of Appeals for the Federal Circuit unanimously rejected Google's arguments that software is entitled to less copyright protection than other original, creative works. The Solicitor General's brief agrees with the Federal Circuit's decision and affirms the importance of copyright protection as an incentive for software innovation," she said.
More importantly for the industry as a whole, however, an Oracle win would establish a significant legal precedent for any U.S. company whose business transactions are conducted online using APIs. If the company did not develop those APIs itself, it could owe royalties or even per-fee transactions to the one that did.
The circumstances are just too unique: Android apps are actually a form of Java, which was developed by Sun Microsystems. A decade ago, Google wanted to build a smartphone operating system and needed a language interpreter. Rather than reinvent the wheel, it copied entire segments of Java itself, right down to the embedded comments.
It built Dalvik, the first runtime for the Android system (which has since been replaced). But it did so completely above-board, including public demonstrations of its work in progress Sun engineers attended that. At the time, they responded enthusiastically.
When Oracle acquired Sun in 2010, it obtained the rights to Java, as well as to the agreements Sun made regarding its fair use. But Sun and Google never entered into any agreements, leaving Oracle free to pursue Google for back royalties.
Last December, Google petitioned the high court [PDF, subscription required] to hear its appeal of the May 2014 Federal Circuit decision.
In that petition, attorneys for Google pointed to one of the software industry’s landmark decisions in Lotus v. Borland. There, the First Circuit Court of Appeals found that Lotus could not claim a copyright on the way one operated the menu commands in a spreadsheet.
Oracle’s attorneys had previously argued that the way programs interoperate with methods and the ways people operate with menus were separate issues. For that reason, it claimed, the inapplicability of copyright law to user interfaces should not extend to application program interfaces.
Google’s attorneys argued that both concepts are actually in the same category, “command structure.” From their petition:
This case... concerns the ‘command structure’ used to operate the Java and Android libraries of pre-written code. There is no meaningful difference between the two.
Lotus held that the command hierarchy used to control the program (by causing it to print, for example) was not copyrightable even though the court assumed arguendo [for the sake of argument] that computer code used to carry out those commands was copyrightable.
So too here, Java’s system of method headers is not copyrightable but the implementing code that instructs a computer how to perform the relevant functions is.
In his amicus brief, the Solicitor General concedes some doubt as to the clarity of the Lotus decision. The part of that decision that resounds clearly enough, he argues, is that original computer code is eligible for copyright.
But then Verrilli takes somewhat of a risk in arguing that the nature of the code in dispute — particularly, a set of Java methods to help programmers write interoperable code (otherwise known as an API) — is too flimsy around which to base a landmark decision.
The questions about every little detail about the specific code that Google copied, he warned, “may have little significance in more common disputes.”
If Google’s appeal does end up being heard by the Supreme Court, it will be because Verrilli’s notion that the code itself was insignificant raises the ire of certain justices who would much rather make that determination themselves — for example, Justice Scalia, who issued a masterful dissent in last June’s Aereo decision.
Verrilli’s argument aside, the Supreme Court’s option in this case will be pivotal, not only for the software industry but for information technology as a whole.
There has been an earnest effort in the law to underscore the principle that the idea behind any expression of creativity deserves protection. When we try to apply that principle to computing, “idea,” “creativity” and “protection” suddenly bear telltale asterisks.
Jurists do see merit in the idea (no asterisk here) that the way one goes about a task can be considered intellectual property, but the notion of the task itself is not.
Therefore, if someone creates a program or a service that performs a novel business function, the program may be copyrighted. The function may be patentable if it is not common, never been done before and entirely new.
But if it’s something that should be common enough, like using a spreadsheet (and Lotus 1-2-3 was not the first one), then the way one operates its menu should not be subject to copyright. Phrased like that, it seems fair enough. But then we’d need to throw out nearly every claim Apple and Samsung have filed against one another.
If someone declares his computer code “free,” is that declaration binding? Sun acted like Java was free by not stopping Google from copying it.
Assuming an API is a “business method,” then you could apply this same set of circumstances to a different business situation: If you create a new market and someone else enters that market by offering the same category of product or service in essentially the same way, then theoretically that benefits you by making the market relevant.
Unless, of course, you let your competitor leverage your own assets in the process.
In a discussion on this subject several months back, I heard a legal scholar break down the essentials of this case in a somewhat different way: It’s the difference, he said, between opening your own door for your business and letting your competitor use its own workmen to detach your door from your building, apply it to their building and open your door for their business.
Title image by Freshita Maluven