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

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 582928
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: This is a significant leak
by kwan_e on Fri 14th Feb 2014 08:11 UTC in reply to "RE[2]: This is a significant leak"
kwan_e
Member since:
2007-02-18

Yes, but the point is how many of these "many APIs" are for proprietary Google services?

Reply Parent Score: 3

oskeladden Member since:
2009-08-05

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:
2006-06-18

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

jared_wilkes Member since:
2011-04-25

Most, but all you've done is restate the problem in question form to say exactly what others are saying:

Many of the most useful APIs that an OEM would want access to our Google proprietary APIs. Yes. Your point?

Reply Parent Score: 1