CTI - Making a decision for glibc.

[Alexandre Oliva]

On Feb  8, 2026, Arsen Arsenović <arsen@aarsen.me> wrote:

> Alexandre Oliva <oliva@gnu.org> writes:
>> On Feb  1, 2026, Arsen Arsenović <arsen@aarsen.me> wrote:
>> 
>>> LF seems to be okay with respecting the requirements we do have).
>> 
>> That's not surprising.  AFAICT, the requirements those who have been
>> pushing for this solution do not encompass keeping the infrastructure
>> under our control, but rather handing it to LF's control.  That's the
>> model they understand and operate in.
>> 
>> But that's not the model the Free Software aims for, in which users and
>> communities control their own computing.

> Community is a very nebulous term.  This so-called CTI may fall under
> such a definition.

Yeah, I wrote a long email elaborating that, in response to Zack.  You
may want to refer to that.

For short, the question is not whether there's a little overlap between
the community members, or whether they belong in the same larger
organization, but whether the "organism" the computing pertains to is
*also* the one that controls the computing.

CTI might belong in a broader community, just like Sourceware, and to a
lesser extent even LF.  But this would be like saying it's not SaaSS
when I do your computing for you because we're both associates of the
same club.  It's you who deserve to control your computing; whoever else
you choose to do your computing for you is someone who gains unjust
power over you, and may turn against you and oppress you through that
control.

Now, that doesn't mean that you cannot hire others to help you operate
your computing, as long as it remains under your control.  I've also
elaborated on that in another recent email, IIRC in response to
Siddhesh, on how, in case some misalignment arises, replacing a person
you've hired to operate your computing, while keeping your
infrastructure, is entirely different, autonomy-wise, from outsourcing
your computing to a third party and, in case of misalignment, having to
worry whether you'll even be able to get your data and where to store it
if you were to discontinue the relationship.

ISTM that people have so normalized the loss of control over one's
computing to somebody else's computers that it's become hard to imagine
how it could be different.  But it can, and it should.


>> The requirements they've put forth to the LF are not representative of
>> Free Software needs, they're representative of something else, with at
>> best a limited overlap with the notions of software freedom.

> Sorry, I don't see it.  They offered dedication to the glibc project and
> agreed to run fully Free Software in line with what we expect.

But they haven't committed to make sure it's not going to be SaaSS.

And, indeed, from what I understand, it would be very likely to end up
being SaaSS, because nobody was as much as paying attention to it, or
even aware of the SaaSS issue.

> To clarify: is hiring a sysadmin relinquishing control and ergo makes
> all software ran on hardware managed by them SaaSS?

No, hiring someone to operate your computing on computers under your
control is not SaaSS.

Outsourcing your computing for someone else to run is.

Outsourcing certain kinds of hosting services is not SaaSS, such as
those that aren't your computing (publishing, mediation of
communication), and those that hand control over to you, such as renting
a VPS or a VM to install and run pretty much whatever you wish under
your control.


>>> I, frankly, support offloading (substituting, if you will) work of
>>> maintainers onto (with) Sourceware infrastructure.
>> 
>> I am also favorable to offloading manual labor to automation, provided
>> that the automation is under control of those who rely on it, rather
>> than of third parties..

> That appears to be the case here?  I'm confused.

The key requirement is to keep the automation under our control.
Otherwise it's outsourcing our computing, which makes us nonfree, and
the software nonfree for us, even if the software is free for the
operators.


>> I'd much rather be able to install that variety of compilers on a
>> machine under my control.  That would have the upsides without any of
>> the downsides.

> That's simply incorrect.  Most of the upsides are gone.  I can't very
> easily share a block of code with a particular compiler, flags, and
> output if I only have local compilers.

I'm afraid I can't grasp the intended meaning of "sharing a block of
code with a compiler."

> the people working on CE are also in the GCC community.

That's great.  When we get a copy of the free software they make or
package, and install it on computers under our control, then we can use
it in freedom.

But using the same software while it's run under someone else's control
is SaaSS, and it's not free for us in that deployment.  Those who
control such software hold unjust power over us by controlling the
computing we do there, and that power is unjust even if they choose not
to oppress us with it for any length of time.


>> Now, a server for anyone to submit any program for compilation by a
>> large collection of compilers would be training people to submit private
>> information to unknown third parties, ...

> We know them.  But, that aside, the same argument applies to pastebins.

Pastebins don't do anyone's computing, they're about publishing or
communication, so it's a much simpler issue.  It's not SaaSS.  But the
inducement to entrust others with data that's none of their business,
and the normalization of such reckless malpractices, is still there.


>> ... and could (hopefully; I'm allowed to dream, ain't I?) raise
>> concerns about how much logging the server operator does, ...

> These details are covered on the site:

*nod*, and I have no reason to doubt that particular site does as it
says now, even if no website can possibly offer verifiable transparency
about such matters.  And it shouldn't have to: it's their server, it's
under their control.  *We* (or anyone else), however, would take
reckless risk and expose our/themselves to injustice and oppression by
using it for our/their own computing.

