Working together and gaining trust

[Claudio Bantaloukas]

On 12/02/2026 03:43, Alexandre Oliva wrote:
> On Feb 11, 2026, Claudio Bantaloukas<claudio.bantaloukas@arm.com> wrote:
> 
>> Indeed, it seems to me the friction comes from two different thought
>> frameworks being applied. You start your argument from a
>> non-conflicting freedom definition whereas my definition sees freedom
>> as inevitably conflicting and thus requiring one or more between eye
>> contact, discussion, negotiation, tradeoffs, policy, law, war, hugs,
>> listening to be made to resolve the conflict.
> *nod*
> 
> Even my proposed solution to what may be perceived as a conflict of
> freedoms is conflictless: I'm not saying that all service suppliers must
> abide by our values and principles and follow our alignments.  I'm just
> saying that we shouldn't rely on suppliers that don't respect our
> freedom.  They can keep on offering the services to those foolish enough
> to accept them under the subjugation framework they wish to impose,
> while we escape the subjugation by getting service elsewhere, or doing
> it ourselves.
> 
>> If it helps, allow me to explain the way that a forgejo instance
> Thanks for the data points, they're useful.
> 
> You surely understand them far more deeply than I do.
> 
> Given your understanding of SaaSS, would you say that a community
> relying on a forĝejo instance ran by a third-party, with runner
> definitions executed by, erhm, fourth-party givers, is in control of its
> own computing, or that there's any aspect of SaaSS in there?  Consider
> the key computing elements done by the forĝejo instance and by
> forĝejo-runners, whose computing those are, and who controls them.

I'll try to frame this using what I believe is the mental model of the 
fsf page, with an absolute definition of freedom and the necessity to 
find boundaries so that freedoms are intact.

I think that it's a similar situation to the "If you rent a server (real 
or virtual), whose software load you have control over" situation.

In a VM, the hypervisor is shared. In a container based environment, the 
kernel is shared. But the software running on top is controlled by the 
project.

If we accept that:
- control over the hypervisor or kernel and checking that the computing 
done is actually the project's and not of malicious third parties
are part of the freedom of the hardware "givers"
- they do not impose restrictions on the software used on top of these 
interfaces by the project, as is effectively the case thanks to 
containers and project defined workflows
then freedom is maintained for all entities involved.

>> Hopefully this shows that a forgejo instance is inherently not SaaSSy.
> These are no doubt interesting design elements.
> 
> I'm still worried about the computing that goes into patch
> merging/rebasing.  (Incidentally, on a related concern that has nothing
> whatsoever to do with SaaSS, I don't see how requiring originator-signed
> commits could even possibly work with server-side rebases)

I believe you're talking about commit hooks that impede commits based on 
quality controls etc.
In the native way of using forgejo, each project defines workflows that 
must pass for a change. And sets rules that disallow the merging of a 
change until the specific workflows pass.
This is optional, the project can also simply create a small list of 
users that can do pushes on "protected" branches.
Control is with the project, it's just that the way it's applied is 
unfamiliar to some people. It's actually better and more transparent 
than the current state.

The documentation of forgejo's signing feature is here
https://forgejo.org/docs/latest/admin/advanced/signing/
In this scenario, the service provider does its own computing to decide 
whether to sign a commit based on specific criteria. This creates an 
opportunity for computation that involves multiple parties.

When it comes to originator-signed commits, server side rebases lose the 
original signature. But the server can have a list of keys it considers 
valid and sign the rebased version itself provided the original change 
was signed by one of those keys and there are no differences in the 
range-diff between the original change and the rebased version. (I don't 
know if this is actually possible or not with forgejo, just speculation 
on how it might work)

(On that note, the criteria for the server signing seem to be 
per-instance rather than per-repo or per-project, which might not be 
workable for us. I'll have to look into that.)

When it comes to rebasing or having merges performed using a merge queue 
mechanism, I understand your worry. But I think these should be 
classified as "not any single party's computing".

Specifically, the rebasing mechanism in the forges is not there merely 
to perform git rebase on behalf of the developer.
It's there to avoid having to do a full check of a change once the 
rebase succeeds. It's there for the project (that doesn't want to run 
the full testsuite every time a rebase occurs), the reviewer (who 
doesn't want to have to do a review again), the developer (who doesn't 
want to wait for the reviewer).
Merge queue mechanisms are of the same nature to me, this time involving 
multiple developers.

