Add F-Droid Build Flavor

[ghost]

F-Droid has a non-free policy that does not allow the use of Private API's in order to support their platform as a distribution channel we need a build we will call "fdroid" which will need to be free of all third party API's as of our current release this means we will need to remove:

play-services (Crash Data, Sharing, Google Drive Backup) and smooch (Feedback, Support)

This build should also disabled any UI elements which point to features enabled by these third party API's being removed.

We will evaluate what degree of support we can provide to end users on F-droid which may be limited by these restrictions.

[mvdan]

To clarify - we are not against non-free APIs. We have twitter clients, for example. The difference is that these twitter clients don't use non-free java API libraries.

Our inclusion policy is simple - no non-free software.

OTOH, you can set up your own f-droid repository and upload whatever you want to it. See https://f-droid.org/wiki/page/Known_Repositories - non-free apps like Offi have set up their own repo.

[Skeptyc]

I don't think it's unreasonable to provide support for people who don't want Google scraping their data. Quite a few people run Android without Gapps (either by choice, or because they're using Amazon devices, etc) - and I don't see how supporting those people is bad, either.

[ghost]

Right and if we had feedback requesting that we probably would have prioritized such a build much sooner but we haven't so basically were undertaking extra work and supporting a platform where we don't anticipate any users or at the very least so few users that the burden outweighs the few users we might gain.

But alas were moving forward with offering a build but still we need to issue F-Droid a license to use our Wordmark, Branding and other IP which it didn't seek appropriate permission or a license to distribute or use.

[grote]

@bkerensa You might want to look into how Mozilla software was rebranded by Debian because of a similar license issue. In the end Mozilla let them use their branding. What's the point of releasing Free Software, but than trying to hold back certain freedoms?

[ghost]

@grote

"You might want to look into how Mozilla software was rebranded by Debian because of a similar license issue. In the end Mozilla let them use their branding."

I'm quite aware as I was involved in those discussions over the last few years to rebrand Iceweasel as Firefox again (Which recently happened after common ground was found).

"What's the point of releasing Free Software, but than trying to hold back certain freedoms?"

Our branding is not part of the covered work specifically all of our source code is GPLv3 with the exception of Glucosio for iOS which is parallel licensed both GPLv3 and MPL 2.0. We reserve all rights to our word mark and other branding to include our mascot. Even if it was part of the covered work Section 7 (c), (d) and (e) of the GPLv3 actually allow us the freedom as copyright holders to make the same restrictions but in this case branding is not a covered work.

[ghost]

@mvdan informed me via email that F-Droid is not interested in distributing Glucosio so marking this won't fix and sadly the discussion today and over the past months and efforts on our part have been wasted.

[paolorotolo]

We made a new branch that contains a FOSS-only version of Glucosio: https://github.com/Glucosio/glucosio-android/tree/foss-only

You can build the latest Glucosio version from there.

[ghost]

Thanks for your effort. However, it doesn't look like this is completely done, at least I run in quite some google dependencies. I tried to strip them but ended up in a depency hell. Here's what i tried before building:

rm -fR wear
echo "include ':app'" > settings.gradle && sed -i -e '/wearApp/d' -e '/wearable/d' app/build.gradle && \
        sed -i -e '/google-services/d' build.gradle app/build.gradle && sed -i -e 's|@integer/google_play_services_version|0|g' app/src/main/AndroidManifest.xml

Btw: where is com.google.android.support:wearable comming from?

[paolorotolo]

Sorry @krt16s I forgot to remove the wear module. Try now please.

[ghost]

/home/krt/src/fdroiddata/build/org.glucosio.android/app/src/main/java/org/glucosio/android/activity/MainActivity.java:56: error: package com.google.android.gms.common does not exist
import com.google.android.gms.common.ConnectionResult;
                                    ^
/home/krt/src/fdroiddata/build/org.glucosio.android/app/src/main/java/org/glucosio/android/activity/MainActivity.java:57: error: package com.google.android.gms.common does not exist
import com.google.android.gms.common.GoogleApiAvailability;
                                    ^
/home/krt/src/fdroiddata/build/org.glucosio.android/app/src/main/java/org/glucosio/android/activity/MainActivity.java:58: error: package com.google.android.gms.common does not exist
import com.google.android.gms.common.GooglePlayServicesUtil;
                                    ^
3 errors
 FAILED

[paolorotolo]

@krt16s Ok there was another Google Play Services check in MainActivity. Since the FOSS build surely will not have GPS installed I've removed it.

[ghost]