Note, this is not about distrust, though it may come across as such;
it's about keeping our freedom and autonomy, about not submitting
ourselves to control by others.  No matter how much you trust someone
else, they may surprise you, they may turn against you, or the server
they operate may end up under a different controller, and if you've
become dependent on it, you may then feel the oppression and regret not
having kept your freedom.

> You can read the rest on https://godbolt.org/#privacy (requires JS due
> to the nature of the service.  Let's agree skip the JS discussion).

Thanks for the warning.  It's not cool to demand others to run programs
under your control even before they can read one's policies.  As a
result, the policy is inaccessible to me.  But yeah, let's not go down
that tangent.

>> ... how the results are twisted to favor one compiler or another.

> What?  What could be twisted here?

It may take some imagination, but one could run this sort of service and
force or pretend that some compilers work more poorly than they actually
do to demote them, or to promote others.  I'm not accusing anyone,
especially CE, of actually doing that, but that's something one can do
when one has control over computing done for others, and it's one more
reason to do our computing under our control.  Even when others run
services with code under the AGPL, you can never really know what else
they're doing on their end, because you don't control it, they do.

> Sorry, but this is undue paranoia towards people who are part of the
> toolchain community.

Please don't take my far-fetched examples as accusations against nice
people who make great free software for us.

Please understand them as examples of things that software enshittifiers
have done because they could and it served their interests.  They could
only do them because they attained control over others' computing.
See https://www.fsfla.org/~lxoliva/#Unshittify

> you can't reasonably substitute compilers with CE.

I see you come back to this point, which suggests to me that it's a
relevant one for you, though I can't quite see why.  I mean, I
understand that if one could use e.g. distcc to submit compilations to
CE sites, that would likely become a more popular case of SaaSS, but
that it's not practical or even usable for this purpose doesn't make the
computing (the compilation) done for you by a service that's not under
your control any less of your computing.  Being your computing, you
deserve to be in control, and using SaaSS for that is just the opposite.

>> Automating testing is something that doesn't require SaaSS,
>> fortunately.  I can easily envision contributors who (voluntarily and
>> automatically) fetch proposed changes, or batches of changes, test
>> them on their favorite targets, and add notes to the proposals about
>> success, or regressions.

> Running a forge on Sourceware achieves precisely that.

Yup.  And AFAICT it makes us subject to SaaSS just the same, too.

It wouldn't be SaaSS if Sourceware somehow gave us control over the
server/VM that does that computing for us, even if they helped us
operate the server/VM.  They key is who controls the software that runs
there.

If we could change it so that it does what we wish, then we may have
control over it (because there are other freedoms that need to be
present for us to have control); if we have to beg (or ask politely)
someone else to make the change for us, because we're not allowed to
make it ourselves, then we don't have that freedom, we don't have
control, and whatever the license might say, the software is not free
for us in that deployment.

> I don't see how Forgejo running on Sourceware hardware is problematic
> here.  Ditto for Patchwork running on Sourceware hardware (all the
> problems with Patchwork are technical).

> Ergo, I do not understand what the issue is.

> That is computing in our community hands, is it not?

It's overlapping communities, not the same community, not the same
governance, not the same "organism".  We need to ask someone else to
please make changes for us, we are not allowed to make the changes
ourselves, so it's like nonfree software for us.  That's why SaaSS is at
least as bad as nonfree software running on your computer; it's usually
worse because sometimes you don't even have access to the software to be
able to install it elsewhere, and to change it so that it does what you
wish.  It's the same problem, but it seems that the introduction of
somebody else's computers in the picture has clouded the reasoning for a
lot of people who have already understood the harms done to freedom and
autonomy, and the injustice imposed by nonfree software in other cases.

> You're describing a Forgejo runner here, by the way.  It does precisely
> what you say.  It pulls code from the remote server onto, say, an SBC,
> executes the scripts configured in the repository, and sends back
> results.

Great!  So we just have to make sure that, when we use it to do our
computing, it runs under our control; if it's doing someone else's
computing, and they choose to share the results with us, we don't care
who controls that computing (it should be that someone else, but if they
choose to relinquish control, it's their freedom, their choice, not
ours), and we're fine, as far as our freedom is concerned, as long as we
don't allow ourselves to become dependent on those results.

> What SaaSS is there on Sourceware then?

I hoped there wasn't any.  I'm still not sure that there is any, but
conversations from the past couple of days makes me worried that there
is some, that people seem to have made decisions without realizing that
those would be in deviation of software freedom principles.

> Is it not the case that
> Sourceware, as part of our community, running software, cannot be SaaSS?

We're friends, we are members of the same club, but we're not the same
organism/organization.  Each one is entitled to control their own
computing, to their own autonomy, even if they're friends, even if they
help each other.

> Would the same not go for CTI(? is that the name of the actual entity
> running computing or some advisory..?  I didn't follow the discussion,
> so assume I mean the former) if they are part of the libc community?

It is the same.  Outsourcing of one's own computing (AKA SaaSS) is a
problem no matter who else gets to control it (and us, through the
control over the software we rely on).  It may get (much) worse
depending on who gets that power over us.

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