Android SDK is now proprietary | Hacker News Reader

Android SDK is now proprietary

blogs.fsfe.org

152 pointsFletch13770 comments

Hold on a minute.

While the Android SDK terms have changed over the years (most notably with the recent "anti-fragmentation" clause), that's not what the post is talking about. Instead, the post is identifying the Android SDK as non-free because you have to agree to Google's Terms and Conditions in order to use it at all. That's absolutely correct, however...

As someone who downloaded the original SDK in 2007, I can tell you that this was true from the beginning. Sadly the Wayback Machine is having trouble retrieving their first crawl of the terms (February 2009), but here's a crawl from January 2010 that shows that the offending clause has been there for at least 3 years: http://web.archive.org/web/20100111025451/http://developer.a...

A more accurate title would be: Google's Android SDK has always been proprietary, but I only just noticed.

Edit: Based on the date at the bottom of the wayback page, the linked version of the agreement dates back to April 2009.

The point may be that agreeing to their terms and conditions previously did not result in one losing any rights.

Not sure, though.

One of the problematic sections others in this thread have mentioned dates back to at least April 2009:

"3.3 Except to the extent required by applicable third party licenses, you may not copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK. Except to the extent required by applicable third party licenses, you may not load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK."

Here are some more rights you were giving up back then:

"4.3 You agree that if you use the SDK to develop applications for general public users, you will protect the privacy and legal rights of those users. If the users provide you with user names, passwords, or other login information or personal information, your must make the users aware that the information will be available to your application, and you must provide legally adequate privacy notice and protection for those users. If your application stores personal or sensitive information provided by users, it must do so securely. If the user provides your application with Google Account information, your application may only use that information to access the user's Google Account when, and for the limited purposes for which, the user has given you permission to do so.

4.4 You agree that you will not engage in any activity with the SDK, including the development or distribution of an application, that interferes with, disrupts, damages, or accesses in an unauthorized manner the servers, networks, or other properties or services of any third party including, but not limited to, Google or any mobile communications carrier."

At first glance, I don't think 4.3 or 4.4 is unreasonable (3.3 is more complicated), but those terms are clearly non-free. Free means free to use for any purpose (including trying to invade people's privacy or taking down cell networks) because different people will reasonably disagree about what purposes are and aren't legitimate.

At first I thought this is hyperbole, but there's an anti-forking clause in the license agreement:

> "3.4 You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK."

IANAL, but this seems to be designed to prevent projects like the Kindle Fire from building their own ecosystem on Google's code. Good for Google I guess, but no longer in the spirit of open source.

"Google's code" is a little vague, though. You can use the code for Android (which the Fire indeed does), you just can't use Google's first-party apps.

Are you sure? This license covers the SDK, not the first-party apps. At the very least, this agreement could prevent them from adding any Kindle-specific extensions to the API.

(This point is a bit moot because the Fire codebase was presumably forked from an older version of Android without this license change.)

This point isn't moot at all. One of the first things Amazon tells Kindle Fire developers to do when setting up their development environment is download the Android SDK:

https://developer.amazon.com/sdk/fire/setup.html

To me, the real issue I have with the SDK anti-fragmentation clause is that I have no idea what it means.

Does it mean you can't develop for the Kindle Fire, Nook, Nabi et al using it? Or is it OK if your apps still work on Google devices as well? Does that mean Amazon can't use the SDK when working on the Kindle Fire OS? Or is that fine too as long as the OS passes the associated compatibility tests (and, reportedly, Amazon has been very good with compatibility to date)? And so on.

And whatever the bizarre restrictions are how in the world is Google even dreaming of enforcing them? Or are they just planning to complete with Microsoft and Oracle for the "most pirated development tools ever" prize?

What does such a clause might mean to projects like Cyanogenmod?

We have been through this many times before here. This is meant to prevent forks that break compatibility. Like that chinese company that made their "own" phone OS. That was just a fork of Android, but not perfectly compatible with the Android SDK. It causes fragmentation in the sense that it forces developers to rewrite apps for it because there are differences in the SDK.

Amazon, Cyanogen, OUYA etc are all fine.

I'm sure that's a good thing for the Android ecosystem. I'm not against that on priciple (that is to say, I'm not an open-source zealot). I'm just saying that a having single entity with the sole right to change the API is essentially the definition of a closed system.

I'm sure there are justifications for this clause, but that doesn't change the fact that you can no longer fork the code, and that API changes are under the control of a single entity.

This is almost the textbook definition of closed software.

