So am I right in understanding that Oracle winning this case would basically destroy the ‘clean room’ design technique?
If so, Oracle simply can’t be permitted to win, as the ramifications would be disastrous to the entire IT industry.
Wait a minute… I implemented java.util.List yesterday… Do I need to call my lawyer?
That’s the scary part: if Oracle wins, where do we draw the line? What’s the difference between implementing a bunch of interfaces and implementing an entire API?
We could come up with some arbitrary limit, but keep in mind that Android didn’t implement nearly 100% of the API, so… where is the line?
No matter where you draw the line, it seems a bit arbitrary and draconian in a way that limits stuff that’s at the core of software development and Java itself.
This contains the notes of the Supreme Court and all the arguments being exchanged, which becomes quite an interesting read, starting with document page 7.
It concludes with that the Supreme Court does not want to decide the verdict and delegates to a subordinate instance.
The legal and tech implications are already basically covered in this thread…
Ethically, making it first open source and then suing someone for seemingly using it appropriately, means one of two things:
A) They didnt image this usage - Seemingly impossible and or very stupid
B) Their behavior was inconsistent, meaning a change of heart. Which means first they were ok with it and then, considering the circumstances they were not anymore, or realized they could sue.
And the second one is not really defensible ethically imo.
I’m not 100% informed on this issue… If SUN open sourced it and THEN was bought and Oracle disapproved it makes more sense at least. Not that I would approve tho anyway.
Off the topic of this thread…but that’s exactly what they didn’t do. They cut corners and actually did violate copyrights. This was demonstrated by the internal memos. An important part of US law is intent and they stepped over the line and the completed system was not clean-room.
The notion of being able to copyright an API, esp. a publicly available one, is stupid. But then again likewise for software patents. Well and a huge list of other current laws in pretty much every country on the planet.
I still can’t understand how Oracle won in the higher courts after it was established that Google:
-Didn’t violate any patents.
-Did do a clean room approach besides a small number of methods’ code that the lower court judge said was ‘overblown’ by Oracle.
-It has been established in past cases that API’s are not copyright-able.
As Cero made clear, morally and from the point of view of a lawyer’s “reasonable person”, open-sourced software is fair game to be copied.
It’s bizarre that the US courts are allowing API’s to be copyrighted.
What’s the point of an object-oriented language that allows inheritance if you can’t copy the API to inherit the methods :clue:
EDIT: By the way, wikipedia has a good run-down of the case:
https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.
Ah ok, I wasn’t aware that Google used Apache Harmony’s java implementation in android, I thought they used OpenJDK.
This case seems to link back to Sun’s refusal to grant Apache Harmony the TCK. Apparently they only wanted it to be given to GPL’ed java code.
Still, this is an unusual step for API’s to be copyright-able. It’s a break from past cases and norms. Copyrights last much longer than patents.
There is some conflation here about the use of a copyrighted API versus the distribution of a copyrighted API. There’s never going to be a way to stop people from linking to copyrighted APIs so we can all rest easy about that, because that’s exactly how APIs are meant to be. The issue is that Google are redistributing a copy of the API which appears to be a 99% verbatim copy of a significant body of original work.
Cas 
At which point your argument breaks down because the case has nothing to do with it being open source, but if it had been that Android derived from OpenJDK this would have been using it inappropriately, in that Google has no right (ethically or legally) to change the license.
There’s a reason Java ME is GPL without the classpath extension. And likewise, a reason that the ARM version of HotSpot isn’t open-source. 
I really don’t see how APIs can be copyrighted; they’re not an expression of an idea, they’re a document describing an idea. The expression of the idea is the implementation itself.
The parallel is patent submissions; they too are documents describing an idea, and sensibly they are (by default at least) not subject to copyright.
Of course an building an API is creative work. Building a good API requires thought, experience,design, and interaction with the millions of API users. Sun/Oracle have spent many thousands of hours getting the API right independently of the (far simpler) work of actually implementing the methods.
- Documents can be copyrighted - it does not matter what the content of the document is. If the contents are substantially copied into another document, you’ve copied it, and if you don’t have the right to make a copy of it, you’re in breach of copyright. This much is simple to grok.
- I very much disagree that an expression of an idea is not itself an idea.
I suspect that the judgement will end up being something describing a level of grey between the black and white of “Google having done wrong” and “Oracle having no rights”. The scale of Google’s wrongdoing will be taken into account; and thus a decision could be made that will, yes, make copying copyrighted APIs a breach of copyright but only when the scale is deemed to be substantial. Something like the protections people have when using samples, or excerpts from novels - you can get away with a certain amount of lifting but at the point you take someone’s work in its entirety or even a substantial amount of it - you risk being sued for breach.
Cas
I agree with @ags1 and @princec. In quite a lot of my code, particularly the public facing API’s, often more work goes into creating the API than into its implementation. Individual method behaviour is defined by the API, and individual method implementations can often be trivial. It is the API that defines the process and therefore the API that is the expression of the idea. Actual code is “just” an implementation detail.
…but processes are not subject to copyright.
If Oracle’s current claim is that Google copied portions of documents describing the API, then fair enough.
The breach is copying the documents describing the API, not copying the API itself.
If Google (actually Apache~Harmony) had extracted the APIs from rt.jar, I think their ‘fair use’ defence would be stronger.
The US really needs to add an interoperability exception to their copyright law…
Well… I don’t know that they do need to add an exception. There are whole businesses that are based upon licensing interopability, predicated on the fact that it takes a huge effort to define an interface and someone’s gotta be rewarded for that effort.
My personal desired outcome? Oracle and Google settle out of court. Google pays Oracle a reasonable license fee, and in return, get proper Java for Android. All problems solved.
Cas
Much as I dislike quoting Wikipedia
[quote]copyright for computer programs prohibits not only literal copying, but also copying of “nonliteral elements”, such as program’s structure, sequence and organization. These non-literal aspects, however, can be protected only “to the extent that they incorporate authorship in programmer’s expression of original ideas, as distinguished from the ideas themselves.”
[/quote]
What I’m saying is that an API could embody all of the expression of the idea, where the implementation of each individual method (the code) is trivial / only expressible in one form and therefore can’t be copyrighted.
Surely it’s quite the opposite though; the API can only be expressed in one form, a precise set of class, field & method signatures.
If any deviation from this precise set is made, the function of the API changes and is no longer compatible.
While the API as a whole is complex, it is also in its simplest form, as it cannot be expressed in any other way without changing its function.
Just as a trivial method body cannot be copyrighted (there is no other way of implementing it), an API cannot be copyrighted because it too is in its simplest expressible form & cannot be constructed in any other way while retaining compatibility.
That’s not the point… the point is it can be copyrighted. Just because it can only exist in one compatible form does not mean you have the right to distribute it.
Cas
That’s a tautological argument. The process(es) which the API expresses could be expressed in another form as a different API.
And documented behaviour! Without that the API is pretty much worthless. With that, in particular in the specification of behaviour between components, you start to get the expression of the idea (IMO).