5:39 p.m.
Dear GNU Assembly,
Like many I’m astonished by the FSF’s decision to reinstate RMS (who
actually still had voting rights, I recently learned). To me, it’s a
betrayal, as if the forced resignation two years ago was a masquerade.
I support the call in the open letter to RMS¹ “for the removal of the
entire Board of the Free Software Foundation.” Until it has cleaned
house, this foundation can no longer pretend to represent the free
software movement.
I also support the call to remove RMS “from all leadership positions,
including the GNU Project”, though I think we’ve gone past that: we
demanded that two years ago², but by creating this assembly, we affirmed
that GNU Project leadership is in our hands, collectively, as
maintainers and contributors to GNU.
Unfortunately, the letter also calls to “[r]efuse to contribute to
projects related to the FSF and RMS”. As Andy explained³, this is
something that’s hard for us to sign, as people who maintain and
contribute to “projects related to the FSF”.
Perhaps one workaround for this bug, so to speak, would be for us to
publish a statement expressing our support, reaffirming where we stand
wrt. “GNU leadership” and what it is we seek to build (as Mark wrote⁴),
and calling hackers to join us in building a landmark of free software
actively working to create a welcoming space for all.
Yes, it would be yet another statement in an already long list. But
we’re in a sweet spot and I think our voice needs to be heard. It’s an
opportunity to move forward on our agenda, too.
Thoughts?
Ludo’.
¹ https://rms-open-letter.github.io/
² https://guix.gnu.org/en/blog/2019/joint-statement-on-the-gnu-project/
³ https://wingolog.org/archives/2021/03/25/here-we-go-again
⁴ https://gnu.wildebeest.org/blog/mjw/2021/03/24/fsf-associate-membership/
11:27 a.m.
Hi Ludo,
On Thu, Mar 25, 2021 at 06:39:18PM +0100, Ludovic Courtès wrote:
Unfortunately, the letter also calls to “[r]efuse to contribute to
projects related to the FSF and RMS”. As Andy explained³, this is
something that’s hard for us to sign, as people who maintain and
contribute to “projects related to the FSF”.
Note that several GNU projects and individual contributors (including
some assembly members) have already signed that open letter. It also
says "We urge those in a position to do so..." which implies a
transitional period for those who cannot yet.
Perhaps one workaround for this bug, so to speak, would be for us to
publish a statement expressing our support, reaffirming where we stand
wrt. “GNU leadership” and what it is we seek to build (as Mark wrote⁴),
and calling hackers to join us in building a landmark of free software
actively working to create a welcoming space for all.
Yes, it would be yet another statement in an already long list. But
we’re in a sweet spot and I think our voice needs to be heard. It’s an
opportunity to move forward on our agenda, too.
Thoughts?
First action item is finishing the rules to allow new GNU Assembly
members. We have some requests to join this list that I cannot act
upon because we haven't exactly established what is required to join.
Then, yes, I think it would be good to write a statement from the
Assembly, that we tried to work with the FSF, and would love to make
things work, but that the current situation makes this unworkable.
Note that this does mean we will have to find a solution for those GNU
projects (like the GNU toolchain and GNU Guix) currently using the FSF
Working together fund to start using a different financial setup. This
will be somewhat painful. But associating with a different foundation
(or start our own) can also be seen as a fresh start.
Cheers,
Mark
> ¹ https://rms-open-letter.github.io/
> ² https://guix.gnu.org/en/blog/2019/joint-statement-on-the-gnu-project/
> ³ https://wingolog.org/archives/2021/03/25/here-we-go-again
> ⁴ https://gnu.wildebeest.org/blog/mjw/2021/03/24/fsf-associate-membership/
2:09 p.m.
Dear Ludovic and Mark and others,
I am glad that there is new activity here, and I'm glad to see you putting forth
proposals for what comes next.
I am willing to help if there are specific tasks to be done in this direction.
My main reason for joining the GNU Assembly is that I don't want to rename the GNU
Scientific Library unless we absolutely have to, and I hope that the GNU name can avoid
permanent tarnish. I don't yet know if it will work, but I hope it will.
5:37 p.m.
Hello,
thanks for reviving this forum!
Am Thu, Mar 25, 2021 at 06:39:18PM +0100 schrieb Ludovic Courtès:
Like many I’m astonished by the FSF’s decision to reinstate RMS (who
actually still had voting rights, I recently learned). To me, it’s a
betrayal, as if the forced resignation two years ago was a masquerade.
When reading the news, and not even on the FSF site, I had trouble
believing it. Richard's resignation in 2019 gave the impression that the
FSF was trying to advance on its leadership problem, as did the invitation
to submit proposals for the future relationship between the FSF and GNU.
As far as I know, there has not been any concrete outcome of this
process for contribution. So Richard reappearing on the board of directors
makes it look as if this has been the ploy from the beginning, sitting out
the scandal and then sneakily moving back to the status before. Not
announcing it publicly, but letting Richard mention it in passing during
his presentation, moreover gives the impression that the FSF is run behind
the scenes by Richard.
So more than astonished, I was actually shocked that the FSF was doing what
appeared to be shovelling its own grave. Before, I feared for GNU and
thought the FSF might be a force moving towards the future with us; now I
am worried for both.
I support the call in the open letter to RMS¹ “for the removal of
the
entire Board of the Free Software Foundation.” Until it has cleaned
house, this foundation can no longer pretend to represent the free
software movement.
I fully agree.
I also support the call to remove RMS “from all leadership
positions,
including the GNU Project”, though I think we’ve gone past that: we
demanded that two years ago², but by creating this assembly, we affirmed
that GNU Project leadership is in our hands, collectively, as
maintainers and contributors to GNU.
Yes, "we are GNU". At the same time:
Am Fri, Mar 26, 2021 at 08:09:36AM -0600 schrieb Mark Galassi:
My main reason for joining the GNU Assembly is that I don't want
to rename the GNU Scientific Library unless we absolutely have to, and I hope that the GNU
name can avoid permanent tarnish. I don't yet know if it will work, but I hope it
will.
it would be nice if we could have most of the current GNU projects on board
and avoid a split.
Am Thu, Mar 25, 2021 at 06:39:18PM +0100 schrieb Ludovic Courtès:
Unfortunately, the letter also calls to “[r]efuse to contribute to
projects related to the FSF and RMS”. As Andy explained³, this is
something that’s hard for us to sign, as people who maintain and
contribute to “projects related to the FSF”.
Indeed, I agree here, and maybe not all is lost yet for the FSF:
https://www.fsf.org/news/preliminary-board-statement-on-fsf-governance
https://www.fsf.org/news/update-on-work-to-improve-governance-at-the-fsf
Perhaps one workaround for this bug, so to speak, would be for us to
publish a statement expressing our support, reaffirming where we stand
wrt. “GNU leadership” and what it is we seek to build (as Mark wrote⁴),
and calling hackers to join us in building a landmark of free software
actively working to create a welcoming space for all.
Fine with me!
Andreas
5:45 p.m.
Am Fri, Mar 26, 2021 at 12:27:29PM +0100 schrieb Mark Wielaard:
Then, yes, I think it would be good to write a statement from the
Assembly, that we tried to work with the FSF, and would love to make
things work, but that the current situation makes this unworkable.
Note that this does mean we will have to find a solution for those GNU
projects (like the GNU toolchain and GNU Guix) currently using the FSF
Working together fund to start using a different financial setup. This
will be somewhat painful. But associating with a different foundation
(or start our own) can also be seen as a fresh start.
I am still hopeful that the FSF will take drastic action to restore its
standing, so that remaining with them will be an option. If not, there is
probably an obvious choice for a different umbrella organisation...
Starting a foundation is, I think, an enormous amount of work, and probably
also a bit redundant given the number of important advocay organisations
for free software around the world.
Andreas
10:47 a.m.
Hello,
as an aside, the following lucid analysis echoes some of my sentiments;
quotes below:
https://wptavern.com/free-software-community-condemns-richard-stallmans-r...
The same author also wrote a friendly article about our initiative in 2019:
https://wptavern.com/gnu-project-maintainers-move-to-oust-richard-stallma...
Am Sat, Mar 27, 2021 at 06:37:08PM +0100 schrieb Andreas Enge:
So Richard reappearing on the board of directors
makes it look as if this has been the ploy from the beginning, sitting out
the scandal and then sneakily moving back to the status before.
Cf. "His return came as a shock to the free software community, though some
suspect he never really left."
So more than astonished, I was actually shocked that the FSF was
doing what
appeared to be shovelling its own grave. Before, I feared for GNU and
thought the FSF might be a force moving towards the future with us; now I
am worried for both.
Cf. "By allowing Stallman to resume his position, the FSF squandered the
opportunity it had to redefine itself following his resignation in 2019.
The organization missed the chance to carve out a new future that would be
free from his damaging influence. If the board doesn’t act in the best
interests of the greater community, by remedying its lack of transparency
and accountability, it may permanently resign the organization to
irrelevance."
Andreas
4:47 p.m.
Hi,
Mark Galassi <mark(a)galassi.org> skribis:
I am glad that there is new activity here, and I'm glad to see
you
putting forth proposals for what comes next.
I am willing to help if there are specific tasks to be done in this
direction.
My main reason for joining the GNU Assembly is that I don't want to
rename the GNU Scientific Library unless we absolutely have to, and I
hope that the GNU name can avoid permanent tarnish. I don't yet know
if it will work, but I hope it will.
Yeah, I guess at this point it’s largely about the name.
When I told one of the signatories about this assembly and our previous
initiatives, they told me they were unaware of them and basically
assumed that Stallman actually is the GNU leader because that’s what he
says. To me, that means we have to be more visible if we are to
convince others in the free software movement that GNU isn’t about RMS.
Likewise, many view FSF and GNU as the same thing. For example, SFC’s
post¹ refers to Guix as a project that “rel[ies] on FSF funding”. That
makes it sound like the FSF is funding Guix when reality is that the FSF
is “merely” a fiscal sponsor.
This is just to say that, to many in the free software world, FSF and
GNU are more or less the same and sinking together.
Ludo’.
¹ https://sfconservancy.org/blog/2021/mar/23/outreachy-fsf/
11:03 p.m.
Hi,
On Sun, 2021-03-28 at 12:47 +0200, Andreas Enge wrote:
as an aside, the following lucid analysis echoes some of my
sentiments;
quotes below:
https://wptavern.com/free-software-community-condemns-richard-stallmans-r...
The same author also wrote a friendly article about our initiative in
2019:
https://wptavern.com/gnu-project-maintainers-move-to-oust-richard-stallma...
The following is also a nice analysis:
https://www.harihareswara.net/sumana/2021/03/26/0
1:42 p.m.
Hi Mark,
On Fri, 2021-03-26 at 08:09 -0600, Mark Galassi wrote:
My main reason for joining the GNU Assembly is that I don't want
to
rename the GNU Scientific Library unless we absolutely have to, and I
hope that the GNU name can avoid permanent tarnish. I don't yet know
if it will work, but I hope it will.
Sorry for the late response, I was kind of waiting what happened and
following what GCC would decide on this issue. You probably saw that
they simply declared themselves an autonomous project and rejected RMS
as being part of the Steering Committee.
https://gcc.gnu.org/pipermail/gcc/2021-March/235245.html
Somewhat similar the GNU Radio project some months ago simply set up an
association under the umbrella of the SETI Institute.
https://github.com/gnuradio/gr-governance/blob/main/aoa.md
So keeping the GNU name is possible without being associated with the
FSF or the GNU project.
There are also other projects that are part of GNU, but don't have the
FSF as fiscal sponsor, like GNUstep under the SPI.
Cheers,
Mark
2:24 p.m.
So keeping the GNU name is possible without being associated with
the
FSF or the GNU project.
Right: the name has never been trademarked -- I heard that in the early days of Cygnus
either John Gilmore or gumby offered to Stallman to trademark the GNU name for the FSF,
but he was not interested.
It's more a matter of association with toxic orgs, so there is a bit of a rush to get
many gnu projects dissociated from the FSF so that at some point pundits will start
writing headlines like "GNU Projects no longer associated with the FSF" and
establish it as an independent name.
Otherwise when we urge someone to work on or use the GNU Scientific Library (or other GNU
projects) they might shy away.
4:17 p.m.
Hi Mark,
Mark Galassi <mark(a)galassi.org> skribis:
It's more a matter of association with toxic orgs, so there is a
bit of a rush to get many gnu projects dissociated from the FSF so that at some point
pundits will start writing headlines like "GNU Projects no longer associated with the
FSF" and establish it as an independent name.
Otherwise when we urge someone to work on or use the GNU Scientific Library (or other GNU
projects) they might shy away.
Indeed, this is the most pressing need, and I think we need to make our
effort more lively and more visible.
There are practical steps we could take, such as mirroring software
pages we care about at gnu.tools, and having a home page that is more
upfront, has direct links to the SC and its list of endorsers, for
instance (currently one has to walk the wiki).
Thoughts?
Ludo’.
10:42 p.m.
Hi Mark, Hi Ludo,
On Mon, Apr 05, 2021 at 06:17:08PM +0200, Ludovic Courtès wrote:
Mark Galassi <mark(a)galassi.org> skribis:
> It's more a matter of association with toxic orgs, so there is a
> bit of a rush to get many gnu projects dissociated from the FSF so
> that at some point pundits will start writing headlines like "GNU
> Projects no longer associated with the FSF" and establish it as an
> independent name.
> Otherwise when we urge someone to work on or use the GNU
> Scientific Library (or other GNU projects) they might shy away.
Indeed, this is the most pressing need, and I think we need to make our
effort more lively and more visible.
There are practical steps we could take, such as mirroring software
pages we care about at gnu.tools, and having a home page that is more
upfront, has direct links to the SC and its list of endorsers, for
instance (currently one has to walk the wiki).
Thoughts?
So have we really arrived at the point where to move Free Software
forward we have to break with the FSF? Has the name GNU become so
toxic because of the myth of the GNU GNUisance that we will have to
make clear we are GNU but without the FSF?
I was hoping to give the FSF another week to clarify which direction
they want to go. As far as I understand the board will meet again this
week and make another statement. Although I admit some of the recent
statements from the FSF haven't been very encouraging.
If we do break off then I hope we will keep using GNU as much as
possible, but start building out resources provided under gnu.tools,
but always with an eye towards one day merging again with those GNU
projects that want to stay behind. As a first step I think we should
find a different fiscal sponsor that can help us setup a new
governance structure and navigate all those foundational issues. I am
not sure we should do this as GNU Assembly, or encourage each
individual project to do this separately.
Cheers,
Mark
12:53 a.m.
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.
For example, and this is without thinking about it in a focused manner, we should decide
on the level at which the GNU assembly should operate.
The entirety of what the GNU project (with the closely associated FSF) is big. It
involves at least the following:
1. branding as a GNU project
2. sometimes fiscal sponsorship
3. sometimes actual funding
4. a technical infrastructure with savannah, ftpd, httpd, mailman, ...
5. maintaining the GNU coding standards (there is some good in a long-lived consistent set
of standards, although some evolution might be needed)
6. stewardship of the GNU General Public License and the other FSF licenses
7. I'm sure there's more
While that was all available and working it was fine for GNU projects to use the services
as needed.
But the world has moved on, and in my opinion it is a much better place. On the
management side we now know that there are good and functional free s/w organizations that
promote good behaviors and a good environment. Gnome foundation is an example, and there
are others.
Looking at the points above, it seems that we do not need to tell projects that we offer
*all* of them. We can point out a path to GNU projects to achieve much of that without
offering it ourselves, while offering a few things ourselves.
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.
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.
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.
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".
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.
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/...
1:29 p.m.
Hi Mark,
Mark Wielaard <mjw(a)gnu.org> skribis:
So have we really arrived at the point where to move Free Software
forward we have to break with the FSF? Has the name GNU become so
toxic because of the myth of the GNU GNUisance that we will have to
make clear we are GNU but without the FSF?
I think so. Fellow free software hackers and activists view it this
way, with very concrete implications: Guix can’t use its money held at
the FSF to pay Outreachy internships, the open letter authors
“inadvertently” called to stop contributing to GNU, and so on.
That’s why I think we must publish a statement to prove that we exist
and that GNU is not a homogeneous group following its one true leader.
I was hoping to give the FSF another week to clarify which direction
they want to go. As far as I understand the board will meet again this
week and make another statement. Although I admit some of the recent
statements from the FSF haven't been very encouraging.
Some of the recent statements, but also everything that’s happened since
2019 when we were hopeful, starting from the
<https://www.fsf.org/news/fsf-and-gnu> operation that, in hindsight,
looks like a trick to silence dissent.
If we do break off then I hope we will keep using GNU as much as
possible, but start building out resources provided under gnu.tools,
but always with an eye towards one day merging again with those GNU
projects that want to stay behind. As a first step I think we should
find a different fiscal sponsor that can help us setup a new
governance structure and navigate all those foundational issues. I am
not sure we should do this as GNU Assembly, or encourage each
individual project to do this separately.
To me, fiscal sponsorship is unrelated to governance.
But I agree it’s also an important issue for those of us involved:
toolchain, Guix, and probably Mailman, Octave, and MediaGoblin:
https://www.fsf.org/working-together/fund
In Guix we’re still discussing what to do, but I think we should discuss
this among all these projects at some point.
Thanks,
Ludo’.
1:55 p.m.
Mark Galassi <mark(a)galassi.org> skribis:
The entirety of what the GNU project (with the closely associated
FSF)
is big. It involves at least the following:
1. branding as a GNU project
2. sometimes fiscal sponsorship
3. sometimes actual funding
4. a technical infrastructure with savannah, ftpd, httpd, mailman, ...
5. maintaining the GNU coding standards (there is some good in a
long-lived consistent set of standards, although some evolution might
be needed)
I would add the Free System Distribution Guidelines (FSDG).
6. stewardship of the GNU General Public License and the other FSF
licenses
7. I'm sure there's more
While that was all available and working it was fine for GNU projects
to use the services as needed.
I think we can build things incrementally as we see fit. All these
things take time and energy to build, let’s just see how far we can get.
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.
To me, that’s the most urgent thing to work on as it will allow us to
recreate ties with other free software projects and organizations.
(Note that GNU actually is trademarked by the FSF (serial number:
85380218; filing date: July 25, 2011; registration date: April 10,
2012). You can find it by searching for “GNU” among live trademarks at
<https://tmsearch.uspto.gov>;. In practice, I think it does not carry
much weight because they haven’t actually defended it, AFAIK.)
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.
These are the two most difficult items in my view. I would definitely
delegate fiscal sponsorship to an established entity.
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.
As far as archiving is concerned, Software Heritage (SWH) is doing the
work:
https://www.softwareheritage.org/
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".
That would be useful.
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.
That one is hard because the GPL is no longer “a GNU thing”. This
responsibility has to be shared with the broader free software
community.
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/...
SWH is archiving ftp.gnu.org already (though the tarball contents rather
than the actual tarballs and signatures) and there are other mirrors
too; Git repos on Savannah are partly archived by SWH, and one can opt
in via the “Save Code Now” API or web interface:
https://archive.softwareheritage.org/save/
Mailing lists have mirrors, but we could very much set up a cron job at
gnu.tools that downloads mbox files periodically from lists.gnu.org.
Thanks,
Ludo’.
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
11:42 p.m.
Hi Ludo,
On Wed, Apr 07, 2021 at 03:29:29PM +0200, Ludovic Courtès wrote:
Mark Wielaard <mjw(a)gnu.org> skribis:
> So have we really arrived at the point where to move Free Software
> forward we have to break with the FSF? Has the name GNU become so
> toxic because of the myth of the GNU GNUisance that we will have to
> make clear we are GNU but without the FSF?
I think so. Fellow free software hackers and activists view it this
way, with very concrete implications: Guix can’t use its money held at
the FSF to pay Outreachy internships, the open letter authors
“inadvertently” called to stop contributing to GNU, and so on.
That’s why I think we must publish a statement to prove that we exist
and that GNU is not a homogeneous group following its one true leader.
I really wish that wasn't true, and I so hope the FSF will do the
right thing, but sigh. I recently saw this list of Free Software
projects statements:
- [April](https://www.april.org/en/richard-stallman-back-board-free-software...
- [Document
Foundation](https://blog.documentfoundation.org/blog/2021/03/25/statement...
-
[EFF](https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-...
- [Fedora
Council](https://fedoramagazine.org/fedora-council-statement-on-richard-s...
- [FSFE](https://fsfe.org/news/2021/news-20210324-01.en.html)
- [KDE](https://ev.kde.org//2021/03/24/on-the-reappointment-of-rms-fsf/)
- [Mixxx](https://mixxx.org/news/2021-03-26-fsf-statement/)
- [OSI](https://opensource.org/OSI_Response)
- [Organization for Ethical
Source](https://ethicalsource.dev/blog/statement-on-richard-stallman/)
- [Outreachy](https://www.outreachy.org/blog/2021-03-23/fsf-participation-ba...
- [Public Laboratory for Open Technology and
Science](https://publiclab.org/notes/jmacha/03-25-2021/public-lab-calls-f...
- [Software Freedom
Conservancy](https://sfconservancy.org/blog/2021/mar/23/outreachy-fsf/)
- [Solidaires
Informatique](https://solidairesinformatique.org/2021/03/30/contre-le-ret...
While the GNU Social Contract says:
The GNU Project collaborates with the broader free software community
The GNU Project works together with other free software projects to
advance its goals, and aims to extend the reach of the project
beyond the GNU System.
This makes that so hard :{
> I was hoping to give the FSF another week to clarify which
direction
> they want to go. As far as I understand the board will meet again this
> week and make another statement. Although I admit some of the recent
> statements from the FSF haven't been very encouraging.
Some of the recent statements, but also everything that’s happened since
2019 when we were hopeful, starting from the
<https://www.fsf.org/news/fsf-and-gnu> operation that, in hindsight,
looks like a trick to silence dissent.
That is cynical, but yes, it wasn't just our letters that were
ignored, I heard from others they also sent in recommendations which
were totally ignored.
> If we do break off then I hope we will keep using GNU as much
as
> possible, but start building out resources provided under gnu.tools,
> but always with an eye towards one day merging again with those GNU
> projects that want to stay behind. As a first step I think we should
> find a different fiscal sponsor that can help us setup a new
> governance structure and navigate all those foundational issues. I am
> not sure we should do this as GNU Assembly, or encourage each
> individual project to do this separately.
To me, fiscal sponsorship is unrelated to governance.
But I agree it’s also an important issue for those of us involved:
toolchain, Guix, and probably Mailman, Octave, and MediaGoblin:
https://www.fsf.org/working-together/fund
In Guix we’re still discussing what to do, but I think we should discuss
this among all these projects at some point.
Having a fiscal sponsor, or a legal entity, is related to governance
to me because without it we cannot hold any resources. Then we are
just a bunch of hackers where individuals have DNS, pay for hosting,
individually collect money to hold a meeting, etc. Now I trust those
individuals and it is a form of governance, but it is very fragile and
you are totally relying on a few people to not go crazy or get drunk
on power :)
Cheers,
Mark
9:40 a.m.
Hello!
Mark Wielaard <mjw(a)gnu.org> skribis:
> To me, fiscal sponsorship is unrelated to governance.
>
> But I agree it’s also an important issue for those of us involved:
> toolchain, Guix, and probably Mailman, Octave, and MediaGoblin:
>
> https://www.fsf.org/working-together/fund
>
> In Guix we’re still discussing what to do, but I think we should discuss
> this among all these projects at some point.
Having a fiscal sponsor, or a legal entity, is related to governance
to me because without it we cannot hold any resources. Then we are
just a bunch of hackers where individuals have DNS, pay for hosting,
individually collect money to hold a meeting, etc. Now I trust those
individuals and it is a form of governance, but it is very fragile and
you are totally relying on a few people to not go crazy or get drunk
on power :)
I’m not sure. Some projects don’t have a “bank account” and thus no
need for a fiscal sponsor (that’s the case of Guile and GSL, for
example).
For others, fiscal matters are not central to the project and dealt with
separately, possibly by a separate team. In Guix, the “spending
committee”, which approves spending from the FSF fund, is a group
separate from co-maintainers (though with a non-empty intersection). By
far most of the “governance activity” in Guix has nothing to do with
funds.
Perhaps Carlos can confirm, but I’m also pretty sure that toolchain
maintainers don’t worry about funds in their day-to-day maintenance and
governance work.
All in all, I would rather let each project take care of its funds and
fiscal sponsorship by itself (but the discussion on how to switch
sponsors should be collective). Ideally there’d be a strong GNU group
with its own fiscal sponsor, which could act on behalf its member
projects. But we’re verrrry far from that. Let’s first save what can
still be saved.
WDYT?
Ludo’.
9:47 p.m.
Hi Ludo,
On Thu, Apr 08, 2021 at 11:40:17AM +0200, Ludovic Courtès wrote:
Mark Wielaard <mjw(a)gnu.org> skribis:
> Having a fiscal sponsor, or a legal entity, is related to governance
> to me because without it we cannot hold any resources. Then we are
> just a bunch of hackers where individuals have DNS, pay for hosting,
> individually collect money to hold a meeting, etc. Now I trust those
> individuals and it is a form of governance, but it is very fragile and
> you are totally relying on a few people to not go crazy or get drunk
> on power :)
I’m not sure. Some projects don’t have a “bank account” and thus no
need for a fiscal sponsor (that’s the case of Guile and GSL, for
example).
For others, fiscal matters are not central to the project and dealt with
separately, possibly by a separate team. In Guix, the “spending
committee”, which approves spending from the FSF fund, is a group
separate from co-maintainers (though with a non-empty intersection). By
far most of the “governance activity” in Guix has nothing to do with
funds.
Perhaps Carlos can confirm, but I’m also pretty sure that toolchain
maintainers don’t worry about funds in their day-to-day maintenance and
governance work.
All in all, I would rather let each project take care of its funds and
fiscal sponsorship by itself (but the discussion on how to switch
sponsors should be collective). Ideally there’d be a strong GNU group
with its own fiscal sponsor, which could act on behalf its member
projects. But we’re verrrry far from that. Let’s first save what can
still be saved.
WDYT?
I think you are a little naive :) Financials are important and I think
you are a bit hung up about the word fiscal, in fiscal sponsor. The
idea is that you do need a legal entity to "exist". A legal guardian
so the individuals aren't taking on all risks personally. A legal
entity who can receive fund, pay expenses, hold assets, etc.
Just look at the list of "services":
https://sfconservancy.org/projects/services/
- Tax-Deductible, Earmarked Donations
- Asset Stewardship
- Contract Negotiation and Execution
- Conference Logistical Support
- Basic Legal Advice and Services
- FLOSS Copyright License Enforcement
- Fundraising Assistance
- Avoid Non-Profit Administrivia
- Leadership Mentoring, Advice and Guidance
- Some Personal Liability Protection
- Officiating Community Elections and Ballot Initiatives
Now you might be right that some of the bigger GNU projects might do
this individually. But I think those should pool together with some of
the smaller ones then, or maybe we should do it as GNU Assembly so
that those smaller ones who think they don't need any resources can
actually get them, because the infrastructure must actually exist and
must be resourced.
Cheers,
Mark
8:04 a.m.
Mark Wielaard <mjw(a)gnu.org> writes:
Hi Ludo,
On Thu, Apr 08, 2021 at 11:40:17AM +0200, Ludovic Courtès wrote:
> Mark Wielaard <mjw(a)gnu.org> skribis:
> > Having a fiscal sponsor, or a legal entity, is related to governance
> > to me because without it we cannot hold any resources. Then we are
> > just a bunch of hackers where individuals have DNS, pay for hosting,
> > individually collect money to hold a meeting, etc. Now I trust those
> > individuals and it is a form of governance, but it is very fragile and
> > you are totally relying on a few people to not go crazy or get drunk
> > on power :)
>
> I’m not sure. Some projects don’t have a “bank account” and thus no
> need for a fiscal sponsor (that’s the case of Guile and GSL, for
> example).
>
> For others, fiscal matters are not central to the project and dealt with
> separately, possibly by a separate team. In Guix, the “spending
> committee”, which approves spending from the FSF fund, is a group
> separate from co-maintainers (though with a non-empty intersection). By
> far most of the “governance activity” in Guix has nothing to do with
> funds.
>
> Perhaps Carlos can confirm, but I’m also pretty sure that toolchain
> maintainers don’t worry about funds in their day-to-day maintenance and
> governance work.
>
> All in all, I would rather let each project take care of its funds and
> fiscal sponsorship by itself (but the discussion on how to switch
> sponsors should be collective). Ideally there’d be a strong GNU group
> with its own fiscal sponsor, which could act on behalf its member
> projects. But we’re verrrry far from that. Let’s first save what can
> still be saved.
>
> WDYT?
I think you are a little naive :) Financials are important and I think
you are a bit hung up about the word fiscal, in fiscal sponsor. The
idea is that you do need a legal entity to "exist". A legal guardian
so the individuals aren't taking on all risks personally. A legal
entity who can receive fund, pay expenses, hold assets, etc.
I don’t think it’s naive to state that there are many GNU packages right
now that don’t *have* funds, reimbursable expenses, or assets. It could
be useful for them to have a legal entity that can manage the legal sido
of this for them eventually, just like it became useful for Guix when we
received USD funds, but I agree that it is not a *requirement* at this
point.
(Guix is also an example for a project where finances/assets are handled
by more than one legal entity.)
Now you might be right that some of the bigger GNU projects might do
this individually. But I think those should pool together with some of
the smaller ones then, or maybe we should do it as GNU Assembly so
that those smaller ones who think they don't need any resources can
actually get them, because the infrastructure must actually exist and
must be resourced.
Yes, though I think taking on this task and aiming for a solution at
this point would not be prudent given the state of the GNU project as a
whole. Is this really a problem we should take on *now*?
--
Ricardo
9:52 p.m.
Hi Ricardo,
On Fri, Apr 09, 2021 at 10:04:13AM +0200, Ricardo Wurmus wrote:
Mark Wielaard <mjw(a)gnu.org> writes:
> On Thu, Apr 08, 2021 at 11:40:17AM +0200, Ludovic Courtès wrote:
>> All in all, I would rather let each project take care of its funds and
>> fiscal sponsorship by itself (but the discussion on how to switch
>> sponsors should be collective). Ideally there’d be a strong GNU group
>> with its own fiscal sponsor, which could act on behalf its member
>> projects. But we’re verrrry far from that. Let’s first save what can
>> still be saved.
>>
>> WDYT?
>
> I think you are a little naive :) Financials are important and I think
> you are a bit hung up about the word fiscal, in fiscal sponsor. The
> idea is that you do need a legal entity to "exist". A legal guardian
> so the individuals aren't taking on all risks personally. A legal
> entity who can receive fund, pay expenses, hold assets, etc.
I don’t think it’s naive to state that there are many GNU packages right
now that don’t *have* funds, reimbursable expenses, or assets. It could
be useful for them to have a legal entity that can manage the legal sido
of this for them eventually, just like it became useful for Guix when we
received USD funds, but I agree that it is not a *requirement* at this
point.
(Guix is also an example for a project where finances/assets are handled
by more than one legal entity.)
GNU Guix did well and it has a backup already. That is good and was
very forward looking. And if Guix wanted to setup a shared copyright
pool they could using the legal entity they setup. But other projects
haven't and are currently relying on the FSF for that and some of
their assets or hosting. I really hope we can keep doing that, but I
don't know we can or if everybody will want to.
> Now you might be right that some of the bigger GNU projects
might do
> this individually. But I think those should pool together with some of
> the smaller ones then, or maybe we should do it as GNU Assembly so
> that those smaller ones who think they don't need any resources can
> actually get them, because the infrastructure must actually exist and
> must be resourced.
Yes, though I think taking on this task and aiming for a solution at
this point would not be prudent given the state of the GNU project as a
whole. Is this really a problem we should take on *now*?
I think it depends on whether you believe the GNU Assembly should take
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.
So at the moment for gnu.tools Carlos deals with DNS and Andy makes
sure the machine that hosts the list and wiki is payed for. And that
is fine, I trust them to deal with that. But what if we want to extend
our resources, setup a pagure machine or get some sourcehut
maintenance contract? I am fine to pay for that personally. But it
would obviously be better if we had an actual legal entity be
responsible for it so that if any of us individuals has something else
to do the organisation still keeps running.
It might not be the most urgent problem to take on. We can wait and
see if the FSF cleans up its board and we as GNU Assembly can start
honest talks about the GNU/FSF relationship as we tried last year. I
haven't given up, but maybe that makes me naive :) But I do think it
is important to start thinking about it now and maybe start some
discussion with some existing organisation like the Conservancy to see
if they can help us out. These things will take months, so it might
make sense to start the converstation early.
Cheers,
Mark
3:44 p.m.
That sounds pretty reasonable.
Frederic
On 10/04/2021 23:52, Mark Wielaard wrote:
> Hi Ricardo,
>
> On Fri, Apr 09, 2021 at 10:04:13AM +0200, Ricardo Wurmus wrote:
>> Mark Wielaard <mjw(a)gnu.org> writes:
>>> On Thu, Apr 08, 2021 at 11:40:17AM +0200, Ludovic Courtès wrote:
>>>> All in all, I would rather let each project take care of its funds and
>>>> fiscal sponsorship by itself (but the discussion on how to switch
>>>> sponsors should be collective). Ideally there’d be a strong GNU group
>>>> with its own fiscal sponsor, which could act on behalf its member
>>>> projects. But we’re verrrry far from that. Let’s first save what can
>>>> still be saved.
>>>>
>>>> WDYT?
>>>
>>> I think you are a little naive :) Financials are important and I think
>>> you are a bit hung up about the word fiscal, in fiscal sponsor. The
>>> idea is that you do need a legal entity to "exist". A legal
guardian
>>> so the individuals aren't taking on all risks personally. A legal
>>> entity who can receive fund, pay expenses, hold assets, etc.
>>
>> I don’t think it’s naive to state that there are many GNU packages right
>> now that don’t *have* funds, reimbursable expenses, or assets. It could
>> be useful for them to have a legal entity that can manage the legal sido
>> of this for them eventually, just like it became useful for Guix when we
>> received USD funds, but I agree that it is not a *requirement* at this
>> point.
>>
>> (Guix is also an example for a project where finances/assets are handled
>> by more than one legal entity.)
>
> GNU Guix did well and it has a backup already. That is good and was
> very forward looking. And if Guix wanted to setup a shared copyright
> pool they could using the legal entity they setup. But other projects
> haven't and are currently relying on the FSF for that and some of
> their assets or hosting. I really hope we can keep doing that, but I
> don't know we can or if everybody will want to.
>
>>> Now you might be right that some of the bigger GNU projects might do
>>> this individually. But I think those should pool together with some of
>>> the smaller ones then, or maybe we should do it as GNU Assembly so
>>> that those smaller ones who think they don't need any resources can
>>> actually get them, because the infrastructure must actually exist and
>>> must be resourced.
>>
>> Yes, though I think taking on this task and aiming for a solution at
>> this point would not be prudent given the state of the GNU project as a
>> whole. Is this really a problem we should take on *now*?
>
> I think it depends on whether you believe the GNU Assembly should take
> 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.
>
> So at the moment for gnu.tools Carlos deals with DNS and Andy makes
> sure the machine that hosts the list and wiki is payed for. And that
> is fine, I trust them to deal with that. But what if we want to extend
> our resources, setup a pagure machine or get some sourcehut
> maintenance contract? I am fine to pay for that personally. But it
> would obviously be better if we had an actual legal entity be
> responsible for it so that if any of us individuals has something else
> to do the organisation still keeps running.
>
> It might not be the most urgent problem to take on. We can wait and
> see if the FSF cleans up its board and we as GNU Assembly can start
> honest talks about the GNU/FSF relationship as we tried last year. I
> haven't given up, but maybe that makes me naive :) But I do think it
> is important to start thinking about it now and maybe start some
> discussion with some existing organisation like the Conservancy to see
> if they can help us out. These things will take months, so it might
> make sense to start the converstation early.
>
> Cheers,
>
> Mark
>
9:58 p.m.
Hi Mark,
> > Now you might be right that some of the bigger GNU projects
might do
> > this individually. But I think those should pool together with some of
> > the smaller ones then, or maybe we should do it as GNU Assembly so
> > that those smaller ones who think they don't need any resources can
> > actually get them, because the infrastructure must actually exist and
> > must be resourced.
>
> Yes, though I think taking on this task and aiming for a solution at
> this point would not be prudent given the state of the GNU project as a
> whole. Is this really a problem we should take on *now*?
I think it depends on whether you believe the GNU Assembly should take
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
this mistake.
So at the moment for gnu.tools Carlos deals with DNS and Andy makes
sure the machine that hosts the list and wiki is payed for. And that
is fine, I trust them to deal with that. But what if we want to extend
our resources, setup a pagure machine or get some sourcehut
maintenance contract? I am fine to pay for that personally. But it
would obviously be better if we had an actual legal entity be
responsible for it so that if any of us individuals has something else
to do the organisation still keeps running.
Yes, this makes sense.
[…] But I do think it is important to start thinking about it now
and
maybe start some discussion with some existing organisation like the
Conservancy to see if they can help us out. These things will take
months, so it might make sense to start the converstation early.
Right.
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?
--
Ricardo
12:41 p.m.
Hi!
Ricardo Wurmus <rekado(a)elephly.net> skribis:
> I think it depends on whether you believe the GNU Assembly should
take
> 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
this mistake.
+1
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
(gnu.org), 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
today.
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
talking about.
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
GnuPG e.V.?).
Thanks,
Ludo’.
10:05 p.m.
Hi Ricardo,
On Sun, Apr 11, 2021 at 11:58:32PM +0200, Ricardo Wurmus wrote:
> […] But I do think it is important to start thinking about it
now and
> maybe start some discussion with some existing organisation like the
> Conservancy to see if they can help us out. These things will take
> months, so it might make sense to start the converstation early.
Right.
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).
Talking to the Conservancy is probably a good thing because they can
also tell us whether we are a good fit and maybe recommend another
organisation. See https://sfconservancy.org/projects/apply/
Many projects apply and subsequently decide not to join a
non-profit, or decide to join a different non-profit entity. Don't
worry about “wasting our time” if your project's developers aren't
completely sure yet if they want to join Conservancy. If membership
in Conservancy is currently a legitimate consideration for your
project, we encourage you to apply. We'd rather that you apply and
turn down an offer for membership than fail to apply and have to
wait until the next application round when you're sure.
If we merely want a legal entity for shared ownership of assets —
would
something simpler (like Guix Europe) suffice?
Maybe yes. If you don't count/want a shared copyright pool as
asset. And the charter matches what we want to do (I assume the one
from Guix Europe does). It probably also depends on whether the entity
has staff or if it is all run by a volunteer board. I cannot say how
much "maintenance" is needed for what we want.
Cheers,
Mark
8:08 a.m.
Hello,
Am Sun, Apr 11, 2021 at 11:58:32PM +0200 schrieb Ricardo Wurmus:
If we merely want a legal entity for shared ownership of assets —
would
something simpler (like Guix Europe) suffice?
as a follow-up to the discussion, setting up a non-profit organisation
in France (and I suppose it will be similar in other European countries)
is very easy: You just need two participants, and bylaws that you can
more or less copy-paste from existing organisations (of course, we invested
a bit more time in writing those of Guix Europe, but there is no difficulty
in principle). Then you declare your organisation to the authorities,
and that is all. Such an organisation can own assets and even employ people
(but that is always tricky since then one needs to know about labour laws,
social insurance, taxes and so on). The important thing is to not make
profits, or at least to not cash them out to the members.
What is difficult is getting a special fiscal status, allowing individuals
to deduce their donations from income tax (details vary by country: in
Germany donations are deduced from the income, so the savings depend on the
personal marginal tax rate; in France about 60% of the donations are
reimbursed by the tax office). For that, one needs a certain importance
(I seem to remember a yearly turn-around of 100000€, for instance, and maybe
a certain number of members), and a special procedure to be recognised as of
public utility. For a small organisation such as Guix Europe, this is not a
realistic option.
So I assume this is meant by the term "fiscal sponsor", and it makes sense
to outsource it to specialised organisations such as Software Freedom
Conservancy. It may even make sense to have several organisations in
separate jurisdictions: For instance as a French tax-payer, I can only
deduce donations to a European non-profit. Maybe the FSFE would be a
suitable partner, if they directly support projects?
Andreas
4:19 p.m.
Hi!
Andreas Enge <andreas(a)enge.fr> skribis:
as a follow-up to the discussion, setting up a non-profit
organisation
in France (and I suppose it will be similar in other European countries)
is very easy: You just need two participants, and bylaws that you can
more or less copy-paste from existing organisations (of course, we invested
a bit more time in writing those of Guix Europe, but there is no difficulty
in principle). Then you declare your organisation to the authorities,
and that is all. Such an organisation can own assets and even employ people
(but that is always tricky since then one needs to know about labour laws,
social insurance, taxes and so on). The important thing is to not make
profits, or at least to not cash them out to the members.
For those following along, here are the Guix Europe bylaws:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/guix-europe/...
and its internal rules (literally translated from French as “interior
reglementary”):
https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/guix-europe/...
It’s nice that it’s short and simple (also nice that it’s not a scanned
random a2ps printout¹ ;-)).
Ludo’.
¹ https://static.fsf.org/nosvn/fsf-amended-bylaws-current.pdf
1107
days inactive
1126
days old
26 comments
6 participants
participants (6)
-
Andreas Enge -
fredomatic -
Ludovic Courtès -
Mark Galassi -
Mark Wielaard -
Ricardo Wurmus