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:
Can someone create and distribute an implementation that isn't compatible with the Java specification using this code? 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.
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.
Can someone create software that doesn't even implement Java, but uses pieces of the OpenJDK code commons? What are the limitations, if any?
Yes. There are no limitations. But there is an obligation to meet the requirements of the GPL (plus Classpath and Assembly exceptions if appropriate).
Can I call the resulting software "Java"?
What must I do to call my software based on code from the OpenJDK or phoneME projects "Java"?
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 http://www.sun.com/policies/trademarks/ for more details….
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?
These components are licensed under GPL v2 only.
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:
What is the significance of this announcement to the industry? 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:
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....
Why is Sun open sourcing its Java implementations now?
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.
What influenced this decision?
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 OpenOffice.org and NetBeans, and with the JDK Community on java.net. 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.
Why is this good for Java SE developers?
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.
How does this benefit Java SE customers and users?
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.
What markets do you believe this initiative will open up for the JDK?
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.
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.
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.
What impact will this move have on the adoption of the Java SE platform?
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.
What are your goals in open sourcing Sun's Java ME implementations?
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]
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.