Google Issues Cease & Desist to Open Source Android Developer

Android MODer issued Cease and Desist order

Last week the Android world was delivered a heavy blow. What happened? Did oft-blamed Microsoft slay the open source darling of the mobile world with a better release of Windows Mobile? Hardly.

Did Mr. Jobs’ return to the helm at Apple mark the end of Android’s honey-moon ride? Nope, sorry Steve.

Did major manufacturers decide to drop Android from upcoming device releases? Not that I am aware of.

The shot heard round the mobile world was from within and could easily be classified as “friendly fire”. The blow came from Google itself. Here’s a very quick summary of what happened.

The Android programmer who goes by the handle “Cyanogen” was issued a legal “Cease and Desist” order from Google’s legal team. Cyanogen is one of the numerous programmers who have embraced the open source Android project with vigor by downloading the Android source from the Android Open Source Project’s repository and actually improved it. Did anyone notice? Yes — word has it they there are over 30,000 active users of his code. The problem is, Google doesn’t like it when their “closed source” applications are redistributed. These are popular “built-in” applications such as:

• GMail
• Application Market
• Google Maps
• YouTube

The reaction from the Android user and developer community has been significant — emotion is running high. Some are warning of a coming Android Apocalypse, vowing to never purchase another Android device again and switch to Apple’s iPhone. Some are “threatening” to perhaps go back to a non-smartphone altogether! Others are laying the case that Google should not sue this developer but rather hire him to work for Google. That idea is countered with the thought that hiring Cyanogen would be the worst thing to happen to the Android community because that would prevent him from releasing his code.

There are of course some more moderate voices in the debate as well. These voices are laying out the case that Google never distributed the source code for their “applications” but only for the Android operating system itself — therefore Google is well within their rights to lay claim to their proprietary code. The implication is that if the source code was not released, but only the binaries for their application, those programs are not open source and therefore cannot be re-distributed without “written consent”. No doubt this is in the fine print already. If they let Cyanogen get away with releasing their “closed source” applications what is to stop the next programmer, or even manufacturer from doing the same? Legal precedents and all of that. I am far from a lawyer, but from a legal perspective this is probably an accurate interpretation.

Opinions abound and are free for the asking — unless they are from an attorney of course. Setting aside for a moment who is right and who is wrong, let’s take a moment to talk about what it means to build a MODified Android ROM in the first place.

What is MOD-ing anyway?

What you think of “MOD-ing” might vary depending on where you sit and from where you draw your income. The technical description of what Cyanogen is doing is rather simple — though non-trivial for the casual observer as they say. Android source code is available for download and building. In fact, the Android project has been lauded for its “open” approach to development. Download the code. Build it. Improve it. Enjoy it. Share it. It’s the “people’s code” after all, right? Well, that is just what Cyanogen and many others have done. He downloaded the code, improved it and shared it with others. And he’s not alone — there are many such MODified ROMS in the wild.

The changes made by the MODi-ng community are significant — things like improved application launchers, running applications from SD cards, tweaked CPU optimization, enhanced access to APIs and file systems. This is powerful stuff — and users love it. Application developers love it too because they can build apps that leverage this new functionality. When code at this level is modified, you cannot simply download an application to the device and casually install it — you must re-flash your device with an “image” of the code because low-level drivers must be installed. Doing this means getting low-level control over the device — often called “rooting” the device. Does this kind of thing help Android? In a word — absolutely.

Open source means more than freedom — it means speed. When Google, or any major software vendor, releases code they have to “get it right” the first time. Or at least make every reasonable effort to do so. This means more layers of quality assurance, documentation, support and even a coordinated marketing effort. And don’t forget the layers of “organization” that lends itself to slower decision making and CYA’ing. And of course, it takes a large budget to support all of this infrastructure and process.

Let’s consider someone in the open source community releasing code — there simply is a different expectation. The code is expected to work, and even be very good. However the consumer of Cyanogen’s code — or anyone else on the MOD scene for that matter — is going to have a much higher tolerance for pain than the average T-Mobile G1 customer running the latest release from Google. If a release turns a device into a brick or a new feature is requested, the open source programmer can fix the code, add the feature, and then re-release the code. No need to run everything past the legal and marketing departments! Ah, the beauty of open source innovation and the intrepid pioneering users who shun the fear of bricked-devices and install build after build of code — they are the test-pilots who help push the envelope to better and better software. In the end the platform is greatly improved over a “stock” build of the operating system and the envelope is pushed. This is what everyone had in mind when Android arrived on the scene, carried on the shoulders of “do no evil” Google.

So what is wrong with this? So far so good?

The problem is that people like those built-in applications also. Imagine running an Android device without email, YouTube, maps or market? The new code delivered in the MOD may be awesome, but without the core applications the device would feel naked. So, Cyanogen simply “included” those applications in his ROM images. He even included the new Android Market application — before Google did. Oops. Someone’s upset — Google did not authorize the re-distribution of their code and now they have to do something about it.

Even though the (binary) code is found in the repository they make available, MODers are not allowed to distribute it. Here is an interesting thing to ponder: in order to have an Android device upon which to install a MOD, the device previously had a “licensed” copy of those built-in applications. Of course, Android will be popping up on other devices so this argument may not hold water before long. This is getting confusing.

So, Google issues a Cease and Desist and everything erupts. What next?

Practical Implications and Unintended Consequences

What does all of this mean? Hopefully cooler heads will prevail in this — and my guess is that if nothing else, Google will improve their communication on what is and what is not permitted with their code. MODing will continue and the boundaries will always be tested. That is what boundaries are for anyway — and all the more in the rapidly changing landscape of an open source mobile platform competing in the turbulent wireless industry. Some will find the boundaries too much and they will go “underground”. From all appearances Cyanogen wants to play by the rules. Time will tell. If nothing else, he’s received his “15 minutes of fame”.

The Android community loves Android as an open source product — but we want, no, we need Google to succeed commercially. Without Google’s pocket-book power, Android would not be what it is today and we would not have the opportunity to have this discussion in the first place. In fact, if you are reading this President Obama (ok, of course he isn’t reading this…), I don’t even mind if Google generates an obscene (legal) profit. The more successful Google is commercially the more they can pour back into the platform and the community. So I think this is a good debate and we should use this opportunity to move things forward constructively.

The hope is that innovation is not unnecessarily stifled in the process. There’s the rub. Can Google succeed commercially by protecting their interests and at the same time keep Android open source? I think they can — though Google needs to consider the perhaps unintended consequence of turning people away from Android by their actions. Life is full of these unintended consequences and Google is walking a fine line. They are not asking me what to do, but if they were, here are my brief suggestions to Google:

1. Be clear about your licensing terms — and do so in plain language, not lawyer speak. Give examples. Use pictures if you want. We’ll understand.
2. Invest in an environment where MODing can avoid going under-ground. Embrace it, don’t fear it. Encourage innovation. The Android Developer Challenges are great — let’s do similar things for low-level stuff, not just applications.
3. Make a clear and public commitment to incorporating MODer code as often as possible. The result will be a far improved platform. And it will broaden the fan base — something every new platform needs, no matter how deep your pockets are.

I’ll let you know if Google calls and asks for my advice. Don’t hold your breath. In the end, this is a growing pain and Android fans everywhere should be pleased that Android is important enough to fight over commercially. Android has arrived.