Danese Cooper's Blog

The Java Debate at OSCon

My Notes on what was said (your mileage may vary and apologies for no links and potential misspellings). -Danese

Tim asked how many Java developers at JavaONE were working in Open Source (because he believes that all the interesting stuff in Java is happening in Open Source, like Struts for instance) and he got not many hands. Of course here at OSCon all the developers who are interested in Java are also interesting in Open Source. Wants this panel to explore questions of whether the status quo way Java has been handled is NOT working...

Eric Raymond (ESR) threw down the fundamental idea of Open Source in the Cathedral and the Bazaar. Bruno Souza is an open source developer, but also the leader of the largest Java User Group in the world (in Brazil). Simon Phipps used to push Java at IBM and then went to work for Sun.

ESR says Open Source developers don't trust tools that someone else has an exclusive lock on. This is the result of bitter past experience. Eric says the right to fork is like the right to sue, the right to strike or the right to bear arms. You many not want to exercise them, but once someone tries to take one of them away from you.

(Tim): So Simon...is Java open enough?

(ESR): No!

Simon Phipps agrees that the problem is trusting the tools. In 1995 Sun was trying to solve that same problem by creating Java. Java (and its emphasis on compatibility) is one attempt at solving the need for "freedom" from vendor lock-in by forcing all vendors to follow an agreed-upon standard. Open Source is another attempt at solving the vendor lock-in problem (via the "freedom" of code availability). So this debate boils down to a need to bridge between two large and successful communities of software freedom. Just as the word "Free" is not enough to describe both "gratis" and "libre", the word "Java" isn't enough. There are many parts of Java and some of them are already "Free" in the Libre sense. Java isn't open enough in the sense that although it is now possible for a compatible open Java to exist, there isn't one yet.

(Tim): So, Bruno...is Java open enough?

Well, in Brazil participation on the JCP lets Java developers specify what Sun and others implement. This is working for for now, but Bruno believes there needs to be an Open Source implementation eventually and that JCP 2.5 allows for this. He says his friends in Brazil would be willing to participate on an open source implementation.

(Tim): Audience...is Java open enough?

Brian Behlendorf...explaining the Apache position says that the JSPA version associated wtih JCP 2.5 (which Apache signed) allows for open source Java compatible re-implementations. The Apache movement sees incompatibility as a bug to be fixed but not necessarily regulated by legal means. Brian says Sun promised (circa JCP 2.5) that Apache would not be required to pass on compatibility requirements downstream. Recently Apache has noticed that the TCK license has a clause in it that doesn't work with the Open Source Definition...that code created in open source at Apache can't be reused without compatibility (required passdown of compatibility). He says that Sun and Apache are negotiating on this issue now and hopefully it will be resolved.

(Tim): Simon, do you want to comment?

This is an artifact of the fact that Sun is dealing with TWO paradigms of creating software...ONE that is bounded by competitors who want to destroy the value proposition by advantaging their implementation against all others, and SECOND from developers who want Sun to "give up control".

(Brian): Microsoft already created a fork...its called C#.

(Tim): Was surprised by number of developers at JavaONE who were cheering for Sun's stewardship of compatibility.

(Brian): Maybe we the F/OSS community need to get the word out how F/OSS supports compatibility.

(Eric): In the F/OSS world, we have languages that don't fork because its in nobody's interest to fork. Why doesn't that convinced Sun that the same can happen for Java?

(Simon): Because the F/OSS community isn't the problem...its the substantial marketshare of big companies who ARE incented to fork.

(Bruno): Notice that IBM sells WebSphere, not Java Application Servers. It is true that we've seen them provide SWT outside of the JCP system. When you hear IBM telling customers that they can ship a JVM without SWING which will be faster, that's a problem for WORA.

(Simon): Because programmers need WORA to work...they need everything there so they know what they can depend on it.

More Audience Questions...

(Russ Nelson): Why isn't there a good Java interpretor in OSS?

(Eric): There is! The problem is the libraries.

(Russ Nelson): Then we should dig in and write them!

(Bruno): Agrees...Its all possible for us to do now. We as a community need to go off and do that now.

(Brian): What we learned at Apache is that to implement the spec, you need to read the spec. To read the spec you need to sign up to the copyright notice (which is bounded by the JSPA). Those restrictions keep companies from committing resources to Open Java implementations and THAT is something the F/OSS community would need to hope to do a compatible re-implementation. Apache is working to try to fix this one problem licensing problem, which they hope will open the floodgates.

