On 9 May 2014, the United States Court of Appeals for the Federal Circuit (CAFC) issued its opinion in Oracle America, Inc v Google Inc. [PDF 342kB], in which it overturned the earlier ruling by District Judge William Alsup that Oracle's Java API declaring code was not protected by copyright. I will explain what that means, for non-programmers, below. But the significant point of this judgment is that Google’s Android operating system – now by far the most popular smartphone operating system globally – has appropriated elements of Oracle’s Java programming language environment that are subject to copyright protection. Potentially, therefore, Google may be found to to have infringed copyrights owned by Oracle.This is a blog about patents and innovation, and I do not usually write about copyright. But the Oracle/Google litigation started out as a combined patent and copyright matter, and one of the most popular early articles on this blog was about this particular dispute. The patent issues have since fallen by the wayside, but I have continued to follow the fortunes of this case out of personal interest.
Although the decision in this appeal is technically a loss for Google, it is far from being the end of the story. The case is now going to return to the United States District Court for the Northern District of California for a further trial, to decide whether Google’s use of Oracle’s programming code is covered by a ‘fair use’ defence. If so, then Google will be off the hook. If not, then it will probably owe Oracle an absolute shed-load of cash in damages!
I want to try to explain what this case is all about, and why it is really important, in the simplest terms possible, assuming that many of my readers are not programmers.
What Is An ‘API’?
The dispute is over software code known as ‘application programming interfaces’, or APIs. The simplest analogy I can think of for an API is the accelerator pedal (that is ‘gas pedal’ for my US readers) of an automobile. Everybody knows that if you want to make a car go (or go faster), all you need to do is to press down on the accelerator pedal. What actually happens, under the bonnet (or ‘hood’, for US readers), when you do this depends upon the age and technology of your vehicle. It might be very different if you are driving an old car, a new car, a petrol (gasoline) powered car, a diesel fuel powered car, an electric vehicle or a hybrid vehicle.As a driver, you do no much care about these technical details. But the end result of pressing down on that pedal will always be the same.
An API is a bit like that. If you are a programmer, and you want to do something such as displaying some text on the screen of a device, it is useful if there is some well-established way to do this that is independent of the particular device the end user happens to own. Ideally, you write the code to do this once, and it then works on a wide range of different devices without the need for any modification or customisation.
An API is a well-defined set of procedures – each of which is a bit like the accelerator pedal of a car, in that a programmer knows that if they want to achieve a particular result they can do it by specifying the required operation and its associated parameters in a manner dictated by the API. For example, in order to display some text, an API may provide a function that requires the programmer to specify the text itself, font details (e.g. typeface, size) and the location on the screen at which the text should be shown.
As another example, a graphics API may provide a function for drawing circles which requires the programmer to specify the coordinates of the centre of the circle, along with its radius.
API Design Involves Creative Choices
Just as somebody, at some time in the past, decided that providing an accelerator pedal would be a good way to enable a driver to control the speed of a vehicle, the designers of programming languages and other software systems need to create interfaces for accessing commonly-required features. Generally speaking, these interfaces consist (at least) of a set of functions, each of which has a name and a list of associated parameters. These groups of functions, and their associated parameters, comprise an API. In the same way, accelerator, brake and clutch pedals, along with a steering wheel, a gear stick, and so forth, comprise an interface enabling a driver to control a vehicle without needing to understand all of the chemical, electrical and mechanical processes that occur when the controls are operated.I have seen it suggested that APIs are not sufficiently substantial to be worthy of copyright protection. For example, the coverage of the CAFC’s Oracle opinion on the IP Kat blog states that ‘from this decision it would seem that neither the originality requirement nor the idea/expression dichotomy are to be intended as particularly meaningful thresholds to protection, especially considering that APIs are not highly sophisticated software commands.’
But in reality, hundreds of creative decisions may be made in designing an API, from the specific set of features that will be provided, to the details of parameters used to control those features, to the individual names of functions and other software objects making up the API. While a single function name may not be substantive enough to attract copyright protection, the CAFC has ruled (quite reasonably, in my view) that an entire API certainly can be.
The Java Programming Language
A company called Sun Microsystems developed a computer programming language called Java. The Java language became quite popular, not least because Sun made it available for free for a wide variety of uses, although it effectively retained control over certain commercial uses of the language. Oracle subsequently acquired Sun, and with it ownership of all rights relating to the Java programming language.The popularity of Java meant that many programmers were familiar with it, and its various APIs.
Rather than reinventing the wheel, the developers of Google’s Android operating system decided that it would be convenient to adopt the Java programming language and many of its APIs. This would mean that the large number of existing Java programmers would not have a steep learning curve if they wanted to start developing applications to run on Android-based devices.
But adopting the Java APIs meant copying hundreds of specific function names, parameter lists and other software component names that had been defined by Sun/Oracle developers. Oracle says that these API details are protected by copyright, and that Google is an infringer. Google says that they are not protected by copyright but that, even if they are, then it is legal to copy them because this is a protected ‘fair use’.
APIs and Copyright Protection
Judge Alsup originally found that Oracle’s APIs are not protected by copyright. The CAFC has now overturned this decision, deciding that the majority of the APIs are the result of creative choices, and that the original developers could have implemented the same ideas in different ways. Google did not have to copy – it could have created its own, equally functional, APIs – but it chose not to in order to capitalise on the existing base of Java programming experience.The ‘Interoperability’ and ‘Fair Use’ Issues
The CAFC’s finding that the Java APIs are subject to copyright protection is not the end of the road for Google. Just because something is ‘copyrightable’, does not mean that any unauthorised us of that thing will be an infringement. In this particular case, it might be that copying the APIs is a ‘fair use’ of the copyright content, because ‘interoperability’ of systems is more important that providing Oracle with exclusive rights over the interfaces.The policy reasons for this are easily understood using my automobile example. Imagine that a single car-maker (say, Mercedes-Benz) owned exclusive rights to the interface we now take for granted (steering wheel, accelerator, brake, clutch, and so forth). Every other manufacturer might then need to develop its own system of control. Learning to drive in one car might not enable you to safely control a vehicle made by a different company.
For example, the ‘standardised’ controls we now take for granted were not the only choice available to early car-makers. The Model-T Ford, for example, had a very different control interface!
It is clear that the overall social benefits of standardising the control interface for automobiles outweigh the private interests of any one manufacturer in ‘owning’ a particular arrangement of controls.
Similarly, it might be the case that the benefits of providing the wider community of programmers with a common set of APIs across multiple vendor systems (e.g. Oracle’s Java environment, and Google’s Android) outweigh the private interests of Oracle in being able to enforce its copyright in those APIs.
In the original District Court trial, the jury was unable to reach a decision on this question. Judge Alsup determined that this did not matter, because the Java APIs were not protected by copyright anyway. The CAFC has decided differently – the Java APIs are subject to copyright protection. However, it may still be the case that others can nonetheless copy them because this constitutes a ‘fair use’ of the copyright material.
Conclusion – Where To From Here?
Google may yet seek to appeal the decision further, either by requesting reconsideration by the CAFC en banc, or by applying to the Supreme Court. I do not expect that any such appeals would be successful, but I do think that the question of interoperability (i.e. the ability of programmers to apply their skills and knowledge across different systems) is an important one, and that there is a strong case to be made that copying of APIs is protected under ‘fair use’.In the absence of any (successful) appeal, the case will be remanded back to the District Court to decide whether Google is entitled to rely on ‘fair use’ as a defence. It will be some time before any final decision is reached on this issue and, in the meantime, there is little sign that Android’s dominance of the global mobile operating system market is likely to wane. Oracle will be hoping to cash in on this, while Google will be praying that it does not have to pay up!
0 comments:
Post a Comment