Ricardo Wurmus <rekado(a)elephly.net> skribis:
> I think it depends on whether you believe the GNU Assembly should
> up more responsibilties for the community setting up new resources or
> if we can keep relying on the FSF and the existing infrastructure
> various GNU projects are using now.
I see what you mean. I think we should not rely on the FSF for
infrastructure. The unclear entanglement of FSF and GNU is one of the
sources of confusion and intransparency, so it seems prudent to avoid
For instance, back in 2019–2020, one of our requests to the fsf-and-gnu
“process” (if we can call it that way) was to get access to the web site
), which is maintained in part by the FSF. But in hindsight, we
can do better: we can build one that better reflects what we’re building
How do we decide the next steps? Is it premature to talk to the
Conservancy about whether they would be open to supporting a structure
where the GNU Assembly is not only a participating project but also an
umbrella organization for its member projects…? I’m not familiar enough
with SFC to understand if picking them as a legal home could send an
unintended message to onlookers (much like *not* picking the FSF could
be seen as disagreement with any of the things the FSF stands for).
If we merely want a legal entity for shared ownership of assets — would
something simpler (like Guix Europe) suffice?
I think we should go incremental. First, identifying which assets we’re
For funds, if we want to make progress within months, it’s probably
easier to let each package (GCC, MediaGoblin, Octave, Guix, etc.) take
care of its own funds, ideally sharing experience and tips.
For copyright assignment, it’s… tricky.
Then there are things like the machine behind gnu.tools and the domain
name. We could set up a new legal entity, similar to Guix Europe (it
doesn’t have to be in the US, too). Until it’s ready, we could even use
an existing one that’s transparent and with a similar mission, like Guix
Europe, though there are probably others that could work (maybe