Ars's headline is inaccurate. These are the licensing terms for Google's closed-source suite of ecosystem apps that turn a generic AOSP-based port into a Google-logo commercial product.
The restrictions stem from a choice you have to make: If you use the Google ecosystem in your products, you have to use all of it, and you can't use parts of Android to compete with the Google ecosystem. You can make the other choice, but, in those cases, Google doesn't want you to have their closed, proprietary apps. That might be hard-nosed dealing, but it isn't more restrictive than Google's competitors are in similar circumstances.
There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause. Some OEMs, like Samsung, are shipping SDK extensions that Google apparently is fine with.
The openness of AOSP is not compromised by this contract. Amazon is an example of a partly direct competitor using AOSP. Google has done nothing to thwart Amazon, not even a hint of FUD. If only Oracle were that straightforward about Java.
> There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause.
as somebody who has had to deal with vendor proprietary SDKs for devices, I can assure you that only having to deal with one stock Android SDK that has not been tempered with by hardware-engineers under time pressure doing software is a very, very good thing.
This way the really ugly crap is contained within vendor specific SDK extensions (which can be abstracted away) instead of the crap being sprinkled all over the basic OS SDK which would require one SDK per device you're targeting and would inflict all sorts of bugs on you even when not touching vendor-specific parts.
In general, most of the terms mentioned in the article are, while being horrendous for the device maker, are very nice for both users and developers targeting these devices.
Yes, it's nowhere near "open", but also, yes, this ensures some level of quality for both users and developers.
AOSP is getting smaller. Google's closed source Android (aka GMS) is getting bigger. On a standard Android phone, a ton of it is closed source and under a proprietary license. It's now at the point that the majority of the most popular Android apps are not Android apps any more. They're GMS apps and they won't run on AOSP. Any app that implements modern location services, in-app purchases, etc, simply won't work on AOSP or any Android variant that isn't Google's with all the GMS bits.
I don't think I would expect to do in-app purchases without my own e-commerce capability, or using some ecosystem's IAP support, and AOSP never had an open source IAP framework.
There are other places where one can complain that Google has effectively abandoned open source components of AOSP. These are places where Google has made previously standalone apps part of their ecosystem.
On the other hand, alternative distributions like CyanogenMod have become sustainable VC-fundable businesses based on the relative reliability that important new core OS features do go into AOSP on a timely basis. ART, for example. It's there to read and study and try long before any Google-label OEM benefits from it.
1) Location API changes - Moving these into GMS is a bad decision, and I think hurts the core platform
2) Hangouts - Moving messaging into a non-standards compliant and closed source solution hurts everyone (except Google, at least in the short-term)
These to me indicate a move towards a more closed model within Google generally, and I think that is terribly unfortunate.
WebRTC is a transport/application level API for building things on top of, it is NOT an open interoperability standard of the same sort XMPP is at all.
iMessage uses TCP, but that doesn't make it an open source application with an open protocol.
One third of all Android devices being sold (that's over half a million a day) don't have GMS on them. If you want to find them I'd suggest you start in China, or a FSF meetup, or Amazon headquarters.
I have GMS on my Nexus phone, but I also have the F-Droid repository, the Humble Bundle store (and briefly had the Amazon App store too).
I also have Chrome installed on my Ubuntu desktop (though I mostly use Firefox, and have Chromium too). And Steam.
that your phone has "fucking" GMS on it.
that.. is the point. The phones sold without GMS in china are sold that way because of licensing reasons. Everyone puts GMS on them at purchase time.
> The restrictions stem from a choice you have to make: If you use the Google ecosystem in your products, you have to use all of it, and you can't use parts of Android to compete with the Google ecosystem. You can make the other choice, but, in those cases, Google doesn't want you to have their closed, proprietary apps. That might be hard-nosed dealing, but it isn't more restrictive than Google's competitors are in similar circumstances.
Yes but that choice is not made on a per-product basis but on a global company wide basis. I could easily see this as being viewed as anti-competitive conduct (as I also saw MS deals penalising OEMs who shipped any products without Windows).
> The openness of AOSP is not compromised by this contract.
I disagree with that conclusion. As I read the article any company that accepts the agreement promises not to fork Android. Amazon does not sign this agreement and therefore can still use AOSP freely and openly but a large bulk of the world's consumer electronic companies cannot. This doesn't make AOSP closed but it does compromise its openness.
I'd agree but for one fact. OEMs have entered into these agreements freely. Amazon (and CyanogenMod&co) aren't the lucky outsiders, they're the ones proving the openness of Android.
The inability to separate AOSP from Google's services irritates me. Google is leaving the door open for anyone to compete with them; use AOSP -a fully functional OS- and provide a better service than Google products offer, you won't owe Google a dime, and you'll be a serious competitor.
As far as I know, there's nothing stopping an independent OEM from releasing unlocked devices. An end user is free to install gapps on his own, and it's laughably easy to do.
> I'd agree but for one fact. OEMs have entered into these agreements freely.
The OEMs aren't the (only?) victims of the anticompetitive behaviour. It reduces the market for services competing with the Google services (as they can't sell to anyone who is also a Google customer) and it affects their customers (end users and telcos) and the choices available to them.
By "independent OEM" do you mean one who doesn't sign the contract?
Ars' headline is not just inaccurate. It's part of what now seem like a clear design of FUD against android.
I don't know their rationale for that but I'm starting getting sick of it. Every. Damn. Article. They insinuate, more or less clearly, that you should be very careful with android, it's not open! The best thing being: they are always talking about Google play services instead of android. Even when they explicitly say AOSP, they make it sound like is a minor part, not enough to run an actual phone (which, for being any useful, requires google apps, is their thesis I guess)
It's part of what now seem like a clear design of FUD against android.
Basically it comes down to if you're being pedant or a layperson.
A pedant is very careful to consider "Android" the AOSP and noting else.
To almost anyone that hasn't tried to install non-stock firmware on a device "Android" includes the proprietary addons.
As someone who knows the difference, I find it my responsibility to translate in my head as necessary and not get bogged down in the weeds and only bring it up when it's significant.
With all that in mind, I see what Ars is saying, think the title is appropriate for the audience and that the content of the article is clear in what the restrictions cover.
I'm not into being pedantic just for the sake of pedantics and fail to see why people think bringing up the distinction meaningfully changes the article.
>>when they explicitly say AOSP, they make it sound like is a minor part, not enough to run an actual phone (which, for being any useful, requires google apps, is their thesis I guess)
It is 2014. Modern phones need to do more than just make phone calls.
Mobile app developers want to build with the best APIs available. Location, in-app advertising & search features are best when they use the api's associated with google's custom services.
The hair you're trying to split misses the point about modern mobile apps & modern smart phones. Google is clearly using API compatibility as a wedge against the OEMs.
Samsung's Taizen project wouldn't exist if this pressure was not a real problem. Google is behaving like mid-90's microsoft. This deeper link paints a bleak picture of what's going on:
Ben Edelman is literally paid by Microsoft (and admits as much), with his one goal being to target Google.
So i'm not wildly surprised that he would paint a bleak picture of what is going on - that's what they pay him to do!
Before this he used to paint a bleak picture of google advertising:
So, I'm all for context and appreciate this color.
I don't think Edelman's stooge status damages the argument.
If Samsung is a comfortable success in android, why in the world would they invest in Taizen? You don't build your business on someone else's property. I work with many people in mobile. These complaints about Google are not anecdotal.
The squeeze has been on for years. Google is ramping up the contractual requirements without investing in support infrastructure for the OEMs- only one of which is not dying. This is a real thing and not zeitgeist or blogger drama.
The real reason is that the promise of "open source" in Android has always been wildly overstated.
Over time, the OEMs have come to realize that Android is prone to vulnerabilities, they don't get the support for updated code that they do fully purchased OS's, and google is rapidly eliminating any opportunity for differentiation of experience. Google wants the OEMs to only focus on the plastic covers of the phones, which does not make a sustainable business model.
That forceful negotiation over time has resulted in Samsung's investment in Taizen and a legitimate opportunity for FirefoxOS & Ubuntu for Phones. All it's going to take is for someone to create a VM on windows phone and the other OS's for executing android sdks- google is going to be in real trouble with their OEMs. The OEMs won't drown without lashing out for survival.
I don't know if I'd call it every article yet, but it seems to be getting more common. What I think makes this a strange thing to harp on is that, while you can make the argument that Android is getting less open, it's still way more open than any of the other major mobile OSes.
Okay, Android isn't a perfect bastion of OSS, but what can you do with iOS without Apple's permission? IIRC, you can't even write apps in their own language and IDE on their hardware to use on your Apple devices without buying a membership to their developer program. Don't even try to put it on non-Apple hardware. It's at least possible for OEMs to install Windows Phone on their hardware, and I'm not sure what development is like there, but there sure isn't anything remotely free or open-source about it.
I'm getting very tired of this. What's happened to ars and why do they seem so anti-android these days? Where's the FUD against windows phone or IOS?
Here's some perspective: Every time Apple releases a new OSX version, ars does a 20 page spread covering every tiny detail. This is an OS that is developed using a model very similar to Android, yet, the reception is totally different. I don't get it. Does Ars now employ shills?
I imagine not shipping a derivative SDK is to prevent one vendor from making an incompatible "Android+" (and the next vendor, etc) which would cause fragmentation. Instead they get to expose extra APIs through the updater app in the one true Google Android SDK (and you use the same mechanism to get the Google APIs).
"There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause."
If google does all the development work to build an SDK, and then, say, Amazon, comes along and reuses it for a completely separate incompatible ecosystem with essentially no changes, that kind of freeloading can cost Google a lot.
Actually, Amazon does not use the Google Play services and app suite, so they can do anything they like, and they do, with the Android SDK which is also mostly Apache licensed.
In a sense they are freeloading. But Google long ago took the gamble that having a broad community, that might include competitors, using the Android OS and creating apps for the Android runtime environment is better than trying to do it all in-house and proprietary.
If that is the mentality, then why is android even open source to begin with, after all people can come and "freeload" off AOSP.
Google is attempting to gain the marketing benefits of being "open" while in actuality exerting the same kind of platform level control apple or Microsoft do.
You can't have both and really be open. Its the same kind of stupid games Sun played with Java for years.
Right... which makes the argument then pretty obvious: if freeloading is a serious concern, maybe Android should be released in a way that doesn't allow that (closed, GPL, whatever). You are just being needlessly pedantic if you insist the person you are responding to should have said "under a permissive license that leads to the freeloading problem".
Except his complaint was about openness. So exerting control through GPL would be open, but exerting control outside of GPL is not, even if you exert less control and over less people?
... the comment went so far as to ask why it was open source at all if there was such concern of a freeloading. The fact that it could remain open source and still avoid freeloading just strengthens that argument and undermines your attempt to defend Google's response to the freeloaders. You also brought up the GPL as the open source way to avoid freeloaders, so your new goal of pretending I'm the one claiming GPL would be "open" (especially when I directly compared it to "closed", not "open") seems to be nothing more than trying to hope I'm too stupid to notice.
Again: this is a very simple argument: you seem really angry about freeloaders, and yet you chose the license that allows them to exist: as the person you are responding to said, if you care this much, why did you make everything this open? You could have just made it closed source, or you could have used a more closed (yet user-benefiting!) license such as GPL. To be clear: I empathize with your pain (I made similar licensing mistakes a while ago, and ended up with tons of freeloaders), but I can't empathize with your continued complaints and name-calling as if this is something other people did to you :(.
As it stands, you have now built a scenario where the people who play along with you (comply with the CTS, get the Google apps, etc.) are handcuffed (making it not exactly "open" anymore for them anyway) and the people who don't (Amazon) are on your "shit list" (leading to any of new SDK-related terms, new closed critical components, temporary closures that aren't "owned up to" as "closed", and when all else fails: bitter tongue lashings on online forums with negative terms like "freeloader" bandied about)... you are trying to have your cake and eat it too, and that's really disingenuous and entirely low of Google.
The restrictions stem from a choice you have to make: If you use the Google ecosystem in your products, you have to use all of it, and you can't use parts of Android to compete with the Google ecosystem. You can make the other choice, but, in those cases, Google doesn't want you to have their closed, proprietary apps. That might be hard-nosed dealing, but it isn't more restrictive than Google's competitors are in similar circumstances.
There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause. Some OEMs, like Samsung, are shipping SDK extensions that Google apparently is fine with.
The openness of AOSP is not compromised by this contract. Amazon is an example of a partly direct competitor using AOSP. Google has done nothing to thwart Amazon, not even a hint of FUD. If only Oracle were that straightforward about Java.