Working together and gaining trust

[Claudio Bantaloukas]

On 09/02/2026 01:47, Alexandre Oliva via Overseers wrote:
> On Feb  8, 2026, Mark Wielaard <mark@klomp.org> wrote:
> 
>> Hi,
>> On Sat, Feb 07, 2026 at 11:07:27PM -0300, Alexandre Oliva wrote:
>>> On Feb  7, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:
>>>>> Could we possibly run it on a machine under our control?
>>>
>>>> Who is the "us" you are talking about?
>>>
>>> [...]
>>> Sourceware, a separate entity, seems to be doing our computing under
>>> its control, instead of our doing our computing under our control.
> 
>> Please stop this "us" versus "them".
> 
> There's no "versus" here.  It's just that there are boundaries between
> individuals, between organisms, between organizations, and those make a
> difference.
> 
> For example, if a piece of software is developed within one
> organization, it can be used in freedom within that organization.  But
> if anyone else, any other organization, wishes to use that program in
> freedom, a free software license needs to be granted covering that
> software.  It doesn't matter if the two parties are best friends,
> partner organizations, or members of the same community.  It won't be
> free software without a license from the originator that grants the
> other party the freedoms needed to control the software.
> 
> If the originator doesn't grant those permissions, the other party
> doesn't have control over the software.  Having to ask for further
> permissions, even if you expect to get them, is not equivalent to
> freedom, it is rather evidence of lack of freedom.
> 
> 
> The same boundaries apply to SaaSS.  If anyone else, any other
> organization, offers to do your computing for you, under their control,
> even if you're best friends, closest partners, members of the same
> community, that's SaaSS.  It won't be free software for you because it's
> a premise that, if it's under their control, it's not under yours.  No
> amount of licensing can fix that.
> 
> Unless the other organization, the one that controls the computing, is
> itself under your control, at least WRT your computing, you won't have
> control over the software that does your computing.  Having to ask the
> other party to do what you should be free to do to begin with, and
> having depend on the other party's willingness to do it, is not freedom,
> it is evidence of lack of freedom.
> 
> 
> 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.  It doesn't mean
> your not our friends, our partners, or part of our community, it just
> means that we don't have control over our computing, and that's
> unacceptable for any part of the GNU Project.  I wish it were not
> tolerated by any other part of the free software community either, or by
> anyone, really, because we all deserve software freedom.
> 
> 
>> instead you both are creating division by manufacturing crisis
> 
> I get where that feeling is coming from, but I don't accept that I'm
> manufacturing crisis or creating division.  Opposing SaaSS is a
> foundational principle of the free software movement and of the GNU
> Project.
> 
> If upholding that principle amounted to creating division, then standing
> for the four freedoms necessary for users to control their computing
> would amount to creating division as well.  If it were so, we would have
> been infiltrated by people who oppose software freedom.  I hope that is
> not the case.  I hope people just haven't realized that it's the same
> issue of control over one's computing, of the freedoms necessary to
> attain that control, and that nonfree software and SaaSS are just two
> slightly different ways to deny that control and those freedoms.
> 
> I'm not manufacturing crisis either.  The crisis, namely the threat to
> our software freedom principles with the possibility of moving to a
> freedom-hostile provider, was in place when I joined the discussion.
> Upholding our principles is nothing to take blame for.  Indeed, if this
> has given us an opportunity to highlight the growing problem of SaaSS,
> to make sure we don't fall in such traps, and to step out of any such
> circumstances we might have fallen into, that's bit is not a crisis,
> that's progress towards software freedom.
> 
> Now, if others were to push against our principles, that would be a
> crisis indeed, but it wouldn't be one I could be accused of promoting,
> would it?
> 
> But I don't think that's what we have; I see people who did not
> *realize* that SaaSS is just another way to deny the four freedoms, so
> if we care for software freedom, we should avoid SaaSS just like all the
> other forms of nonfree software.  After all, if doesn't matter if it's
> nonfree because we don't have sources, we don't have a license, we
> signed an NDA, we accepted a restrictive patent license, we see
> restrictive trademarks too enmeshed in the software, or if it's deployed
> Tivoized or as SaaSS or under any other number of circumstances that
> deny us control over the software: it's not free, and that means we
> don't control it, and someone else does, and so, if we use it to do our
> computing, that someone else could control us through our computing.
> 
>> Both of you know these people, they have been part of our community
>> for decades
> 
> I know those people indeed, and I'm happy they're in these positions of
> leadership in the Sourceware community.  That's been good for all the
> larger community of projects served by Sourceware, and that's been good
> for the even larger community of free software users and developers.
> 
> But what does this have to do with any of what I'm saying?
> 
> I'm not denying that we're part of the same communities.  I'm not saying
> we don't belong together, or that we can't trust each other.
> 
> Trust is just not enough for freedom.
> 
> All individuals, all organizations, all communities deserve freedom, at
> all scales.  If some computing pertains to an individual, that's who
> should control it.  If it pertains to an organization, that's who should
> control it.  If it pertains to a specific community, that's who should
> control it.
> 

