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.

Share and Enjoy:
  • Digg
  • Facebook
  • Mixx
  • Google
  • E-mail this story to a friend!
  • Live
  • Ma.gnolia
  • Reddit
  • Slashdot
  • SphereIt
  • StumbleUpon
  • TwitThis
  • YahooMyWeb

29 Responses to “GPL + Sun + Java = Try Before You Buy?”

  1. Kevin Says:

    I guess I don’t fully get the point. I have built lots of stuff on Java (enterprise/web/PCs not phones). Java is free from Sun. Lots of GPLed software runs on Java. Is your stuff different because you want to ship the JVM on a device?

  2. Ken Says:

    Kevin, you are correct. While the Java source code is free from Sun, it is not possible to create a product with it in its open form. A commercial license must be purchased. This issue is mainly relevant for those wishing to extend it or ship a product with it.

  3. Dalibor Topic Says:

    I think you simply landed in a corner their business plan didn’t foresee, as most embedded vendors seem to have a love/hate relationship with the GPL (and I assume the ME implementation has been targeted for that market), rather than a love/love one, like you do.

    I’d suggest pinging Mr. Schwartz about it. It could be an interesting area for Sun to expand its services in, I guess.

  4. Dalibor Topic Says:

    Oh, and japitools are a too weak compatibility statement, unfortunately. They can only tell you that an implementation of API exists, not that it is behaving in the some specification compliant way.

  5. Benjamin Stein Says:

    I agree – you should ping Jonathan Schwartz about this. Exactly the type of topic he likes to write about (and someone who can actually change policies). I blogged about your story in contrast with his most recent post:

    (Not showing up in the trackbacks, for some reason…)

  6. anonymous Says:

    The key issue here appears to be that the lack of availability of TCKs really accelerates fragmentation. The community is free to go off and create derivatives of the phoneME stack but can’t test compatibility without paying a lot of money for a commercial package. That’s bad for everyone in the Java ecosystem, including Sun’s commercial business (which derives a big part of its value from Java being a widespread and fairly consistent platform). I can only assume that Sun’s upper management is not aware of the issue and that it needs to be brought to their attention and will be fixed.

  7. anonymous Says:

    I’d like to add one more thing to my previous post:

    I trust one of the goals of releasing phoneME as GPL was for Sun to increase implementation consistency (reduce fragmentation) by encouraging people to use their bits. That’s goodness because a set of ‘reference bits’ is what the Java ME space has been sorely lacking. The spread of untested phoneME stacks certainly will create the opposite effect: it will promote fragmentation.

  8. Ross Gardler Says:

    Ping Mr. Schwartz?

    Try a web search for “apache tck open letter”

  9. Henri Yandell Says:

    Me, I’m laughing at “their business plan didn’t forsee”. :)

  10. say Says:

    so who will get Mr. Schwartz to comment… doesnt he run a blog?

  11. Barry Pilo Says:

    Is there any other equivalent in the free software world – is there a compatibility kit for Linux? Or some other example we could cite?

    It sounds like you can ship your product today, without any license from Sun. Is that true?

  12. Ken Says:

    Benjamin: I will try that, thanks for the idea.

    Anon: I hope you are right :)

    Barry: I am not aware of an accurate equivalent. And yes, we could ship our product today with nothing from Sun. But we can’t say our product uses Java. And we can’t test our implementation. We have customized the Java build scripts for our specific hardware architecture so we are running our own binaries of the JVM and class libraries.

  13. Ken Says:

    Dalibor, Thanks for the tip to contact Mr. Schwartz. I wonder if there are other OSS projects out there aiming at better Java API testing…

  14. Dalibor Topic Says:

    While we have mauve as our own API testing project in Classpath, it is not the same thing as the TCK. No independent testing project can give you access to Sun’s Java trade marks, which you seem to need.

  15. Ken Says:


    I’m less concerned about the brand than I am about the risks associated with untested code. Honestly the language and classlib validation is of more importance. And, this is also something that could be at some point in the future provided by an open source project rather than Sun if Sun TCKs remain unavailable to open source Java implementations.


  16. Ken Says:

    I found someone else blogging about the exact same issue almost a year ago:

  17. Ken Says:

    Another useful link to the Sun FAQ on TCKs:

  18. Ken Says:


    I can see after some googling we share two things: concern for open source accessible TCKs and fans of Wir Sind Helden :) I’m now following some of your trails.


  19. Tim Says:

    Some companies (such as Motorola) have made their TCKs available as open source.

    Both their Bluetooth TCK and MIDP TCK can also be obtained at zero cost, so I can use the same tests that everyone else has to use for TCK certification.

    Other companies should try this to seriously combat fragmentation.

  20. Dalibor Topic Says:

    I think that all components of a JSR should be open source, and I’d like to see the JCP mandate it in the future. Unfortunately, we’re far, far away from a majority in the EC supporting that idea (or even a minority ;) .

    But that’s something to work on in the next couple of years.

  21. Michael Says:

    I don’t expect you’ll get a resolution of this from Sun anytime soon. There seems to be a lot of division inside Sun about open-sourcing Java. My sense is that the only reason they’ve done it is to try and convince the linux/gnu/oss crowd to write in Java instead of .net via mono. But they can’t bring themselves to go the whole way.

  22. TinkerTim Says:

    while you try to talk things out with Jonathan Schwartz, I suggest that you read this:
    and remind him of it as well.

    And sure as hell, I’m waiting for the pricing to be put up! This sounds a bit like a Finnish University student’s favourite project that started about 16 years ago!

  23. Michael Says:

    I am curious. Why do hardware people get to charge money, but software gets criticized?

    Are you going to give your products away for free?

    Open source, but charge for service?

    Open hardware, but charge for service?

    Just curious, not trying to be rude. I understood why the original movement took off, but then I see that everyone is making a buck anyway, or asking for money in donations.

    Maybe I do not understand the pricing structure for Sun.

    Are you going to give away anything for free?

    Maybe we should demand free cars too ;-)

  24. Michael Says:

    And to be clear. I hope all the best for your company.

    I worked at a software company for years. I understand that MS dominated and people grew angry at pricing.

    I’m just trying to understand the trends today. I cashed out years ago. Thankfully, no more specs, mods and production deadlines.

    all the best, I think this is a great idea.

  25. Mehrshad Mansouri Says:

    Hey Michael,

    These are great questions and thanks for your kind words. We’re actually planning to address these points in a forthcoming blog post. Looking forward to hearing your thoughts.

    Cheers, -m

  26. Doug Jones Says:

    Might want to take a look at this:

    “Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME”

  27. Ken Says:

    Hi Doug, yeah a friend send that to me earlier today. Certainly interesting! Looks like there is a lot of activity with small Java these days.

  28. Bruce Boyes Says:

    Ken, I share your frustration. We were hoping to be using Sun Squawk in a line of commercial products and ran into the same issues as you… I have to wonder if Android is more what you really want, for the reasons detailed in the mail archives here: – but of course Android wasn’t quite available when you were launching. Or Sun Squawk (although they have the same licensing issues as phoneME). Squawk and Android are very different, and Squawk is very different from phoneME. I’ll be blogging more about all this at in the coming days. My interest is to determine what (if anything) my company should be using in future products.

    best regards
    Bruce Boyes

  29. Ken Gilmer Says:

    Hi Bruce,
    Yes I agree both Android and Squawk are interesting projects. Have you looked into OpenJDK recently? There are now ARM builds that may be suitable for your targets. Despite the FOSS traps in PMEA (JDBC, HTTPS) we have had good experience with the performance and reliability of the JVM.


Leave a Reply