You can fork the open source parts of the code, even the open source parts of the SDK code. The SDK code is not the same as the SDK download.

The whole point of free software, though, is that you can fork it and customize and use it as you like. If someone wants to fork Android to run on stoves, and they have to break compatibility to do that, if it was free software it would support and allow that. Instead you aren't even allowed to use the SDK or let developers use the SDK if you do so. You can't really claim Android is open or free anymore now, just that it uses a few free pieces, which are being taken away wherever possible.

>The whole point of free software, though, is that you can fork it and customize and use it as you like.

No one is stopping you from writing your own SDK. Reverse engineer the API and off you go. Fork your own android. Make your own play store. Its not a violation of "freedom" because something is inconvenient.

Its like when people complain about Linus ignoring their patches. Sorry, but its still free software, its just done under terms you don't appreciate. Fork it if its such a huge problem for you.

You don't need to reverse engineer anything, the source is still available, it's still almost all apache2.

Your argument doesn't make sense to me. You're replying to a post that says the SDK is not free. Writing your own SDK if you don't like it is agreeing that the SDK is not free.

The next bit about Linus makes no sense at all. We are not talking about Google ignoring your fork of Android or your fork of the SDK, we're talking about being prohibited from forking the SDK or using it to fork Android.

The SDK is not free. It is not inconvenient to fork it, it is prohibited. Android may be free by your definition, but the SDK is not.

Actually, this is false entirely.

The SDK sources are still Apache2, and you can build your own SDK with them if you wanted.

You just can't take the Google-built SDK binaries (except as allowed by a third party license, such as Apache 2), or non-open source pieces, and use them to do it.

The SDK sources are still Apache2, and you can build your own SDK with them if you wanted.

Actually, the Apache 2 license does not disallow you to impose further restrictions. So, if you agree to a EULA, that is valid.

What you say is somewhat true but irrelevant. The EULA applies to the SDK binary download, not to the sources. If you go grab the sources, there is no EULA on them. They are straight apache2/etc. You can grab the sources, and build your own SDK, without ever involving this EULA. The binary SDK has a bunch of non-open source parts in it (they are clearly marked, AFAICT), so you'd have to deal with that, but otherwise ....

Even if you did agree to the EULA, again, the EULA applies to the binary download of the SDK.

If you want to try to claim that one of the clauses binds you otherwise, it's an interesting claim to make (though the clause is clearly written to talk about the SDK), but one i think is wrong.

FWIW: I'm an IP lawyer specializing in open source licensing

So it sounds like what we need isn't someone to reverse engineer or even fork the SDK, we just need someone to publish the binaries for download with an EULA, right?

Well, you'd have to build your own binaries from source, and then ship those. It won't entirely match the SDK, the SDK has non-open source components.

Wait, so the SDK has non-open source components, and people are up in arms that it isn't free? Huh??

Why can't you compile from source that is under Apache 2?

> This is meant to prevent forks that break compatibility. Like that chinese company that made their "own" phone OS. That was just a fork of Android, but not perfectly compatible with the Android SDK.

I don't see a distinction between what Aliyun is doing and what Amazon, OPhone, and Cyanogen are doing. Aliyun was, after all, accused of making Android apps available for Aliyun without the developers' OK. So Aliyun is as compatible as Kindle Fire.

There might be some reason Aliyun is different, but, so far, nobody has actually shown such a difference.

What's bad about this is that Google is putting a fence around code they have made available under the Apache license.

Android SDK != Android. Not saying whether this move by Google is good or bad, just pointing out an important difference. You can still fork the Android source code to your heart's content, you just have to write your own toolchain for building and developing with it.

This is an important but nuanced point that seems to be getting glossed over. There is Android SDK [1] which has the terms and conditions. There is Android Open Source Project [2], from which you can easily download the source using git, and is licensed under the Apache Software License 2.0.

This is not all that different from what many open source providers do (e.g., RedHat). If you want their official binaries, there are sometimes additional restrictions, but you are welcome to compile the source on your own or find a third-party who will provide you with unofficial builds (in this analogy, CentOS).

[1] http://developer.android.com/sdk/index.html

[2] http://source.android.com/index.html

Maybe you can, but the way the license is written, you essentially agree not to ever do that:

Now, IANAL and maybe that doesn't mean what I think it means. To me it sounds like you're signing a non-compete agreement just by downloading the SDK.

What if you fork it, and do NOT call the project anything related to Android?

That way, you won't be fragmenting Android - you'll be creating something new.

