Oracle wants $9.3B for Google’s use of Java in Android(computerworld.com) |
Oracle wants $9.3B for Google’s use of Java in Android(computerworld.com) |
Edit: http://www.cand.uscourts.gov/wha/oraclevgoogle the original Alsup opinion
http://regmedia.co.uk/2014/05/09/oracle_google_appeal_opinio... The appeal opinion -- which, as it stands, rules that programming APIs are in fact copyrightable.
(Also, look at the list of counsel -- heavy hitters, damn.)
Oracle appeals from the portion of the final judgment entered against it, and Google
cross-appeals from the portion of that same judgment entered in favor of Oracle as to
the rangeCheck code and eight decompiled files. Because we conclude that the declaring
code and the structure, sequence, and organization of the API packages are entitled
to copyright protection, we reverse the district court’s copyrightability determination
with instructions to reinstate the jury’s infringement finding as to the 37 Java
packages. Because the jury deadlocked on fair use, we remand for further consideration
of Google’s fair use defense in light of this decision.Many judges probably do, every day, in lots of technically specialized fields, and we're just not paying attention because we're not experts in those fields, either.
Shouldn't assume our field is so much harder for judges to understand than medical, scientific, and other specialized fields judges need to weigh in on.
(interface)* = (class)*
(class) = (method_stub)* | (ivar)* | (class_var)* |(property}* | {delegate}* | {some_LINQy_constructs}* | {other_stuff_from_NETCLR3.5_onwards}* | ...
.
I.e. Azul ZING(tm) and the lot of insanely high-performance and/or hard-real-time-in-the-QNX-sense is priced at... a lot. In finance we used to use it because operations could be bounded deterministically. There was enough value in that that CTOs cut 7 figure checks to run that specific API implementation rather than use the Sun/Oracle JVM.
[1] Yep that's probably gobblydygook. My C# and Java meld together, I always confuse IEnumerable,IEnumerator,IDispose,and all the damn duals smash together in my mind, even worse now with Rx one more tensor rank was added (Time). Gods of the CoreCLR, smite me not. Also I'm not in PL design, forgive my bad BNF.
The java.* API is not even that good (it is very verbose to achieve basic things). The only reason to re-implement it is compatibility with existing, third-party software using that API.
If you would come with API, that would be technically better, but doing the same thing, do you think that everyone would rewrite all their libraries, frameworks and apps? No way.
The tack they are taking is to define any computer that does "one specific thing" as an embedded device and ask you for $300+ per "device", plus some other lofty fees. (http://www.oracle.com/us/corporate/pricing/price-lists/java-...)
So, if you're using Java in a kiosk, ATM, media player, etc, they may be coming for you.
My guess is that this just spawns a mass migration to OpenJDK, but perhaps they trap enough Java shops that it's worth the effort?
Not knowing when Oracle might decide to shake down your business is a massive incentive to use anything else.
I miss PJ and Groklaw, too.
Let's give Oracle 10 years from now to fade from relevance as yet another fucked by cloud vendor and Google can then orchestrate a hostile takeover.
P.S. Dart actually has a Java-to-Dart converter hidden somewhere. I can't find the link, but the static analyzer was ported from Java to Dart using it. Perhaps they could expand that effort?
:-)
Imagine if Microsoft granted Google a perpetual license to use C#.
http://www.wired.com/2012/04/android-google-oracle/
In another 2005 e-mail admitted as evidence by Oracle, Rubin tells Google co-founder Larry Page: “If Sun doesn’t want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language, or 2) Do Java anyway and defend our decision, perhaps making enemies along the way.”
http://arstechnica.com/tech-policy/2013/02/microsoft-foresee...
Looking at gomobile and CLs on golang-dev etc I feel Go support in Android is worked on by small focussed team rather than order from top management.
I also invite anyone reading this comment, to read the following story, which always comes to my mind in this sort of events: http://www.folklore.org/StoryView.py?story=MacBasic.txt
2. If Oracle's dumb lawyers win, I'm happy. I get paid a salary to work. Why should companies get code for free, why do they need me. Copying and violating a license is bad. Even GPL and other code I write, respect the license.
3. To summarize, would you want Google to violate GPL?
Yes, coming up with ever-more-creative theories about why Google owes Oracle might have some tactical advantages, but any victory in court on those terms would be pyrrhic.
It doesn't matter how many billions Google coughs up if the next phone call is IBM demanding the company for using SQL.
Aren't Oracle's lawyers looking past the next move? Are they that confident that their API arguments will lose? Do they really have that much faith in the hairs they're splitting between Google's API reuse and Oracle's?
Or is their advice being colored by all the follow-on legal work there will be because Oracle is going down this path?
If I understand correctly, Oracle would have to prove that Google's use of the Java API did not fall under the fair use exception in copyright law.
That is, if I write something, you can't publish it as your own. That's copyright. But there are exceptions within the law. One exception is fair use (others are criticism, parody, and there may be more, but fair use is the one in play in this case). Note that fair use was in the original trial, and the jury deadlocked on whether that was a valid defense for Google.
Below here, my understanding is less solid. But I think that one category of fair use is interoperability. That is, if I have a copyright interface (like, say, an API), you can copy that API in order to interface to something. To what degree, and what the boundaries are, I'm not sure.
Has Google's use of Java somehow damaged Oracle? Are they worse off now than they would be if Android were built on a different technology?
While with Microsoft everyone went out with their pitchforks.
Android Java is nothing more than Google's J++.
You probably know this, but Java-the-language is not the same as Java-the-platform (VM); Google only uses the language bit, not the runtime. They created their own runtime (Dalvik, and later ART) with its own bytecode format. What Microsoft did was implement an intentionally-incompatible JVM, hopefully you see the differences between Google and Microsoft's action (both technical and the reasoning behind the actions)
Edit: changed quote from wikipedia to [1], added reference.
1.http://www.javaworld.com/article/2077055/soa/what-does-sun-s...
They claimed that you can write Android apps in Java language, or reuse your existing libraries written in Java - like Google themselves did with Apache Commons.
On the contrary, J++ claimed to be Java implementation.
If APIs are going to be copyrightable, it will allow Oracle to hold all the third-parties using Java (or another JVM-based, like Kotlin or Scala) language hostage wrt where they can run their own software.
Since Windows has been clear from the start that any commercial use requires a paid license, it's not similar in any way at all.
It didn't end well.
In spite all of this, Android Team has given zero support for anything other than Java on Android, even for its own languages.
The NDK is anemic, because "In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need."
http://developer.android.com/tools/sdk/ndk/index.html
And the Go and Dart teams had to work on their own even for the NDK integration.
The results of their work aren't even described in any of the official Android documentation sites.
True, it runs in the same runtime, but it does allow them to slowly move away from 20 years of history. Mind you, the obj-C runtime / Foundation isn't badly set up at all, I'd argue it's better than the Java SDK.
Google should have started looking at alternatives back them and making another environment first-class on Android as well
(or maybe they can just compile Go to Dalvik and flip the switch, I don't know)
This is even harder for the Android runtime because it's run on a virtual machine with characteristics that don't easily map to another language.
Basically if they switch to any other language all the apps that currently use Java (ie. all of them) will have to practically use their own VM -which would be slow - or reprogram everything in another language - which would be expensive.
Kotlin is JVM + Java interoperable language and this is its major if not sole selling point. So it does not help Google in any way regarding Oracle-Google copyright and patent issues.
Any kind of support might come when some developers get down and write lot of code to support that language. Android team is not going to add any support just because someone wanted or voted to support new language on Android platform.
At least people who wanted Go on android have written extensive amount of code to add support and still they are far from done.
http://techcrunch.com/2015/03/05/microsoft-and-google-collab...
Things could be worse. This could be decided in East Texas, for instance. That well-known hotbed of technical innovation ... /s
So do programming languages.
I'm not a lawyer but I believe this what you can do that you can't do with windows is ship the kiosk without java but give the customer a CD-ROM to install it themselves.
It sounds like this all would take a lot of time to complete. What would be the point for Google to do all this work?
The bad news was, that everything was reimplemented in Dart, including the widgets, so they had that not-quite-native feel.
Since it outputs bytecode, IANAL but it probably does not helps with Java APIs litigation.
Oracle apparently bamboozled the Federal Circuit into deciding that something called the "structure, sequence and organization" of the API should be copyrightable. But of course nobody cares about that part -- the order doesn't matter. You can sort the API into alphabetical order and strip out all the comments and it would make no real difference to anybody. But here is Oracle claiming that the copyrightable part is worth billions of dollars.
It's like asking why you can write C programs on Windows even though it doesn't provide an X server.
I cannot take whatever piece of Java code I feel like it and run it on Android.
But there are tons of differences in other aspects of the issue -- which make all the difference as to the MS case.
But your sequencing is dead on. It's a messy story.
However I suppose they could just add an extra one on the side. I wouldn't really consider that switching though.
The fact is that Google forked all of it.
You cannot use anything besides a pseudo Java 6.5 (the language), because there isn't support for all features available.
You cannot make use of the full Java SDK libraries, because Google's fork only supports cherry picked portions of the JDK, to the point that people have ported JDK classes to Android to close the gaps when porting Java code.
You cannot rely JVM features, because Dalvik/ART don't support everything that it is possible in a certified JVM like invokedynamic or more updated JNI versions.
The fact is that Google broke the Java eco-system, regardless how Google fanboys want to paint the picture that Google != Microsoft.
They tried to screw Sun and take advantage of their economic misfortune.
Luckily I don't suffer from Google colored glasses.
Even thought the specifics don't seem to matter to you, I'll add a bit more detail. "The sticking point is that Microsoft decided the Core Java class libraries were insufficient for its needs. Now there's nothing wrong with extending things by subclassing and placing the new objects in a package outside of the java.* class hierarchy. But deciding to add about 50 methods and 50 fields into the classes within the java.awt, java.lang, and java.io packages, as Microsoft did, is extremely problematic. "Microsoft deceptively altered key classes and inserted them into their SDK," said Baratz, which results in developers thinking they are writing Java, when actually they are writing something that runs only on Internet Explorer.[1]
> They tried to screw Sun and take advantage of their economic misfortune.
I have some sympathy for Sun, but had Google asked for permission for Java on Mobile, Sun would have insisted on the abomination that was J2ME because that was their mobile strategy. I'll take Java 6.5 over J2ME any day
1. http://www.javaworld.com/article/2077055/soa/what-does-sun-s...
The created a whole new language that happens to be mostly based on Java, for a very specific target OS where Java wasn't even available before.
The familiarity with Java is merely a bonus and boost for the adoption of Android programming from Java devs. It's wasn't meant (and it isn't) a jab at taking the Java development market (which is was Microsoft did -- going after the same people using Sun's Java, and for the same environments they used it in).
That's the "extend" part of "embrace, extend, extinguish."
I also suspect that OpenJDK's license might bite them in problematic ways, or they would have either done that to start or not had such difficulty negotiating an agreement under whatever terms Java possessed that Google might have wanted alternatives for.
That ticket was raised before Go 1.0, so I very much doubt it.
So unless you want to wage a perpetual war at the border between your app and Android base libraries, forget Go, or about any language that does not run on JVM.
Unfortunately that still means that there is no good way to write cross-platform mobile apps.
Extend implies extending an existing X product.
Google made their own runtime, NOT calling it X, and NOT targeting the same platforms where Java was available. And of course this never had any impact on regular Java itself -- so no extinguish part. Nobody stopped using Java on the server or the client even, to use Google's version, because it's not offered at all there.
Their language not only didn't target existing Java deployments, but it was also created (and has always been constrained) for a new platform where Java never existed, and for a usage domain where Java had negligible presence (mobile development in post-iPhone smartphones).
And even if they HAD targeted normal Java deployments, it would have been totally find, and not "embrace, extend, extinguish" if it wasn't called Java. It would have been like MS' C#, not MS' altered Java.
If you don't pretend it's the same product (like MS did), then "embrace, extend, extinguish" is exactly how evolution works in most cases, including the natural one -- things get replicated and some crucial extra sauce is added, and if it's good, then the old things wither.
In fact, in this sense (where you mimic another opponent) "embrace, extend, extinguish" is exactly what projects like OpenOffice, Gnumeric, Gimp, etc intended to do.
But, as said above, this, while also fine, is totally different to what Google did.
True. It does prevent damages going forward, however, and it removes Oracle's biggest club - a court order forbidding any further shipments of Android.
And you weren't meant to.
It's a whole different environment, and they made their own language for it, which they happened to base on Java.
The didn't call it "Java", nor they targeted regular Java deployments (like MS did).
They just wanted to have something that looks familiar to lots of devs, but for THEIR platform.
If MS had done the same (and in fact they sort of did, as early C# was heavily based on Java -- just not as much as Google's) they'd have no issue with SUN. But instead they did those changes while still calling it Java and offering it for Java development on Windows.
(Besides, "I cannot take whatever piece of Java code I feel like it and run it on Android" was also true for SUN's own Java Mobile Edition too, when it comes to the mobile edition's compatibility with the Java SDK's on the desktop/server).
> Android provides a rich application framework that allows you to build innovative apps and games for mobile devices in a Java language environment.
In order to compile for Android, you use JACK, the Java Android Compiler Kit.[2] I could go on. Google uses the name Java all the time in reference to the language used for Android.
Google didn't base a language off Java. Android uses Java-the-language, unmodified (and an outdated one at that). It uses some existing Java APIs as well, and keeps the same names, which is why the official Android API reference[3] has the word Java appearing more times in it than a history of Indonesia.
[1] http://developer.android.com/guide/index.html [2] https://source.android.com/source/jack.html [3] http://developer.android.com/reference/java/lang/package-sum...
As I wrote, that was intentional, so that it's immediately familiar to Java programmers. That's just at the superficial API level though, which Oracle contested in court and I don't recall HNers being on their side...
Nobody was ever meant to use it to replace Java in their Java deployments and enterprise apps, or to run Java apps as is on that environment. And Google never promoted it as such -- as a Java replacement. Only as a Java-like environment specifically for Android development, and tied to the specific needs of its OS and devices.
What Android actually runs is a different language implementation through and through, with a different scope (target OS, environments, use etc) and a different VM, GC and tons of different APIs, with tons of not used APIs compared to the Java one's too (Swing for starters). And it's own bytecode of course.
So why should it follow Oracle's Java versions and progress, when it's NOT meant as a Java replacement? It has its own roadmap.
Heck, even the Java-like code behind the APIs, what's not 100% Googles, is not Oracle's or Sun's, but from the open source Apache Harmony project.
It's the high-level language and interfaces that would be hard. The real factor, though, is social given lock-in is in full effect here. Java was a bad, long-term bet given the Oracle acquisition.
I can see Android rolling this out across two major releases. The first adding support for a new VM or app language and the second removing Java. Time between those releases will give developers the chance to catch up.
I just think it's silly that you are opposed to throwing everything away. That is what got us in this mess to begin with. Android was supposed to be a simple transition for existing J2ME devs.
"I just think it's silly that you are opposed to throwing everything away"
That may be, but I'm pretty sure Google wouldn't think so :)
Nobody really throws away anything, that other people are depending on. Especially, if you are depending on their continued investment into your platform.
Otherwise, Windows Mobile to Windows Phone happens. Or Python2 to Python3 (how many years it is already taking?)
So two major releases is too optimistic. Especially in android world, where more than two major releases are used simultaneously.
And in fact Oracle's lawsuit is about neither the language or the runtime, it's about the APIs. Yes, they were taken from Apache Harmony. Oracle insists that Android's use of them infringes because Google created a derived work, incompatible with the full Java API, from the Harmony implementation of the Java API. Google, in fact, is replacing the Harmony code with OpenJDK[1], Oracle's official open-source implementation of the Java API. (Which is one of about a billion reasons why your claim that Android uses a language based on Java instead of actually using Java is so baffling -- it's so based on Java that they can replace their code with Oracle's official Java implementation!)
[1] http://arstechnica.com/tech-policy/2016/01/android-n-switche...
Java is not the syntax, though, it's the whole specificication -- down to the bytecode.
Google just borrowed the syntax (and API).
(As did other people and projects who did "clean room" clones of Java, while not calling their product/project Java).
>And in fact Oracle's lawsuit is about neither the language or the runtime, it's about the APIs.
Yeah, that's what I wrote above: "That's just at the superficial API level though, which Oracle contested in court".