Unlike other nuclear states, Iran is governed by religious zealots.
In that case their highest religious authority has issued a fatwa against weapons of mass destruction, including nuclear weapons, and since they're religious zealots they would honour that fatwa.
So they're either very religious, and should pose no danger because of that, or they're not very religious, in which case they would pose no danger.
I can't speak for others but here's my take: I think it's not useful to have only two bins: "pro RMS" and "anti RMS". We are capable of more nuance and I'd like to see that reflected in our communication.
I for one am convinced that RMS has a voice that is worth hearing in the wider free software community. I also think that part of his behavior has been pretty constantly alienating to many people (and the lack of willingness to address those issues is part of that force of alienation). I don't want my work as a GNU maintainer and contributor to be tarnished by the negative fallout of RMS comments and behaviors.
The lack of nuance in peoples reverence of RMS is one of the seeds of conflict, in my opinion. If GNU (and the FSF) was seen less as the RMS club and instead was more closely associated with the GNU manifesto and the vision it outlines, and if there was actual project governance (instead of RMS butting in to demand context-free changes, expecting people who do the work to "respect his authoritah!") --- then probably we wouldn't even be at this point.
I "support" RMS in that I don't think it's wise to shut him up. But I also don't support his claim to "lead" the GNU project. He doesn't and hasn't for a while. I also don't support his claim to represent the work of those who contribute to GNU. He does that a lot, speaking in the royal "we" when really he is just stating his own opinion.
So to me this is a false dichotomy and thus not a criterion to reject members to the GNU assembly. All we ask is that members affirm the Social Contract (a pretty low bar that nevertheless seems necessary if we want to cooperate and work towards a shared vision) and to communicate in acknowledgement of the code of conduct --- which lays out what kind of communication style we like to see, and what to expect when people (you or others) risk ruining it for all others.
The GNU Assembly is about treating the "GNU project" like an actual project. It is about collaborative governance and better communication. Any individual's personal nuanced opinion on rms is really not related, though I personally find rms to be an example of how not to run a project.
For once the GNU Assembly is not about rms. That any discussion of GNU keeps circling back to rms is an indictment of the state of GNU. I hope that together we can manage to escape this vortex.
By design.
GNU maintainers already have full control over their projects. The only thing left to delegate to maintainers is the definition and application of the four software freedoms.
> The GNU Assembly is about treating the "GNU project" like an actual project.
With input from people who don't agree or would like clarifications? Because that didn't happen during the last time you tried this[1]. It was just the proposers talking in circles and ignoring input and questions, asserting that things would be for the better but unwilling to engage what "better" would entail.
> The GNU Assembly
is not GNU. And you were asked repeatedly to change the name to avoid confusion the last time you tried this with "gnu.tools", but it was ignored, just like all the input and questions that didn't straight up fit your world view.
> It is about collaborative governance and better communication
That's what got people to listen to you on the gnu-misc mailing list, but it turned out it was about ousting rms (without any solid plan other than "trust us") and shutting down dissenting opinions.
There's a reason you failed the first time, and it doesn't look like the gnu-tools initiative has managed to improve their governance or communication in the meantime.
[1]https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/...