>> When it comes to the service that Carlos is proposing that openssf
>> provide, things are even clearer. gitolite is so barebones it squarely
>> fits the "Use of simple software repositories is not SaaSS" rule.
> I don't know a lot about gitolite, but if all it does is publish the
> code and selectively accept pushes from authorized git users, it's not
> even doing anyone's computing.  Server-side commit checkers, however,
> could be SaaSS depending on who controls them.
> 
Funny that, I'd classify authorization as computing myself.

>> When it comes to projects controlling who has access, both of these
>> software programs have provisions for delegating user and group
>> management.
> And then we get to another important point: who controls the user and
> group management infrastructure.  Is there any relevant computing there
> to worry about?  Are there other issues (not necessarily relevant for
> SaaSS) that would make it a poor idea to delegate such key piece of
> self-control infrastructure to a third party?

In both cases the service provider controls the infrastructure, notably 
for blocking abuse. The projects then have authority over who can do 
things on the project.
The only reason not to delegate such control is if you think the third 
party won't do the job fairly and neutrally on behalf of the project.

> 
>> You seem to argue that shared infrastructure with independent
>> authority is structurally incompatible with software freedom.
> It depends a lot on what the infrastructure does.  If it's publishing or
> mediation of communication, those are not much of a point of concern.
> (and that's what Savannah does AFAIK, so there aren't any SaaSS concerns
> there).

This is a point where I have issues with the reasoning.
That's because web servers are programs. They transform data on its way 
to the intended recipient and thus are computing.
And they can make very important choices on the way:
- who gets access, who gets to push
- whether the format is accessible or not by (categories)
- whether to allow discourse and under what terms
It may seem like semantics but it shows that an implicit choice was made 
to consider such systems as being neutral in their workings.
But in reality, they can be anything but neutral and often are not. See 
how most self hosted and community hosted websites block AI scrapers to 
avoid being overwhelmed.
Or how someone can do their computing for the project but their 
contributions are blocked because they happen to connect from one of the 
many blocked networds that overwhelm our servers or from a country that 
blocks outbound access.
You rightly hint that authorization is potentially SaaSS earlier. But 
similar mechanisms are built into all web servers.


>> Does your argument mean that any project hosted in savannah.nongnu.org
>> can ask for a separate instance of savannah that the project can
>> change independently? I think that's not the case.
> It is't, and that's fine because the services it offers aren't SaaSS
> because they aren't the client projects' computing: publishing and
> mediation of communication are not any single party's computing.  The
> consequence is that the server-side computing that Savannah does is the
> service provider's own computing, and control over that belongs with the
> service provider.
> 
> A lot of what a Forge is expected to do falls in this category.
>

I can't find a coherent argument as to why publishing and mediation of 
communication is "no single party's computing". I can concede that it's 
computing happening on the boundary of freedoms, because it requires 
that two or more parties do asymmetric computations.

I'm happy to consider it a pragmatic exception, in the face of a 
communication provider that's "neutral" for the entities involved.
But at that point we should entertain the argument that we must be free 
to choose what pragmatic exceptions to allow.
Like saying that a system applying git rebase neutrally for all that ask 
and reporting the result is ok because it involves three parties: 
developer, infrastructure provider and project.
Or a system that applies a specific logic on whether to authorize a user 
because it involves the same three parties.

> But a lot of recent-ish (proprietary/locking-in) Forges have taken over
> (or rather offered suckers the opportunity to be SaaSSed) various other
> kinds of computing that belongs with the users and with the projects, to
> the point that today even Forges that aim to be freedom-respecting offer
> such features, so those can only be used in freedom by projects that
> self-host their Forges.
> 
> But you also show that there has been effort in free software Forges to
> redesign some such proprietary traps into something that keeps at least
> some significant amount of control in the hands of the projects where
> control belongs.  Self-hosting of computing services remains the golden
> standard, but this may open up valuable alternatives, depending on deep
> understanding and careful analysis.  Not the sort of analysis that could
> be done in a battlefield, for sure.
> 
I'm glad we're debating in good spirit :)