Then, should Android even stagnate, someone could take the source and create a new mobile platform, similar to, but not a different version of, Android.

What is and what is not a fragmentation of Android seems to be the key here.

> What if you fork it, and do NOT call the project anything related to Android?

It says you can't distribute any modified versions of the SDK. What you choose to call such modifications isn't addressed and isn't relevant, you just can't do it.

SDK != Source. And it's the source I'm concerned about.

That's in the Android SDK right? So you don't need to agree to that, and you can still fork off the Android code and build your own toolchain?

Correct. You can fork the Android code [1] as you have always been able to do. This is exactly what third-party Android builds do. The restrictions are for the Google's official Android SDK binary package [2], and this should not come as any surprise as it is basically the same as what many open source vendors do (CollabNet, RedHat, and ActiveState come to mind as examples, but there are many more).

The confusion appears to stem from the fact that people are conflating the official, supported binary distribution license with the source code distribution license. These need not be the same. While easy access to binaries are convenient, it is certainly not a requirement of open source. And while it might be nice if every single thing in binary Android SDK was open source, this is also not an automatic requirement (depending on the license).

Reading the Terms and Conditions through this lens makes perfect sense -- the clauses about reverse engineering, distributing, developer key protection, all apply to the binary SDK. The source does not have these restrictions, and of course, statements like "reverse engineering" or "decompiling" can't possibly apply in the context of the source code in the first place.

[1] http://source.android.com/

[2] http://developer.android.com/sdk/index.html#download

These terms do not apply to the Android source code, only the "Android SDK". This is like the difference between the JDK and source code to the Java standard class library. The SDK only contains tools for developing Android applications, like a compiler of the Java-like Android source code into Dalvik bytecode, a debugger, Eclipse plugin, etc. You can still get the sourcecode here: http://source.android.com/source/downloading.html without accepting the license you quoted.

Another interesting step in this direction is that Google stopped listing third party SDK add-ons in the Android SDK manager. They have to be added manually as a URL now, which means far, far fewer developers will ever use a third party SDK add-on.

It's sad, but I think it really hurt Google that they pushed tablets so hard and so long and pretty much failed at that market where amazon kicked ass. So business reasons seem to have forced them to kill Android as open and free. Reminds me a lot of this recent post about all the platforms closing up to try to squeeze more money out of mobile as web revenues dry up: http://techcrunch.com/2012/12/29/unnatural-acts-and-the-rise...

Google's bread and butter has always been web ads, and it is losing that with the mobile revolution. Now amazon came along and customized Android, and took a large share of the mobile money that Google was expecting. I do really hate the new Google Play. It is constantly showing books and movies and music in my face when I want apps and app search results directly. You can tell they are being pressured to deliver revenue at the cost of user experiences and pushed out a poor man's clone of amazon business model.

Not true. I recently installed Android SDK on a new computer and the SDK manager had bunch of third-party repositories already added. Heck, the hardware acceleration of the emulator under Windows requires Intel's repository for the HAXM installation and x86 images.

Very amusing. Didn't Google just fight, and win, a court case with Oracle about forking Java into the Android SDK?

So it's not OK for Oracle to prevent Java fragmentation, but it is OK for Google to prevent Android fragmentation.

Apparently "don't be evil" is more nuanced then I thought.

Google didn't use Oracle's code, and I guess you can fragment Android as much as you want as long as you don't use any of Google's code.

Uh I think you got the words "SDK" and "API" mixed up.

Also preventing fragmentation is a goal, not an action. Oracle did legally abusive things, google hasn't.

Both Oracle and Google are trying to protect their IP from fragmentation. Google changing the SDK license is just as much of a action as Oracle suing Google over their copying of the API. We're just earlier in the process with Android.

They are definitely both 100% 'actions'. But google is just being less-sharey with stuff that isn't even part of android. While oracle was trying to claim code that wasn't even theirs.

I wonder if that's why we're seeing stories like this? http://www.foxbusiness.com/technology/2013/01/03/samsung-con...

Samsung has amassed quite a history, in a very short amount of time, of heavily customizing Android for their devices. That might at least partially explain why they seem willing to gamble on their own in-house OS rather than continue with Android.

