You are only as old as the keyboard you feel

It's easy to forget how young computing is still. Or maybe it's just easy to forget how old I'm getting.

I recently had reason to remind myself about the projects I have worked on in my professional career, and that required some archeology through my old papers and notebooks. What really struck me was how recent the dates appear to be -- surely 1997 wasn't that long ago? and yet 10 years ago we were nowhere near where we are today with the connectivity, Internet, wireless commuting, portable devices, and so on.

If I go further back in time to university, and pre-university days things get really interesting. I really can't remember what prompted my interested in computing, but I recall vividly the trips I made as a schoolboy to the University of Bradford Computer Centre as a guest, looking round the machine rooms and punched tape/card terminals etc.

I took it upon myself to travel on the bus for an hour each way every Wednesday afternoon to use their teletype machines (I bet a random kid couldn't show up and use their machines today!) There was great excitement when they got six Commodore PETs. You could book an hour session on the PET, and I spent many of those PEEKing and POKEing various memory locations described in computer magazines of the day to create some kind of external effect -- and typing in long sequences of BASIC to implement something like the Eliza pseudo-therapist programme.

The first computer that I owned was a TRS-80 portable PC. I remember pestering my dad to buy it for Christmas one year. He is a gadget person, so probably didn't need much persuading really, but he put up a good pretence. That gift probably cemented my future choice of career. I spent many hours programming that thing, and over time I bought the tape deck interface and 16-character per line printer too!

Once things got established I went with my dad to choose a desktop -- and we spent a few hours at a very stylish showroom with four computers proudly on display, spotlit and surrounded by black curtains. We ordered an Apple IIe, and waited eagerly for it to be delivered (you couldn't just buy one off the shelf in those days). It was a great machine. Green screen and limited graphics, etc., but enough for me to write a pretty decent application to track some data on employees and customers in my dad's business. I submitted that application as part of my O-level Computer Studies, the first year it was offered in the UK.

To make a long story short, I later went off to study Computer Science at university, and at some point was the proud owner of an Atari Portfolio. I bought an Amstrad PCW to write up my thesis, and shortly after went mobile with an Apple PowerBook 100, and later replaced the Portfolio with a Palm Pilot (I craved an Apple Newton, but never bought one).

Since then it has been a succession of heartless PC clones, that look really boring and are only differentiated by the chips in them with different numbers.

It's fun to look back and see that old stuff. It brings back many memories of happy hours tapping on keyboards, the people who so generously gave of their time, knowledge, and enthusiasm to help some kid who could give nothing back to them -- which is very humbling, would I be so helpful and accommodating?

And when the time comes to bounce my grandchildren on my knee, I won't be telling them about fighting for my country in foreign lands, or how I had to work my way through crushing poverty through hard manual labour; I'll tell them how I have programmed everything from teletypes to a supercomputers. Will they be impressed? They'll probably laugh.

"Not to go back is somewhat to advance, and men must walk, at least, before they dance."

In my last entry I wrote about Sun's plans to open source their Java implementation, and my speculation about the how? and why? that would happen. Lo and behold, last week there was an announcement that gives many of the details of their open source Java actions and plans.

Sun are re-licensing some of their code under GPLv2 with the 'Classpath exception', and some code under GPLv2 unmodified, into a new project called OpenJDK. The motive appears to be as I predicted -- making Java a viable option as a managed runtime environment on Linux.

The choice of GPLv2 ensures that the license is a non-issue for distributing OpenJDK unmodified with Linux. That said, I have not seen any distro balk at the Apache license for httpd, so there is more to it than that. The 'Classpath exception' is an instrument designed to alleviate the fear that Java applications will be subject to the so-called 'viral' effects of the GPL. This is because it is ambiguous, in some people's eyes, whether Java application code "in whole or in part contains or is derived from" the system code at runtime. The intent is to make the situation for Java equivalent to the goal of the LGPL for dynamic libraries.

The code that has been given the linking exception includes the Java SE APIs, and interestingly the Java EE APIs (which now become dual licenced with CDDL). The Java ME class library, JVM, javac, and JavaHelp code do not enjoy the linking exception.

By drawing the distinction between some code that has the linking exception, and some that doesn't, Sun seem to be acknowledging that Java application code is 'linked' to the system code as described above, and therefore is subject to the viral effects of GPL without the benefit of the exception.

It would appear that Sun recognize the value of Java SE and Java EE as a platform, and the network-effect of a pervasive platform enhances the opportunity to make money indirectly, through services etc. I would argue that Sun could have identified areas of competitive value, say in the VM and JIT, that would play to particular hardware and OS strengths, and been more permissive of ongoing commercial investment in these areas around a shared 'commons'. That would be an opportunity for OpenJDK to compete on performance, reliability, scalability, etc. to the overall benefit of the Java ecosystem; whilst providing a viable open source VM for those that do not choose to pay for the vendors' enhancements. As vendors of these proprietary technologies determine they are no longer providing distinguishing value in these areas, the technology will flow into 'the commons' and the technology moves up a step.

I hope the choice of GPL doesn't stifle such competition and investment in Java, or serve to fracture the Java implementation space and introduce compatibility issues. I'm sure you appreciate that many of the performance advances in those no-cost Java runtimes you have been downloading have been made on the back on the commercial vendors. Competition is good. For now at least, Sun are effectively saying that such competition comes at the cost of a commercial license to the reference implementation codebase.

The stick for compatibility seems to be the JCK test suite. There have been a number of references to threats that people will find themselves in court if they fork the GPL code and try to call it Java without passing the JCK. It's not clear what the future terms of the JCK-availability will be for such forked projects, but I expect that Sun will keep tight control over it. It's unclear to me again how this situation works for distros that build the OpenJDK source to work well with the packages they distribute, or people who innovate in this space -- I hope we do not end up with an equivalent to IceWeasel for Java.

Sun appear to have taken a different approach to Java ME. By explicitly excluding the linking exception for Java ME they are requiring applications and network provider stacks to be GPL'd. Of course, that's not going to happen, so Sun are effectively telling Java ME licenses that it will be business as usual for them, period.

Sun need to maintain the 'business as usual' rule for ME, SE, and EE -- at least for the moment. It is totally understandable that Sun would not compromise their commercial licensing opportunities for their Java implementation. In fact, as a publicly traded company I believe that they could not have compromised that revenue stream. Such companies are obliged to maximize shareholder value. So to maintain that commercial license stream Sun have also specified a contributor agreement for code offered to the OpenJDK project.

The contributor agreement requires that you:

• assign joint ownership of the code to Sun, in copyright and all other relevant intellectual property rights,
• grant a royalty-free, sub-licenseable, patent grant to any inventions embodied in the code,
• allow Sun to use your code in other licensing mechanisms, at Sun's option.

Hmm, that seems a bit one sided doesn't it? Where's Sun's patent non-assertion covenant, or royalty free-licence granted to consumers of the OpenJDK code? What about all the code that has been granted to Sun over the years and included into the reference implementation?

I'm surprised that we haven't heard more about this agreement from the Free Software movement who applauded Sun's choice of GPL. Doesn't FLOSS mean that such code rights should not be granted to a for-profit corporation that reserve the rights to exploit it for commercial gain? Presumably such potential exploitation for commercial gain is ok provided that I can get the code under GPL? And what about the GNU Classpath folk who signed their copyright over to the FSF? It is unlikely that the FSF are going to enter into such an agreement with Sun, so is there a channel for any code in GNU Classpath to make it into the OpenJDK?

Very little has been written about the community that will exist in OpenJDK. Sun are, of course, eager to get as many contributors as possible, and in the future expect to allow members of that community to gain commit rights to the OpenJDK source code. But it has been made clear that the bar has been set very high. Sun cannot allow any opportunity for instability or poor engineering to creep into the reference implementation. So for the moment, all contributions will go through Sun engineers, and the Sun development process to ensure the required quality and standards are maintained. As such it seems very similar to the "JDK-Collaboration" project, only you don't get the T-shirt!

So to wrap up, the first steps have been taken. The OpenJDK implementation is rolling out into a new project. It remains to be seen how the community is built and the effects on the existing open source Java community, the effects on the JCP, and the reaction of the commercial Java implementers.

I'm delighted to see the OpenJDK project take it's first steps. Now let's see this baby dance!

Sun's plans to open source their Java implementation

When you talk about "Java(tm)" what exactly do you mean?

Are you referring to the Java language? the tools in the Java runtime and development environments? or the Java VM and class library specifications (such as JEE, JSE and JME)?

Maybe you mean the eco-system that has grown up around Java, such as world-class web containers, databases, scripting languages, and so on.

The term "Java" means different things to different people. I believe that most people understand that there are many diverse interests within the general community that develop and use applications written in the Java language. I believe that people understand you can get different implementations of application servers and IDE's that have different characteristics and design points. Most people probably know that you can get Java SE implementations from companies other than Sun, such as IBM and BEA who create work derived from Sun's under license. So when Sun says it is going to 'open source Java', we should understand what that means.

Sun plan to open source their implementation of the Java SE and ME specifications (they already open sourced their Java EE implementation as Project GlassFish.) This is a big deal. Sun's implementation is the reference implementation of the specification, and is the implementation that most people have installed on their desktop. Making the implementation open source, under an OSI-approved license as promised by Sun, means that people will have rights and freedoms that they currently don't have, and this is to be applauded.

A large part of the value of Java is its universality. Java is available on lots of platforms, and many interests are represented in the evolution of the specifications through the JCP. It is in the interests of all Java users that implementations are both compliant to the specifications and compatible with each other, so that Java applications really do 'run anywhere'. Apache Harmony is committed to producing a compliant and compatible implementation of Java SE for just such reasons.

So I'm left wondering why Sun have decided to open source their implementation? I don't think I can answer that question until we hear exactly how it will be opened. It comes down to the community model, and the code license and contributor agreement.

Turning to the license first. I mentioned that Sun have promised that the code will be made available under an OSI-approved license, but that still leaves a wide latitude of conditions for adopting and developing the code. It would seem from press coverage and common sense that the principle candidates are CDDL and GPLv2. The decision will come down to the type of community that Sun are trying to attract.

From my reading I believe that Sun are principally intending to make Java SE and ME open source in order to make it more acceptable to Linux distributors, and thereby increase the relevance of Java in that open OS space. I accept that Sun have already made moves to improve Java's acceptance by Linux distros by introducing the Distro Licence for Java (DLJ), but that hasn't been universally welcomed, attracting criticisms from one of the main Linux distributors for not going far enough.

Listening to some of the well-respected individuals at Sun I find it hard to believe that they really will trust the reference implementations of ME and SE to an open source community, where 'community' is defined in terms that you and I would generally understand it. I think development of Sun's implementation will continue as a principally in-house activity, with increased visibility to the changes that are being made to the code, but with very little opportunity for outsiders to earn rights to modify the code directly. The offer of such rights will be there, but the bar will be extremely high, and any contributions that are made will be under a contributor agreement with Sun that gives them copyright assignment rights so they can continue to license the code to companies such as IBM and BEA as I mentioned earlier.

The principal reason Sun are open sourcing the code is therefore to make it more acceptable to the Linux community. My prediction is that Sun will choose GPLv2, with a contributor agreement assigning significant relicensing rights to Sun for code going into the mainstream codebase, and the community around that mainstream will remain very tightly controlled for the foreseeable future. Any fork of the mainstream code will have to pass the appropriate TCK in order to be called Java, and we know that the TCK's are not being opened, so Sun still retain the control point of what can be distributed as 'Java'.

Such a scenario will allow Sun to say quite legitimately that the code is open, and they will do what it takes to make it palatable to the Linux distros; however, Free Software types will not be able to live with a contributor agreement that allows their work to be commercially licensed, and the Apache types will not be able to live with the conditions of the GPLv2, so I expect that both types of existing open source project will be dissatisfied, and we will unfortunately have a third open source Java SE project.

It remains to be seen how the current Java licensees react. It may be business as usual, or they may choose to work in one of the other open source communities. Perhaps it depends upon their current working relationship with Sun, and how they see their future use of Java evolving. In any case, there will be a benefit for all involved in the Java eco-system to continue working together on evolving the specifications and competing on the implementations so that the real winners are the millions of good people who write and use Java on a daily basis and appreciate the choices of implementation within standards that they are being offered.

Now Voyager depart, (much, much for thee is yet in store)

Welcome to my blog -- and welcome to the very first posting on the blog!

Looking at the site settings on blogger.com, I can see that I created my blog site back in July 2004. Back then, blogging was still in it's infancy, and I was interested in what this phenomenon was all about, and how people were using this new medium to publish information that was of great personal interest to them. So why has it taken me so long to write this first post?

Well just like websites in general, the range in quality of bloggers and their blogs is quite remarkable. Overall I've been underwhelmed by the quality of many blogs that I have read, and the implication was always there that I'd do no better (and that still remains to be seen!)

I believe that interesting blogs are those that are both informative and express an opinion. Until recently I was working exclusively on a proprietary implementation of the Java specification for IBM. What "changed" is that IBM decided to participate in the Apache Harmony open source project, and I was lucky enough to be involved in that process. Up to that point it would have been inappropriate, or irrelevant to many people, for me to inform and opine on the issues that were of great personal interest to me.

Being involved with open source is a game-changer. I've worked on projects in collaboration with other companies, and worked in open standards groups such as the IETF, but nothing feels quite like working in an open source project. Open source projects provide a special combination of working on a shared architecture and code base, and working in a broad and liberal community with simple rules of engagement, that I believe is unique.

My first experience of open source was while working for IBM Canada through involvement with the early days of the Eclipse Project and subsequent formation of the Eclipse Foundation. That was a relatively smooth transition of an existing code and community from 'closed' to open development.

Starting to work with Apache was a different experience. It required learning the Apache style of working and interaction, which I had never really appreciated as an enthusiastic consumer of their software. I think I've seen enough now that I get the basics if not all the subtleties.

So now I feel that I can write about aspects of life that relate to a broader community of fellow travellers. Some of my opinions, ideas, and rants are not going to be appropriate to inflict directly on the Apache Harmony development team, who are a great bunch of people and rightly focused on the task in hand. To date it has been my office co-workers (and bewildered family members) who have endured such outbursts. At least now I will have a distinct channel to express myself, and people can make the decision whether to follow along or not.

Let's see if I can beat my current record, and get round to a second posting within the next two years.