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


Groklaw Gear

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

You won't find me on Facebook


Donate Paypal

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 and Fragmentation of Java (Oracle v. Google) ~pj
Saturday, May 05 2012 @ 08:39 PM EDT

OK, Java guys. Can I ask you another question, please? I've found something I hope you will listen to and tell me then if it doesn't answer the judge's question about compatibility, question 13:
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?
I'd like to have you listen to a panel discussion, from JavaOne in 2007. I think it answers the question, at least mostly. It also shows what the real relationship between Sun and Project Harmony was at the time, and it's not at all the way Oracle is presenting it in this litigation.

Oracle is presenting it now that Sun grit its teeth and endured Google's actions and Project Harmony's presence, but that now there is a new sheriff in town, willing to take steps to enforce against anyone "violating" its terms. But was Project Harmony viewed as a violation by Sun?

They were collaborating with Sun in the JCP, and the title of the panel discussion was the "Java Technology Libre Panel", and the moderator, Sun's Tom Marble, identified the panel as representing the "leading voices" from the Open Source Java community, and he said, just before introducing Geir Magnusson of the Apache Harmony Project, "I've quite a distinguished panel of guests." If Sun viewed them as illegal projects forking Java, why invite them to the panel and introduce them like that?

On that panel were:

  • Sun's Tom Marble, OpenJDK Ambassador at the time
  • Mark Reinhold, Chief Engineer of Java SE for Sun, whom you recall from his testimony for Oracle in this litigation
  • Geir Magnusson, Chairman of the Apache Harmony Project and VP of Joost
  • Mark Wielaard maintainer of GNU/Classpath
  • Tom Tromey, Lead Developer, GCJ, at Red Hat and
  • Dalibor Topic, co-maintainer of Kaffe Virtual Machine community

If you listen to the audio, notice how firmly they all agree that compatibility matters, so programs will actually run, including legacy applications. Specifications are discussed specifically in this context. Sun's Tom Marble is sitting right there, and the Open Source guys talk about just merging the code, so as to provide bug compatibility, so old Sun code that is now deprecated can still work without breakage.

"The diversity is below the API level," one panelist says, talking about how important it is that the APIs be the same for everyone. "We collaborate on the spec and then we compete in the implementation," another says. Another contributor says that the blueprint and the as-built are never the same. And the Sun guy agrees. They all seem to me to agree that everyone could and should use the same specs and then implement with their own special touch, specifically to achieve compatibility, for the benefit of users. Sun didn't create those APIs all by itself, you see. And some of the folks that helped were from projects like Project Harmony. Sun was there. It knew. It had to know what was happening with the APIs.

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.

I mean, why include these independent projects leads as panelists in JavaOne, a conference Sun put on and so could invite whomever they wished, if they didn't approve of what they are doing? In 2008, Sun even hired Dalibor Topic to take over Tom Marble's job.

How deeply unfair it is, then, for Oracle to argue now that using Project Harmony APIs, as Google did, can't even be used as a defense. Oracle argued that the jury shouldn't even be allowed to consider that evidence. There may be a new sheriff in town, but does he get to retroactively change the law and start suing people because they acted in harmony with what they were led to believe was the law at the time?

It was reported that the jury was told by the judge in answer to one jury question that Google had no license. But that is false. They did have a license. They had the Apache License, which comes with the code. You don't need to sign a paper to have that license. And to pretend now that all this history never happened -- and keep in mind that in 2007 Google was working on Android and relying on how things were at the time and in fact a Google employee, Zaheda Bhorat, was on another panel at that same 2007 JavaOne and very possibly listened to this panel discussion -- is smarmy. There. I said it. It may be legal in Oracle's eyes, if you dance around in the law's intricacies with great lawyers, but us common folk watch, and we say, Ugh.

You know what happens to companies when enough people watch its business practices and say Ugh? Ask Microsoft.

Or the SCO Group. They tried to claim proprietary rights on header files. Remember? Errno.h. Lordy. How many words did Groklaw have to publish about errno.h? Does Oracle really want to act like the SCO Group? SCO tried to change the terms of the deal retroactively too. You saw how that worked out. The entire world despised them in the end.

People are drawn to fairness, not sharp practices, even if they sometimes work in the short term. It's obvious Sun knew about Project Harmony and not only didn't act like it minded, it included Project Harmony folks on JavaOne panels in 2007 and introduced them with respect. It's too late now to fix that mistake in the answer to the jury's question, I suppose. But there is no reason for the rest of us to be misled.

As for fragmentation, look at this FAQ from the day Sun released Java under the GPLv2:

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.

Q: Can someone create software that doesn't even implement Java, but uses pieces of the OpenJDK code commons? What are the limitations, if any?

A: Yes. There are no limitations. But there is an obligation to meet the requirements of the GPL (plus Classpath and Assembly exceptions if appropriate).

Q: Can I call the resulting software "Java"?

