Working together and gaining trust

[Claudio Bantaloukas]

On 11/02/2026 11:24, Alexandre Oliva wrote:
> On Feb 10, 2026, Claudio Bantaloukas <claudio.bantaloukas@arm.com> wrote:
> 
>> 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.
> 
> Your argument is too abstract for me to figure out, but I suspect it
> arises out of misalignment between the understanding of freedom.  In my
> understanding, freedoms don't conflict: one's freedom ends just where
> others' freedoms begin.  Moreover, the ethical imperative to control
> one's own computing is exacty the same regardless of whether you're an
> individual or a collective.
> 

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.

>> 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.
> 
> That may be true.  But the important question is not whether it is
> provided as a service, but who gets to control it.  If that who renders
> the service is operating as your agent, i.e., under your control, then
> you are in control, whether you are an autonomous individual or the
> governance structure of a collective.  But if that who renders the
> service is operating independently, with autonomy to decide whether or
> not to abide by your requests, then the service is under their control,
> not yours, and that is a problem if the service does your computing.
> 
>> 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.
> 
> That's going way too far.  I'm not asking fo rus to have full control
> over giver's hardware.  I'm not even asking for us to be able to do
> absolutely anything we wish on it.  We only need to have control over
> the computing we run on it.  Do you see the difference?
> 

I think I do.

If it helps, allow me to explain the way that a forgejo instance allows 
projects to do computing in a way that maximises their control is the 
following.
- projects create "runner definitions". These are random strings that 
allow associating a runner agent to a project.
- "givers" run the forgejo-runner program on their hardware using the 
random string provided by the project. This program can then start other 
programs based on the mechanism below. "givers" decide how their 
hardware is managed, including what os it runs and how to constrain the 
runner and anything it runs.
- projects create "workflows" in their repository. These define what 
code the project wants to run. An example is the workflow that checks 
new merge requests adhere to the coding style in gcc. Have a look at the 
code 
https://forge.sourceware.org/gcc/gcc-TEST/src/branch/trunk/.forgejo/workflows/sanity-checks.yaml 

- additionally, projects can use specific container images so they can 
define the runtime where their programs run. This has two important 
benefits. One is that the containers are recreated every time, making 
for more repeatable builds. The other is that the project decides what 
third party software to use and depend on regardless of what the "giver" 
installs on their system.
- individual developers can use the runner executable with a local 
repository clone to run the workflows on computers they operate
- projects can decide to block the merging of a merge request if a set 
of these workflows does not complete successfully on a set of runners of 
their choice, creating an opportunity for quality control that is much 
more transparent and controllable by the project compared to things like 
the git hooks projects currently use.

Hopefully this shows that a forgejo instance is inherently not SaaSSy.

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.

When it comes to projects controlling who has access, both of these 
software programs have provisions for delegating user and group management.
In both cases, the people running the shared instance have some control 
over who can register on the system.
One would expect that they use this power to block spammers, bots and 
other abusers and not to block legitimate users for other reasons. But 
that is not a matter of something being SaaSS, it's a matter of policy.

>> All four freedoms are intact.
> 
> Again, if we wish to make a change to the software that runs the service
> we rely on, we can't, because that deployment is under somebody else's
> control.  That means the freedoms are *not* intact.
> 
> Our having to move the service away for us to be able to enjoy the
> freedoms is proof that they're not intact.
> 
> Our moving them away if the service provider doesn't respect our
> freedom, and insists on doing so, is the way to defend our freedom, to
> have it back.
> 
>> 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's *exactly* the problem.  If it's *our* computing, *our* service,
> it's nobody else's business to accept it or not.  We must be free to
> make the changes we wish to our services, regardless of whether anyone
> else is interested in integrating those changes.  If we can't do that,
> our control over our computing is lost, and so is our freedom.
> 
>> I think it's very reasonable that the people maintaining
>> infrastructure should push back against patches that risk making such
>> infrastructure unworkable or unmaintainable.
> 
> I can agree with that.  If they think of it as *their* infrastructure,
> that's what they should do.  But that also signals that it's not *our*
> infrastructure, that it doesn't serve *us* first and foremost.  So we
> shouldn't rely on it to do our computing.  Our computing should be done
> on infrastructure that does what we wish, using software that does what
> we wish, and when our needs or wishes change, we should be allowed to
> independently change the infrastructure and the software so that they do
> what we wish and need, regardless of what others want them to do.
> That's what software freedom is about.
> 
> Shared infrastructure that cannot accommodate this is infrastructure
> that cannot respect our freedom, that's not under our control.
> 

You seem to argue that shared infrastructure with independent authority 
is structurally incompatible with software freedom.
Whereas I'm arguing that shared infrastructure inevitably involves 
negotiated constraints and freedom must coexist with asymmetric 
provision (whether that's time or money).

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.

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

In the case of sourceware:
- projects have some abilities to make non systemic changes themselves
- some projects have people with more access that can do more changes 
but, for some things, they must discuss with the overseers, who 
ultimately decide what to do and what to do first with their finite time.
The list of overseers is here: https://sourceware.org/mission.html
I would guess savannah has a similar structure.

In the case of CTI, there's a technical council that records requests 
from the projects and prioritizes them.
Then there's a board composed of representatives from the companies 
putting in the money that decides where the money goes (and what's done 
first).
This process is documented here: 
https://cti.coretoolchain.dev/gov/index.html

None of these existing systems provide absolute and direct control of 
the infrastructure to the projects. All of these systems have an 
inherent risk that the ultimate decision making bodies go against the 
project's wishes.
In all of these cases, projects have ways to influence the decision 
making bodies.
And given that the services offered can be replicated, projects have the 
ultimate power to walk out.

>> Calling organizations who do something good out of "impure" motives
>> "reptiles" as you do here is not just unhelpful.
> 
> You're projecting on me ideas I reject.  Please don't do that, it's not
> cool.
> 
> The text I quoted explicitly states there's no moral judgment in that
> assessment.  It's just the nature of corporations.  They're hungry for
> profits, and that's what they pursue.  There's nothing wrong in pursuing
> one's own interests, provided that it doesn't bring harm onto others.
> Free Software philosophy is meant to enable everyone to do so.
> 
> There's nothing wrong in working under corporations either.  Sure,
> there's capitalist exploitation there, but it's not ethically or morally
> wrong to be a victim of exploitation, and to do one's job, again, as
> long as that doesn't bring harm onto others.  Contributing to Free
> Software projects doesn't bring harm onto anyone, so we're fine.
> 
>> It has a negative impact on the very people
> 
> It shouldn't.  I'm not talking about those people.  I'm not even making
> a value judgment on the companies they work for.  I should not be held
> responsible for thoughts others project onto me.  You've just made a lot
> of assumptions about where I'm coming from that aren't even close to the
> mark.  *That* has a negative impact.

I'm sure your intention is good. I could have avoided responding to the 
social connotations of the wording, especially since I agree with the 
underlying thinking of the page.


Cheers,
Claudio

All the opinions are mine and do not reflect my employer's