Linked by Thom Holwerda on Thu 13th Feb 2014 23:38 UTC

Another day, another fear-mongering 'Android is closed!'-article at Ars Technica. After Peter Bright's article last week (sharply torn to shreds by Dianne Hackborn), we now have an article with the scary title "New Android OEM licensing terms leak; 'open' comes with a lot of restrictions".

The title itself is already highly misleading, since one, the licensing terms aren't new (they're from early 2011 - that's three years old), and two, they're not licensing terms for Android, but for the suite of Google applications that run atop Android.

This article makes the classic mistake about the nature of Android. It conflates the Android Open Source Project with the suite of optional proprietary Google applications, the GMS. These old, most likely outdated licensing terms cover the Google applications, and not the open source Android platform, which anyone can download, alter, build and ship. Everyone can build a smartphone business based on the Android Open Source Project, which is a complete smartphone operating system.

Thread beginning with comment 582930
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

It depends on how you define "Google services". The API for you to send data from *your* server to an Android device is in Google Play Services, not AOSP. This covers pushing notifications, sending messages upstream, everything. Is this a Google service? In technical terms, it very clearly is - the API passes the data through Google's servers in order to get them onto the end-user's phone. But when people hear "Google services", they usually tend to think of consumer services like Gmail, Gchat or Google Maps, not low-level building blocks for applications which a consumer will neither see nor sign up to.

The situation with the Google Play Games Services is even more striking. This provides achievements, leaderboards and cloud save (enabling syncing of progress across devices). Any game relying on any of these features will simply not work on AOSP. Are these "Google services"? Again, they are in technical terms, but they're not the sort of thing end-users will associate with "signing up for a Google service." And the really striking thing is that Google supports these services on a range of platforms beyond Android - including iOS and even web games - but not AOSP.

Reply Parent Score: 5

chithanh Member since:

The API for you to send data

The API? You mean one (particularly easy to use) API.

Same with Games Services. They interact with Google Accounts. Nothing prevents you from implementing your own achievements system, or using the web API.

Saying that apps running on AOSP without GMS cannot use pushing notifications or achievements in games would be disingenuous.

Reply Parent Score: 2

oskeladden Member since:

Oh, for crimmy's sake. Yeah, sure. And you can write the whole thing to address controllers and devices directly and completely avoid using the OS's APIs for interacting with them. Heck, you can write your own bootloader and OS kernel and avoid using the OS altogether. You don't need any OS-provided API by that logic - nothing prevents you from implementing your own dialog box system.

The point is this. Google Android is moving in a direction that's making interaction with online services as fundamental a part of the OS and its programming framework as interaction with the device's hardware. This is how the OS is being designed, and this is how it's going to evolve. We are getting to a stage where interaction with online services is as fundamental a part of an OS's programming framework as interaction with the graphic module or the audio codec. If in such a world you have to reimplement virtually all APIs that entail interaction with online services, you've ended up with an OS that is no longer compatible with Google Android, because programs written for Google Android won't run on it. An OS, many of whose core APIs are cordoned off and unavailable in the open-source version, is not an open OS. It may be built on top of an open OS, but it's a different OS from that open OS. Android is already almost at that stage, and Ars Technica are completely correct to draw attention to the fact that this is where Google is going.

This doesn't mean that AOSP not useful, or is a poor OS, or any such thing. It just means that we need to recognise that AOSP and Android are becoming two different things, and that we can't call Android open just because AOSP is open. This is not an issue of semantics. As Ben Edelman points out in the piece* on which Ars was drawing, this has a range of legal implications - not least in terms of competition / antitrust law - which have been glossed over until now because of the "Android is open" argument, but which can't be ignored if that no longer holds.


Reply Parent Score: 7