11:07 p.m.
Hi Mark,
On Mon, Apr 05, 2021 at 06:53:42PM -0600, Mark Galassi wrote:
> I was hoping to give the FSF another week to clarify which direction
> they want to go.
I agree that there is no rush, even more than a week is fine. It
might take us longer than that to do the needed structural
soul-searching.
I was just reading "Governing Values-Centered Tech Non-Profits" a talk
given at LibrePlanet this year:
https://lu.is/blog/2021/04/07/values-centered-npos-with-kmaher/
I am still hoping the FSF learns the lessons given in that talk, but
it might have been given too late. One of the things they say is:
So it’s absolutely the case that shutting down FSF, and finding homes
for its most important projects in organizations that do not suffer
from deep governance issues, should be an option the current board and
membership consider.
But lets me somewhat hopeful the talk made an impact and the FSF
learns to refocus. Hopefully they come with a statement soon.
Going through the list:
1. branding as a GNU project: I think that GNU is not trademarked in
the world of software, so we could establish certain criteria
(commitment to s/w freedom; a tech goal of playing well with the
rest of the free s/w world) where we list projects as GNU. Without
any need for a public split, we would just maintain a page of GNU
projects recognized by the GNU assembly, pointing out that these are
projects deeply rooted in software freedom, and with non-toxic
governance.
I believe the FSF might have a registered trademark, but isn't
enforcing it. In the past a friend of mine had a project GNUjsp
https://www.klomp.org/gnujsp and when he asked the FSF they were fine
with it, even though it wasn't related to the GNU project. See also
https://mikegerwitz.com/2012/10/trademarks-in-free-software#fn1
But even so we are acting in good faith representing the GNU project
and having projects explicitly listed as "part of" the GNU Assembly
seems like a good idea.
2. sometimes fiscal sponsorship: this is a tougher one. (a) not all
projects need it, which solves the problem. (b) fiscal sponsorship
loses money, since the 10% or so that the sponsor takes from your
donations is not really enough to offer the full services of
accounting and legal matters. (c) the organizations that offer it
for free s/w projects (debian, gnome foundation, software freedom
conservancy, ...) have a particular angle and I don't think they
take just anyone. Asking the Conservancy leadership for advice
might be a good idea. (Note that although I'm on the Conservancy
board, I am writing this purely as a GNU contributor, which I have
been since 1984.)
3. sometimes actual funding: I think people might just have to
strike out on their own to get funding. I don't know if there is
another central source of GNU funding.
I think that if we break with the FSF then we need to find a fiscal
sponsor which can also act as legal guardian for the project. My
recommendation would also be to ask the Conservancy (note that I am a
financial sponsor of the Conservancy and a big fan of how they provide
Free Software projects with a "legal home").
https://sfconservancy.org/blog/2017/oct/02/mjw/
https://sfconservancy.org/blog/2019/dec/17/mjw2019/
I am not sure what the best setup would be, the GNU Assembly as a kind
of umbrella or each individual GNU project as separate conservancy
member project.
4. a technical infrastructure with...: this one is easy, and we will
come out better for it: not only can you host source code, but, for
example, Fosshost will let you host a jitsi (and maybe big blue
button) instance, as might others. In today's tech world there is
no need for us to maintain that infrastructure, and I recommend that
we not try to. But we could put a bit of continuing work into a
good awareness of the well-behaved free s/w mercurial and git
services, and making sure that one of these options keeps a proper
archive of all GNU project history. mercurial and git make this a
straightforward task.
I actually think this is hard :) In today's tech world you often end
up with non-free solutions, or solutions that are based on Free
Software, but that you don't actually control (the hosted version is
actually proprietary). But yes, there are actually free software
solutions you can "self-host" and various GNU projects are already
independently hosted on e.g. sourceware.
5. maintaining the GNU coding standards: this could become an actual
GNU project (unlike now where it's a one-person monopoly) with a
tech review process based on the good tech review approaches used in
industry (like language standards committees, ...) with something
maybe akin to the C++ 3-year cycle, or whatever they come up with.
We should have at least 4 people on a standards "board".
Yes, this would be really nice the current "standard" is really
outdated.
6. stewardship of the GNU General Public License...: this one seems
impossible, or close. The best we can do is get good advice on how
to best handle the "GPL version X or later" clause, and pass that
good advice to projects so they can decide on their licensing
stance.
If we can get an legal guardian and setup a shared copyright pool then
we could make a liaison with the FSF and appoint them as proxy for the
"or later" version as GPLv3 section 14. The Conservancy has some
interesting arrangements for the Linux kernel and the Debian project
that we could maybe follow:
https://sfconservancy.org/copyleft-compliance/
OK, enough now, but I wanted to get people thinking about an
"effort
almost-neutral" approach to achieving a GNU structure as the FSF+GNU
system might become un-viable.
The only urgent one is making sure someone develop a mirror of all
that's on savannah/ftpd/httpd/mailmain/...
Some of this is already mirrored, I am somewhat unsure about mirror
all of the mailman lists, some of them are really toxic and should
just be shutdown. Also running a big mailman instance is non-trivial
work.
Cheers,
Mark