The Android SDK Is No Longer Free Software
New submitter tian2992 writes "The new terms for the Android SDK now include phrases such as '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' among other non-Free-software-friendly terms, as noted by FSF Europe's Torsten Grote. Replicant, a free fork of Android, announced the release of Replicant SDK 4.0 based on the latest sources of the Android SDK without the new terms."
Right?
it is still more open than the iOS SDK, Blackberry and WP
All of a sudden a new market opens for Ubuntu Mobile ;-)
Seriously, does that impact anyone? The thing is available for free anyway...
Write boring code, not shiny code!
Google has long been willing to compromise on their "do no evil" mantra and is probably under huge pressure from successful incumbent phone device manufacturers to create barriers to entry in the market. This is common with any market where goods or services start to become commoditized.
Helping with organizational effectiveness is our job.
I don't know why the summary concentrated on the copy provisions. Here is the complete clause #3.2. Emphasis is mine:
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.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
The Android platform has some fragmentation problems and there's been endless bitching about them on Slashdot. This change is part of a number of changes made to limit the problem. The section following the summary's quote spells it out:
"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."
tl;dr - you got what you asked for.
This looks like it only covers the SDK for now. We will see if this happens to android as a whole.
I was initially not sure if anyone would use Ubuntu on their phone. Now I am looking forward to the images for nexus devices in the next few weeks.
Combining the above term with others - such as '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.'
Could for example be used to say that no, CyanogenMod, or any other 'distribution' - that is not an exact vanilla build is 'fragmentation' - and hence is not a permitted use.
samsung probably copied a few of apple's design patents, but you can't patent the concept of a touch screen device. apple never made touch screens and samsung had real touch screen phones in testing before the iphone was released. along with others.
the iphone's strength was that it had a real almost desktop class OS. LG Prada had the crappy Qualcomm Brew. If LG shipped an android phone in late 2006 then it would have been a totally different story. Android as an OS was close to ready in 2006 it just that the GUI was made for blackberry type phones
Very little.
From what I can tell, the nearest thing there'll be to real world consequences is that when Google releases a new version of the OS, people will have to wait until the corresponding AOSP release comes out before trying it out on their hardware. Previously, as soon as the SDK had a new version of Android available, you'd get a lot of (usually bad) ports of it to various phones and tablets. A significant example was Honeycomb, which wasn't put in the AOSP repository until the release of ICS (and the "AOSP" version is still hard to obtain as the versions of each file that make it up are not clearly tagged) which was, nonetheless, ported to a series of tablets by using the SDK version.
It's unfortunate, I don't know why Google is taking this action, but it remains the case that Android itself is FOSS, and I guess I'm not going to start demanding my torch be lit or my pitchfork be sharpened until I see evidence Google plans to change that; of course, even if Google was the secretly evil organization its detractors keep claiming, and planned to do that, it's hard to see how closing Android would do anything other than result in a serious, first class, fork that really would threaten "official" Android for years to come, so I seriously doubt they'll ever do that.
You are not alone. This is not normal. None of this is normal.
Android is FLOSS, the SDK is not.
CyanogenMod is not an SDK. It's an Android distribution. It is not in any way affected by the changes to the SDK licensing terms.
You are not alone. This is not normal. None of this is normal.
So if I understand correctly Android (which is based on linux) remains FLOSS, it is just a development tool that has "become" close sourced?
If that is correct, then why not go on with the latest version and update that with the community? As it is not used, then this scheme falls into shambles right?
Also, am I the only one who thinks this is against the whole principle of FOSS? This looks like they used linux because of cheap and now make things closed source because of make $...
rm -rf --no-preserve-root /
"You may not use the SDK for any purpose not expressly permitted by this License Agreement", "You agree that you will not take any actions that may cause or result in the fragmentation of Android".
If they say any specific use of the SDK is fragmentation, then you have real problems arguing it's not.
The argument that CM is fragmentation is not clearly ridiculous.
This being the case, you are in real trouble arguing otherwise, especially as they have considerably larger lawyers than you.
Well, the TaC is dated Nov 13th and there is a crazy amount of custom rom dev work going on, so I'm going say not much.
It impacts people who care about principle the software they use is based upon.
Unfortunately for people who do care about principle, the vast majority of people buying electronics for individual use have shown that they do not care about principle, and only products targeted to the vast majority benefit from the sort of economies of scale seen in mass-market products.
Yeah. SDK. Not the AOSP code. The SDK has nothing to do with Cyanogen or any other custom ROM, they're based off of the same code, code that's DESIGNED to work with what the SDK produces.
This does not affect CM.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
CM is not fragmentation, there are no changes to the API, but again: THIS IS NOT ABOUT ANDROID.
Android is still open.
The _SDK_ is what's changed. The _SDK_ is what you use to write _APPS_ for Android.
CyanogenMod contains absolutely nothing from the SDK. It is not in any way affected by these licensing conditions, any more than Ubuntu suddenly becomes closed source if Intel releases a C compiler for Linux systems. If Cyanogen and his team wants to fork Android and produce a version with an entirely incompatible API they continue to have the right to do that.
At this point I'm not sure if this is genuine confusion on your part, or if you're part of the legion of Slashdot Google FUD spreaders. I'm not happy about the SDK licensing change but I can honestly say it does not in any way, shape, or form affect the openness of Android itself. If and when Google imposes new licenses on AOSP, you can start to pretend that CyanogenMod is suddenly in legal jeopardy. It isn't right now.
You are not alone. This is not normal. None of this is normal.
I just checked the wayback machine and the SDK terms haven't changed much in years. Here's a link to the 2010 terms for the SDK:
http://web.archive.org/web/20100724144708/http://developer.android.com/sdk/terms.html
Pretty much the same as the current SDK agreement. The parts under proprietary license you can't mess with, the parts under open source licenses you can do what you want with. I can't see that anything has changed with the latest version of the agreement.
First: IANAL
What scares me about this license change is that Google is attempting to prevent, apparently in perpetuity, those agreeing to the license terms from doing anything involving fragmentation of Android (web links? Mentioning on Slashdot comments?), or from promoting a software development kit "derived from the SDK" - that presumably includes older, legitimate forks.
I didn't even realise that it was legal (or at least, enforceable) to prevent someone from doing something completely unrelated to the licensed material at issue in a one-sided license agreement. Like preventing people from doing things that "may cause or result in the fragmentation of android". That would be like the license requirement requiring users not to hop on one leg for the rest of their lives as a result of agreeing.
Hopefully the definition of "SDK" in the first section of the license [1.1: "The Android Software Development Kit (referred to in this License Agreement as the "SDK" and specifically including the Android system files, packaged APIs, and Google APIs add-ons)..."] is specific enough to not apply to derived works of the Apache-licensed source of the SDK in AOSP's repo's.
They would not need to be made available for the fork.
It would be fairly simple to retain binary compatibility with AOSP or the last version of it. The same way the Cyanogenmod does not need special apps.
For me, I would not carry two phones. I would rather give up the non-free applications.
with BLACKJACK! and HOOKERS!
It seems as though they are trying to prevent fork's even at the the sdk level.
Sparking a fork at the SDK level.
Ah, bitter-sweet irony!
On second thought, forget the SDK!
Well OK. Also not yet affected by changes to the SDK licensing terms:
* Windows 8
* Ubuntu
* The entire GNU project
* iOS
* Slashcode
* The New York Times
* The birther case against President Obama
* The thing Glenn Beck allegedly did that he hasn't denied
* The pair of headphones on my desk
* The value of the US dollar
* Superman
* Batman
* The Mayan Calendar
You are not alone. This is not normal. None of this is normal.
Since when do app developers typically need to "modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK"?
Say an application developer carries a tablet on which he uses AIDE to make and test small changes to an application while on the road. As Bill_the_Engineer pointed out, that's prohibited to the extent that AIDE contains any SDK component: "You may not [...] load any part of the SDK onto a mobile handset or any other hardware device except a personal computer."
Andy Rubin (Co-founder of Android before Google bought it, and current VP of Mobile) posted this a few months ago in relation to Aluyin OS. https://plus.google.com/112599748506977857728/posts/hRcCi5xgayg (which links to the official Android blog: http://officialandroid.blogspot.com.au/2012/09/the-benefits-importance-of-compatibility.html).
It sounds like this modification of the SDK might be another move toward Google defending against this Aluyin OS-style modification of Android. While Android is commonly cited as being "fragmented" due to the %'s of handsets that have older versions of Android on them (see the Development Dashboard); what these links talk about is a very serious, more dangerous style of fragmentation. Currently all Android apps are forward compatible with future versions and most are backward compatible (unless the develop chooses to use a new API and not include any graceful degradation in their app for older versions). But Google's flavor of Android is also sideways-compatible with the likes of Amazon such that if you write an app intended for the play store and later decide to distribute it to an Amazon-flavored device (via their app store or other various means), you can do this.
The implications of allowing such activities to continue are that Android could turn into a true wild-west of operating systems. From a technical standpoint, a budding Chinese developer modifies some core Android source code which work with the apps being developed by his company, but suddenly break every other app developed for their flavor of the Android OS -- and then suddenly developers for that hypothetical OS can no longer pick up their app and take it to Google's (/Amazon's) flavor of Android without resorting to hacks and workarounds. Suddenly that Android Development dashboard needs to represent that data in more than 2 dimensions - and Google's got a world of new problems to deal with.
See this Architecture Diagram for some further context. Basically the various Android OEM's and custom ROM developers such as Cyanogenmod should only really be modifying the blue bits and maybe some of the green (I'm sure ROM developers would argue on the red bits, but in a perfect world..). Seems like Google is trying to stop the messing with of the yellow "Android runtime" section.
Larry Page better remember what happened to Sun. Sun used to rule the world. Now look at them. Err, you can't they're dead. It's getting hard to tell the difference between control freak Google over Android versus Control freak Sun over Java.
When all you have is a hammer, every problem starts to look like a thumb.