>>>> 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.
>>> And then, who decides?  If we can weight on our own terms and have
>>> our
>>> decision implemented, we have control.  If we make our decision and then
>>> have to beg someone else to hopefully do it for us, fearing they might
>>> refuse, we don't have control.  And if it's our computing we're talking
>>> about, that's a software freedom problem.
>> The question is not just who, but how, how long the decision making
>> process takes, whether it is finite, whether a decision actually
>> results in the desired action and how much it helps the projects.
> Another important consideration, that I realized after posting my
> earlier message to you, is what recourse the project has if a service
> provider refuses.
> 
> If we speak of project's self-hosted infrastructure, the problem becomes
> a matter of find other helpers to make the change.
> 
> If we speak of infrastructure hosted by the service provider, a "no can
> do" by the provider can be a*lot* more disruptive to the project.

Yours is a valid concern on a concrete risk.
But it must be weighed agains other risks, the most important being the 
inability to find these helpers for a self-hosted infrastructure.

That risk is the reason why shared infrastructure projects like 
sourceware, savannah, gitlab and github are such successes. Some people 
fall prey to easy solutions but not all of them do. Some merely make 
value judgements based on different criteria from yours or mine.

> 
>> In the case of sourceware:
> [...]
>> I would guess savannah has a similar structure.
> For quite some time, AFAIK Sourceware and Savannah shared the property
> of not doing computing for the hosted projects, only publishing and
> mediation of communication.  Concerns about SaaSS were out of scope
> then, because there wasn't any project's computing involved.
> 
> At some point Sourceware started offering services that involved
> project's computing.  AFAICT at least some Sourceware operators have an
> understanding of the SaaSS issues and strive to avoid entrapping hosted
> projects, but at least one of the hosted projects seems to have been
> dangerously unaware and/or uncaring about SaaSS avoidance.

I think there's lots of opportunity for nuance here:
- People who historically agreed with the four freedoms may disagree 
with subsequent philosophical additions like SaaSS.
- People can disagree over details of what is and isn't SaaSS. We are 
debating such things right now.
- People who are aware of the notion of SaaSS can disagree over what the 
risk is and what to do about it. Some don't care, some may make a case 
by case evaluation of the risks, some may avoid it entirely, some may 
use such services but taking steps to avoid lock-in, some can have 
contractual agreements in place that shield them from the worst aspects 
of SaaSS.
- Most importantly, people mey be using a different thought framework 
where control is not a binary property but a multidimensional vector and 
freedom is not an immutable absolute but a dance around the edges of 
this vector.

I doubt that Carlos, David and Joseph are unaware or uncaring of FSF's 
position on this matter. But it is well within their and the glibc's 
project's rights to try to move things in ways that don't wholly abide 
by the FSF's position, especially when that position was formed after 
the project.

>> In the case of CTI
> Your description matches my understanding, and it makes matters even
> more complicated because there are two layers of indirection that could
> each say "no can do" to our project's community governance on matters in
> which we should have our autonomous control.
> 

Andrew P. has already debated that it's important for the project to 
have a direct channel of communication with the people in control of the 
infrastructure so that they can intervene if something is amiss.

I personally doubt that corporate sponsors are going to actively stop 
community based proposals. The whole point of that setup is to make 
funding available for the projects that the sponsors depend on. But that 
is for the CTI to clarify and of course you're free to think otherwise 
no matter what!

So, all in all I don't think it's that bad. In the spectrum of No 
agency/Indirect agency/Direct agency, we're still in the middle but the 
levers change.

>> None of these existing systems provide absolute and direct control of
>> the infrastructure to the projects.
> That would be too demanding.  Avoiding SaaSS is about having control
> over your computing, not over everything around it, and not necessarily
> direct (which doesn't even make sense to me when it comes to
> collectives, whose actions are of necessity always carried out by
> appointed agents)
> 
>> And given that the services offered can be replicated, projects have
>> the ultimate power to walk out.
> That's valuable, but it's no substitute to being able to make changes
> autonomously, without having to walk away from our own infrastructure.

Indeed, but the glibc project doesn't have infrastructure where it can 
make autonomous changes today. Or this thread would not have been a thing.

On that note, I doubt that we'll ever be able to fully resolve positions 
that come from two different mental frameworks. But I think we'll agree 
that they don't come from lack of thinking about the issues at hand or 
lack of care.

To bring this to a more technical argument, I would love it if you could 
volunteer some of your time. The deployment of the sourceware forge 
could use some code review, in particular this change where I move the 
forgejo process to a container based deployment is open for debate:
https://forge.sourceware.org/forge/forge/pulls/16

Cheers,
Claudio

The opinions in this email are mine and do not reflect my employer's