New Android OEM licensing terms leak; “Open” comes with a lot of restrictions
arstechnica.com
arstechnica.com
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.
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.
Sounds like the exact argument for iOS.
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.
iMessage uses TCP, but that doesn't make it an open source application with an open protocol.
Whether XMPP or WebRTC are open, and open source, is different from whether services that run on them are open to federation.
But what the post I responded to claimed was about the tech, and the tech will be just as standardized and just as open source.
i'd like to see ONE full time user of AOSP without GMS. I bet you got GMS, or non-android phone, or else its not your main phone.
and that's the fucking point.
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.
What was the fucking point again?
Your arguing is senseless.
That's ludicrous, and the rest of your post isn't much better, but its a good example of the worldview that Ars is currently pushing.
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.
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.
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?
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)
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.
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:
Before this he used to paint a bleak picture of google advertising:
http://techrights.org/2011/08/30/ben-edelman-works-for-monop...
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.
In samsung's ideal world, they are Apple. That's why. Plus, you always need a plan b.
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.
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.
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?
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.
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.
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.
I'm not sure I follow. Freeloading is a huge problem, even in the open source community. This is for example, one of the reasons the GPL exists.
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.
Hangouts - people were pissed that there wasn't a integrated, one stop messaging solution on Android in 2013. Google tries to do something like that - integrating Google Talk and SMS and now suddenly it's a move to take all your bases.
There was lot of cry about the F word. Google does the only thing they could - put reasonable amount of control while keeping their business interests in mind - to reduce fragmentation and offer a more uniform experience. Now people are crying too much control. If on the other hand they would have said here's Android, and here are freely downloadable GApps that you can freely use to avail Google services, you can do whatever you want with them - I am sure there would be an article somewhere claiming the F word, "dumping", lack of uniform experience and few other things vaguely implying malaise.
You also notice that this drivel is coming mostly from two sources - sites benefiting from page views and user interaction via comments and people who kind of feel threatened by Android's success - techies on the other mobile platform for example.
Problem is none of these articles provide any practical solutions for Google to implement - I guess doing that would be too inconvenient for a future article they might need to write claiming what Google was doing then was bad! If one of these articles articulated the path Google should take to keep Android successful, have no fragmentation, have singular, uniform experience without violating any of their future whiney articles ( [2015]How Google screwed up - Android went from 78.1% market share to 1.5% by following what we said in 2014) - it would be worthwhile paying attention.
But of course that is impossible to do - you can only have your cake OR you can eat it! Why solve that when you can just keep writing nonsense drivel and 'engage' you audience.
Practically speaking, it would be pretty easy for Google to make many of its already standalone updated apps fully standalone. Anyone could distribute the Gmail package, Google just won't let them.
It's very useful that Google Play is integrated in a way that reduces the friction of payments and protects the users and developers from various kinds of fraud. I don't know how to allow multiple stores to be installed where a high-stakes third party developer doesn't get ruined by fraud when they reach a sufficient scale.
CM and ton of other ROMs are distributing GApps as standalone Zip - Google isn't doing anything to stop them. Tomorrow if Huawei does that - it would be a different story. Then Huawei can ship with 2.3 and outdated/incomplete Gapps (no browser, just gmail, no Google location APIs, instead incompatible APIs, and do a bunch of other things that could be bad for everyone else - which brings me to the point I made - that will result in people then complaining - In China you don't get uniform Google experience - Huawei phones ship with HuaweiKit instead of Blink, HuaweiBrowser instead of Chrome - so site owners can't even create a web app that works on all "Android" devices etc.
stop the appologetics.
In other words you don't know what you are talking about. (Hint: Try working through all the consequences of it.)
Remember Google isn't a charity - they are a business and they have to protect their business interests. Once you start under the incomplete premise of Google with their Open stuff and without their business interests - that's when you start demanding 100% open. IMHO they are as of today doing a fair job balancing both their interests and AOSP's openness. Conflate AOSP and GApps and that's when you get into silly land.
Google is very consistent in their treatment of AOSP. That's not to say it's a bed of roses. AOSP was and maybe still is under-resourced. It hasn't always had stable hardware targets. That's not a good way to treat a resource that is instrumental to creating a community of developers that know how to keep Android updated on a wide range of SoC platforms. Google makes no attempt to create an independent AOSP governance and pool of maintainer resources. I can go on. How much time do you have?
But the bottom line is AOSP has been remarkably free of shenanigans. Very unlike some other in-house but nominally open source projects I can think of.
If google said "we're ditching AOSP but we're making a new closed source OS with google play services and a compatible API layer" then really would people move to AOSP or the new google OS?
The potential for "extinguish" is there. Had this all happened the other way around or had AOSP been around and MS had embraced it and extended it in this manner then I think people would be acting differently.
I don't see a fix for parts of the open Android app layer migrating into dependence on the Google ecosystem, apart from allowing downstream distros to maintain and/or replace the open versions. If Google wants to integrate Photos with G+ what are they going to do about that that would be consistent with their "All of our ecosystem or none of it" approach to licensing?
Google are applying their lessons from Android to Chrome OS.
Chrome OS is closer in spirit to iOS than it is to Android.
The thing you might not get access to is cloud based Chrome services like Chrome Sync. But since these are Javascript APIs, you can easily polyfill them to use your backend.
I don't think forking ChromeOS is as difficult as forking Android.
The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.
1. The majority of iOS apps can't be side loaded, are locked to the App Store. Vast majority of ChromeOS apps are not "Chrome Apps", it's a red herring. Plus, Chrome Apps can still be side loaded and are not locked to the Web Store. None of Google's major apps: GMail, Maps, Docs, YouTube, etc are actually "Chrome Apps" in this regard. Then will run on any ChromeOS fork. Chromium today supports side loading any app from the Extensions page without going through the Chrome Store.
Simply put, it is not possible to create the kinds of Google-service lock-in agreements for ChromeOS that have been created for Android, because ChromeOS is just a web browser.
2. ChromeOS doesn't need to add hooks for app delivery contrary to your claims. The Chrome equivalent of an APK is a CRX file and CRX files can be self hosted, see "Hosted Apps". In fact, they used to auto-install if you just clicked a link pointing at one, but phishers/hackers took advantage of this, so now you have to go through the Extensions page.
Any Web app you build for Chromium will work on any subsequent ChromeOS fork without needing to make any lower level changes, because Web apps don't have huge dependencies on local OS services. Many ChromeOS apps will even work on Firefox because again, the vast majority of Chrome apps don't really depend on local OS privileges like getting access to the USB port.
Implementing a different app distribution mechanism is trivial.
In practice, Android apps are far more likely to depend on non-AOSP services (like Google Play Services) than Web Apps are to depend on Chrome Web Store required services (of which there is only a tiny few, like push messaging). That's just the facts, so the practical reality is, forking AOSP creates more incompatibility than forking Chromium.
Chrome OS is _not_ just a web browser, as that link to the Chrome Apps stuff very clearly demonstrates. It's not "pure web" at all. This is PR nonsense, when there's a whole extra API.
Clearly you don't like it being pointed out, but Chrome OS is Google's walled garden.
Besides, the whole argument is how easy it would be to fork Android vs Chrome, and the reality is, turning off install restrictions in Chrome in a few lines of code. Replacing Google Play Services/GMS are far far harder.
I'd suggest you try writing some Android services, and you'll find you don't have to modify the OS at all.
I don't think you're going to get many people to believe that apps which target a platform that is mostly based on a spec controlled by a consortium, and for the most part, are cross-platform, are somehow more locked down and proprietary than a native apps platform. This is pretty much the first time I've seen anyone on HN try to argue that web apps, even chromium apps, are harder to port, and more of a walled garden than Android. It's a difficult to pull off argument, and I don't think it works.
As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.
The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium?
Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use.
And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence.
The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into.
That said, locally installed apps can provide services to other apps through multiple techniques:
* Background pages (invisible HTML pages running in the background)
* Shared Web Workers (spawned process that lives at a known address)
* Custom Protocol Handler
* Service Workers (intercept HTTP requests for resources)
* Chrome Extension content page
* WebRTC or local web server
* Web Intents/Web Activities (got shelved by Google and Mozilla)
From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work.
This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
API compatibility in Android is excellent. This is because you don't need to touch the bits that make the runtime. It's the same runtime, and the exact same bits that apps touch, in Mountain View as in the Two Chinese Guys Making Handsets factory. Most developers of widely used apps test on Kindle devices, at least, if not other Android-derived OSs.
Web apps face multiple implementations of a standard. That's going to be less the same.
Also, compiling without breaking, and running without breaking for two different things. If the binary compatibility alone was the main problem, there'd be no issues with Android fragmentation and testing.
If you go to Google Play, pick "Top Apps" and read the reviews of any top apps, you'll see plenty of "It's not working", "won't launch", "freezes my phone" type comments.
You happen to be missing our rather epic point that apps which are 100% dependent on GPS and cannot be moved from them are in practice rather thin on the ground.
I used to work doing games on Android across all varieties of it, and the differences are nothing like as big as people that haven't looked properly seem to think. In fact for many titles without push or in app billing it was simply a question of testing, and these things ran perfectly, or no worse than any other issue you might have with a device on the Play Store. It is most definitely less than the difference between different web browsers, and far better defined. Do this a few times and it can be abstracted away (to the point of portability to iOS abstracted).
Let's say I'm an OEM without an existing contract with Google. I could either build a Chromium device or an Android one, and shove some other app store on it. Unsurprisingly many are doing the latter, and they're in the wild, but has anyone seen a Chromium device actually out there? Given how many Chromebooks are selling you'd think maybe one enterprising Chinese OEM would do it, but they seem far keener on Android. I wonder why.
You are greatly overestimating how hard it is to implement services on the device. The only hard part of implementing a store and in app billing, for example, is the server. The clients practically write themselves by comparison. Given that the entire Chinese Android market exists without Google's cloud services it's clearly nothing like as big a deal as you and Google wish it were.
No one is wishing anything is a big deal. I am not attacking Android or the bogus Ars Technica articles which keep pushing the line that AOSP isn't open. I'm criticizing this weird claim that ChromeOS is more of a walled garden, which it most decidedly is not.
Chromium is "more" open source than Android because it is developed continuously in the open, there's no "code bomb" that publishes the entire Next version once a year. Secondly, the surface area of Chrome-specific APIs or services are tiny and insignificant compared to native devices. Those two features limit platform lockin and increase portability.
The Chrome Web Store/Chrome Apps are simply a red herring. The vast vast majority of ChromeOS "apps" are links to hosted sites, the majority of which work on any browser. That's been the major problem getting people to pay for stuff in the CWS as you can cut/paste the URL and avoid the store entirely for many apps.
Leaving aside Chromium, many people have taken WebKit and made desktops based on it. WebOS, the new SteamBox uses a frontend built with WebKit, the PlayStation UI has various parts built with a browser. There was also Jolicloud.
It is not hard to take a Linux distribution and slap a browser on it as the desktop launcher. Sorry, it's just not. Whether people are interested in doing that and think it is something they could sell for a profit is a different story that has nothing to do with the technical difficulty of doing it.
edit: i.e. the Web Store is playing the same role as any other website. You wouldn't criticize Chrome OS for the difficulty of making an alternative to Facebook for your fork.
I think the only two real sticking points are what was mentioned about this agreement having to be a company wide deal, and also that stuff against forking the SDK giving Google far too big a veto over proceedings. Ideally to fix this the OHA should become independent of Google, but that would rely on the other members being remotely competent.
They swallow whatever any PR person is feeding them.
It's the same reason that GPL often make sense for shared projects, the restrictions on "freedom" prevent defection and so enable cooperation.
The OEMs rejected the GPL, but they probably want some kind of protection from say Samsung freezing them out of the market, or just as bad, everyone trying but failing and ending up like Unix.
I've actually been waiting for Google to take a harder stance on OEMs and force them to provide better support to their users for a long time. It will also make things a lot easier for developers in the future, as this will have the effect of reducing fragmentation, and not having to use APIs that are 5 years old.
Apple doesn't get this sort of flack because from the very beginning expectations were set that they would exert full control over iOS. So if they make a dick move no one is surprised.
There is something to be said about how setting reasonable and even lower expectations is always a good route in all sorts of aspects of business. It leaves you options, room to improve, and it changes to those expectations are less jarring to fans and customers.
So by the standard of the mud being thrown at them Google are actually exceeding expectations for openness. And it's just odd to see Apple and Microsoft boosters take positions that are more extreme than RMS just to minimize this advantage.