Working together and gaining trust

[Alexandre Oliva]

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.

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

> And yes, there must be something in it for them or they would not be
> providing the service at all.

There's no problem whatsoever in hiring people or even companies to be
our agents.  The goal is that they provide the services to us under
*our* control, not *theirs*.

We can compensate for the services in various ways: money, favors,
whatever.  Just not with our freedom!  That would be far too expensive.

> I think it's fundamentally unfair to put these people/organisations
> and such needs in the same category as those that make lock-in,
> privacy and freedom removing SaaSS.

If what they offer is lock in, then they belong in the same category,
and we should be wary of them.

If they allow us to control our computing, then they don't, and we
should welcome their voluntary help, or their compensated services.

> Treating these people as "others" or worse as "enemies" rather than
> compensating them, whether in money, in kind, or just by expressing 
> gratitude on behalf of the group is a great way to make them stop
> providing that service.

Agreed.  If they treat us kindly, respecting our freedom, we should
treat them nicely.  If they attempt to take our freedom away, they're
not being kind, they're being sneaky and treacherous, and we should
treat them accordingly.

> All of the code in the repositories that Mark provided and to which I
> have contributed are licensed under the GPL with the exception of 
> passwords and cryptography keys identifying the servers as such.
> You can check this using the reuse tool provided by FSFe.
> All software used is under Free and Open Source licenses.
> All services provided make it possible to obtain the full source code
> of all repositories. (including the gitolite service being proposed)
> All forge repositories and the data therein can be replicated using
> the friendly forge format tool available on
> https://code.forgejo.org/f3/gof3 and documented on the
> https://f3.forgefriends.org/ website.
> All data can be accessed programmatically and without loss of information.

This is all nice and desirable...

> This combination gives you total freedom to replicate the service in
> its entirety *on your hardware* provided you have a system that can
> run Debian 13. You "just" need to put in the effort.

... but all of this is not enough for the service to be running under
our control in the deployment we use.

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

> And so the wish can be granted.

A SaaSS provider can grant wishes.  The problem is that they can decide
on their own whether or not to grant them.  Because they control the
service provided to us, and we don't.

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

Sourceware is showing it knows how to enable projects to have control
over their computing, and that it cares about keeping it so.  There may
be details, but containerized services controlled by each community
independently, inasmuchas they do each community's computing, are a good
way to deliver services that respect communities' software freedom.

> Burnout is real. Life is short. We must take care of our maintainers,
> sysadmins, volunteers and developers. Not just our users.

Yup.

> I think this puts you in a great position to constructively challenge
> and help improve the text in 
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
> based on the discussions its application generated here. It seems to
> me it could use some TLC when it comes to clarifying what SaaSS means,
> or doesn't, in the context of communities.

TLC?

I don't see that I`m in a position to improve it because what I bring
here into this conversation is what I've learned from it.

I'm also learning there are plenty of misconceptions and
misunderstandings surrounding this, and they presumably arise out of
preconceptions that do not follow from what's there, and often even
conflict wiht it, or with other pieces of free software philosophy.

But unless I succeed in overcoming those misconceptions and
misunderstandings, I don't stand a chance of proposing clarifying
changes to that article, do I?

> I mentioned above how people and organisations contribute here due to
> their own motives. You may not like it but I would not have been able
> to contribute the way I have if my employer did not pay me and this
> would be the same for the vast majority of people here.

GNU welcomes contributions, even from those who don't agree with our
philosophy, as long as the contributions don't conflict with our
philosophy and goals.  It's good when something motivates others to
contribute.  We don't generally care what their motives are, as long as
the contributions are something we can use, rather than something we
should avoid.  That's one of the great things about free software: we
can collaborate without minding other's motivations and values.

> And again, whether you like it or not, the people being employed to do
> work on this project represent their companies.

Yup.  Isn't that great?

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

Fortunately, misunderstandings can be cleared up with good faith and
patience, and incorrect assumptions can be corrected once they're
communicated.  So thank you for the opportunity.

> You seemed like a great person when we met in person at the cauldron

You also made a good first impression on me, FWIW.

> and I know you can do better than that.

I'm not sure I can, not when I'm attributed shit that crosses others'
minds but that doesn't come from me.

There are so many misconceptions and misassumptions that it's really
really hard to communicate without being misunderstood.  Even
understanding that communications are always a partnership, there's been
a pretty consistent (with rare exceptions) amount of leaping to negative
conclusions, instead of asking clarifying questions.  Clearly emotions
and frustrations are running high, and expectations are not being met.

But is it my fault that people have got ~~wrong~~ misaligned and
incomplete ideas about software freedom, to the point that they claim
and believe to be operating in line with free software principles, while
pursuing and pushing for the diametrical opposite?

Is it my fault that when I use long-established terms in free software
literature, they get different and surprising meanings and draw even
more surprising conclusions from that, while they *claim* to have a
grasp and being in line with it?

Is it my fault that people get to wrong conclusions about free software
out of following superficial ideas that have been published with the
explicit goal of removing deeper core principles of free software from
the discourse and from consideration?

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