I was thoroughly impressed with the judge who presided over the last ruling -- IIRC he went so far as to learn at least the basics of Java to the point where I remember being impressed by the insight of the questions he posed. There are subsets of law one can specialize in ranging from medical malpractice to obscure patent litigation, but as far as I know there are no factors linking a presiding judge to a specific specialty. I really think other judges should follow the example he set and at least develop a core understanding in a similar fashion.
(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.
"I really think other judges should follow the example he set and at least develop a core understanding in a similar fashion."
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.
Not more difficult per se, but more obfuscated. So much brands, paradigms, domain specific metalanguage. Medicine, physics have some kind of shared, time-tested foundations.
You could argue programming really took off in the 80s, and look at the plethora of languages then that are obsolete. Medicine and physics are more than 100 years old; programming is very new in the grand scheme of things and rapidly changing as it "finds itself." It's not very convincing to assert it has "time-tested foundations."
You mean the various kinds of semantics ? in that case yes, otherwise if it's for framework of the day, stack of the day it's hard to reason and compare anything.
I'm aware. I was making a larger critique w/r/t the justice system especially concerning higher level court decisions and the justices (more likely, their clerks) who draft opinions.
On software like JDK, my feeling (without thinking too much) is that the API is actually the most valuable part and the one that requires true expertise to craft.
"Alright, now implement IEnumerator OnNext(); bool MoveNext(); IDisposible Dispose();"[1] and your data now has the trait/type-class/whatever of IEnumerable! That's all an API is really -- method signatures and code contracts between the requester/requestee. The real gold isn't in that, but in the implementation details of the JVM (and the greybeards who know the -Xxs256 -Xmm10230 blah blah, I suppose.)
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.
That's the point. The API isn't valuable because of the creative expression (the thing copyright protects), it's valuable because its functionality (the thing copyright doesn't protect) is necessary for compatibility.
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 compatible with many Java libraries and IDEs etc. It isn't compatible with Java apps because the UI framework has to be different on a phone. Porting Java apps thereby requires changing only a minority of things rather than everything.
It's like asking why you can write C programs on Windows even though it doesn't provide an X server.
First, I don't see any way that moving to OpenJDK is going to cost more than $10 billion. Second, if I understand correctly, OpenJDK has a license grant from Oracle. That's going to make it really hard for Oracle to say that Google doesn't have permission to use it.
Moving to OpenJDK might not, but does not retroactively ameliorate any issues they had.
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.
More than 9 billion? Give 36,000 people $250,000 a year salary and you still haven't hit 9.2 billion. Pretty sure they could get it done in a year with 36,000 people.
The only thing better than throwing more engineers at an already-late solution is hiring a mass swarm of engineers and turning them loose on a only-semi-bounded new problem.
How is this any difference than installing Windows 10 on your Kiosk? You are paying for updates and support. You are free to use Linux and OpenJDK if you don't want to pay. Most shops I know of are using OpenJDK for all production deployments at this point unless you have a larger contract with Oracle.
It would be similar if Windows originally released with a license that let you use it without charge, and then later changed the terms of the license in an obscure way that classified a full sized PC as an embedded device.
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.
Kiosk licensing has always been required for shipping machines pre-installed with java. Sun required this 10+ years ago as well.
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.
But SCO preceeded Linux. If there'd been a cheap version of SCO in the first half of the 1990s, I doubt I'd have looked twice at Linux. My employer at the time did look at SCO, but WFWG solved the problem for us.
But your sequencing is dead on. It's a messy story.
OJDK is GPL v2, so you're a-okay there unless you're shipping a binary (in which case, upon customer request, the source + derivative code has to be released). RH puts out a "100% free" version under the moniker 'Iced Tea', if you want to play it safe. Realistically, attorneys are expensive -- going after a startup worth maybe 10MM on paper for a license violation isn't an economically prudent move for anyone.
Oracle should pay Google for using Java in Android and keeping the language somewhere around edge of hip and cool. I wonder how long it will be before Google flips to Go or JavaScript for Android.
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."
Never say never, that's what I thought about Apple and objective-C, and they just invented a new language for it.
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.
Go and Java stdlib have very different opinions about the basic types, used by every app (like strings or maps, heck, even about concepts what is a class and class hierarchies, or how the stack is supposed to look like).
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.
Without providing close to 100% interoperability, replacing Java with another language would be insane. All the open-source third party libraries for Android (and there's plenty, and many of them have become the de facto industry standard), all of that goes out of the window. I don't see how it could pan out
If that is the level we are happy about you can already run with Kotlin today. Its not official Alphabet, but it is offical from the company that makes Android Studio and it is roughly to Java what Apples new language was to Objective-C.
Unfortunately that still means that there is no good way to write cross-platform mobile apps.
There is never a good way to write cross-platform apps. Cross-platform programs are always inferior to solutions specifically designed for a particular use case (e.g. touch input + mobile device, pen input + tablet device).
I agree there needs to be a platform specific input output layer, but assuming you are writing the same app on different devices there is always going to be a large core (essentially all the business logic, all models, all validation, all sync code) that is, or should be, the same on all platforms. It is that code I wanted to refer to.
Yeah, unless there's explicit orders from above I don't see them moving (and usually Java people like to live in Java world and ignores everything else)
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 reminds me of that contest where people had to get the phrase "I smoke crack rocks" into a published academic paper, and the winner was something like "we burnt iodine (I) solution to observe its corrosive effect on stone and witnessed I smoke crack rocks".
Right ? If they keep putting Google under fire for the use of Java, they will only accelerate the process of Google moving away from Java (which is a huge task mind you) and as a result Java will loose a lot of relevance.
Google have indicated a future Android-Chrome merger. Although the public announcements were to the effect of Android simply replacing Chrome, there has been speculation about other outcomes. Perhaps this suit will encourage movement in the other direction, from Android to Chrome.
I'd say never. That would kind of be like an apple switching to Swift for iOS.
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.
Actually as a first step the language could be implemented on top of the dalvik vm. It's just that the IR of go would need to change for that target. Something like Truffle for OpenJDK could help by adopting new languages.
I don't see Android team itself is going to switch to Go or Javascript for android.
Otherwise, I would say Kotlin[0] would be a better alternative to Java.
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.
What is Pamela Jones doing nowadays? I understand her decision to shutdown groklaw because of govt spying but I can't help but think that, overall, it was a net loss for everyone involved.
To speed that up, just buy Postgresql and use that to smother both Oracle DB and to some extent, mysql. Defence only helps that much, offence can do it a lot faster on their own DB territory.
Better yet, buy EnterpriseDB that's actively targeting Oracle's market. Put a bunch of money into expanding it with conversion tools from Oracle to not Oracle API's it will use.
Given how much Google owed Sun in terms of technology and employees pulled from Sun over the years, I always thought not buying the company was an especially cynical move. Sort of like, "Ha! We got all their stuff for free and now they're gone! We win!" Payback's a bitch - though in this case it's not just going to be Google that pays. Oracle is vicious.
Dart is a very viable alternative to Java already for Android. See https://flutter.io/
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?
This case seems unusual in the fact that the code in question was already free to use and fork under the terms of OpenJDK, so paying Oracle for a license was not the only alternative. How would one calculate damages relative to the scenario where Google simply used OpenJDK as they are doing now?
And Google briefly considered adopting C# instead of Java back in the day. As a .NET dev turned Android dev (and not liking Java 6 one bit) I regret they didn't go down that path...
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.”
Brainfuck probably has an equal chance of being selected as C#. The problem is more that the APIs and all of the existing apps. Google can't just wake up one morning and decide that everything will be now in language XYZ because there are literally millions of apps for Android which have been written in Java against Java APIs. C# would also be an unusual choice for a company that does zero(?) C# work.
If this teaches us anything, is that you should avoid as hard as you can, giving others rope, with which they can hang you. I avoid Java anywhere I can, so for me, Java is only for mobile apps on Android.
1. Oracle's lawyers are idiots as they can't show it's same. For example run apache http client jar on android and java. It's same. Idiots.
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?
I really don't understand what Oracle's lawyers are thinking.
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?
I just wished google would use C++ for Android. It's does away with all this nonsense. I'm looking forward to the day where I have to pay oracle for every android app download I get even if the app is free...
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.
afaik, the real issue is that the dalvik-vm is api compatible with oracle(sun)-jvm. iirc, api is not 'copyrightable' which seems to suggest that it might not be so good for oracle. but then again, cases like these depend a lot on proficiency of presiding judges. wasn't there an earlier judge, who learned some elementary programming while preparing for this case, and who ended up favoring google...
If it were api compatible Java Android wouldn't be the second coming of J++, where apparently thanks to some strange events it is ok for Google to fork Java, break WORA where even many Java 6 libraries cannot run on Android, not to mention about later versions, and some devs seem to think it is ok.
While with Microsoft everyone went out with their pitchforks.
To refresh your memory:
"The complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract."[1]
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.
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.
Reality tends to have more nuance than you are willing to admit in this instance. Sun v. Microsoft was over very specific issues.
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
No Google "fanboy" (I actually hate the term, it's for immature 20 somethings to use), but Google didn't break the Java ecosystem IMHO.
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).
Google never claimed that Android runs Java (after all, it does not, dex is not Java Bytecode and Dalvik/libART are not JVM). It never passed TCK and never claimed to.
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.
J++ got into trouble for trademark issues because MS called their incompatible implementation Java(TM) and caused brand confusion. Android does not do this.
But Google doesn't call its fork Java(TM), which makes all the difference between this case and J++. The practice of independently implementing and modifying an API has never been questioned until now. It was not in dispute in J++ and it's in fact the reason why software projects like GNU/Linux (which is at most an approximation of AT&T Unix and has never received any sort of certification) are able to exist.
Yet another reason I push updating the old Modula, Oberon, or Component Pascal languages instead of using C# or Java. Both are controlled by scheming, money-hungry companies that try to eliminate competition and innovation outside their firms. Best not to be tied to such companies at all.
Reported earnings from Android, one would guess.. though as Google mentions, this is likely ALL they've earned from Android as a platform, nut just the impact of those specific methods.
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.)