(Simon): Predicts that there will BE open source Java (possibly based on Cafe, GNU Classpath) real soon now.

(Tim): Has never understood why Sun gets hung up on theorhetical worries and loses all credit for the much good work they have really done.

(Audience member Scott Dietzen) : Would like to propose a middle ground based on control of the Java Namespace and Brand. (Scott works for BEA and this is their current proposal) to the JCP

(Brian): Apache have also proposed this to Sun. Nothing would give you the right to use Sun's trademarks without their approval in this proposal.

(ESR): That would be compatible for OSD.

(Simon): This is worth pursuing (in his opinion, but he isn't going to speak for Sun on this).

(Bruno): Feels this type of debate is important because there are two communities here who are seemingly at odds...There ARE Java developers who are worried that Java isn't open source yet. Sun needs to hear this.

(Tim): But maybe also the F/OSS community needs to hear that there IS evidently support in the Java community for Sun's point of view among their key constituents. So there needs to be more dialog...How can we get this discussion to happen more constructively?

(Audience Question): How can we help?

(Bruno): Download the F/OSS version of Java and use it...then contribute to enhance it!

(Simon): Programmers join libraries together these days, so VMs are sort of irrelevant. There is still time to work out how to get Java open.

(Audience Question): Is Mono having any implications for F/OSS server-side in the future?

(Tim): Seems to be Java all the way on the server.

(Bruno): There is a BOF tonight at 8:00 about this...come and lets see if we can go anything more ;-)

Comments

• Just the Java J2ME,J2SE,J2EE Libraries
  From 2004-04-30 Just the Java J2ME,J2SE,J2EE LibrariesSun would still
  retain the veto, and the Java J2ME, J2SE and J2EE brand would be still be protected under trademark law.
  See In answer to Java's Opening and Bad Rep: Two replies to Joshua Marinacci.

  Posted by: nzheretic on July 28, 2004 at 09:24 AM

• Fixing second link, java.net deperately needs preview option
  See In answer to Java's Opening and Bad Rep: Two replies to Joshua Marinacci.</a.

  Posted by: nzheretic on July 28, 2004 at 09:26 AM

• java.net deperately needs preview option
  This is a digression, but you are so right about "deperately" needing the ability to preview all of our postings. We can't even preview the subject lines of our posts.

  Posted by: johnreynolds on July 28, 2004 at 11:55 PM