Could you blame them ? The writing started to appear on the wall when Google started selling the Nexus 7 and 10 at cost making 90% remaining Android tablets (including most of Samsung's tablet line) dead in the water with the Nexus 4 being another nail in that coffin.

Umm, the Nexus 10 is made by Samsung...

For now. What if Google chooses a different OEM for the Nexus 10 II? The Nexus business model basically means one winner (chosen by Google) and N losers.

a different OEM like... Motorola?

N losers, like Samsung lost with the Galaxy S3? (Or the S2, or motorola lost with the droid, or ...)

The full Nexus business model (where the Nexus is sold at cost so regular Android phones look overpriced) just went into effect. If the Galaxy S4 is $500 and the Nexus 5 is $350 but they have similar specs, Samsung could be in serious trouble.

From the terms and conditions:

3.3 You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; or (b) load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK.

3.4 You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.

3.5 Use, reproduction and distribution of components of the SDK licensed under an open source software license are governed solely by the terms of that open source software license and not this License Agreement.

Sorry to sound like a troll. But I am always confused by this movement on free software. Make no mistake: I totally respect choices of certain individuals whom contribute to free software like Linux, they have made the software a better place, just like those philanthropists out there whom make the world a little bit less cruel. However for those who decide not to, I don't see the reason to demand for anything, even in this case Google which may have changed its decisions. All effort will need money, and I really don't see there is free lunch in this world. Am I missing anything?

" 3.3 You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK;"

The part about not being allowed to reverse engineer seems to be the part of the license, which is most against free software principles. So IANAL, but actually understanding what a software does is, IMHO, the core of FOSS.

As far as I can tell, Android has always been proprietary except for the parts they were required to release under the GPL (like the kernel). Their GUI libraries were closed source (at least when I was tinkering with Android), and clauses like this have been in their terms for a long time. Sure, they look more open than Apple, but Android is a long way from being as open as the desktop Linux distros and BSD systems.

Parts of the graphics/GUI stack are closed source, mostly the lower level parts like the OpenGL implementations. Also codecs, camera sw etc are closed source.

Not correct. AOSP source code has always included full source for android.view., android.widget., and so forth. Which are, by the way, Apache-licensed, not GPL. If you'd like to look for yourself, it's here:

https://github.com/android/platform_frameworks_base

in the "core/java" subdirectory.

In recent releases (4.x, a/k/a ICS and later), some of the low-level GPU drivers are included as binary blobs, but the GUI libraries built on top of them remain, at the very least, source-available.

At least I'm having problems accessing the site. Page from Google Cache: http://webcache.googleusercontent.com/search?q=cache:LPBhLpm...

so if you build something based on Android and want to expose some functionality to that system but customize it, you can't do it on top of the Android SDK?

>ActivityManager.isUserAMonkey() >>Log.WTF()

Oh boy, I can't wait to see how this would be purposefully re-written and bastardized by TechCrunch (or by MG Seigler himself) saying how iOS is much better in the end, because both of some random reason.

All the more reason to back Ubuntu on phones.

What does this mean for Cordova/PhoneGap?

Google's blogpost about vendor compatability: http://officialandroid.blogspot.com/2012/09/the-benefits-imp...

What bullshit. Does requiring users to agree to GPL or LGPL license make a software non-free?

Users of GPL/LGPL don't have to agree to anything. Only distributors of GPL/LGPL software do.

Yes, that's true.

Most people misunderstand the license, being my favourite:

http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePos...

EDIT: just in case... "You are not required to accept this License in order to receive or run a copy of the Program.", point 9 of the GPLv3: http://www.gnu.org/licenses/gpl.html

You guys are right, I was wrong. As others have pointed out, Android SDK has never been free software and Android SDK != Android

Does not seem to be GPL, here's just one clause:

You end up making quite broad promises (IMHO) by just clicking through to download the SDK.

If only Sun had thought to include those magic words "You agree that you will not take any actions that may cause or result in the fragmentation of Java" in the JDK/JRE download web pages then Sun v. Microsoft and Oracle v. Google would have turned out differently?

If not, then what does this wording even mean in practice?

You don't think this kind of open-ended language makes it pretty non-free:

"You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK."

Any action? Promoting? Does this mean that I can't write a blog post about developing for Kindle Fire? Hell, can I even buy a Kindle Fire and not break these terms (or install Cyanogenmod) seeing that it is just "including but not limited to" the SDK itself?

You don't have to agree to the GPL to use the software - it explicitly states this - just to redistribute or modify it.

Somewhere long ago someone raised the point that the GPL doesn't actually give you the right to use the covered software.

Is it conceivable that a company could offer source via GPL yet demand a separate license for the right to use it?

Section 2 of the GPLv3

>This License explicitly affirms your unlimited permission to run the unmodified Program.

it also protects your freedom to modify and run modified versions of the software

Reply on news.ycombinator.com