Skip to main content

The Grand War is over, and what we can Learn from it

Posted by cayhorstmann on June 1, 2012 at 10:45 PM PDT

The grand war between Oracle and Google over the Android API is over, unless
Oracle prevails on appeal. The judge and jury have spoken, and this is what
they said:

  • Android doesn't infringe on the couple of patents that were at play in
    the lawsuit. (Other patents that Oracle asserted were invalidated by the
    USPTO or not included for tactical reasons—there wasn't a lot of “air
    time” allotted to either party.)
  • Android's use of a subset of the Java API doesn't violate copyright law.
    The jury found that the Android API copied the Java API, but the judge
    decided that was ok in the interest of interoperability, provided that the
    implementation was not copied.
  • Much noise was made about a few decompiled files and nine lines of code
    that Josh Bloch carelessly copied, but the judge realized that this was
    just a drop in the bucket and properly ignored it—as I
    18 months ago.

You can read his opinion here. As legal
documents go, it's a pretty easy read, and it gives a great background on the
legal history of this kind of lawsuits. So, pour yourself a martini and get
right to it.

Here are a couple of highlights.

Judge Alsup was dismissive of the “fragmentation” issue that we care
about as Java champions. He sniffily said that's a mere “business” concern
of no particular legal significance. In this day and age, where the desires of
business seem to routinely trump public policy, that's a refreshing line of

But think about it. There is more than a grain of truth to it. Sun was doing
a really poor job at the time, fighting a rear-guard battle on Java ME in
second-tier markets (albeit large ones), while smartphones were unstoppable in
the first tier. No, LWUIT wasn't going to
cut it. BlackBerry was polite enough to take out a Java ME license, even though
I can't think of any essential Java ME app anyone ever ran on a BlackBerry
device. Google, not so much. Sure, they were rude, and James Gosling didn't
like it
. But they had a credible API, and it seems better that it uses Java
than some oddball
. Given that Sun and then Oracle had nothing to offer (LWUIT
doesn't count), it would have made sense to join forces rather than to fight.
More business sense. More community sense.

So, the takeaway his that we aren't going to get any legal protection when
it comes to fragmentation or common standards. We've got to come together as a
community and realize that there is a benefit in having common standards and
common platforms, without trying to eke out momentary gains. By and large, Java
has done really well on this, with the notable exception of mobile.

Now, here is the other interesting aspect. When you read through the history
of copyright lawsuits, you'll be struck by how clueless the courts can be. Look
at those dueling dental programs. Those judges, about as clued in as the senior
managers who watch our demos, totally equate user interface with program
structure. If two programs have similar screens, surely one must have ripped
off the other.

But Alsup cuts right to the chase. Why? Because in a prior life, he wrote
some code!!! He knows that rangeCheck isn't rocket science because he has coded
something like it before. He told the Oracle attorney that he should be ashamed
at himself, making a mountain out of a molehill, because deep in his guts he
knew. Those judges looking at the dental programs didn't.

At Berkeley, the physics department teaches a course “Physics for Future
Presidents”. Mostly {nuclear|nucular} stuff, depending on your political
persuasion. In computer science, we need a course “Computing for Future

Related Topics >>


Regarding your Apple comment, I actually think they did a ...

Regarding your Apple comment, I actually think they did a good choice going with that oddball alternative as you put it.

Android is the last place where Java still might have a desktop like usage, Oracle with its actions seems to make the developers look for alternatives.

In our case, if we are able to target Android 2.2+ devices, C++ is our language of choice.