Should APIs be copyrighted?

Should APIs be copyrighted?

Summary: Latest court ruling states Oracle can be granted copyright protection for its Java APIs, opening up a legal precedent that could affect the thousands of APIs out there.


In the latest chapter of an ongoing legal battle, a U.S. appeals court has just ruled that Oracle can be granted copyright protection for its Java APIs in a battle with Google over Android's inclusion of the code. As reported by ZDNet colleague Zack Whittaker, the case dates back to 2010, when Oracle took Google to court alleging that Google had violated Oracle's Java copyright with the inclusion of 37 Java APIs within its Android mobile OS. The court ruled in May 2012 that the structure of the Java APIs were not copyrightable. The appellate court just reversed that ruling.

Keyboard and question marks 2 by Joe McKendrick
Photo: Joe McKendrick

What does it mean if APIs can be copyrighted? Will this have a chilling effect on the burgeoning API economy, and the flexibility of developers and enterprises to build and connect their digital ventures? Or will it afford developers some protection over the fruits of their labors?

The stakes are potentially high. As fellow ZDNet contributor Stilgherrian recently pointed out, the only businesses that can compete from this point going forward are those that leverage APIs for back-end services and digital capabilities.

Some industry observers say nothing good can come of copyrighting APIs. Ed Anuff, VP of product strategy at Apigee, says the ruling is "a no-win proposition for anyone involved," noting that "while the goal of avoiding fragmentation of Java that has been Oracle's stated intent in pursuing this has some merit, we're not comfortable with the idea that copyrighting APIs is the way to accomplish this.  It's likely going to have the opposite effect, causing the proliferation of convoluted APIs for no other reason than to avoid the potential of legal exposure."

APIs can be quite simple, constructed with REST calls, and therefore many APIs developed by different creators are likely to be similar, if not identical. By some counts, there are more than 10,000 public-facing APIs, and it is projected that there may be between 100,000 to 200,000 public and private APIs this year. Anuff's colleague, Bob Pagano, spelled out the implications of API copyright claims to developers in a Wired interview a couple of years back: he feared that in a world of proprietary APIs, someone will make "a land grab of common names and starts enforcing copyrights on APIs en masse," locking down APIs in the same way internet addresses or Twitter handles are locked down. And “the odds of similarity between any two RESTful APIs is quite high,” he added.

Community sites such as the API Commons may help to keep APIs open and available -- but will it be enough?

Dan Rowinski documents the appellate court's ruling in ReadWrite, which states 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."

Rowinski also cites the warning issued by the Electronic Frontier Foundation in 2012, as the lawsuit was progressing. "Treating APIs as copyrightable would have a profound negative impact on interoperability, and, therefore, innovation. APIs are ubiquitous and fundamental to all kinds of program development. It is safe to say that ALL software developers use APIs to make their software work with other software."

UPDATE 1: In a statement published in CRN, Oracle General Counsel Dorian Daley said "the Federal Circuit's opinion is a win for Oracle and the entire software industry that relies on copyright protection to fuel innovation and ensure that developers are rewarded for their breakthroughs."

UPDATE 2: The EFF issued a statement in response to the ruling, calling the ruling a "dangerous decision," noting that copyrighted APIs will impede developers' ability to "freely reimplement or reverse engineer an API without the need to negotiate a costly license or risk a lawsuit."

Will extending copyright protection to APIs mean a step backwards in efforts to make applications more open and interoperable with each other? Or, is there another side to this? Does anyone see advantage in providing copyright protection to APIs? Should weeks' or months' worth of work and investment in this area be protected, as with other forms of software? Perhaps this is also an opportunity for vendors to publicly demonstrate their commitment to open innovation by putting many of their key APIs into the API Commons -- as vendors have done in the past with Web services.

