Today I scanned our complete repo for references to google’s nonfree android libraries. I found a few hits which I have to sort through and I’ll open an issue about this later. Those hits bundle some of the com.google.android.gms classes into the apk.
There’s a different class of problem which I encountered which still isn’t clear to me how that works out under a free software viewpoint. This is about a free software library (mapbox sdk) needing another non-free library at compile time (gradle compileOnly dependency). The final apk using the mapbox sdk will not inherit this dependency and the nonfree library will not be bundled into the apk. The apk does contain references to the nonfree code though.
Does anyone have any insight into this? Is the mapbox sdk free software, is the final consumer free software even if you could not rebuild it’s dependencies from source without needing another nonfree library?
I’m afraid we cannot reliably enforce this unless we start rebuilding the whole java library ecosystem and allow only using libraries we built ourself. Others have attempted to do that (most notably I know about guix investing a lot of time into this) and ultimately given up because they ran into circular dependency issues (because that’s what happens when the whole ecosystem just uses binary dependencies).
In the case of MapBox it’s just a GMS library, so if there would be an f-droid maven repo one could rebuild it with a small patch and use this in the apps.
Here you go, this is relatively unverified. I know some of them are using mapbox. Others come up because of com.evernote.android.job.gcm.JobProxyGcm which in turn has a build time dependency to GCM. I didn’t check all of them in detail yet.
(This is the list of apps that came up for referencing com.google.android.gms but not actually bundling any of it.)
Regarding your “library with non-free compile-time dependency” case: To me the relevant question would be if it would be feasible to build the library without such compile time dependency.
The reasoning for this is as follows: If it it feasible to do it without non-free compile-time dependency, we might as well decide to do it. We also do/did patch apps that have non-free compile-time dependencies, so it sounds sensible to do the same for libraries. But if we do it, we should in the end get the same result (if builds are reproducible, it would even be binary identical). So we might as well argue that it’s not worth the effort of actually doing it if the result will be the same and it’s actually feasible to realize it.
For the case of mapbox sdk: I checked the classes being used and if they are already provided as part of microG. Only two classes are not yet. Adding them should be reasonably feasible (as for this purpose, it’s only required to have stubs, the actual implementation is not required).
However, I would not be entirely against tolerating this (kind of like Debian contrib), as long as it is mentioned somewhere, for example with an AntiFeature.
So I think you are saying, if we can do it, we don’t need to; but if we can’t we definitely do need to?
I do think that’s a fairly reasonable way of looking at this. If the binaries do end up the same, we can just as well use upstreams. We should have a way to make sure we can arrive at those same binaries though. There are a lot of ways to get to this point, some probably more painful then others.
I think any non-free build dependency should block something from F-Droid, even if it does not end up in the APK. If you can’t built it, it is not free software. That’s Debian policy too. Debian contrib does not allow non-free anything as part of the package, including Build-Depends. contrib means it requires a non-free thing to work.
Izzysoft already provides a repo where apps with small violations can be included. Its a great stepping stone to f-droid.org.
