Please add wg tunnel back to the main repo. Its maintainers are free to go full proprietary if they don’t wish to publish it in fdroid. WG Tunnel isn’t some random app that tells you when to drink water, it’s actually quite useful, and as long as the license allows it and is oss, it should be published in fdroid.
Please don’t require adding a separate repo for each app, esp. not for such a ridiculous reason.
Thank you.
Unfortunately it is not in our hands. The developer requested and we obliged. BTW, not going to say anything more about the reason and all. Let us not get into it again. Danke.
The MIT license puts it into your hands. No one can demand you to pull wg tunnel, not even the copyright holder. Isn’t that the whole point of oss? WG Tunnel’s maintainers are free to release future versions under proprietary license if they do not want to include future versions in fdroid.
Folks are free to submit forks of WGTunnel, yeah. I believe something similar happened when NetGuard was pulled from F-Droid (ex). The various SimpleMobileTools apps were also hard forked wholesale by Fossify (why). A few apps are already forks of their originals, like Intra.
What F-Droid now wouldn’t do is track the original repository for releases anymore, at the request of the lead developer.
Respecting the removal request is F-Droid policy, nothing to do with the license, and the point of it is to avoid even more drama. Making a phony fork of an active open source project just to put it on F-Droid also wouldn’t be ok from that point of view, so a proper fork in this case will need a new developer who’ll willing to work on it indepedently to take it in a different direction, and that might take a while or never happen due to a lack of proper incentive.
Already covered in F-Droid’s inclusion policy.
This is one of those things that’s sufficiently vague as to be entirely arbitrary; what constitutes added value is subjective. Regardless, I feel this is meant to apply to apps already on F-Droid; having multiple apps on F-Droid which differ in name only is unlikely to be helpful, whereas being on F-Droid is itself “value” (IMHO; as I said it’s entirely subjective) if the upstream decided to pull out of F-Droid.
It doesn’t really feel fair if upstream had the right to keep forks out of F-Droid. Forking is a basic right in free software. It’s not (or shouldn’t be) considered inappropriate to fork, even if it is just to change a minor thing.
Right, I disagree too.
the policy is about the name, icon, appid and that stuff, imho.
Let me get this straight.
“Rule for inclusion of forks - forks must provide value - inclusion of forks is value - I didn’t put a single thought in writing this policy”? Is that the correct interpretation?
To me there is nothing vague about the policy as written, it even clearly states that it applies to apps that are not on F-Droid, it’s just basic open source development etiquette. If you are saying you can just rebrand WG Tunnel and include it in F-Droid main repo today, then might as well skip the whole charade, remove that policy and include the oringinal. What’s the point? You think the original author wouldn’t notice or what? They can’t trademark strike you if you don’t make modifications, if that’s what you are afraid of.
Well, my point is what constitutes added value is up to interpretation. My interpretation is that being on F-Droid is valuable, because F-Droid provides value to users - the assurance that the app is free software that can be built from available source. If both the upstream and the fork are on F-Droid, assuming the only difference is the name/branding, the fork is providing no added value compared to the upstream. However, knowing that one is on F-Droid and the other is not, I would choose the one on F-Droid in order to have the freedom assurances provided by F-Droid.
To me, the first part of the policy (forks must be rebranded) is what applies even if the upstream is not on F-Droid, because that is just common courtesy. If your fork is presented as the original then it causes confusion in users. If I rebrand my fork, that is a signal that I am taking responsibility for this version of the app. From the upstream developer’s point of view, being on F-Droid also incurs maintenance burden, which is the burden being taken on by a fork.
If you fork WG Tunnel - clearly mention it’s a fork, publish under different name/appid and most importantly keep issues section open for your repo. You’ve to respect upstream dev that they don’t want issues coming from unofficial fork or unofficial download source.
Even in linux all distros keep separate issues e.g. for fdroidserver package versions - Repology | bug reports at Debian Unstable: Bugs in source package fdroidserver -- Debian Bug report logs where as official issue tracker is Issues · F-Droid / fdroidserver · GitLab
Currently F-Droid don’t keep issues for such android app forks i.e. none of the packages exclusively maintained by F-Droid.
Debian pins a version, applies minor patches, mostly backports from upstream and some configuration, these are not meanigful changes, that’s why you don’t see debian rebranding everything all the time. That does warrant a separate issue tracker for issues specific to their pinned patched version, but issues that are relevant to the upstrream will by all means be forwarded there, assuming said upstream is actively maintained.
If you make meaningful changes you must rebrand. If you do not make meanigful changes you must not rebrand. OP is not a case of the dev not having time or desire to maintain an F-Droid build, they specifically asked F-Droid to pull their app over some drama. If you make a fork that just rebrands and makes no meanigful changes, you’ll be just fenangling the policy to spite them, and being as much of a drama queen as they are.