In this months news it is said that developer requested removal of a few apps, but it doesnt say why or link to any discussion
I happen to use a few of those apps
So what did it happen?
Should become available on Izzy soon.
1 Like
There is no preview that I can open…
Thanks for the link, that’s what I was looking for, because I was interested in understanding what had happened. But now that I have read the discussion on the Matrix server in addition to the one on GitLab, I still don’t understand…
Since axet’s apps are FOSS apps, I thought F-Droid could redistribute them without any restriction. Is it not the case?
From what I have read, axet asked for their apps to be withdrawn from F-Droid’s repository because they disagree with the way F-Droid manages its money. Why did it lead to the removal of axet’s apps? Is there some underlying legal basis, that allows a developer to ask that kind of thing? Or was it more some “diplomacy” gesture from F-Droid, to maintain good relations?
In any case, well done to all the negotiators! What composure!
The answer is… 
b)
We have to must, should & do honor if a developer requests us to withdraw publishing their apps. The disagreement was his believing the funds and donations received for F-Droid specifically should be distributed to him and other devs for their apps and work. Clearly there was a misunderstanding, but no misrepresentation from F-Droid. Moreover, he kept gesturing and suggesting we were a bunch of stuff and called us names.
TLDR; we tried and hopefully he will one day return. Izzy is hosting him for now. Izzy has the same logic for funds and donations as F-Droid has (fyi).
2 Likes
(Sorry, I don’t really get the differences between “have to”, “must” and “should”…) Do you mean it’s some kind of moral obligation, like some code of conduct from the FOSS community, expected to be expected from apps’ devs? Or rather… I don’t know… something else… ?
For me, open source community is all about togetherness, open, connected and honest. No reproach on the proprietary blobs.
I did a strike through as “have to” is like a force on someone. In my mind it is defined as “I am being forced to do this or that, even though I may not be willing to or even though I really am willing to”.
“Should do”, is not just moral obligation, but it shows respect for each other and builds greater trust and goodwill. It allows for more willingness, rather than an enforcement. Also, always honor the request.
At F-Droid every one is free to join or leave, and request for archival of their developed software. This in my open mind is one factor which makes us so different from many others.
2 Likes
You’re correct that a FOSS license legally allows them to redistribute the app, even against the developer’s wishes (the license is the thing granting consent, and it’s irrevocable). In this case it’s entirely because of F-Droid’s policy which requires that the developer approve of their app being on it, and allows them to revoke said approval at any point.
I can see the reasoning but I’m not sure I 100% agree with it generally speaking. The notion that, as a creator of a work, one has absolute control over how the work is used, consumed, and distributed, is entirely a belief of the proprietary world. In the FOSS world developers give up some of that absolute control to the community and to their users, and IMO a distro should consider the needs of its users as well as that of upstream developers when making decisions like this.
Look at the Debian vs xscreensaver fiasco where the xscreensaver developer quite rudely demanded that Debian remove the package, despite Debian’s attempts to come to a compromise with him. Removing this package would have obvious consequences for users. In the end Debian stood by its users and kept the package against the wishes of the hostile upstream and I’m 200% on Debian’s side here.
To be clear, I’m not suggesting F-Droid should have done the same. But. I feel like a distibution’s obligations are both to its users and to upstream and both should be considered.
3 Likes
What should happen to apps that projects are closed, as stated on GitHub but they are still on F-droid \ IzzyOnDroid? Should they be reported somehow?
Depends, we kinda Archive them, read: TL;DR: News about 571 apps | F-Droid - Free and Open Source Android App Repository
Specifically I was about RiMusic ATM. Source code unavailable, project closed. App doesn’t work.
OK, took my pipe and reading on… 
“What happens if I had one installed? Nothing happens, they continue to be installed. Whether they continue to work or not in the future is not something that F-Droid has any influence on.”
That’s awesome. Not that I wish to use outdated and buggy app but… the big G company would silently remove such app behind your back not even notifying you. Happened to me few times.
Partially unrelated to your post but there is actually a alive and well fork of RiMusic that works well most of the time.
It has bugs from time to time that can be pretty annoying but the app gets updates pretty fast so I hardly ever notice for long 
1 Like
I know Kreate, mate, tested few times since it appeared in repo 
Musify looks promising to
1 Like
Yes, you’re right, and I never thought that adding an app in a repository adds to the developers’ workload, this is at the beginning of F-Droid’s “Inclusion Policy” doc page:
Notably:
- The original app author has been notified (and does not oppose the inclusion). Distributing an app will bring more support cases for the developers, not only from the actual users but from F-Droid itself
Yes, I think that is the point that “troubled” me. In the recent case of axet’s apps, as in the one about XScreenSaver you mentioned, the devs just demand, like if they reserved the right to decide what the others can or cannot do, and people shall obey. Axet even asked for all existing and future forks of their apps to be withdrawn!
Which they don’t hold any power over…
2 Likes
My understanding is that while OSI/FSF licenses grant downstream parties the right to modify and redistribute, they do not grant downstream parties the right to modify and redistribute under the upstream’s name.
In other words, both F-Droid and Izzy OnDroid distribute under the upstream’s name. Therefore, the upstream retains the right to prevent downstream parties from continuing distribution under its name.
Thus, shifting perspectives: as long as F-Droid and IzzyOnDroid abandon distribution under the upstream’s name and instead modify and distribute under their own or third-party names, I believe this would be entirely reasonable.
@goddaneel When you say “distribute under downstream’s name”, do you mean forks (with or without changes made to the source), so that issue reports and support requests are sent to downstream instead of upstream?
Where the application is a fork of another (even one not included in the F-Droid repository) it must have a new ID, different from the original. Make sure to rename your fork accordingly (including all active translations). Forks which only re-brand an app but do not add value for users might not get accepted.