A: No.

  Q: What must I do to call my software based on code from the OpenJDK or phoneME projects "Java"?

A: The requirements for the use of the "Java" trademark and name have not changed with the open sourcing of the JDK and Java ME source code. The GPL v2 does not include a trademark license - no OSI-approved open-source licenses do. Sun does not currently have a licensing program that permits the use of the "Java" mark in your product or company name. You can use a truthful "tagline" however associating your product or company with Java technology, according to Sun's standard terms for use for trademarks. Please see for more details….

Q: What about non-Java language files such as manpages, readme files, scripts, and other elements of the JDK? How are these licensed in the OpenJDK Project?

A: These components are licensed under GPL v2 only.

Does that sound like Sun was determined to prevent all forks? Obviously, when it came to the release of Java under the GPL, they not only didn't care, because of the license terms, which they freely chose, they had no right to prevent it. So it's a pretense that Sun or Oracle hasn't already fragmented Java and/or enabled it to be further fragmented. They said you can fork if you wish, just don't call it Java, and that's because the GPL won't let you restrict modifying the code and redistributing. Sun was free to choose any license it wished, and this is the license it chose. One with no restrictions on doing whatever you wanted, whether compatible or not with Sun's Java.

And look how Oracle has treated other Open Source projects it bought when it bought Sun. OpenOffice, Solaris, MySQL. It's not that there is a new sheriff. There's a new *owner* who disdains Open Source ways, except when it suits the company to just take its code and make money from it.

Why, then, did Sun have a different view? That same FAQ, from 2008, tells us why:

Q: What is the significance of this announcement to the industry?

A: This announcement takes open-source, compatible Java from a long-standing dream of developers worldwide, to concrete reality. With the open sourcing of the code base for one of the industry's most significant and pervasive software platforms, the groundwork has been established to foster adoption in new markets, to build broader communities, and fuel even more innovation. With over 5.4 billion Java technology enabled devices, Java technology has already demonstrated explosive growth, appearing in volume nearly everywhere. Now, as free software, the Java platform can address new markets and be the engine of innovation for the next generation of networked applications....

Q: Why is Sun open sourcing its Java implementations now?

A: The Java platform is 12+ years in the making. When it was first released it was a radical departure for commercial software, including full source code under a novel license. Sun and the Java ecosystem have been extremely successful at establishing and growing a very large and dynamic market in this time. The Java platform retained its own licensing model even as the open-source model proliferated, because the Java licensing model successfully created a large and open market with many compatible choices. We now see an opportunity to encourage even more possibilities for adoption in places the Java platform hasn't gone before, where Free licensing and open-source development approaches are a prerequisite for consideration.

At the same time, the Free software and open-source communities are now saying that compatibility is a given for any Java implementation. And there is a new spirit of innovation with Web 2.0, SOA and collaboration/participation technologies, and the Java platform is the perfect foundation platform on which to innovate - and open-source can help accelerate this innovation.

Q: What influenced this decision?

A: Key Free software and open-source communities have stated that they believe that only Java technology implementation that are completely compatible with the specification can succeed in the market. These communities, which provide thought leadership for the open-source Java world, are now focused on delivering only compatible implementations. In addition, Sun has gained experience in community development with the Project GlassFish open-source implementation of Java EE, with OpenSolaris, with and NetBeans, and with the JDK Community on This experience makes us confident that when we open-source Sun's Java implementations, the platform will benefit, and we can better balance the needs of community with those of customers, end users, and licensees.

Overall, we feel that caution is appropriate for a technology that affects the lives and livelihoods of tens of millions of people around the world. After much reflection we feel now is the perfect time to take the next step with the Java platform.

Q: Why is this good for Java SE developers?

A: Because volume wins. Open sourcing Sun's Java SE implementation will lower barriers to adoption in markets where open-source software leads. As new markets adopt Java technology, developers will discover new opportunities. More applications. Innovations that leverage the industrial strength foundation of Java to deliver valuable new products and services. And developers will be able to directly influence the future of the JDK implementation, participating with their peers in an open community. Taking Java where it hasn't been before, and helping to ensure that Java technology remains a central unifying standard for the Internet.

Q: How does this benefit Java SE customers and users?

A: Your investment is safe, with multiple independent implementations of Java SE, and the reference implementation from Sun available under an open-source license. An open-source JDK provides peace of mind, plain and simple:

You can adopt Sun's Java technologies with full confidence. Java SE will be freely available - subject to the market forces that drive competition, reduce price and speed innovation.

Whether you value Free and open-source software for philosophical or economic reasons, want more flexibility, appreciate the quality that transparency brings, or want to know you have ultimate control over your investment, you can adopt the JDK knowing that you'll gain these advantages.

With the rock-solid, high performance JDK implementation from Sun under the same open-source license used by GNU/Linux distributions, you can expect Java technology to find its way onto new platforms, be leveraged for new applications and infrastructure, and be the foundation of tomorrow's most exciting new products and web technologies.

