The recent announcement [http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/%3CCA4BEB82-3D84-457D-9531-1477DD749919@apache.org%3E] from Apache regarding their plans to embark on their own J2SE implementation called Harmony has re-ignited the long-running Java/OSS debate. James "Father of Java" Gosling reacted in an unexpected way by giving a misleading view of what open source is really all about. Now that the dust has settled a little bit, it's time for an article that is not championing the cause for the relicensing of Sun's implementation under more permissive, open source terms, but simply a look at what could (and could not) happen under the open source model.
Java, Page 1/2
Whilst obviously aiming to be as objective as possible, I think it fair to let you know my leanings. I'm a big OSS fan. I've been using various forms of the GNU/Linux platform for around 8 years. I'm not a purist though: I will use propriety products if it does the job. Proof of this is that I am also a big Java fan. I started learning it around 5 years ago, although it's the last 3 years or so that it's been my main language. I honestly don't have an issue with the Java team, or Sun in general about their decisions. I don't always agree with their approach, specifically their licenses, but I don't mean to be anti-Sun, even if it should appear that way in this article (just anti-FUD).
The charges
In an interview [http://www.devx.com/Java/Article/28125/0/page/1] with DevX, Gosling made some comments, which, to anyone already sceptical or ignorant of OSS, give a completely false impression.
"It's often difficult to get a good picture from the open source community of what they actually object to in what we're doing. In what way could we be more open? Since day zero, 10 years ago, all of our sources have been open and available, very similar to how many projects in open source work."
Later, he adds,
"We've got several thousand man-years of engineering in [Java], and we hear very strongly that if this thing turned into an open source project - where just any old person could check in stuff - they'd all freak. They'd all go screaming into the hills."
And in a subsequent interview [http://www2.vnunet.com/lite/News/1163182] on Vnunet:
"I understand why [the OSS community] would like it to be different. From our point of view that would actually be more destructive than helpful. It boils down to forking: they believe that the ability to fork is an absolutely critical right."
Let's be clear here - these are Gosling's opinions, not those necessarily of Sun. Gosling and Stallman famously had a fracas [http://www.free-soft.org/gpl_history/] over Emacs which became the impetus for the GPL, so perhaps it's not so strange that Gosling has anti-OSS sentiments, and that Stallman has all guns blazing [http://www.gnu.org/philosophy/java-trap.html] at Java. However, I've seen them echoed within various quarters of the Java community itself, and so it's a worthwhile cause to have a closer look, I think.
Who wants a free cup of coffee?
From an ideological perspective, Richard Stallman is clearly at the front of the queue here! Free to see the source code; free to modify the source code; free to redistribute the code. It's a freedom of speech thing really! OSS isn't necessarily about giving products away for free (i.e., without payment). You can still charge for it, but your source will be visible to the end-user (should they care to look). The Java platform is free as in beer, i.e., you don't have to pay. You can look at the source. You can modify and recompile. You can't freely redistribute modified Sun code. Tut tut: hell hath no fury like a RMS scorned [http://software.newsforge.com/software/05/05/16/1358227.shtml?tid=152&tid=150&tid=89&tid=93&tid=132]...
From my experience, people don't like open source software because they can exercise the freedom of hacking with source code. They like it because it tends to deliver stable products; because it innovates; because it responds quickly to bugs and security issues; because it does the boring stuff that no-one else wants to do!
I've been fortunate to have an excellent contact regarding the Java/OSS issue in the shape of Dalibor Topic [http://www.advogato.org/person/robilad/]. He's unashamedly pro-free software and is the lead developer of Kaffe, contributor to GNU Classpath and Harmony participant. A tad biased one expects, but he always delivers decent explanations of the current situation - starting with Apache's motives,
"Apache Software Foundation, an organisation that's been quite successful at writing, maintaining and encouraging donations of Free Software written in the Java programming language eventually started thinking that a full J2SE implementation might be a good thing to have under Apache's umbrella as well, beside a huge chunk of the stack above it."
I couldn't agree more! The ASF have released some fantastic Java libraries that add tremendous value to the platform. Think about Ant, Log4j, Lucene, Struts, all the XML projects, and then there's Jakarta: Commons, POI, Tomcat, Velocity, Tapestry and so on. It's not just ASF who want an open J2SE to complete their stack, there is the wider free software community who need it. Dalibor notes:
"These days, there is an almost full Free Software stack, going from the Linux kernel, to the supporting GNU libraries from one side, and going from certified, compatible enterprise software development and deployment environments and their supporting libraries from the other side, like JBoss or JOnAS. The only remaining non-free card in that software stack is a fully compatible Free Software runtime for programs and libraries written in the Java programming language."
But I just made you a cuppa
There even seems to be some dissent within the OSS community itself. This is because OSS is itself a broad term and encapsulates a whole spectrum of ideologies. You don't have to look far before you find a complaints that Apache appear to be duplicating the efforts of GNU Classpath [http://www.gnu.org/software/classpath/classpath.html] and VMs like Kaffe [http://www.kaffe.org] or GCJ [http://gcc.gnu.org/java/]. This isn't the case. The Harmony team want to reuse as much of the pre-existing components as possible (you would be foolish not to!) The issue is that there is a slight conflict between the GPL license and the Apache license. The difference essentially boils down to the fact that redistributed GPL code must preserve the GPL license (and thus remain Free) where as Apache lets you redistribute under your own license. But, Classpath has an 'exception' clause similar to that found in libgcc/libg++ which permits linkage in binary form under your own license. This means that Harmony could work by having Classpath as a binary dependency, thereby avoiding the reimplementation of the class libraries. Likewise there's already talk of using JCVM [http://jcvm.sourceforge.net/] as a base for the VM. So, reuse is clearly on the agenda and Harmony is seeking all Apache friendly resources to evaluate their potential. Any shortcomings will of course have to be met by the Harmony developers and may require implementation of that component from scratch.
Forkin' hell
The biggest argument for resisting the opening of Java is that it permits forks of the platform that would lead to incompatible versions all competing against each other. The idea that all open source advocates want to do is fork everything is a slight exaggeration. Still, this is a very real concern that should be considered carefully. The example given is to think about all the hassle you have making sure your web page looks correct on all the mainstream browsers. Even closer to home was the controversy of Microsoft's non-standard JVM.
I personally don't think there will be many instances of a fully forked Java platform. It's pretty darn big! And I don't think any one wants to see a fragmented platform. What I think would happen is what I call 'micro-forks': stripped down versions that are designed for specific purposes. I also imagine you'd see the JVM ported to several other platforms that are not on Sun's radar at the moment. Dalibor speaks of Kaffe's success on reaching new platforms:
"Kaffe is one of the most widely ported pieces of runtime software around. In total, it has been ported to more than 70 platforms, ranging from good old x86 GNU/Linux to WindowsCE and PlayStation 2. There is a lot of interest on niche platforms in having ready access to Free Software written in the Java programming language, in particular if the platform in question does not have enough marketing value for some large corporation to step in and fund the porting and certification effort of a non-free runtime."
Sun already has a method to ensure the fragmentation of Java is avoided with it's JCK [https://jck.dev.java.net/] compatibility test suite. Since anyone is free to write their own Java compiler or runtime, Sun wanted a system that gives you the seal of approval, in that your implementation conforms to the specifications. It contains comprehensive testing of all aspects of the platform and at last count the number of tests it contained was around one-hundred-billion-trillion, times infinity, plus 1, plus tax. So, it's quite thorough and without it, Java's lawyers will hunt you down if you try and stick the 'Java' badge on your implementation. Dalibor pointed out to me:
"The major argument against breaking the platform is that on the broken platform the wealth of good software written in the Java programming language will not work, so it would be a pointless exercise now, after 10 years of software development. No one would switch to something broken when they can use the real, working thing.
"One must also note that official and unofficial extensions to the Java programming language, like support for generics, have existed already for years without the platform breaking apart. The 'everything will break and collapse' argument has been thoroughly refuted by the history of the platform."
A typical real world example I have come across: Java applications are often bundled with their own local copy of a JVM (to simplify deployment, as opposed to relying on the user installing the required version). Say I spot a bug in a core class that's causing me a head-ache. I look at the source and notice it's a really trivial error. I correct it and resubmit to Sun. If it gets approved, I then I could be waiting up to 18 months for the next official before I can get hold of a JRE that fixes the bug which I can legally deploy to customers. I can't distribute my fixed version of the class. Therefore, depending on the bug, I have to sub-class and fix by over-riding affected methods. A lot of work for what was a simple fix (cue cries from the Aspect Oriented Programming crowd). If it's a JVM bug, then you've no chance. There are also developers who simply want to remove packages that are not needed by their application - no source changes at all, but even that is not permitted. Would this really be a problem?
Java, Page 2/2
Get off my land!
The very notion that an open source project is automatically open to anyone to mess around with is laughable. Imagine I have an OSS project called CupOfTea. If you get hold of the source, you only have a copy of my source. You can mess that up as much as you like, but it will never affect CupOfTea. Now, OSS projects tend to promote the idea of gathering a community of programmers, but it's not the law! I have control of CupOfTea's source, and if I choose to, I can grant someone else access to modify the code, but it's very rare to see a project which allows an untrusted person access to the main branch.
For any large OSS project, structures and policies become part of the development process to ensure only worthwhile and tested submissions are committed to the development source, and meritocracies typically determine who gets access to the source. Sun would be no different when it comes to managing their Java source. If "any old person could check in stuff" into Java (if it were ever open sourced) then that's just bad management, which Sun simply wouldn't let happen: it's not as if they're open source virgins (think OpenOffice and OpenSolaris). Basically, it's a myth and Gosling should know better than to spread this one around.
Keep the change
Only the most eternal optimist is expecting Java to open their platform in a OSI compatible fashion. The free software world has accepted over the last 10 years that it's not going to happen. Heck, that's all part of free speech too, by the way. It's not that OSS communities expect a free lunch [http://www.gnu.org/philosophy/shouldbefree.html] here. Sun has invested so much in the platform and is undoubtedly the reason why it's reached such success in a relatively short time. They just want an open Java platform that can happily co-exist with their open OSes. Sun's Java license [http://java.sun.com/j2se/1.5.0/jdk-1_5_0_03-license.txt] has a nasty clause under section B regarding the distribution of the JDK (and similarly for the JRE):
"...(iii) you do not distribute additional software intended to replace any component(s) of the Software,"
The interpretation [http://www.debian.org/doc/manuals/debian-java-faq/ch5.html#s-license-concerns] is as follows: say I'm about to release MyOpenOS and am deciding which packages to bundle, if I put the Java binaries on it, I can't then have alternatives like the Jikes compiler, GNU Classpath, Kaffe VM, etc., bundled too. Open OSes won't accept this clause as they believe that users have the freedom to pick alternatives if they wish - and therefore Sun's JRE/JDK doesn't often get bundled. This is a shame because installing the official JRE/JDK on Linux isn't as user-friendly as its Windows equivalent. It would have been an advantage, therefore, for Sun to leave it up to the OS maintainers to do the work to ensure easier deployment of Java on open platforms.
This is why there has been so much effort by the OSS community over the years. Sun won't open up Java, so the OSS guys will do it for them! Gosling may exclaim that Java is "open" enough, yet once again this shows a lack of understanding of what free software is about. Dalibor makes a solid case:
"I find Sun Microsystems's marketing staff's desperate attempts funny, to try to rub off some the magic Open Source pixie dust of great street-credibility and coolness by pretending that their non-free implementations' licenses are just as good as Open Source ones. I think it would be equivalently futile if someone tried to confuse developers and users about the fact that Kaffe is not Java(TM), in the same sense that it is not Pepsi(TM) or Coca Cola(TM), or that GNU is not Unix(TM).
"When Kaffe eventually passes the official compatibility test suites from the JCP, then it (or a suitable fork of it) may get branded with the Java(TM) label. If Kaffe or Apache Harmony were trying to rub off some magic from Sun Microsystems's Java trademark before they meet the rules for the use of that trademark, such behaviour would be very misleading and rude towards Sun Microsystems. Proprietary software marketing efforts trying to rub off the good Open Source image without the marketed software meeting the criteria to be called Open Source, are an equivalently futile and funny attempt to mislead Open Source developers and users."
Allow me to take a small diversion... OpenSolaris has been taking its time because it had to work around 3rd party licensing issues. I expected similar constraints in Java that could hinder an open implementation. For anyone with more than their fair share of spare time, you can have a look at the 3rd Party Readme [http://java.sun.com/j2se/1.5.0/j2se-1_5_0-thirdpartyreadme.txt] that accompanies the J2SE platform. I couldn't see much in the form of propriety licenses, but you'll quickly find that Java benefits from a number of open source projects, including:
1. Apache Xerces [http://xml.apache.org/xerces2-j] (XML parser)
2. Apache Xalan J2 [http://xml.apache.org/xalan-j/] (XSLT processor)
3. SAX [http://www.saxproject.org/] (XML API)
4. Nullsoft NSIS [http://nsis.sourceforge.net/] (Windows installer)
5. IBM ICU4J [http://icu.sourceforge.net/] (Unicode support, software internationalisation and globalisation libraries)
6. IAIK PKCS#11 Wrapper [http://jce.iaik.tugraz.at/products/14_PKCS11_Wrapper/index.php] (Cryptographic Token Interface Standard implementation)
7. CUPS API [http://www.cups.org] (*N*X printing APIs)
8. MESA [http://www.mesa3d.org/] (OpenGL library)
9. Apache BCEL [http://jakarta.apache.org/bcel/] (Byte Code Engineering Library)
10. Apache Jakarta Regexp [http://jakarta.apache.org/regexp/index.html] (regular expression package)
11. JLex [http://www.cs.princeton.edu/~appel/modern/java/CUP/CUP Parser Generator (A parser generator like YACC)
12.
13. Crytpix [http://www.cryptix.org/] (Crypto package)
It's not many in the grand scheme of things, although the XML related projects are very key components to the platform. I wouldn't be surprised to hear if Java engineers have helped many of these projects since utilising them - fixing bugs or extending features, and re-contributing back (although I don't know for sure). Yet, it goes to show how commercial projects continually benefit from open source projects - even Java - so it can't be that bad, eh?
Drinking from the same cup
What gets me is that the Java crew know that many enterprises are scared of open source and hence are likely to "run for the hills" at the thought of Java being opened. However, instead of merely vocalising these fears, how about some education? You see, just like when someone moans at me and says "isn't Java slow?", I don't sit back and let them dwell in their ignorance, I'll explain why this is an untruth. It would have been nice that if in Sun's consultation with their customers, instead of playing on the fears of enterprises, and hence helping to reinforce their fear-based closed-source stance, they clarify things, "No, Mr BigCustomer, open source isn't what you think, it can help with A, B, and C, but it isn't helpful in X, Y, Z. Therefore, we've decided to keep Java closed, whilst doing what we can to promote a community of volunteer contributors..." But it doesn't - it sends out mixed messages. Sun has just recently responded to customer demands with the new JIUL license [http://www.java.net/jiul.csp] to allow them to modify the JRE within an organisation. Dalibor's observation was:
"It is fascinating to see how Sun Microsystems' customers, the same people who according to some would run straight to the hills on mention of Open Source, are at the same time apparently asking for freedoms to modify Sun Microsystems' implementation and distribute those modifications. The same freedoms that are granted and protected by Open Source software licenses."
The thing is, you can't deny that with open source, you open the door to forks. Yet the assumption that they are all bad is perhaps unfair. With the Linux kernel for example, you see several high-profile forks, which are essentially kept in sync with Linus's release, and have a set of patches on top that do additional things like tightening up security, performance boosts, etc. People don't actually want to deviate far from the main branch, just the freedom to tweak if they so feel like. This experimentation helps because successful advances can be reincorporated back to the main branch if they prove robust. Dalibor speaks of his experience:
"Kaffe has been forked a lot of times for specific purposes, and those forks have been great for the development of the project. They lead to fresh code and insight from developers and researchers taking it to new tasks like isolation, single system image, real-time or runtime environments for handheld platforms. Those different research goals could have been problematic to manage within a single project that users and developers expect to build and run for each release on more than a dozen of rapidly evolving platforms. Therefore researchers are encouraged to fork Kaffe if they have some really specific research needs, and, if they want, send patches back when they are done. By having people fork off a stable release, and integrating their work back later when it is ready, the Kaffe project is able to both sustain a fast rate of progress and gradually incorporate exciting new code from projects like JanosVM, Kangaroo or Jessica."
I personally don't think Sun is terribly worried about what the OSS community would do with Java - I think they're worried [http://www.almaer.com/blog/archives/000939.html] what a certain three-letter-acronym with a fondness for the colour blue would do with it.
Summary
So, let's recap,
1. OSS doesn't mean that Sun loses control of its Java platform (NB Sun never had control of the clean-room implementations in the first place).
2. OSS doesn't mean that any one can mess with the source - you copy it and mess with your own.
3. OSS doesn't mean forking. If derivatives do come, then they don't twist anyone's arm to force them to use it. There must be a compelling reason for it. Therefore, enterprise customers can stick with Sun - whilst the OSS boys play with their toys - and needn't go running to the hills after all.
It occurs to me that with increasing pressure from .Net, Sun will have to be looking over its shoulder to ensure it stays ahead of MS and its seemingly bottom-less pockets. I want to see Java succeed well in to the future and I personally see leveraging the energies of the OSS community will give it greater strength. You could submit patches back to Java, if you're happy with the license and faxed their form back! (NB, if you ever sign up, or even look at Java's source, you are no longer eligible to contribute to OSS Java projects as you are now contaminated!) There will be many who want to contribute but won't until it's under an OSI approved license. In the meantime, I simply hope that the sceptics have a better understanding of what the OSS community is about. Regardless of whether you're pro- or anti-OSS, at least you can make a more informed decision now. I'll finish with an optimistic view of the future from Dalibor:
"In the long run, though, GNU Classpath, gcj and Kaffe will probably pass the official test suites eventually, lead to a whole set of related Free Software runtimes passing those compatibility tests, and in turn make bytecode runtime environments as much as a commodity as GCC and g++ did it for the C and C++ development tools.
"If anyone can make the 'write once, run anywhere' slogan true, then it is a set of compatible Free Software runtimes for all occasions and environments."
About the author:
Andrew Roberts [http://www.comp.leeds.ac.uk/andyr/] is a computer science graduate from the University of Leeds, UK. He remained at Leeds to study further towards a PhD in Natural Language Processing. He has been using Linux for almost 8 years, and Java has been his language of choice for advanced language processing and machine learning during the last three years.
(http://www.osnews.com/printer.php?news_id=10806)
No comments:
Post a Comment