Going back to Android recently, I saw that all tools binaries from the Android project are now click-wrapped by a quite ugly proprietary license, among others an anti-fork clause (details below). Apparently those T&C are years old, but the click-wrapping is newer.
This applies to the SDK, the NDK, Android Studio, and all the essentials you download through the Android SDK Manager.
Since I keep my hands clean of smelly EULAs, I'm working on rebuilding the Android tools I need.
We're talking about hours-long, quad-core + 8GB-RAM + 100GB-disk-eating builds here, so I'd like to publish them as part of a project who cares.
As a proof-of-concept, the Replicant project ships a 4.2 SDK and I contributed build instructions for ADT and NDK (which I now use daily).
(Replicant is currently stuck to a 2013 code base though.)
I also have in-progress instructions on my hard-drive to rebuild various newer versions of the SDK/API levels, and for the NDK whose releases are
quite hard to reproduce (no git tags, requires fixes committed after the release, updates are partial rebuilds, etc.) - not to
mention that Google doesn't publish the source code until after the official release (closed development) 
And in some cases like Android Support Repository [not Library] I didn't even find the proper source code, only an old prebuilt.
Would you be interested in contributing, and would you recommend a structure that would promote Free, rebuilt Android *DK?
The legalese
Anti-fork clause:
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.
So basically the source is Apache 2 + GPL, but the binaries are non-free. By the way this is not a GPL violation because right after:
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.
Still, AFAIU by clicking "Accept" to get the binary you still accept the non-free "Terms and Conditions".
(Incidentally, if Google wanted SDK forks to spread and increase fragmentation, introducing an obnoxious EULA is probably the first thing I'd have recommended. What was its legal team thinking?)
Indemnification clause:
12.1 To the maximum extent permitted by law, you agree to defend, indemnify and hold harmless Google, its affiliates and their respective directors, officers, employees and agents from and against any and all claims, actions, suits or proceedings, as well as any and all losses, liabilities, damages, costs and expenses (including reasonable attorneys fees) arising out of or accruing from (a) your use of the SDK, (b) any application you develop on the SDK that infringes any copyright, trademark, trade secret, trade dress, patent or other intellectual property right of any person or defames any person or violates their rights of publicity or privacy, and (c) any non-compliance by you with this License Agreement.
Usage restriction:
3.1 Subject to the terms of this License Agreement, Google grants you a limited, worldwide, royalty-free, non-assignable and non-exclusive license to use the SDK solely to develop applications to run on the Android platform.
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.
If you know the URLs, you can still direct-download some of the binaries which don't embed the license, but all this feels fishy. GNU licensing didn't answer me (yet). Maybe debian-legal has an opinion?
In any case, the difficulty to reproduce the *DK builds is worrying enough to warrant an independent rebuild.
Did you notice this?
I'm sure I remember the restriction in point 3.3 b "[You may not] load any part of the SDK onto a mobile handset or any other hardware device except a personal computer" from when I've read the terms and conditions of the SDK back in the times of Android 1.4 - 1.6 when I decided that I didn't want anything to do with the binary SDK and tried to build it myself; it wasn't the only reason, so probably at least some other conditions were already there.
I had some success with 1.4, but then I've never had a computer powerful enough to build the SDK and just decided to ignore it and maybe hope that one day the SDK would have been available in Debian as a package.
I'd welcome help figuring out how to publish a full SDK in Debian.
I'm pretty sure that we'll get loads of nitpicks over duplicate (and patched) GCC versions and not following the FHS, need to generate 10-20GB source tarballs, patches to deal with different build dep versions (they standardize on Ubuntu LTS), etc. Also the SDK itself, even already large, is just an empty shell, and requires to download "API platforms", some of them built long ago and requiring an old build environment to be reproduced.
We could also find a completely new way to build the SDK/NDK/etc. in a more modular fashion, possibly incompatible with other dev tools for Android - probably what the Debian Android Team has been trying for the past 5 years
Having the SDK in Debian would be really nice - but how? Suggestions?
Interesting that Google cloned Java and is now throwing roadblocks.
I wonder if running this as a VM client inside Debian helps: http://bbqlinux.org/ http://linuxonandroid.org/ http://distrowatch.com/table.php?distribution=androidx86
And linux tools in Andorid are GPL
Interesting projects.