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.”1

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

nine + 8 =

Archives

  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • September 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010