Android and Honeycomb

There's been a lot of press—and hand-wringing—about Google's decision to withhold the source code for the latest Android 3.0 release. There have been claims that Google is (or will be) violating various licenses by doing so. While that claim is overblown, there are still reasons to be unhappy about the choice being made here, while recognizing that it is Google's choice to make.

Business Week broke the story that, unlike previous releases, Android 3.0 ("Honeycomb")—targeted at tablet devices—would not be released for several months, possibly not until the next version ("Ice Cream") is completed. The article quoted Andy Rubin, Google's VP for engineering and head of the Android group, as saying that Honeycomb may not be suitable for phones:

The concern seems to be that vendors might take Honeycomb, put it on phones (or other small-screen devices), and create "a really bad user experience". There has certainly been a number of vendors who took previous non-tablet-oriented releases and put them on tablets with varying degrees of success. Google appears to be worried that the Android brand is being tainted by low quality implementations. That may be true, but there are other ways that problem could be prevented.

One obvious choice is the Android trademark, which Google could use to require devices to meet some minimum standards. Google already exercises some control via its Google-branded Android applications (like Market, Maps, and Gmail) that have to be licensed from the company. In order to do that, a device must fulfill the Android Compatibility Definition. But plenty of low-end phone and tablet makers were willing to forgo those applications, take the source code, and run with it—sometimes with less-than-stellar results.

So, Google has found a different way to enforce its will on device makers that do not directly license code from the company: stop providing the source. Since one of the goals of the project was to "keep the GPL out of user space", that means that the Android user space is licensed under non-copyleft terms. But even if it were all covered by the GPL, Google, as the copyright holder, would not be obligated to release the code. Copyright holders are not beholden to the license they provide to others for using their code.

As it is, most of the code is under the Apache Software License or similar terms, which means there is no requirement for anyone to provide source. The big exception, of course, is the Linux kernel, and one would expect that Google is GPL-savvy enough to not withhold that code. For the kernel, though, the interesting parts are not necessarily in Google's kernel tree, as it is the device makers that add support and drivers for their platforms. As we've seen, GPL compliance in Android tablets is rather spotty, at best, so that's where any license problems are likely to be found.

Part of the uproar about Google's decision is based on the somewhat faulty belief that Android was ever a real open source project. There were high hopes early on that it might become one, and, up until now, Google kept throwing its code over the wall to—more or less—continue the open source spirit of the project. But, unlike real open source projects, there were only limited attempts to build a developer community around Android itself, instead, for the most part, there were just the periodic code drops. Much of the effort was aimed at cultivating application developers, which has worked out quite well. It's hard to say for sure, but one might guess that the openness of the Android code played a role in how quickly the platform was embraced by application developers.

One could argue that Google needed to keep Android development in-house, so that it could keep up with the incredibly fast-paced smartphone market—and that may be true. One could certainly point to MeeGo as a counterexample of sorts, and one that has yet to really produce any tangible results in the form of products for sale. MeeGo clearly has a development community slowly growing around it, even though it is dominated by two (now one, really) companies. While MeeGo is much more upstream-oriented than Android, its governance has been largely top-down. So far, Google's model has been much more successful, but MeeGo is really only a year old at this point.

Google has made a lot of noise about how "open" Android is, including things like Rubin's famous tweet in response to Steve Jobs: "The definition of open: 'mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make'" For Honeycomb, at least for the next few months, that will no longer be true, which is enough to sour some folks on the Android platform as a whole.

Google has evidently weighed the benefits that it gets from opening the Android code—bug fixes, enhancements, good public relations—and found that it was not enough to overcome its concerns. It is unfortunate that we won't be able to see what the CyanogenMod folks (and others in the "mod" community) might have done with Honeycomb, at least for a while yet. There are likely some low-cost tablet makers that could have done interesting things with it as well. While Google claims to be concerned about "user experience", it's pretty hard to read this move as anything other than a tightening of control over the platform. Hopefully, this is just a blip, and things will return to "normal" with "Ice Cream", but the damage may have already been done by then.

Over the last few weeks, we have defended the behavior of several companies (Red Hat and Google) when they have been faced with accusations of license violations. In all of these cases, though, one does not have to like what the company is doing to recognize that it isn't a violation of any licenses. Once again, we would much rather see Google keep the Android project open—or make it even more open—but recognize that it is well within its rights not to do so. With any luck, other open source projects will show the way such that Google finds it in its interests to open up Android further. Time will tell ...