Add to F-Droid

[licaon-kter]

I see some stuff that needs to be separated under a gradle flavor (google services, cast, firebase, billing. oss-license: as these are either not FOSS or depend on not-FOSS libs). Sentry/Tracks is ok but it might warrant a Tracking antifeature if not opt-in.

A custom maven repo is used for which dep (Automattic-Tracks)? That is FOSS. Is it available in other repos, eg. Maven Central? Or we need to build it.

/LE: updated deps info

[eighthave]

As an F-Droid contributor, I'm here to offer my help getting Pocket Casts to be free software.

[xrishox]

would love to see this project added to fdroid

[IzzySoft]

Still not even a response from the team? Third F-Droid contributor here. There's already an inclusion request open with us for several month which we cannot proceed with, as we'd need your help. Count the thumbs how many folks wait to see your app there, doesn't that convince you it should be included? You were even offered a hand for that. So may I kindly ask you to join the efforts? Thanks in advance – @mchowning & all!

[mchowning]

Thanks for following up @IzzySoft . This had fallen off my radar.

It would be great to see Pocket Casts on F-Droid, but unfortunately this is not a focus for the core team at this time. I'm happy to help move this forward and do what I can unblock anyone who wants to work on this though.

What do you think would be the best first steps? Is there anything you need to unblock this work?

I see some stuff that needs to be separated under a gradle flavor (google services, cast, firebase, billing. oss-license: as these are either not FOSS or depend on not-FOSS libs).

How would we go about separating these? Something like calling a wrapper around these libraries that has a noop implementation in the f-droid build flavor, or something else?

Sentry/Tracks is ok but it might warrant a Tracking antifeature if not opt-in.

Just applying the Tracking anti-feature flag sounds like the best option at this time to me.

[IzzySoft]

Thanks for your reply, @mchowning! I'm not an Android dev myself, so I cannot speak for "proper implementation" nor how to set up build flavors (I've seen that a lot, though, that build.gradle e.g. had gplayImplementaion for Firebase to keep it out of the foss flavor – and maybe fossImplementation for a dummy). If you'd need a dummy, it should better not have the same "paths" (e.g. the "stub" should not have the same package name, as that would lead to "false alerts" in the scanners). At least if it can be avoided.

As for the Tracking AF: why not making Sentry opt-in instead? Have a bool setting for that initiated with NULL, so on first start the user is asked for consent – and later can correct the decision via the settings of the app)? That would avoid the AF. Again, that can also be done flavor-wise – though I'd recommend opt-in always (also GDPR-wise).

Now reaching the top: first steps. I didn't work on that RFP, it just came to my attention in one of my triage runs. Let me take a quick look…

1. moving Billing and GMS with the install referrer, Firebase etc. to a gplayflavor to keep them out of the foss build, as those two are show-stoppers for F-Droid
2. making Sentry opt-in
3. setting up Fastlane (I can help with that step – or you could use my Fastlane Cheat Sheet for guidance)

As for cloud messages: you might wish to take a look at UnifiedPush, which is a FOSS way to achieve that. For your Playstore release (gplayImplementation), you could bundle their FcmDistributor, so folks there wouldn't even notice a difference – while shipping the foss flavor entirely without distributor, and folks can pick the one they prefer (see e.g. Push Clients/Manager – several apps at F-Droid do so already). That could be implemented in a second step, once flavors are set up and all is ready (i.e. the first FOSS release might simply come without, one of the next will fill it in – so you don't have to do all of it at once).

[IzzySoft]

@mchowning the due-date of the F-Droid RFP was just reached again, so may I ask where we stand here? Do you have any ETA for when these issues might be addressed? I just skimmed the release notes made since our last contact, but could not see any related entry. Do you think it's realistic until end of the year – or should we rather close the RFP and wait for you to open a new one once you're ready?

[mchowning]

Hi @IzzySoft ! This still isn't something that the core team can focus on because there are a fair number of other, higher priorities on our roadmap. I don't think this will be done by the end of the year unless some open-source contributors decide to pick this up and run with it, so it may be best to just close the RFP for now.

[erebion]

Isn't it just removing some proprietary play services stuff and tracking for building a serate version? o.O

Or even tracking opt-in which it should be anyway?

[IzzySoft]

@erebion basically yes. Relevant output from the library scanner (everything marked NonFreeDep would be affected here):

Offending libs:
---------------
* BillingClient (/com/android/billingclient): NonFreeDep,NonFreeNet
* Automattic-Tracks-Android (/com/automattic/android/tracks): Tracking
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Google Cast (/com/google/android/gms/cast): NonFreeDep
* Android Wear APIs (/com/google/android/gms/wearable): NonFreeDep
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Firebase (/com/google/firebase): NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): NonFreeDep,Tracking
* Firebase Installations (/com/google/firebase/installations): NonFreeNet
* Tasker Plugin Library (/com/joaomgcd/taskerpluginlibrary): NonFreeAdd
* Sentry SDK for Java (/io/sentry): Tracking
* Tasker (/net/dinglisch/android/tasker): NonFreeAdd

12 offenders.

So that would mean to at least remove: BillingClient, Google Cast, Android Wear, Firebase incl. Firebase Analytics, then GMS if it's not gone then already as it probably was just dragged in by the aforementioned libs. Remaining libraries would "only" raise anti-features at F-Droid, where Tracking could then be avoided by making the remaining analytics packages (Automattic-Tracks, Sentry) opt-in – and NonFreeAdd (for Tasker) is arguable (could probably be ignored).

[eighthave]

@mchowning would you accept a pull request that adds a "free" build flavor that removes the proprietary libraries? Then there will be a build flavor for the current state, whatever you want to call that. It is often called "play" after Google Play.

[mchowning]

would you accept a pull request that adds a "free" build flavor that removes the proprietary libraries? Then there will be a build flavor for the current state...

👍 We would gladly accept PRs toward that @eighthave! I do think that getting to a fully free build flavor will require quite a few changes, so I just ask that the work be broken up into separate PRs where possible so that it's easier to review and test the PRs.

[eighthave]

I just took a quick look. I agree, the best approach here should be to chip away at it in multiple merge requests. I just submitted the first, which defines the gplay and free build flavors, based on well honed setups in Nextcloud, Element, and other apps. https://github.com/Automattic/pocket-casts-android/pull/1206

[codenyte]

Any updates?