Still a string not caught, but at least with this modification it builds:

https://gitlab.com/fdroid/fdroiddata/commit/7e3e496c6fe9f59e1d54415bc74eac577a1388c9

However, I'll wait for you to merge as much as possible upstream, try to build again, test the release and then enable the build. So if everything is good, we might have the version this weekend :). Thanks for the awesome work!

[grote]

Since the FOSS build surely will not have GPS installed I've removed it.

What do you mean by that? Phones without proprietary Google libraries still have GPS and it can be used by apps as well, just not via the API provided by the proprietary libraries.

[paolorotolo]

@grote We had a method to check if Play Services were available on the phone before opening Invites or Google Drive backup. Both Invites API and Drive SDK on Android are not open source so the check itself is not needed on the FOSS only build.

@krt16s Thanks for your work, I'll remove the string ASAP.

[ghost]

Once this is live ping me on coreteam and I can grab their badge https://f-droid.org/posts/get-it-on-f-droid-badges/ and stage it for our next site update.

[paolorotolo]

Okay, @krt16s is it fine now?

[ghost]

I still apply a small change to the manifest, but it builds, installs and works (as far as I can tell). I enable the build, see https://gitlab.com/fdroid/fdroiddata/commit/c6229fea.

ps: Sorry for missing my own timeframe -.-

[paolorotolo]

I see on F-Droid page that the build succeeded, thanks for your efforts. I'll close this issue as soon as Glucosio will be available in the repository: https://f-droid.org/repository/browse/?fdid=org.glucosio.android

[mvdan]

FWIW, if you want to link to your app on F-Droid you can use the shorter https://f-droid.org/app/org.glucosio.android - it's what the badge uses.

[mvdan]

Also, I'm pretty sure I already asked in this thread but can't find the comment - what happened to the licensing stuff? Do we still need a license to distribute modified versions of the app?

[ghost]

We've already issued a license to use our branding which is trademarked.

Our code is dual licensed under the GPLv3 and MPL 2.0.

[mvdan]

We've already issued a license to use our branding which is trademarked.

So I understand we are not allowed to make any modifications to the distributed app, unless we completely rebrand the app?

I just want to make this clear. Especially since we tend to patch things quite often to get builds to work - @krt is even doing it already to build the app.

[mvdan]

I think we did receive one, but we never requested nor agreed to it.

Edit: we got an email about a ticket about getting one, but we never got the actual license.

[ghost]

@mvdan in your response to your question we do not place any restrictions on your editing the app. Should edits harm the reputation of our brand we reserve the right to revoke the branding license.

This setup is not unique and many major open source projects including apps you already distribute have the same policy.

Our position on our brand is very similar to Mozilla's and you already distribute Fennec on FDroid so hopefully that answers your question.

The permission granted does not restrict your freedoms granted by the license of the source code. It only protects our brand and allows us to withdraw if downstream or any third-party harm's the reputation of our brand or harm our end users.

Distributing software like Glucosio can be subject to regulation in multiple countries including the U.S. because of the nature of the data it analyzes and it's use in managing ones disease.

We definitely for instance would revoke permission under any of the following scenarios:

• Legal disclaimers removed or modified
• Any modification that presents a risk to the end users health
• Any modification to formulas that estimate HBA1C or could impact the visualization of health data
• Any modification that would contradict our terms of service of privacy policy
• Any modification that would cause irreparable harm to our brand
• Any modification that would introduce legal risk to our foundation
• Any modification that would change the app to such a degree that we no longer feel it is the app we author

These are the circumstances where we would most likely revoke permission after consulting legal counsel, our advisory board and our board of directors and core team.

[ghost]

Also it might be helpful if we had one person we were working with at FDroid as I'm not sure who CiarinG is or his affiliation with your project. If we could have one maintainer downstream or one FDroid contact that might be an easier way to maintain communication with less confusion.

[mvdan]

This setup is not unique and many major open source projects including apps you already distribute have the same policy.

We've never agreed to any terms like these, so that's not the case. It might be because we didn't notice or because it wasn't brought to our attention, but that's a different matter.

These are the circumstances where we would most likely revoke permission after consulting legal counsel, our advisory board and our board of directors and core team.

We have none of those and we have no interest in dealing with any of this, which is why we're not agreeing to any such terms in the first place.

Keeping the existing apps up to date is enough work for our small team, so dealing with extra policies and restrictions set by apps is not something we're keen on doing.

If we could have one maintainer downstream or one FDroid contact that might be an easier way to maintain communication with less confusion.

