Universal Fdroid Packaging and Licensing Questions

[amenk]

I opened an issue on for F-droid packaging a while a ago, but due to various reasons can not push this forward at the moment.

I know @christophhanser get's asked regularly why the Trufi app(s) are not on F-droid.

The most recent problem was that publishing it on F-droid means that the maptiler key is shared. Is this still an issue for the main trufi app or is there already a tile server which is not from maptiler? Then it would be cool if anyone could push this forward here or in a related issue on F-droid for the benefit of all trufi-core-based apps

[md-weber]

I believe this is still a problem.

@mdoelker Do you know more about the MapTiler Key is shared in our current Flutter App? This is quite a blocker if we have to reveal the key, I guess.

If F-Droid really does not support any Secrets, I have the feeling that this could be quite difficult if we work with MapTiler.

[mdoelker]

The maptiler key is not an issue for us really as we use our own tiling server nowadays. A bigger problem was that I believe some of the licenses of dependencies are not compatible.

The ones I identified back then were:

• boringssl / openssl (OpenSSL / modified 4 clause bsd)
• gif (mozilla public license 1.1)

[amenk]

Interesting, so do we currently follow the license clause of the 4-clause-BSD and state the copyright in adverst materials for trufi? https://www.gnu.org/licenses/bsd.en.html

[mdoelker]

We advertise all libraries used and their licenses in the about section.

[amenk]

But we don't mention OpenSSL when we promote Trufi, right?

So does this mean that no products using OpenSSL are allowed in fdroid?

[amenk]

Example:

Directly on the store listing it states

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ([http://www.openssl.org/]).

So I assume, that using OpenSSL in Froid is 1. allowed but 2. has to be stated everywhere, also on Trufi website and so on

@mdoelker wrote

I believe some of the licenses of dependencies are not compatible.

So this probably is not about f-droid it self but the general licensing of Trufi under GPLv3, right?

[mdoelker]

It really is a modified one: https://www.gnu.org/licenses/license-list.en.html#OpenSSL that is not compatible with GPL.

Fdroid only states that the software must be free and open source, so this might indeed not be an issue for this license. I probably remembered that incorrectly and the issue lies in our usage of GPL like you said.

Same goes for the Mozilla license. https://www.gnu.org/licenses/license-list.en.html#MPL

I don’t know what the extent of the advertising should be really.

[amenk]

I don’t know what the extent of the advertising should be really.

Me, too :-) And if OpenSSL and GIF really have licenses incompatible to GPLv3, Trufi probably cannot be published under GPLv3?

[mdoelker]

Wouldn’t that essentially mean that no flutter project could be released under GPL? Sounds weird to me. We’re not even using gif encoding/decoding, but we certainly use SSL.

@md-weber do you know anything more about this?

[md-weber]

Sorry, unfortunatly I am not really good with this licences stuff. The only thing I could find about that topic was the following: https://opensource.stackexchange.com/a/9793

[mdoelker]

Yeah that one I saw too. Sounds like this would work.

[amenk]

I guess the flutter licensing should not really be a problem. Shall we warm-up the topic to public on fdroid again? The last problem I had was only about publishing the maptiler key, but as we will plan to move to a own tileserver, this would not be a problem anymore.

My packaging request was marked as stale https://gitlab.com/fdroid/rfp/-/issues/1182 / closed but probably can be reopened.

But I also had technical problems in building for F-droid.

The idea would be to solve this one-for-all so all the trufi apps could potentially and easily be published in F-droid.

(as long as we don't include other proprietary code like Mapbox GL)

[ValorNaram]

(as long as we don't include other proprietary code like Mapbox GL)

in the trufi core yes. We have no influence in what others do with our code but we should make it work that all apps based on our Trufi Core without any additional (proprietary) features/add ins can be pushed to F-Droid. If we do it for e.g. a future version of Trotro App and the F-Droid team sees that it is based on Trufi Core then it will going to be easier for others building on Trufi Core as the F-Droid team knows it already.

[amenk]

I am working on this again:

https://gitlab.com/addismap/fdroiddata/-/blob/com.addismaptransit.app/metadata/com.addismaptransit.app.yml

It seems to build the APK, but then some Google packages are blocklisted...

Trying to find out, which are those google packages in use.

[amenk]

One culprit seems the app_review package. I removed this in https://github.com/addismap/trufi-core/tree/no-reviews and get less warnings

There still seem to be warnings about location services; I don't know if they can be removed / replaced.

As for the app_review package we could provide a simple link to the store instead of a in-app rating. Also we could need to link to the F-droid store for that package. F-droid store does not have a rating functionality. Or we include this dependency conditionally - but I don't know yet how to accomplish such a conditional dependency.

Those are the remaining packages/classes. Seems pretty expected that we use location services, but I did not expect this is non-free Google code. Wondering how for example OsmAnd is handling this

cat /tmp/classes.txt | cut -d " " -f 6|rev|cut -d/ -f2-|rev|sort|uniq
'com/google/android/gms/auth/api/signin
'com/google/android/gms/auth/api/signin/a
'com/google/android/gms/common/annotation
'com/google/android/gms/common/api
'com/google/android/gms/common/api/internal
'com/google/android/gms/common/internal
'com/google/android/gms/common/internal/v
'com/google/android/gms/common/util
'com/google/android/gms/dynamite
'com/google/android/gms/location

[amenk]

@SamuelRioTz do you know which flutter packages use those Google dependencies which are incompatible with F-droids licensing, and if they can be replaced?

[Zverik]

Adding this to pubspec might help:

dependency_overrides:
  geolocator_android:
    git:
      url: https://github.com/Zverik/flutter-geolocator.git
      ref: floss
      path: geolocator_android

[amenk]

@Zverik that seems to work well, thank you so much

Are you planning to maintain this fork somehow? Or should we create an issue at flutter-geolocator and try to make a PR to remove the Google dependencies maybe using a compile-flag so something like this?

[amenk]

F-droid checks / builds are all green now.

Inclusion request: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11834

[Zverik]

Alexander, please test the build first: I have an issue with geolocator when it doesn't activate the GPS receiver, making it an interface for Google services (see https://github.com/Baseflow/flutter-geolocator/issues/1114). Maybe that's in my code, but maybe it's a bug in the library. I'm trying different options now, this fork was one of them.

[amenk]

@Zverik What do you mean exactly? I tested the build and have to say I found one known issue which I think is low priority: I have to click the locator button again after granting permission in the first attempt to actually "jump" to the current location. This seems to be a bug in Trufi core already, because it happens also with v0.2.0 where we did not yet remove GMS and it is also happening with the main trufi app.

Or are you talking about something different?

[Zverik]

Hey, if it works, great! Gives me hope that I can sort out GPS in my code :)

[Zverik]

Regarding the support, the branch will stay there, and I might do further branches when geolocator_android is updated. Depends on whether I end up staying with the library, but you can also create issues in the repo to remind me. I'm pretty sure this cannot get into the upstream.

[amenk]

Ah okay, it was already discussed here: https://github.com/Baseflow/flutter-geolocator/issues/841#issuecomment-1122188744 Looks like the only option is a fork.