GPL + Sun + Java = Try Before You Buy?
From early on (pre-GPL Java) in the development of the BUG we realized that Java-like language features would be a great help to us in providing a consumer electronics platform that is easy to use and modify. In general, we wish to openly enable more people with different skill-sets the ability to create custom consumer electronics devices and applications. Here are some reasons why Java makes sense:
1. There exists a large base of people that can write Java programs.
2. The "Write Once, Run Anywhere" design of Java side-steps many of the pitfalls of traditional embedded development. By simplifying how applications are written, built, and deployed to BUGs, a larger group of of people can participate.
3. A large pool of existing applications and libraries are available, both open source and commercial, that could possibly be combined with BUG to provide rich functionality.
4. Java has a wide variety of rich tools to develop and debug applications, making the process of building software easier.
5. Sun and other companies and institutions have spent a great deal of time and effort on making Java run well in small systems.
6. Unlike many older languages, rich networking support was built in from the beginning.
We experimented with various other languages that had some of these features, but in the end nothing else really stacked up. So we created some early proof of concept systems involving JamVM and GNU Classpath and were pleased to see that open source Java worked and looked to be stable enough for production use. And then, of course, came the Sun announcement that Java ME was to be released under the GPL. We watched with great interest as the phoneME project emerged as open source Java for small machines. We began working with it and found it to be extremely mature and well documented. The development team at Sun have been extremely helpful and diligent in supporting FOSS folks.
So we plowed ahead, building our application layer on top of phoneME. A little JNI here, a little OSGi over there. Everything was coming together and the product matured to the point that we were ready to begin the process of validating our system via TCKs. TCKs are test suites used by Sun and other companies to pass or fail a given implementation of a specification. The are necessary to ensure that different products have consistent behavior. In essence they enforce the "write once run anywhere" design goal. We had a conversation with Sun that went something like this:
Bug: "We use your open source Java product and want to validate it. We want to be able to say it's Java. What are time and cost constraints?"
Sun: "Great! We love the open source community. Please step into our commercial license so we can proceed."
Bug: "Umm...we can't have a commercial license. Our product is completely open source."
Sun: "We're working on our open source validation process. Let us get back to you when we have something in place. Are you sure you don't want a commercial license?"
Bug: "Well, can we pay you for the validation and stick with GPL PhoneME?"
Sun: "Nope, TCKs are only available with a commercial license."
So here we are, a pure open source software stack using GPL'ed Java from Sun without the ability to validate it or even call it Java. What are our options? The same options we've always had with other OSS Java implementations: don't call it Java. We could also utilize another implementation such as JamVM with GNU Classpath, Harmony, or one of several others. As it stands the quality of the Sun implementation and the engineers behind it make it a very good choice, but once you remove the feature of "Java from Sun", other implementations begin to look more attractive. Given the simplest solution, don't call it Java, it seems that Sun is almost ensuring that fragmentation will occur. We have to call it something..perhaps "anything but Java" (abJ)? And without tests how can we ensure compatibility? Of course we can't. Without validation from Sun, we'll need some kind of validation from someone like Apache Harmony or GNU Classpath. Validation is important because it gives us the ability to isolate our bugs from class library and JVM bugs. Sun of course is the gold standard but both GNU and Harmony have validation strategies that look to be effective.
In open sourcing Java, Sun wishes to increase it's usage and popularity, get help from the FOSS community in expanding and enhancing it, and be a successful commercial company by doing so. As it stands now there is a road block in that no community-driven phoneME implementation can be called Java, nor can it be validated against Sun TCKs. Is GPL short for "Try before you buy" at Sun? If Sun truly maintains the Java trademark to ensure that the product does not become fragmented it MUST provide TCK and branding options for GPL PhoneME, otherwise further fragmentation is inevitable.
