Battle of the API’s
In recent news, Google just won a major legal victory over a lawsuit from Oracle over a set of 37 APIs which Oracle claims that Google has stolen from the Java framework, which was acquired by Oracle when they purchased the company behind the original implementation of the Java programming language, Sun Microsystems.
From just a financial perspective, it’s a significant amount of money at stake. Oracle filed for damages in the amount of north of $9 billion dollars against Google … not a small chunk of change.
Beyond the financial damages Oracle sought for during the lawsuit, there are some important intellectual property ramifications behind this significant lawsuit.
At the heart of Oracle’s lawsuit against Google is their claim that Google literally copied 11,500 lines of the actual source code in the Java programming language, and incorporated it directly into Google’s flagship mobile device operating system, Android.
What Oracle claims Google did is rather than requesting and seeking a software license from Oracle (which likely would involve some amount of financial fee which Google would need to fork over to Oracle for the right to use the Java language for their Android operating system), Google decided to bypass any sort of software licensing negotiations, and take what they needed from Java and bake it directly inside their Android operating system.
To understand WHY Google would want to go through the rigamarole of incorporating those Java API libraries into the Android operating system, one must first understand the basic concept of an API.
An API is short for “Application Programming Interface”.
An API is essentially a software library that any software developer can use in their own custom software program.
It essentially frees that software developer from having to write her own implementation of that same API library.
There is nothing magical about APIs. It’s just a chunk of source code, wrapped up in a “pretty bow” that other software developers can use.
What typically ends up in an API?
In terms of an operating system like Microsoft Windows, Unix/Linux, Apple’s Mac OS X, or Google’s Android OS, it’s any sort of functionality that would help prevent software developers who are interested in making software applications for that operating system, from “reinventing the wheel” themselves.
For example, most operating systems have APIs that allow you to do things like reading and writing files. Or make HTTP calls. Or draw a button on the screen. Or a window. Or open up a connection to a database.
All this kind of functionality is common to ANY kind of software program that software developers typically write. So why would you want to reinvent the wheel and code up a new implementation of say, opening up a file yourself, when there’s an API library out there which you can incorporate in your own custom program?
If there’s one golden rule in software development, it’s DON’T REPEAT YOURSELF. If someone has already written something that you can use in your own program, why waste needless time doing it yourself?
The value you add as a software developer, is the specific business domain requirements that can’t be replicated anywhere else.
And that is precisely why Google incorporated Java APIs directly into their Android operating system.
Google wanted to attract as many software developers as they could, to program applications for their mobile operating system, Android.
In order to do that, they needed to provide useful API libraries to software developers that will free them from writing “reinventing the wheel” type code, that an Android API could provide instead.
The problem lies in the way Google went about building the API libraries for Android.
The entire Android operating system is written in the Java programming language, originally developed by Sun Microsystems.
Java and the JDK libraries (think APIs) associated with Java, changed ownership when Sun Microsystems was bought out by Oracle.
Instead of seeking licensing agreements with Oracle to use those important Java API libraries (which are very useful for software developers, as previously explained), Google decided to bypass any licensing agreements and essentially copy the source code behind the Java API libraries they wanted, directly into their Android operating system.
This is the heart of the lawsuit. During the lawsuit, Google claims they didn’t need to bother seeking licensing agreements with Oracle because they claim APIs aren’t protected by copyright laws. They claim that it was “fair use” to use those Java APIs without the need for software licensing negotiations with Oracle.
I’m no mind reader, but my educated guess was that Google was in a rush to release Android as soon as they could, as they feared Microsoft would soon dominate the mobile device ecosystem just as they did with desktop computers.
Despite proof in the Oracle/Google trial that their own legal department recommended seeking a licensing agreement with Oracle, to avoid the very litigation that Oracle instigated.
I have no doubt that many open source advocates have wholeheartedly supported Google’s victory in the name of intellectual freedom.
But I personally believe this trial is only the first volley and Oracle will be granted a retrial and appeal to argue that APIs are fully protected under copyright laws.
To use the defense of “fair use” seems a slippery slope to me. Just how exactly do you quantify “fair use”? Is it some threshold number of just how many lines of source code you can copy from an API?
If Google was adamant about not bothering with seeking licensing agreements with Oracle, a better route to avoid litigation might have been to create a “clean room” implementation of the Java APIs they were seeking to incorporate into Android.
That is, instead of COPYING the source code behind the API libraries they took, they should have created their own source code implementation behind the API method/function declarations.
In the early 1980s, when IBM ruled the roost with their IBM personal computer, that’s how IBM clone maker computer makers created “IBM compatible” computers … that is, computers that could run the same software that IBM computers.
They needed to reverse engineer the BIOS software that controlled IBM computers but without actual access to the source code behind IBM’s BIOS software.
Not an easy task, but they managed to do it and avoid any legal litigation troubles that could have ensued, had they just gone the easy route of just copying IBM’s copyright protected BIOS software.
Conclusion
Whether you think it’s right or wrong to think APIs should be protected by copyright laws, I think it’s necessary to think about the importance of intellectual property.
Source code is intellectual property. Much like novels and screenplays are fully protected by copyright laws, source code is no different.
You can either write source code under an open source license where anyone is free to use it and modify it.
OR you can write source code under a non open source license, more appropriate for anyone who wishes to keep the source code under their control and non modifiable without express permission and licensing fee negotiations.
I think every company, organization or individual programmer should have the right to choose either path of licensing and enjoy the benefits and protections each kind of licensing entails.
But allowing this concept of “fair use” of APIs, seems to defeat the purpose of non open source licensing protections … if you want to keep source code under your private stewardship and control that comes with the umbrella of non open source licensing, “fair use” copying of APIs severely degrades that private stewardship protection.
I hope Oracle will have another day in court to reintroduce their case under a different judge and jury.
Something as important as intellectual property rights certainly deserves more attention than a single lawsuit.
Especially when it’s ramifications can affect the future of software development.