We don't have maintainers and we don't have paid employees, so that's very likely never going to be available.

[mvdan]

And as said before, you are free to set up your own F-Droid repository. This is not a "this app will never be available on F-Droid", rather a "we don't want to deal with this ourselves in the long term".

[ghost]

In regards to you not agreeing with upstream trademark policies that's not how it works. When you distribute you have agreed to any policies upstream. So until you stop distributing Mozilla Firefox your subject to their trademark policy and we take the same legally.

We are definitely sad you cannot agree to what we believe are very common sense protections for our end users. But legally we have an obligation to protect ourselves as medical software is regulated when distributed in binary form and the risk is on us as a project not on downstream. We believe our asks are very fair and common sense. We're not saying you can't make edits or introduce patches but that you cannot put our users at risk for our project at legal risk.

Sorry we couldnt agree on that and in terms of maintaining our own repo I'd leave that decision up to the module owner for Android which is Paolo decide whether he wants to invest his teams energy in maintaining such.

[ghost]

FWIW our policy is less restrictive btw:

"addition, if you are distributing Mozilla binaries yourself, and wish to use the Mozilla Mark(s), you may not (a) disable, modify or otherwise interfere with any installation mechanism contained in a Mozilla product; (b) use any such installation mechanism to install any plug-ins, themes, extensions, software, or items other than the Mozilla product; or (c) use or provide any program, mechanism or process (other than an installation mechanism contained in the Mozilla product) to install such product. Any use of a meta-installer would require our prior written permission."

"If you're taking full advantage of the open-source nature of Mozilla's products and making significant functional changes, you may not redistribute the fruits of your labor under any Mozilla trademark, without Mozilla's prior written consent. For example, if the product you've modified is Firefox, you may not use Mozilla or Firefox, in whole or in part, in its name. Also, it would be inappropriate for you to say "based on Mozilla Firefox". Instead, in the interest of complete accuracy, you could describe your executables as "based on Mozilla technology", or "incorporating Mozilla source code." In addition, you may want to read the discussion on the "Powered by Mozilla" logo.

In addition, if you compile a modified version, as discussed above, with branding enabled (the default in our source code is branding disabled), you will require Mozilla's prior written permission. If it's not the unmodified installer package from www.mozilla.com, and you want to use our trademark(s), our review and approval of your modifications is required. You also must change the name of the executable so as to reduce the chance that a user of the modified software will be misled into believing it to be a native Mozilla product.

Again, any modification to the Mozilla product, including adding to, modifying in any way, or deleting content from the files included with an installer, file location changes, added code, modification of any source files including additions and deletions, etc., will require our permission if you want to use the Mozilla Marks."

See any changes really and here were only setting limitations that introduce legal risk.

https://www.mozilla.org/en-US/foundation/trademarks/policy/

[ghost]

@mvdan

So I am curious what exactly is it about our policy is it that FDroid objects to?

https://f-droid.org/repository/browse/?fdcategory=Internet&fdid=org.adblockplus.android
https://adblockplus.org/blog/adblock-plus-trademarks

https://f-droid.org/repository/browse/?fdid=com.github.dfa.diaspora_android https://wiki.diasporafoundation.org/Trademark_guidelines

https://f-droid.org/repository/browse/?fdcategory=Internet&fdid=se.johanhil.duckduckgo&fdpage=2 https://duck.co/help/company/partnerships

https://f-droid.org/repository/browse/?fdcategory=Internet&fdid=org.mozilla.firefox&fdpage=2 https://www.mozilla.org/en-US/foundation/trademarks/policy/

https://f-droid.org/repository/browse/?fdcategory=Internet&fdid=com.nextcloud.client&fdpage=4 https://nextcloud.com/trademarks/

Just a few minutes and all these apps you distribute and maintain all have trademark policies some of which your not even complying with. Trademark policies are not something FDroid agrees to rather the terms are automatic when you distribute the brand.

The GPLv3 is compatible with trademarked brands so its not like your freedoms are being restricted here and our asks are must more common sense than other projects.

Ideally we would like FDroid to maintain a repo off our branch and we do not see any problem with changes you need to make or modifications. Our trademark policy only exists to legally protect our brand as is required by law and to protect our brand and project from liability since this is a medical app.

Our legal counsel advised us we need to take such precautions.

[mvdan]

So I am curious what exactly is it about our policy is it that FDroid objects to?

Nothing. If an app has a policy or rules we have to obey to publish it, we usually don't bother. This has happened in the past with upstreams who would get very upset if their apps were not kept up to date, or if we were distributing a version with less features since they required google play services.

