Oracle Claims Google 'Directly Copied' Our Java Code 675
itwbennett writes "On Wednesday, Oracle amended the lawsuit it filed against Google in August, saying that 'approximately one third of Android's Application Programmer Interface (API) packages' are 'derivative of Oracle's copyrighted Java API packages' and related documents. In particular, 'the infringed elements of Oracle America's copyrighted work include Java method and class names, definitions, organization, and parameters; the structure, organization and content of Java class libraries; and the content and organization of Java's documentation,' Oracle says. 'In at least several instances, Android computer program code also was directly copied from copyrighted Oracle America code,' Oracle alleges."
Dangerous claim (Score:5, Interesting)
"The infringed elements of Oracle America’s copyrighted work include Java method and class names, definitions, organization, and parameters; the structure, organization and content of Java class libraries; and the content and organization of Java’s documentation," Oracle says.
All of this stuff should count as an interface, and therefore not covered by copyright under US law. If they win this, then it sets a very dangerous precedent. Any project that implements an interface defined by another would potentially be violating copyright - including every single PC, which includes a BIOS that implements the behaviour of the IBM-copyrighted PC BIOS. Projects like WINE and GNUstep would also be in serious trouble and Linux (implementing UNIX APIs) would be illegal.
Claiming that Google copied their code is interesting. I was under the impression that the java.* classes in Android came from Apache, not from the Sun releases. Is Oracle trying to pull a SCO here? (i.e. it does something like what our code does, therefore it's ours).
They really should have kept this as a patent / trademark issue. Bringing copyrights in is a terrible idea.
Re:Dangerous claim (Score:5, Interesting)
All those perfectly valid points aside, there's the slight matter of Sun having released the vast majority of their API implementation as open source.
To all those who saw no harm in the Sun purchase (Score:3, Interesting)
Oracle should never have been allowed to buy Sun. Instead it should have been liquidated (since that's what happening anyways... particularly with the high-profile Sun departures).
And so it begins...
Re:Only if they are certified Java (Score:3, Interesting)
Yes, you can create a free/open-source implementation of Java, as long as you are licensing from Sun/Oracle under the terms of the Java license.
But really, how long can it be before Oracle's suing open source implementations of Java, too?
I know, GPL, law isn't on their side, etc. But who really thinks that will stop them from trying to manage a win simply based on having more lawyers and money?
Same Lawyer (Score:3, Interesting)
Is Oracle trying to pull a SCO here?
Groklaw pointed out that David Boies is one of the three Lawyers listed on the Oracle filings. He also represented SCO in that fiasco, so, yes it appears we will be seeing the same sort of bullshit we saw there. He is a lawyer, and has represented many clients including some we would side with (such as arguing the DOJ's case against Microsoft). But his methods are similar regardless of the client; a no-holds-barred fight claiming anything they can think of regardless of the merit of the claims or how it affects Oracle's reputation with their customers.
Apple - Java (Score:5, Interesting)
Re:Here we go again (SCO) (Score:1, Interesting)
i agree.
we are currently laying out requirements to recode our gui system (linux based, using old motif code)
java was mentioned as a possible solution, but was quickly shot down due to its liability, and due to the fact that oracle seems intent on killing it.
we can't rewrite code & update systems using code that isn't going to be supported here in a few years.
Re:Here we go again (SCO) (Score:2, Interesting)
Programmer time costs more than machine time in almost all cases. Why have programmers reinventing the wheel when you can have a library of well tested code to cover most of what programmers need to write?
Re:Conspiracy (Score:3, Interesting)
Nope. I'm of the opinion that Java and Android are casualties to "business as usual" at Oracle.
I believe they really did want to be able to market an Oracle appliance set up specifically for running Oracle DBs. In fact, they will likely eventually move to a mode where Oracle is only supported on Oracle machines with a support contract. Since even the most trivial install of Oracle on the enterprise level requires a staggering amount of machines and processors, there's huge money in selling you a couple of million in hardware/software with tens of millions in built in support costs over the lifetime.
My wife works for a large company that does enterprise backups and the like. They have some aging Sun equipment -- but, since the machine isn't on a maintenance agreement with Oracle for bazillions of dollars each year, they suddenly can't get even the most basic stuff they used to be able to get. Oracle has locked everything down, and basically says "no contract, no peeking" -- needless to say, that is accelerating replacing Sun equipment with something else.
Oracle are as evil and closed as Microsoft, and ran by megalomaniacs on the same scale. Java is a casualty, but it wasn't a strategic goal of buying Sun. They had bigger fish to fry there.
In the long run, I think Oracle might devalue themselves overall -- they're gutting the brand value and good will of Sun, they're destroying Java, and generally not playing nice. I don't think people will want the taint of Oracle around their Sun platforms and Java.
Re:Only if they are certified Java (Score:3, Interesting)
Very unlikely actually. You forget that Java on the desktop doesn't make much money - it's far more lucrative to make it free, get people addicted and use Java elsewhere that makes more money - enterprise and mobile devices.
I didn't forget that; let me explain the nuance of where we differ.
I think what you're saying is true.
I think Sun saw it that way.
I don't think Oracle sees it that way. I think they're more likely to take the (bad, imho) strategy of deciding that Java needs to make them money directly even on the desktop/enterprise (herein defined as businesses that are using Java for business apps but maybe not using "enterprise Java"), one way or another. Maybe that's trying to get rid of free decent Java IDEs and muscle the makers of the rest into paying them a fee. Maybe that's bolting features or APIs onto Java that are extremely labryinthine or poorly documented so that you need to pay Oracle for consultants to do some or all of your implementation, and suing the hell out of alternate implementations of Java.
Basically, I think Oracle is about as likely to keep things going the smart way they previously were as the RIAA is to decide that file-sharing ultimately helps them out. There's just nothing in their culture or history that indicates they're remotely capable of letting a goose continue to lay golden eggs when it can be cooked and eaten today.
Evil? (Score:2, Interesting)
Re:Only if they are certified Java (Score:2, Interesting)
Oracle has not shown any *affection* for anything they got from Sun other than Patents. Unless you work there AND know different, I would GTFO. Handing out pink slips seems to cost more than watching the people leave.
BTW: is Oracle hiring for Solaris ,OpenOffice or Java positions? If not it proves my point.
Re:Behaving like SCO... (Score:5, Interesting)
Apparently they are getting really desperate and are behaving like SCO now. If you have tons of getters, setters and other small functions, it is easy to have the same implementation in all cases.
My guess: What Oracle is desparate for is a cross licensing deal with Google to give them access to Google's IP related to massively distributed data storage/retrieval. Google, on the other hand, isn't particularly interested in giving away their crown jewels in this way.
Um, isn't java code GPL? (Score:3, Interesting)
--Coder
Re:Um, isn't java code GPL? (Score:3, Interesting)
Ruby? Python? D? An adaptation of Python with (optional) static typing (to allow compilation into more efficient code)? (Note, btw, the existence of Pyrex and Cython which allow the compilation of python into native code. Sometimes much more efficient native code. This isn't what I'm talking about.)
Why bother to come up with an entirely new language? If you must, why not Go?
As for Ada... they'd need to make some basic changes. It could be done, but they've refused to even *look* in that direction. E.g., even in the early days Ada had the specifications for an optional extension for garbage collection. It was never made standard, or even recommended. And the new Ada standard still doesn't recommend it. And literals are by default of type fixed length char array. They need to default to type "unbounded string" (which needs a better name, say "string"). Etc. Most of the changes aren't basic, but they are very important for usability. The one exception is making it easier to allocate things on the heap. That does require a more basic change. But it isn't going to happen. Neither are the other, lesser, upgrades.
Re:Conspiracy (Score:3, Interesting)
Oracle is not in the mobile market, except in the sense that they now own Java and want to collect royalties for the use of Java in handheld devices. Sun has always required royalties for J2ME (Micro edition) in handheld devices. The issue here is that Google tried to weasel out of royalties by making a Java-compatible VM based on J2SE (Standard Edition) which is GPL and open. The problem is that this move violates the *spirit* of the original Java licensing agreement, which as to open Java for desktop/server use and charge royalties for Java on handheld devices.
I listened to Jonathan Schwartz's keynote at Java One in 2005 and he made the claim that handhelds were the future and where Sun's focus would be. One of his statements was about how there were virtually no desktop computers or land lines in rural areas / developing nations (India, China, Africa) but cell phones were ubiquitous. J2ME (at the time) was on 1 billion handhelds (now over 2 billion I believe). Whatever the royalties are, it is a significant source of revenue.
The success of Oracle's lawsuit will depend whether the wording of the licenses is such that a derivative of J2SE on a handheld device can be considered to be essentially J2ME. I.e. does any flavor of, or derivative of, Java on a handheld require licensing and royalty payments? And it may come down to whether certain APIs or implementations are shared between J2SE and J2ME, which is almost certainly the case.
Google tried to have their cake and eat it too. They wanted the ability to leverage a massive preexisting class library and huge developer population without paying the royalties to Sun/Oracle. So they made a byte code translator to allow developers to build and compile using Java, and execute on the Dalvik VM.
Harmony is in the clear, because the Apache Foundation is not trying to sell handheld devices with Harmony embedded. (Same with OpenJDK, GCJ, etc.)
I think Sun could have successfully sued Google over this, but chose not to, probably because it would be messy and because the goodwill with Google was more valuable. For Oracle it's a potential revenue stream. The intent isn't to kill the goose that lays the golden eggs, but to get a chunk of each egg that comes out.
Re:Here we go again (SCO) (Score:2, Interesting)
Q1: Where's a complete FOSS implementation of it, not tied to or dependant on anything from .NET and/or Microsoft?
Q2: How confident are you that, should you build the next big thing on such an implementation, Microsoft won't come after you one day, like Oracle is coming after Google now?
Re:PostgreKill (Score:3, Interesting)
Re:Here we go again (SCO) (Score:1, Interesting)
1995 called, it wants its java back. Also claiming that C coders are just shit doesn't really help the cause.
One example is the benchmark of Jake2 (a clone of Quake 2 written in Java by translating the original GPL C code). The Java 5.0 version performs better in some hardware configurations than its C counterpart[37]...
... high performance computing applications written in Java have recently won benchmark competitions. In 2008 and 2009, Apache Hadoop, an open-source high performance computing project written in Java was able to sort a terabyte and petabyte of integers the fastest.[63][64][65][66]
the rest is here, with citations [wikipedia.org]
Re:Um, isn't java code GPL? (Score:2, Interesting)
Mono is a C#/.NET runtime, and thus connected to Microsoft, making it even more of a liability than Java.
The good thing about C# and CLR in that perspective is that they are covered by the Open Specification Promise, which is essentially a patent waiver from MS. You don't get it for the entire .NET, but you do get it for the language itself, and for the most fundamental classes. It could be built from there, even in a direction completely different from (and incompatible with) .NET if need be.
Re:Here's Oracle's Example (Score:4, Interesting)
Of course, it could just as well be that the code in the screenshot was obtained from the decompiler by creator of said screenshot. Which doesn't make sense, since it's open source... but then the original Java is as well, so neither would Google (or Android Inc) have any reason to use a decompiler.
Oh, so it looks like there is an explanation for that, actually. The class in question is not one of the public Java class library APIs, but rather an implementation detail of Sun JRE. So, apparently, its source code was not available until Sun went truly OSS with OpenJDK. And the presence of that file in Android predates OpenJDK. Which gives some credence to "someone at Google or Android Inc used a decompiler" theory.
It would also explain the various minor and seemingly random differences in the code, such as bracing, or the use of "while" vs "for" - the latter is an example of detail which gets lost in Java bytecode, and cannot be fully reconstructed - the decompiler would have to guess. Here's an example from Oracle's submission. The original code looked like this:
As written, this while-loop is the stock Java pattern for the use of iterators prior to the introduction of "collection for" in Java 5. Now look at corresponding Android code:
If this for-loop sounds weird - especially its increment step - it's because it is. No-one actually writes code like that - it's a big no-no for readability.
But if you look closely, it's exactly equivalent to the while-loop above! It's what you'd get if you mechanically place the immediately preceding statement of the while-loop as the initializer in the for-loop, and then place the trailing statement of the loop body as the for-step.
Or - alternatively - this is what would happen if a decompiler would look at the bytecode produced from the for-loop (which boils down to if/goto on bytecode level), and said decompiler would have some heuristics in it to try to figure out whether it was a for-loop. Looks like in this case the heuristics is really simple, so if it can be written as a for-loop, that's what the decompiler does.
If you look around that code, you'll notice that the same pattern of shoehorning code into for-loops in strange ways - readily identifiable by inconsequential statement in for-loop increment steps - is all over the code. QED.
Re:Here's Oracle's Example (Score:3, Interesting)
More corroboration:
private static final String ANY_POLICY = "2.5.29.32.0";
Skipping down...
if(s.equals("2.5.29.32.0"))
Skipping down...
if(mExpectedPolicySet.contains("2.5.29.32.0"))
Why would anyone do that?