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?