Add this version to IzzyOnDroid

[DUOLabs333]

Is your feature request related to a problem?
The version available in F-droid hasn't been updated in a while (which makes sense, as you're going to focus on the full-featured version). IzzyOnDroid has much laxer policies about inclusion than F-droid, so this might make it in.

Describe the solution you'd like:
Request inclusion into IzzyOnDroid. This will include making apks available in the repo's releases.

Describe alternatives you've considered:

A clear description of any alternative solutions you've considered.

[KaustubhPatange]

I checked their repo & found this line,

• it preferably has no proprietary components. While some of them might be acceptable, trackers (e.g. ads, analytics) are tolerated at best but only if there are no more than two such modules.

So from this statement, only ads & analytics SDKs are allowed but the app uses "Google Authentication" for the synchronization functionality to work i.e Firebase Auth & even Firebase Realtime database where user's data is stored. They definitely will a scene out of it.

Also, consider this statement,

should be free (as in „free beer“ and as in „free speech“) and Open Source

The term "free" here means no in-app purchase & if you look at the app there are in-app purchases if you go to Settings > Upgrades where you can buy some digital assets which unlock some of the features of the app & it uses Google Play API which requires Google services to be present on the user's device.

All in all, it is almost the same effort as F-Droid which is why it is important to have a single source of the store where users can download the app. Also if you worry about privacy then don't as the app collects absolutely no information about you & anything you do. So chill & keep using the version from "Google Play" as it will also help me to serve updates faster :)

[DUOLabs333]

Could you update the F-droid version, or did you stop working on it?

[KaustubhPatange]

As you predicted, yes I've stopped working on maintaining the F-droid version.

[jstetten]

Hey @IzzySoft , as the expert, do you concur?

The creator's full explanation is here, and we should respect their wishes.

Thanks!

[IzzySoft]

As there is not even an APK available here, there's nothing I could pick. So I cannot even tell if I would if it were there, as I cannot check. Going by the gradle definitions:

    implementation(LibraryDependency.BILLING)
    implementation(LibraryDependency.FIREBASE_REALTIME_DATABASE)
    implementation(LibraryDependency.FIREBASE_AUTH)
    implementation(LibraryDependency.FIREBASE_CRASHLYTICS)
    implementation(LibraryDependency.FIREBASE_ANALYTICS)
    implementation(LibraryDependency.PLAY_SERVICE_AUTH)

doesn't look convincing to me. For me personally, that would be a clear no-go: why would I want the contents of my clipboards copied to elgoog? And even stored there (Firebase Realtime Database)? Clipboard contents should stay on-device or only sync to where I want to sync them (like here, on my devices).

So apart from the proprietary parts, I'd count that a clear violation of my privacy.

Why not instead use build flavors, so there's a "clean" FOSS flavor that could be used with F-Droid? Seeing Firebase Realtime Database I guess your app already depends on that online storage (does it even work if there's no internet connection then?) Which would mean "plan B": if you cannot make that "local storage" (which would be much preferable), there are replacements for those proprietary parts named Firebase, like appwrite and Supabase. So the flavor would only need to exclude billing and play/firebase auth then. If you insist on analytics, some FOSS replacements are listed here – but whichever you choose, please make sure they're opt-in.

That done, I wouldn't even need to ask for an APK to be attached, as you'd be eligible for F-Droid.org itself again.

---

As for the interpretation made by @KaustubhPatange – "only ads & analytics SDKs are allowed" is not what is meant, but rather that those are expressively count as "unwanted" if proprietary. And the term "free" relates to the 4 software freedoms (maybe I should link that there to make it clear, so thanks for bringing that up!) So if there's a FOSS variant of in-app-payments for donations, that's totally fine. Just e.g. Play Billing is proprietary and bound to a proprietary system, so it's considered a clear anti-feature.

it is important to have a single source of the store where users can download the app

I might concur with that if it's a place open to all users – which Play Store certainly is not 😉

[DUOLabs333]

@IzzySoft They actually used to have a F-droid version, but abandoned it. Also, the app only optionally requires Firebase -- by default, it's local only.

[IzzySoft]

The second fact is good to know! Then a FOSS flavor (not including Firebase etc.) should be possible right away. If then analytics is stripped as well and an APK attached here which fits into the size limits of my repo (i.e. max 30 MB), the billing part would be acceptable to me (and just cause the proper anti-feature to be raised) – or, if that could also be excluded from the then real foss flavor, F-Droid could pick up updates again directly.

[KaustubhPatange]

