Does anyone know if the Google Play Store agreement or the Amazon App Store agreement contain similar terms?
I'd love to see Apple open things up a bit. My personal pet peeve is that it's nearly impossible to use LGPL libraries in iOS apps due to some of the terms.
The Play Store agreement has a very similar clause which applies to all apps plus the store itself (haven't checked the Amazon one). The Android SDK agreement also has one, which may or may not be preempted by whatever parts of it are available under open source licenses (depending on your interpretation of "require"), but definitely applies to anything closed source (e.g. the new Java compilers, if I remember correctly). So basically the EFF is full of shit.
> Security Features. You may not attempt to, nor assist, authorise or encourage others to circumvent, disable or defeat any of the security features or components, such as digital rights management software or encryption, that protect, obfuscate or otherwise restrict access to any Content or Google Play.
> 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; ...
I don't know enough about Android technically to tell whether this is true, but the blog post is complaining specifically about restrictions on reverse engineering the SDK.
Another bullet point is about restrictions on jailbreaking; while this is certainly highly onerous and I don't think Google has an equivalent clause, it's worth noting that Google's ban on reverse engineering the Play Store and apps distributed by it (as opposed to the SDK itself) includes activities that, translated to Apple terms, are fairly important to jailbreaking. (In particular, many App Store apps refuse to run on jailbroken devices, and must be reverse engineered to identify how to bypass this check. I don't know what the situation is on Android, but I would be surprised if that clause wasn't rouinely ignored.)
Additionally, I know enough of the Android build process to know that yes, it is true that the Google Play Store does not require DRM. It's also easy to pull any app that doesn't have DRM off a phone and put it on a phone using the debug tool that google themselves release (ADB).
The main SDK is open source. It's built from the same tree as Android from the AOSP, and you can build it yourself right now, which makes reverse engineering it sort of moot. Things like billing APIs or maps or google's push notifications however are in closed binaries, which I believe is what the clause is protecting.
You can call it DRM but what it really is, is security. Apps are signed, preventing the running of unauthorized code, which keeps malware off the platform.
If google really doesn't have this, then it's a shame, but it would explain why there's so much malware on android.
EFF's position across this article is supporting malware, and preventing malware is the clear cause and reasons for all the things the EFF opposes.
Android encourages users to stick to the Play Store, but has an escape hatch for users who don't want to. If Apple had such a policy, it might increase the presence of malware, but only for users who explicitly decided to circumvent the normal distribution process.
Most Android malware is distributed on the Play Store; the reasons it is prevalent include the lack of review process and the Android permission system, both of which are orthogonal to the ability to circumvent the store.
I think Apple's policy is mainly aimed at preventing competing app stores. You see them having a conniption every time someone submits an app that includes an alternate app store. And while I don't particularly like their policy, they have every right to implement it in order to protect their revenue.
You're implying that "preventing malware" is important enough that it overrides all other rights of the user, including some very important freedoms? And that somehow, supporting these freedoms means "supporting malware"? What the actual fuck!? This is as horrible an argument as "only terrorists have something to hide, therefore anyone who wants privacy is supporting terrorism." (Replace "terrorism" with your choice of anything the government is fighting against.)
How about we put everyone in prison, because some percentage of them will become criminals anyway? I don't even...
"Those who give up freedom for security deserve neither."
What about people building their own SDKs from AOSP source? I know quite a few people that does this, which helps them with built-in app developments as you can get all the @hidden methods/properties.
I read them quite some time ago (when I signed them) but I don't remember reading anything similar in the Play Store.
Several of these terms don't even apply to Android (the platform is open so you can publish where you want and you don't have to use reverse engineering on an open source project).
Also, I don't see why the EFF would have published their Android app if they thought the terms were unacceptable.
EFF is making a well reasoned decision here that is consistent with their stated goals as an organization, and with the stances they take on other issues.
Obviously, there are massive differences between Apple's policies and Google's policies, when taken as a whole.
EFF might (speculation) see the Google Play store as a minor compromise of their values, while the apple app store is a MAJOR compromise.
> Also, I don't see why the EFF would have published their Android app if they thought the terms were unacceptable.
It seems that the dominant theory by the enraged applephiles is relates to some imaginary 'holy war' against their beloved, innocent apple.
The Amazon App Store rewraps your app with Amazon metrics and a DRM framework; even if you choose not to use DRM, the additional code is added and the app is re-signed using their keys ( with all the implications that entails ).
The Amazon code is really invasive, I have been working on extricating a free app from it for some time and it is tedious work.
I'd love to see Apple open things up a bit. My personal pet peeve is that it's nearly impossible to use LGPL libraries in iOS apps due to some of the terms.