Recently, while looking around F-Droid forum, I found a post about a person who wanted to build Android apps, but did not want to use Google’s Android-SDK, which comes with an EULA, or Google’s Android Studio, because it is proprietary. You can read their forum posts here:
https://forum.f-droid.org/t/open-source-android-development-tools/30599
They were requesting if there are any completely open source methods to build Android apps. Among the listed answers was using Eclipse IDE or gradle, but both seem to come back to using the Android-SDK or Android-NDK, etc., which state they are open source, but come with Google’s EULA. Someone else brought up that these SDK and NDK’s could be built from source code, and there were scripts available to do so, but no one to do the building. Long story short, though discussion and asking and talking, I volunteered/was asked to build them from the Android Open Source Project code.
So I did. I built Android-SDK versions 12, 12.1, 13, 14, and 15, as well as Android Studio 3.0, and Android-NDK R29, R28, and R27. Took a bit of fiddling, but for the most part just followed the scripts and build instructions. When I was done, I received several zips, and they all have a LICENSE file which states that they are Apache2.0 licensed, meaning open sourced.
Worth noting, for Android Studio, 3.0 was the highest one I could build successfully, without the proprietary vendor files from Google. Versions 3.5+, such as 4.2, do not build when you try to build them from the open source code.
Now, a little background for those who don’t build from the Android Open Source Project (AOSP), all the repositories listed and all the files shared in the AOSP are under open source licenses of various flavors: GPL, Apache2.0, MIT, etc. They cannot host any proprietary files in the AOSP source code repositories. However, some hosted default.xml files will tell the repo tool (the tool used to download the repositories) to also download some closed source files. These are clearly marked, and I avoided any of these files when creating my builds.
So, to the best of my knowledge, when I was done building all of my files, I have a bunch of zips with various tools, etc., and they all come with a license file that says Apache2.0, and a few have extra license files for BSD/MIT/GPL, etc. tools that are also included.
However, despite all of this, there are two inherent problems.
#1. Some of the open source repositories store open source tools that have been prebuilt for use and inclusion in this project.
#2. One prebuilt, open source set of tools comes with a Google EULA.
Tackling #1 first: The tools in question, are tools like Go, or Rust, or GCC. These tools are open source tools that can be built from source. But, for sake of continuity, Google prebuilt them and put them, along with their original license, in a prebuilt folder so that everyone used the exact same version of the prebuilt tool.
To expound on this, I will use widgettool as an example. If you are building Android 12.1 SDK, you need widgettool version 3.4.5, but the current version is widgettool 5.6.7, because they come out with a new revision every 5 or 6 months. So, Google realized that if you use widgettool 4.8.3, you get a different end product that isn’t compatible with somedudad version 3.8. So, to keep the results the same for all the 12.1 builds, they specifically prebuilt widgettool 3.4.5 and put it in a folder so you can use it to rebuilt Android 12.1 from source with identical results. The tool is still (at least in theory) the properly built widgettool 3.4.5 that was an open source tool, built to specs, includes the widgettool open source license, and is just sitting ready to go in a folder.
Why is this a problem? Well, some people believe that if a tool is open source and can be built from source, you can’t use a prebuilt version of the tool, you have to build it from source yourself, then use it, making it completely open source and trustworthy.
I personally find this argument flawed, because, I used Ubuntu to build with. Ubuntu comes with (and you can replace this with any distribution) prebuilt packages and tools. When I want to use git to fetch these repositories and tools to build more, I don’t build git from source, I download it from my distro’s repository of prebuilt packages. When I want to use make, a command used in building AOSP, I don’t build it from source, I use the prebuilt package from Ubuntu. So, what is the difference? I guess the difference is trust. Most people trust Ubuntu, but not Google. And I get that, but for Google to host the prebuilt file in the AOSP repository, it has to be open source. If it’s not, they get into legal trouble. So the prebuilt tool, in theory, with the originating license, has to be properly built. I personally don’t trust Google, but I don’t think that this is a slight of hand to trick people, I think it is a way to keep everything properly aligned.
Some folks differ on that. And that’s great. The problem with building all of the prebuilt open source tools from scratch is two fold: it already take over 100GB of source and a really good server to build the SDK, to also build all of the prebuilt tools from source would increase the project to at least 200GB, and would take a week to compile the extra tools, if they all can be built properly, and if you get any wrong revision of the tool, it may not work right.
Kind of limits the available people who could produce a reproducible build.
One thought was to have 20 people take on the job of rebuilding the prebuilt tools, put them in a repository, and then use that. But wait, isn’t that the same as using the prebuilt tools as they are from the AOSP?
Okay, so now to the second issue: one of the prebuilt tool sets, the “prebuilt/sdk” folder comes with a Google EULA.
This is really strange, so to be in the AOSP repository, it has to be open source. If you look at the license file for the Android-SDK, it says Apache2.0 is the license, which is open source. If you look at the how to build instructions, from Google, it says that the tools are open source and that this is Apache2.0 licensed.
https://android.googlesource.com/platform/sdk/+/refs/heads/main/docs/howto_build_SDK.txt
Section 0 is the license for building Android-SDK, in case you want to look. Of all the zip files you get when you are done, all of them include open source licenses. However, one of the zip files: sdk-repo-linux-build-tools-eng.14.0.0_r3.zip, and only this one, includes a LICENSE file that starts out as Apache2.0, and then at the bottom has a Google EULA that says you cannot modify, distribute, etc., any part of this work.
Well, wait a minute?! It can’t be Apache2.0 and not allow you to modify it. That would be contradictory.
It is also funny that to build the SDK, you need the SDK. E.g., to build a hammer you need a hammer? It doesn’t just repackage the tools, it goes through and builds the needed files, but uses some of the tools to build the tools, which is a funny way to do this. But that is a separate issue.
What I do wonder is this: could it be that, since you can use these repositories with other downloaded Google proprietary add ons (which I choose not to do), that they wrote the EULA and left it in the AOSP directory, but it only applies if you download and use the Google proprietary add ons? For instance, when building Android Studio, there are about a dozen Google vendor repositories with add ons that I don’t use for building the open source version of Android Studio, making mine Apache2.0 instead. Could the SDK be similar?
Is it open source, or is it not? Is it Apache2.0, or Google’s proprietary tool? I’m not sure who to ask, and I’m not a lawyer. I decided to email the SDK owners listed in the OWNERS file and ask them. It has only been a few days, but I have not received a response yet. If it is not, then the entire AOSP is also not open source, since it is build with these tools….
Linux – keep it simple.