Paid features in opensource apps

For purely technical reasons, it must have a different “package ID”. There can’t be two apps with the ID “”. I’m not sure what the exact rules from F-Droid’s side are for the app name and its icon, but changing them from the original so you can tell them apart is highly desirable.

Changing the name can be also be mandatory through the app’s license, but that depends on the license.

1 Like

Well, actually I think ads are much, much worse, depending on how they are implemented.

Ads cause network activity and leak information, even if they aren’t explicitly tracking you.

A pay-to-unlock feature just sits there until you click it and is, until then, quite harmless.


some of the things you bring up are very clear,

  • if it has an ad, then it should be marked with that Anti-Feature
  • if it requires a non-free network service, it should be marked
  • if it tracks the user, it should be marked

Given the name of the topic, I’d like to broaden the conversation a bit to determine precisely what F-Droid will allow, in which variations, based on comments I’ve made & seen @ other open-source projects.:

1 Like

(sorry again) I still believe obfuscation should not be recommended on fdroid : I’m referring to post scans on apk using ./dexdump org.mozilla.firefox.apk | grep "Class descriptor" in order to identify known bloatware prints (transparency).
Since the apks on fdroid are open source, what obfuscation (scramble classes exception to ads/analytics ; check example greenify.apk) can be good for ? Maybe an anti-feature could be raised in such case: also I don’t even know if there is such case actually on fdroid…

I also believe permission READ_LOGS should raise an anti-feature; is there a way to list all fdroid apks using it?

Thx for helping.

(btw, I don’t get why F-Droid & Gitlab concatenates spaces in InsertCode considering potential sed expressions: 2xSpaces-> <- !?)

Google quote: Be careful when writing to on-device logs. In Android, logs are a shared resource and are available to an application with the READ_LOGS permission. Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications…

It’s of no particular consequence to me if apps have paid features or other moneymaking mechanisms built in, and I am fully aware that nothing about doing this violates most open-source licenses or the F-Droid rules. However, I personally have little or no extra money available to buy extra features, and my use cases almost always require the edge-case/“power user” features that most developers choose to make paid-only, so I always prefer to seek out apps that don’t have these types of things. Until recently, F-Droid has always provided the ability for me to do this easily with its anti-feature flag system, but then I encountered Fair Email and NetGuard, both of which contain ads and paid features and neither of which bear any anti-feature markings.
While I by no means want to declare any entitlement to apps that don’t contain undesirable features, I also have no tolerance for those that do, and it would really help me a lot of these anti-feature markings were maintained more completely, so that I could be saved the trouble of installing them and only finding out that I can’t do certain things when I actually attempt to do them. This occurrence is why I no longer use apps from Google Play when I can avoid it, as it is a serious nuisance to me.
Once again, I definitely do not think that these apps should be removed from F-Droid or that their developers are doing something wrong; I simply think that there should be more transparency about what an app does on its F-Droid installation page. Paid-only features are a big deal to me and many other users, and so I think that they should be well-indicated before the app is installed.

To put it in a more concise form, here are some lists. I want to make it clear that they do not attempt to explain any laws, F-Droid’s rules, or any other objective or binding requirements, but merely my own thoughts.
These are things that I think developers should be allowed to do without receiving backlash:

  • make apps with paid features or advertisements
  • post these apps on F-Droid
  • refuse to assist in obtaining free access to paid features
  • refuse to provide support for the app for any reason

On the other hand, the following are things that I do not believe are things that developers should do, or that should be condoned by F-Droid:

  • attempt to hide the existence of paid features or advertisements in their apps during the user’s selection and installation process
  • call other people over-entitled or freeloaders for refusing to use apps with paid features or advertisements
  • direct backlash against people who take legally-permitted actions to avoid paid features or advertisements, or to circumvent them in their own copies of apps (e.g. building them from modified source)
  • insist that their apps do not contain anti-features, when, in fact, they do

I am completely aware that app developers need money to live just as much as anyone else. However, I really do not believe that they should have any right to hide the paid-only nature of certain features until a more opportune time and place than the F-Droid installation page as a marketing strategy. I think F-Droid needs a “contains paid features” anti-feature flag, and that this and the other anti-feature flags should be kept up-to-date with due diligence for all listed apps. Without this, F-Droid becomes much less useful and much more frustrating for me and no doubt many others.

1 Like

But they don’t actually contain ads…right?

Actually, the developer doesn’t care about F-Droid, we are threading on a fine line here, he can drop by and say “how about you take it down?”, would that be better than a button on the main screen of the app? (Hey, how often do you open NetGuard, really?)(Yes, this has happened and F-Droid complied… open-source app and all)

Not sure it’s useful to put “a button on screen antifeature” ('cause these 2 don’t have actual ads) in the same bucket with “tracking users”. The current system has only a toggle… for better or in this case…worse.

Bookmark the link: feel free to drop by and start fixing the metadata :+1:


What kind of ads are we talking about here?

How about you install them quick (they’re 2Mb each) and have a first impression to share, as that might be useful to grasp the experience of a new user:

  • was the description clear
  • where the free features blocked
  • are there ads?
  • are the ads making the use of the app hard?
1 Like

The description has a “Pro features” section.

I’m not the dev, hence not sure I’m the target, but my problem was not about “refusing to use” but more on easy moral judgments

Yup, fair indeed (I covered the circumvent and distribute part here: Paid features in opensource apps)

No one did this, again… case by case… also… “THE ONE TOGGLE” needs some thinking.

@oF2pks about working around obfuscation, you should check out LibScout. It detects libraries even if they are obfuscated. It would be awesome if someone integrated LibScout as an automated checker of apps in fdroiddata . proguard “obfuscation” is often about reducing the size of the APK, it isn’t only for hiding code.


I asked for the pro featured, if the pro features are released under the same GPLv3 license and the first response was “you can paid and activate the pro featured in two devices”, so in not clear how to activate that pro features and if the activation is through the non-free network and if the case it should be marked with that anti-feature flag.

What non-free network?

Please read the discussion above first.

I was reading and I understand FairMail use a non-free network to purchase the pro-features, so in that case, promote a non-free network, it also redirect to a page and inviting the user to purchase the app in PlayStore

1 Like

btw, I making a fork of FairEmail because I don’t like the unclear way to purchase the pro features:


Developers need to be intellectually honest or have a better grasp of certain words.

Don’t give away your work product if you cannot support yourself otherwise.


I will not be able to keep using EteSync after the initial 14 days, because I have to give away money.
I choose to not spend money on it. I’ll look for an alternative (paying with my data and download something from the play$tore is not an option)

What about an AntiFeature like: ‘only with money it works’?
A sort of ‘paid app’ warning that let the user know if he will be ale to still using the app after the demo period or if he will be forced to donate afterwards.


@uniqx just made a point to me that I hadn’t fully considered before. Payment requirements can be undemocratic if they are too high. But of course there is a big grey area there, since basically everyone in the world could afford 1 Euro a year to use software. F-Droid has not limited itself only to the ethics of Free Software. We mark tracking and advertising, both which are 100% compatible with Free Software. So to me, the original, overarching idea that started this thread is still an open question: should apps requiring payment be marked?

  • If an app is 100% free software, then anyone who objects to the payment requirement can fork it and remove that.
  • Would we mark apps that required users to click through a payment prompt, even if it allowed the user to enter 0?
  • How about if it required them to pay $0.01 in a fully anonymous, free software method?

If there a clear line somewhere to draw? I think it is also important that F-Droid is not anti-commercial, since developers will write better software if they can make a living doing it. So it is hazardous to mark all attempts to make a living from free software as an Anti-Feature.

I still think F-Droid should require all users to click through a payment prompt, with a default value set by the developer, and the option to set it to 0.


Listing whether an App contains paid features is certainly useful information for users. So I’d actually be happy to have this listed. But if we do so, we definitely should not do so as an Anti-Feature. There is no harm for users financially supporting App developers.

Having a note like “contains paid features” well separated from our Anti-Features is totally fine for me.

Here’s an edge case that peeked my interest: Conversations is free to use XMPP App, but it helps users signing up with the developers XMPP servers for a little subscription fee to sustains continued development. Is this what you would label as paid feature? I wouldn’t because all features of the App are totally working without ever paying anything to the developers.

1 Like

EteSync was mentioned above, I wanted to add that note… given that Fastlane is used… I’d have to PR upstream directly… let’s see how that goes. :wink:

1 Like