Toward a freer Android

The dust has mostly settled after Google's shutdown of the Cyanogen build for Android phones. Nobody can really dispute Google's core claim that Cyanogen was redistributing proprietary software in ways not allowed by the license. But numerous people have disputed Google's good sense; those applications are freely downloadable elsewhere and can only run on phones which already shipped with a copy. So shutting down their redistribution does Google little (if any) good, but it has had a harsh chilling effect over the enthusiastic communities that were promoting Android and trying to make it better. Now those communities are trying to regroup and continue their work, but the rules of the game have changed.

The most community-friendly representative within Google has long been Jean-Baptiste Queru; he clearly puts quite a bit of time into helping other developers work with Android. He is now at the center of an effort to turn Google's "Android Open Source Project" (AOSP) into something deserving of that name. Jean-Baptiste has (belatedly, one might say) figured out one of the major obstacles to contributing to the platform: the difficulty of actually running one's changes.

Anybody who has tried to build and install Android knows that this "out of the box" experience is certainly not available today. Part of the problem is the massive size and complexity of the Android platform as a whole; there is not a whole lot to be done about that. But even owners of the "Android Developer Phone," who might reasonably expect to be able to develop for their phones, have to locate a set of proprietary components and incorporate them into the build. And then there's the problem of those proprietary applications. A purely-free Android build lacks the maps, gmail, calendar, and market applications - and the synchronization backends which keep things current with the mothership. Such a build does not equip a handset to be "usable as a day-to-day phone."

The first step, according to Jean-Baptiste, is to get to where an Android build just works on the target hardware - the ADP1, naturally. Once the hardware-level hassles have been overcome, it might make sense to talk about filling in the missing applications. But until developers can easily create a build that runs on a real handset, there's not much point in looking at the bigger goals. With the upcoming AOSP 1.0 release, it looks like this preliminary phase is nearing completion.

Solving the rest of the problems should not be all that hard. If the gmail application never becomes available, mail can be read through IMAP instead - and that might just inspire some people to help improve the somewhat painful email application currently shipped with Android. There is a lot of interest in free mapping utilities, including tools like AndNav which have the potential to surpass Google's maps program. AndNav works from OpenStreetMap data and has the ability to do turn-by-turn navigation - something that the Google tool is unlikely to ever be able to do. SlideME has been offered as a free replacement for the market application. And so on.

The harder part might be the tools requiring synchronization with Google's services; those protocols are not always open. It has been made clear that the Android Open Source Project - hosted at Google - is not going to host software developed for reverse-engineered protocols. So, if Google continues to refuse to make the gmail, calendar, and market backends available, those applications simply will not be supported in free builds. There is, of course, nothing preventing the implementation of applications which synchronize to services hosted elsewhere.

The other place where Google will make its presence felt in this project is with licensing:

GPLv2 might be allowed for new components, maybe, but given the extent to which Android has gone out of its way to avoid GPLv2 software as well, it could still be a hard sell.

Those looking for a more independent effort may be interested in the Open Android Alliance, which is working to make a fully-free version of Android outside of Google. The Alliance's project page (on Google Code, ironically) states that new work will be licensed under GPLv3. It looks like the developers behind the Alliance are not strongly tied to that license, but there are certainly developers out there who would like to see some sort of copyleft license used. If Google is going to hold back and make them reimplement applications, they reason, Google should not be able to take the resulting code and distribute it as another proprietary application.

The Open Android Alliance has a number of developers who are said to be working on various aspects of the problem. It does not, however, appear to have a mailing list or any code available for download. This is a newborn project; its long-term viability is yet to be determined.

What is clear is that people take the "open handset" idea seriously. It is not enough to dump a bunch of code into an online git server; many of us actually want to mess with our devices. Google, perhaps, is starting to understand that, even if it is still having a hard time balancing pressures from the development community, wireless carriers, hardware manufacturers, and its own lawyers. It is not yet clear whether that understanding will translate into sufficient openness for the Android project, but it appears that things might be headed in the right direction.

It seems that Linux World Domination in the handset market is within our grasp. But which Linux distributions will participate in that success? There are a number of Android handsets out there, but there are still more based on other Linux distributions and the LiMo platform. Soon (not soon enough, for many of us) there will be Maemo-based handsets to play with, and it would not be entirely surprising to see Moblin-based handsets in the not-too-distant future. Some of these platforms will do better than others in the market. It may well be that the platform which is the most open, and which draws the most developer interest, will win out.