maplibre-native
maplibre-native copied to clipboard
maplibre
Separate build flavor to avoid any references to non-FLOSS software
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.
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.
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
@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.
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?
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.
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.
@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.
@birkskyum Thank you for taking care of this now. I had already opened a new issue to move this forward: https://github.com/maplibre/maplibre-gl-native/issues/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.
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.
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
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?
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
I am new to the F-Droid stuff. What does libre mean in terms of licenses? Is it like only MIT, BSD, and Apache?
@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.
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.
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
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?
@ntadej org.osmdroiddirectly or via https://github.com/johan12345/AnyMaps
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.
I think nobody has been working on the fdroid issue. Feel free to puah this forward, @jakoblm
F-Droid builds maplibre-truly-free for DeltaChat and Element and SchildiChat (at least).
It would be better to have this clean up done here so F-Droid does not need to rebuild the lib each time one of those app releases an update.
Thanks both for feedback! What Oliver wanted to say is we currently lack Android expertise a bit and any help would be welcome. Otherwise it may take a while for this to happen.
As already mentioned, I also lack technical expertise in these matters. Therefore, I would not know what I can do. If there is something for me to do, let me know. But I would be very grateful if a solution can be found soon. Maybe some experts from F-Droid or from affected apps (like Transportr) would be willing to collaborate? https://github.com/grote/Transportr/issues/826
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.
@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.
I guess devs here will comment when they'll look.
F-Droid side FYI https://gitlab.com/fdroid/admin/-/issues/364