posted by Andy Roberts on Thu 9th Jun 2005 20:58 UTC

"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 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 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 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 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 (XML parser)
  2. Apache Xalan J2 (XSLT processor)
  3. SAX (XML API)
  4. Nullsoft NSIS (Windows installer)
  5. IBM ICU4J (Unicode support, software internationalisation and globalisation libraries)
  6. IAIK PKCS#11 Wrapper (Cryptographic Token Interface Standard implementation)
  7. CUPS API (*N*X printing APIs)
  8. MESA (OpenGL library)
  9. Apache BCEL (Byte Code Engineering Library)
  10. Apache Jakarta Regexp (regular expression package)
  11. JLex (Lexical analyser generator)
  12. Crytpix (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 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 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 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.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Table of contents
  1. "Java, Page 1/2"
  2. "Java, Page 2/2"
e p (0)    44 Comment(s)

Technology White Papers

See More