January 5, 2013 at 2:22 pm #5653
I’ll just post this Slashdot comment on blog post by Mr. Grote about the EULA of the Android SDK http://developer.android.com/sdk/terms.html:
Hi I’m the lead developer of the Replicant project, who just released the Replicant 4.0 SDK.
First, it’s nice to see such a coverage of what we’re doing, though I’d like to point out some misunderstandings that would need to be corrected:
* The Android SDK has apparently always been covered by this restrictive overall license. We just learned about it a couple days ago.
The main changes that has actually been added recently (as far as we remember) are:
* That the user is now requested to accept these terms before downloading the SDK and by refusing them, it isn’t possible to get the Android SDK. Since these terms are very restrictive, we believe that anyone should be free to develop software for the Android platform without having to comply with such restrictions and that’s why we decided to release a Replicant SDK.
* That all the individual plug-ins from Google are covered by these terms, removing any clear distinction between what’s free and what’s not among these plug-ins. The Replicant SDK won’t check for software updates or plug-ins from Google and already comes with an usable emulator.
As for the files in the Android SDK itself, you can check their license in the various NOTICE files. For what we’ve seen, all the software mentioned in those files is released under a free software license, thus they are still free software. Keep in mind that Android uses a lot of 3rd party software for which Google is not the copyright holder and thus can’t license the way it wants. Applying a restrictive license to the whole software package seems much like a borderline practice, though I’m not a lawyer and I’ll let competent people judge if there is a license infringement or not. There is also a statement, when listing the restrictions on that overall non-free license, regarding other licenses that may apply: “Except to the extent required by applicable third party licenses”. To my understanding, it means that those restrictions don’t apply to the free software in the SDK package.
However, it remains possible that non-free software is present in the Android SDK package (we haven’t checked each file particularly) and we thought it would be safer to release a Replicant SDK package. We never stated that the Android SDK was no longer free software, it is more complex than that.
Our Replicant SDK package was built from the Replicant 4.0 source tree and contains free software only (if you find any non-free piece in it, please let us know), it is not released under any particular license: check each component’s license from the NOTICE files. Replicant uses the same codebase as CyanogenMod with some little modifications that are specific to our free system. The Replicant SDK is thus fully compatibly with any other Android distribution: you can use the Replicant SDK to develop software for another Android distribution.
It is still possible to download the basic SDK via http://dl.google.com/android/android-sdk_r17-linux.tgz and I don’t see any EULA, so our integration the day before yesterday of android-17 should proceed as normal. It is important for us to have access to all the SDK platforms to build apps; thus I don’t think we can switch to using only Android-15, without causing ourself major difficulties. The Android SDK is the only show in town for java apps: the only other one I’ve ever seen in source code was an Intel one and we would have a lot of difficulty convincing programmers to use just Android-15. However these matters are worth mentioning on the wiki and manual, because with the latest SDK the same EULA is on the both the free and nonfree components.January 9, 2013 at 10:28 am #5671
Is building SDK yourself really that hard? http://tools.android.com/build seems to contain human-readable instructions and git wouldn’t annoy you with license prompts.. Although there is hardly need for this, because F-Droid have never had anything to do with system-level software, ROMS and anything else fragmentation-related.January 9, 2013 at 11:09 am #5672
There is one app that I know of that requires access to the hidden APIs in the SDK which can be gained by uncommenting-out lines of the source code. The app is Legacy launcher, a fork of ADW and he says its a technique commonly used by launchers. However there are more apps that need AOSP to build Propmodder, Pinyin/Ja/Korean IMEs and spin offs, DroidVNC; the new PDroid prefs app needs patched system frameworks. I would say that in the long list of ‘other SDKs worth supporting’, AOSP comes out on top.January 30, 2013 at 6:51 pm #5906
I also don’t see any big problem with Google SDK – there always has been need to accept some license if packages were installed via “android” tool. But yeah, who did that, everyone wget’ed it from http://dl.google.com/android/.. via cron I believe.
I never paid much attention to what they had in that, because I assumed it’s in the vein: “we got bunch of open source stuff in here”. Indeed, it’s like that (recent SDK Platform Android 2.3.3, API 10, revision 2):
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.
It has laughable stuff too though:
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.
Anyway, it might be good idea to “support” building against 3rd-party cleanroom build of SDK (there’s “make sdk” in AOSP for that, as pointed out).
And regarding private APIs, that’s what I wanted to ask: does anybody know an analogue of Windows “import library” build tool for Java/Dalvik – i.e. a tool would take a .jar/.dex and output another .jar which would contain all the symbols in oriignal jar, but with empty code bodies, to serve solely for compiling/linking apps against? That way, even if googel puts soem private stuff not in AOSP on which soem apps my depend, it would be possible to create such “implib” from a real devcie file, and redistribute it on fair use conditions.February 1, 2013 at 8:56 pm #5950
I just downloaded the Google Play Services SDK component to see what the licence is . There is no licence in $$SDK$$/extras/google/google_play_services. However if you go to the documentation at http://developer.android.com/reference/gms-packages.html it says the content is Apache licensed. If you view these docs within the SDK the licence file gives 404. And there is a jar in the library and “source code”, though src is empty: I think it’s only used for calling it as a library project.
This is in contrast with GCM (Google Cloud Messaging): the source code for that is on Google Code and in the SDK, and there is a copy of the Apache licence in $$SDK$$/extras/google/gcm.
The forum ‘General’ is closed to new topics and replies.