Huh. https://mastodon.social/@datenschutzratgeber/105900221850302612 This is weird - anyone know the backstory?
@brainwane Don't know, but I always wondered if it makes sense to talk about the server side of anything being open-source.
I mean, on my own computer it makes sense to want open-source software because I can verify it and I can modify it as I want.
But on someone else's server, if they say things are "open-source", I can anyway never verify that, and I can't change anything. In the server case "open-source" is just something they say, sounds good, but I don't know if it is true.
@zwol @eliasr @brainwane On the other hand, it does mean that you can go and run your own copy/fork it if you want; there are plenty of people doing that for Mastodon.
What makes a huge difference for social software in particular is whether you can do anything *useful* with your self-hosted copy. For fediverse software, you of course can, as your instance can federate with the rest.
For Signal, which is centralized, not so much.
I was thinking that, regarding Signal, maybe it does not matter so much that there are no commits since April 2020 because we anyway don't know what software they have been running on the server side. We don't know that neither before or after April 2020.
They could run something quite different, that just seems the same from the outside. Or they could just add some secret patches on top of the open-source code.
Or is there some way to verify what the server runs?
@eliasr @brainwane The AGPL tries to help with this—it’s the GPL plus an additional requirement for anyone who has access to the server to be told where they can get the source code the server is actually running (“it’s apache” is not good enough)
but it’s not clear to me that this accomplishes anything useful, because you still don’t have the ability to get the server operators to take your patches
witness all the arguments over features that gargon didn’t want to add to mastodon