I'm on Oracle's side dogmatically because I think there's nothing in the law that says they can't copyright an API.
I'm on neither side personally because I think this whole case is a massive failing by the law to adapt to new use cases.
It's not clear to me why one copyright would be legitimate and the other not.
I mean, Google clearly wanted to build something similar in many ways to Java and, honestly, did _not_ do so for trivial "interoperability" purposes (which is the most common defense of what Google did, as "interoperability" has often been used as a successful defense of fair use and even has many explicit carve outs and exemptions in the DMCA) as existing Java software did not work on their implementation and they didn't _really_ care (and in fact benefited); the best part of the lawsuit to me was when Google's lawyers failed to find even a single Java program that could run on Android when challenged by Oracle.
> District Court noted that Oracle in essence was arguing that Google’s interoperability argument would have been stronger if Google copied more--the structure of all 166 Java API packages--rather than just 37.
https://www.law.berkeley.edu/wp-content/uploads/2015/09/Jona...
I mean, this is just "good TV", and doesn't lead to a situation to me where anyone is "obviously correct" to me given either the law or the current precedent. At the end of that PDF, the case of Lotus v. Borland is brought up, where Borland had a menu variant compatible with Lotus 1-2-3 for their Quattro Pro. Is the API of a programming environment more like this kind of user interface (which was left without a national precedent as it _split evenly_ at the Supreme Court level: four to four with one recusal) or more like the API of the IBM BIOS that had to be replicated by Compaq (which _was_ considered to be copyrightable)?
I really feel like most people are largely on Google's side for, as you state, "professional" reasons, as it causes all of us issues if it turns out that Google wasn't allowed to do this, as we all _like_ being able to build something "kind of similar to what this other person built but not compatible enough so that our use is neutral". Imagine if this got applied to protocols... what kind of effect would that have on the web? Oracle has also been so classically evil--and there's still this residual delusion that Google isn't--that I think we all have blinders on with respect to whether they might be right.
Does anyone really thing Swing, or PersonalJava, or MIDP on phones, or even JavaFX, was going to compete with iOS?
The whole write-once-run-anywhere promise of Java is a sham. Any non-trivial professional Java app, used some non-portable APIs. Take the popular ones like Limewire, or IntelliJ, and they end up on each platform, hooking into MacOS, Windows, et al, specific APIs that require JNI code.
" Imagine if this got applied to protocols"
That's exactly what happened since the 80s. Do you know how many versions of IMAP there are if you count the extensions? Or Jabber? The internet was built on "rough consensus and running code". People shared code and ideas freely. That's what built the net.
Copyrighting APIs with 100+ year time spans is INSANE.
> That's exactly what happened since the 80s.
You managed to invert my paragraph somehow :/. Imagine if [this: the idea that APIs are copyrightable] got applied to protocols... that would be horrible, and would have had massive (negative) impacts on the web; this categorically did not happen "since the 80s".
Therefore, paying no attention to the law or the precedent or even the facts of the case, we all have this visceral reaction to the idea behind this lawsuit and want it to be decided in a way that feels like it works for us... but maybe the issue is that the law is broken.
> Copyrighting APIs with 100+ year time spans is INSANE.
I would argue copyrighting anything with 100+ year time spans is INSANE. The idea that developing and distributing techniques that even merely help people copy things is illegal (a la Section 1201(b))... the issue is that this entire area of law is INSANE :/.
Well this is copyright law and not patent law but my understanding is in patent law they've already established things like obvious plug designs cannot be patented. If we assume the same is to be said for code you easily argue that to keep compatibility for any given method signature, the reimplementation method signature is obvious.
Google has shown that they did not copy the bodies verbatim so its down to the API. There happens to only be a single way to write the method signatures of a compatible method.
That's not actually true. For example, all of the following method headers are compatible:
void foo(int a) throws Exception
void foo(int x) throws IOException
void foo(int index) throws RuntimeException
Sure, this is a technicality, but it is not completely irrelevant.However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android.
Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying.
>However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android.
The vast majority of Java code runs on perfectly well in Android. APKs are packaged differently than JARs but that's a different discussion.
>Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying.
This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement.
Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around.
> The vast majority of Java code runs on perfectly well in Android.
The vast majority of Java applications use features not available on Dalvik, ever-changing though the vast majority of their code would indeed run.
> This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement.
They did a clean-room implementation by looking at the specification of the Java API. They did not reverse-engineer the API from working programs or from decompiled binaries, and are not claiming that they did. If they had, you would have probably seen minor differences in parameter names, thrown exceptions and a few other places.
These are public classes and third party code will have overridden the original exception and not your subtype. This would break compatibility. You cannot change the types of these signatures in either direction.
What I think would make most sense is to allow APIs to be copyrighted, but to enshrine a specific fair-use exception for interoperability. If that were granted, WINE and other emulators would be allowed to copy Windows' API under that fair-use exception, whereas Google would still not be allowed to do what they did.
And that's essentially what Google did - made a partial implementation of the API. I don't see a good way to rule that Google use was protected but other not 100% complete implementations are.
The Trump Administration. (They've filed, AFAIK, the only amicus brief supporting Oracle in the case. I would think they count as a major player.)
I don't believe that this will be massively disruptive to the industry.
I think it's unfair that Google or anyone should have to pay anyone for doing something that was no clearly unlawful and the gov. should also step in and clear up the legality of these things. Clarity on these matters will help everyone, everywhere, except lawyers.
I do not believe that the adversarial justice system is remotely the right place to be making these decisions.