Oracle Claims Google 'Directly Copied' Our Java Code

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."

Comments

Dangerous claim

[TheRaven64]

"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

[Anonymous Coward]

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.

Apple - Java

[aitikin]

So maybe this is why Apple decided to stop updating their java and leave it to Oracle...

Re:Behaving like SCO...

[jdgeorge]

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.

Re:Here's Oracle's Example

[shutdown -p now]

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:

private void getPolicyNodes(int depth, Set set) {
        if (mDepth == depth) {
            set.add(this);
        } else {
            Iterator it = mChildren.iterator();
            while (it.hasNext()) {
                PolicyNodeImpl node = (PolicyNodeImpl) it.next();
  node.getPolicyNodes(depth, set);
            }
        }
    }

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:

private void getPolicyNodes(int i, Set set) {
        if(mDepth == i) {
            set.add(this);
        } else {
            PolicyNodeImpl policynodeimpl;
            for(Iterator iterator = mChildren.iterator();
iterator.hasNext(); policynodeimpl.getPolicyNodes(i, set))
                policynodeimpl = (PolicyNodeImpl)iterator.next();
        }
    }

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.