There’s no way around it – virtually every business today uses some form of software in providing its goods and services to its customers. From software-as-a-service solutions to custom-developed code, software has become an indispensable business need, especially as customer solutions expand to the mobile application space. Without question, software impacts your business and its bottom line…which is why ignoring Oracle’s ongoing battle with Google over Google’s use of Java application programming interfaces (“APIs”) is a risk your business cannot take.
Before delving into why, a little background will be helpful. Seeing (quite correctly) the potential merger of digital consumer devices and computers, Sun Microsystems developed the Java programming language – a 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). This is accomplished in part by writing to the Java Virtual Machine – an abstract computer machine that basically enables a computer to run a Java program. Java has now become one of the most popular programming languages, helping power the Internet as well as mobile phones, watches, navigations systems and e-business solutions. In an effort to encourage widespread use of Java, Sun Microsystems licensed the bulk – but not all — of Java as open source code through the GNU General Public License in 2006…for free. As part of its purchase of Android, Inc. in 2005 and ongoing Android mobile platform development (no doubt spurred on by Apple’s iPhone release in 2007), Google wanted Java programs to work with Android…so Google needed to be sure that such Java programs would work the same on its Android operating system. Unfortunately, Google was unable to come to licensing terms with Sun for the remaining components…so it decided to essentially write its own version of Java, but apparently copying the same names, organization and functions as the Java APIs ostensibly to save development time. A few years later, Oracle Corporation acquired Sun Microsystems — including its Java patent and copyright assets. To no one’s surprise, Oracle and Google could not come to terms on a license…so Oracle sued Google in 2010 for patent and 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 court reversed, 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. Just the other week, a jury in the second trial found “fair use” in favor of Google, saving Google from potentially billions of dollars in copyright infringement damages…and prompting a collective sigh of relief from the software development community that worried about its own liability for development to the Android platform. Interestingly, Google decided to move away from the standard Java APIs and embrace the open source-licensed OpenJDK in late 2015…thereby opting to avoid any future issues with the Java APIs in the process.
In light of this latest turn of events, many questions remain regarding the use of API’s and fair use under copyright in software development. In fact, some argue that the decision is blight on copyright law and bad for software development. What should your company do to protect itself regarding software development involving APIs? Here are 3 points to help you navigate these developments:
1. Look to the Licenses. Notwithstanding the long and convoluted litigation in the present case, let’s not lose sight of the fact that APIs are designed to facilitate inter-operation between software platforms…and in most cases, are subject to reasonable limited licenses from the original developer or otherwise subject to open source licensing constructs (such as the GNU General Public License, or more business-friendly Berkeley Software Distribution licenses, such as the BSD-2 Clause License and BSD-3 Clause License). Unlike the fairly unique situation presented by the Google/Oracle litigation, most development under the current copyright framework (i.e. APIs are copyrightable, but may be subject to fair use) will likely fall within a specific license construct under which your company can operate without fear of infringement. That said, do not take the existence of a license covering the APIs for granted – you need to review the terms of the license with qualified counsel to ensure your intended development will (i) meet the needs of your platform without sacrificing functionality due to limitations in the specifications for the APIs, (ii) properly fit within the license parameters, and (iii) not give away rights you did not intend to contribute to the development community (for open source licenses).
2. Fair Use Does NOT Mean Your Use is Fair. Although the jury found Google’s use of the Java APIs to be fair use, this finding is far from comprehensive. The fair use analysis under copyright law involves 4 separate considerations that are to be weighed by the judge – factors that are really guidelines that the judge has a great deal of latitude in applying on a case-by-case basis. Unless you are a mind reader, there is 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. As a result, fair use cannot be predicted with any reasonable certainty in a particular case. Bottom line: Your company simply cannot rely upon fair use when developing to APIs, and you will need to properly instruct your internal development team to be diligent. Where third-party contractors are used, your team must identify the programming elements and negotiate appropriate risk allocation with third-party contractors performing the development, memorializing this understanding in the appropriate software development agreement to protect against undue risk.
3. Beware the Changing Landscape. Google may have won this battle, but the war is far from over – Oracle has already indicated its intent to appeal. If the past is any indicator, this appeal will be hotly contested. Don’t get caught in the crossfire – engage qualified technology counsel to help you stay abreast of developments and ahead of any potential changes to the underlying legal landscape. If you don’t, the calls being made will not be to APIs…and may be a lot more expensive to resolve.
Tom Kulik is a sought-after technology lawyer who uses his award-winning industry experience to creatively help his clients navigate the complexities of law and technology in their business. He is an intellectual property & technology partner at Scheef & Stone, L.L.P., a full-service commercial law firm based in Texas representing businesses of all sizes throughout the United States and, through its Mackrell International network, around the world.