The Android mobile phone software platform from Google has some journalists and developers confused due to its license terms. The terms are open source, but not as free as the GNU General Public License. That decision has people wondering what Google’s up to. I have a theory about why they did this.
Android is a full software stack made up of many projects that exist separately from Android. The components of this stack are available under a variety of different terms: Linux is GPL’d; WebKit is LGPL’d; SQLite is in the public domain; FreeType is available via GPL or its own license. There are probably a dozen more little libraries and components that Android builds upon, all of which have licenses that need to be considered. It’s not possible for Google to just put a bow on the whole stack and say it all uses license X.
Google has released the Android SDK, which is the top layer, under the Apache license. According to the OSI list of approved open source licenses, this is an open source license. And yet, the reaction to Android from open source advocates is negative. Why? Well, the concern is that some implementation of Android will add proprietary code and/or remove standard code, fragmenting the platform. Since Google can’t rewrite the licenses of the underlying components of the stack, we’re really talking about fragmentation at the top layer of the stack.
The Apache license allows for parties who download the source code to alter it and then keep the altered source code secret, while distributing a derivative work. Contrast this with the “viral” GNU General Public License, which obligates all parties who modify the source to either keep the modified software completely to themselves, or to distribute the source if they distribute a derivative work. Ignoring the case where a licensee simply keeps the derivative work to themselves, the GPL forces a web of innovation and collective advancement, whereas the Apache license encourages a central publishing model, where innovations are kept private and used for competitive gain.
Thus, Android applications designed to be compatible with Google’s platform could be made incompatible with a particular device, by a handset vendor who removes core Android APIs and replaces them with their own closed source alternative. This might seem like a paranoid fantasy of a small clan of open source zealots, but it’s not. This is the same tactic that Apple has successfully used to keep Mac OS X closed. Mac OS X rests upon a large amount of open-source code (some of which is also part of what Android is built upon), while requiring developers to code to Apple’s proprietary Cocoa APIs in order to make Mac apps. You can install Linux on a Mac, but then you lose the ability to run Mac OS X apps. You can build generic Unix applications on a Mac, but they look quite different from a standard Mac app, and lose a lot of Mac-specific functionality. Apple chose to make this possible, but compare this with the iPhone, which uses much of the same software underneath, but (as of this writing) cannot run a generic Unix app because Apple doesn’t want you to do this.
This same sort of situation is possible with Android under this license. Company X grabs the Android sources, dumps a few key APIs (maybe the GUI, network, and process management ones) and suddenly they have their own incompatible platform that can run on the same hardware but can’t share apps with the mainstream. Dump phones on the market (subsidized by monthly fees, as usual) and fund a few key apps (MP3 player, movie player, email/SMS, web browser) and users are stuck with that vendor’s offering, just like they are now. And this is just how telcos and media companies, both of whom are desperately trying to keep hardware and software platforms closed, think. The more closed a platform is, the more secure they feel about their profits, and the more willing they are to invest in it.
The only charitable explanation I can think of for why Google chose this license is the Apple explanation.
If Google were really pandering to the existing mobile carrier crowd, they could simply have released nothing, because another closed platform to build phones with and to write apps for is pointless. There are plenty of existing trunks to be locked in already. We don’t need somebody else to slap together a Linux distro for phones with a closed GUI on it. You can to go LinuxWorld Expo and probably find two dozen companies doing exactly that, and none of them is particularly successful. Google is too smart to add itself to this list of flops. It makes no strategic sense.
More likely, I think, is that Google intends to be Company X in my above scenario, putting themselves in the role of Apple by making an “Android Plus” premium platform that they put on the handsets they’re pushing. In this scenario, you can write your own apps to the reference platform and they’ll run on Google’s favored phone, but Google can still reserve the right to put all sorts of funky stuff on their phones without documenting it or giving developers or users any rights to it, and more importantly, without having to open source their special components so that non-Google devices could use them.
Sure, this is a charitable interpretation. They might just have screwed up royally, buying a company (Android) that wasn’t anything special and releasing something that no one other than journalists will pay attention to. But given that Google is betting $4.6 billion on the 700MHz spectrum auction in the U.S., I’m reluctant to simply write Android off as a “hail mary” acquisition.
There must be a larger strategy here, and I suspect it’s Google putting itself in the shoes of mobile carrier, handset OS maker, and service provider. Somebody else manufactures the handsets, of course, but Google owns and operates the whole experience from end to end other than that. You buy a Google device, pay a monthly Google subscription fee, your bits travel over a Google global network of wireless towers and a wired backbone, and you run apps on your Google phone that interact with Google back-end services. It’s a carbon copy of Apple’s iPhone/iTunes strategy, without AT&T in the picture, and with third party apps allowed on the phone, as long as they work on the already-published Android SDK. All Google has to do is to make a decent looking device and be less customer-hostile than existing U.S. mobile providers, and they’ll do well.
In this light, the partnering talks with existing mobile carriers is puzzling. It’s possible that they’re pitching a strategy that removes the burden of application development from mobile carriers, allowing them to be the billing companies that they really are, and putting Google in the position of being the provider of content and software. The lukewarm responses from these carriers is predictable; for the carriers to be involved as just bandwidth providers and customer billing service providers, there would have to be a careful negotiation of revenue sharing, or else the carriers will simply continue on their current, very lucrative course.
If they are planning to become a carrier themselves, then nothing can actually begin to happen until January, when the 700MHz spectrum auction actually takes place. There’s a closer December 3rd deadline for Google to reveal their plans. At that point we’ll know what they’re up to, assuming they’re actually able to buy the spectrum that would make it possible. Alternatively, this spectrum purchase could be a bargaining chip on Google’s part, which they do not intend to directly utilize themselves. Google would provide the spectrum, the handsets, the OS, the apps, and the services, and the carrier partners would provide the towers, the maintenance staff, sales, and billing.
Given all this, it makes little sense for Google to GPL the Android platform. They need to own it so that they can assure a prospective carrier partner that they will be the ones whose phones are being used by customers, in order to share revenues. If they were to open up the handset market entirely, the carriers would block any new entrants and Android based phones would be doomed.