Separate build flavor to avoid any references to non-FLOSS software

[cyBerta]

Delta Chat faces problems to distribute the Android app containing MapLibre in F-Droid. F-Droid considers MapLibre as violating their FOSS principles because it contains references to google gms. Even though we didn’t opt-in the use of the GoogleLocationEngine and thus using any google dependencies in the client, these dependencies are required during compile time. Other software projects do or will face the same problem with F-Droid and MapLibre, e.g. see https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11527)

A contributor proposed to remove the problematic classes on compile-time. While this works, it’s quite a hack. I would like to propose instead to have a separate build flavor that fulfits F-Droids requirements, which has no references to com.google.android.gms.

Problematic classes we identified are:

com/mapbox/mapboxsdk/location/engine/LocationEngineResult.java
com/mapbox/mapboxsdk/location/engine/GoogleLocationEngineImpl.java
com/mapbox/mapboxsdk/location/engine/LocationEngineProvider.java

And some tests.

[link2xt]

Related: #288

[link2xt]

My interpretation is that #288 was closed as fixed because library user can avoid GMS dependency, but F-Droid still considers the library to be violating free software principles because building the library itself (e.g. if you want to build everything from source) depends on GMS.

[jakoblm]

Indeed. What is the current progress on this? I ask because it's been over a month since the last comment and there doesn't seem to be any current effort. Correct me if I am wrong. A number of apps are affected. See also: https://gitlab.com/fdroid/fdroidserver/-/issues/1004

[licaon-kter]

@jakoblm see latest F-Droid metadata for Element or Delta Chat. And https://gitlab.com/freed-by-fdroid Maplibre was setup for a purpose, but not yet functional. Free free to port those changes to a flavor I guess.

[jakoblm]

Thank you for your answer. Unfortunately, this is beyond my capabilities. I am not familiar with the technical details to do that.
I'm not sure who is taking on these issues. The team behind F-Droid, MapLibre or the developers whose apps are affected? What is the current status with "Transportr"? https://f-droid.org/en/packages/de.grobox.liberario/ Is there anywhere I can help out?

[licaon-kter]

Ideally this should be handled here, but... yeah...

[jakoblm]

Well, ideally... I became aware of this when I noticed the downgrade of Transportr in F-Droid.
If I can help to speed up the process, let me know.

[birkskyum]

Hi @licaon-kter @jakoblm , thank you for pushing this. MapLibre should be possible to use in "Libre" software, so let's sort it out in this repo. I raised this topic in the latest Technical Steering Committee meeting because it's important to resolve, but unfortunately, we haven't been able to address it yet. I'll look into it now to see what can be done. If you have specific ideas for how to resolve it or even a PR, let me know.

[licaon-kter]

@birkskyum as said above, one can look at either https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/com.b44t.messenger.yml#L1297-L1306 or at https://gitlab.com/freed-by-fdroid/maplibre-gl-native/-/merge_requests/1/diffs to see what needs to be done. This is more of a hammer than a scalpel, but for the devs here it might provide the start point for an actual gradle flavor that can be pushed to maven as alternates artifacts.

[jakoblm]

@birkskyum Thank you for taking care of this now. I had already opened a new issue to move this forward: #482. If it continues here now, the new issue can be closed.

Since I don't understand anything about the technical details, I can't help with this. If there is something else to do, I will try that.
I think the F-Droid team's ideas are a good approach.

[licaon-kter]

How does a new duplicate issue help exactly?

[jakoblm]

I didn't know how much more attention this closed issue would get. Obviously that was unnecessary, sorry. If it continues here now, the new duplicate issue can be closed.

[birkskyum]

I don't think a build type or product flavour will resolve this, because gradle might still pull in the proprietary code, as mentioned here, so these proprietary parts should be conditionally excluded instead https://www.oliverspryn.com/blog/conditional-gradle-configuration-by-build-variant

[birkskyum]

Affected Apps (non-exhaustive list):

• Delta Chat - issue, fix-by-updating, f-droid
• Transportr - issue, f-droid
• Element - issue, fix-by-excluding, f-droid
• EVMap - issue, fix-by-exclusion-using-product-flavour

What is the current status of these apps? It seems like they still are to be found on f-droid, so weren't they removed anyway, or are they not relying directly on the latest maplibre-gl-native android SDK 9.5.2?

[licaon-kter]

As linked above directly from F-Droid Gitlab, Element (and SchildiChat) and Delta Chat, before building the actual app, we sed clean up maplibre-gl and build a truly libre version of it without proprietary dependencies.

Transportr versions are still disabled.

EVMap uses https://github.com/johan12345/AnyMaps

/LE: fix-by-excluding is not a solution, although proposed at first it does not fix the "depends on build" issue for the lib, making it non-foss

[wipfli]

I am new to the F-Droid stuff. What does libre mean in terms of licenses? Is it like only MIT, BSD, and Apache?

[licaon-kter]

@wipfli OSI and/or FSF approved https://spdx.org/licenses

Do note that the issue here is the confused use of "libre" in "maplibre". It means the code is "libre licensed" not "buildable from libre code and dependencies".

The current situation is that the library artifacts used by apps are NOT FOSS.

[wipfli]

