Working together and gaining trust

[Alexandre Oliva]

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.

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.


> 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.


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.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/