I feel the judge will rule that APIs are not subject to copyright. There is no expression of creativity and it is fairly mechanical. I also think that if they are subject to copyright lots of people are going to get sued.
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.
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.
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.
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'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.
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.
“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"
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).
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....
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.
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.
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 are using Apache Harmony. Ask Oracle, they will tell you it is not Java.
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?
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.
“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"
Also, according to Andy Rubin (slide 73)
“Ha, wish them luck. Java.lang api’s are copyrighted. And Sun gets to say who they license the tck to, and forces you to take the ‘shared part’ which taints any clean room implementation.”
According to Google employee Bob Lee (Slide 72)
Q. Did you consult the Java docs when doing your work on the API implementations for Android?
A. Yes.
Q. Okay. And where did you obtain those Java docs?
A. They’re posted for free on Sun’s website...
Q. Did you observe any copyright notices on the specifications?
A. Yes.
Your overarching point that some things have false (or partially false) notice on them is accurate -- however the point that copyright law is subtle and often unclear in its details is equally valid.
https://en.wikipedia.org/wiki/Authorized_King_James_Version#...
http://en.wikipedia.org/wiki/Copyright#Public_domain
Here's a concrete example. Someone wrote a very successful book and it is protected by copyright laws. You may reproduce sections of it, but not the whole book. After X years have passed, and the book has passed into the public domain, you may reproduce it in full. You may not alter the work to credit yourself as the author.
Similarly, the crux of the matter is: does the Google version of the Java API constitute a derivative work that is significantly different from the Sun-Oracle version? As stated above, the UK and US do not recognize common law of copyright. So despite the fact that the Sun-Oracle APIs are publicly available, it does not allow Google to claim that the code that belonged to Sun-Oracle is free from restrictions and thus can be copied.
Sure one can. In fact, copyright has nothing to say regarding plagiarism. US copyright only prevents the copying of a work. I could claim to have authored Star Wars, the Bible, and your post -- copyright does not provide you recourse against this so long as I do not /copy/ them.
"The text is in the public domain but it is still covered by copyright."
No, it is not. Text in the public domain is not covered by copyright according to US law. Copyright ONLY applies to copies and incorporation into derivative works in the USA.
I apologize for being contradictory but you are completely wrong on both points here.