Dear Alexandre,

Boundaries are made for self determination but also for exploration, 
communication and mixing. How they are used is a (messy!) choice we face 
every day of our lives and I am sad because you seem to choose 
consistenly in favour of the former and at the expense of the latter. I 
hope you experiment with the ideas below.

I think the statement you wrote above (all individuals...) is a 
fundamental vulnerability in your reasoning. You are collapsing 
incompatible meanings of freedom into a single slogan and then applying 
it universally, which makes it incoherent.

Freedoms of individuals are not the same as those of organisations and 
communities (unless you are a U.S. supreme court judge!) and you're 
ignoring mutual exclusion of freedoms.

Similar simplifications are the biggest problem I have with 
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
If you only read the headline and fail to go down the entirety of the 
text, you'll likely reject the whole idea rms is trying to convey.

To be clear, I have no problem with the concept that using SaaSS is 
"bad" and depending on it *worse* where individuals are concerned.

But the logical castle in that document breaks down when you apply it to 
groups of people. In such groups, someone *must* provide a service to 
others.

This is even more the case in this community, where some parts possess 
unique abilities. Some people and/or companies (givers) have hardware 
that they must *choose* to provide access to. Some have 
fiscal/organizational/technical/security requirements that at times 
conflict with the notion that anyone in this community (taker) can do 
whatever they want with the giver's hardware.
And yes, there must be something in it for them or they would not be 
providing the service at all.

I think it's fundamentally unfair to put these people/organisations and 
such needs in the same category as those that make lock-in, privacy and 
freedom removing SaaSS.

Treating these people as "others" or worse as "enemies" rather than 
compensating them, whether in money, in kind, or just by expressing 
gratitude on behalf of the group is a great way to make them stop 
providing that service.

