Slinger,
Yes ,I was able to build 15.0.0_r9.
Are you using a repo you downloaded before and just reran init with branch 15? That’s when I see errors like that, usually.
Thanks. I ended up deleting all files and downloaded them again, it took some time but now it seems to have worked.
Now I will try to build the SDK and see from where the EULA gets copied from. However, I did a grep in this v15 tree and compared to v11 there are a lot more files with the EULA:
> grep -r "This is the Android Software Development Kit License Agreement."
packages/apps/Dialer/java/com/android/dialer/about/res/raw/third_party_licenses:This is the Android Software Development Kit License Agreement.
prebuilts/sdk/NOTICE:This is the Android Software Development Kit License Agreement.
prebuilts/sdk/tools/darwin/bin/NOTICE.txt:This is the Android Software Development Kit License Agreement.
prebuilts/sdk/tools/linux/bin/NOTICE.txt:This is the Android Software Development Kit License Agreement.
prebuilts/sdk/tools/windows/bin/NOTICE.txt:This is the Android Software Development Kit License Agreement.
prebuilts/tools/common/api-versions/NOTICE:This is the Android Software Development Kit License Agreement.
prebuilts/tools/LICENSE:This is the Android Software Development Kit License Agreement.
external/licenseclassifier/v2/assets/License/Android-SDK/20090410.txt:This is the Android Software Development Kit License Agreement.
So even for v15, the prebuilts/tools/common/api-versions still does exist. It must have been removed from the git repo very recently (after v15). And there are a lot of new files with the EULA…
Update! So the build of SDK 15 finished (first time I’ve successfully built the SDK itself, yay!), and here is my finding: as before, the only EULA I’ve found is in android-15/NOTICE.txt from sdk-repo-linux-build-tools-<name>.zip. And it gets copied from prebuilts/sdk/NOTICE, not prebuilts/tools as I had hoped.
So… this raises the question: why do the build tools need to redistribute parts of the prebuilt SDK? Most/all of these programs can be compiled independently of the SDK (which debian already do). And no other parts seem to need it? Is this just an oversight from google? Personally I only need the d8 program as the rest is already provided by debian.
Glad you got it downloaded.
As for more files with the EULA, it appears all of them reference the same SDK. E.g., because they were built with the SDK tools, then they all have that statement.
I did a overview write up on my blog about this, which you can read here:
https://alaskalinuxuser3.ddns.net/2025/03/13/is-it-really-open-source/
But the main question is: Is the Android Open Source Project open source? Per Google’s own rules, they can only put open sourced material in the AOSP repositories that are downloadable. If, for instance, the dialer app, as you saw, has an EULA from Google and an Apache2.0 license, which is it? Apache2.0 says you can modify it, and Google’s EULA says you can’t. That doesn’t work.
However, this may also come back to the question of open source vs free software. Technically, you can open the source for review and not have it free, but your license has to reflect that.
Google’s four “owners” of the SDK have not responded to my email, suggesting that either:
a. I am too small fry for them.
b. They don’t care or don’t know the answer.
c. Their spam filters removed my email.
d. They no longer are the owners.
While you personally only need the d8 program, others may need more or all of the tools in the package. Also, it may be needed as a plug in for various IDEs used for building Android.
But, again, we are at the crossroads where we have to make a decision.
Since Debian has already built all the tools, we could try downloading all of these tools (except d8) and replace the prebuilt tools with them, in a similar file structure, and see if that works. And we would have to look into building this d8 program as well. If we do that, then we don’t need the prebuilt folder with the tools, and thus will avoid the EULA all together.
However, even by doing that, some of the other apps/material, such as the dialer app (not needed in our case, but for an example) will still have a EULA clause in their own notice text file.
To do that, we would need to download the prebuilt tools repository, and make our own with our own version of all of those tools. However, the notice text specifically says it is the SDK itself that is EULA by Google, and that is what we are building… So? Maybe we need an answer from Google? I am not a lawyer, I don’t know the technicalities of it.
Now I’m just rambling in circles.
Keep in mind, I’m the dumbest person I know, so take it all with a grain of salt. 
1 Like
I don’t see the point in trying to replace prebuilts/tools with the tools from debian. We would have even bigger challenges trying to replace prebuilts/sdk. Instead what I propose is that if the build-tool zip is truly affected by the EULA it contains, and if it’s the only package affected by the EULA, then we make our own build-tool zip that gets built without relying on the SDK sources. This could include copying them from debian, or a script that sets up symlinks to those from debian, or just building the individual tools sources. Which can be done as demonstrated by debian and the stand-alone d8 repo.
The most important part, I feel, is: build-tools gets its EULA from prebuilts/sdk/NOTICE. I don’t see why these tools would even need anything from the SDK, especially the prebuilt one. But… I have a long post down below…
First of all:
Neat blog post, it also gives me better understanding on your stance on some of this. And I can really feel your frustration and the lack of response from the developers. Regarding prebuilt executables, I can see and respect your stance, and I am thankful that you respect mine. But in your blog you wrote:
I understand this was somewhat directed at me. But that’s not quite what I was trying to say. If the software can’t be built from source, then I would trust it even less. What I mean is for me to run a piece of software on my real machine, there are certain levels of trust:
I would never download and run a random executable from some unknown person on the internet (like a windows user would), and I don’t think you would either. Neither would I curl a script to sudo, and I don’t think you would either. There are some people who do this, but I think we both understand the security threat of it. In fact, I would probably not trust an unread piece of source code any more than a compiled binary of it.
But I still do use precompiled binaries from sources I trust. On my main desktop this is from packages by debian, because I have made the explicit decision to trust them. Similarly I use f-droid for prebuilt android apps. I am very picky about this. Far more than the typical gnu/linux user. I know this. I do not use npm or pip, snaps, flatpacks, external apt repositories.
In fact, all my work regarding android (and indeed, rebuilding the SDK and NDK we’re doing here) is done on an isolated OS on my system. And I might still use a chroot/vm (or separate system) to build android apps with the SDK/NDK we’re working on here. Both debian and f-droid have a policy of building their packages from source, and it’s something I hope can be done for the NDK to what extent is possible.
But I feel I might have expressed my self a bit bluntly in the past, so I just want to clarify my stance on the prebuilts specifically related to the SDK/NDK. I don’t want you to feel I’m coming across blunt and unreasonable about this…
The way I see it, we can split the concept of prebuilts into two (possibly overlapping) categories: prebuilts needed for the build process, and prebuilts being directly copied/repackaged into the final product. Furthermore, I think we need to separate the prebuilts discussions surrounding the SDK and NDK.
For the SDK:
- Prebuilts needed to build the SDK: I think these are inescapable at this point. Reading the research of debian’s android packaging team, I really don’t think we can work around these easily. And, as long as there’s not legal concern (read: EULA “infecting” the results), you will not hear me complain about these kinds of prebuilts any more. I promise. I have accepted this.
- Prebuilts repackaged and shipped as part of the SDK: when it comes to any jar-files and binaries intended for the target android devices I also don’t care much, if there even are any. Almost any android system is already very proprietary and untrustworthy, including the hardware. So as long as they don’t have any legal ramifications, I also don’t care about these prebuilts. The tools meant to be run on a computer (and part of the build-tools package) I do care about. But from what I can tell, they are already being built from source.
As for the NDK:
What concerns me there is the prebuilt clang binaries and similar that are simply repackaged into a zip. I believe it might be possible to work around this, but I think we should wait with the NDK and focus on the SDK first.
Still, if this is something you are currently focusing on, I can try to change focus and see if I can get these to build from source when I got some time (perhaps just deleting some of the prebuilt files/repos and see what happens). The NDK might still need some prebuilts for the build process, but my concern is primarily the precompiled executables being packaged up.
Does this make sense? Right now I have only one single reason for looking at the prebuilts for the SDK, and that is: what legal implication do they cause?
My main concern right now is on the EULA. I see two points:
- If there is no EULA in a zip, does it mean it doesn’t apply? Or are we already bound by it by downloading SDK “source” (prebuilts or actual source code) that contain it? I’m not a lawyer, but if I had to guess/hope I would say if there is no EULA among the license files in the zips, then it should not apply. So are we clear to just ignore it when redistributing these zips?
- If so, only the build-tools package contains the EULA. It is copied from the SDK prebuilts (not the tools prebuilts!). But does it even apply? I don’t see what these tools would even need from the SDK, especially the prebuilt one.
2 Likes
Slinger,
No problem, and I think I better understand your stance. Actually, the quoted part of the post is about my brother. He informed me that if there is an open source screwdriver used to build a widget, you can’t call the widget open sourced if you use a prebuilt open source screwdriver, you have to build the open source screwdriver yourself, then use it to build the widget, or declare that version xyz of open source screwdriver is required, but not have a prebuilt distributed with the code.
Also, he falls into the free software vs open source battle, where anything less than copyleft is not free software.
Ultimately, though, until we answer the legal question, I am at a standstill on the project. I can’t bring myself to continue to build the SDK/NDK files if a large part of the open source community/free software community is not going to use them because they are ‘tainted’. And it may not be legal to do so with the odd EULA present, even though that clashes with the Apache2.0 license of the code.
I fear we have gone in a circle and are back where we started, but with the gain of a deeper understanding of each other’s position and an increased mutual respect. 
Where do we go from here?
1 Like
@hans and @Licaon_Kter
Perhaps I can ask the question a different way and get your input.
When I submit an app to F-Droid to be built, and it is built in Android Studio, You all accept that build script that uses Android Studio as part of building that app, correct? But Android Studio, the regular one (not the open source one I built for 3.0) includes Google proprietary stuff, right?
Yet, you don’t allow Unity built apps, correct?
So, summarizing the above problem:
We want to build the Android-SDK from source, the how to documents from Google tell you how to do it and state it will be Apache2.0 when you are done. But when we build it, the build tools that get built for/with it are Apache2.0 but have a EULA with it.
Would apps submitted on F-Droid, using the open source Android-SDK/NDK/Android Studio we built be permitted? I think yes, since you accept using the Android Studio builds that have proprietary stuff in them. Would that be any kind of violation? Would your build of someone’s app who used our open source Android Studio just be built in your pipeline with the Google Android Studio?
What is the difference in your pipeline of building apps between using Android Studio and Unity?
I know this might seem off topic, and maybe it is, but I feel it will give me a clearer picture of the situation.
And lastly, are we just overthinking this? You two are not only intelligent, but also have been doing this a long time, do you see benefits to this, or does it end up the same because of the EULA from Google?
Android Studio is not doing the build, it’s an IDE, it uses Gradle, the SDK, NDK, cmake ,etc.
F-Droid uses Gradle, the SDK, NDK, cmake ,etc to build the apps.
Unity (if you mean the game engine) is not FOSS, please use Godot instead 
3 Likes
Our policy makes it clear
Android SDK/NDK. They are released as proprietary binaries but we don’t have an alternative currently. There is in-progress work to package recent Android SDK versions in Debian.
2 Likes
I fully understand. In fact, a few months back that is exactly where I landed as well (Legal advice: avoiding the Google EULA?). I didn’t have the legal base to know what the EULA would affect. And I got (almost) no feedback. At least nothing to help clear up the situation.
If it is any motivation: I can assure you that if these rebuilds succeed (including from a legal perspective) then there will be many people interested in this. It would not surprise me if F-Droid would start using them or at least offer it as an option for building submitted apps. Personally, I have been slowly porting a pretty large project of mine to android, with the intent on eventually releasing it on F-Droid. But I will only do so officially when we have an open SDK+NDK. If we fail, I will probably put this porting effort back in hibernation.
I guess we have to start seeking legal feedback on this. Given how important an open SDK+NDK would be for F-Droid, perhaps they can provide some insight? I am surprised they have not responded to this, but it’s a tricky subject. We also could reach out to FSFE since they can help with legal support. There’s the Software Freedom Conservacy. And I think FSF itself might be able to give some feedback.
I still feel somewhat hopeful about this. Given the size and legal department of google, I would imagine they would not overlook the way the build system copied the licenses to NOTICE files and make sure it includes everything relevant. The fact that so many of the packages then don’t have an EULA seems to indicate they know it doesn’t apply.
If this is true, which we would need reliable feedback on, then the remaining build-tools that does contain an EULA could be worked around if it is affected by the EULA. At least the programs in it (and their sources are not under any EULA from what I’ve seen) and can be built independently of the SDK (in fact, google offer separate git repos with prebuilt binaries of these for CI pipelines).
However, build-tools does seem to contain one further part that is not one of the programs. It’s called “renderscript” and appears to be a deprecated thing. But this might actually be why the EULA exists in this specific zip?
What can I say? Sounds like you got an awesome brother. Anyway, the obvious challenges with building everything from source all the way down is a big and interesting topic. It’s often called “bootstrapping”. And if you want a break and read something completely different and impressive, I highly recommend looking at this, it’s quite a wild ride:
1 Like
Since we are now able to rebuild the SDK and NDK (depending on definition), and the resulting archives only contain FLOSS licenses (with one exception), do you still consider them to be proprietary?
To you, as well as @hans and @Licaon_Kter and anyone else involved in F-Droid who it might concern: we have a legal question that we need resolved.
There is an issue of an EULA text from google. It seems to directly contradict the otherwise open licenses of the sources. It can be found in some git repos (checked out by repo) providing prebuilt files that are needed to build the SDK.
However it is not included in the resulting archives that are built, except for one. For those that do not include the EULA, does it mean we can proceed assuming it does not apply? And for the archive where it is included, how can we confirm if it even applies? This specific archive contains mostly the tools already packaged by debian (aapt, zipalign, and similar), and some more recent programs that also appear to be under FLOSS license, like d8. Most of these can be built separately from their own git repos without building the SDK itself.
And as far as I can tell, the efforts of getting the SDK+NDK into Debian has pretty much stalled at this point. The current stable version of debian actually has less of these packages than before, due to regressions. Waiting for debian to package up a modern SDK seems unreasonable due to its circular build process. As en example: the file android.jar essential to build an app was available in libandroid-23-java in bullseye, but that package is not available in more recent versions. And it still is an old version that would not be sufficient for building many modern apps.
I thought we do want to switch to a FOSS build of SDK/NDK.
- We need to check if your build works correctly. We can build some apps with it including reproducible builds.
- If it works, we should rebuild and host it, maybe with reproducible build.
- We should make sdkmanager fetch it with an option. We also need to figure out how we can make AGP use this build.
- Then we can switch apps to this build.
5 Likes
That is awesome! But we do need to figure out the legal situation before we go too far.
That SDK EULA, where/if it applies, does pose some quite serious freedom restrictions (on pretty much all four base freedoms, like freedom to share and freedom to use). We need to be sure it doesn’t legally “contaminate” the resulting SDK packages that we build. Again: it is not included in the license texts in most of the resulting packages, but could it still apply to them?
Also, right now the NDK isn’t really built from source, but it just repackages prebuilt binaries (like clang) downloaded from google. This is what google’s official scripts are doing when “building” it, but it might be possible to work around and get them built from source instead.
1 Like
Well, while we figure out the legal EULA part, is there anyone who wants to test the SDK from 12.0 up through 15.0?
And NDK 27, 28, or 29?
And on the side, anyone who can test Android Studio 3.0?
I will be a bit too busy for a few days, but of course I will do some testing when possible!
At least with my own build system (which is Makefile-based instead of gradle), where changing SDK is pretty much just changing two variables (path to android.jar and d8, maybe I should also adjust it to test some more tools instead of the debian-provided…). That being said, not using gradle stuff means I’m maybe not testing all aspects of the SDK like most apps…
The NDK might be trickier since I use api 19 (kitkat) for 32 bit arm and x86 (api 21 for 64 bit systems). And NDK dropped 19 after version 25. It can be done (IIRC by just change the manifest xml and adjust the call to d8), but I would also have less 32 bit devices to test if it runs on. Still, I’m pretty much 100% certain the NDK will work as it’s just the prebuilt clang binaries (which I’ve successfully used directly from the prebuilt git repo!).
1 Like
Great to see all this progress! I can’t keep up 
.
I think it is important to break down this project into useful steps. The first useful step is build recipes for the Android SDK packages. I think that’s mostly done. The next useful step is building using only binaries with free software licenses, e.g. no Google EULA. That should be official free software, but just not confirmed to the DFSG guidelines where everything in built from source. I personally think those would be acceptible for use in fdroiddata, but I’d defer to @linsui @licaon_kter on that one. The next step would be building all prebuilts from source. Then after that, building only using Debian packages.
For the biggest impact, I think making free software binary packages is most important. So freeing them from the Google EULA will be the highest impact IMHO.
I’ve been involved in packaging the Android SDK for Debian for years now, so far there have been zero copyright complaints. Also, we did quite a bit of checking to make sure we’re only using free software. I think we’re pretty safe looking at the license declarations at the top level of each git repo, at least when it comes to the project of making binaries without the Google EULA.
If the source code declares the license as Apache-2.0 or some other free license, and has no mention of the Google EULA, then anything built from that source code will have the same license. That one is quite clear to me.
3 Likes
Thanks for looking at this. I agree figuring out the legal issues regarding the EULA is a high priority. And working around it where needed.
I want to say I really appreciate your work on android-related packages for debian. They are clean, from the source, and without all the legal issues. So I hope it will continue!
That said, the impression I get from the android page in the debian wiki is that building the current parts from the SDK is only possible thanks to the old version of the SDK selected. And that the new versions have obtained a nasty circular build dependency. These “prebuilts” obviously makes from-source build and packaging for debian much much harder, but it’s also at the core of the issue we are having here!
Aside from the discussion we already have here, you can see some more details I found digging into this a while back (Legal advice: avoiding the Google EULA?). But I think it would be too much to read through. So to summarize, in short, I feel three things worth mentioning here. Things we really need to look at, if possibly seek legal advice on:
- The circular build dependency means a need for a couple of git repos with prebuilt binaries and jar-files, some containing a NOTICE file containing the EULA (the same file also contains other licenses which the EULA clearly contradicts). I don’t think we can just ignore this fact. Will it affect other files generated using them? Or are parts of these prebuilt files simply copied over to the resulting zip files and, if so, does the EULA apply there as well?
- Of the produced zip-files only one,
build-tools, contains a copy of the EULA (inside the NOTICE file, my testing shows it gets copied from the prebuilt repo called “sdk”). What does this mean? Can we ignore it? If not, thebuild-toolsironically would be the easiest to rebuild ourselves, as it primarily contains the same tools debian already builds from source. - And vice-versa: since the EULA is not present in the other zips, does that mean we’re already good on them?
So… where do we go from here?
One thing is clear: these rebuilds have value even if using the prebuilts means
the EULA still applies. Since everyone is already using binaries with the EULA,
I can’t think of any legal risk to anyone here. Plus we have the @beuc’s
precedent that was active and available for years, and I heard of no legal
troubles. If legal troubles arise, I think we can get legal support from orgs
like SFLC, Commons Conservancy, etc.
Another thing seems clear to me: if everything is built from source, then only
the license in the source repo applies. I’ve never seen an AOSP repo with a
non-free license in the source repo, but they might exist. Sounds like you’ve
been checking those.
As far as I understand the Android SDK EULA, using them to build source code
does not affect the license of those binaries. If that was true, it never would
have been possible to have any apps with a free software license, since almost
every app is built using the Google binaries.
As for the license being copied over into the zip packages, that will need to
change. Instead it should contain the contents of the NOTICE files that are
relevant.
As to where to go, I think something like this:
- Get the rebuilds working with the prebuilts
- Patch the builds so the ZIPs have the source code license, not the EULA
- Work on replacing the prebuilts.
Also, it is clear we are working hard to try to comply with the licenses that
Google has laid out for this source code. If it ever came to court, which
happens exceedingly rarely with free software, it matters a lot that we are
publicly and transparently working to comply with the license. In that case,
what is most likely is a “cease and desist”. Court fights involving free
software licenses rarely end up with penalties. This whole effort seems quite
low risk to me, and I’ve been poking Google’s hornet’s nest for many years now.
Mats Wahlberg via F-Droid Forum:
2 Likes