
New Android OEM licensing terms leak; “Open” comes with a lot of restrictions - RougeFemme
http://arstechnica.com/gadgets/2014/02/new-android-oem-licensing-terms-leak-open-comes-with-restrictions/
======
Zigurd
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.

~~~
scotu
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)

~~~
droopybuns
>>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:

[http://www.benedelman.org/news/021314-1.html](http://www.benedelman.org/news/021314-1.html)

~~~
DannyBee
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:

[http://techrights.org/2011/08/30/ben-edelman-works-for-
monop...](http://techrights.org/2011/08/30/ben-edelman-works-for-monopolist/)

~~~
droopybuns
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.

~~~
DannyBee
"If Samsung is a comfortable success in android, why in the world would they
invest in Taizen?"

In samsung's ideal world, they are Apple. That's why. Plus, you always need a
plan b.

~~~
droopybuns
Bzt.

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.

------
blinkingled
With Android, for some, it's damned if Google does and damned if they don't!
Kind of amusing to watch lately - bloggers, writers, whoever - going out and
writing inflammatory stuff that is bound to get page views and comments.

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.

~~~
doctorpangloss
>Problem is none of these articles provide any practical solutions for Google
to implement

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.

~~~
blinkingled
> 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.

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.

------
RyanZAG
Anybody else a bit worried that this basically comes down to the good old
"embrace extend extinguish" ? It's slightly different in that the "embrace"
step was the purchase of Danger and open sourcing of the base AOSP - but the
"extend" bit is pretty clearly in full effect here.

~~~
Zigurd
No. Or not yet.

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.

~~~
eterm
That's not the point that GP is making. The point is that AOSP has been
extended through google play services in the same way MS used to extend open
protocols. It has used that to bring up a lot of people who associate android
more closely with the google play services ecosystem than the AOSP ecosystem.

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.

~~~
fidotron
That new OS is Chrome OS. Notice that the Chrome OS device manufacturers don't
get to rebrand it, modify it in any way, or control delivery of the updates.
It is far more closed than Android ever was.

Google are applying their lessons from Android to Chrome OS.

~~~
cromwellian
That's a rather bizarre way of putting it. Another way of looking at it is
that Chromium is completely open source and anyone who wants to build a Web-
browser based netbook could do so, they just couldn't call it ChromeBook.
Since all the apps are web apps, everything would continue to work as normal.
There's no "if you don't agree to all of this, you can't use the GMail Web App
or Google Maps on your device"

~~~
fidotron
Can you access the Chrome API from apps not delivered through the Chrome
Store?

Chrome OS is closer in spirit to iOS than it is to Android.

~~~
cromwellian
AFAIK, you can install apps and extensions without going through the Chrome
store, and if you have the source, you can certainly hack it to use an
alternate store host.

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.

~~~
fidotron
That's like arguing that iOS is open since you could all become developers and
distribute the ObjC. Not all Chrome apps are web apps (
[http://developer.chrome.com/apps/about_apps.html](http://developer.chrome.com/apps/about_apps.html)
) and you can't distribute those packages trivially to end users, so the whole
distinction is almost identical to the iOS situation, by design. Google's
Chrome group have a serious case of Apple envy, and this is how it manifests
itself.

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.

~~~
cromwellian
Almost identical to iOS? Absolutely ridiculous analogy. ChromeOS doesn't
compare to iOS at all and Chrome is far more open than Android in terms of
development (All new Chromium development is done in the open and new releases
happen nightly and every 6 weeks. Do you know what Android 4.5 will have in it
yet?)

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.

~~~
fidotron
Nope, look at the docs - you need developer stuff enabled to side load. The
rest is being removed "for user safety". This makes it just like iOS, where if
I'm a developer I can likewise sideload anything I have the source to.

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.

~~~
cromwellian
How about actually owning a ChromeOS device before making comments? "Developer
Stuff Enabled" = "Menu -> Extensions -> Developer Mode Checkbox". It's not
different than going to Android settings and saying "allow apps from unknown
sources."

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.

~~~
fidotron
I'm on a Pixel!

I'd suggest you try writing some Android services, and you'll find you don't
have to modify the OS at all.

------
fidotron
Did Ars just conflate android with the Google play apps again? Why isn't this
surprising?

They swallow whatever any PR person is feeding them.

------
samworm
New in the sense that they're newly available to the public. The agreement is
dated Jan 2011.

------
ZeroGravitas
From a game theoretic point of view the OEMs are probably grateful for most of
the restrictions because they apply to their competitors too.

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.

------
coldcode
In the end Google wants what Apple has: control. In this case it's a slow
strangulation.

------
higherpurpose
It's like Ars is on a mission to discredit Google here.

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.

------
macinjosh
The overarching problem here for Google is that they set an expectation of
openness from the outset which in reality was probably an unreasonably high
expectation. As Google realized they need more control to provide a better
user experience over time they have had to make moves that fall short of those
expectations.

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.

~~~
ZeroGravitas
This has been part of the PR strategy against Android from the beginning.
Remember when not releasing Honeycomb meant that Google was taking Android
closed source? Or the list of AOSP apps that Ars claimed were abandoned but
then got major updates in KitKat?

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.

------
sjh
As such, the software which makes up "Android" resembles OS X to me: open
source in parts (even large parts), but the bit which most people (including
developers) use is closed source and restricted to running only on sanctioned
hardware.