• The trademark issue
  The trade mark problem is unnecessary. It has caused so much confusion for Geronimo and JOnAS already, even though neither is officially J2EE(TM) certified yet.

  The problem seems to be that in order to protects some trade marks, Sun(SM, TM) Microsystems(TM) made the projects put up a weird notice [1] that seems to contradict the open source licenses of those projects. The result is that noone seems to know who can distribute what sort of derived works to whom under which terms.

  I think the solution to the trade mark problem is simple: unbundle the trade mark & certification from the TCK, and make the TCK available no charge, no strings attached for anyone to download. Don't (auto)certify open source project's releases, let vendors come to you or an independant entity to certify their offers.[2]

  The reasoning for this is quite simple: the TCK is quite useful in finding out and fixing incompatibilites between the reference implemenation (i.e. Sun(TM)'s), and a clean-room implementation. Giving everyone unencumbered[3] access to TCKs would let anyone check their vendor's claims of compatibility, which is what WORA(TM) is all about. That would put an effective tool against vendors intentionally breaking the platform into the hands of the consumers and developers.

  Certification and trade marks, on the other hand, are a different beast altogether. Trade marks are about marketing, being 'officialy certified'. They are not important to developers[4]. They are important to vendors and brand-aware consumers.[5]

  So let vendors that want to tap in the power of the Java(TM) and J2EE(TM) brands join into the marketing effort to certify & brand their offers. But please keep trade marks issues away from open source projects, as they only cause needless trouble.

  Fortunately, the J2SE(TM) 1.5 preliminary business terms seem to be a step in that direction. Thanks, Sun(TM)!

  cheers,
  dalibor topic

  [1] http://geronimo.apache.org/download.html
  [2] It only makes sense to certify the whole stack, anyway. If we are talking about J2EE(TM), then it only makes sense to certify a particular vendor's release of on operating syste for a specific cpu architecture with a specified release of a J2SE(TM) runtime with a specific J2EE(TM) server. While in theory WORA(TM) means that things will always run anywhere, in practice a change to the stack, to fix a security problem, for example, could limit the runtime's, and therefore server's ability to run some code.
  [3] No NDAs, for example.
  [4] Developers of clean-room implementations.
  [5] That includes developers that use implementations of specifications to get their work done.

  Posted by: robilad on July 29, 2004 at 07:19 AM

• same old rethoric regurgitated...
  ESR and his supporters are the one wanting to destroy Java.
  They say they will be able to "save" Java from destruction by making sure noone can take ownership of it by taking on that ownership themselves.
  In fact what they want is by limitless forking to spread so many mutually incompatible compilers and JVMs (which they call irrelevant...) that the platform looses its capability to write once, run anywhere and therefore its main strength.

  If Tim doesn't see that, I have always overrated his intelligence.
  If he does see it and agrees with ESR on wanting to detroy Java I've always had too much respect for his opinion.

  Posted by: jwenting on July 29, 2004 at 07:01 PM

• same old rethoric regurgitated...
  I fully agree. ESR & his cohorts will do nothing but destroy java by spawning 100 incompatible "open" versions of java. It's quite clear that M$ will be the ultimate beneficiary of all this rhetoric. Even IBM doesn't realise that it's shooting itself in the foot by adding to the chaos,pressing for open sourcing java, appearing a good samaritan and pretending be the open source community's voice.Time these people grew up and saw the bigger picture.

  Posted by: bharathch on July 29, 2004 at 08:42 PM

• same old rethoric regurgitated...
  The above comment borders on insanity.

  Any rational person can SEE that forks of Java are being created BECAUSE the standard java libraries offered by Sun DO NOT come under an OSI approved license. This is the reason for existence of GNU Classpath. Quite frankly, this is a waste of development effort...

  If Sun open-sourced Java under a modification friendly license (preferably OSI approved), then THAT would be the inevitably become the de-facto and de-jure JDK for all innovative open-source development . For example, highly innovative projects like JNode (http://www.jnode.org) - a java based operating system DO require certain changes in JDK code. They are now using Classpath, but just imagine the benefits if they could use the standard JDK instead. Classpath doesn't have a workable Swing implementation as yet - and it is going to take quite a bit of time to catch up with 1.5/5.0 new language features.

  Sun SHOULD open -source java - it will ENSURE that java will become the mainstream programming language for the next decade or more for just about every kind of project targeting a computing machine. It will even assimilate all adherents of C/C++ and other languages. :-)

  Sun is afraid of two things - the JDK forking and more specifically M$ forking the JDK. :-). They wish to ensure 100% compatibility. This is GOOD, but why should this prevent the JDK from being open-sourced ??. If you afraid of losing control - KEEP the control by all means! The JDK already a test suite. Get a OSI-approved license that states that all JDK's must pass the compatibility test in order to be called "java". Open source the test-suite itself. Just about every open-source developer will make sure that his code passes the test suite - else he/she will need to call his application "lava" based. :-)

  And about M$ - pleeeez - do you really think they are going to leave their .Net strategy in order to make an incompatible Java fork, that couldn't be called Java ?

  I actually fail to see any convincing reason offered by Sun as to why they don't want to open-source Java. Forking is not a problem, Control is not a problem - they can keep control over the specs.. .what else ?

  Posted by: lenkite on July 29, 2004 at 09:45 PM

• same old rethoric regurgitated...
  "spawning 100 incompatible "open" versions"

  C'mon. That's silly.

  What open source languages can you think of that has "100 incompatable versions". There's 1 dominant C complier, 1 dominant C++ complier, only 1 perl, only 1 python. Where standards exist (C99, C++98), the compatibility comes from the standards; just as it will for the Mono implementaiton of C#.

  Clearly GCC, Perl, Python, and G++ have *FAR BETTER* "run-anywhere" properties than Java, considering they run fine on ARM, MIPS, etc as well as BSD, Windows, Hurd.

  The big risk is not "100..versions", it's 2 versions -- the J#/J#.NET/C# family from Microsoft and Java from Sun. And that battle is better thought _with_ the open source community (IBM included) rather than against them. It saddens me to think that Sun's stubbornness will drive the open source community straight to Novel's C#/.NET camp rather than Java which at one time had a substantial lead and that I spent many years learning.

  Posted by: ramayer on August 01, 2004 at 06:21 PM

This work is licensed under a Creative Commons License.