While F-Droid appears to be "just" an alternative #OpenSource #AppStore for #Android, it is actually the apex of a lifestyle movement that's choosing to use Android only with #FreeSoftware and without #Google or advertising-related #surveillance. Realising that makes many of its features - and shortcomings - easier to understand. I was the main interviewer in the discussion this week on #FLOSS Weekly with core @fdroidorg developer @eighthave and it was a good show.
https://twit.tv/shows/floss-weekly/episodes/741?autostart=false
@webmink @fdroidorg @eighthave Good episode, my respect for F-Droid grows every-time I find out more about it and each time I use it, a great project.
On a tangential note, is there a process for when an app drops out of the inclusion policy? I think I came across an example yesterday, where a company has made changes to their licensing.
@danb @webmink @fdroidorg By "drops out", do you mean like if an app adds a proprietary lib? In that case, we've handled that many times. We also have handled many cases of changing Anti-Features on existing apps. We generally engage with upstream in these cases, and work through the issue. Many upstreams are thankful because we caught something they didn't know was happening. Occasionally, upstreams are very grumpy about it, and even demand their app is removed from f-droid.org.
@eighthave @webmink @fdroidorg
This particular case is where components/parts of the app may have moved to a non-floss license.
The licensing is not too clear, so I've queried this with the maintainers: https://github.com/standardnotes/forum/discussions/3196
Saw they were on F-Droid, which got me thinking about how apps with license changes are handled.
@danb @webmink @fdroidorg We have some automated scans for license changes, but we always appreciate when people let us know when they see something. We have a harder problem than say Debian since #Android apps are basically all built using dependencies from #MavenCentral, which doesn't enforce that things published there are #FLOSS. https://f-droid.org/2022/07/22/maven-central.html
@eighthave @danb @webmink @fdroidorg again this glosses over the downside that if a dependency needs a patch (security or functional) and there is no expectation that this will happen within your release time frame, you need to hard fork and re-publish to remain f-droid compatible.
And yes I've had to do that to many times in IRL to let this nonsense pass as is.
@eighthave
Debian's upstream's don't enforce that things are FLOSS either; that's a big part of the labour of packaging for Debian, in my experience.
@danb @webmink @fdroidorg