WebMink
Simon Phipps's personal commentary

"The need to optimise that trinity and maintain the greatest freedom for the greatest number is, by the way, probably the reason there's no open source implementation of Java yet."
What about Kaffe? JBOSS?
 

> What about Kaffe? JBOSS?

Hey, I can't win :-) When I point out that there are already open source implementations of Java out there I get jumped all over by people who insist that Sun does one!

Yep, Geronimo, Jonas and JBoss all aspire to being open source implementations of J2EE, and Kaffe has historically been available too. You (whoever you are) hint at the real deal - that Java is actually a whole suite of standards defined by a community and since the recent JCP rule changes freely implementable as open source.

The question in the minds of those actually in a position to seed a full and current implementation of J2SE (and I personally believe there's more than one party in a position to do that, and that each party is faced with the same issue) is how to create a source tree and license that nonetheless maintains compatibility. Sadly there was no room left in the OSD for compatibility as it was purely about maintaining developer rights, so anyone who acts responsibly will have to be inventive to create this balance.
 

I think you've hit on something there. Our freedom[0] is a function of our occupation, or outlook on life. As an Architect, I care about what my choices are. As a Developer, I care about my ability to tinker. As a designer, I care about my ability to grok the design. As a Writer, I care about the ability to access, and control my writings. As a consumer, I'm keen on not getting milked on license fees every year for an appliance I already own.
 

Sorry for posting anonymously, but the Indemnification clause in the TOC of the site is not something I'd sign without need. So you'll have to trust me that I'm Dalibor Topic from Kaffe.org ;)

"The need to optimise that trinity and maintain the greatest freedom for the greatest number is, by the way, probably the reason there's no open source implementation of Java yet."

Well, I think one of the main problems there is that the licensing terms for the documentation to the JDKs are contrary to the free software development model.

Judging by http://java.sun.com/j2se/1.4.2/j2sdk-1_4_2-doc-license.html I am under an implicit legal threat from Sun for working on Kaffe, a clean-rom implementation of a runtime for applications written in Java.

* Kaffe does not implement all of JDK 1.4.2. Well, yeah, free software is developed in the open and refined gradually. If you can make the x-thousand classes from the JDK spring out from your head like Athena from Zeus', I'd like to buy you a beer. ;)
* I'd therefore assume that it does not pass the JDK TCK, which is unavailable to us mere mortals anyway under an acceptable, GPL-compatible license, if it is available at all.
* It implements classes in the Licensor Name Space that are not defined by the Spec, like java.awt.peers, that are referenced all over AWT but are never actually specified. It's impossible to implement the AWT according the the API specification without them.

The JDK API specification license terms are drafted that way that it's impossible to write an implementation from scratch without infringing on the license terms. So it takes a certain kind of courage to attempt to do it anyway, which is getting rare in today's sue-happy world.

I have a lot of respect for Mono and dotGNU developers for going ahead despite Microsoft's implicit threat of ruining their lives. The .net runtime implementors have the slight advantage that they don't have to compete for developer mindshare with Microsoft on non-Windows platforms. Whoever wants to run .net on Linux will turn to Mono and dotGNU and offer their help.

In Sun's case, there is a very nice free as in beer runtime implementation available from Sun, and that's apparently good enough for some people. For many of those for whom freedom of speech matters more then free beer, the licensing threats that surrond the platform are a big blocker to contribution. Less legally burdened platforms, like Python, Perl, or even C and C++ seem to be a much safer investment for developers that care about freedom of speech. The minority that cares both about free speech and about Java is doing a lot to create good runtimes and class libraries. But as long as the stakes of entry to the playing field remain as high as they are now, chances are that we will remain a minority.

So there will likely be no open source implementations of Java(TM) in the future, either. Noone wants to infringe on Sun's trademarks. Noone wants to provoke the wrath of the army of lawyers that have beaten Microsoft. Even when (one fine, not-so-distant day) Kaffe is able to run all applications written in Java perfectly and implements the JDK x.y.z specification better then Sun's own JDK [1] ;), I'll insist on saying that Kaffe is not Java.

I believe that begging Sun to open-source their JDK implementation is pointless (and humiliating). The only way to gain freedom 0 for Java is to write our own, from scratch, and make sure it is the best thing out there for running applications written in Java on all platforms imaginable.

Sun could help us by making clear that they see free runtime implementations as a welcome addition to the Java ecosystem. Or as a threat, if that's the case.

You see, I believe that free as in speech Java runtimes have the same potential to push Java runtimes ahead as free as in speech Linux did with Unix-ish operating systems. The interesting innovation is already happening without the explicit need for Sun's blessing: binary compatibility ABIs for ahead-of-time compiled Java in gcj, running Java code on .net using IKVM, state-of-the art research on JITs and garbage collection being done on SableVM and JikesRVM, ... I really hope that Sun can find a new formula to 'optimize the trinity of open source, standards and portability' as you seem to put it. I'm afraid that if they don't manage to find an acceptable formula, Sun might turn into an IP company instead of an IT company, just like SCO did. So if they need help finding a suitable bit of magic, they may want to get in touch with FSF and OSI, these guys know a lot about the value of freedom as in free software, open source, standards and portability.

[1] Which it already partly does, judging by Mauve, the independant, free software Java API specification test suite ;)
 

Thanks for the posting, Dalibor - I'll choose to trust :-)

The thing I've been trying to point out for some time is that there's no essential conflict of intent here. Sun has been trying for years to find a meeting point of freedom 0 for individual developers, freedom 0 for end users and freedom 0 for software vendors. To optimise each it has so far seemed neccessary to encroach slightly on each, but pragmatically the result in the case of Java seems to have been to find a sweet spot given the market that's been created.

The fact is, no-one wants to sue kaffe.org (at least no-one I have met - if you've had letters let me know) but the license has to leave that right in order to create freedom 0 for end users and software vendors - the freedom of choice of multiple, compatible implementations. The
really, really hard question, the one no-one from OSI or FSF has been willing to even consider seriously yet in my hearing, is how to create OSI/FSF licensing that honours compatibility and yet facilities community-based open development. In my view the OSD ignored the problem back in 1999 despite it being obvious (at least I hope that was all there was to it), and that's what lays at the heart of the incompatibility with open source, not Sun's intransigence necessarily.

I and others have had long discussions with both FSF and OSI (a Sun employee is on the OSI board and Sun is a sponsor of FSF) but the fact is that there's a philosophical difference here about how to maximise freedom for all. Sun's intent is freedom, just as it's the intent of FSF and OSI, but the precise way it's defined philosophically leads to differences of execution.

Open source re-implementations of Java reference implementations and open source reference implementations of new JSRs where that is the choice of the spec lead are not just welcome, they lay at the heart of all the hard work that's gone in to create the JCP 2.5 and JCP 2.6 rules and are intended. In particular, the Jonas, Geronimo and JBoss projects are all highly valued.

I recognise the issue you raise over SWT (it's also the case with Swing I believe) but the reason it's there is that no-one was able to justify the huge cost of creating the test cases for those areas of the JDK - it's not a conspiracy. Sun is in my view going to have to do something about those to satisfy the JCP 2.6 rules; I know what seems obvious to me...

I'd love to talk more - can you get in touch by e-mail please?