|
|
Featured White Papers
Sponsored Links
-
Slow Apps? Overloaded DBMS? - FREE Download
FREE Download Feb 14 - March 7th Eliminate bottlenecks & maximize performance ScaleOut StateServer®
The long-running Sun-Apache dispute
Submitted by Josh Fruhlinger on Wed, 03/11/2009 - 00:52.
Apache Software Foundation member Stephen Coleborne, speaking personally, quite rightly took me to task on my post from last week about the long-standing beef with Sun that led to the ASF's no vote on Java EE 6. Basically, I misunderstood exactly what the dispute was about; my excuse is that the real germ of dispute on this has been actively hidden from view by the participants. As Coleborne put it, "Many people think this is some minor, esoteric discussion of no importance. They couldn't be more wrong, but since the rest of the information in this dispute is private, I can't tell you why."
This led me on a bit of a treasure hunt to see if I could do a better job of explaining things. The best primary source documents are the open letter the ASF's Geir Magnusson wrote to Sun in 2007, and, even more illuminating, the accompanying FAQ. (The comments to this post on Magnusson's blog are also instructive.) As I noted yesterday, the ultimate dispute lies in the compatibility kit Sun offered the ASF for Apache Harmony. This kit is a technical framework that determines whether a specific implementation of some Java-related technology meets the standard laid out in the relevant JSR. But that's not all it is; it's also legal document that, if you pass, offers you the right, within the context of your implementation, to use the intellectually property contributed to the JSR standard by everyone who worked on that JSR.
The problem arose when Apache refused to accept the compatibility kit it was offered for its Harmony project, which is an implementation of Java SE, because it would limit the fields of use in which end users would be able to deploy Harmony. Apache says that such field of use restrictions are specifically forbidden by Sun's own rules for the JCP. And here's where it gets murky, because it's next to impossible to find information on exactly what the restrictions in this particular case entail, which I assume means that this is the private information to which Coleborne refers. The closest you get to an explanation is this excerpt from Apache's FAQ on the matter:
To give a concrete example from the Sun / Apache dispute, if Apache accepted Sun's terms, then users of a standard, tested build of Apache Harmony for Linux on a standard general purpose x86-based computer (for example, a Dell desktop) would be prevented from freely using that software and that hardware in any application where the computer was placed in an enclosed cabinet, like an information kiosk at a shopping mall, or an X-ray machine at an airport.
My first reaction to this -- which was the first bit of concrete information I had found after much pussyfooting around by all concerned -- was profound befuddlement. I had expected sweeping and squishy language restricting whole categories of potential use; this seemed like a painfully petty thing that couldn't possibly have held things up for so long. I thought about my own old tower computer, which sat in a little cabinet in my Ikea desk. Would I be either in violation or compliance of the terms of this agreement depending on whether the door was open or closed? Upon reflection, I imagine that this example is really Apache extrapolating some vague clause in the compatibility kit to an absurd conclusion. Just because it's absurd doesn't mean it isn't true, mind you, but it's in the ASF's interest to make the proposed restrictions sound as silly and arbitrary as possible.
Anyway, as you may have noticed, this dispute is over Harmony, an implementation of Java SE -- and yet the reason I'm going on about it at such length is that Apache voted no on the Java EE standard. As I read it, Apache is simply using this high-profile vote to draw attention to this dispute, which obviously matters a great deal to the ASF and yet hasn't been widely reported of late. (I was shocked to find that my own blog post from last week was the #4 Google hit for "apache harmony dispute.") In that sense, the move may have been productive, at least in terms of the quite specific audience that's important here; both Red Hat and IBM accompanied their "Yes" votes on the standard with caveats criticizing field of use restrictions in the JCP in general.
And Apache isn't being obstructionist in its larger participation with the Java Community Process; it even won the JCP Member Of The Year Award at 2008's JavaOne. I'm assuming that the Java EE 6 standard that was approved reflects Apache's contributions, even though they ultimately voted no on it. In a weird way, I'm reminded of Congressman Ron Paul, who gained a certain amount of notoriety with his quixotic run for the Republican presidential nomination last year. Paul, a libertarian who thinks that virtually everything the federal government does today lies outside the bounds of the constitution, is famous for voting "no" on nearly every piece of legislation that comes to the floor of the House of Representatives. But he works in committees to make sure that the budget bills he votes down contain earmarked spending that benefits his home district; he votes "no" on these bills, safe in the knowledge that they'll pass. I'd be very interested in seeing how the ASF would approach a vote that was actually close.
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2010 Infoworld, Inc. All rights reserved.
Field of Use
The example stated may seem like a stretch, but it is just a single example. Consider two important points about it:
A "field of use" (FOU) restriction affects what you get to do around point (2). The Apache License is supposed to allow you to do just about anything with the software. The FOU prevents that.
The important point is what kinds of values you can fill in for (1) and (2) to come up with another example. I bet you could find some values that would be very interesting -- and quite troubling.
The problem? Many of the agreements surrounding the JCK and the JCP, even the operation of the JCP, are covered by Non Disclosure Agreements. This is why Stephen, myself, and others can't provide exact language.
And Sun is not providing any solution here. They have money at stake. Apache Harmony without FOU restrictions would cause serious problems for them, so they going to keep the restrictions in place. Which, in turn, means that the Java world will not get a "certified" Harmony.
Cheers,
-g
Apache Member, Director, and Former Chairman
... and not speaking for the ASF
really nice post Josh and
really nice post Josh and nice explanation greg
Jack from Custom Flash Drives
Very helpful Information
It is amazing. You are doing a very great job that is to separate knowledge to others.
Informative Article
It is really helpful article. It is a bundle of knowledge of the new inventions in JAVA World. It is really a hue work that you do guys.
Informative Article
It is really helpful article. It is a bundle of knowledge of the new inventions in JAVA World. It is really a hue work that you do guys.
really nice information
It is really a helpful article. you are doing such a moral work that you are spreading knowledge. It is really great work you r doing.
Really a Helpful Article
IT is really a knowledgeable article.It gives many information about your new programs that how to use that and how to control that. You guys are really amazing.
The Apache HTTP Server
The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
Re:
Anyway, as you may have noticed, this dispute is over Harmony, an implementation of Java SE -- and yet the reason I'm going on about it at such length is that Apache voted no on the Java EE standard.
Nice Information
Nice article. It is really a knowledgeable article. It helps us to know about the new programs of JAVA World. It is great. YOu r doing really a god job.
Wonderful information
Great article. It s really knowledgeable.It helps in many thinks related to web designing. You guys are really doing a great job.
It is amazing. You are doing
It is amazing. You are doing a very great job that is to separate knowledge to others.
Apache should stop whinging
The code is available via the GPL, with NO restrictions. That's all I care about. The Apache folks just keep whinging and whinging. Move on.
Agreed!
They should focus their energy on something more positive than complaining!
what does "whinging" mean?
what does "whinging" mean?
Money, money... must be funny
There is no Classpath-exception for mobile/embedded Java (TM) so any non-GPL-application say any commercial mobile or embedded Java-application must use Sun's commercial Java-licence.
Sun wants to make money with their trademark and doesn't allow a really free-as-in-beer Java-alternative for mobile/embedded devices.
A typical monopolistic behaviour that we know from Microsoft and Apple since eternities. Sun isn't some sort of benevolent dictator for Java. It's only the dictator.
That's why Google had to invent Android and Dalvik. It's impossible for Google to offer Android for free if they would call it "Java".
That's all folks. Move on... there's nothing to see here.
Good update...still more investigative journalism to do
Thanks for taking on my comments and digging deeper. There's still more public info on the internet to find however - the Java community needs an investigative journalist right now. Its just about joining up the dots...
Some ideas. Take a look at not just the recent Java EE vote, but the history of comments of all recent votes (and how they have changed over time). Take a look at the Sun blogs and notice what word comes before "7". Appreciate the difference in the JCP between a spec, such as 'Java SE 6' (JSR-270) and an implementation, such as 'Sun JDK 6', 'IBM JDK 6' or 'OpenJDK 6'. What about the long delay to version 7 and the current absence of a JSR for Java SE 7 or Project Jigsaw - why is that?. You said "I'd be very interested in seeing how the ASF would approach a vote that was actually close" - but perhaps you could ask yourself the same question from the perspective of other voters?
Finally, think about the financial implications of a growth in new developments like these.
Again, I wish I could just write out what's wrong here, and why the GPL licensed OpenJDK is a smokescreen, but the JCP and legal agreements are private. That doesn't mean that there aren't enough dots to be joined up to find the bigger story lurking here.
Stephen Colebourne
ASF member, speaking personally
(Geir is the official ASF representative - http://blogs.codehaus.org/people/geir/)
the cabint example wasn't extrapolation
The example of putting the Dell into a cabinet wasn't extrapolation - it was the example given to me during negotiations by Sun. You can imagine my own astonishment. Go read Sun's license for their Java SE binaries distributed on their website - you couldn't put the Dell in a cabinet with their software, as they charge people for "cabinetization", and they don't want people using Harmony for that instead, I suppose. I personally think this is a restraint of trade issue, or would be if the ASF didn't give their software away for free.
Anyway, the specific terms that we are refusing to accept are such that end-users of Apache Harmony would be burdened by terms over and above those of the Apache License, which is unacceptable to the ASF. We don't distribute software that we create under terms other than the AL. We've tried very hard to find compromises, but Sun is unwavering in their insistence that these terms are included. Clearly they believe that the terms have a real, material effect on users, and that itself should be a big red flag, as that points to an intent to enforce such terms.
Ultimately, this boils down to whether or not Java is an ecosystem based on open specifications - where we as a community collaborate on specifications and then produce multiple compatible implementations - or an ecosystem where one company's business plan dictates what technology is developed.
The ASF has been fighting for the former for years now, and we're not going to stop. Our work has made compatible, open source implementations of Java specs possible, and we think that Java is very much stronger because of it.
Thanks for covering this issue.
geir
An update
An update for this. "Sun Microsystems' rocky relationship with open source over Java is again in the spotlight, after it lost support of two influential groups for the latest update to enterprise Java." More at http://www.theregister.co.uk/2009/03/05/sun_enterprise_java_opensource/
Still?
I can't believe this dispute is STILL going on!
The ASF has been fighting
The ASF has been fighting for the former for years now, and we're not going to stop. Our work has made compatible, open source implementations of Java specs possible, and we think that Java is very much stronger because of it.
Apache is very great, I like
Apache is very great, I like it very much.
Thank for the post.
Sun wants to make money with
Sun wants to make money with their trademark and doesn't allow a really free-as-in-beer Java-alternative for mobile/embedded devices.
A typical monopolistic behaviour that we know from Microsoft and Apple since eternities. Sun isn't some sort of benevolent dictator for Java. It's only the dictator.
Sun wants to make money with
Sun wants to make money with their trademark
That's why Google had to
That's why Google had to invent Android and Dalvik. It's impossible for Google to offer Android for free if they would call it "Java".
A typical monopolistic
A typical monopolistic behaviour that we know from Microsoft and Apple since eternities. Sun isn't some sort of benevolent dictator for Java. It's only the dictator.
The Apache HTTP Server
The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
I think apache is better
I think apache is better then java i love apache.
I am still using java not
I am still using java not apache java is the best it is easy to use,
Nice post Dimitri. It is no
Nice post Dimitri. It is no doubt a Cool idea. I really liked this text and i appreciate it but I would like to ask that are these songs in mp3 format?? Regards, Earvin James
Post new comment