Hacker News new | past | comments | ask | show | jobs | submit login

> Google admited several times that they haven't done a clean room reverse engineering

> It is undisputed that Google copied verbatim the declaring code of the 37 Java API packages—11,500 lines of Oracle’s copyrighted code. It also copied the SSO of the Java API packages. Google then wrote its own implementing code.

The only problem with Google's implementation is the copying of the API.

---

> If Google cared so much, they could have bought Sun, but they were expecting it would just crash and burn, while the company would get away with it.

> The parties were unable to reach an agreement, in part because Google wanted device manufacturers to be able to use Oracle’s APIs in Android for free with no limits on modifying the code, which would jeopardize the “write once, run anywhere” philosophy.

> in any event that the jury must have found that Google did not act in bad faith

Google tried to get a reasonable license.

---

Even CAFC has said that if Google had not received advertising revenue from Android, their use of the APIs would have fallen under fair use. They are not a Java vendor.




> They are not a Java vendor.

Last time I checked https://developer.android.com/ and https://developer.android.com/guide/platform/ has the word Java written all over the place.

So apparently they license an operating system, that makes use of Java, the language, and a subset of its standard library, to the point that it affects the sales of other Java vendors.

On my naivety it makes them a Java vendor to me.


Strangely I can only find 'Java API'.

> The entire feature-set of the Android OS is available to you through APIs written in the Java language.

> Build toolchains, such as Jack, compile Java sources into DEX bytecode, which can run on the Android platform.

Seems they make no use of the JVM... Which would be required to vend it, no?


A JVM is only one possible implementation of the Java language.

A few Java vendors on the embedded space also provide their own implementations, where .class files are converted either into their special VM format or straight into native code, before generating the firmware image for deployment.

Android uses Java the language, alongside a partial implementation of Java the standard library. The way it is implemented, is like any other programming language, a detail.

The fact that I can pick any Java library that compiles under that subset and use it on Android is expected by any Java developer.

Likewise embedded vendors that sell C compilers, even if they aren't fully ANSI C compliant, still acknowledge they are selling C compilers.


You seem to be confused on a few points.

The court case is that Android infringes on Java SE, not the Java language. The question is if it infringes on the platform, not the language.

> Android uses Java the language, alongside a partial implementation of Java the standard library

That's not what is being disputed. They use an API written in Java, afterall.

> Likewise embedded vendors that sell C compilers, even if they aren't fully ANSI C compliant, still acknowledge they are selling C compilers.

And Android has a compiler for Dalvik and AR. That's not up for dispute either. That doesn't make them a vendor for Java SE. No more than the compiler in GCC makes the GNU project a vendor.

> A few Java vendors on the embedded space also provide their own implementations, where .class files are converted either into their special VM format or straight into native code, before generating the firmware image for deployment.

Usage of the Java brand requires any platform you ensure compatibility between your implementation and all other implementations [0]. The Android SDK is not compatible to the letter of that trademark license, as the Android SDK is both a subset, and also extends the Java API, so Google followed their license by not claiming it.

---

The only thing being disputed, is if their Java-written API is allowed to reflect Java SE's API.

Google is a library vendor for a library that reflects a subset of the host language. They also have their own compiler for a subset of the language.

> Likewise embedded vendors that sell C compilers, even if they aren't fully ANSI C compliant, still acknowledge they are selling C compilers.

This is more akin to claiming that a C++ compiler is infringing on a C compiler by both being compatible with a subset of the C language.

[0] > This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft implementation did not support RMI or JNI and had added platform-specific features of their own. Sun sued in 1997, and, in 2001, won a settlement of US$20 million, as well as a court order enforcing the terms of the license from Sun. As a result, Microsoft no longer ships Java with Windows.


Fact, Google ships an operating system with the userspace written in Java the language, making use of a subset of Java standard library.

Fact, Google created a schism on the Java compatibility story by only providing a subset, thus forcing Java developers to write Android specific libraries.

Fact, if Google actually cared about Java they would have bought the Java assets from Sun, after helping driving them to the ground, as they were aware Sun was short on cash and would never sue them.

Now we can all enjoy a broken compatibility story up to Java 8, while Java 10 is out there and the distance will only increase.

Android is just as bad for Java portability as J++ was.

But hey, it is the nice "do no evil" corporation against the big bad lawyer corporation.


I don't know what your problem is, and I don't know why you believe certain 'facts' that have never been presented at trial, but would clinch the case against Google.

I'm tired of reading legal documents to answer your complaints. You can read yourself, or continue ignoring the court case. Adios.


My problem is that Google just played a Microsoft, forked the Java eco-system, but because it is the beloved "Do no Evil " company of SV, it gets love support like yours instead of the hate Microsoft did exactly for the same result, while we Java developers have to workaround the fragmentation issues Google has brought into the Java world.

My problem is that I cannot pick any random Java library out of Maven and be 100% assured that it will run at all on Android.

My problem is that Android most likely will never move beyond its partial implementation of Java 8, as per Android P.

If it was for Google's wishes, Sun would have closed doors, hopefully no one would have bought the Java assets, they would get away with it, and we could all enjoy a Java language stuck at what was Java 6's subset.


> My problem is that I cannot pick any random Java library out of Maven and be 100% assured that it will run at all on Android.

You need to stop thinking of the Android SDK as Java, because it isn't. It has Objective-C to C similarities.

It doesn't have API compatibility, or bytecode compatibility or even the same class constructors.

Thinking they're pretending to be the same is going to cause nothing but frustration, and hurt you. It'll irritate and chafe more every time you have to touch that god-awful ecosystem.

> it gets love support like yours instead of the hate Microsoft

No Google does not get my love, I have ranted against their practices for years. This conversation has been about legalities, not ethics.

They suck as a company - but we have ecosystems built around compatible APIs, a legal precedent here would be awful for everyone. (Firefox's new extension API, the entire JS ecosystem, etc.)


> You need to stop thinking of the Android SDK as Java, because it isn't.

That is exactly my point, Google has broken Java's compatibility story, regardless if they have found a legal loophole to get away with it or not.

Objective-C and C are two completely different programming languages, where Objective-C is a superset of C. Any C compliant code is compilable by an Objective-C compiler.

It is not the same as what Google has done to Java.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: