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.


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.:


(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.


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?


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.