Google, Android and licensing bypass strategies
I’m in the process of writing a master thesis for my school. After some mail exchanges with my tutor, I chose to study Android’s model, specifically how and why Google has altered it from the early days of the AOSP project. I will be regularly posting about my research and updates to my (humble) research.
As most of Android fanboys know, the AOSP project lost its lead developer (Jean-Baptiste Queru) some time ago last year because of frustrations and legal issues (Qualcomm not opening its GPU driver’s source code, among other things). It seemed to me at that time that the initial Android value proposition was less and less about a mobile OS opened to OEMs and more and more about Google in your pocket.
Winding the clock back a couple of years, Android’s value proposition could be broadly summarized as follows: an open, fully customizable mobile OS that OEMs could port to their devices free of charge and hassle. To promote Android, Google teamed up with OEMs, software and hardware vendors as well as carriers to push the platform forward. Roughly a year after, Google started its own Nexus program, showcasing devices developed in cooperation with a manufacturer (the first one being HTC) that were targeted at developers and fans and were supposed to show other OEMs how to build a good Android device. Android phones manufacturers like Samsung, HTC and LG took part in the Nexus program but still added their own software layer upon the AOSP codebase to differentiate and build a competitive advantage. They could, because the AOSP codebase was so complete that modding/theming/adding to it (and even replicating functionalities like Samsung does) was the natural way to go. In other words, no essential part of the OS was missing from the AOSP codebase and OEMs could make an Android phone the way they wanted (provided the phone came preloaded with Google applications like Maps, GMail and Search).
Recently leaked Android OEM licensing agreement for 2011 show a picture very different from the openness claims. What we see in 2013 is a dramatic shift where Google does not update AOSP functionalities but rather packages updates in the form of applications, exclusively distributed through the Play Store. The calendar application, search application, even the keyboard are now Google Applications, and versions included into the AOSP code are deprecated. Other functionalities such as Google+ login or the Google Play Games functionalities now require a proprietary Google API that is kept out of AOSP. Some days ago, Google released its “Google Now Launcher” for all Nexus devices, providing its “Google Experience” to all Nexus devices. I think this is the direction where Google is headed with Android.
Any Android sales pitch is always sure to mention that Google’s OS is “free and open source.” The reality is that while the core OS is open source, all the Google-branded apps that Android relies on to be a useful, competitive operating system are not part of Android—and not open source.
Of course, Google is free to choose what it contributes to AOSP. Updating core elements of Android outside of AOSP and packaging them into Apks does not break the letter of the Apache 2 license. And of course, Google still pushes crucial code to AOSP, like the new Android Runtime. It is an interesting move though because it shows that Google is willing to go to lengths to control Android. Giving an OS for free to OEMs with a license to do whatever they feel like with it could be dangerous, and in that regard, Amazon’s fork of Android could have triggered the decision to keep key Android features out of AOSP. Could Google have felt threatened by the Kindle Fire ?
Hopefully, this has no effect on the custom rom community (CyanogenMod especially), one of Android greatest asset. While built on AOSP code, custom roms generally do not include Google Apps (which you can always flash and install these applications separately, and use Google’s web services on your phone).
The result of this, nevertheless, is that Google is in my opinion actively bypassing the spirit of the Apache 2 license. The coming months are going to be interesting in that regard. Will the AOSP codebase still lack functions compared to the “Google Experience” Android builds? And will Google push this “Google Experience” to all devices at the risk of and OEM revolt? Will Google euthanize AOSP?