Your investment in Java technology will become even more valuable as open-source speeds innovation, spreads adoption, and carries the platform to places it couldn't previously go.

Q: What markets do you believe this initiative will open up for the JDK?

A: Several markets are likely to find the JDK to be more suitable for use once it is under an open-source license:

Government, educational, and research markets where open-source software is either mandated, or highly desired.

Enterprises that mandate open-source infrastructure to retain maximum flexibility and drive competitive procurement.

Enterprises and organizations that have selected OS distributions based on GNU/Linux and OpenSolaris as preferred OSs for deployment.

In order to gain the benefits of commercial support, and predictability, these customers may choose to use Sun's commercial distribution of the JDK or JRE in conjunction with a support contract. However, they might not consider the commercial product if the open-source version were not available.

Q: What impact will this move have on the adoption of the Java SE platform?

A: The Java platform has been very widely adopted already - it is one of the most important and widely used components of modern web-based infrastructure. But there remain un-tapped or under-served markets. In particular, Java technology is not always included in open-source web infrastructure stacks that are commonly distributed and deployed alongside and included with GNU/Linux distributions. Those that do include Java technology often do not include an up-to-date, compatible runtime and development environment. We continue to work with the GNU/Linux distributions to get the JDK included as part of the free software repositories commonly included with these open-source operating system distros. Once the JDK is easily obtained and installed with these platforms, we expect to see more widespread adoption of Java technology especially outside of North America and Western Europe, as well as in cutting edge web infrastructure deployments worldwide. Since the GPL is a very widely used open-source license (in fact it's the same license used by GNU/Linux), distributing the JDK under the GPL with GNU/Linux distributions should be a good match, making it easier to adopt by those looking for open-source alternatives.

Q: What are your goals in open sourcing Sun's Java ME implementations?

A: To remain the number one mobile application development platform*, Java ME needs to grow and evolve. This means engaged developers, accelerated innovation, and a more consistent implementation across devices. [* Evans Data Corp. Spring 2006]

Sun believed that sharing led to broader market adoption of Java and that over time that would work to Sun's benefit. But what about the threat of incompatible Java code? The FAQ:
In addition to the specific steps that we're taking to help foster compatibility, we are convinced that the market will demand compatible implementations, and that incompatible ones won't gain traction. With the billions of dollars of Java applications in the installed base, the community has recognized that a Java implementation that doesn't run the installed base of code won't get very far. That is why both the GNU/Classpath and Apache Harmony projects have stated unequivocally that they're working to build fully compatible implementations of Java SE.
And that too answers the judge's question #4. Yes, Android could rename everything, but then it wouldn't "get very far". [Update: Comments are saying it couldn't get anywhere at all, not just not very far. And another comment says that even if all the names were changed, Android would still violate "this made up thing called SSO" because it "would still be violated because the same classes and their parameters would appear in Android. That is what you just can't get around."] 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?

Oracle... well, I don't think it yet understands or appreciates the value Open Source brings. Perhaps, if the UK and the EU decide to require open code and open standards, then Oracle will understand the foolishness of proprietary APIs, because who will then be willing to use Java?

It's this history of promises and representations made by Sun, relied upon by many, not just Google, that makes suing Google, who relied upon these very representations, so very unjust.

That's what law is for, no? Justice?

Next week, the trial will begin the patent phase. I have no idea how that will go. I'm not a patent expert by any stretch of the imagination. I don't know if Google infringed Sun's patents or not. If they did, they'll have to pay. My words are specifically about the copyright phase of this litigation.

I continue to hope that Oracle will realize how its claims make it look to the FOSS community and make a change. Actually, it's bigger than just the FOSS community. I've seen article after article decrying Oracle's API claims and warning of damage if Oracle wins. Have you seen any articles defending it, other than by people paid by Oracle? I haven't either.

I know they don't listen to me, but they should. If they succeed in damaging FOSS and software innovation, by introducing a new field for copyright trolling in loathsome and destructive API litigation, which is what I believe is at risk with its API claims, they will fill a dark page in the history of software development, and the world will surely react unfavorably to Java, at a minimum.

Does Oracle have no desire to sell or license anything in the UK, where APIs were just found to be not copyrightable? How will it sell or license Java to the UK now, even if it wins this litigation? The EU also is determined to benefit from FOSS. Other countries feel the same way. Does Oracle plan on selling only in the US? The arrow is pointing all one way, in the direction of openness. Even Microsoft sees that much and made adjustments, because its clients demanded it. If countries require open standards and open code, would Java qualify? That's an issue Sun was trying to solve by open sourcing its Java implementation. I wonder if Oracle has thought about that. That's what I mean about painting itself into a proprietary corner. If they've thought of it, I see no indication that they care.

But it's never too late to do the right thing.


About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj | 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 )