CTI - Making a decision for glibc.

[Alexandre Oliva]

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.

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.

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

> The infrastructure need be Free, of course

The term freedom-respecting is probably clearer.  It must encompass the
avoidance of control by third parties to be free as in freedom-respecting.

> We only lose by forcing maintainers to perform work that could be done
> automatically.

Agreed.

> Compiler Explorer is an example of such a service.  It is immensely
> useful to us compiler hackers as it allows sharing and comparing with a
> variety of compilers.

I can see it is useful.  I also see how it can be harmful and dangerous.

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.

Or under control of the community that is going to use it.  That
wouldn't remove entirely some of the potential harms and dangers, mainly
related with privacy, but it would be acceptable freedom-wise.

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, would be a constant risk of DoS
and possibly security issues for the server operator, and could
(hopefully; I'm allowed to dream, ain't I?) raise concerns about how
much logging the server operator does, how the submitted programs end up
being used, how the results are twisted to favor one compiler or
another.

> And, it is not practical to replace a compiler with Compiler Explorer,
> so if one of the ess-es in SaaSS is "substitute", then CE cannot qualify
> for it.

> CE is, of course, free software.

It's important to distinguish between the software and the service.

When you install it on a computer under your control, you're installing
software, and then you may possibly be using it in freedom, if the
software is self-contained (as opposed to being a frontend to a remote
service) and freedom-respecting.

When you use it as a service provided by a third party, you have no
control over it, even if the operator installed free software to provide
the service.  So that deployment is not free for you.  It's a service.
Services aren't free or nonfree, they are SaaSS or not.

>> But performing server-side GIT merges, for example, is SaaSS if the
>> server is operated by a third party.

> ... and here we have a perfect example.  Merging patches requires
> tonnes of drudgery, specifically the drudgery of testing (and sometimes
> testing twice and comparing as for GCC for instance unfortunately) on a
> variety of machines.

Hmm, I hear you, but ISTM we miscommunicate.

By "merging patches", I meant:

- taking as inputs (a) a patch (or patchset, but let's make it singular for
  simplicity), (b) the commit it's based on, and (c) the commit at the
  top of the tree

- computing and producing as output (d) a corresponding patch based on
  commit (c).

Although that's deterministic and relatively simple, that is computing
that could be done under one's (the community's) own control, so doing
that under someone else's control qualifies as SaaSS as long as we
understand that it's one's (the comunity's) own computing.  It's pretty
hard for me to find how it couldn't be.

Now, perhaps I should have more accurately phrased it as "rebasing".
Apologies for the confusion.  Terminology over multiple VCSs, Forges and
whatnot isn't exactly consistent, and that's why it's useful for us to
detail what we mean in terms of requirements, features and expectations.
It's far too easy to find out too late that we've had misunderstandings
because different terms mean different things to different parties.

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.  I can also envision Forge support to aggregate such
results, to make it easy for reviewers to decide whether it makes sense
to review a proposed change.

ISTM it would be quite easy to automate rebasing on the community side,
even using a third-party repository host.  You already have your patch
on your end, you probably have a program (git itself?) to upload your
proposed changes to the server, and to fetch the top of the tree at the
server, so there could easily be something running under your control
that rebases your pending changes and uploads them to the repository.
Community contributors could run a very lightweight program on old
single-board computers behind low bandwidth to do such things under
community control.  Others could run programs to flag when unexpected
differences arise in rebases.

These are ways that come to mind to make up for a server's running under
someone else's control.

> If the above is not SaaSS, then no SaaSS was proposed.  If it is, then
> it's not a useful category, as it's in clear conflict with something
> actually useful.

Avoiding SaaSS doesn't rule out useful computing, it rules out
relinquishing control over your computing.

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