By Jake Edge
March 30, 2011
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:
We didn't want to think
about what it would take for the same software to run on phones. It would
have required a lot of additional resources and extended our schedule
beyond what we thought was reasonable. So we took a shortcut.
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 ...
(
Log in to post comments)