I am the developer of Ceno Browser. I am regularly questioned as to why the Ceno Browser on F-Droid has the “Upstream Non-Free” anti-feature. I chose to include this because my implementation of the F-Droid build for Ceno is a fork of @relan’s Fennec, which also includes this anti-feature. Though, Ceno is not a fork of Firefox for Android, rather it is a bespoke browser built from the same libraries as Firefox. So, I would like to understand if I really need this anti-feature or is I could avoid it somehow. Some questions along this line is,
What should I consider my upstream source? Only the Ceno Browser repo? Or also the mozilla libraries which I fork and patch?
If I were to build all the mozilla libraries from scratch with non-free blobs removed for the official (play store) release of Ceno, would that allow me to remove the anti-feature?
Or is it hopeless because I’m using mozilla’s libraries, which include some non-free blobs in their upstream releases, so I can’t honestly remove the anti-feature?
I hope I am asking the right question in the right place. I’m just looking for clarification on this anti-feature and to deflect responsibility for including this anti-feature from myself
Thanks for the quick reply @SkewedZeppelin, it’s good (or maybe sad?) to hear that you struggle with the same question. We’ve added some text to the app description that attempts to explain the situation as I understood it, which seems to be the correct understanding, but people rarely read the whole description
It is true that we do not use the same build for the play store release. This is mostly because of how long and complicated is it to build for f-droid. Instead, I actually publish patched forks of the required libraries (geckoview + android-components) to our sonatype so that our developers can more easily build, test, and iterate. I was considering that it might be worth it to unify the play store and f-droid release (and make the builds reproducible), but one key motivation would have been to get rid of the anti-feature. Without that benefit it’s hard to justify the time/effort it would require to develop and maintain identical, reproducible builds for both app stores.
@linsui, thanks for the tip. I was aware of this field, though this doesn’t show up when viewing the listing in a browser, but only in the app. Hence why I put it an explanation the description, but I should probably put it in both places.