Topics: Software, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It's a disaster waiting to happen, frankly

    The industry has been operating on the assumption that neither APIs nor programming languages are copyrightable since the first compiler was written; and copyright terms are a ridiculously long life plus 70 years, and have been automatic since the 1970s (if I remember rightly). That makes for a *lot* of potential litigation affecting languages and APIs that have been in wide use for *decades*. Even Oracle itself could be affected adversely if this precedent is allowed to stand (it's not like Java is the only language it uses).

    I'm not enough of a lawyer to tell whether or not the Federal Circuit's decision is correct, but if it is, that means there is a serious problem with the existing copyright statute that Congress needs to fix ASAP.

    On the other hand, we could see a revival in the fortunes of Ada, which, as it was developed by the US Defense Department, cannot legally be copyrighted.
    John L. Ries
    • Corrections

      I should have said "legal geek", as I'm not a lawyer at all (thankfully). I also seem to recall that the copyright term is life plus 90 years.
      John L. Ries
      • I AM a lawyer.

        1) IN THE U.S. automatic copyright has applied since Jan 1, 1978.

        2) The Sonny Bono Copyright Extension Act extended ALL *existing* copyrights (i.e., still under copyright as of the effective date of the Act) to 70 years after the death of the individual author or 120 years if the "author" is a corporation (i.e., the actual authors are corporate employees or the work is a "work for hire").

        (The main impetus behind the extension is that Disney and the music industry want to keep in force their right to make profits on movies and music. The fact is that MANY of Disney's movies didn't make a profit for DECADES. And, obviously, there is still a huge demand for music from the 1950's and 60's. One reason why Apple has "digitally remastered" so many recordings from that era is that in the U.K. copyright is 50 years.)

        3) Legally, there's no question that API's are copyrightable. Someone wrote a program. That source code is copyrightable, just the same as if someone writes music or a novel or newspaper article. The compiled program is a "derivative work" and only the copyright owner is allowed to make "derivative works" (or someone licensed by the copyright owner).

        4) ACCESS TO the API is NOT copyrightable. So anyone can write code that CALLS the API. But if they want those calls to be PROCESSED, they'll have to have the API installed -- and the API owner has the right to charge for use of its PROPERTY.

        It's the same as if I load my stuff in a truck and drive to an apartment complex. I have a bed, dishes, etc. No one can charge me for having my truck loaded with stuff and bringing it to the complex (the code that CALLS the API). But if I want to USE the apartment owner's PROPERTY, he has the right to charge me.
        • But you obiously know nothing about software.

          The truck analogy is bad. It's more like parking a bike in a bike rack.

          The rack is the software owned by the author. The bike is your derivative work.
          The API itself is the freaking hole in the rack. You can't own that.

          If someone else comes along and makes a completely different rack of different materials (corresponding to a different internal software implementation) which also happens to fit your bike, then the first rack owner cannot claim ownership and stop the second rack maker from selling his product. To claim otherwise isn't just stupid, it is dangerous.
          • You are right

            Without offense - many lawyers don't know much about software or understand it - and that's ok, they don't have to know everything.
            Copyrighting an API is pure madness in my opinion, the bicycle rack example was a very good example, most APIs are obvious and don't have any level of innovation except its implementation - the code itself, that obviously should be protected.
            If I create an API with a method Sendmailtosomeone that takes an email address and a chunk of text, how can someone conceive that nobody else can do an API with a same Sendmailtosomeone method?! That's insane!
          • wrong analogy

            a IP expert lawyer told me the best analogy:
            the java APIs are just the lyrics of a song.
            The implementation is like the what comes out of the performer(s) mouth.
            In this case the performers are Oracle and google.
            since java APIs are pulic domain, oracle has no right to sue google as the implementation is independent and done in a clean room.
            The victim is google who is facing tortuos interference in its bussines.
            LlNUX Geek
          • Google admitted to no clean room.

            They used the spec that was copyrighted. A clean room would have to determine the action of each method independently WITHOUT using the spec as a rule book.
          • You don't know what a "clean room development" is.

            They used NO CODE that was not GPL to start with.

            Using published specifications is still a CLEAN ROOM implementation.
          • It was the Apache Harmony Project that used a cleanroom for Java

            The Apache Harmony Project was launched prior to Sun's open sourcing of Java.

            Guess what Google dipped into for Dalvik? Apache's Harmony project code.

            P.S. It's rather funny that Oracle and IBM are best buds today with OpenJDK (these two large corporations control the OpenJDK project) as IBM was the primary corporate sponsor of the Apache Harmony project.
            Rabid Howler Monkey
          • In addition ...

            Since Google used Apache Harmony as the source for Dalvik, the license for Dalvik is Apache 2.0. Recall that Sun Licensed Java under the GPL.

            At a minimum, Google's got a licensing problem with Dalvik as (according to you and others) it copied GPL source code and licensed that same code under Apache 2.0.
            Rabid Howler Monkey
        • Not what an API is

          An API is not a program, it is the definition of how to interact with a progam.

          With your truck analogy, the API would the be stripes in the parking lot.

          An API itself does not do anything... it is the implementation of an API that actually does anything.
          • The API is the most complex part.

            It defines a set of concrete rules, actions, interactions and names that allows any code monkey to implement things.
          • You keep referring to the "rules, actions, interactions"

            None of which is in the API.

            And a list of names is not copyrightable.
        • You also don't understand Copyright Law.

          What you're describing isn't a copyright - it's a patent.

          A copyright is a time limited monopoly on a *creative* work in a fixed media. It has to be expressive and not derivative.

          For example, you can't copyright a language. You can't copyright an alphabet.

          Until this ruling, it was generally held than an API - in the sense of a collection of subroutine prototypes - wasn't in and of itself expressive - it was a *description* of something that was expressive and so was utilitarian, not creative. Ergo, not copyrightable.

          In your example, you're confusing the API (which describes the interfaces and wasn't until now copyrightable) with the actual code that does the work (which IS copyrightable).

          To draw a literary analogy: the API is the table of contents of a book... the actual program is the contents of the book itself. The table of contents on its own isn't likely copyrightable - even if the book as a whole is.
          • The API is also the plot.

            It spells out specifics of characters and how they act. It defines what happens in each scene.
          • Naaa, the plot sounds more like an implementation decision.

            The API of a book is what allows you to use is *as a book*. The contents of the book is an implementation of the author.
        • Wrong.

          As others pointed out, truck usage isn't a good analogy.

          Try "telephone book". The API is the telephone book.

          You can copyright the telephone book as an aggregate, but you cannot copyright the facts within the book.

          The telephone book itself doesn't make telephone calls. There is nothing there that DOES anything.

          It doesn't even dictate how the telephone works - that is up to the various telephone companies.

          But if you want to CALL someone, it specifies the sequence of numbers to use.
        • A Quibble

          Not an attorney, but I was reading Billboard magazine in the mid-70s. The 1976 act was to bring the US into conformity with The Berne Convention.

          I think you are in a gray area with #3. While expression may be protected, ideas are not. For instance, a math textbook may be protected, but a particular equation would not be. Yes, the documentation and description of a programming language could have protection, but a for loop, or a method sort(a-list), or the concept that someone implements independently, but uses the same name and argument calls for compatibility? Keywords aren't protected. Semantics? Isn't that an idea?

          And I'd also say that if a Federal judge said they weren't and an Appeals Court said they were, there, indeed, is a question regarding protectability. Whittaker's write-up was — no surprise — not very good, but he did say that the trial court was going to have to give Google a chance to present arguments regarding its privileges under fair use. That means, at the appellate level, there was no finding that apis were incontrovertibly protected expression.

          With number 4, I'm not sure you've thought this through completely. What is a computer program/procedure/function/module/package except the extension and utilization of apis into a new bespoke api? When one puts that invocation of someone else's api in source code into the class that creates a new api, how is that not infringement if the api is protectable?

          Before java had boxing and unboxing, I created an IntList (a wrapper to a mutable array of int values) class and followed Sun's guidelines for the smart way to set up a List — hey there — api. The difference between Google and me? I don't have a gajillion dollars. Also, I may have had license as a legitimate downloader of the jdk.

          As near as I can tell, Sun used examples from C++, Objective-C, and SmallTalk when they were working through their core classes. Does Oracle get to say "Ownership starts here. Tough luck Drs. Stroustrup, Kay, et al." There's also a point to be made regarding implementing something like QuickSort, in that if you don't write it one of a very few ways to be written it will not work. Your api will need sorting. There's one better way.

          Your final analogy isn't applicable in this case. Google looked at Sun's complex and made an incomplete complex that from a distance looks like Sun's and then invited folks to bring their loaded trucks there. As it turns out, I've been employed by architects. The drawings are copyrighted, but the concept of a one-bedroom apartment is not, and indeed there are books of graphical standards — which look to me quite analogous to code examples — that everyone includes in their drawings.
          • the apartment example

            is very apt I think
    • John L. Ries: "The industry has been operating on the assumption

      that neither APIs nor programming languages are copyrightable since the first compiler was written."

      What if this assumption is incorrect? What stood out for me from the article is this question:

      "Should weeks' or months' worth of work and investment in this area be protected, as with other forms of software?"

      An API is a user interface for developers. And the creation of APIs is often non-trivial as evidenced by these links, the first to a presentation by a Google (formerly Sun) employee and the second to a book by the founder and initial architect of the Netbeans IDE:

      "How to Design a Good API and Why it Matters"

      It seems to me that the U.S. appeals court might be on to something. APIs are integral to many programming languages and applications. And, often, they are non-trivial.
      Rabid Howler Monkey