So the problem is that MapLibre GL Native uses libraries which are not OSI? If yes, how did you find this out? I am asking because I would like to better track the licenses of our dependencies, see #296.

[licaon-kter]

F-Droid has (better said will have soon) a binary scanner for the resulting APKs, so this, and many more, were found: https://gitlab.com/fdroid/fdroidserver/-/issues/1004

[ntadej]

Just for my curiosity, is there an alternative for location services that is F-Droid compliant or are those apps then just without location services?

[licaon-kter]

@ntadej org.osmdroiddirectly or via https://github.com/johan12345/AnyMaps

[ialokim]

Just for my curiosity, is there an alternative for location services that is F-Droid compliant or are those apps then just without location services?

AFAIK there's no real alternative for Google location services, but using the built-in Android location information is often good enough. I think they (can?) also take mobile cell location into account.

[jakoblm]

Is there any progress on this, or has it been postponed again?

[wipfli]

I think nobody has been working on the fdroid issue. Feel free to puah this forward, @jakoblm

[licaon-kter]

You can see what a patch entails here: https://gitlab.com/freed-by-fdroid/maplibre-gl-native/-/merge_requests/1/diffs

That needs to be translated to a gradle flavor.

[jakoblm]

@licaon-kter: That sounds great. And what is the current status? Is it realistic that the patch will be out soon, or does it still take time? Thanks for working on this.

[licaon-kter]

I guess devs here will comment when they'll look.

F-Droid side FYI https://gitlab.com/fdroid/admin/-/issues/364

[birkskyum]

We finally got the Gradle version of maplibre updated from something quite old to the latest, so that's a step in the right direction.

[jakoblm]

@birkskyum: Any progress here?

[birkskyum]

@louwers

[louwers]

@jakoblm Thanks for the reminder. Not at this point, but we definitely have the Gradle & Android experience with @ovivoda on board right now.

Is the merge reques @licaon-kte shared all it takes? Should be doable to get this sorted this week then.

[louwers]

Would anyone have any objections if we completely removed this dependency and related code?

Those willing to use Google's propietary location services can provide their own LocationEngine. And someone could publish it as a separate library. We could remove it from the upcoming 10.0.0 release.

[birkskyum]

If it's made in such way that it's trivial to still get the existing solution setup, then it could be a way forward

[louwers]

We would need to get rid of the LocationEngineProvider class entirely (which chooses a LocationEngine based on if Google Play Services are available) and instead require that a LocationEngine is passed to LocationComponent directly.

I don't think LocationEngines are used anywhere else but the LocationComponent.

We can default to the same LocationEngine that is used right now when Google Play Services is not available.

[boldtrn]

In my experience, Google's Fused Location Provider provides better results, compared to native Android.

The current code works pretty well because it can provide both providers, depending on what the device is capable of.

I understand that F-Droid has the requirement.

On the other hand I feel like the default behaviour should provide the best location provider (GMS). So some excluding logic for special builds would be my vote if it's possible, if not, we should make it super easy for everyone to use the current logic.

[louwers]

@boldtrn Thanks for pitching in. I am working on a refactor. You can pass your own LocationEngine to the LocationComponent via LocationComponentActivationOptions. To get the same behavior you would have to copy the GoogleLocationEngineImpl to your own source tree. You would also have to include the logic to choose a LocationEngine i.e. the essentially the if-statement in LocationEngineProvider.

https://github.com/maplibre/maplibre-gl-native/blob/ea234edf67bb3aec75f077e15c1c30c99756b926/platform/android/MapboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/location/engine/LocationEngineProvider.java#L49

[boldtrn]

@louwers, thanks for the info, we have a custom implementation of this already for the Kurviger app. I just meant that IMHO we should avoid exactly this, like adding a note in the README along the lines of:

If you would like the best location results, please copy this class to your codebase. Then there are 100s of apps out there that have to copy this.

[louwers]

@boldtrn I agree that it is not ideal. Hopefully someone from the community can put this code in a separate package and publish it. I am not sure if we should maintain an intergration with the Google Play services location provider in this repo or even if it is in scope for the MapLibre project to maintain it. If it is, I am happy to create a maplibre-gms repo & package.

@birkskyum What do you think?

[birkskyum]

I understand the minor inconvenience this might bring to our users, but I still think we should move the proprietary software out of the SDK, and provide as straightforward instructions on how to use the LocationEngine as possible

[louwers]

@birkskyum I agree. I updated the pull request to make LocationEngineImpl and LocationEngineProxy public so that the Google Play services location provider can be implemented outside MapLibre GL Native for Android. Right now it would be a copy paste job, but hopefully someone will make this code available as a package.

[jakoblm]

Great.
@licaon-kter What are the necessary steps to get the latest release of apps like Transportr back into F-Droid? Do the respective developers have to integrate the current Maplibre version or does the F-Droid team do it?

[louwers]

@jakoblm Please discuss this in the appropiate place. This is the MapLibre repo. Thanks.

[licaon-kter]

We can be on topic, maplibre needs to tag a release and publish the new version to maven first.

[louwers]

@licaon-kter Good news: https://github.com/maplibre/maplibre-gl-native/releases/tag/android-v10.0.0 😉