@IzzySoft I can maybe work around this. Just for clarification an app without Firebase's Realtime database but it can include Google's In-App-Billing would be okay with you? Also, considering online sync functionality will be disabled is there a way I can keep the dependency on Firebase Crashlytics & Analytics as they really help me to measure app crashes, ANRs & other performance metrics like slow startup time, etc. Is this possible?

If yes, this repo has a CI pipeline that uploads a release apk as an artifact upon every commit on master. I can configure it to produce a foss build as a Github release if these above requests are okay with you?

[IzzySoft]

Let's say GBilling would be acceptable. But as soon as you include the two analytics modules, you will most likely again have more than 4 proprietary libraries in your app. I could check if there's such an APK available to me – but I certainly would feel proprietary analytics a show-stopper here. Quote:

if the app processes sensitive data (e.g. health data, passwords), is intended to improve security/privacy, has root permissions, or is targeted at children, it must have no trackers at all

Now guess what data end up in the clipboard. Most likely all kind of, including the examples mentioned.

I'd say you get those analytics from your users at GPlay, which will certainly be the majority – so maybe the "privacy focused" variant can do without? Or at least with one of the FOSS alternatives I've linked above, and opt-in?

That said (or asked), I might raise the question what good GBilling would do in this place: those wanting the app from outside play are very unlikely to use GBilling 😉 Many of them will even run devices without GServices and especially without a GAccount, so that lib would be pretty useless in this build variant. Instead, be welcome to ask for donations using different channels (which Google forbids, and which because of that you cannot utilize in your Play version). Not promising you billions here, but it might offer possibilities you'd not have otherwise. If you're interested, I could see what donation libs my library checker has recorded.

[KaustubhPatange]

@IzzySoft I can find a way to get away with Firebase Crashlytics and Analytics. The app also has a different crash reporting server using sentry.io, if that is okay with you I can disable the Firebase one and completely depend on sentry.io.

Although removing Google In app billing could be helpful as there are no promising alternatives. If you know some better libraries I can mitigate around this to make it only work on foss version?

[IzzySoft]

Sentry.io is totally fine (it's fully FOSS). As for payment/donation libs: I haven't checked any of them, but let me have a look in my library definitions for possible candidates (without any ranking or explicit recommendation, just listing my findings):

• Android Donations Lib (Apache-2.0): author is a well known FOSS contributor (SufficientlySecure has several apps at F-Droid)
• AndroidDonate (MIT)
• Adyen Components for Android (MIT)
• Stripe Android SDK (MIT)

These seem to be the ones without ties to playstore or dragging in a bunch of trackers (not sure what the last 2 might bring along, though). As pointed out, I haven't had a deeper look – so apart from the first one I'd say should be absolutely fine, and the second one I guess is clean as well, I cannot really tell. Both Adyen and Stripe are payment processors.

[jstetten]

Wow guys, thanks for the open exchange of ideas. A solution for everyone seems much more possible than I thought.

@KaustubhPatange, I can't speak for all privacy- conscious users, but I do think many of us are happy to donate to let high-quality open source software flourish. Especially if it's something they've come to depend on everyday, users have as much interest in the project's longevity as the makers. (The chances of them being a sympathetic fellow dev is also...well, it's not low.)

[KaustubhPatange]

Yeah, I'm considering this! Still not sure the libraries recommended by @IzzySoft could be used with the existing billing logic & how to swap the existing logic for the Google Play version as they don't allow any third-party billing library that could get my app banned if I try to do so.

All in all, it's also a good effort from my side. I'll pick it up soon when I find free time from my job.

[KaustubhPatange]

@rihaq Sorry man, since I'm very much caught up in my job I don't think I would be able to maintain a separate source with all these vendor-specific dependencies removed. It has already become difficult for me to maintain this project since I hardly find any time but nonetheless, I'll try to find time & at least maintain this version of the app :)

[IzzySoft]

@KaustubhPatange as pointed out – and already confirmed by you:

I can find a way to get away with Firebase Crashlytics and Analytics.

That would make it eligible for my repo – so you can solve the remaining things (billing) later, to get back with updates on "F-Droid proper". Google meanwhile had to accept a "change of mind", allowing alternative payment methods for apps on Play btw,

Approach for the billing stuff: You could have a wrapper for that, including PlayBilling in the Play version and the alternative in the FOSS one, and then include the underlying, service-specific functionality depending on the flavor (e.g. the gplay flavor has a billing.kt utilizing PlayBilling, while the foss flavor has a billing.kt utilizing one of the donation libs – both billing.kt offering the very same interfaces so they can be swapped easily). F-Droid then would build the foss flavor and be fine with it – and you could use the gplay flavor for PlayStore-builds.