Unfair Use? Why Google's Ongoing Battle With Oracle Matters To Your Business

It's worth it to carefully review all underlying licenses to APIs before engaging in any development for commercial use.

Software developers please take heed: the ongoing feud between Google and Oracle over Google’s use of Java shortcuts just got a whole lot more interesting, and potentially a whole lot more expensive. There’s no way around it — virtually every business today uses some form of software in providing its goods and services to its customers. Whether custom-developed mobile applications or software-as-a-service solutions, computer software is no longer a supporting element but an indispensable business need. In fact, this need is becoming more prevalent with the expansion of mobile device platforms.  Without question, software impacts your business and its bottom line… which is why Oracle’s ongoing battle with Google over Google’s use of Java application programming interfaces (“APIs”) just may do so as well.

First, a little background may help to provide context.  Seeing (quite correctly) the potential merger of digital consumer devices and computers, Sun Microsystems developed the Java programming languagea computer programming language designed to let application developers compile code that they could “write once, run anywhere” (allowing the compiled code to run on all Java-supported platforms without having to compile the code separately for each separate platform). Java has become one of the most popular programming languages, helping power the Internet as well as mobile phones, watches, navigations systems and e-business solutions, due in no small part to Sun Microsystems licensing most (but not all) of Java as open source software under the GNU General Public License.   You read correctly — to encourage widespread adoption, Sun Microsystems provided Java source code for free.

As part of Google’s ongoing mobile platform development after Google purchased Android, Inc. in 2005, Google wanted to ensure that Java programs would work within its Android operating system environment.  Although most of Java was open source, not all of it was publicly available, so Google tried to license the remaining Java components from Sun Microsystems, but the parties simply could not come to terms.  As a result, Google did the next best thing — write its own version of Java, but apparently copying the same names, organization, and functions as the Java APIs ostensibly to save development time.  Unfortunately for Google, Oracle Corporation purchased Sun Microsystems (and its Java assets) a few years later, and Oracle proved even less inclined to come to license terms with Google for the remaining Java components.  So, Google pressed forward with its own version of those components, and less than eight months after acquiring Sun Microsystems, Oracle pressed forward in suing Google for copyright infringement.

The first trial resulted in a holding that Goggle copied portions of Oracle’s Java code, but that the portions were APIs that were not protectable under copyright law. On appeal, the Federal Circuit Court of Appeals reversed in 2014, holding that the API “structure, sequence, and organization” was protectable expression under copyright law, and remanded back to the trial court to determine if Google’s use of the APIs was a “fair use” under copyright law. The jury in that second trial did just that, finding in favor of Google and its “fair use” of the APIs.  So, the Federal Circuit ruled that APIs were protectable under copyright law, and on remand the second jury found fair use.  Settled, right?  Wrong.  The Federal Circuit has now overturned that verdict, holding that Google’s use did not constitute fair use. Ugh.

Forgive my frustration, but my own issues with the Federal Circuit’s position stem from my own misgivings about the 2014 ruling.  By their very nature, APIs are designed to be used by others. In fact, APIs are freely provided by most platform developers to encourage interoperability between disparate software platforms — that’s arguably the whole point of having them in the first place.  In fact, many programmers argue that APIs are more like specifications for interoperation than underlying code that facilitates it anyway. That said, even Oracle admits that its own APIs are freely available to developers (albeit not for use on competing platforms).  Even though the Federal Circuit’s 2014 holding that APIs are copyrightable remains controlling law, overriding a jury finding on fair use is not to be taken lightly.  In that vein, the Federal Circuit stressed that Google’s distribution of its Java code for free did not mean such use was non-commercial, and appeared troubled by the fact that Google copied elements of the APIs verbatim. Now, it seems more likely than not that this ruling will be appealed to the Supreme Court, but whether the highest court in the land will grant certiorari to hear the case is questionable.  In the interim, a bitter battle over damages will continue to be fought between the parties (Oracle only wants $8.8 billion dollars).

From my perspective, the Federal Circuit decision should give pause to every company that codes to APIs to facilitate interoperability with third-party platforms.  As if APIs being copyrightable isn’t problematic enough, now fair use of such freely-available APIs has been drawn into question.  Unless you are a mind reader, there is also no way to reliably predict fair use in the software development context outside the enumerated fair use exceptions under 17 U.S.C. Section 107.  This is because fair use is determined by a federal court after the application of a four factor test that is really more guideline than rule.  As a result, fair use cannot be predicted with any reasonable certainty in a particular case.

As it stands, companies can no longer take liberties in assuming that freely-available software APIs are free.  Based upon my experience with software development teams, industry accepted practices have taken such liberties and simply may no longer suffice.  As a result, I would strongly urge a careful review of all underlying licenses to APIs before engaging in any development for commercial use.  If you don’t, top line revenues risk being impacted by unforeseen infringement damages, and your company’s (or client’s) bottom line will be all the worse for it.

Sponsored


Tom Kulik is an Intellectual Property & Information Technology Partner at the Dallas-based law firm of Scheef & Stone, LLP. In private practice for over 20 years, Tom is a sought-after technology lawyer who uses his industry experience as a former computer systems engineer to creatively counsel and help his clients navigate the complexities of law and technology in their business. News outlets reach out to Tom for his insight, and he has been quoted by national media organizations. Get in touch with Tom on Twitter (@LegalIntangibls) or Facebook (www.facebook.com/technologylawyer), or contact him directly at tom.kulik@solidcounsel.com.

Sponsored