As I said, we barely have the manpower to keep the existing apps up to date - https://f-droid.org/wiki/page/Category:Apps_to_Update - so adding new apps that require extra attention is not a good idea.

[ghost]

Nothing. If an app has a policy or rules we have to obey to publish it, we usually don't bother.

And so in this case were saying as long as nothing malicious occurs that could jeopardize our brand or put us at legal risk we would never consider revoking use of our trademark. I just hope our effort here is not in vain and that F-Droid will reconsider.

All the apps I mentioned above have rules and policies you must follow to publish but it seems you take no issue with their policies and freedom to have such policies under the GPLv3?

Our trademark policy is a freedom we as authors are entitled to under Section 7 (e) of the GPLv3 https://www.gnu.org/licenses/gpl-3.0.en.html https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html#gplv3

I mean you are basically objecting to us exercising our freedom under a free software license but at the same time simultaneously respecting other upstreams right to exercise that same freedom? Basically in order to publish with F-Droid we have to give up that freedom or publish ourselves?

[mvdan]

I mean you are basically objecting to us exercising our freedom under a free software license but at the same time simultaneously respecting other upstreams right to exercise that same freedom? Basically in order to publish with F-Droid we have to give up that freedom or publish ourselves?

You're overcomplicating things. I said we do not want to take care of this. I invited you to open your own F-Droid repository, which then you can handle yourselves.

[elioqoshi]

@bkerensa I'd hate not to miss out on F-Droid. Can we proceed with this?

[ghost]

@elioqoshi They asked us to make them a build that meets their requirements and said they would re-enable builds and we did that it was their choice to ultimately change their mind again.

We are an upstream and if F-Droid wants Glucosio available to their users the branch is there they are choosing not to re-enable it and offer it.

We cannot keep playing this back and forth with them it takes time away from work on our software which needs to come first.

[ghost]

@PaoloRotolo as we look at our expansion to Chinese verticals in the next release cycle we can have this on discussion for core team to decide whether to maintain a F-Droid repo.

[mvdan]

Since you did the flavour, how about we just publish it and forget about the whole terms thing. My only concern with it for our repo is that we don't have maintainers - as said, not enough people - and we can't guarantee that we will not break your conditions.

Then, if we do break them, simply tell us and we will see if that can be fixed - or the app dropped again. That means no extra work for us than any other app.

[ghost]

@mvdan We have to consistently protect our trademark I would not worry about us litigating your project we are underfunded and do not have the capital to hire an attorney to sue you guys if you did make a mistake. The only time we would ever enforce our license and revoke trademark use is if a negligent act were done that being you guys intentionally did something to harm our users or our brand which I do not see happening.

So would that work? I really do not see this being an issue ever just like other large more corporate projects like Mozilla have not come threatening with lawyers.

We do want to be on F-Droid we do value and appreciate the F-Droid model and even if we do not have as much users we still think it is important to be on F-Droid so that users who use forks like Copperhead can use Glucosio without compromising their values and being forced to use GP.

[mvdan]

Okay then. I'm having some issues building without the Google maven repo installed though, might open an issue about that.

[mvdan]

Oh, I was trying to build 1.2.0 and not from the foss branch. I can't do anything with it as it's not up to date with 1.2.0.

[mvdan]

Also, it would help tremendously if you could tag foss releases too. This way we can enable automatic updates. Otherwise, we will have to manually check the branch HEAD for a commit hash and old builds are likely to break if you rebase on master instead of merging.

[paolorotolo]

Good to hear @mvdan. I'll take care of updating the FOSS branch.

[paolorotolo]

@mvdan Done, I've just released 1.2.0-FOSS. You can find it here: https://github.com/Glucosio/glucosio-android/releases/tag/1.2.0-foss

[mvdan]

Hmm, there is 1.2.0-foss and 1.2.0-FOSS. They both point at the same commit, but which format will you be using?

[mvdan]

(fingers crossed it's not the all caps one)

[paolorotolo]

1.2.0-foss is the right one. The all caps one was pointing to devel branch instead of foss-only.

[mvdan]

Cool then. You might want to delete the all caps one just to avoid confusion.

[paolorotolo]

Sure! So try to build from here, let me know if there're issues: https://github.com/Glucosio/glucosio-android/releases/tag/1.2.0-foss

[mvdan]

1.2.0-foss contains the version 1.1.2-FOSS, so that won't do.

[paolorotolo]

Sorry I just realized build.gradle wasn't updated. Try now please.