> If an individual is a member of a community, it doesn't follow that the
> community should control that individual's computing, nor that it would
> be ok for other members of the community to control it.
> 
> Lkewise, if that specific community is encompassed by a larger
> community, it doesn't follow that the larger community should control
> the computing of the specific community, or that other members of the
> larger community should control it.
> 
> Sourceware is a welcome member in various communities, but control over
> the communities' computing doesn't belong with Sourceware, any more than
> control over individual members's computing belong with Sourceware.
> That's not a matter of trust, that's a matter of who the computing
> pertains to; what follows from that is who should control it, and who
> shouldn't.
> 
>> You should be able to trust these people to make sure that the
>> community will always be in control of their own computing.
> 
> You may indeed be right about that.  From our private conversation, I've
> learned that the arrangement with containers to run glibc's CI builders
> autonomously, wherein we have control over the configuration of the
> containers and of what runs inside them, has largely alleviated my
> concerns that this arrangement might be SaaSS.  Thank you very much!
> 
> It would also be quite a relief to learn that Sourceware commits to not
> offering SaaSS.  I'm no longer sure that this is the case, but I used to
> expect that, whether out of its own volition, or perhaps from the SFC.
> The ongoing arrangements with CIs and Forges and whatnot make me wary,
> because of the risk of tripping on SaaSS; it would be really great to be
> reassured that Sourceware not only understands this matter, but is also
> adamant about respecting the freedoms of projects, contributors and
> users, by ensuring that Sourceware won't be a party to denying them
> freedom, whether through software that is distributed, run or relied on
> by Sourceware for its hosted projects.  I didn't mention SaaSS
> explicitly here because it's redundant: it follows from "[not] denying
> them freedom [...] through software [...] run [...] for [...] its hosted
> projects".  (I wouldn't mind if Sourceware made such commitments as to
> its own computing too, but that's its own freedom, inasmuchas ours is
> not on the line.)
> 
> 
>> you can control what "compute" it does for the community as a whole
>> (they operate just like other projects, your patches get reviewed
>> first).
> 
> Hmm, that aspect of having to get approval from others to be allowed to
> make changes to our own computing seems doubtful to me.  It suggests our
> autonomy (and thus freedom) is limited here.  Could this possibly be
> improved, by segregating different project's configurations or somesuch?
> 
>> https://forge.sourceware.org/forge/
> 
> Say, if we (glibc) wanted to apply a patch to our forge so that we could
> apply our patches in a more convenient way (recursion is fun :-) could
> we do that autonomously?  Could we do that ourselves?
> 
> I pick applying patches specifically because several other aspects of
> typical forges are not strictly our computing, but applying (and
> rebasing) our patches is.  So we should have control over that.
> 

All of the code in the repositories that Mark provided and to which I 
have contributed are licensed under the GPL with the exception of 
passwords and cryptography keys identifying the servers as such.
You can check this using the reuse tool provided by FSFe.
All software used is under Free and Open Source licenses.
All services provided make it possible to obtain the full source code of 
all repositories. (including the gitolite service being proposed)
All forge repositories and the data therein can be replicated using the 
friendly forge format tool available on https://code.forgejo.org/f3/gof3 
and documented on the https://f3.forgefriends.org/ website.
All data can be accessed programmatically and without loss of information.

This combination gives you total freedom to replicate the service in its 
entirety *on your hardware* provided you have a system that can run 
Debian 13. You "just" need to put in the effort.

All four freedoms are intact.

I'm sure a person of your experience understands that the freedom to 
share your changes so that the whole community can benefit does not 
imply that someone other than you has to accept them.
That is not reduction of freedom. That's negotiation and convincing 
people that an idea is a good one, of the kind we routinely do in 
mailing lists and on merge requests.

I think it's very reasonable that the people maintaining infrastructure 
should push back against patches that risk making such infrastructure 
unworkable or unmaintainable.

For example, I was asked to make the forge use the term "merge request" 
rather than "pull request" because PR conflicts with bugzilla terminology.
I pushed back initially because the way the forge was set up would have 
created a significant maintenance burden.
But in https://forge.sourceware.org/forge/forge/pulls/16 I managed to 
find a way that makes that possible without making updating the forge 
too laborious and error prone. And so the wish can be granted.

I think whatever change proposal is made will have to be weighed in 
against such considerations, including technical feasibility, resource 
constraints, technical debt being introduced and maintenance burden 
generated.
Burnout is real. Life is short. We must take care of our maintainers, 
sysadmins, volunteers and developers. Not just our users.

> 
>> Lets see if we can expand "us".
> 
> I'm all for growing our communities, but this seems to be missing the
> point.  Growing the free software community, or the Sourceware
> community, or the GNU Toolchain community, or the glibc community
> couldn't possibly solve any SaaSS problem.  If some computing pertains
> to glibc, running it under control of any other member of the community
> would still be SaaSS.
> 
>> Zoe is talking to the LF/OpenSSF right now. Lets give her some credit
>> for defining what is acceptable for the FSF.
> 
> Erhm.  This calls for some clarification.  It's great that she's doing
> that.  As for me, I don't speak for the FSF.  I'm wearing my GNU hat
> here (some people conflate them, but GNU is an independent project
> supported by the FSF, it's not the FSF; GNU welcomes FSF's support and
> dedication), but it's not like I am representing GNU leadership either,
> or the GNU advisory committee.
> 
> I am a GNU Speaker, which implies I'm recognized as having significant
> understanding of free software philosophy, and that's what I'm bringing
> here.  I am also assigned some (mainly political, as of many many years
> ago) maintainership responsibilities over GNU libc, which require me to
> uphold and stand for GNU philosophy (Free Software principles, really)
> at least in this context (which doesn't stop me from taking them to
> heart and to life at large).  These are my personal responsibilities
> regardless of any other arrangements or agreements.
> 

