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).
Maybe you can, but the way the license is written, you essentially agree not to ever do that:
> "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."
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.
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.
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.
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.
