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.
I don't actually know what fragmentation of Android means. I'm unsure that a court would know it either. Theoretically a new SDK derived from the Google SDK would actually be less of a fragmentation than an SDK for Android that was engineered totally from new.
Google really don't take open development seriously sometimes.
I don't really get it either. I'm not even sure how I, as a developer, can do anything to create fragmentation. If I use the official Android API, than my app (or SDK) should be forward-compatible.
If my app or SDK uses undocumented APIs, then it may not work in newer versions - but I'm not supposed to do that anyway. Maybe this is just a fancy way of saying "use only the documented API, because we guarantee it is stable".
Maybe carriers / handheld makers really just copied the source of the Google SDK, used or changed whatever they felt fit as if everything was an official API and with the next update all their changes were broken... so deriving of the SDK had to be addressed in a special way.
IANAL, but "participating in the creation of" ... "a software development kit derived from the SDK" sound like it contains creating a patch for the SDK. Very unfortunate wording, I wish they would have sticked to "don't use undocumented APIs".
I suspect this is intended to address the case where someone creates a platform derived from the Android OS, and then modifies the SDK to use it for development on that platform, or for dual use to develop software for Android and NewForkedOS.
Edit: This may be an issue for Amazon. They have forked the OS, which is fine, but they also use the (separately licensed) SDK and now this is apparently not OK.
"Theoretically a new SDK derived from the Google SDK would actually be less of a fragmentation than an SDK for Android that was engineered totally from new."
I think Google would not be happy with that, either, but there is little they can do about that (they probably can forbid you the use of the Android name, but AFAIK, that's it).
Luckily for Google, that also is much more work than extending the existing API with proprietary extensions.
So, they do the best they can: make it as hard as possible to create an SDK for a slightly (or less slightly) incompatible API.
It is unclear relative to both the text, and Google's intent in choosing the Apache license, which is a "liberal" open source license in the sense that it is nonrestrictive. You can fork, keep your source code unpublished, etc.
Google choose the Apache license to give their OEM and carrier partners as much freedom of action as possible, while making Android an open source system.
...distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.
I don't understand what Google is trying to prevent with this change. Is a "derived" SDK one that provides an alternative api to the official SDK, or extends it? Are there any derived SDKs in existence or being proposed?
Also, does any one have any thoughts about if/how this affects mono for android? As far as I am aware, MFA is an api layered on top of the the SDK. Does that count as "derived"?
If you want to use the Android SDK (this includes additionally Google APIs), you have to agree to this license: http://developer.android.com/sdk/terms.html This is also needed to release your App in the Play store.
Someone has argued source.android.com should be given a different name, similar to chromium and chrome. I think that would clear things up, too.
People who fork Android wouldn't really benefit from offering a separate SDK anyway. They would want to take advantage of the existing app ecosystem and preserve compatibility, just like Amazon is doing with Kindle Fire.
Indeed. And I never felt the fragmentation people worry about is much of a problem. We have been doing resizable interfaces since the first windowing systems arrived.
Android fragmentation was never really about the resolution differences. As stated by the various Nexus 7/10 reviews out there, many Android apps on tablets are just badly resized phone UIs, but they're still functional. Badly coded apps might crash at unexpected resolutions, but most decent developers avoid those mistakes.
The fragmentation comes from the woeful OS update situation (API fragmentation) and there being a ton of different manufacturers each producing something slightly different (hardware fragmentation).
Older iPhones don't support all the features a 5 does (panorama, Siri, etc), but they support the latest APIs. Want to use a ICS TextureView for fast GL rendering to a view? 70% of the userbase won't have support.
Writing an image processing app that depends on the GL_OES_texture_float extension on the GPU? Phones from with GPU X will have the extension, phones with GPU Y won't. Need a gyroscope for some fancy UI widget? What about NEON intrinsics? What about an app that relies on all three? Having so many more combinations of hardware is a blessing and a curse, and testing against all the possibilities is a real hassle. Every platform has hardware fragmentation - Android just has it the worst.
It looks like this is about the name. If you want to call your thing Android, you have to respect the Android API (the example they give with SystemClock makes sense).
The android source being under an Apache License, you can still fork the project, but you'll have to change the name.
I'm assuming they made this change to combat forks that do little more than redirect the flow of data and money to themselves, eg. OPhone, Aliyun, Kindle Fire. I have little respect for them.
But I'm more concerned with forks that do more than that - namely, ones that take Android and adapts it for formfactors and usage models beyond what it was designed for. WIMM takes Android into a wristwatch; Ouya, into a gaming console; Vuzix M100, into wearable computing. Each of them have their own specific SDKs and would amount to "fragmenting" Android, but for good reasons. (Hell, Google themselves are probably creating an incompatible Android fork with Project Glass!)
I sure hope Google doesn't mess with those folks, as IMO they are the ones truly putting the openness of Android to good use.
They have recently made a lot of noise about incompatible Android derived OS in China.
Like the Alibaba OS Aliyun. The name election is interesting. Yun is mandarin for cloud, which according to the news it is a main feature of this android bastard child, saving your data to the cloud like iCloud for iOS
The good part: Android has really good API-level compatibility across official and AOSP-derived Android systems. Even Kindle Fire is highly compatible. These terms appear to be aimed at maintaining that level of compatibility. Also, these terms do not prohibit SDK extensions or plugins. So, if you have an API you want Android developers to use, you are fine.
The bad part: The terms are vague and could readily be used for evil, arbitrary, witch-hunts. "Fragmentation" is undefined. And Google has a history of wielding agreements, such as the "Anti-fragmentation Agreement" some OEMs have entered into in arbitrary inconsistent ways.
The worst part: It makes Google look paranoid, like Sun and Oracle. Android is conquering the planet. Chill.
21 comments
[ 2.9 ms ] story [ 46.6 ms ] threadI don't actually know what fragmentation of Android means. I'm unsure that a court would know it either. Theoretically a new SDK derived from the Google SDK would actually be less of a fragmentation than an SDK for Android that was engineered totally from new.
Google really don't take open development seriously sometimes.
If my app or SDK uses undocumented APIs, then it may not work in newer versions - but I'm not supposed to do that anyway. Maybe this is just a fancy way of saying "use only the documented API, because we guarantee it is stable".
Maybe carriers / handheld makers really just copied the source of the Google SDK, used or changed whatever they felt fit as if everything was an official API and with the next update all their changes were broken... so deriving of the SDK had to be addressed in a special way.
IANAL, but "participating in the creation of" ... "a software development kit derived from the SDK" sound like it contains creating a patch for the SDK. Very unfortunate wording, I wish they would have sticked to "don't use undocumented APIs".
Edit: This may be an issue for Amazon. They have forked the OS, which is fine, but they also use the (separately licensed) SDK and now this is apparently not OK.
I think Google would not be happy with that, either, but there is little they can do about that (they probably can forbid you the use of the Android name, but AFAIK, that's it).
Luckily for Google, that also is much more work than extending the existing API with proprietary extensions.
So, they do the best they can: make it as hard as possible to create an SDK for a slightly (or less slightly) incompatible API.
Google choose the Apache license to give their OEM and carrier partners as much freedom of action as possible, while making Android an open source system.
I don't understand what Google is trying to prevent with this change. Is a "derived" SDK one that provides an alternative api to the official SDK, or extends it? Are there any derived SDKs in existence or being proposed?
Also, does any one have any thoughts about if/how this affects mono for android? As far as I am aware, MFA is an api layered on top of the the SDK. Does that count as "derived"?
If you want to use the Android SDK (this includes additionally Google APIs), you have to agree to this license: http://developer.android.com/sdk/terms.html This is also needed to release your App in the Play store.
Someone has argued source.android.com should be given a different name, similar to chromium and chrome. I think that would clear things up, too.
People who fork Android wouldn't really benefit from offering a separate SDK anyway. They would want to take advantage of the existing app ecosystem and preserve compatibility, just like Amazon is doing with Kindle Fire.
The fragmentation comes from the woeful OS update situation (API fragmentation) and there being a ton of different manufacturers each producing something slightly different (hardware fragmentation).
Older iPhones don't support all the features a 5 does (panorama, Siri, etc), but they support the latest APIs. Want to use a ICS TextureView for fast GL rendering to a view? 70% of the userbase won't have support.
Writing an image processing app that depends on the GL_OES_texture_float extension on the GPU? Phones from with GPU X will have the extension, phones with GPU Y won't. Need a gyroscope for some fancy UI widget? What about NEON intrinsics? What about an app that relies on all three? Having so many more combinations of hardware is a blessing and a curse, and testing against all the possibilities is a real hassle. Every platform has hardware fragmentation - Android just has it the worst.
The android source being under an Apache License, you can still fork the project, but you'll have to change the name.
This reminds me of the Firefox/Iceweasel story.
like when sun was worried that googles dalvik might fragment the installationbase vor javaME-based stuff
only that they remained quiet and let them proceed because in the end it might result in smth. good?
But I'm more concerned with forks that do more than that - namely, ones that take Android and adapts it for formfactors and usage models beyond what it was designed for. WIMM takes Android into a wristwatch; Ouya, into a gaming console; Vuzix M100, into wearable computing. Each of them have their own specific SDKs and would amount to "fragmenting" Android, but for good reasons. (Hell, Google themselves are probably creating an incompatible Android fork with Project Glass!)
I sure hope Google doesn't mess with those folks, as IMO they are the ones truly putting the openness of Android to good use.
Like the Alibaba OS Aliyun. The name election is interesting. Yun is mandarin for cloud, which according to the news it is a main feature of this android bastard child, saving your data to the cloud like iCloud for iOS
http://www.zdnet.com/cn/alibabas-aliyun-os-hopes-to-be-andro...
http://news.cnet.com/8301-1035_3-57513559-94/google-alibabas...
Just my two cents
The bad part: The terms are vague and could readily be used for evil, arbitrary, witch-hunts. "Fragmentation" is undefined. And Google has a history of wielding agreements, such as the "Anti-fragmentation Agreement" some OEMs have entered into in arbitrary inconsistent ways.
The worst part: It makes Google look paranoid, like Sun and Oracle. Android is conquering the planet. Chill.