I think this puts you in a great position to constructively challenge 
and help improve the text in 
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html 
based on the discussions its application generated here. It seems to me 
it could use some TLC when it comes to clarifying what SaaSS means, or 
doesn't, in the context of communities.

> 
> As for your questions about CTI/LF...  Some of them are confusing to me
> because "us" is unclear and possibly not relevant.
> 
> The bare minimum for me would be a commitment to uphold free software
> principles, particularly the strict avoidance of nonfree software,
> including SaaSS deployments.
> 
> I've made it clear that I consider the LF a hostile organization, but I
> would welcome financial support from it, without strings attached, as I
> would from anyone I can think of.  I'd also welcome hardware (ideally
> RYF-certified, or at least capable of running fully-free GNU/Linux
> distros), connectivity, and virtual machines, provided that we could
> control what runs on them.  I'd also welcome contributions in the form
> of labor, say from sysadmins and the likes, provided that they were
> assigned to abide by our requests.  I'd also welcome code contributions,
> documentation, testing, bug reports...  There are so many ways to
> contribute to glibc!  I'm not picky about accepting contributions.  I am
> very picky, however, about things that would take away our freedoms, or
> that of our users.
> 
> I've long proposed collaboration between LF and Sourceware in the form
> of replicating the hosting services we rely on, so that we wouldn't
> depend on any single organization; so that we could replicate to other
> parties; so that if any party temporarily went down the remaining
> parties could keep the services going, and the other would catch up when
> it came back.
> 
> This would be the most useful, though somewhat pipe-dreamy, way the LF
> (or anyone, really) could contribute to our infrastructure.
> 
> Failing that, it would be great if LF were to help Sourceware, instead
> of trying to replace it, so as to raise all the boats and cross-polinate
> the knowledge on how to do the technically solid stuff you and they do,
> inasmuchas it is freedom-respecting.  Taking things over doesn't help
> glibc or Sourceware, it's disruptive and risky.  Growing the pie instead
> of fighting over it would be actual help; sowing division by offering
> bait circular money and misleading commitments that promise free
> software but don't rule out SaaSS isn't help.
> 
> I wouldn't be comfortable with the LF hosting stuff for projects I'm
> involved in any more than I'd be comfortable in the vicinity of a river
> infested with hungry crocodiles; corporations (including it and those
> that control it) are reptiles, not friends.
> https://webmink.com/essays/reptiles/
> 
> I could live with its hosting things we publish, ideally replicated with
> other parties.  I wouldn't tolerate SaaSS, but that's not because it's
> the LF, it's because SaaSS is unacceptable regardless of the service
> provider.
> 
> I realize the reptilian "instincts" apply to Sourceware's corporate
> support as well.  That's why freedom, autonomy, and
> replication/redundancy are so appealing to me.
> 

I mentioned above how people and organisations contribute here due to 
their own motives. You may not like it but I would not have been able to 
contribute the way I have if my employer did not pay me and this would 
be the same for the vast majority of people here.
And again, whether you like it or not, the people being employed to do 
work on this project represent their companies.
Calling organizations who do something good out of "impure" motives 
"reptiles" as you do here is not just unhelpful. It has a negative 
impact on the very people that do their best to be helpful and 
principled in the face of potentially conflicting priorities.

You seemed like a great person when we met in person at the cauldron and 
I know you can do better than that.

Claudio Bantaloukas

All the opinions expressed here are my own and not my employer's.