A few years ago, the database company Oracle sued Google, arguing that Google’s Android operating system infringed the copyright of Oracle’s Java technology. On Thursday a jury sided with Google, ruling that copyright’s fair use doctrine allowed Google to build Java-compatible software without getting a license from Oracle.
[su_dropcap style=”flat”]T[/su_dropcap]his is not the final word in the dispute. Oracle is almost certain to appeal the case to the Federal Circuit Appeals Court, which is known for its pro-patent and pro-copyright views and has already ruled for Oracle once in the case.
Oracle said making software compatible with Java infringed copyright
The lawsuit focuses on technical decisions Google made when it created the Android operating system.
Google wanted people who wrote programs in the popular programming language Java to be able to reuse their code in Android apps. To do that, Google had to ensure that Java code written for other purposes ran exactly the same on Android. But negotiations with the company behind Java, Sun Microsystems (which was later acquired by Oracle), broke down, so Google decided to create its own version of Java from scratch.
Google’s version of Java didn’t reuse any code from Oracle’s version. But to ensure compatibility, Google’s version used functions with the same names and functionality.
This practice was widely viewed as legal within the software world at the time Google did it, but Oracle sued, arguing that this was copyright infringement. Oracle argued that the list of Java function names and features constitutes a creative work, and that Google infringed Oracle’s copyright when it included functions with the same names and features.
Google argued that the list of function names, known as an application programming interface (API), was not protected by copyright law.
Google’s defenders pointed to a landmark 1995 ruling in which an appeals court held that the software company Borland had not infringed copyright when it created a spreadsheet program whose menus were organized in the same way as the menus in the more popular spreadsheet Lotus 1-2-3.
The court held that the order of Lotus 1-2-3 menu items was an uncopyrightable “method of operation.” And it concluded that giving Lotus exclusive ownership over its menu structure would harm the public:
Under Lotus’s theory, if a user uses several different programs, he or she must learn how to perform the same operation in a different way for each program used. For example, if the user wanted the computer to print material, then the user would have to learn not just one method of operating the computer such that it prints, but many different methods. We find this absurd.
Google believed that its own copying was directly analogous to what Borland had done. There were thousands of programmers with expertise in writing Java programs. By designing its platform to respond to the same set of programming commands as Oracle’s Java system, Google allowed Java programmers to become Android programmers with minimal training — just as Borland’s decision to copy Lotus’s menu structure avoided unnecessary training for seasoned Lotus 1-2-3 users.
Google was forced to fall back on a fair use argument
In 2012, Judge William Alsup agreed with Google. He ruled that copyright only protects the creative aspects of a work, not functional characteristics. Alsup ruled that because the names of Java functions was essential to achieving interoperability, they were a functional characteristic rather than a creative aspect of Java, and using them wasn’t copyright infringement.
But in 2014, the Federal Circuit Court of Appeals disagreed. The court was unimpressed with Google’s argument that function names were functional characteristics not protected by copyright. In the Federal Circuit’s view, the list of Java functions was just another kind of “code” that couldn’t be copied without its creator’s permission.
But the case wasn’t over. APIs might be protected by copyright law, but Google could still invoke copyright’s fair use doctrine to justify its use of them. The case was sent back down to Judge Alsup’s courtroom, where he was asked to assume (contrary to his previous ruling) that APIs were copyrightable and hold another trial focused on the fair use question.
Now Google has prevailed again in Alsup’s courtroom, with the jury ruling that Google’s use of the Java APIs were, in fact, fair use.
But the case still isn’t over. It will next go back to the Federal Circuit. And given its track record, there’s a decent chance it will overrule the lower court’s decision once again. Then the losing party will have the chance to appeal to the Supreme Court, which declined to hear the case during the first go-round.
API copyrights could become an obstacle to software compatibility
There’s a long tradition of computer programs being designed to be compatible with other programs created by third parties. To do that, the developer of the new software needs to copy certain functional characteristics of the old software. Often, software companies have good reasons to do this even when the author of the old software objects.
One good example is the open source project Samba. It was created to allow users of open source operating systems such as Linux to share files with Windows users. To do that, the Samba programmers reverse-engineered and then duplicated the functionality of the Windows file-sharing system. They didn’t copy any Microsoft software, but they did duplicate the sequence of commands needed to transfer files, read the contents of folders, and perform other functions in the Windows file-sharing system.
As an open source project, Samba became hugely popular. The early versions of Mac OS X included a version of Samba, and the software was incorporated into a lot of standalone file servers.
The legality of projects like Samba has been widely accepted for more than two decades. But if Oracle’s arguments are accepted by the courts, Microsoft might be able to sue Samba for copyright infringement. If the Federal Circuit’s precedent isn’t overturned, companies could become more reluctant to reverse-engineer competitors’ products in order to make them compatible.
A 2014 brief by the Electronic Frontier Foundation offered another example of a case where copying APIs was valuable:
Jeremiah Flerchinger is an electrical engineer with over ten years of service in the Department of Defense, after previous experience with a machine-tool company. When the National Aeronautics and Space Administration (NASA) sought to repurpose old manufacturing robots for a new project, they asked Flerchinger’s company to manufacture and program updated memory chips to store the robots’ new instructions. Configuring firmware to put on the chips required using obsolete software that wouldn’t run on modern computers. Flerchinger reimplemented the software’s API, creating modern software that could fulfill the same functions and work alongside old machines that had the same API hard-coded into their electronics.