[josnyder]

API design requires much skill and foresight. As you said:

Designing a good API is one of the most difficult skills to acquire in all of software development.

However, the yardstick for copyrightability remains creativity (among other things). Some tangible work that was formed by the "sweat of one's brow" is not necessarily copyrightable, unless it was done creatively by the sweat of one's brow. Feist v. Rural [1] is the common case to cite here, where it was decided that telephone books were not creative, and thus not copyrightable, despite the effort that went into creating them.

[1] https://en.wikipedia.org/wiki/Feist_v._Rural

[othermaciej]

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. There is no pre-existing fact that requires, for instance, that java.lang.String has several overloads of a lastIndexOf method that take the particular arguments that they do. Someone invented that.

It may be that APIs are not copyrightable subject matter, or that there is some general defense based on fair use or interoperability, but I don't think it can be argued that creating an API is not a creative act.

[AnthonyMouse]

>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.

[uxp]

This makes me think of WINE. WINE takes the direct API, as in all the doSomethings(), and rewrites how it does that thing to work on a different environment than the original API call intended it to do. In the end, it may have the same exact or near exact result, but it does it in a completely different way.

I'd fear that if Oracle wins here, a huge number of open source projects like Wine and even the Gnash Flash alternative would find themselves under attack when they had previously been determined outside of court to be legitimate and fair uses of an API reimplementation.

[AnthonyMouse]

Absolutely. I mean forget about WINE, what about SQL? Recall that SQL originally came out of IBM. It kind of makes you wonder whether Oracle's lawyers have thought this one through.

[cheald]

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.

[jimmyvanhalen]

According to Joshua Block, Google's Chief Java Architect. (slide 62 and 63)

“I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life.”

"API design is a noble and rewarding craft"

"API design is tough"

[nerdfiles]

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).