Working together and gaining trust

[Mark Wielaard]

Hi Alex,

On Wed, Feb 11, 2026 at 11:45:12PM -0300, Alexandre Oliva wrote:
> On Feb 10, 2026, Mark Wielaard <mark@klomp.org> wrote:
> 
> >> There's no "versus" here.  It's just that there are boundaries between
> >> individuals, between organisms, between organizations, and those make a
> >> difference.
> 
> > Lets break down those boundaries.
> 
> Are you suggesting to unify Sourceware and CTI and Glibc and binutils
> and GDB and GCC and GNU Toolchain and GNU governance into a single
> decision-making body?  That could address pretty much any risk of SaaSS,
> but it sounds very very hard.
> 
> And as long as we aren't there, we have different governance structures,
> each with its computing needs, each with its autonomy and freedom that
> needs to be respected.

I wouldn't try to include the CTI, but would include the FSF (and
tech-team). Those organisations/projects have a somewhat hierarchical
relationship and strong Free Software charters and governance
structures. Some literally only exist to support the others. They are
kind of a big (sometimes slightly disfunctional) family. They don't
need to become one single decision-making body, they can certainly
keep their autonomy. But their core values and their infrastructure
needs are so similar that it makes sense to share some of it (see
below).

The issue with trying to include CTI is that it has a charter and
governance that is totally opposite to that of the existing
organizations/projects. The charter doesn't even mention Free
Software, GNU or any other goal than raising money by companies for
companies. They do appoint an advisory committee, but even there the
condition is just who pays most. The LF then also says all "outreach,
website and marketing activities" need to be coordinated by them.

It feels like it is just taking over the FSF Working Together Fund
from the FSF without the FSF's permission. I think it is up to the FSF
to first make sure that charter is rewritten to guarantee Software
Freedom for the community.

That doesn't mean OpenSSF/LF cannot meaningfully provide support to
the community. As we discussed there are several very useful ways that
don't impact the communities freedom, autonamy and control.

I know I am a little naive, especially with just trusting other people
doing the right thing, and I know you don't like looking or the
boundary of what is/isn't acceptable. But I hope you can be a little
flexible wrt those organisations/communities who have similar Free
Software goals. But I am certainly not that naive to suggest we just
share control with an entity that isn't willing to put at least a
minimum of guarantees around Free Software goals in their charter.

> > Individuals can cross these
> > boundaries and be part of multiple communities.
> 
> Sure, but how is this relevant to this conversation?

Because I believe that, people, is how you share. e.g. gcc and glibc
are people, some of these same people were delegated by their
communities to setup some shared infrastructure for these projects to
use. The leadership of Sourceware comes from these same
people. Technically they might be separate organisations, but they are
family.

> >> So, you see, if we (glibc) run something on shared rather than
> >> autonomous infrastructure, and we ask you (Sourceware) to make a change
> >> for us, and you refuse on the grounds that, for example, it's shared
> >> infrastructure, that's a symptom that we are not free.
> 
> > But what happens in practice is that the sharing is between people in
> > both the (for example) glibc and binutils communities. And if you
> > really are unable to share we (all of us together) would split the
> > infrastructure in two, so that the communities both have autonomous
> > control.
> 
> I can see how this could work.
> 
> It still makes me uncomfortable to be in a situation in which a service
> provider can say 'no', and then our only recourse is to move our
> infrastructure elsewhere.

Sure, but not all "service providers" are the same. If you see
Sourceware/SFC as a separate service provider/organisation you can
rely on their official agreement to provide you with Free Software
"solutions". We will go out of our way to put things into separate VMs
or run them in containers under your control. If say gcc and glibc
really cannot agree upon sharing a service we will try to make sure
you get separate VMs for them. And I think you can get similar
guarantees from the FSF tech-team for example. The Sourceware PLC and
the FSF tech-team even share "leadership" positions.

> Keep in mind that this matter of providers saying 'no' is at the very
> core of free software philosophy.  Back in the days before minds were
> clouded, people installed and ran programs on personal computers.  If
> those programs were nonfree, their users had to beg the suppliers for
> changes, and even if the suppliers were to tend to the users' every
> request, such programs would still be regarded as nonfree, because the
> users depended on the supplier to make the change.
> 
> We've fought that power imbalance and subjugation with free software.
> 
> Do you see that SaaSS brings that power imbalance and subjugation back?

Yes, of course.
 
> Do you see that minimizing them because you're nice and friendly
> providers is no different from minimizing them for nonfree software
> whose supplier puts on a friendly face?  It's "trust me to have
> power over your computing" all over again.

Yes, I do see I am a little naive at times. But I also believe that in
some cases it isn't just "puts on a friendly face". I believe that we
can put in place some minimal guarantees that show communities and
entities working together are in fact friendly. And that it matters
which people are in a leadership position.

> > But I don't think the solution is to divide people even more by trying
> > to define who is in and who is out of the community or place
> > unnecessary boundaries around them.
> 
> This seems to follow from miscommunication.
> 
> I'm not trying to divide communities, they already exist as independent
> entities, and the need for freedoms follows from that.
> 
> Who belongs in each community is not even relevant to the SaaSS
> argument.  It seems to be a common misconception that keeps coming back.

Sorry for using hash words like dividing communities. I really do mean
that I like our communities to feel more like one with a shared
mission and a shared goal of Software Freedom. I do honestly believe
that if the communities believe they are sharing control over their
(shared) infrastructure they cannot fall into the SaaSS trap. Maybe
that is naive and we need more concrete agreements in place to make
sure they don't. But even then I think we can and have provided such
agreements (at least between the FSF, GNU Toolchain projects and
Sourceware/SFC).

Cheers,

Mark