News/Resources: Blog

Emerging Technologies BLOG

Copyright in APIs: The Sky Won’t Fall, and The Clouds Are Safe

Posted on Wednesday, May 30, 2012

BY Edward J. Naughton

It’s “The End Of Programming As We Know It”! Oracle is going to “rewrite software law” to create crushing legal burdens on cloud computing! People will soon be able to copyright anything – there could even be a “land grab” for common words that would allow them to “lockdown” programming!

If you’ve seen the apocalyptic articles on the tech news sites following the jury’s verdict on the copyright claim in Oracle v. Google, you may have already begun building an underground shelter and arming the kids against the impending zombie onslaught. But is it really the end of days for software? Not so much.

The Java language, platform, and APIs

Some of the clamor may be misinformation, but I think a lot of the confusion stems from the imprecise use of terminology, partly because Java is both a programming language and a platform. So let’s start by getting the details right.

The Java programming language was created by Sun (now Oracle) and designed specifically to be able to run on as many hardware and software environments as possible. The Java language has been made available under the General Public License, a free software license.

Programs written in the Java language run on the Java platform, which is a software environment that runs on top of other hardware-based environments (e.g., it runs on Windows, Mac OS, Linux, etc.). The Java platform consists of the Java Virtual Machine and the Java Application Programming Interface (“API”). The Java Virtual Machine is the virtual (software-only) processor that runs programs written in the Java language. The Java API is a collection of prewritten software components called class libraries, that provide useful functions (such as networking, database, security, encryption, etc.). Developers writing programs in the Java language can “call to,” these components to use their functionality, and thus can avoid having to re-write this code themselves.

This prewritten code is organized into methods, each of which provides a specific function. The methods are grouped into classes (and subclasses), which are grouped into packages. These elements are interrelated in a complex way. Interfaces define the relationship between different classes that share common characteristics, for instance, and methods can use parameters that are defined in different classes. This is true even if the classes are in different packages.

Each class library has an accompanying specification. A specification (or “spec”) is the documentation that describes the pre-written code in the library. It describes the elements that make up the library, including the classes, the methods, the interfaces, exceptions (errors), parameters, and fields. The Java API specifications, in other words, lay out a detailed blueprint for the prewritten code, comprising hundreds of classes, methods, interfaces, parameters, and fields.

When it created Android, Google substantially copied the structure, sequence, and organization (“SSO”) of 37 Java API packages and specifications. It admitted this at trial. Google also admitted that the 37 Java API packages are sufficiently original to meet the requirements of the copyright law, and that its copying was more than de minimis. The jury – assuming that the API packages were protected by copyright, as it was instructed – found that Google infringed the copyrights in the API packages, and that Oracle did not lead Google to believe that copying the SSO of the 37 API packages was permitted.

After the jury decided that there was infringement of the software code in the API packages, a flurry of articles appeared, all echoing the notion that the verdict jeopardized a “long-held practice of API copyright exemption” and arguing that programming would be all but impossible if the API packages were allowed to be copyrighted. These claims have been repeated throughout the technology press, accompanied by dire warnings of doom, but neither stands up to any scrutiny under copyright law.

APIs have long been understood to be copyrightable

The first claim, that API packages have been regarded as subject to some kind of “exemption” from copyright law, is — not to put too fine a point on it – nonsense. Google made this argument last summer, but it did not identify a single case that held that API packages were unprotected by copyright. Judge Alsup rejected Google’s argument, ruling that the API packages are not categorically exempt from copyright protection. (Judge Alsup also ruled that individual method names alone cannot be protected by copyright, which is why the suggestion that there will be a “land rush” to copyright method names is just silly.)

Judge Alsup got it right. The Java API packages are, under copyright law, “literary works.” This category is broad, covering pretty much any written expression, whether on paper or electronically, including fiction, nonfiction, poetry, textbooks, reference works, directories, catalogs, advertising copy, compilations of information, and even databases. It was decided long ago that software source and object code are to be treated literary works. The only requirement is that the work must meet the copyright law’s low threshold for originality. (Remember that here Google admitted the originality of the Java API packages.)

I’ve been advising software companies on copyright law for more than 17 years. In my experience, software lawyers and developers routinely treat APIs as copyrightable and proprietary. Virtually every software license agreement declares that the software is copyrighted, and some of the best-drafted licenses I’ve seen specifically state that the APIs are copyrighted.

It’s not just me: this software attorney explains why software companies need API licenses to protect their IP. And most software developers follow this advice and provide access to their APIs subject to an API license agreement. Intel’s is here; eBay’s is here; Garmin’s is here; Yahoo’s are here; Twitter’s is here; VMware’s is here; Microsoft’s is here. The US Postal Service presents you with a 33-page document if you want to use their address mapping API. All of these companies (and many more than I can list) believe that their APIs are protected by copyright, and they make them available precisely because copyright gives them protection.

In the financial services industry in particular, proprietary APIs for high-performance electronic trading are commonplace. The idea that these proprietary APIs, developed at great expense, are not protected by copyright and can be freely copied would be regarded as heresy.

And Oracle’s assertion of copyright in its Java API packages is hardly groundbreaking. In the 1990s, for example, 3Dfx Interactive aggressively asserted its copyrights against others who distributed utilities that sought to emulate its proprietary Glide 3D graphics API.

Copyright is critical to free and open computing

It’s true that some APIs are made freely available, either on a royalty-free basis or under a FOSS license. Even when APIs are made available under a liberal open source license, such as OpenGL (a cross-platform 3D graphics API licensed under various open source and commercial licenses) and OpenMP (a widely used API for parallel shared-memory, multiprocessing programming), copyright is asserted in the API.

Indeed, copyright ability isn’t a threat to open computing. It’s essential to it. Open source licensing of APIs or code works precisely because copyright applies to the API or code and allows the copyright owner to impose the terms and conditions of the open source license. Richard Stallman explains this better than anyone in his famous essay on copyleft:

The simplest way to make a program free software is to put it in the public domain, uncopyrighted. This allows people to share the program and their improvements, if they are so minded. But it also allows uncooperative people to convert the program into proprietary software. They can make changes, many or few, and distribute the result as a proprietary product. People who receive the program in that modified form do not have the freedom that the original author gave them; the middleman has stripped it away.

In the GNU project, our aim is to give all users the freedom to redistribute and change GNU software. If middlemen could strip off the freedom, we might have many users, but those users would not have freedom. So instead of putting GNU software in the public domain, we “copyleft” it. Copyleft says that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. Copyleft guarantees that every user has freedom.

To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program’s code, or any program derived from it, but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.

Proprietary software developers use copyright to take away the users’ freedom; we use copyright to guarantee their freedom. That’s why we reverse the name, changing “copyright” into “copyleft.”

Copyleft is a way of using of the copyright on the program. It doesn’t mean abandoning the copyright; in fact, doing so would make copyleft impossible.

In a very real sense, then, we shouldn’t be at all worried about a ruling that the Java API packages are protected by copyright. Most of the industry (excepting Google, I guess) already has assumed this. But a ruling that APIs cannot be copyrighted would have serious implications, for both proprietary developers and the FOSS community alike.