Hacker News Reader

Comment by Silhouette | Hacker News Reader

There is no expression of creativity and it is fairly mechanical.

I disagree. Designing a good API is one of the most difficult skills to acquire in all of software development. If creating a good API were "fairly mechanical" then the world wouldn't be full of crappy ones, and we'd all rejoice permanently in the comforting glow that comes from writing code against an API written by someone who gets it.

Despite this, I strongly believe that APIs should be excluded from copyright, for the same reason that I support the US exclusion of fonts. Some things are too important to general communication and creativity to allow any individual to have exclusive control over them, and they demonstrably can and will be created without needing that incentive to make them economically viable.

View on HN

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

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.

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.

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"

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

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.

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.

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

For a good API I'd agree with you that it's a difficult skill to learn. In the case of java I would say that "no expression of creativity and it is fairly mechanical" is a fairly apt description.

I can agree with parts of it, but I still think Google should pay Oracle for licensing Java. They copied the entire API so they could leverage the entire Java ecosystem, I think that's quite unfair to Oracle. Oracle is not suing microsoft for implementing their own .NET VM.

What does it mean to "leverage the entire Java ecosystem?"

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

Okay, but Oracle doesn't own the talents of everyone who knows Java, and has nothing to do with Eclipse.

Do K&R collect massive royalties for all the operating systems written in C? Does Oxford demand licensing fees from speakers of English-derived dialects? Most of the words ("APIs") are the same.

They did create their own VM -- Dalvik.

Sort of -- but not in the same sense that the .NET CLR is MS's own VM, with its own unique bytecode (MSIL code).

Dalvik compiles ("dexes") Java bytecode (most of which, except for Android-specific libraries, would run on any JVM) down to Dalvik 'bytecode'.

It's honestly not that different from what the MSVM tried to do. The main difference, it seems to me, between the MS/Sun lawsuit over the MSVM, and the Google/Oracle suit, is that 1) Google did implement the entire JDK -- they simply added more proprietary libraries that can't run on a conventional JVM and 2) MS had a binding agreement with Sun.

If Google wins (and for the record I'm on their side of this completely), my question is -- does that mean Microsoft didn't need that license agreement with Sun to begin with -- the one signed in 1996 that eventually caused the downfall of J++/MSVM, and the birth of .NET?

That would be an interesting turn.

AIUI the main problem with Microsoft's implementation was that they were calling it "Java" with the implication that it was compatible.

So asking for forgiveness and not permission would work out for Google? I don't see how that can work, the only way is if API's are not copyrightable, which will be up to the judge and not the jury.

Again -- and this probably works in your argument's favor -- MS did implement a JDK under a license agreement with Sun, and then violated that agreement by corrupting the JDK specification with incomplete/missing pieces.

MS didn't start work on the .NET VM until they had to abandon their corrupted Java VM under a court order -- the whole reason C# and .NET exists in the first place instead of J++ and the MSVM.

"They copied the entire API ..."

They are using Apache Harmony. Ask Oracle, they will tell you it is not Java.

Oracle/Sun couldn't sue MS for their VM because .NET has nothing do due with Java except some common high-level architectural strategies (bytecode/msil, GC, VM, etc.) that neither company has exclusive claims on.

In fact the .NET VM came about as a direct result of the fact that Oracle(Sun) did sue Microsoft for incompletely implementing the Java JDK under a license agreement between them, and MS had to abandon J++ and started work on C# to replace it.

http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit....

I don't even think they should be excluded because they're important, but simply because they are required for interoperability, which can never be made illegal anyway.

...exclusion of fonts. Some things are too important to general communication and creativity to allow any individual to have exclusive control over them

I realize we're getting off-topic, but I'm curious how that follows. It is certainly important for people to have access to some typefaces, but if fonts were copyrightable there would still be some public-domain ones for people to use. Why is it important that people be able to use "premium" typefaces?

The problem is where you draw the line. All typefaces based on a western alphabet are ultimately going to be somewhat similar, because the shapes of the letters are what they are. The differences between many typefaces' designs are subtle at best, and frankly little more than typographic snobbery in some cases. Given that copyright applies not just to the original work but also to derived works, if you allow the basic design of a typeface to be protected then you are in danger of covering not just the design of the typeface but the entire medium of written communication.

That said, "premium" typefaces in common styles (geometric sans, transitional serif, etc.) tend to be premium mostly because of all the detail work beyond the basic shape, such as hinting and kerning. Since that work is part of the implementation font file rather than the design, AIUI it can still be covered by copyright even in the US.

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.

Reply on news.ycombinator.com