And we thought Java API’s were open?

Oracle vs. Google is truly one of the most amazing IP battles that I have personally observed in the recent past. What millions of developers and customers would have literally thought to have been considered open Application Programming Interfaces (APIs) when it comes to JAVA, is potentially turning out to be proprietary from the perspective of the Federal Circuit. This is really an example of a fantastic unsettling discussion that Copyright Infringement always leads one to. The present post would be kept relatively brief given that the magnitude of the case, and potential implications it can have on thousands of software companies and independent developers using Java packets, API’s, classes, and methods, as a platform to develop their software/websites, is unimaginable and cannot be assessed at this stage if Oracle wins the present appeal/case and starts suing entities of all sizes on API/Package infringement. The present article however would not focus on the fair use discussion that Google contends as an argument, and also would not detail about the GPL, Specification License, and Commercial License that is available to developers but rather would try to give the impact that API’s per se, if held copyrightable, can have on people at large.

The aforementioned case started four years back when Oracle bought Java from Sun and focused on Google’s use of Java API’s in Android, wherein Google was claimed to have copied certain elements—names, declaration, and header lines—of the Java APIs in Android in the process of using Java programming language to design its own virtual machine, the Dalvik virtual machine (VM), for writing its own implementation for the functions in the Java API, and ended up writing 37 packages that were similar to the corresponding Java packets. In 2012, the district court largely sided with Google, saying that the code in question could not be copyrighted. It was held back then that “As to the 37 packages, the Java and Android libraries are organized in the same basic way but all of the chapters in Android have been written with implementations different from Java but solving the same problems and providing the same functions.” Therefore, in view of each API that can, in general, include a plurality of packages, each of which can, in turn, include a plurality of classes in which exist one or more methods, it was held that “Ninety-seven percent of the source code (of Google’s Android) in the API packages is different; it’s only the three percent that overlaps that formed the heart of Oracle’s copyright claim. That three percent included packages, methods, and class names. But those declarations—like starting a function with package java.lang—can only be used in certain ways. “In order to declare a particular functionality, the language demands that the method declaration take a particular form”.

However, last month (in May 2014), came a reversal from the federal appeals court, which stated that “Because we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection, we reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement finding as to the 37 Java packages,“. The decision comes as a surprise as Java API’s are extensively used/incorporated in numerous online and offline software all over the world, and if access to Java API’s is held copyrightable, sustainable action can potentially be taken against practically any entity/developer that incorporates calls to such API without a prior license from Oracle. It was on similar lines that Google and digital rights groups argued that APIs should not be copyrightable because developers need them to produce interoperable programs. “An API is dictated primarily by functional requirements, not creativity or aesthetics, even more so than the internal implementation of a piece of software. Copyright protects creative expression, not functionality,” Mitch Stoltz, an Electronic Frontier Foundation attorney said in an e-mail. “Also, the purpose of an API is to enable two pieces of software to interact. While copyright may protect software against copying, it shouldn’t prevent building new software that can interact with existing programs. That impedes creativity rather than strengthening it.”¹

In addition, it was also contended by Former Sun CEO Jonathan Schwartz, acting as a witness for the defense, that “These (Java API’s) are open APIs, and we wanted to bring in more people…we wanted to build the biggest tent and invite as many people as possible.” It was for this reason that, according to Schwartz, they had given a go-ahead to Google to use the Java API’s till the time they don’t use their brand name “Java”, and had stated that “I’d also like Sun to be the first platform software company to commit to a complete developer environment around the platform, as we throw Sun’s NetBeans developer platform for mobile devices behind the effort. We’ve obviously done a ton of work to support developers on all Java-based platforms, and we’re pleased to add Google’s Android to the list.”.

Few exemplary Java APIs, which form the basis of software being built relying on Java can be seen here, wherein these APIs typically form the foundation on which the actual new source/software code is written to get the desired functionality. Therefore, the statements “It’s only the code itself—not the “how-to” instructions represented by APIs—that can be the subject of a copyright claim”, and “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API,” written by the judge of the lower court prior to recent reversal gave a sense of relief to the developers globally, and in case the API’s per se are restricted to use unless, through a valid executed license, each access or incorporation of the API would be a violation from the Copyright infringement standpoint.

In sum, the recent reversal by the appeals court stating that “We find that the district court failed to distinguish between the threshold question of what is copyrightable — which presents a low bar — and the scope of conduct that constitutes infringing activity. The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis. For the reasons that follow, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection.”, brings along with it a sense to otherwise publicly available API’s and how they would be interpreted in case their developers now start claiming infringement by applications that use such interface to connect their software with the other components.

Although the matter is sure to be taken to the highest level of legal remedy available by Google to come to a logical conclusion, assuming the reversal is upheld, the precedent set by the instant case is bound to send a strong message down to every developer who has ever taken advantage of Java or any other coding platform software interface APIs.At the same time, even if it is clear and accepted that Java programming language is open is free for anyone to use, it is the very use of these Java Packages (API’s) that enables significantly shorter software development time and reduction on overall software cost, and therefore, at this stage, its even unimaginable as to the impact that non-allowance of use of most commonly used API’s such as for string manipulation, java.lang, java.text, object creation, Java SDK, HTML manipulation, among other heavily used APIs can have on software coding time, manpower cost, an incremental cost that customers are going to pay when enforcement starts happening left, right, and center. A brief call with a close friend and technical architect at a large Indian Software development company a few days back also helped me learn that Oracle is already in the process of making Java API’s paid and asking each company to enter into a commercial license, making most of these Indian companies to look out for other avenues such as Open JDK to escape such an inconvenient position.