For whom the API tolls?

One of the pivotal aspects of the ongoing Oracle vs. Google trial over Android is the notion of whether application programming interfaces (APIs) are copyrightable.

Oracle argues that Android can use the Java language freely, but Android’s use of copyrighted Java APIs infringes on Oracle’s intellectual property. Google asserts that the Java language is only a shell and the language plus the functional libraries accessed by the APIs as a whole make it useful.


CNET reports on yesterday’s proceedings:

Prior to the jury entering the courtroom, [Judge William] Alsup asked the Google team whether Google admitted that it copied the 37 APIs at the center of the lawsuit.

“I quibble with the word ‘copy,'” Google lawyer Bruce Baber said. “APIs have been out for long time, in books, on the web and available in (Apache) Harmony. We absolutely used and included them in Android so we would have them exactly right for the [Java] specification.”

So is it fair use for Google to copy scores of Java APIs developed by Sun (now part of Oracle) without compensation? Android czar Andy Rubin, who testified yesterday, didn’t think so, reports VentureBeat:

Rubin, who began working on building Android in 2003, said in court yesterday that while Android was being developed, he was under the impression that key Java APIs were protected by copyright and that Google would need to work with Sun or license the technology from Sun in order to make Java for Android work.
Oracle lead attorney David Boies asked Rubin specifically if Rubin thought Google needed Sun’s permission to use the java.lang APIs, and Rubin answered in the affirmative. [Emphasis added]

Executives from both sides of the aisle have contradicted themselves and their respective company’s positions in the courtroom more than once. There are some historically unique aspects of this case given the players and the ubiquity of the products involved. Nevertheless, a decision on this case could have broad consequences.

“I [am] turning over in my mind how we deal with the work as a whole issue,” [the Judge] said. Judge Alsup said he would tell the jury that copyright could extend to structure, sequence and organization of the APIs, and let the jury consider Google’s fair use claim in its deliberations.

If even the most basic APIs can be copyrighted, then conceivably any computer program would be a derivative of the language it was written in, through the APIs. Developers who didn’t want to pay for the language creator’s APIs could, and likely would, create their own APIs, but that would quickly fragment the language and the vital ecosystem around it. A step further, programming languages would become commercial, finished products as opposed to organically growing ecosystem of expanding utility through shared APIs.

Of course, the counter argument is that without the language creator’s stewardship, both through the language but also the APIs that ultimately make it useful, fragmentation becomes inevitable. This is not academic for Oracle/Sun which sued Microsoft a decade ago over “Java compatibility” and ended up settling favorably.

Just to illustrate the messiness of the API copyrightability issue, consider the little known Y Combinator startup 280 North, started by former Apple engineers. Perhaps better known as the creators of the Apple Keynote clone 280 Slides, the company developed a language (Objective-J, a clone of Apple’s Objective-C) and a set of frameworks (“inspired by” Apple’s Cocoa). Their product Cappuccino, was “a re-implementation of Cocoa in Objective-J, which means we reimplemented [Apple’s] AppKit, Foundation, CoreGraphics, and parts of CoreAnimation” explains one of the founders.


After having raised only $250,000 in angel money in 2008, somewhat inexplicably, 280 North was acquired by Motorola for $20 million in 2010. It hasn’t been public what exactly Motorola got in terms of talent vs IP in the deal, but Motorola, in turn, was recently acquired by Google. So today, Google owns a “re-implementation” of Apple’s crown jewels Objective-C/Cocoa for the web.

Think of the possibilities. In a courtroom.

5 thoughts on “For whom the API tolls?

  1. We’ll find out in the next day or two about API’s and copyrights once the jury comes back with the results of their deliberations in the oracle vs google suit. I think? The case seems pretty straight forward for the most part except for the JS weirdness. In retrospect, oracle should have kept him on board for a while longer.
    On the equally strange objective-j, are you saying that if java goes down the tubes for google that google might find itself better off just switching to it’s rip-off of Apple’s cocoa?

  2. So good to have you writing again on this site; I’d put you under “check once in a blue moon.” After all, nothing till now since February of last year.

    I follow a number of tech writers, yet find so few that write cogently, with clear and compelling insight into their topics, not just regurgitating another writer’s work or restating the obvious.

    Your insight is always fresh and gives me pause to rethink or think anew. That makes it worth waiting for that blue moon.

  3. Oh, I forgot about Cocoa.
    GnuStep was strict OpenStep clone
    but then it has continued to copy new Cocoa APIs
    without Apple batting an eye. Apple even allowed
    Obj 2.0 to be integrated with gcc 4.6.
    WebObjects has several clones.
    EOF as well. I am sure there other IOS API
    Microsoft has copied wholesale in their Window Phone.

    • As I indicated above, just how far this API copyrightability issue can impact any industry reliant on digital computing is hard to imagine, since derivations are so deep and pervasive.

  4. Software programs are copyrightable.
    Code is copyrightable.
    Design is copyrightable.
    Yet Language and API is not copyrightable.
    Even GNU allows copying of headers for sake of compatibility
    but Java has no need for compatibility where as
    LibC needs to compatible otherwise you would still be paying
    AT&T and have no compatibility.
    But then again Fair Use and EULA complicate the matter.

    So it just comes to whether clean room implementation
    is really allowed for example BIOS which definitely had API
    but IBM was unable to stop it.

Comments are closed.