I don't think it would be infringement. The main difference between WINE and Android is where the interoperability integration points are.
WINE is using the Windows names for the purposes of allowing Windows programs to run. This is a case where a judge would easily grant fair-use because you have to use the API surface area to provide compatibility for existing programs.
Android is using the Java names for the purposes of allowing existing Java developers to be productive, not so that existing Java programs can run.
>I don't think it would be infringement. The main difference between WINE and Android is where the interoperability integration points are. [...] Android is using the Java names for the purposes of allowing existing Java developers to be _productive_, not so that existing Java programs can run.
>Since Oracle's claim is that Google's use of the Java APIs wasn't to provide compatibility to existing software written in Java but to have a _familiar_ language for Java developers it becomes a novel but normal copyright case.
You're making a distinction between "interopability" and "end user familiarity". But Lotus also sued Borland on the basis of "familiarity" of the menu "names and structure" and they lost. The Supreme Court's 4-4 split decision left the lower appeals court's ruling intact.
It's not just about "developer interoperability" vs "program interoprability". Implementing Java APIs means that entire libraries can run.
Sure you might not be able to take a legacy SWING Windows Java app and run it on android, but you can run entire libraries in your android app. It absolutely _is_ about interoperability in both cases. Perhaps to varying degrees
Correct, and I was always surprised that Google didn't argue this point more. In my Android apps I've used Java libraries that were created years before Android even existed, and they work perfectly. And vice versa; I've reused code I originally wrote for Android in a Java desktop app with zero changes.
There is actually, and the court argued as such: if Android had been compatible with Java programs, Google could have claimed a fair-use exemption. Since Android can't run many Java programs, by design, they can't claim such an exemption.
WINE could very likely win a legal battle through claiming a fair-use exemption (of course, if the case fails, they wouldn't have to go to court at all).
Why is the distinction between "runs with zero changes" and "runs with minimal changes"—or even just "runs with fewer changes"—so critical?
Where is the line? Is Android "compatible" with Java programs if those programs need to be recompiled first, but no source edits are necessary? What if source edits are necessary, but can be automated? What if recompiling isn't necessary, but you need to hex edit the binary?
"Compatibility" is a spectrum, and I'd say Android falls within that range.
Because the actual implementation isn't what the courts are looking for. This is a case about Google's intention for copying the Java API. Oracle is claiming that Google copied their API because it was easier than designing a new language; Google is claiming that they did it for interoperability reasons.
There is no distinction between the two because these things are presented as evidence of Google's intent, it's not proof. There's no line. Google's case would be much stronger is Android-Java could run most Java software unmodified but it doesn't mean they'll lose just because it's not true.
Thanks, that's interesting! It seems reasonable—if Google was explicitly trying to enable compatibility, that should be allowed, whereas if they were just trying to save a buck, that should be illegal.
Of course, in reality Google's decision was probably a little of both, right? They selected a technology based on a wide range of factors, including development costs and compatibility.
I'm still concerned that a decision in Oracle's favor would have a massive chilling effect on everyone else. All companies want to limit their potential liabilities. How can you prove in advance that you selected a language or API for the sake of compatibility, even when that is in fact the driving factor?
> Of course, in reality Google's decision was probably a little of both, right?
I wouldn't think that Google's development costs were part of the decision. There aren't that many Java APIs -- as the article says, it's ~11k lines of definitions -- so Oracle is seeking ~$818k per line. Assuming Google's lawyers predicted that there was some risk of a lawsuit like this, any engineering costs associated with redesigning the APIs would just be negligible compared to the legal risk.
One could argue that it is quite difficult to design a good API, but Java's APIs are frankly full of mistakes: Date/Calendar, immutable collections with no type safety, "optional" methods like Iterator.remove, etc. It wouldn't take a team of world-class engineers to come up with something better with the benefit of hindsight.
On the other hand, developer familiarity and compatibility with existing Java libraries could have had a significant impact on Android's adoption. I think that was what justified the legal risks.
> "We've been over a bunch of these, and we think they all suck," Lindholm wrote. "We conclude that we need to negotiate a license for java under the terms we need."
> This is a case about Google's intention for copying the Java API.
Not centrally. The copyrightability issue is absolutely not about Google’s intentions (and if Oracle loses that, it's game over), and Google’s intentions are relevant to one half of one of four fair use factors (the “purpose and character of use” factor) which are weighed together (it's not a pass-fail each factor test) in the fair use portion.
Wine makes programs written for Windows work on Linux. The key difference is that Linux is an independently developed system. The extent that wine copies Windows code is limited to a compatability layer. It doesn't transform Linux into just a copy of Windows.
In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.
Didn't they though? They've had their own vm and bytecode for as long as Android has been released. The use of Java is for making libraries compatible.
If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay?
How would such a programming language be detectably different from being an implementation of Java?
>If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay?
Yes
>How would such a programming language be detectably different from being an implementation of Java?
It would have it's own unique API. As an example, Ruby can run on the JVM via JRuby and it's clear that Ruby is a different language than Java.
In this example Google independently developed a language and made it compatible with the JVM.
In the real world Google wanted Java and didn't like the licensing terms. So they copied the Java API and from that starting point built out their own version of Java.
Developing a programming language does not give you brownie points with a judge, and has no bearing on the matter.
What you are suggestying is copying the binary API instead of the texual one. It is equally the subject of copyright.
In the real world Google deleoped their own equivalent of the JVM, which uses different bytecode. This is technically more difficult than putting together a language. But that has no relevance to the subject of copyright.
But "making it compatible with the JVM" would involve implementing the Java standard library, right? Recognizing terms like "java.lang.String" or "java.lang.Math.max" and doing the right thing? To do that, aren't you creating a copy of the Java API?
Strange, in hardware land I thought that a clean-room reimplementation of something (where you make something with the same interface -- the API of the hardware) was legal.
Only if the clean-room re-implementation was properly done with separate teams, proven in court that both teams never had any contact with each other beyond written specification architecture documents.
But one of the reasons Android chose Java was for compatibility with existing Java software. It was code rather than binary compatibility, but I'm not convinced that's a meaningful distinction.
I mean, a programming language is fundamentally a set of instructions that produces output, right? So, a Java programmer writes `System.out.print("Hello")` and the Java implementation does the work to make "Hello" appear on screen. Similarly, a Windows executable running via Wine will tell the Windows API to print "Hello", and Wine will do the work to make that message appear on the screen.
> In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.
This isn't an argument that has been made in court in anyway, and Google's use of the Java language hasn't been questioned.
Google could have used the Java language with completely different APIs (google.lang instead of java.lang for example). It's the APIs that this case is about.
Also, the key analogy is wrong anyway: while Android used java.lang and java.util and other related APIs, the key functionality of the phone was accessible via custom APIs that aren't copied. Note that the "interoperability" argument was lost by Google because of this exact thing.
> Google could have used the Java language with completely different APIs
Well, no, because many Java language constructs are defined in context to the standard library, for instance all classes being children of java.lang.Object. They'd need quite a bit of java.lang at the very least.
Which even after their adoption of OpenJDK still isn't compatible out of the box with the standard library available at https://adoptopenjdk.net/
In 2020 it is still pretty much hint and miss getting a Java library working without changes on Android, given that the Android team cherry picks whatever they feel like from OpenJDK for their own Android API implementation purposes.
Easily to find that out from Gerrit commits and AOSP source code.
Meanwhile, effort has been spent ensuring that 100% of ISO C and ISO C++ are available on Android NDK.
Thus out of the window goes the interoperability argument.
Nothing happens to the interoperability argument. Nothing says it need to be 100% interoperable, or else you wouldn't be able to ship an MVP for any reimplementation of an API. And hell, the official JDK isn't even 100% interoperable with it's past selves.
Maybe if Sun didn't play games with access to the TCK in the past we wouldn't be here adn there'd be a valid test for compliance that wasn't "do what the official JDK does".
Maybe if Google had bought Sun after torpedoing it, we wouldn't be having this discussion and everyone was enjoying a Go style management with Java stuck at version 6.
If Google didn't wanted to be sued (IBM would likely have done the same), their solution was to own Java instead of hoping that their torpedo would have sunk Sun's ship without a hiss.
I am not pivoting, Google has only itself to blame for their little J++ adventure.
"James Gosling Triangulation's Interview on Google vs. Sun"
Basically wanting Java as free beer, without paying Sun any money given that Java actually required licenses for handsets/embedded deployments in pre-OpenJDK days, in the not so good economical situation that they were, withdrawing them from possible Android license revenues.
That is torpedoing, regardless how Google employees, or wannabe employees play it.
Except Sun never charged for handset/embedded deployments. They charged for access to the J2ME trademark. This case is neither about trademarks nor J2ME.
That means they wouldn't have gotten any money from SavaJe like phones either.
The only people who "torpedoed" Sun was Sun themselves.
And yes, switching from an interoperabilty argument to 'they were morally obligated to buy Sun' is very much pivoting to a different argument.
I am very worried about this case.