[last part of the series on five traits of open source and its impact in the mobile industry. See also part 1, part 2, part 3 and part 4.]
In early November 2006, Sun proclaimed the most significant shift in Java strategy since the launch of the software platform in 1995. The US software giant announced that it is licensing several key components of the Java for mobile (Java ME) and desktop (Java SE) platforms under an open source license. With this move, Sun provides Java ME and Java SE platform reference implementations not only under its traditional commercial license terms, but also under open source license (GPL) terms. Furthermore, Sun has created a web-based repository for open source Java projects (the Mobile & Embedded community), and announced a governance model for it. It is worth stressing that the Java Community Process (JCP), the process by which third parties can play a role in the future of the Java platforms, remains unaffected.
With the open source strategy, Sun s goal is likely to incentivise the industry into adopting a single reference Java implementation and mitigate the threat from rapid market penetration of Adobe s Flash as well as other competing application environments such as BREW.
The fundamentals of open source Java To estimate the implications that Sun s Java open source strategy will have in the mobile industry, we should consider four fundamental elements of Sun s licensing and trademark policies.
1. Sun s choice of GPL license, requires third party modifications to be also distributed under GPL for no charge. This dis-incentivises handset manufacturers from even accessing GPL code due to IP contamination concerns.
2. Sun s open source Java phoneME Feature and Advanced projects are reference optimised implementations, but ones which have not been optimised for specific phone hardware. Handset manufacturers today compete heavily on Java platform optimisation to accelerate the performance of Java applications and games on each handset as a means of differentiation. Even if an OEM takes Sun’s optimised implementation of the MIDP2 JVM, they would have to further tweak the JVM to adapt it to their particular hardware and add own memory or speed optimisations.
3. Sun Microsystems retains a trademark to the Java term and has a copyright on the cup & steam logo. Sun requires handset OEMs and Java implementation vendors to pass TCK certification tests for the base CLDC and CDC platforms (at a considerable cost) in order to be able to claim that their handsets are Java Compatible.
4. Sun’s phoneME GPL branch excludes about 5% of the source code corresponding to ‘IPR-encumbered’ code which Sun does not have the right to release under GPL. This means that you can’t build the full phoneME project from source code.
On the other hand, Sun did a couple of things right: firstly, contributors to the GPL branch of phoneME have to surrender copyrights; thereby allowing Sun to integrate these changes directly into the commercial branch. This prevents the divergence of the two code branches in a dual licensing model, as happened to Trolltech’s Qtopia. Secondly, Sun receives direct feedback from developers and is able to use that feedback within product planning.
Too much an effort, too small a change Overall, I believe that Sun s Java open source policy will change very little in the mobile industry; the choice of the GPL license protects Sun’s revenue stream from licensing of optimised implementations, but scares off handset OEMs (in fact I recently had a conversation with an exec at a top-5 OEM that confirmed just that). Sun does maintain its revenue stream from TCK licensing due to its Java trademark.
Was Sun too greedy to choose the GPL ? Perhaps, as Sun’s optimised implementation is mostly licensed to ODMs; OEMs use their in-house optimised implementations.
Did Sun have any other choice ? Probably. They could have licensed the ‘core’ JVM under GPL and the hardware-dependent code under a non-copyleft license like the Apache license, so that OEMs could optimise for their hardware. When I mentioned this to Sun last week they sounded interested in the idea, but said it might be too complex from an organisational perspective.
I would also argue that Motorola s intentions for releasing Java MIDP3 under open source will likely see more uniform adoption and consistent implementation of MIDP3 across mobile handsets. This is assuming Motorola sticks with its promise for releasing the full MIDP3 source code under the liberal Apache License 2.0; Motorola wants to first test the waters by releasing the code under the Motorola Extensible License, which is a copyleft license. Motorola will also release the TCK under an open source license, which means it will be cheaper for OEMs to certify their implementations as MIDP-3 compliant.
– Andreas
[this article has been updated following a briefing with Sun at the Informa Open Source in Mobile conference]