decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal

User Functions



Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

About Compatibility -- Oracle v. World & Dog | 388 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread
Authored by: bugstomper on Saturday, May 05 2012 @ 08:45 PM EDT
Please summarize in the Title box error->correction or s/error/correction/ to
make it easy for PJ or Mark to see what needs to be corrected and for other
people to see what errors have already been noted.

[ Reply to This | # ]

Off Topic threads
Authored by: bugstomper on Saturday, May 05 2012 @ 08:50 PM EDT
Please stay off topic in thee threads. No Java, unless it is coffee. Perl,
Python, Pascal, or PL/I are ok. Lisp is always fine.

[ Reply to This | # ]

News Picks Thread
Authored by: bugstomper on Saturday, May 05 2012 @ 08:54 PM EDT
Please put the title of the News Picks article in the Title box of your comment
to make it easy to scan through the comments. Also please include the link to
the News Picks article in the body of your comment, preferably as a clickable
link posted in HTML Formatted mode for the readers' convenience once the article
has scrolled off the News Picks sidebar.

[ Reply to This | # ]

Comes transcripts here
Authored by: bugstomper on Saturday, May 05 2012 @ 08:58 PM EDT
Please post your transcriptions of Comes exhibits using full HTML markup but
posted in Plain Old Text mode so PJ can easily copy and paste your work.

[ Reply to This | # ]

Tweets from the courtroom
Authored by: feldegast on Saturday, May 05 2012 @ 09:08 PM EDT!/Feldegast

- --
My posts are ©2004-2012 and released under the Creative Commons License Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

The answer is "yes".
Authored by: pem on Saturday, May 05 2012 @ 09:16 PM EDT
Is it “compatibility” with programmers who write in the Java programming language? Or compatibility with pre-existing programs?

Programs often have to be "tweaked" for a new environment. If you're lucky, that tweaking can be done in such a way the program still runs fine in the old environment. Gnu autoconf is a system for doing this sort of thing for C/C++.

But Sun's premise that Java itself is write-once/run anywhere is obviously false. Even pure Java non-Android programs will often have code in them to "discover" their environment and configure themselves. How big is the screen size? Is there audio? Making a program that "just works" without any effort on the part of the programmer has been realized -- if all you want is a simple text interface.

To the extent that new environments exist, it's good to make them as similar as possible to the old environments. This results in less effort spent porting existing programs, and less effort writing new programs that work in both environments, and less rote memorization of stupid niggling little system differences for the poor programmer.

Good software is all about reuse. Software is different than building a physical product. With a physical product such as an iPhone, there might be a few hundred designers and tens of thousands of production people. With software, the designers and production people are often the same. They can be infinitely more productive if they have preexisting concepts and implementations of those concepts at their fingertips.

Open source software, in particular, is a promise that you can reuse an implementation without fear, as long as you follow the license. If you don't like it, build your own and license it the way you like. It was long assumed that the concepts were reusable in any case, but Oracle seems bound and determined to change that. Half of what they are suing over is a reimplementation of tried and true functionality they borrowed from other languages.

[ Reply to This | # ]

A simple solution for Judge Alsup
Authored by: jbb on Saturday, May 05 2012 @ 09:21 PM EDT
Here is a very simple solution for Judge Alsup. If you have a list of unprotectable things and the order of the things in that list does not matter then the list itself is unprotectable even if people use the same or similar order.

I think this might be the core of the problem. I realize it might be too late for this trial but IMO Google should take a simple API with less than 100 declarations and present those declarations in different orders such as alphabetical, by length, etc. and show those to a witness and ask the witness if those are the same API or not and if they would all be infringing if there was a copyright on one of them.

The judge could call it his "order order". I think he would like that.

Our job is to remind ourselves that there are more contexts
than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

IBM can sue Oracle for SQL API?
Authored by: Anonymous on Saturday, May 05 2012 @ 10:20 PM EDT
From comment by Anonymous in the Corrections thread
...make me wonder what would happen if Oracle did wi(n) the copyright case because it would give IBM a clear road to shut them down for using SQL without a license and that would truly be a sweet victory.
Really? Was the SQL API designed by IBM?

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Saturday, May 05 2012 @ 10:34 PM EDT

Compatibility is a marketing word. For instance, I used it a lot when nine years back I converted the small company I worked at from Office to What I meant then was that for the types of things my co- workers did, opened and produced files that were close enough so that our clients wouldn't know that we didn't use Word.

I used it because I was asking them to do something new and somewhat different and these things fail unless you get buy-in which you do by minimizing the inconvenience and emphasizing the positive. And deliver in a proximate ratio.

I note that Judge Alsup was asking the parties to the suit for some clarification as to how they were using the word. Within the context of what I understood Google to be doing with Android, I think their use of compatible would mean that were I a software company, I'd be able to hire people who had a background that was useful for the Android development environment, and who could focus on what was new, since they had a fundamental understanding of the java idioms and metaphors. This might give Android a first look from me as java folks are easier to find than Objective-C folks for the going like gangbusters iOS platform. Having folks who knew java would reduce my time to market, and mean I could pay my developers less, because of supply and demand. That said, I suspect the ability to use Eclipse (java IDE from IBM) for Android development and Android growth curves about month 18 would be more eye- opening to me than Google's launch rhetoric. As to whether the source code we develop is TCK, jvm, or java compiler compatible, that would matter very little. Reuse of library code is nice, but at the end of the day, the goal is to make a profit from revenues after subtracting development and marketing costs for this year's product. Future reuse of the new code is a bird in the bush.

Disclaimer: I am not a professional developer, though I have gotten paid for software writing and maintenance.

With regards to Sheriff Oracle, I don't know if it matters if Sun was cringing in the saloon's corner or pouring the drinks (unless there is a real point regarding estoppel that Google didn't launch or was told wouldn't fly). The new Sheriff is enforcing the law that members only are drinking in private clubs on Sunday. Apologies for the sloppy metaphor and pun. Think of all the Court's time saved (and savings to Oracle's shareholders) if on the day Schwartz's blog hit the webs, Google had called up and gotten a signed piece of paper to codify what Schwartz implied.

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Saturday, May 05 2012 @ 10:35 PM EDT
> 13. When discussing use of the SSO in the 37 API packages in Android to
achieve “compatibility,” what exactly are the parties referring to? Is it
“compatibility” with programmers who write in the Java programming language? Or
compatibility with pre-existing programs? If so, approximately what percent of
pre-existing programs written for the Java platform are compatible with Android?
Is it compatibility with the TCK? Or Java virtual machine? Or java compiler?

Yes, it helps the programmers. It also helps people porting pre-existing
programs. They can't use the TCK due to licensing nonsense, so I'm not sure
that has ever been a concern, though if it was, they would need to use the
names. Dalvik uses its own VM and compiler, so I'm not sure what
"compatibility" means there. Insofar as it means that Google's
compiler can be fed the same source code, then yes, it's for compatibility there

I have no idea what percent of programs work, but if Oracle owns even the name
java.lang.Object, I know that nothing would work at all, unless perhaps someone
can find some incredibly contrived example to the contrary of no real world
importance. I suspect that a lot of programs need modification, depending on
the environments they've come from. Google has tried to make the amount of
modification small, or even zero for as many programs as possible in the name of
keeping compatibility. But the incompatibility would be the fault of the new
environment (e.g. smartphones have tiny screens), something outside of the
control of Java itself, rather than because of some choice Google made in naming

There simply wasn't any reasonable way for Google to avoid using these names
except to avoid using Java entirely. Personally, I'd like to see a ruling that
this was fair use, but it looks like the jury has to decide that part and who
knows what they're thinking.

[ Reply to This | # ]

Compatibility redux
Authored by: jbb on Saturday, May 05 2012 @ 11:05 PM EDT
I borrowed some of this from a previous post here.

Compatibility with Existing Code
If you look at entire applications then, sure, the amount of usability between Android and other Java applications would be near zero. But 99% of the time, that is not how existing code is re-used. Blocks of code that perform certain tasks are what get re-used most of the time. There would be a HUGE amount of overlap with these blocks. This is close to the essence of good programming. Code is made up of blocks within blocks within blocks.

This layering is usually achieved with method (function) call just like the method calls in APIs. A single API method call in an application program will substitute for hundreds or thousands (or more) lines of code from the API library. This same thing goes on inside the application itself. Methods (functions) that contain many lines of code (and other method calls) are created and then used with a single line of code elsewhere that calls the method. Experienced programmers will often have their own little libraries that they have developed over the years.

The big promise Sun made was that as long as you only used the "core APIs" then your personal library of code would be able to run on any system that ran an official version of Java. This was one of the main attractions of Java. The exact APIs included in this promise are specified in Sun/Oracle's own TCK. This is a large number of APIs and it includes all the accused APIs.

Compatibility in Future Programs
Going forward,the key thing with API compatibility is developer head space. Good developers hold the APIs they are using in their heads. The API calls can just stream from their fingers. Forcing them to use two different APIs to do exactly the same thing in very similar contexts would violate one of the most fundamental rules of programming. It would not make things 2x harder (because you now have to keep twice as much in your head), it would make things 100x harder or worse because of the tremendous risk of confusing a call in one set of APIs with the matching call in the other set of APIs. Even worse, if Google only changed the names so the translation between the two system was easy and could even be mechanized then the SSO of the Anrdroid APIs would have to be the same as the SSO of the Java APIs. I don't know what the SSO of an API is but the judge has already ruled that it doesn't include the names because names aren't protected.

Imagine what would have happened if in 2007 Google did exactly what Oracle is now insisting they should have done: release new, totally incompatible core APIs in Android. Sun would have screamed bloody murder and rightly so. Releasing incompatible core APIs would have truly fractured the Java community. It would have been very difficult for developers to switch between using Sun-Java and using Android-Java. There would be almost no code reuse between the two systems. Anyone who tried to switch from one to the other would generate tons of bugs as they tried to get their fingers accustomed to the new system. It would be like changing around the keys on the keyboard. You could eventually get used to the new layout but the transition would be difficult and your productivity would plummet every time you switched from one to the other.

If Google had released incompatible core APIs then Sun would have pointed to Harmony and OpenJDK and GNU Classpath as examples of open source implementations of the core APIs that were compatible with standard Java. Google's move would have been seen by everyone in the tech community as extremely hostile. They would have been called out for violating their motto "don't be evil". Even if there was only a sliver of a chance for success Sun would have instantly sued Google over making non-compatible core APIs. Many people would say that Google was being worse than Microsoft. These people would have been correct. Releasing incompatible core APIs on the Android platform would have been the meanest, nastiest, most deadly attack Java ever encountered. Oracle is now insisting that Google pay them tons of money for not launching this possibly fatal attack on Java.

Our job is to remind ourselves that there are more contexts
than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Saturday, May 05 2012 @ 11:34 PM EDT
Q: Can someone create and distribute an implementation that isn't compatible with the Java specification using this code?

A: Yes. We do not recommend or endorse that action, however. In addition, they cannot label that implementation with the Java Compatible or Java Powered (for Java ME) brand and logo. These brands are your assurance that an implementation has passed the relevant TCKs.

Which is in fact how Android itself basically works: http:/ / compatibility-mean

[ Reply to This | # ]

PJ - You haven't yet gotten it re: #4
Authored by: Gringo_ on Saturday, May 05 2012 @ 11:38 PM EDT

I think that answers one of the judge's questions. But what do you say? I think it also partially answers question 4, about whether Google could have come up with different names and SSO yet still have provided the same functionality as in Android. The issue isn't whether Google could do that; the issue is what would have happened to compatibility had they done that. It's not just Android developers that would have been affected. You have to think about all the world's Java developers.

"the issue is what would have happened to compatibility had they done that" - That is incorrect. You are missing the point completely here. Google could not have come up with different names and SSO, because you simply couldn't use Java anymore. It wouldn't compile even if they changed just one letter in each name, not alone the SSO. You haven't been following the discussion on this point, and I think it is essential we be clear on this, because the fudsters will be saying "Google could have used their own names and SSO, but they chose to steal Oracle's instead!" Make no mistake about it - change the names and/or SSO is not an option. The only option is what they did, or write a whole new language. Without its libraries, Java is not a language - it is nothing - there is nothing there. Without the "Class", without "Object", you can't write any code.

And that too answers the judge's question #4. Yes, Android could rename everything, but then it wouldn't "get very far". Compatibility matters so much that Sun here commended Classpath and the Apache Harmony projects for "working to build fully compatible implementations of Java SE", and how would you do that without the APIs?

"Yes, Android could rename everything" No - they could most definitely not! The only choice is - use Java, or use some other language. There is no such thing as Java without its libraries - its API.

It has been suggest that maybe you could rename the classes and methods in Harmony, then could use some kind of interpreter to connect the Java classes to Harmony. However, if you examine this system as a black box, it looks exactly the same as before - with the same names and SSO no matter what you do.

I just think it is so important that everybody understand that for reasons I cannot fully articulate. For example, we don't want the judge thinking Google could have done that but chose not to. This would not bode well for Google or the future of software development.

[ Reply to This | # ]

About Compatibility -- Oracle v. World & Dog
Authored by: artp on Saturday, May 05 2012 @ 11:45 PM EDT
Not only does Oracle want to have their cake, eat it, and
sell it to the highest bidder, but it wants to tax the rest
of us for watching the auction.

It sticks in my craw that the 9 lines of duplicated code (I
really will get back on topic shortly) were written in two
different places for two different employers by the SAME

There is a unanimous agreement among corporate bodies to
believe that they own the skills of the people that they
hire. I can't take a skill that I learned at one company to
another and use it. I have to pretend that I don't know it,
even though it was my previous abilities that allowed me to
learn it in the first place. In the engineering field, it is
almost always the case that the innovation came from the

Corporations drone on about best practices and reusable code
and doing more with less (my personal favorite meaningless
slogan!). Yet when we take it to the logical conclusion,
they make a fuss.

To get back on topic, I haven't heard anyone talk about
reusable code, about the right of an employee to practice
his trade, about the necessity of having talented employees
who can learn and innovate, or any number of things that are
important to how WE do our work. As we write code, or
practice any other technical skill, we learn what works,
what doesn't, and where we need to use each one. We develop
an arsenal of specific applied skills that we can pull out
when a common problem pops up. That is the definition of a
craftsman -- knowing when to use each tool in the best
manner possible.

These things were far more important back when the
Constitution was written, because the US was a nation of
tradesman, craftsman and freeholders. Today, so many people
are employed by corporations that these freedoms are at
great risk of fading away.

I really do wish that SOMEONE at the two attorney's tables
had mentioned the right of an a employee to practice his
trade. It would not have gained any traction, but that is
the tragedy that I am concerned with. We have become a
nation of employees instead of a nation of free men. Nobody
wants to take any risk.

When someone can't use 9 lines of code that they wrote, then
freedom is truly gone.

Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Sunday, May 06 2012 @ 12:26 AM EDT
It is important to recall that 'Java' is two things. It is both a language, and
a JVM specification. It doesn't work like C or C++ -- you do indeed create a
text file that calls an API, but that does not get compiled into ELF format
(binary), but rather into class files, which are rather more byte oriented.

Thus, talking about APIs and compatibility may be a bit misleading, if your core
paradigm is native C/C++ and execution means loading ELF. It's rather closer to
the ABI -- application binary interface.

The JVM governs how classes are stored in the class file, and how they are
loaded. The most basic form of compatibility is a method call that looks up an
'mangled' class name (C++ concept, not Java, but similar and specified) in a
string table at the start of the class file. The string has, textually and byte
by byte, the package and class name, and codes representing the signature type,
including *their* string representations, if they happen to be classes.

Unlike 'symbol tables' in a C compiler, these are strings that actually must be
the same at run time, and have the same signature, to 'match'. The reason is
because cross-language calls are not contemplated, and the JVM spec takes the
easy route and uses language control to avoid the indirection of a symbol

It is possible to hook this loading mechanism and provide a custom class loader
that does not just 'look up the name in the string table' then go looking for a
class with that name on the class path. There are other very common cases where
more than just invoking a class by the most straightforward JVM mechanism is
done. Thus, it might be worthwhile to enumerate 'use cases' and discuss how
compatibility is affected in each case.

However, basic Java compatibility was always meant to be a the *byte code*
level. If the class names and signature types, including the class names of any
invoked classes, do not match, something fundamental about compatibility, which
is part of how the Java language and the JVM are intended to both work and work
together, has been broken.

[ Reply to This | # ]

The original con was McNealy's
Authored by: maco on Sunday, May 06 2012 @ 12:46 AM EDT
Apparently Oracle way overpaid for Sun.

Oracle have dumped Open Office.

Oracle are dropping a lot of Sun hardware.

The supposed star, Java's phone IP, is proving worthless as well because of Sun's previous actions.

Oracle is in court trying to recoup what it thought it had purchased from sun. Who would have led Oracle to believe other than Ellison's good friend, McNealy.

So of course McNealy is lying. He's the one who helped con persuade his "good friend" into purchasing Sun. Who knows what he claimed, and now, what is forced to "substantiate" in court.

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Sunday, May 06 2012 @ 12:47 AM EDT

Google has actually not done a very good job of explaining the necessity for compatibility to the judge.

Apache Harmony isn't the only project at the Apache Software Foundation. In particular, Apache Commons is quite popular with Java programmers. Without basic API compatibility developers on Android would have either

  1. had to create Android specific versions of all the Java open source projects they would like to use or
  2. create a tool to change the names of the system APIs in the jar files before they could be used.
Of course, I'm sure some sort of tool could have been included with Android to do this but it would have likely created a mess

A second consideration are the Interactive Development Environments (IDEs) developers use. They understand the Java language and understand that java.lang.String does not have to be imported into a Class. It would have created a barrier to acceptance if Android's packages would have to have been named android.lang.

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Sunday, May 06 2012 @ 01:47 AM EDT
Compatibility with the Java API on Android, even if only an important subset, is
less about allowing Java programs to work on Android without change (which is
what Oracle wants in addition to the extra cash they need to make shareholders
happier). But more about allowing the hundreds if not thousands of pre-existing
Java based class libraries to be compatible with Android (which is what Google
wants in addition to making it easier for people who were familiar with Java to
pick up Android application development). These class libraries are not owned or
developed by Sun. These class libraries are developed/own by other companies
(including Google, IBM, ... etc), organizations (including Apache) and
individual developers.

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Sunday, May 06 2012 @ 02:10 AM EDT
The primary reason for maintaining compatibility with the Java API's were to
allow Java programmers to port their existing applications over to Android
fairly quickly without having to change every API call. Additionally, have
familiarity with the Java API's also allowed you to develop more quickly, but
this is debatable as adjusting to new API's isn't really that difficult nowadays
with the code completion tools most IDE's ship with.

Google doesn't call their version Java so how does Oracle even have a leg to
stand on? Had Google called their implementation Java then there would have been
an issue, but they don't so why are we here again? This is simply a last ditch
effort from Oracle to try and extort money from Google by preposterously
claiming that method declarations fall under copyright. This is not only a
despicable maneuver, but it goes against the moral conscience of every
programmer. Any programmer that works for Oracle must truly be disgusted with
what they're trying to do.

Oracle is trying to do what SCO did and they failed miserably. History shall
repeat itself again. It does make me wonder what would happen if Oracle did win
the copyright case because it would give IBM a clear road to shut them down for
using SQL without a license and that would truly be a sweet victory.

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Sunday, May 06 2012 @ 03:15 AM EDT
>because who will then be willing to use Java?

>How will it sell or license Java to the UK now, even if it wins this

This would only be significant if someone else wanted to *re-implement* the Java
API's would it not? Of course most users of Java do not re-implement the API's.

I can (do in fact) use Oracle's Java in the UK - I can't see this litigation
(which I actually strongly oppose and hope Google prevail) having any effect on
that particular aspect.

[ Reply to This | # ]

Sure, you can rename, re-organize, and compile, iff ...
Authored by: reiisi on Sunday, May 06 2012 @ 03:58 AM EDT
If and only if Java had a macro-preprocessor like C, you could define a set of
macros that mapped Dalvik APIs to Java APIs. And you could give Dalvik a
macro-preprocessor, and write a set of macros to reverse the mapping, from Java
APIs to Dalvik.

Of course, that not only fails to answer the question, but it also opens a whole
new can of worms.

If you do such macro conversion, the combination of macro-preprocessor and the
macro definition files will be just as infringing as the current Dalvik
implementation is.

That is, if the jury says 10%, then the conversion macro-preprocessing stuff
would have to be 10% infringing. Dalvik itself could be separated from the
infringment arguments, but the macro-preprocessing stuff could not be.

But then there is that other can of worms, that I sometimes complain about.
Lawyers would notice that the macro wall appears porous to them. They would miss
the point of the conversion, and assume that macro-coated Dalvik infringes
because Dalvik (even with deliberately different APIs) itself infringes, and
pretty soon Oracle's lawyers would come after Ruby, Lua, and any other language
more recent than Java, because all such languages can (in theory) be
mechanically converted back and forth. One successful conversion, and it's offf
to the races.

The reason software and other literature/fine art were supposed to be kept out
of the patent pool is precisely this possibility of conversion. When you start
abstracting things out to this level, everything becomes everything else. The
patent with highest precedence is the dictator of the world, and, I'm not
speaking metaphorically, I do mean the Constitutions of all Constitional
government be damned.

Why am I suddenly talking about patents? Precisely because the argument about
copyrighting APIs destroys the barrier between copyright and patent. Yeah. I
mean that if you can claim and enforce copyright on APIs, in a few years some
lawyer is going to twist that to the plots of novels, and so it goes.

If and only if we could get the lawyers to forever agree not to try to expand
their patents, we could allow source code to be patented on the condition that
changing one variable name must be considered equivalent to changing the shape
or composition of one physical component, and that changing the compiler or
run-time library would be equivalent to changing the physical implementation
framework, and that changing the language would be equivalent to a complete
re-implementation of the device in different technology, and completely beyond
the claims of the patent. And the entire source code would have to be registered
and published, just the same as the blueprints have to be registered in
physically implemented patents.

Otherwise, you absolutely will open the door to abstracting away all barriers to
frivolous litigation, and it's just a matter of time until the entire economy
comes grinding to a halt under the burden.

And, now that you think about it, copyright is always a better fit for software
than patents, when you place the proper requirements on software patents. The
only real issue is how to protect a combination of software and machine, but
even that is going to require a lot more specificity than is currently
practiced, because a CPU can be used as a basis for arguments abstracting the
patent out of the physical implementation.

Symbols are inherently abstract.

[ Reply to This | # ]

Where is the justice?
Authored by: Anonymous on Sunday, May 06 2012 @ 05:42 AM EDT
Reading there is further evidence in the referenced recording showing Oracle and
some of their witnesses should have known better that to make big
misrepresentations to the court about Sun's view back in 2007/8, where is the
justice by not allowing these recordings into evidence at this stage? What law
stops it's inclusion or a mistrial? And what's to stop the court/dpp also
bringing charges against those that falsely testified knowing the correct Sun
viewpoint as indicated by these recordings back in 2007/8 during the java

Where is the justice? Or is the law so far removed from the concept of

[ Reply to This | # ]

That Sun FAQ is devastating to Oracle's case
Authored by: Anonymous on Sunday, May 06 2012 @ 05:50 AM EDT
It makes it clear that there is no case.

[ Reply to This | # ]

The answer is "yes" - bis
Authored by: Ian Al on Sunday, May 06 2012 @ 06:30 AM EDT
13. When discussing use of the SSO in the 37 API packages in Android to achieve “compatibility,” what exactly are the parties referring to? Is it “compatibility” with programmers who write in the Java programming language? Or compatibility with pre-existing programs?
My reply has been delayed by the need for Zen meditation... and a search through the comments. The meditation lead me to the comments... it was the meditation that was important. Brain the size of a planet and I have to consider Oracle's twaddle! I'm so depressed.

dcs channelled my meditative thoughts when he wrote:
It's not so much compatibility with existing programs as with existing libraries and frameworks. I'll give two simple examples.

The situation is such that if you ask any experienced Java programmer about how to do something with dates or times, he will most likely tell you to use JODA Time...

Unless Android supports Java's API for Date and Time, someone writing a program for Android cannot use JODA.

For Java, one tool, called a "testing framework", got so popular that not only alternative tools had to provide *APIs compatible with it* (never thought about that until now), but it inspired similar tools for other languages. This tool is called JUnit.

If the API used by Android was different than the API used by Java, one could not test code written for Android using JUnit in a reliable fashion, as the libraries used by JUnit and the tested code would be different.

Like these two, the are many more examples. One of the greatest advantages brought by Java over previous language was precisely how easy it was to use libraries provided by third parties.
Then there is the evidence given to the jury by Scott McNealy. He referred to the swing APIs. They could not work without a good number of the 51 APIs in Java SE and also in Android. In fact, they were so good they were eventually folded into the Java SE core APIs.

All those popular third party libraries including those that have been folded into the core over time (javax?) rely on the core APIs being available. It is not possible to guess in general terms which of those are essential. Google decided that 51 of them were the best set for Android devices.

It is essential that large parts of the core are available both for new programming, development of new libraries to put right the existing faults in Java and the support of existing third party libraries that have been found essential to make the Java SE platform in any way a fully functional cross-platform middleware solution.

Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

How did we get here?
Authored by: Ian Al on Sunday, May 06 2012 @ 08:11 AM EDT
If Sun had kept the Java SE Specification secret, only Sun could program in the Java language. They could have licensed out the Specification, at a price, and then third parties could program.

The only way to make a market for that product was to give away (free as in beer) the Java Runtime Environment to allow John Doe to run those paided-for third-party programs. They could not have been free. The third party needed to recover development and licensing costs.

A third party who did not want to pay Sun for a licence could legally deduce the API Specification from the operation of the proprietary program and use it to write their own programs. Mind you, that would only be feasible if someone also published books like Java in a Nutshell to explain the use of the APIs and the syntax of the Java language. There are limits to what you can deduce from the operation of a program.

If Sun decided to expand the walled garden in the face of this legal avoidance of its licence, it could have published the Java SE Specification and the Java Language Specification. Both documents would have been functionally necessary for program and programming compatibility and would also be a statement of fact about language and API. They would be no more copyright protectable than the third party derivation of the same.

That third party derivation was direct from the functionality of the program compiled code. By definition, it could not contain any creative expression fixed in a media and copied by the third party. Copyright of a document could not, by definition, be infringed because there was no document to copy. The compilable code could not be infringed because the compilable or compiled code was not copied. Only the functionality was deduced.

Could inheritance have been visible in the deduced API? No, because the API does not include any inheritance processes or functionality. If you create a programming object in any class, it acquires the properties of that class. It does not hunt through senior classes to collect its property set.

Could the fact that the language is OOP be determined from the API? No. Programmers might use their knowledge, skill and judgement to come to that conclusion, but they could not see that in the API. The same applies if Sun publishes the Java language syntax. It is only apparent to language experts. Sun would have to add explanatory text to tell programmers that oop was in play. Programmers would only be able to use their knowledge of earlier oop to know what this meant.

Oracle are suing over something not apparent in a deduced API. A deduced API cannot, by definition, copy creative expression. The judge has decided that this something is available to be copied from the documentation included in the compilable code written against the API.

The legal principle that this discloses is that both a deduced and a published API are legally untrammelled by copyright in order to make third party programs compatible with a proprietary program.

Oracle are claiming that copyright prevents that same API from being used to implement a replacement to the proprietary program. However, their argument boils down to copying of the creative expression included with the proprietary code. Because the published API Specification is both totally fact and totally functional, they cannot base their claims on it.

The reason that Oracle's claims fail and that all such comparable claims will fail is because Oracle never published the proprietary source files from which the included creative expression could be copied.

Which just leaves the Sun endorsed, free and open source, third party implemented version of their proprietary, compilable, API library code. Harmony only had access to the API Specification - fact.

No, fact, functional and unprotectable by copyright law.

They did not have access to the proprietary compilable code files that included the protected creative expression. They, absolutely, would have refused such access even if it was offered by Sun, at the time. The only way that they could claim full copyright on their work is by clean-room implementation.

Oracle proved that all 51 of the API implementations used by Google were completely free of accusable copying. The implementations used Harmony's API documentation code with Harmony's compilable code. The only additions to all the help documentation on the Android website that related to Java was ideas copied from Java in a Nutshell and other publications as testified by Dan Bornstein.

Google: How did you go about learning how to program in Java?

Dan Bornstein: Read books. "Java in a Nutshell," and "The Java Language Specification" (James Gosling and Bill Joy).
Do you remember reading all those Dalvik help files on the Android website? Dan was the lead author for that lot.

Didn't I tell you that Oracle were blowing smoke! Oh, no I didn't tell you that.

Oracle are blowing smoke.

Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

Re patent infringement - let me help you
Authored by: Anonymous on Sunday, May 06 2012 @ 08:53 AM EDT
>> I don't know if Google infringed Sun's patents or not.

Of course Google infringed Sun's patents. Software patents
are designed to be infringed upon regardless of the
programmer knowledge or intention. One can say that Oracle
has infringed Google's patents.

In the mind of the software community the question is not
who infringed on a software patent but rather who has, with
straight face, brought up such a claim for offensive

'nough said.

[ Reply to This | # ]

As did Groklaw.
Authored by: Anonymous on Sunday, May 06 2012 @ 09:17 AM EDT
"SCO tried to change the terms of the deal retroactively too."

You claimed to be able to change the license that comments had been posted under
some time after the event.

Why are they wrong and not you?

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: feldegast on Sunday, May 06 2012 @ 09:53 AM EDT
sun document still accessable saying java forks are ok

Q: Can someone create and distribute an implementation that isn't compatible with the Java specification using this code?

A: Yes. We do not recommend or endorse that action, however. In addition, they cannot label that implementation with the Java Compatible or Java Powered (for Java ME) brand and logo. These brands are your assurance that an implementation has passed the relevant TCKs.

My posts are ©2004-2012 and released under the Creative Commons License Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

Q: Answered in two bullets, + corrections to misguided assertions on "compatible" and "SSO"
Authored by: Anonymous on Sunday, May 06 2012 @ 10:14 AM EDT
1. Google wanted Android to be compatible with Java programmers head space

2. Oracle want Android to implement all 166 packages, be called Java, and pay
the toll. Compatibility in this sense means "to be Java".

It doesn't really matter what anybody else thinks "compatible" meant
for Java.

Compatibility is a spectrum, Google and Oracle are at two different places on

My pen writes on paper and on cloth, but it does not write on glass

Oracles pen is a different pen that writes on glass as well as paper but not on

I do not need to be able to write on glass, so I don't care one jot about
Oracles pen.

I do concede that our pens look very similar, they perform similar functions
they have the same interface.

They are not the same pen.

The pens could be said to be compatible, in the paper domain, yet Oracles pen
is not compatible with my cloth writing pen, also looked at from another
perspective, my pen is not compatible with Oracles Pen, it does not write on

If we restrict forms of expression to paper, I could freely interchange my pen
with a (say) Chinese person who had an Oracle pen.

We can both write on paper. There is clearly compatibility.

Our writing however is not compatible, despite using similar devices and the
same interface, no communication is possible because the symbols used are not
the same.

(A subset of) Java Language is compatible with Android
Android is not compatible with Java(tm) Programs

Oracle could choose to port Java to Android in the same way that it has been
ported to Windows/MacOS/Unix/Symbian
(it is made considerably easier by the fact that Android is already compatible
with ~400 java classes)
And then Android(+Java) would be compatible with Java.

Or Oracle could dissemble and use the law to force somebody else to do it.

As for Q4(SSO), It is related to the question of compatibility, but there is too
much nitpicking going on, the judge is actually (almost) factually correct in
the question that he asks (I am ignoring the Spring part)

first the question again...

"4. Could Google have come up with different names and SSO yet still have
provided the same functionality as in Android? Android users would have had to
learn a new vocabulary and a new outline but the methods would all still have
been resident in such a modified Android. True?"

The key part is in the second question, "Android user would have to learn
a new vocabulary".

Yes, this is software, Google [still] could have re-implemented every one of the
400 classes('thing' concept) with different names in one great bloated
package(library concept) with no hierarchy(tree concept) called...

UsefulStuffDevelopersExpect2BeThere (USDE2BT for short)

Some vague similarity in names would still exist at the class level, after all
an Array is an Array (and is a well understood concept) and a Buffer is a Buffer
(and isn't what you think it is, it's another concept), and you wouldn't call
Zip anything else, any more than you would call your Toyota a
FourWheeledRoadBasedTransportSystem for fear of stepping on Fords idea of 'Car',
and is why names are not protected, but there would be no sign of the
insubstantial concept of the/Oracles SSO.

Android Users would not be affected in the slightest, they would not know the

Android developers would indeed have to learn a whole new vocabulary in order to
program for Android, and any existing code that was written in Java that a
developer wanted to reuse would have to be ported to the new vocabulary in
exactly the same way that Python code could/would be ported to Java if you
wanted it to run on Android (ignore the NDK for now).

It would be necessary in such circumstances for Google to change the way the
virtual machine works for the new vocabulary and they would also need to develop
additional tools along the tool chain.

e.g. javac compiles <source-code>.java files into
<source-code>.class files which are processed by dex tools for Android to
<source-code>.dex (I assume, this part is opaque to me, in part because I
can't be bothered to look,IJW)

Obviously javac does not have the vocabulary for our new USDE2BT package, and
javac expects certain things like quoted "Strings" to be exactly
something special and so would probably no longer do anything terribly useful.

Writing an AndroidC(ompiler) to process <source-code>.android files that
use the USDE2BT vocabulary is entirely possible and just a piece of work
(think: if you can do it for perl/java/basic/ruby/C/C++/ nausea then it

In this instance you'd probably end up skipping the <source-code>.class
step and go straight to the <source-code>.dex with AndroidC.

Writing a tool to convert existing Android <source code>.java files to
<source code>.android files would be relatively trivial and contrary to
various assertions made, it would not infringe any mythical SSO that Oracle may
own, it would only need a map of unordered names, it is conceptually no
different to a text editor/word processor search and replace function.

At this point, you now have an Android system that is independent of Java and a
pile of (relatively) unhappy programmers. Android programmers now write software
in a new language which is 'java like' in its syntax and awkwardly not 'java
like' in it's vocabulary.

Anybody who has programmed regularly in both C++ and in Java knows how awkward
this is. Anybody who has switched between Battlefield 3 and CoDIV(?), or a PS3
Controller to Xbox Controller knows how awkward this is.

You have to switch to a different conceptual framework and you will make

<wild speculation>
2 Days after the SSO has been removed someone will port DalvikVM to
Windows/Unix, the whole world switches to Android and ASUS releases a PC that
boots to Android and runs Win7 in a VM and Java is belly up in the water with
it's eyes pecked out.
</wild speculation>

This is software, everything is possible (with access to enough processing power
and storage), some things however are just not sensible.

When an Englishman steps of a boat and meets a Native American, they do not
invent a completely new language to communicate.

When a Spaniard rocks up to join the party, they do not throw away well
established communication symbols and invent another new language suitable for

When they are joined by a German, they do not start all over again with yet
another new language.

When a Frenchman turns up and declares that everyone is doing it all wrong and
the only way is his way and his language should be the one used, you would not
likely everything and switch to his language.

The correct response is to give him the wrong directions so he ends up lost in a
forest in Canada and promptly ignore him.

The Native American is Android

English happens to have absorbed a few French words

Oracle are playing the Frenchman

Android can switch to Italian (if it has to)

And that is the conceptual context for the compatibility question.

(With apologies to any French, Canadians or French-Canadians and Native
Americans reading)

[ Reply to This | # ]

SUN, Gosling and the world knew of Jyton
Authored by: IMANAL_TOO on Sunday, May 06 2012 @ 10:58 AM EDT
James Gosling, the creater of Java recently criticized Google who 'totally slimed SUN'. In another interview Gosling (JG) said:
EA Our audience consists of practitioners. Should they be thinking about writing interpreters instead of just writing the code?

JG The performance of many situations when people use these interpretive languages is actually not a big deal, mostly because the individual atomic operations in some of these languages are themselves fairly heavyweight. There are things like filling a polygon or drawing a string, and on top of that adding a few instructions to interpret the invocation of an imaging operation, that’s relatively low cost. But there are other ways to do it. For example, one technique that people use to get really good performance, rather than writing their own interpreters, is leveraging off one that exists already.

A common one to use is the Java Virtual Machine. There are things like Jython, which is a Python compiler that instead of compiling for the Python virtual machine actually generates Java bytecodes. That way they get a more dynamic-feeling language, but it sits on top of the Java Virtual Machine, and so they get to leverage off all the work that gets done in that optimization.

EA Do you know if any other languages have done the same thing?

JG There are several hundred of them. People have done things like ML compilers that compile down to Java bytecodes. You can even find Fortran and Lisp compilers that do the same thing.

EA I’m curious about your opinion of some of the other languages that in some sense overlap Java. Notably, C#.

JG They did such a job of copying Java, it’s hard to criticize them. Imitation is the sincerest form of flattery.
What? There are hundreds of other platforms doing the same thing? And many of those overlap Java? But here it is flattery? Ok...
But, I had never heard of Jython.

Reading Wikipedia on Jython:
Jython, successor of JPython, is an implementation of the Python programming language written in Java.

Jython programs can import and use any Java class. Except for some standard modules, Jython programs use Java classes instead of Python modules. Jython includes almost all of the modules in the standard Python programming language distribution, lacking only some of the modules implemented originally in C. For example, a user interface in Jython could be written with Swing, AWT or SWT. Jython compiles to Java bytecode (intermediate language) either on demand or statically.

On 3 March 2008, Sun Microsystems announced they had hired Ted Leung and Frank Wierzbicki to work on Jython and Python, similar to Sun's hiring of two JRuby developers.[2][3] Development progressed steadily,[4][5][5][6] and Jython 2.5.0 was released on June 16, 2009.
Hhhh?! It can import and use any Java class? And it is based on Java classes instead of Python and it compiles to Java bytecode either on demand or statically.

And SUN even hired people to promote it!

Didn't the Judge hear about this?!



[ Reply to This | # ]

The Breathtaking Creativity of the SSO
Authored by: Anonymous on Sunday, May 06 2012 @ 01:52 PM EDT
Being a sensitive soul, I find myself moved nearly to tears just thinking about
the spare creative beauty of the Java API.

My simple mind struggles to imagine what it must have been like for Java's
creators on the day when java.lang.Math, for instance, first saw the light of
day. How ever did they make the incredible perceptual leap that enabled them to
take Java's disparate mathematical functions, heretofore drifting aimlessly in
the Void, and give them blessed order by placing them together them under the
heading of "Math"? Seeking understanding, my thoughts inevitably drift
to the opening movement of of my favorite symphony, Mahler's 1st. It opens with
an air of expectancy, builds tension while moving through moods ranging from
light to ominous, then releases it all in a triumphal burst of brass and trumpet
calls that exalts the soul. I imagine the birth of java.lang.Math must have been
like that.

And what of Think about it: just two simple vowels, 'i' and 'o', to
encapsulate the mind-bogglingly abstruse concept of data flowing and in and out
of a computer. The beauty of its spare simplicity fairly takes one's breath
away. And its member functions are documented in...wait for it...alphabetical
order! How does one account for such sheer creative genius?

It doesn't stop there. There's for networking functions, java.text for
text-handling just goes on and on.

Such tremendous breakthroughs in computer science! Before the Java API, the poor
souls who programmed in C, for example, had to struggle along with such
unintuitive things as, um...hmmmm...math.h and stdio.h. Gosh, those don't really
look so different.

How about Python then? Gee, Python has a library named "math". But it
doesn't include a max() function as java.lang.Math does. Instead max() is built
into the language--how pedestrian. And Python's "io" library deals
only with files, while again many of the functions are language

With sarcasm turned off, the fact is that the organization of an API is simply a
taxonomy of library functions. It's a functional classification for the benefit
of the programmer, that will vary with the purposes of the language. Python, for
example, was created for scripting, so many functions are language built-ins to
make them available to the programmer with minimal code.

I think it important to point out that Java is itself highly derivative. I've
often seen it characterized--fairly, I think--as "C without pointers".
Java's creators used (in Oracle-speak, "stole") C syntax essentially
verbatim. They also "stole" the modular nature of C, in which most
functionality is located in libraries that are accessed through a standard
interface. And they "stole" the concept of organizing those functional
elements into files that are given descriptive names.

If memory serves correctly, Java was based on C in no small part to make it easy
for C programmers to become Java programmers: the same syntax, similarly-named
libraries, etc. That's why Google decided to implement the Java language for
Android: to make it easy for developers to code for the new platform. For Oracle
to argue that it was okay for them to do what they did with C, but illegal for
Google to use Java, seems to me to be the height of cynical prevarication.

[ Reply to This | # ]

  • sweet thought - Authored by: Anonymous on Sunday, May 06 2012 @ 03:44 PM EDT
Does The Following Constitute "Copyrightable Expression"?
Authored by: sk43 on Sunday, May 06 2012 @ 04:12 PM EDT
In his Opening Expert Report [Oracle-397-1, par. 140], John Mitchell writes:

"Based on my understanding of copyright law, it is my opinion that multiple
ELEMENTS of the Java API specifications contain COPYRIGHTABLE EXPRESSION. These
elements include the selection, coordination, and arrangement of the Java
packages; the class names and DEFINITIONS, fields, METHODS, and method
signatures contained in each package; and the English prose TEXT that explains
each of the above elements."

Got it. Let us examine the prose TEXT that EXPLAINS the Java libary class

"The Java math library is DEFINED with respect to fdlibm version 5.3.
Where fdlibm provides more than one DEFINITION for a function (such as acos),
use the 'IEEE 754 core function' version (residing in a file whose name begins
with the letter e). The METHODS which REQUIRE FDLIB semantics are sin, cos, tan

What is "fdlib"? Here is how Oracle describes it:

"... the package 'FREELY DISTRIBUTABLE MATH LIBRARY', known as

"... available from the well-known network library NETLIB ..."

That's right - the METHODS in java.lang.StrictMath are DEFINED in a third-party
package, fdlib. You can find it here:

Copyrightable expression. Infringed by Google?

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Sunday, May 06 2012 @ 08:24 PM EDT
Not directly on point, but perhaps relevant; a quote from the "100% Pure Java Cookbook" (c) 1997 Sun Microsystems:
Any implementation of the Java core APIs will include classes and packages that are not part of the documented API interface. Portable programs must not depend on these undocumented classes, because they might vary among different Java platform implementations. This is true even if the classes in question are undocumented parts of the reference Java platform implementation from Sun Microsystems. Those interfaces are not part of the Java platform definition, and they are not checked by the Java tests for compatibility, so they might be absent or might behave in subtly and dangerously different ways on different Java platform implementations. They are not documented because they are not intended for client use.
-- R Hayes

[ Reply to This | # ]

Spec Copyrightability as a Whole Not the Issue! Free Public Licensing of Spec Is!
Authored by: Anonymous on Sunday, May 06 2012 @ 08:50 PM EDT
Apparently according to this Apache Foundation's Harmony Project
page, Java's API's were used freely under a "public license" in
their "Independent Implementation":

""The Reference Implementation (RI) is used to resolve issues that
are not adequately addressed in the specification. In such cases we
use the RI as a guide to the compliant and expected behavior;
however, developers must ensure that the behaviour of the RI is
determined soley through exercising the 'PUBLIC' Java APIs --
specifically we avoid any notion of reverse engineering or
exposition of the RI's implementation by exercising non-API types
and methods.""

Copyrighted does not mean they were not Free to Use with a Pass-
Through Publically Licensed "Independent Implementation". Such as
what Apache Harmony was and Android is!

So now which Public Java SE Specifications License did Apache for
Harmony use and which one was Google going by? Oracle's currently
posted Public Java SE Specification License? ....or the Final Public
Java Specifications License posted for SE 5 or maybe SE 6 available
at these links below (copy/paste to address bar)!

(Public) Java SE 5 Specification License:

(Public) Java SE 6 Specification License 2006 (notice how this
license is much more clearly defined and written too):

There is a distinct difference between using a Copyrighted Public
Specification to develop Applications or an "Independent
Implementation" and possibly ripping the Whole Spec off, posting
them online (partially = Fair Use), claiming them as yours, etc. But
using individual API's (or a portion as in Google's case 37 of them)
in an "Independent Implementation" shouldn't be a problem. At least
under "Fair Use". Just because an API begins with "Java"
(java.lang = Provides classes that are fundamental to the design of
the Java programming language.), doesn't mean you're violating "Name
Space" or "Trademarks" under Fair Use either!

Warning!!! Specifications as a whole are Copyrighted... Yes. But if
individual API's within that Specification are made Copyrightable
(Protected without possibility of Fair Use or API's held separable),
then we have a major problem and the World is in for a whole lot of
hurt including Oracle themselves!

Therefore this is why the EU Court of Justice has properly declared
API's separable from the Specification... Un-Copyrightable!!!
OTHERWISE... you will have NO Compatibility with the Java Language
itself and ultimately Fragmentation to the 9th Degree on all
resultant "Independent Implementations" rendered worthless by API

[ Reply to This | # ]

"blueprint and the as-built"
Authored by: rsteinmetz70112 on Sunday, May 06 2012 @ 10:16 PM EDT
This goes back to the broken metaphor between API's and programs.

I am an Architect ( licensed in 10 states) to design buildings. Early in my
career one of my mentors told me, "no one ever drew a perfect set of plans
and no one ever built a perfect building".

During construction there are always minor and sometimes major changes in
construction from the original plans.

Rsteinmetz - IANAL therefore my opinions are illegal.

"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk

[ Reply to This | # ]

Compatibility for JCK Licensing Not Google's Objective!
Authored by: Anonymous on Sunday, May 06 2012 @ 11:27 PM EDT
Especially after Sun basically flipped them off on dropping
Open Source Required lack of any "Field of Use Restrictions".

Although Compatibility with the JCK was Apache's Objective as a
member of the JSPA, it was primarily driven by their desire to
not have "Field of Use" restrictions as well. That go against
FOSS and their own Apache licensing. Here's a link below for
the Apache Foundations Open Letter, concerning their's and
Sun's main disagreement. Having to do with those Field of Use
Restrictions that run contrary to the FOSS community at large,
including GPL'd Open Source License. It had nothing to do with
money either, as Apache is a non-profit. Here's the web address
of that Open Letter and be sure to visit that JCP link on it:

JCP page where Sun JCP representative Robert A. Gingell commits
to bringing the JCK/TCK in line with Apache's "No Field of Use
Restrictions" requirements for Harmony under Apache's own Free
Open Source License (not GPL). I think Mr. Gingell would have
been a great witness for Google. Too bad he left Sun before
Android was created!

Google after battling with Sun on these same "Field of Use"
restrictions abandoned their efforts to fully license their
Android Implementation and obtain JCK/TCK Compatibility to use
the Java Trademark for this very same reason. Thereby forcing
Google to create their own non-compatible implementation w/o
the use of the Java Trademarks, Licenses and IP protection the
JCK would bring them. In a way you could say Sun forced them to
Fragment Java by not allowing them to reject those "Field of
Use" restrictions and control Sun was demanding.

Sun brought this whole Android/Java debacle on themselves. By
refusing to relinquish control via "Field of Use Restrictions"
to both Apache and Google. That's why to this day, both Apache
Harmony and Google Android remain Non-Compatible. Even if
Apache had fully completed Harmony (99% complete) Sun still
wouldn't made their the JCK (Java Compatibility Test Kit-TCK)
for them as promised by Robert A. Gingell Sun Fellow and Vice
President in the JCP. So Google rightly believed they too would
be fighting a losing battle and the only thing they'd gain is
the ability to use the Java name and coffee cup logo!

In other words, Google on seeing how Sun was treating Apache in
it's supposedly JCP co-operative creation of Harmony Open
Source Implementation, decided to give up fighting with them
(mostly due to McNealy). Then decided to create from scratch
their own Non-Compatible Java Implementation using Harmony's
Clean Room created Open Source Libraries in their own Clean
Room Implementation running w/ their own Dalvik VM creation!

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Monday, May 07 2012 @ 03:18 AM EDT
Some thing have been overlooked in the context of interoperability,

Google and Sun/Oracle java is used by a lot of people or corporate
They work and produce soft and library on their own.

Not following specs or following specs and not using the SSO bar
standard developer from using third party library/API developed
under paid or free term closed or open term. This preventing easy
reuse of code but mainly of code using existing third party library for
which a "sed refactoring" is not an option...

Oracle don't even contest the right to reimplement a function, they
contest the right to use their patent in some reimplementation.
Coming soon :)

So, if Oracle copyright claim are found valide the only thing this will
provide to Oracle, and other in the same position, is right to lock out
a competitor from third party tool/lib/API by the meen of a single
inherently and fonctionaly worthless SSO.
No other gain there and plenty of pain for other.

This will give oversight to a hudge body of work over which Oracle
has no right and no control. This will hinder third party
right to enjoy the fruit of THEIR hard work.

API/lib/SSO around a langage/system, whatever you call them, are a
common ground where consumer/producer of an entire market meet,
share, sell and build amazing things :)

In this case Oracle want to monetize the third party java ecosystem at
no cost, no pain and prevent other from doing the same thing.

Non native english writer. Try my best to speak my mind many thing
left behind.

[ Reply to This | # ]

This suit should be call: "Broken promise"
Authored by: Anonymous on Monday, May 07 2012 @ 05:30 AM EDT
Sun was right about linking the success and grow of Java to openess.

Their is nothing so marvelous/original/distruptive/unique about java
language and API which can prevent doing same usefull work/soft on
other platform with other API and other language. Or prevent the
building and usage of language/API/platform really open.

The grow and relevance of java and it's ecosystem is directly linked to
this well understood premiss/promise which attracted many
contributor/user from major AND minor field.

Even if Sun failed to finally gain from this, other were successfull at it.
Someone can think of Oracle :)
And that's why contributor keep coming in. True competition on the
merit front with no lock-in or lock-out.

Beside that, I don't think Sun have failed on the java front.
From Oracle testimony the most import thing they bought with Sun
was Java...
It is my feeling that without Java Sun was really doom to fail and

[ Reply to This | # ]

About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj
Authored by: Anonymous on Monday, May 07 2012 @ 03:50 PM EDT
I'm probably a bit late but I've written a clone of an OS so here is some
technological background about "compatibility".

The term means "so similar that a computer program can't tell the

Examples: illegal and iIlegal look the same to the human eye (depending on which
font you're using in your browser) but the second word begins with two letters
'i'. For a human, these seem similar and if you're reading fast, you probably
wouldn't have noticed unless I told you about it.

For a computer, the two words are different. It's a hard task (= needs a lot of
code and experience) to make a computer "understand" (= mimic or make
it appear to a human) that two words are similar. Basically, for a computer,
"aaa" is as different to "aab" as is "xyz". A
human would think that the last one is much more different but this concept is
alien to a computer - unless you write a program for this specific case. The
computer wouldn't be the wiser, but it could behave as if it did understand. It
would look as if it knew what it was doing but only to a human. For the
computer, it's still just moving bits around in it's memory. No program can ever
make a computer "understand" what the bits mean in any way that is
similar to us humans "understanding" something.

When a software developer starts a new software, they have to begin somewhere.
Everyone starts in a place they feel comfortable with. My guess is that Google
started to write Android code in Java because that seemed to make sense at the

But them, the license deal "failed" (whatever the legal term for that
is or the reasons).

Now Google had a technical problem that it had to find a solution for. Every
class (= molds for the building blocks that make up the "living" form
of the software) has a name. In theory, the name doesn't matter but there are
two important factors: 1) A human should understand what the class does/means by
looking at the name and 2) when you use the class, the computer will try to find
the mold by name.

#1 is a product of the limitations of the human brain. A class should have a
meaningful name. Almost every programmer will use the word "Window"
for a class that works with windows on a computer display/monitor. That's a
technical term and if you write a program which uses windows to communicate with
the user, that's the word you will be looking for in the documentation. So the
mold for classes will be "Class". For objects, it will be
"Object" and for strings of text, it will be "String".
That's just a good way to avoid bugs by reducing the amount of information the
developers have to juggle in their heads.

#2 is different. As we have seen above, even small changes in the code (like
using an upper case "i" for a lower case "l" or a zero for
upper case o) make a computer fail to recognize a word. It doesn't look at the
letters on the screen, it looks at bit patterns in memory. And in memory, the
bit pattern for o and for 0 (zero) is very, very different. If you convert the
bit pattern into a number, you'd get 48 for "0" and 117 for upper case
"o". No one would think that 48 and 117 are similar.

So we have the following situation:

Google had a lot of code already written. It was using many names from the Java
language (think English grammar) and the Java runtime (= English words). In
theory, you could change all the names to new ones. But you'd face a couple of

1. Software developers would expect the molds under different names. No software
developer likes to spend their time looking for the classes which solve their
problems. Using different names is a good way to kill enthusiasm or to slow down
development. It's like replacing any piece of furniture in a house with
something similar and moving things around. It drives people crazy, especially
control freaks.

2. Computers don't understand what code means. When I write "Object"
in a source document, that can mean different things, depending on where I write
it. It's not always easy to see at first glance what it means, even for a human.
So if you start renaming stuff, you never know if you really, really got it
right in all the places. If you miss one (and you always do), you have a bug. If
you rename lots of things, you have many, many bugs. Software with a lot of bugs
doesn't get a lot of love.

3. If you rename something that is rarely used and has an unusual name, that is
pretty easy to handle. If you rename something that has a common name and it
used in a lot of places, that's begging for trouble. In our case, Oracle asks
that Google should rename "java.lang.Object". This string (and I mean
this exact string, see above) is used *everywhere*. It you don't mind the
reference but it's a bit like saying "Yeah, you can print The Bible but you
mustn't use the letter 'e'. Oh, and good luck selling it!".

4. There is a lot of code - databases, helper frameworks, literally billions of
lines of code - that use the Java API. If you start changing core names, then
all this code becomes useless. As I said above: Computers don't understand the
concept of similarity very well. You can't tell them "my language is a lot
like Java". When it looks for molds, the names must match exactly, letter
for letter, dot for dot.

5. In Java, unlike other, older languages, you mix API (that is the interface
that you should use to talk to a part of the software) and implementation (this
tells the computer what to do when a method of the API is invoked). Example:
String.length() gives me the length of a string. "hello".length()
would yield 5. In source code, this could read like so:

public int length() // This is the "API" - What you can do
{ // Anything between the braces is "implementation"
// How to do the actual work
int count = 0;
... somehow count the number of letters in the string ...
return count;

In the API (often called "header files") of older languages, you'd see
only "public int length();" which means "the class 'String' has a
method 'length' which returns a number without decimal places".

If I want to call this method, I use the code above. If someone renames the
method to something else, my program suddenly fails without being changed. The
API basically defines the words in the dictionary that my program can use. If
you start to rename words in the dictionary, the result isn't English anymore.

So what Oracle wants is to force Google into creating a product which can't use
anything related to Java. Billions of lines of code and the work that went into
them would be useless to Android and its developers. Everything that Java
already has would have to be invented again from scratch. It would take years to
rebuild the thriving Java ecosystem. All the apps on the Google market today
would be digital waste overnight. Every Android developer would have to learn
the new grammar and the new words.

Some things you asked:

> [...]what percent of pre-existing programs written for the Java platform
are compatible with Android?

That depends on what you call a "program". The H2 database is both a
program and a framework which you can use to build software that uses a
database. The program (the H2 database server) doesn't work as such on Android
but you can use the framework to add a database to a program that you write.

The key here is that not all Java code works on Android but that you can reuse a
lot of the code that was written for Java. It's a bit like building a car from
iron ore that you still have to mine or building it from pieces that you found
on a junkyard and in existing cars. Of course it's possible to build a car from
scratch, starting your own mining company and everything. But it's also a pretty
sure way to fail.

Which is why most new programming languages are compatible to something that
already exists: You don't have to dig up your own iron. Without writing a lot of
code, you can have a database because you can use the one which already exists.
There will be drawbacks (like design compromises which you'll have to make) but
it will help enormously spreading your new thing because you and everyone else
doesn't have to start from nothing.

It's obvious that Oracle would like Google to pay for their
"parasitic" use of the huge amount of work that went into Java. But
I'd question that stance:

1. What did Oracle do for Java besides buying Sun and selling a commercial Java
VM? Yes, they spent a lot of money but that doesn't mean the universe has to
make sure the investment pays off.

2. A lot of code in the Java universe is open source; you can see how it works,
you can change it and often even use it for free (it's free as in freedom and as
in beer!) I'm not sure how this came to pass but I'm sure Oracle wasn't part of
it. Java was always about sharing and Sun, no matter how many other mistakes
they made, did eventually understand this. Google depends a lot on this part of
the Java world; the language and the runtime are only the basic blocks.

3. If Oracle gets their way, I want to own the word "the". Sounds only

Hope this helps.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )