Oracle v. Google judge to decide whether APIs are Copyrightable, not the jury

Is this rangecheck() function that we're debating critical to the Android platform? Is that the feature that made it so popular? Clearly not, or Oracle would have made smartphones already. I'm curious as to how many different ways a range check function can be written in Java. Can we reasonably expect Bloch to re-implement his own code in a slightly different way? Should Google have diff'd Android source against Java source? What does Open Source mean to you?

    private void RangeCheck(int index) {
    if (index >= size)
        throw new IndexOutOfBoundsException(
        "Index: "+index+", Size: "+size);
    }

If this were the basis of Oracle's copyright claim, any judge in the country would have tossed the case on summary judgement.

I would argue that once an API is published and put into use, it becomes a list of facts about the interfaces in the program. You cannot change an API without undermining its entire purpose. In that sense, it is factual, in that the API class paths and signatures are effectively routing information between a client program and the API implementation. They describe the means by which you give data to a library and give data back.

An API may be entirely as functional (though not necessarily as usable) if no creative thought or effort goes into it. You could have all your API methods be called api1(...), api2(...) and still have them function. Creativity and skill are a very useful component in making APIs, but I would argue that they are not requisite, as evidenced by the dearth of uncreative APIs created by unskilled programmers who have still managed to create libraries and services that we use on a daily basis.

>An API is not a compilation of facts, though. The specific names in an API and their relationships to each other seem like a creative work.

The trouble is that it is a compilation of facts. "There is a function in Java called lastIndexOf in class java.lang.String that takes int as argument and returns int." That's a fact. The formal specification of that fact is "public int lastIndexOf(int)" -- that can't be a creative expression of the fact because it's the only way you can formally represent it to the compiler. The language mandates that expression; you can't alter it so there is no opportunity for creativity.

Or to put it a different way, you might want to call it a creative endeavor to lay out a city and name all the streets. But if the person who named all the streets then comes around trying to claim a copyright over an independent cartographer's map of the city or the local phone book because it contains all of the street names, I wouldn't expect much sympathy.

But I think the crux of it is this:

>Someone invented that.

Exactly. Software development contains both engineering and creative components. The functional components are patentable (in countries like the US that have software patents). The creative components are copyrightable. But the API is strictly functional -- if there is any protection for it, it's in the domain of patents. You can call inventions creative all you like, but you can't copyright function.

I believe bringing the concept of a fact into question will do more harm than good. A phone book is _not merely_ a set of facts, but also a set of agreements. Surely one can look inside the phone and disagree with one's own listing. If one were to dive into an API and find that it mistakenly calls an undefined function, or typos abound, in this case the API would need to be changed because it has become less functional. It may be rendered useless. A phonebook cannot be rendered useless if even all the numbers are incorrect; though I doubt such a philosophical argument need be presented (Sorite's Paradox).

My goal here is to understand the analogy that is being made. True, one could development algorithms from a phonebook such that bank robberies and pranksterism may take place. This possibility secures a conceptual machinery for viewing a phonebook and an API as conceptually similar, since such practices would likely presuppose a concept of hierarchical relationships between numbers and names in the book, assuming sophistication. However, such practice is not the intent behind the phonebook, and so further a concept of hierarchy is unnecessary essentially to the phonebook. An API depends on some basic conceptual metaphor (@see Metaphors We Live By by Lakoff and Johnson to grok the sense in which I use "conceptual metaphor") of:

A FUNCTION IS INSIDE A CLASS

(I do not count sorting or grouping concepts in a phonebook as "hierarchical.") And this concept is essential to the working of the API. So I believe the comparison is unfair, if not misleadingly true (that APIs and phonebooks are compilations of facts) when thinking of phonebooks whose institutional facts are conceptually nearer, by analysis, in proximity to their brute facts (those facts to which no other facts are necessary to ground their truth). An API and a phonebook are compilations of institutional facts, and should be compared only if the structures of those facts they assert are grounded in relevantly similar conceptual spaces (the institutions wherein those facts are true).

Developer tools (eclipse), libraries, developers trained in Java, Java training. Just some of reasons they did not create their own VM like Microsoft.

Ah. Even if, say, the original Times was copyrighted, it would have long expired by now. That's why I don't see any harm in having (reasonable-length) copyright for all typefaces of the last century or so.

That's only valid in the UK. The Oracle vs Google trial is taking place in the United States where the KJV bible is most certainly in the public domain.