Supreme Court Delivers Major Blow To API Economy In Copyright Ruling

scotus-building

The Supreme Court has officially declined to hear Google's appeal in the case of Oracle vs. Google.

In a decision that could potentially stifle innovation, give birth to a new breed of copyright trolls, and undo decades of industry precedent, the Supreme Court has officially declined to hear Google's appeal in the case of Oracle vs. Google; otherwise known as "the API (application programming interface) copyright case."

On the heels of some serious last-minute docket cleaning including its momentous findings regarding Obamacare and gay marriage, the Supreme Court has officially weighed-in on Oracle vs. Google, essentially supporting the US Federal Court of Appeals' prior findings that APIs are indeed copyrightable and to remand the case back to the district court where a single glimmer of hope still remains for Google. That hope -- and the only question that remains now -- is whether Google's royalty-free use of the Java APIs in Android is allowable on the grounds of "fair-use."  

"Fair-use" is a murky area of copyright law that allows third parties (Google in this case) limited rights to make copies of copyrightable material or portions thereof. For example, in preparing its coverage for some breaking news story, one news organization might copy a quotation or two from another news organization's article. While copyright law prevents the former from legally publishing a complete copy of the original article as its own, it also prevents the latter from prevailing in an infringement lawsuit for copying just a little bit.

But just exactly what constitutes "a little bit" is subjective. There is no definitive fair-use formula; for example a fixed number of characters or a flat percentage (i.e.: 10 percent) of the original article's text. Perhaps emphasizing the challenges surrounding such subjectivity in this case, the district court may now look to determine the extent to which a given platform's APIs represent a percentage of the overall platform's body of work -- something for which no precedent exists. One big problem is that APIs are really just specifications. Unlike the copyrightable source code behind all software, APIs themselves are not code. They are merely a commonly understood agreement -- often described with API documentation -- for how one body of software talks to another.  

The District Court will also likely consider a range of other issues. For example, there's the extent to which Google experienced commercial gain as a result of copying the APIs. Then, there's the fact that Java was open-sourced by Sun prior to Oracle's acquisition of Sun and the question of whether or not the APIs in question are covered by that open source license. There's also the extent to which Google may have overstepped the open source license's legal boundaries.

For the US court system, it is completely uncharted territory which is why so much is at risk. For decades, the computer industry has operated under the premise that intellectual property laws (copyrights, patents, trademarks, etc.) do not apply to APIs. Technology innovation has long depended on the unencumbered ability for one or more pieces of software to talk to other pieces of software through APIs. Even more important for consumers, such API-enabled interoperability has lead to choice among "compatible" products which in turn has driven healthy competition and reasonable prices for technology products.  

But now that the Supreme Court has found in favor of the Appeals Court's finding that APIs are copyrightable, it may have created a new class of technology copyright holder that can not only stand in the way of such interoperation and competition, but like a patent troll can extract huge royalties out of potential infringements if not put certain companies out of business altogether. Potentially stifling innovation, startups that prior to this ruling might have depended on APIs may never startup due to the potential royalties connected with API use. Some API copyright holders may decide to keep their APIs to themselves and refuse to license them at all for use by third parties. 

ProgrammableWeb stands firmly against the idea of API copyrightability. For example, one of the most promising areas of growth for the API economy is on the API design front where dozens of great tools exist to automate the art of API design. These tools respond to the patterns they observe and incorporate commonly accepted best practices of API design. 

Given the same API design problem by two competitors in the same industry that must deal with industry-wide standard data formats (i.e.: the insurance industry), an API design product will likely arrive at the same or very similar designs. But the insurance company that's first to copyright that API can force the hand of the others, requiring them to pay royalties or, worse, sending them back to the drawing board to hand-design unique but sub-optimal APIs that short-cut commonly accepted best practices. In other words, the net result could be a crappy, poorly designed API that developers turn their backs on.

Now, we must wait to hear what the District Court has to say on the matter of fair use. On one extreme, the District Court could find in favor of Google, ruling very broadly that all APIs across all software are subject to fair use. A finding such as this could potentially prevent further API copyright infringement suits from being filed by API copyright trolls. Somewhere in the middle, the District Court could find in favor of Google, ruling very narrowly that only the APIs that Oracle sued Google over are subject to fair use. In other words, while the case would still serve as precedent for future API copyright infringement cases, those future cases can more easily swing in the direction of the copyright holder. On the other extreme, the District Court could find in favor of Oracle thereby setting a precedent for "API monopolies" whereby API copyright trolls have a field day. 

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.

Comments

Comments(4)

tanyagupta

Twitter post icon not working as it should

jlouvel

Thanks David for the detailled analysis of this decision of the Supreme Court.

I also found this previous legal analysis enlightening as well regarding the legal process that led to the previous decisions: http://www.natlawreview.com/article/oracle-v-google-interoperability-and...

In addition to the "fair use" considerations that have not been decided yet, there is still IMO the "interoperability" legal aspect that could be leveraged. There are several examples of Java libraries that were ported to Android thanks to the availability of the core Java API, such as the built-in Apache HTTP Client or the Restlet API that is available thanks to an automated port.

Other evidences of interest in porting Java code to Android are available online:

https://www.google.com/webhp?#q=port+java+code+to+android

Best regards,

Jerome

david_berlind

jlouvel: these are both great links. Thanks very much for sharing. The National Law Review's coverage of the case does a nice job of distilling the circuit court's decision and raises the likelihood that Google "interoperability" justification was hardly justified in as much that an interoperable app (one that runs unchanged on both regular Java and Android) doesn't exist.. nor can it in absence of critical pieces like Swing and AWT. The federal circuit also argued in favor of the expressiveness of the declaring code (expressiveness being key to copyrightability). 

Again, thanks for sharing.