CTI - Making a decision for glibc.

CTI - Making a decision for glibc.

[Carlos O'Donell]

tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
core services to infrastructure hosted by the Core Toolchain
Infrastructure (CTI) project. As maintainers for the project we do this
to meet the present and future needs of glibc and the GNU Toolchain. We
want secure, robust, and sustainable infrastructure, balanced against
the needs of developers and the community to collaborate and innovate,
with reliable funding to support the infrastructure in the long term.

In 2019 leadership from the GNU Toolchain started down a path that led
to the Core Toolchain Infrastructure project. The project aims to move
toolchain infrastructure issues forward; to provide a sustainable path
forward for secure and state of the art infrastructure.

Post-pandemic, since 2022 the GNU Toolchain has continued to move
forward the state of the current infrastructure by engaging the
developers, the projects, and a wider set of sponsors that can
support a sustainable path forward for the toolchain.

Key achievements:

  2022 - Started using infrastructure provided by CTI like BigBlueButton
         for meetings for the GNU Toolchain e.g. Weekly glibc patch
         queue review and Monthly Office hours in two timezones.

  2023 - Service enumeration for GNU Toolchain projects (gcc, glibc,
         binutils, gdb).

  2024 - Completed pricing and service contract negotiation for migration
         with LF IT.

  2025 - Completed GNU Toolchain and glibc documents to define secure
         development requirements and the infrastructure needs.

These steps were a necessary evolution and resulted in several critical
milestones, e.g., service enumeration, secure development documents;
which collectively paved the way for a sustainable path forward.

While it was clear to the GNU Toolchain leadership that requirements
were coming to improve the toolchain cyber-security posture, these
requirements were not clear to all project developers. As part of
receiving this feedback we have worked to document and define a secure
development policy for glibc and at a higher level the GNU Toolchain.
While Sourceware has started making some critical technical changes, the
GNU Toolchain still faces serious, systemic concerns about securing a
global, highly available service and building a sustainable, diverse
sponsorship model. At the same time we are freeing up the GNU Toolchain
developers and volunteers to focus on next-generation work, such as
Sourceware’s post-commit CI and Forge-based workflows.

The decision to leverage CTI and LF IT is the direct result of seeking a
comprehensive, long-term solution to these exact challenges, expanding
our sponsorship base and leveraging existing sponsors like the OpenSSF.
The CTI TAC’s proposal to use Linux Foundation IT is rooted in the fact
that they are an existing team in the industry that implements very
similar functionality for the Linux kernel. The proposal directly
benefits glibc developers. By partnering with a team that develops and
understands FOSS tooling (b4, grokmirror and patatt) and large-scale
kernel infrastructure. This partnership ensures our core infrastructure
is secure and scalable.

This sustainable path forward for glibc includes:

  * A global robust and secure mirrored git repository for public clones
    that supports robust CI/CD workflows for developers and downstream
    distributions.

  * A global robust and scalable email system leveraging existing
    production deployments and reputation i.e. subspace.kernel.org.

  * A continuous process of review for project requirements, FOSS usage,
    security policy, and cost.

  * A sustainable funding model for the infrastructure including a
    diverse collection of sponsors to support various infrastructure
    requirements now and in the future.

While consensus for the move among GNU Maintainers for glibc is not
unanimous, most of the maintainers endorse the move, and key developers
have expressed their support in the upstream discussions. Additionally
CTI has received a lot of feedback over the last 3 years as the project
worked on infrastructure, and we include some of that feedback here and
in our CTI FAQ [1] with comments.

Some members of the community have expressed disappointment that funding
would go to the Linux Foundation. Some members of the community have
expressed concern that a board structure would allow corporate
influence. Neither of these concerns are new and exist today with Red
Hat and IBM, both being for-profit corporate entities. The GNU Toolchain
leadership has a 30+ year history of successfully navigating the
dynamics of working with sponsors and providing FOSS solutions,
including meeting the GNU Ethical Repository hosting criteria.

We invite all members of the glibc and GNU Toolchain community to join
us in this important transition. Your insights, contributions, and
feedback are essential to making CTI infrastructure a success that
benefits everyone. Let's work together to build a more secure and
sustainable future — reach out on libc-alpha@sourceware.org, participate
in the weekly office hours, or propose ways to get involved. Let's
collaborate to build a more resilient and sustainable infrastructure
foundation for the GNU Toolchain.

Action plan:

  * Weekly office hours for CTI to provide an open space for discussion
    of infrastructure improvements

  * Work with LF IT to update the CY24 statement of work and discuss with
    the glibc developers

  * Work towards migrating glibc git and mailing lists as first priority
    since these match our security priorities.

Cheers,
Carlos O’Donell
GNU Maintainer for glibc
Core Toolchain Infrastructure Project TAC member
[1] https://cti.coretoolchain.dev/faq/index.html

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

[-- Attachment #1: Type: text/plain, Size: 6621 bytes --]

Please dont.
The concern is more than foundations.
Sourceware has stepped up in ways that linux foundation it could not and
would not do without a new contract.

An example has been integration with forge.
Other examples is how handling of AI scrapping. Iirc there was nothing in
the contract with LF It for handling of that and still has not been added.

Without a fluid contract, LF IT is bad for security and stability and the
future of glibc.

On Tue, Jan 27, 2026, 8:16 AM Carlos O'Donell <carlos@redhat.com> wrote:

> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.
>
> In 2019 leadership from the GNU Toolchain started down a path that led
> to the Core Toolchain Infrastructure project. The project aims to move
> toolchain infrastructure issues forward; to provide a sustainable path
> forward for secure and state of the art infrastructure.
>
> Post-pandemic, since 2022 the GNU Toolchain has continued to move
> forward the state of the current infrastructure by engaging the
> developers, the projects, and a wider set of sponsors that can
> support a sustainable path forward for the toolchain.
>
> Key achievements:
>
>   2022 - Started using infrastructure provided by CTI like BigBlueButton
>          for meetings for the GNU Toolchain e.g. Weekly glibc patch
>          queue review and Monthly Office hours in two timezones.
>
>   2023 - Service enumeration for GNU Toolchain projects (gcc, glibc,
>          binutils, gdb).
>
>   2024 - Completed pricing and service contract negotiation for migration
>          with LF IT.
>
>   2025 - Completed GNU Toolchain and glibc documents to define secure
>          development requirements and the infrastructure needs.
>
> These steps were a necessary evolution and resulted in several critical
> milestones, e.g., service enumeration, secure development documents;
> which collectively paved the way for a sustainable path forward.
>
> While it was clear to the GNU Toolchain leadership that requirements
> were coming to improve the toolchain cyber-security posture, these
> requirements were not clear to all project developers. As part of
> receiving this feedback we have worked to document and define a secure
> development policy for glibc and at a higher level the GNU Toolchain.
> While Sourceware has started making some critical technical changes, the
> GNU Toolchain still faces serious, systemic concerns about securing a
> global, highly available service and building a sustainable, diverse
> sponsorship model. At the same time we are freeing up the GNU Toolchain
> developers and volunteers to focus on next-generation work, such as
> Sourceware’s post-commit CI and Forge-based workflows.
>
> The decision to leverage CTI and LF IT is the direct result of seeking a
> comprehensive, long-term solution to these exact challenges, expanding
> our sponsorship base and leveraging existing sponsors like the OpenSSF.
> The CTI TAC’s proposal to use Linux Foundation IT is rooted in the fact
> that they are an existing team in the industry that implements very
> similar functionality for the Linux kernel. The proposal directly
> benefits glibc developers. By partnering with a team that develops and
> understands FOSS tooling (b4, grokmirror and patatt) and large-scale
> kernel infrastructure. This partnership ensures our core infrastructure
> is secure and scalable.
>
> This sustainable path forward for glibc includes:
>
>   * A global robust and secure mirrored git repository for public clones
>     that supports robust CI/CD workflows for developers and downstream
>     distributions.
>
>   * A global robust and scalable email system leveraging existing
>     production deployments and reputation i.e. subspace.kernel.org.
>
>   * A continuous process of review for project requirements, FOSS usage,
>     security policy, and cost.
>
>   * A sustainable funding model for the infrastructure including a
>     diverse collection of sponsors to support various infrastructure
>     requirements now and in the future.
>
> While consensus for the move among GNU Maintainers for glibc is not
> unanimous, most of the maintainers endorse the move, and key developers
> have expressed their support in the upstream discussions. Additionally
> CTI has received a lot of feedback over the last 3 years as the project
> worked on infrastructure, and we include some of that feedback here and
> in our CTI FAQ [1] with comments.
>
> Some members of the community have expressed disappointment that funding
> would go to the Linux Foundation. Some members of the community have
> expressed concern that a board structure would allow corporate
> influence. Neither of these concerns are new and exist today with Red
> Hat and IBM, both being for-profit corporate entities. The GNU Toolchain
> leadership has a 30+ year history of successfully navigating the
> dynamics of working with sponsors and providing FOSS solutions,
> including meeting the GNU Ethical Repository hosting criteria.
>
> We invite all members of the glibc and GNU Toolchain community to join
> us in this important transition. Your insights, contributions, and
> feedback are essential to making CTI infrastructure a success that
> benefits everyone. Let's work together to build a more secure and
> sustainable future — reach out on libc-alpha@sourceware.org, participate
> in the weekly office hours, or propose ways to get involved. Let's
> collaborate to build a more resilient and sustainable infrastructure
> foundation for the GNU Toolchain.
>
> Action plan:
>
>   * Weekly office hours for CTI to provide an open space for discussion
>     of infrastructure improvements
>
>   * Work with LF IT to update the CY24 statement of work and discuss with
>     the glibc developers
>
>   * Work towards migrating glibc git and mailing lists as first priority
>     since these match our security priorities.
>
> Cheers,
> Carlos O’Donell
> GNU Maintainer for glibc
> Core Toolchain Infrastructure Project TAC member
> [1] https://cti.coretoolchain.dev/faq/index.html
>
>

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-27 11:23, Andrew Pinski wrote:
> Please dont.
> The concern is more than foundations.
> Sourceware has stepped up in ways that linux foundation it could not and 
> would not do without a new contract.
> 
> An example has been integration with forge.

Experimental and low volume/impact uses like the forge are exactly what 
we'll continue using sourceware for; it's a great place to pilot 
infrastructure related experiments where we have root access and can try 
different things.  The LF infrastructure provides stable funding and 
scalability for core services like git, email and bugzilla.  If/when the 
forge becomes central to the glibc workflow and needs to scale, we have 
the option to get that included (and funded) through the LF IT.

> Other examples is how handling of AI scrapping. Iirc there was nothing 
> in the contract with LF It for handling of that and still has not been 
> added.

I'm not sure what you mean here, could you please elaborate on how LF IT 
is unable to handle AI scraping related infrastructure challenges vs 
sourceware?  What would you like included in the LF IT contract to 
specifically handle AI scraping?  IMO it's covered under general 
infrastructure reliability and there's no real need for additional 
clauses in any contract for this.

> Without a fluid contract, LF IT is bad for security and stability and the future of glibc.

The TAC is responsible for identifying the technical requirements and 
the funding LF project (OpenSSF in this case) is responsible for funding 
what we identify.  Fluidity of the contract doesn't really matter here, 
it's a statement of work and it can be amended and funded as and when we 
need it.

Sid

Re: CTI - Making a decision for glibc.

[Joseph Myers]

On Tue, 27 Jan 2026, Siddhesh Poyarekar wrote:

> > Other examples is how handling of AI scrapping. Iirc there was nothing in
> > the contract with LF It for handling of that and still has not been added.
> 
> I'm not sure what you mean here, could you please elaborate on how LF IT is
> unable to handle AI scraping related infrastructure challenges vs sourceware?

Furthermore, AI scrapers are exactly the kind of thing where scale helps - 
more resources to spend on mitigations that can be shared with mitigations 
shared with other projects such as the Linux kernel, and more resources to 
serve whatever load from scrapers can't be effectively blocked without 
causing issues for legitimate users.

It should be fairly clear that when we had problems with load on git over 
https recently, suggesting that people use insecure git:// was hardly a 
good mitigation, and nor was disabling the smart http backend and leaving 
only the dumb one with warnings it might not be able to do new clones.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Tue, Jan 27, 2026 at 8:58 AM Joseph Myers <josmyers@redhat.com> wrote:
>
> On Tue, 27 Jan 2026, Siddhesh Poyarekar wrote:
>
> > > Other examples is how handling of AI scrapping. Iirc there was nothing in
> > > the contract with LF It for handling of that and still has not been added.
> >
> > I'm not sure what you mean here, could you please elaborate on how LF IT is
> > unable to handle AI scraping related infrastructure challenges vs sourceware?
>
> Furthermore, AI scrapers are exactly the kind of thing where scale helps -
> more resources to spend on mitigations that can be shared with mitigations
> shared with other projects such as the Linux kernel, and more resources to
> serve whatever load from scrapers can't be effectively blocked without
> causing issues for legitimate users.
>
> It should be fairly clear that when we had problems with load on git over
> https recently, suggesting that people use insecure git:// was hardly a
> good mitigation, and nor was disabling the smart http backend and leaving
> only the dumb one with warnings it might not be able to do new clones.

Actually LF IT would not have a solution for that even with the
scaling you are thinking about.
So the talk about scale vs AI scrapping is the wrong thing.
Is LF IT going to fix git because that was where the scaling issue
was; not in needing more hardware or machines.


>
> --
> Joseph S. Myers
> josmyers@redhat.com
>

Re: CTI - Making a decision for glibc.

[David Edelsohn]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

On Tue, Jan 27, 2026 at 12:01 PM Andrew Pinski <pinskia@gmail.com> wrote:

> On Tue, Jan 27, 2026 at 8:58 AM Joseph Myers <josmyers@redhat.com> wrote:
> >
> > On Tue, 27 Jan 2026, Siddhesh Poyarekar wrote:
> >
> > > > Other examples is how handling of AI scrapping. Iirc there was
> nothing in
> > > > the contract with LF It for handling of that and still has not been
> added.
> > >
> > > I'm not sure what you mean here, could you please elaborate on how LF
> IT is
> > > unable to handle AI scraping related infrastructure challenges vs
> sourceware?
> >
> > Furthermore, AI scrapers are exactly the kind of thing where scale helps
> -
> > more resources to spend on mitigations that can be shared with
> mitigations
> > shared with other projects such as the Linux kernel, and more resources
> to
> > serve whatever load from scrapers can't be effectively blocked without
> > causing issues for legitimate users.
> >
> > It should be fairly clear that when we had problems with load on git over
> > https recently, suggesting that people use insecure git:// was hardly a
> > good mitigation, and nor was disabling the smart http backend and leaving
> > only the dumb one with warnings it might not be able to do new clones.
>
> Actually LF IT would not have a solution for that even with the
> scaling you are thinking about.
> So the talk about scale vs AI scrapping is the wrong thing.
> Is LF IT going to fix git because that was where the scaling issue
> was; not in needing more hardware or machines.
>

 The transition of GLIBC infrastructure to CTI/LF IT is a fantastic step
for the
continued, long-term success of GLIBC and the GNU Toolchain project.
LF IT is a well-established, well-respected team that provides very similar
capabilities to the Linux kernel community, who have very similar
requirements.

It's important to hear these technical concerns.  The CTI TAC will catalog
them
and ensure that they are addressed in the LF IT implementation.  CTI
welcomes
the GNU Toolchain community and Sourceware help and participation to ensure
a smooth and successful transition.

Thanks, David

Re: CTI - Making a decision for glibc.

[Florian Weimer]

* Andrew Pinski via Overseers:

> Please dont.
> The concern is more than foundations.
> Sourceware has stepped up in ways that linux foundation it could not and
> would not do without a new contract.

While I appreciate what Sourceware has been doing and is doing for us,
they just cannot implement some things, like turning off From: rewriting
on mailing lists that are used for patch distribution.

> An example has been integration with forge.

The glibc project doesn't want to move to a forge at this time, so this
is not really a concern for us?

> Other examples is how handling of AI scrapping. Iirc there was nothing in
> the contract with LF It for handling of that and still has not been
> added.

Didn't Sourceware disable https:// Git service at various points as part
of this (first full disablement, then just the smart transport)?  We
don't want people to direct to git:// as a stable replacement.

(Without the smart transport, https:// clones are not usable from most
of the world due to the RTT overhead.)

Thanks,
Florian

Re: CTI - Making a decision for glibc.

[Florian Weimer]

* Andrew Pinski via Overseers:

> Actually LF IT would not have a solution for that even with the
> scaling you are thinking about.
> So the talk about scale vs AI scrapping is the wrong thing.
> Is LF IT going to fix git because that was where the scaling issue
> was; not in needing more hardware or machines.

Why wouldn't the git.kernel.org infrastructure insufficient for glibc?
Maybe GCC clones are harder than kernel clones, but glibc is quite a bit
smaller.

Thanks,
Florian

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Tue, Jan 27, 2026 at 9:34 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Andrew Pinski via Overseers:
>
> > Please dont.
> > The concern is more than foundations.
> > Sourceware has stepped up in ways that linux foundation it could not and
> > would not do without a new contract.
>
> While I appreciate what Sourceware has been doing and is doing for us,
> they just cannot implement some things, like turning off From: rewriting
> on mailing lists that are used for patch distribution.

LF IT won't be able to do it either. This is a problem that is NOT
solvable by switching providers. The problem is gmail has messed up
email lists.
See https://lwn.net/Articles/950567/ for an example.


>
> > An example has been integration with forge.
>
> The glibc project doesn't want to move to a forge at this time, so this
> is not really a concern for us?
>
> > Other examples is how handling of AI scrapping. Iirc there was nothing in
> > the contract with LF It for handling of that and still has not been
> > added.
>
> Didn't Sourceware disable https:// Git service at various points as part
> of this (first full disablement, then just the smart transport)?  We
> don't want people to direct to git:// as a stable replacement.
>
> (Without the smart transport, https:// clones are not usable from most
> of the world due to the RTT overhead.)
>
> Thanks,
> Florian
>

Re: CTI - Making a decision for glibc.

[Jakub Jelinek]

On Tue, Jan 27, 2026 at 11:15:28AM -0500, Carlos O'Donell wrote:
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

I think this is a bad idea and if this was about GCC rather than glibc
I'd be very strongly against that, but as I'm not actively working on glibc
anymore, if the majority of the glibc current developers support that, I
won't object.

	Jakub

Re: CTI - Making a decision for glibc.

[Florian Weimer]

* Carlos O'Donell:

> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

What does this mean in terms of workflow changes?

The last status update on the web says that Gitolite is still under
evaluation.  What would branch management etc. look like?

Thanks,
Florian

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-27 12:36, Andrew Pinski wrote:
>>> Please dont.
>>> The concern is more than foundations.
>>> Sourceware has stepped up in ways that linux foundation it could not and
>>> would not do without a new contract.
>>
>> While I appreciate what Sourceware has been doing and is doing for us,
>> they just cannot implement some things, like turning off From: rewriting
>> on mailing lists that are used for patch distribution.
> 
> LF IT won't be able to do it either. This is a problem that is NOT
> solvable by switching providers. The problem is gmail has messed up
> email lists.
> See https://lwn.net/Articles/950567/ for an example.

AI scraping is not the motivation for the switch anyway; these 
discussions predate all of this by years.  If anything, that article 
only reinforces the fact that infrastructure discussions and actions 
remain open and transparent and that there's plenty of room to scale GNU 
toolchain infrastructure with the OpenSSF funding.

Sid

Re: CTI - Making a decision for glibc.

[Joseph Myers]

On Tue, 27 Jan 2026, Florian Weimer wrote:

> * Carlos O'Donell:
> 
> > tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> > core services to infrastructure hosted by the Core Toolchain
> > Infrastructure (CTI) project. As maintainers for the project we do this
> > to meet the present and future needs of glibc and the GNU Toolchain. We
> > want secure, robust, and sustainable infrastructure, balanced against
> > the needs of developers and the community to collaborate and innovate,
> > with reliable funding to support the infrastructure in the long term.
> 
> What does this mean in terms of workflow changes?
> 
> The last status update on the web says that Gitolite is still under
> evaluation.  What would branch management etc. look like?

There's not meant to be any workflow change beyond switching git checkouts 
to some different location (and thus active users with write access 
needing to register their SSH public keys at the new location).  I'd 
expect the same branch conventions (including the same rules on which 
branches allow or disallow force pushes and branch deletion).

Hopefully http redirection works for existing https checkouts; I don't 
know if git:// can do anything like that, but I think it's possible for a 
git server to send messages to clients that they're using a deprecated 
location that's no longer updated (maybe messages on the stderr of 
git-upload-pack get reported to the client?).  And of course we'd block 
all pushes / ref updates on the existing repository when making the move.

Email addresses for mailing lists can of course forward so that email sent 
to existing list addresses gets delivered to the new list hosting.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: CTI - Making a decision for glibc.

[Maxim Kuvyrkov]

> On Jan 28, 2026, at 05:15, Carlos O'Donell <carlos@redhat.com> wrote:
> 
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

I think this is the right thing to do.  The GNU Toolchain projects are smaller than Linux kernel in terms of git repo size, community size and user-base size -- so whatever hosting approach works for Linux will work for us as well.  As a bonus, whenever there is a new issue (e.g., new type of DDoS), the Linux folks are likely to be affected first, and they might fix it before we ever notice.  It's easier not to be the biggest fish in the pond.

Regarding Sourceware vs LF IT -- these are two different tools, and I'm a proponent of using the right tool for the job.  I see LF IT as industrial-scale hosting, and Sourceware as experimental workshop -- and we need both.  We should be using Sourceware for forge, CI, and other experiments, which we will not be able to easily do on LF IT.  And use LF IT for stable solid core functionality like git hosting and mailing lists.

Thanks,

--
Maxim Kuvyrkov
https://www.linaro.org


> 
> In 2019 leadership from the GNU Toolchain started down a path that led
> to the Core Toolchain Infrastructure project. The project aims to move
> toolchain infrastructure issues forward; to provide a sustainable path
> forward for secure and state of the art infrastructure.
> 
> Post-pandemic, since 2022 the GNU Toolchain has continued to move
> forward the state of the current infrastructure by engaging the
> developers, the projects, and a wider set of sponsors that can
> support a sustainable path forward for the toolchain.
> 
> Key achievements:
> 
> 2022 - Started using infrastructure provided by CTI like BigBlueButton
>        for meetings for the GNU Toolchain e.g. Weekly glibc patch
>        queue review and Monthly Office hours in two timezones.
> 
> 2023 - Service enumeration for GNU Toolchain projects (gcc, glibc,
>        binutils, gdb).
> 
> 2024 - Completed pricing and service contract negotiation for migration
>        with LF IT.
> 
> 2025 - Completed GNU Toolchain and glibc documents to define secure
>        development requirements and the infrastructure needs.
> 
> These steps were a necessary evolution and resulted in several critical
> milestones, e.g., service enumeration, secure development documents;
> which collectively paved the way for a sustainable path forward.
> 
> While it was clear to the GNU Toolchain leadership that requirements
> were coming to improve the toolchain cyber-security posture, these
> requirements were not clear to all project developers. As part of
> receiving this feedback we have worked to document and define a secure
> development policy for glibc and at a higher level the GNU Toolchain.
> While Sourceware has started making some critical technical changes, the
> GNU Toolchain still faces serious, systemic concerns about securing a
> global, highly available service and building a sustainable, diverse
> sponsorship model. At the same time we are freeing up the GNU Toolchain
> developers and volunteers to focus on next-generation work, such as
> Sourceware’s post-commit CI and Forge-based workflows.
> 
> The decision to leverage CTI and LF IT is the direct result of seeking a
> comprehensive, long-term solution to these exact challenges, expanding
> our sponsorship base and leveraging existing sponsors like the OpenSSF.
> The CTI TAC’s proposal to use Linux Foundation IT is rooted in the fact
> that they are an existing team in the industry that implements very
> similar functionality for the Linux kernel. The proposal directly
> benefits glibc developers. By partnering with a team that develops and
> understands FOSS tooling (b4, grokmirror and patatt) and large-scale
> kernel infrastructure. This partnership ensures our core infrastructure
> is secure and scalable.
> 
> This sustainable path forward for glibc includes:
> 
> * A global robust and secure mirrored git repository for public clones
>   that supports robust CI/CD workflows for developers and downstream
>   distributions.
> 
> * A global robust and scalable email system leveraging existing
>   production deployments and reputation i.e. subspace.kernel.org.
> 
> * A continuous process of review for project requirements, FOSS usage,
>   security policy, and cost.
> 
> * A sustainable funding model for the infrastructure including a
>   diverse collection of sponsors to support various infrastructure
>   requirements now and in the future.
> 
> While consensus for the move among GNU Maintainers for glibc is not
> unanimous, most of the maintainers endorse the move, and key developers
> have expressed their support in the upstream discussions. Additionally
> CTI has received a lot of feedback over the last 3 years as the project
> worked on infrastructure, and we include some of that feedback here and
> in our CTI FAQ [1] with comments.
> 
> Some members of the community have expressed disappointment that funding
> would go to the Linux Foundation. Some members of the community have
> expressed concern that a board structure would allow corporate
> influence. Neither of these concerns are new and exist today with Red
> Hat and IBM, both being for-profit corporate entities. The GNU Toolchain
> leadership has a 30+ year history of successfully navigating the
> dynamics of working with sponsors and providing FOSS solutions,
> including meeting the GNU Ethical Repository hosting criteria.
> 
> We invite all members of the glibc and GNU Toolchain community to join
> us in this important transition. Your insights, contributions, and
> feedback are essential to making CTI infrastructure a success that
> benefits everyone. Let's work together to build a more secure and
> sustainable future — reach out on libc-alpha@sourceware.org, participate
> in the weekly office hours, or propose ways to get involved. Let's
> collaborate to build a more resilient and sustainable infrastructure
> foundation for the GNU Toolchain.
> 
> Action plan:
> 
> * Weekly office hours for CTI to provide an open space for discussion
>   of infrastructure improvements
> 
> * Work with LF IT to update the CY24 statement of work and discuss with
>   the glibc developers
> 
> * Work towards migrating glibc git and mailing lists as first priority
>   since these match our security priorities.
> 
> Cheers,
> Carlos O’Donell
> GNU Maintainer for glibc
> Core Toolchain Infrastructure Project TAC member
> [1] https://cti.coretoolchain.dev/faq/index.html
> 

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Tue, Jan 27, 2026 at 3:19 PM Maxim Kuvyrkov via Overseers
<overseers@sourceware.org> wrote:
>
> > On Jan 28, 2026, at 05:15, Carlos O'Donell <carlos@redhat.com> wrote:
> >
> > tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> > core services to infrastructure hosted by the Core Toolchain
> > Infrastructure (CTI) project. As maintainers for the project we do this
> > to meet the present and future needs of glibc and the GNU Toolchain. We
> > want secure, robust, and sustainable infrastructure, balanced against
> > the needs of developers and the community to collaborate and innovate,
> > with reliable funding to support the infrastructure in the long term.
>
> I think this is the right thing to do.  The GNU Toolchain projects are smaller than Linux kernel in terms of git repo size, community size and user-base size -- so whatever hosting approach works for Linux will work for us as well.  As a bonus, whenever there is a new issue (e.g., new type of DDoS), the Linux folks are likely to be affected first, and they might fix it before we ever notice.  It's easier not to be the biggest fish in the pond.

LF IT is NOT a tool, it is a contract.
Also " the Linux folks are likely to be affected first" That is a
false hood on what you think. It is not true and has never been true.

>
> Regarding Sourceware vs LF IT -- these are two different tools, and I'm a proponent of using the right tool for the job.  I see LF IT as industrial-scale hosting, and Sourceware as experimental workshop -- and we need both.  We should be using Sourceware for forge, CI, and other experiments, which we will not be able to easily do on LF IT.  And use LF IT for stable solid core functionality like git hosting and mailing lists.

Why do you think `LF IT as industrial-scale hosting`? There is no
different in LT IT than sourceware at all; people on LT IT have the
same knowledge as sourceware.
In fact it is a degradation of support to use LF IT because there are
not part of the community which means you have to go out of your way
and ping someone when things are broken from the community. Will there
be a LF IT IRC channel so we can ping someone when say bugzilla
breaks? Or there is a git lock happened?  I don't think so.


>
> Thanks,
>
> --
> Maxim Kuvyrkov
> https://www.linaro.org
>
>
> >
> > In 2019 leadership from the GNU Toolchain started down a path that led
> > to the Core Toolchain Infrastructure project. The project aims to move
> > toolchain infrastructure issues forward; to provide a sustainable path
> > forward for secure and state of the art infrastructure.
> >
> > Post-pandemic, since 2022 the GNU Toolchain has continued to move
> > forward the state of the current infrastructure by engaging the
> > developers, the projects, and a wider set of sponsors that can
> > support a sustainable path forward for the toolchain.
> >
> > Key achievements:
> >
> > 2022 - Started using infrastructure provided by CTI like BigBlueButton
> >        for meetings for the GNU Toolchain e.g. Weekly glibc patch
> >        queue review and Monthly Office hours in two timezones.
> >
> > 2023 - Service enumeration for GNU Toolchain projects (gcc, glibc,
> >        binutils, gdb).
> >
> > 2024 - Completed pricing and service contract negotiation for migration
> >        with LF IT.
> >
> > 2025 - Completed GNU Toolchain and glibc documents to define secure
> >        development requirements and the infrastructure needs.
> >
> > These steps were a necessary evolution and resulted in several critical
> > milestones, e.g., service enumeration, secure development documents;
> > which collectively paved the way for a sustainable path forward.
> >
> > While it was clear to the GNU Toolchain leadership that requirements
> > were coming to improve the toolchain cyber-security posture, these
> > requirements were not clear to all project developers. As part of
> > receiving this feedback we have worked to document and define a secure
> > development policy for glibc and at a higher level the GNU Toolchain.
> > While Sourceware has started making some critical technical changes, the
> > GNU Toolchain still faces serious, systemic concerns about securing a
> > global, highly available service and building a sustainable, diverse
> > sponsorship model. At the same time we are freeing up the GNU Toolchain
> > developers and volunteers to focus on next-generation work, such as
> > Sourceware’s post-commit CI and Forge-based workflows.
> >
> > The decision to leverage CTI and LF IT is the direct result of seeking a
> > comprehensive, long-term solution to these exact challenges, expanding
> > our sponsorship base and leveraging existing sponsors like the OpenSSF.
> > The CTI TAC’s proposal to use Linux Foundation IT is rooted in the fact
> > that they are an existing team in the industry that implements very
> > similar functionality for the Linux kernel. The proposal directly
> > benefits glibc developers. By partnering with a team that develops and
> > understands FOSS tooling (b4, grokmirror and patatt) and large-scale
> > kernel infrastructure. This partnership ensures our core infrastructure
> > is secure and scalable.
> >
> > This sustainable path forward for glibc includes:
> >
> > * A global robust and secure mirrored git repository for public clones
> >   that supports robust CI/CD workflows for developers and downstream
> >   distributions.
> >
> > * A global robust and scalable email system leveraging existing
> >   production deployments and reputation i.e. subspace.kernel.org.
> >
> > * A continuous process of review for project requirements, FOSS usage,
> >   security policy, and cost.
> >
> > * A sustainable funding model for the infrastructure including a
> >   diverse collection of sponsors to support various infrastructure
> >   requirements now and in the future.
> >
> > While consensus for the move among GNU Maintainers for glibc is not
> > unanimous, most of the maintainers endorse the move, and key developers
> > have expressed their support in the upstream discussions. Additionally
> > CTI has received a lot of feedback over the last 3 years as the project
> > worked on infrastructure, and we include some of that feedback here and
> > in our CTI FAQ [1] with comments.
> >
> > Some members of the community have expressed disappointment that funding
> > would go to the Linux Foundation. Some members of the community have
> > expressed concern that a board structure would allow corporate
> > influence. Neither of these concerns are new and exist today with Red
> > Hat and IBM, both being for-profit corporate entities. The GNU Toolchain
> > leadership has a 30+ year history of successfully navigating the
> > dynamics of working with sponsors and providing FOSS solutions,
> > including meeting the GNU Ethical Repository hosting criteria.
> >
> > We invite all members of the glibc and GNU Toolchain community to join
> > us in this important transition. Your insights, contributions, and
> > feedback are essential to making CTI infrastructure a success that
> > benefits everyone. Let's work together to build a more secure and
> > sustainable future — reach out on libc-alpha@sourceware.org, participate
> > in the weekly office hours, or propose ways to get involved. Let's
> > collaborate to build a more resilient and sustainable infrastructure
> > foundation for the GNU Toolchain.
> >
> > Action plan:
> >
> > * Weekly office hours for CTI to provide an open space for discussion
> >   of infrastructure improvements
> >
> > * Work with LF IT to update the CY24 statement of work and discuss with
> >   the glibc developers
> >
> > * Work towards migrating glibc git and mailing lists as first priority
> >   since these match our security priorities.
> >
> > Cheers,
> > Carlos O’Donell
> > GNU Maintainer for glibc
> > Core Toolchain Infrastructure Project TAC member
> > [1] https://cti.coretoolchain.dev/faq/index.html
> >
>

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

On 1/27/2026 9:15 AM, Carlos O'Donell wrote:
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.
[ ... snip ... ]
So this has been a long time coming; as Carlos noted this effort started 
years ago --  back when I was still with Red Hat!  It's been a ton of 
work for many folks, not just Carlos and I'd like to thank them for 
sticking with the process and pushing to ensure that the migration for 
glibc is as smooth as it can possibly be.

As we've already seen, not everyone is going to be happy with this 
decision for the glibc project, but it's a decision the leaders of the 
project have made and I'm fully supportive of both the process and the 
final decision that the glibc project has reached.

I'm not going to try and rehash all the points folks have made (from 
either side).  I will ask that folks realize everyone is trying to do 
what they think is best for the projects they have an interest in.  We 
don't have to agree on everything and at the end of the day we still 
need to work together to move these core infrastructure projects forward.

With glibc moving, I think it is in multiple projects' best interests to 
monitor how the move goes and ponder how the transition is working in 
practice.    I'm cautiously optimistic that the movement will have 
minimal hiccups and result in infrastructure that continues to serve the 
needs of the development community and the glibc transition provides a 
blueprint for any other projects that may want to move in the future.

I'd love to have a frank (and likely spirited) discussion on what's 
working well and what isn't at the next Cauldron.

Carlos, David, etc  Congrats.  It's been a long long road.

jeff

ps.  And just to be 100% clear given the controversial nature of this 
change, my opinions are strictly my own.  I do not speak for any 
project, employer (past, present or future), or other entities.

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

On 1/27/2026 12:16 PM, Joseph Myers wrote:
> On Tue, 27 Jan 2026, Florian Weimer wrote:
>
>> * Carlos O'Donell:
>>
>>> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
>>> core services to infrastructure hosted by the Core Toolchain
>>> Infrastructure (CTI) project. As maintainers for the project we do this
>>> to meet the present and future needs of glibc and the GNU Toolchain. We
>>> want secure, robust, and sustainable infrastructure, balanced against
>>> the needs of developers and the community to collaborate and innovate,
>>> with reliable funding to support the infrastructure in the long term.
>> What does this mean in terms of workflow changes?
>>
>> The last status update on the web says that Gitolite is still under
>> evaluation.  What would branch management etc. look like?
> There's not meant to be any workflow change beyond switching git checkouts
> to some different location (and thus active users with write access
> needing to register their SSH public keys at the new location).  I'd
> expect the same branch conventions (including the same rules on which
> branches allow or disallow force pushes and branch deletion).
This was my expectation -- we upload keys, adjust our git config, then 
get on with life.   At least that's what I expect most users to need 
nothing else.  Things like integrations and hooks may need adjustment, 
but that's for the project infrastructure folks to sort out, not end 
developers & users.

jeff

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

On 1/27/2026 10:34 AM, Florian Weimer via Overseers wrote:
>> Other examples is how handling of AI scrapping. Iirc there was nothing in
>> the contract with LF It for handling of that and still has not been
>> added.
> Didn't Sourceware disable https:// Git service at various points as part
> of this (first full disablement, then just the smart transport)?  We
> don't want people to direct to git:// as a stable replacement.
Yup.  And it brought down CI systems that were reliant upon anonymous 
checkouts.  It was necessary at the time, but obviously highly inconvenient.

Jeff

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

On 1/27/2026 10:36 AM, Florian Weimer via Overseers wrote:
> * Andrew Pinski via Overseers:
>
>> Actually LF IT would not have a solution for that even with the
>> scaling you are thinking about.
>> So the talk about scale vs AI scrapping is the wrong thing.
>> Is LF IT going to fix git because that was where the scaling issue
>> was; not in needing more hardware or machines.
> Why wouldn't the git.kernel.org infrastructure insufficient for glibc?
> Maybe GCC clones are harder than kernel clones, but glibc is quite a bit
> smaller.
Concretely the kernel and gcc repositories are about 1 order of 
magnitude larger than glibc & binutils which in turn are 3-4X the size 
of newlib-cygwin (5-6G vs several hundred M vs a couple hundred M).    
If the infrastructure can handle the kernel's git repo, then it should 
be able to easily handle glibc's repo.

jeff

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Tue, Jan 27, 2026 at 8:16 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

Where are the concrete plans on doing this transitition and timelines?
Also from CTI's own project page:
As of 2025-08-11 moving to new infrastructure is on hold as we discuss
the core reasons for the migration.
....
So CTI's page for this action seems to be missing.


>
> In 2019 leadership from the GNU Toolchain started down a path that led
> to the Core Toolchain Infrastructure project. The project aims to move
> toolchain infrastructure issues forward; to provide a sustainable path
> forward for secure and state of the art infrastructure.
>
> Post-pandemic, since 2022 the GNU Toolchain has continued to move
> forward the state of the current infrastructure by engaging the
> developers, the projects, and a wider set of sponsors that can
> support a sustainable path forward for the toolchain.
>
> Key achievements:
>
>   2022 - Started using infrastructure provided by CTI like BigBlueButton
>          for meetings for the GNU Toolchain e.g. Weekly glibc patch
>          queue review and Monthly Office hours in two timezones.
>
>   2023 - Service enumeration for GNU Toolchain projects (gcc, glibc,
>          binutils, gdb).
>
>   2024 - Completed pricing and service contract negotiation for migration
>          with LF IT.
>
>   2025 - Completed GNU Toolchain and glibc documents to define secure
>          development requirements and the infrastructure needs.
>
> These steps were a necessary evolution and resulted in several critical
> milestones, e.g., service enumeration, secure development documents;
> which collectively paved the way for a sustainable path forward.
>
> While it was clear to the GNU Toolchain leadership that requirements
> were coming to improve the toolchain cyber-security posture, these
> requirements were not clear to all project developers. As part of
> receiving this feedback we have worked to document and define a secure
> development policy for glibc and at a higher level the GNU Toolchain.
> While Sourceware has started making some critical technical changes, the
> GNU Toolchain still faces serious, systemic concerns about securing a
> global, highly available service and building a sustainable, diverse
> sponsorship model. At the same time we are freeing up the GNU Toolchain
> developers and volunteers to focus on next-generation work, such as
> Sourceware’s post-commit CI and Forge-based workflows.
>
> The decision to leverage CTI and LF IT is the direct result of seeking a
> comprehensive, long-term solution to these exact challenges, expanding
> our sponsorship base and leveraging existing sponsors like the OpenSSF.
> The CTI TAC’s proposal to use Linux Foundation IT is rooted in the fact
> that they are an existing team in the industry that implements very
> similar functionality for the Linux kernel. The proposal directly
> benefits glibc developers. By partnering with a team that develops and
> understands FOSS tooling (b4, grokmirror and patatt) and large-scale
> kernel infrastructure. This partnership ensures our core infrastructure
> is secure and scalable.
>
> This sustainable path forward for glibc includes:
>
>   * A global robust and secure mirrored git repository for public clones
>     that supports robust CI/CD workflows for developers and downstream
>     distributions.
>
>   * A global robust and scalable email system leveraging existing
>     production deployments and reputation i.e. subspace.kernel.org.
>
>   * A continuous process of review for project requirements, FOSS usage,
>     security policy, and cost.
>
>   * A sustainable funding model for the infrastructure including a
>     diverse collection of sponsors to support various infrastructure
>     requirements now and in the future.
>
> While consensus for the move among GNU Maintainers for glibc is not
> unanimous, most of the maintainers endorse the move, and key developers
> have expressed their support in the upstream discussions. Additionally
> CTI has received a lot of feedback over the last 3 years as the project
> worked on infrastructure, and we include some of that feedback here and
> in our CTI FAQ [1] with comments.
>
> Some members of the community have expressed disappointment that funding
> would go to the Linux Foundation. Some members of the community have
> expressed concern that a board structure would allow corporate
> influence. Neither of these concerns are new and exist today with Red
> Hat and IBM, both being for-profit corporate entities. The GNU Toolchain
> leadership has a 30+ year history of successfully navigating the
> dynamics of working with sponsors and providing FOSS solutions,
> including meeting the GNU Ethical Repository hosting criteria.
>
> We invite all members of the glibc and GNU Toolchain community to join
> us in this important transition. Your insights, contributions, and
> feedback are essential to making CTI infrastructure a success that
> benefits everyone. Let's work together to build a more secure and
> sustainable future — reach out on libc-alpha@sourceware.org, participate
> in the weekly office hours, or propose ways to get involved. Let's
> collaborate to build a more resilient and sustainable infrastructure
> foundation for the GNU Toolchain.
>
> Action plan:
>
>   * Weekly office hours for CTI to provide an open space for discussion
>     of infrastructure improvements
>
>   * Work with LF IT to update the CY24 statement of work and discuss with
>     the glibc developers
>
>   * Work towards migrating glibc git and mailing lists as first priority
>     since these match our security priorities.
>
> Cheers,
> Carlos O’Donell
> GNU Maintainer for glibc
> Core Toolchain Infrastructure Project TAC member
> [1] https://cti.coretoolchain.dev/faq/index.html
>

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]



On 1/27/2026 10:21 AM, David Edelsohn wrote:
>
>  The transition of GLIBC infrastructure to CTI/LF IT is a fantastic 
> step for the
> continued, long-term success of GLIBC and the GNU Toolchain project.
> LF IT is a well-established, well-respected team that provides very 
> similar
> capabilities to the Linux kernel community, who have very similar 
> requirements.
>
> It's important to hear these technical concerns.  The CTI TAC will 
> catalog them
> and ensure that they are addressed in the LF IT implementation.  CTI 
> welcomes
> the GNU Toolchain community and Sourceware help and participation to 
> ensure
> a smooth and successful transition.
I think that's going to be one of the key things to do once the initial 
transition of the bits is done -- evaluate how it works in practice, 
document gaps and concerns and ask the question (after a suitable period 
of burn-in), is this working well or not.

Jeff

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

On 1/27/2026 9:51 AM, Siddhesh Poyarekar wrote:
> On 2026-01-27 11:23, Andrew Pinski wrote:
>> Please dont.
>> The concern is more than foundations.
>> Sourceware has stepped up in ways that linux foundation it could not 
>> and would not do without a new contract.
>>
>> An example has been integration with forge.
>
> Experimental and low volume/impact uses like the forge are exactly 
> what we'll continue using sourceware for; it's a great place to pilot 
> infrastructure related experiments where we have root access and can 
> try different things.  The LF infrastructure provides stable funding 
> and scalability for core services like git, email and bugzilla.  
> If/when the forge becomes central to the glibc workflow and needs to 
> scale, we have the option to get that included (and funded) through 
> the LF IT.
Right.  This sounds like a great way to look at things.  Having the 
repos separate from these other services forces a model where moving a 
service from sourceware to LF IT is a lot easier to do in the future -- 
it essentially forces services to communicate over a channel with common 
APIs rather than any ad-hoc integration solutions.

>
>
>> Without a fluid contract, LF IT is bad for security and stability and 
>> the future of glibc.
>
> The TAC is responsible for identifying the technical requirements and 
> the funding LF project (OpenSSF in this case) is responsible for 
> funding what we identify.  Fluidity of the contract doesn't really 
> matter here, it's a statement of work and it can be amended and funded 
> as and when we need it.
RIght.  It's a contract and it should be expected by both parties that 
adjustments will need to be made over time.

Jeff

Re: CTI - Making a decision for glibc.

[Mark Wielaard]

Hi Carlos,

On Tue, Jan 27, 2026 at 11:15:28AM -0500, Carlos O'Donell wrote:
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

So this is describing how you believe the community should make a
decision for glibc? It feels like this is what you tried to push
through two years ago. Which I believe ended with the conclusion these
kind of decisions should be discussed with the project developers on
the public list to see if there can be some kind of concensus on the
direction of the project. Not as some kind of mandate. As far as I
know no new public discussions have been done, no new votes have been
cast. This is you just restating your opinion.

If this is meant as start of such a discussion then with my glibc
developer hat on I still believe it is a negative to set up a
corporate controlled directed fund to handle our infrastructure. I
don't want a messy migration of some of the services separating glibc
from the rest of the core toolchain and developer tool projects hosted
at Sourceware.

Two years ago Zoë summarized some of the discussion and controversies:
https://inbox.sourceware.org/libc-alpha/f20ce996-e9c6-4b6c-856d-eec6e14af26e@fsf.org/
I don't believe any of those objections have been resolved.

With my Sourceware Project Leadership hat on I would like to invite
you again to come to the Infrastructure Open Office meetings to
discuss this topic. These kind of organizational issues are certainly
on topic there. And if the CTI/LF/OpenSSF wants to contribute
resources to Sourceware that would certainly be appreciated. We can
invite some Software Freedom Conservancy staff to discuss how that
would work if you like to see that on the agenda.

And for those that are coming to Fosdem this weekend, there will be
some Sourceware PLC members around, plus SFC and FSF staff in case you
like to chat about free infrastructure.

Cheers,

Mark

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 27, 2026, "Carlos O'Donell" <carlos@redhat.com> wrote:

> tl;dr The GNU Maintainers for the GNU C Library (glibc)

Erhm.  It was a bad idea before, and nothing has improved to make this
hostile takeover less unpalatable, only more lies have been added on top
to try to force it through.

It's a lie that GNU Maintainers have made such a plan.  It might be more
accurate to state that a few have.

The excuses presented to justify the move don't hold water.

The resources that could be used for the project's benefit would be
welcome, but not at the expense of turning control over the project to a
hostile party that doesn't even recognize or acknowledge GNU, and that
is funded mainly by GPL violators.

Rendering control over a key piece of GNU to a hostile party is
obviously not being done for GNU's benefit, for GNU's sake, on its
behalf, or even in agreement with GNU leadership.  It's IMHO an abuse of
the authority that has been delegated, and therefore these acts should
be considered NULL and (void).

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

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-27 19:47, Alexandre Oliva wrote:
> The resources that could be used for the project's benefit would be
> welcome, but not at the expense of turning control over the project to a
> hostile party that doesn't even recognize or acknowledge GNU, and that
> is funded mainly by GPL violators.

There is no change in governance or functioning of the glibc project.

> Rendering control over a key piece of GNU to a hostile party is

The infrastructure on which the glibc git repository and mailing list 
are hosted are not GNU.  Savannah (that we use for some things like 
uploading tarballs) is, and that aspect is currently unchanged.

Sid

Re: CTI - Making a decision for glibc.

[Joseph Myers]

On Tue, 27 Jan 2026, Alexandre Oliva wrote:

> Rendering control over a key piece of GNU to a hostile party is
> obviously not being done for GNU's benefit, for GNU's sake, on its
> behalf, or even in agreement with GNU leadership.  It's IMHO an abuse of

I don't recognize this description of LF hosting.  The documented 
requirements for GNU package hosting are a grade of at least C on the GNU 
ethical repository criteria, which I believe the LF hosting fully meets 
(along with many of the criteria for higher grades - note that a lot of 
the criteria about recommending or offering options for licenses are 
simply inapplicable to hosting providers such as LF or Sourceware that 
don't allow users to add hosting for arbitrary packages of their own 
accord).

-- 
Joseph S. Myers
josmyers@redhat.com

Re: CTI - Making a decision for glibc.

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Tue, 27 Jan 2026, Jeffrey Law wrote:

> Right.  This sounds like a great way to look at things.  Having the repos
> separate from these other services forces a model where moving a service from
> sourceware to LF IT is a lot easier to do in the future -- it essentially
> forces services to communicate over a channel with common APIs rather than any
> ad-hoc integration solutions.

For example: at present, updating Bugzilla (GCC or Sourceware) with commit 
messages mentioning bugs involves a git hook running a script *using 
direct SQL access to search the Bugzilla database*.  Direct SQL access to 
the Bugzilla database is not a good interface at all (compared to, say, 
using the REST interface, as is done e.g. to generate the list of fixed 
bugs in a glibc release).

-- 
Joseph S. Myers
josmyers@redhat.com

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

On 1/27/2026 5:47 PM, Alexandre Oliva wrote:
> On Jan 27, 2026, "Carlos O'Donell" <carlos@redhat.com> wrote:
>
>> tl;dr The GNU Maintainers for the GNU C Library (glibc)
> Erhm.  It was a bad idea before, and nothing has improved to make this
> hostile takeover less unpalatable, only more lies have been added on top
> to try to force it through.
Sigh, there is no change in control, hostile takeover or hostile parties 
involved here.  Characterizing using those kinds of loaded terms isn't 
helpful to your case or the project as a whole.  It is precisely those 
kind of statements I was hoping to avoid because they are not constructive.

Clearly your are unhappy about the direction the project is taking on 
this decision.  I get that.  I can only hope that you will observe with 
an open mind and re-evaluate after some time has passed.

Jeff

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 27, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> On 2026-01-27 19:47, Alexandre Oliva wrote:
>> The resources that could be used for the project's benefit would be
>> welcome, but not at the expense of turning control over the project to a
>> hostile party that doesn't even recognize or acknowledge GNU, and that
>> is funded mainly by GPL violators.

> There is no change in governance or functioning of the glibc project.

There would be change of control over technical services and over data
storage.

Surely you're not naïve enough or unaware enough about software freedom
matters to dismiss the effects of loss of such control.  That's the core
and basis of software freedom philosophy.

>> Rendering control over a key piece of GNU to a hostile party is

> The infrastructure on which the glibc git repository and mailing list
> are hosted are not GNU.  Savannah (that we use for some things like 
> uploading tarballs) is, and that aspect is currently unchanged.

You're arguing talking points that aren't mine.

It is change for the worse.

It is founded on a fundamental misassumption that our current
community-member provider cannot offer us services that we wish, and
that we must resort to a SaaSS arrangement with a third party to get
them, and lose our autonomy in the process.

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 27, 2026, Joseph Myers <josmyers@redhat.com> wrote:

> On Tue, 27 Jan 2026, Alexandre Oliva wrote:
>> Rendering control over a key piece of GNU to a hostile party is
>> obviously not being done for GNU's benefit, for GNU's sake, on its
>> behalf, or even in agreement with GNU leadership.  It's IMHO an abuse of

> I don't recognize this description of LF hosting.

Please don't misdirect.  This is not about the hosting service per se,
it's about the hostility of the hosting provider.

If hosting of git repositories or publishing of information were the
issue, that wouldn't be SaaSS.

The services that are falsely claimed as justifying the move aren't
merely communication and publishing, they're computing, and, when
performed by a third party, amount to SaaSS (Service as a Software
Substitute), a malpractice that is worse than proprietary software to
the user whose computing is so done.

It's a fundamental betrayal of the values of our movement.

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 27, 2026, Jeffrey Law <jeffreyalaw@gmail.com> wrote:

>> Erhm.  It was a bad idea before, and nothing has improved to make this
>> hostile takeover less unpalatable, only more lies have been added on top
>> to try to force it through.

> Sigh, there is no change in control, hostile takeover or hostile
> parties involved here.

Oh, so who'd be in charge of rendering the services and thus controlling
the servers, the computing they do and the data they hold, if not an
organization that has always been hostile to GNU?

> Characterizing using those kinds of loaded terms

s/loaded/objective/

> isn't helpful to your case

Then maybe let me shoot myself in the foot?  Why do you care?

> precisely those kind of statements I was hoping to avoid because they
> are not constructive.

Whereas taking away a chunk of GNU is constructive, is what you're saying?

> Clearly your are unhappy about the direction the project is taking on
> this decision.

And I'm also unhappy that lies have been published suggesting that I'm
part of this destructive move.

> I can only hope that you will observe
> with an open mind and re-evaluate after some time has passed.

Don't count on my changing my mind about not giving up software freedom.

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

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Tue, Jan 27, 2026 at 5:27 PM Joseph Myers <josmyers@redhat.com> wrote:
>
> On Tue, 27 Jan 2026, Jeffrey Law wrote:
>
> > Right.  This sounds like a great way to look at things.  Having the repos
> > separate from these other services forces a model where moving a service from
> > sourceware to LF IT is a lot easier to do in the future -- it essentially
> > forces services to communicate over a channel with common APIs rather than any
> > ad-hoc integration solutions.
>
> For example: at present, updating Bugzilla (GCC or Sourceware) with commit
> messages mentioning bugs involves a git hook running a script *using
> direct SQL access to search the Bugzilla database*.  Direct SQL access to
> the Bugzilla database is not a good interface at all (compared to, say,
> using the REST interface, as is done e.g. to generate the list of fixed
> bugs in a glibc release).

I am not sure that LF IT is going to implement this at all.
Also why is this part of the discussion here in the first place as
that is independent of hosting site and really could have been done
years ago.

Thanks,
Andrew

>
> --
> Joseph S. Myers
> josmyers@redhat.com

Re: CTI - Making a decision for glibc.

[Jeffrey Law]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]



On 1/27/2026 8:02 PM, Alexandre Oliva wrote:
> On Jan 27, 2026, Jeffrey Law<jeffreyalaw@gmail.com> wrote:
>
>>> Erhm.  It was a bad idea before, and nothing has improved to make this
>>> hostile takeover less unpalatable, only more lies have been added on top
>>> to try to force it through.
>> Sigh, there is no change in control, hostile takeover or hostile
>> parties involved here.
> Oh, so who'd be in charge of rendering the services and thus controlling
> the servers, the computing they do and the data they hold, if not an
> organization that has always been hostile to GNU?
That's not a change in control of the project or a hostile takeover.  
The project still controls development, project policies, releases, etc 
etc.  LF IT is providing a service that the project has chosen to 
utilize.  The project still retains control over itself, including the 
possibility of moving away from LF IT if the project decides that's 
what's best.

> Then maybe let me shoot myself in the foot?  Why do you care?
I care because I have always respected you skills as a developer and I 
would rather have you involved in a positive way with development 
efforts rather than off in another world where the project doesn't 
benefit from your skills.  But the tone of your message makes it clear 
to me that we can't have a constructive discussion on this topic.  
  That's unfortunate.

jeff

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-27 21:40, Alexandre Oliva wrote:
> On Jan 27, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> On 2026-01-27 19:47, Alexandre Oliva wrote:
>>> The resources that could be used for the project's benefit would be
>>> welcome, but not at the expense of turning control over the project to a
>>> hostile party that doesn't even recognize or acknowledge GNU, and that
>>> is funded mainly by GPL violators.
> 
>> There is no change in governance or functioning of the glibc project.
> 
> There would be change of control over technical services and over data
> storage.
> 
> Surely you're not naïve enough or unaware enough about software freedom
> matters to dismiss the effects of loss of such control.  That's the core
> and basis of software freedom philosophy.

I'm aware enough to see that you're reading a threat to the GNU project 
where none exists.  Your claim of loss of control is rooted in LF IT 
being the "other" from the glibc community, due to them being employed 
by the Linux Foundation.  Many of us work for competitors and we find 
common ground to work primarily in the interest of the glibc project, so 
I don't think this is a new situation at all.

>>> Rendering control over a key piece of GNU to a hostile party is
> 
>> The infrastructure on which the glibc git repository and mailing list
>> are hosted are not GNU.  Savannah (that we use for some things like
>> uploading tarballs) is, and that aspect is currently unchanged.
> 
> You're arguing talking points that aren't mine.
> 
> It is change for the worse.
> 
> It is founded on a fundamental misassumption that our current
> community-member provider cannot offer us services that we wish, and
> that we must resort to a SaaSS arrangement with a third party to get
> them, and lose our autonomy in the process.

Unfortunately I cannot convince you of our position because I don't see 
myself moving you out of your deep rooted animosity towards the LF. 
You've been moving goalposts from the GNU Ethical repository hosting 
guidelines to whimsical claims of SaaSS and I don't see the point of 
chasing those claims.

Sid

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> Your claim of loss of control is rooted in
> LF IT being the "other" from the glibc community, due to them being
> employed by the Linux Foundation.

Yes, that's what makes the computing they do on our community's behalf
SaaSS and therefore worse than nonfree software.  I've been pointing
this out from the beginning.  When someone else does your computing for
you, that's taking away the control you deserve over your digital life.
That's the fundamental injustice that the free software movement fights
against.  This is not about hosting code by itself.  This is about doing
computing.  The addon features that some people seem to be interested
in, and use as an excuse to move to LF instead of implementing them
under community control, are what I'm concerned about.

That the provider would be a hostile organization who has for decades
worked to erase GNU from existence makes that prospect even worse.

> Unfortunately I cannot convince you of our position because I don't
> see myself moving you out of your deep rooted animosity towards the
> LF.

That seems to go both ways.  How many times has this destructive
proposal been put before us, and a number of us had to explain why it's
a bad idea?

> You've been moving goalposts from the GNU Ethical repository
> hosting guidelines

No sir, that's a misrepresentation.

I've raised the software freedom issue from the beginning.

I'm not moving the goal post.

That some of you either don't even understand the issue, or choose to
disregard it (I can't tell which), and keep on pushing for something
that is so obviously detrimental to software freedom, and detrimental to
GNU, makes me very worried.

I wish you would listen to me this time and try to understand what I'm
saying, instead of dismissing me one more time.  Maybe you wouldn't
change your mind (I don't really get what motivates you on this matter),
but at least I wouldn't get falsely accused of moving the goal post.

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Jeffrey Law <jeffreyalaw@gmail.com> wrote:

> That's not a change in control of the project or a hostile takeover. 

Oh, Jeff, please, come on, don't twist my words, that's not like you.
I'm not saying it is any of that.

I'm saying it would be a change in control over the essential services
that would move under a hostile organization.  It would be like using
nonfree software to implement those services, but worse because it would
be SaaSS: our data would become hostage, and we wouldn't even have
access to (modify) the software or its configurations.

Our community's computing, that we deserve to control collectively (per
the free software philosophy that motivates GNU), would be placed under
control of a third party, instead of our community's.  That loss of
control is the very injustice that the free software movement stands
against.

And that's not even an uninterested third party, but one that has for
decades been working to misrepresent as its own the fruits of all the
software development work that has gone into GNU.

>> Then maybe let me shoot myself in the foot?  Why do you care?

> I care because I have always respected you skills as a developer

Thank you.

> I would rather have you involved in a positive way with development
> efforts

As long as they don't violate core tenets of the movement that this
software development should be standing for, I would be positive.

When they do violate them, it's my duty to be one of the many sounding
the alarm and trying to bring others back to their minds.  That assumes
they mind about software freedom.  That grows unclearer every time this
detrimental proposal is brought forth.

> But the tone of your message makes it clear 
> to me that we can't have a constructive discussion on this topic.

The entire proposal is destructive and threatening.  It sucks, and every
time it's been put forth, it has been justified with misrepresentations
and false claims!

That my reaction comes across as negative is a reflection of that.

Maybe if the proposal stopped trying to destroy things I care a lot
about, such as software freedom for our community and for every one of
us, we could be constructive together.

But as long as it is threatening and destructive, it's not reasonable to
expect me to help make that destruction come about.  If I were to do
that, that would be self-defeating.  You can count on my fiercest
opposition to such destructive moves.

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Jeffrey Law <jeffreyalaw@gmail.com> wrote:

> we can't have a constructive discussion on this topic. 

FTR, I have suggested to Carlos during the Cauldron that trying to find
a way to use the promised funds with our current (non-ideal, but still)
hosting, to implement the desired addon features on it, rather than
having those funds come across as bait to lure us into a trap, would go
a long way in alleviating my concerns.

That *is* objectively constructive.

But has that been done?

Evidently not.

I worry why it hasn't.

It reeks of something fishy.

As a result, the bait, the trap and the discomfort stand, so that wasn't
a constructive choice.


But of course calling out behaviors by labeling them as not constructive
is often very selective.  It usually depends on what colors one's
glasses are tinted with.

We're showing our biases, no doubt, but is it constructive to label
disagreeing but well-founded and well-meaning opinions as not
constructive?

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> whimsical claims of SaaSS and I don't see the point of chasing those
> claims.

You know, arguing that you're not interested in aligning the proposal
with a core tenet of software freedom doesn't make it sound like the
proposal or those pushing it forward take software freedom seriously.

It doesn't do much to alleviate my concerns, quite the opposite :-(

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

Re: CTI - Making a decision for glibc.

[Mark Wielaard]

Hi Jeff,

On Tue, Jan 27, 2026 at 08:25:10PM -0700, Jeffrey Law wrote:
> >Then maybe let me shoot myself in the foot?  Why do you care?
> I care because I have always respected you skills as a developer and
> I would rather have you involved in a positive way with development
> efforts rather than off in another world where the project doesn't
> benefit from your skills.  But the tone of your message makes it
> clear to me that we can't have a constructive discussion on this
> topic.   That's unfortunate.

You can certainly fault the tone of Alex message. He is clearly
showing his emotions. Which isn't always very helpful. But I do think
Alex has been trying to be constructive. It is just that although
Carlos email had a positive tone, it wasn't really all that
constructive itself. It just restated the same proposal he made two
years ago without addressing any of the issues people had back
then. And there hasn't been any attempt to publicly discuss the imho
valid concerns people raised. Adopt any compromise proposals people
made. Or try to get to any kind of consensus. Which might explain the
rather negative reaction from some people.

I must admit that irritates me also a lot. And it makes Alex have to
repeat and restate his analysis from two years back. Failure to
acknowledge this makes you talk past each other about governance and
control.

Basically this proposal is for setting up a directed fund controlled
by the Linux Foundation into which corporations can donate money if
they first become a LF member company. In exchange these companies
will get a board seat to control what happens to this money and may
appoint a technical advisary member. In return the Linux Foundation
gets all the trademarks and coordinates all outreach, website and
marketing activities. Then the proposal is for this fund to have some
contract with the LF IT team instead of funding Sourceware services.

It is good to have a fund and fiscal sponsor, the community can hold
assets and enter into contracts, etc. It is also good to have
corporate sponsors. But we already have two such funds, the Working
Together Fund from the FSF and Sourceware itself as member project of
the SFC, which already have corporate sponsors (next to grants and
community donations).

I think Alex and others do have constructive proposals that would
prevent "corporate take over" and disruptive changes to where the
services are hosted.

Cheers,

Mark

Re: CTI - Making a decision for glibc.

[Florian Weimer]

* Mark Wielaard:

> Hi Carlos,
>
> On Tue, Jan 27, 2026 at 11:15:28AM -0500, Carlos O'Donell wrote:
>> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
>> core services to infrastructure hosted by the Core Toolchain
>> Infrastructure (CTI) project. As maintainers for the project we do this
>> to meet the present and future needs of glibc and the GNU Toolchain. We
>> want secure, robust, and sustainable infrastructure, balanced against
>> the needs of developers and the community to collaborate and innovate,
>> with reliable funding to support the infrastructure in the long term.
>
> So this is describing how you believe the community should make a
> decision for glibc?

As far as I can see, the approach uses the current governance structure.
I have not seen a proposal for an alternative structure.  What do you
mean by “community”?

> It feels like this is what you tried to push through two years
> ago. Which I believe ended with the conclusion these kind of decisions
> should be discussed with the project developers on the public list to
> see if there can be some kind of concensus on the direction of the
> project. Not as some kind of mandate. As far as I know no new public
> discussions have been done, no new votes have been cast. This is you
> just restating your opinion.

As a member of the development community who is not a GNU maintainer, I
nevertheless feel appropriately consulted.

Thanks,
Florian

Re: CTI - Making a decision for glibc.

[Mark Wielaard]

Hi Florian,

On Wed, 2026-01-28 at 13:12 +0100, Florian Weimer wrote:
> * Mark Wielaard:
> > 
> > So this is describing how you believe the community should make a
> > decision for glibc?
> 
> As far as I can see, the approach uses the current governance structure.
> I have not seen a proposal for an alternative structure.  What do you
> mean by “community”?

I mean community consensus as Zack Weinberg described it last time this
came up:
https://inbox.sourceware.org/libc-alpha/77cd5739-d62b-46c8-b154-1f4baf61c3ed@app.fastmail.com/

Cheers,

Mark

Unpopular opinion (Re: CTI - Making a decision for glibc.)

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

So...

I'm coming from a Linux distribution that is entirely noncommercial and
has in the past internally rejected the Linux Foundation as service provider,
because, err, it seemed way too corporate to us. In addition, right now all
my involvment with Gentoo and glibc is as an unpaid volunteer. That said...

> Basically this proposal is for setting up a directed fund controlled
> by the Linux Foundation into which corporations can donate money if
> they first become a LF member company. In exchange these companies
> will get a board seat to control what happens to this money and may
> appoint a technical advisary member....

I'm citing Mark here because this is a nice example, but my mail is
directed not to him specifically, just to make this clear.

Please get a grip. We are for now talking here about who is hosting git,
mailing lists, and bugzilla. Git and mailing lists are by definition
decentral, bugzilla is an SQL database which can easily be dumped and
restored elsewhere.

If anyone talks about project control and governance, it's *much* more
important to look at who is doing the actual coding work. This does for a
successful open source project not only include submitting your own fun
patches but also keeping the entire project going by helping out with
difficult things that are not your own passion.

As someone who is keeping track of the mailing list and patchwork,  I would
guess that roughly 90% of contributed code in glibc these day comes from people
who work for corporations with a stake in glibc. So, Gnu or not, complaining
about the Linux Foundation is somewhat hypocritical then.

I've made my peace with this because I see the systemic reasons for it.

If you think that this situation is wrong somehow, the first thing you
should do is join the patch reviewer pool [1] and volunteer help to
regularly work down the submission queue in Patchwork.

Making a stand over where services are hosted is mostly just throwing
flashbangs.


[1] https://sourceware.org/glibc/wiki/PatchworkReviewMeetings

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 1018 bytes --]

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-28 04:58, Mark Wielaard wrote:
> Basically this proposal is for setting up a directed fund controlled
> by the Linux Foundation into which corporations can donate money if
> they first become a LF member company. In exchange these companies
> will get a board seat to control what happens to this money and may
> appoint a technical advisary member. In return the Linux Foundation

I can assure you that if there's any hint of hostile manipulation of 
control over infrastructure, we will step away.  Based on my prior 
experience of working with a similarly structured company, corporations 
use these foundations to maintain distance from FOSS projects but still 
sustain them because they depend on the software and it is a 
significantly smaller cost for them to pool in support for the project 
with other companies, compared to writing something of their own.  So I 
see no reason or motivation for companies to attempt to wrest control of 
the glibc infrastructure away from the community members that form the TAC.

Sid

Re: Unpopular opinion (Re: CTI - Making a decision for glibc.)

[Adhemerval Zanella Netto]

On 28/01/26 09:47, Andreas K. Huettel wrote:
> So...
> 
> I'm coming from a Linux distribution that is entirely noncommercial and
> has in the past internally rejected the Linux Foundation as service provider,
> because, err, it seemed way too corporate to us. In addition, right now all
> my involvment with Gentoo and glibc is as an unpaid volunteer. That said...
> 
>> Basically this proposal is for setting up a directed fund controlled
>> by the Linux Foundation into which corporations can donate money if
>> they first become a LF member company. In exchange these companies
>> will get a board seat to control what happens to this money and may
>> appoint a technical advisary member....
> 
> I'm citing Mark here because this is a nice example, but my mail is
> directed not to him specifically, just to make this clear.
> 
> Please get a grip. We are for now talking here about who is hosting git,
> mailing lists, and bugzilla. Git and mailing lists are by definition
> decentral, bugzilla is an SQL database which can easily be dumped and
> restored elsewhere.
> 
> If anyone talks about project control and governance, it's *much* more
> important to look at who is doing the actual coding work. This does for a
> successful open source project not only include submitting your own fun
> patches but also keeping the entire project going by helping out with
> difficult things that are not your own passion.
> 
> As someone who is keeping track of the mailing list and patchwork,  I would
> guess that roughly 90% of contributed code in glibc these day comes from people
> who work for corporations with a stake in glibc. So, Gnu or not, complaining
> about the Linux Foundation is somewhat hypocritical then.
> 
> I've made my peace with this because I see the systemic reasons for it.
> 
> If you think that this situation is wrong somehow, the first thing you
> should do is join the patch reviewer pool [1] and volunteer help to
> regularly work down the submission queue in Patchwork.
> 
> Making a stand over where services are hosted is mostly just throwing
> flashbangs.
> 
> 
> [1] https://sourceware.org/glibc/wiki/PatchworkReviewMeetings
> 

Thank you Andreas, this is very reasonable take of this situation and I fully
agree with your assessment. I also don't see why we can't just rollback this
effort if the glibc community found out any governance or similar issue once
it is implemented.

Re: CTI - Making a decision for glibc.

[David Edelsohn]

[-- Attachment #1: Type: text/plain, Size: 2346 bytes --]

On Wed, Jan 28, 2026 at 12:22 AM Alexandre Oliva <oliva@gnu.org> wrote:

> On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> > whimsical claims of SaaSS and I don't see the point of chasing those
> > claims.
>
> You know, arguing that you're not interested in aligning the proposal
> with a core tenet of software freedom doesn't make it sound like the
> proposal or those pushing it forward take software freedom seriously.
>

Alex,

We appreciate that you are upset and concerned.  We appreciate that you
want the best for GLIBC and the GNU Toolchain.  The leadership and
developers of GLIBC and the GNU Toolchain are working in good faith
for the best of the project.

CTI has ensured that it is conforming to the GNU Ethical repository hosting
guidelines.

GLIBC and the GNU Toolchain Project support the principles of the GNU
Project, namely to develop and promote Free Software, specifically a
Unix-like operating system that grants users freedom, control, and
autonomy over their computing devices.  The GNU Toolchain always
has been the foundation for that goal.

The members of the GNU Project can have additional objectives
and relationships with other developers and other organizations.
Supporting the principles of GNU Project does not mean that the
GNU Toolchain inserts itself into and joins every argument.
The mission of the GNU Project shouldn't expand and shift based
on the loudest voices.  The GNU Toolchain Project is operating
with a clear, consistent set of principles.

The leadership of the GNU Toolchain has navigated the project for
over 30 years to be highly respected, technically excellent, and
widely adopted.  This is exactly contributing to the goals and
success of the GNU Project.  The GLIBC leadership believes that
utilizing CTI and LF IT for the core infrastructure is the best path to
continue to fulfill its mission within the GNU Project while ensuring
a secure, robust, sustainable, and resilient environment.

Cheers, David


>
> It doesn't do much to alleviate my concerns, quite the opposite :-(
>
> --
> 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/
>

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> I can assure you that if there's any hint of hostile manipulation of
> control over infrastructure, we will step away.

And yet you don't take the "you'll get funds, but you can only use them
to hire services under our own control" as a hint of hostile
manipulation of control over infrastructure, so instead of walking away
from the trap, you're jumping all in.

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

Re: Unpopular opinion (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Jan 28, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Making a stand over where services are hosted is

... exactly what this destructive proposal has been all about since its
inception.

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

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Tue, Jan 27, 2026 at 8:16 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

Coming back to this with a less frusted mind. I have to say this still
seems forced.
Especially with the following statement on your own projects page for 2025:
`As of 2025-08-11 moving to new infrastructure is on hold as we
discuss the core reasons for the migration.`.
The second thing is the reasons to move are quoted as "to move to an
enterprise based IT service". Does that mean all communication to the
support team will have to go through a ticket and there is no longer
any informal path at getting support for when hosting services and/or
network are broken? What if you can't get into the issue tracker? Also
who will get access to this issue tracker and be able to direct/steer
the issues? This piece seems to be very much missing from all of this
discussions.
Do you need to join the CTI and donate to get steer the direction? Or
is being part of the overall community enough?
There also does NOT seem to be a full thought out plan on which parts
and when will be the transition, rather this is just a statement again
on plan to do it. The FAQ on CTI does not answer this question either.
The frustrating parts is not just about LF IT but the way this whole
thing was handled and the messaging is happening. Especially when your
own FAQ and the messages from previous discussion seems to counter
this email.

Looking at the meeting minutes of CTI meetings, there was a few things
which seems to have done counter this email even.
October 29, 2025
(https://lore.kernel.org/cti-tac/efca566d-6826-44d5-a599-240e0d1353d1@redhat.com/):
  * Discussed the GNU Tools Cauldron 2025 glibc BoF discussion and the
use of CTI hardware.
First off that discussion finished off with we should discuss more on
the mailing list. And the slide from BoF mentioned CTI but there was
no discussion in the BoF itself (I watched the video over again)
rather Carlos deflected Mark's question.
  * Carlos to post to the glibc mailing list to raise infrastructure move again.
Is that what this email is? This seems a heavy handed way of raising it.

November 26, 2025:
  * Discussed if we had enough material discussions for weekly updates?
   * Yes, with enough material each week we can make the transition.
Huh? There has been no weekly updates at all to the glibc mailing list.
  * Noted that we need to continue to update the community, not every
quarter, but more frequently including weekly updates on CTI progress
to show the project continues to move forward.
This is the most frustrating part it was mentioned in your own meeting
you need to do weekly update but then nothing is done. It is exactly
why we are partly frusted here.
  * Suggest collaboration with Sourceware on specific projects?
   * Fold it into the main conversation?
   * Publicly invite Mark to have a role.
Why was the invite to Mark not done before this email push?
  * Carlos to post to the glibc mailing list to raise infrastructure move again.
I see this was again a todo list but again this was just to raise the
issue rather than say "we are moving".





Thanks,
Andrew Pinski




>
> In 2019 leadership from the GNU Toolchain started down a path that led
> to the Core Toolchain Infrastructure project. The project aims to move
> toolchain infrastructure issues forward; to provide a sustainable path
> forward for secure and state of the art infrastructure.
>
> Post-pandemic, since 2022 the GNU Toolchain has continued to move
> forward the state of the current infrastructure by engaging the
> developers, the projects, and a wider set of sponsors that can
> support a sustainable path forward for the toolchain.
>
> Key achievements:
>
>   2022 - Started using infrastructure provided by CTI like BigBlueButton
>          for meetings for the GNU Toolchain e.g. Weekly glibc patch
>          queue review and Monthly Office hours in two timezones.
>
>   2023 - Service enumeration for GNU Toolchain projects (gcc, glibc,
>          binutils, gdb).
>
>   2024 - Completed pricing and service contract negotiation for migration
>          with LF IT.
>
>   2025 - Completed GNU Toolchain and glibc documents to define secure
>          development requirements and the infrastructure needs.
>
> These steps were a necessary evolution and resulted in several critical
> milestones, e.g., service enumeration, secure development documents;
> which collectively paved the way for a sustainable path forward.
>
> While it was clear to the GNU Toolchain leadership that requirements
> were coming to improve the toolchain cyber-security posture, these
> requirements were not clear to all project developers. As part of
> receiving this feedback we have worked to document and define a secure
> development policy for glibc and at a higher level the GNU Toolchain.
> While Sourceware has started making some critical technical changes, the
> GNU Toolchain still faces serious, systemic concerns about securing a
> global, highly available service and building a sustainable, diverse
> sponsorship model. At the same time we are freeing up the GNU Toolchain
> developers and volunteers to focus on next-generation work, such as
> Sourceware’s post-commit CI and Forge-based workflows.
>
> The decision to leverage CTI and LF IT is the direct result of seeking a
> comprehensive, long-term solution to these exact challenges, expanding
> our sponsorship base and leveraging existing sponsors like the OpenSSF.
> The CTI TAC’s proposal to use Linux Foundation IT is rooted in the fact
> that they are an existing team in the industry that implements very
> similar functionality for the Linux kernel. The proposal directly
> benefits glibc developers. By partnering with a team that develops and
> understands FOSS tooling (b4, grokmirror and patatt) and large-scale
> kernel infrastructure. This partnership ensures our core infrastructure
> is secure and scalable.
>
> This sustainable path forward for glibc includes:
>
>   * A global robust and secure mirrored git repository for public clones
>     that supports robust CI/CD workflows for developers and downstream
>     distributions.
>
>   * A global robust and scalable email system leveraging existing
>     production deployments and reputation i.e. subspace.kernel.org.
>
>   * A continuous process of review for project requirements, FOSS usage,
>     security policy, and cost.
>
>   * A sustainable funding model for the infrastructure including a
>     diverse collection of sponsors to support various infrastructure
>     requirements now and in the future.
>
> While consensus for the move among GNU Maintainers for glibc is not
> unanimous, most of the maintainers endorse the move, and key developers
> have expressed their support in the upstream discussions. Additionally
> CTI has received a lot of feedback over the last 3 years as the project
> worked on infrastructure, and we include some of that feedback here and
> in our CTI FAQ [1] with comments.
>
> Some members of the community have expressed disappointment that funding
> would go to the Linux Foundation. Some members of the community have
> expressed concern that a board structure would allow corporate
> influence. Neither of these concerns are new and exist today with Red
> Hat and IBM, both being for-profit corporate entities. The GNU Toolchain
> leadership has a 30+ year history of successfully navigating the
> dynamics of working with sponsors and providing FOSS solutions,
> including meeting the GNU Ethical Repository hosting criteria.
>
> We invite all members of the glibc and GNU Toolchain community to join
> us in this important transition. Your insights, contributions, and
> feedback are essential to making CTI infrastructure a success that
> benefits everyone. Let's work together to build a more secure and
> sustainable future — reach out on libc-alpha@sourceware.org, participate
> in the weekly office hours, or propose ways to get involved. Let's
> collaborate to build a more resilient and sustainable infrastructure
> foundation for the GNU Toolchain.
>
> Action plan:
>
>   * Weekly office hours for CTI to provide an open space for discussion
>     of infrastructure improvements
>
>   * Work with LF IT to update the CY24 statement of work and discuss with
>     the glibc developers
>
>   * Work towards migrating glibc git and mailing lists as first priority
>     since these match our security priorities.
>
> Cheers,
> Carlos O’Donell
> GNU Maintainer for glibc
> Core Toolchain Infrastructure Project TAC member
> [1] https://cti.coretoolchain.dev/faq/index.html
>

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, David Edelsohn <dje.gcc@gmail.com> wrote:

> The leadership and developers of GLIBC and the GNU Toolchain are
> working in good faith for the best of the project.

I don't doubt that.  What I doubt, because of mounting evidence, is your
understanding of what free software is about.  The disregard and lack of
understanding of the problem of SaaSS is shining blindingly.

> CTI has ensured that it is conforming to the GNU Ethical repository hosting
> guidelines.

Like, why are you getting back to this particular point in response to
my concerns that you don't get SaaSS, if this retort has nothing
whatsoever to do with anything SaaSS.

To wit, holding and publishing data and mediating communication are
*not* SaaSS: they're not any particular individual's or group's
computing.

The problem is that, by interpreting "hosting" in expansive ways, as
proprietary/SaaSS providers have been doing to gain control over
projects hosted by them (I speak mainly of GitHub here), they encompass
in that term various computing activities that software development
communities should have control over, to avoid falling to the very
unjust power that the free software movement has fought since the '80s.

SaaSS may seem different because it can be implemented with free
software, but that's no relief when it is the service provider, not the
users whose computing is done, who gets the freedom.  The users, under
SaaSS, are even more overpowered by those who control the software than
if they used nonfree software on their own computers.

> GLIBC and the GNU Toolchain Project support the principles of the GNU
> Project, namely to develop and promote Free Software

And here again you're misdirecting.

That's only part of the GNU Project's principles.

What you're overlooking and dismissing, intentionally or not, is the
other part, namely that of promoting freedom by avoiding nonfree
software and SaaSS.

> The members of the GNU Project can have additional objectives
> and relationships with other developers and other organizations.

As long as they don't conflict with higher principles, which is the
problem at hand.

> The mission of the GNU Project shouldn't expand and shift based
> on the loudest voices

Not should it be betrayed by the more insistent subverters.

> The GNU Toolchain Project is operating
> with a clear, consistent set of principles.

Can you reassure me that it understands and avoids SaaSS?

If so, can you detail how that concern is being addressed?

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

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-28 11:53, Alexandre Oliva wrote:
> On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> I can assure you that if there's any hint of hostile manipulation of
>> control over infrastructure, we will step away.
> 
> And yet you don't take the "you'll get funds, but you can only use them
> to hire services under our own control" as a hint of hostile
> manipulation of control over infrastructure, so instead of walking away
> from the trap, you're jumping all in.

It's not because:

1. I don't view the Linux Foundation as a hostile adversary to the glibc 
project.

2. While I greatly respect the work Mark and Frank do (and will continue 
to rely on sourceware for workflow improvement ideas that we've done 
over, well, decades now) I see a strong need for a dedicated team to 
work full time to support critical infrastructure that glibc uses and a 
stable source of funding with the assurance that the hosting follows the 
GNU ethical hosting guidelines.

3. I consider Konstantin and his team to be excellent members of the 
larger FOSS community and am happy to have them support the 
infrastructure full time.

4. I have strong faith in our capacity as the CTI TAC to find 
alternatives and pull the plug on this if we find anything going even 
slightly sideways.

Sid

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> I see a strong need for a dedicated team to work full time to support
> critical infrastructure that glibc uses

Better look elsewhere, then, because the that dedicated team you're
thinking of already works full time to support critical infrastructure
for other projects that are more important to the LF than GNU libc.  And
if they're going to take in even more projects, their time will be
further divided.  If we need a full time team, we'd be heading down the
wrong path with this choice.

> and a stable source of funding with the assurance that
> the hosting follows the GNU ethical hosting guidelines.

How about SaaSS?

Can you tell which services, or which components thereof, that are being
proposed for hosting by the LF, are or aren't SaaSS?

Can you at least reassure me that this concern has been taken into
account?

> 4. I have strong faith in our capacity as the CTI TAC to find
> alternatives and pull the plug on this if we find anything going even 
> slightly sideways.

Would this require walking away from the stable funding?

Or could the funding be retained and redirected?

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

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-28 12:32, Alexandre Oliva wrote:
> On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> I see a strong need for a dedicated team to work full time to support
>> critical infrastructure that glibc uses
> 
> Better look elsewhere, then, because the that dedicated team you're
> thinking of already works full time to support critical infrastructure
> for other projects that are more important to the LF than GNU libc.  And
> if they're going to take in even more projects, their time will be
> further divided.  If we need a full time team, we'd be heading down the
> wrong path with this choice.

That's not how paid support contracts work, but I know that you know that :)

>> and a stable source of funding with the assurance that
>> the hosting follows the GNU ethical hosting guidelines.
> 
> How about SaaSS?
> 
> Can you tell which services, or which components thereof, that are being
> proposed for hosting by the LF, are or aren't SaaSS?
> 
> Can you at least reassure me that this concern has been taken into
> account?

I don't think claims of SaaSS violation are substantiated here, unless 
you claim that the "right" of sourceware overseers to administer systems 
that host the glibc project are being restricted, which is nonsense. 
Sourceware overseers != glibc project community, even though there is an 
overlap in individuals.  The infrastructure services will be all FOSS 
too, so there's no agenda here to push proprietary software under the hood.

>> 4. I have strong faith in our capacity as the CTI TAC to find
>> alternatives and pull the plug on this if we find anything going even
>> slightly sideways.
> 
> Would this require walking away from the stable funding?
> 
> Or could the funding be retained and redirected?
> 

We'll know in future when that happens but in the worst case it will 
likely mean walking away from the stable funding.

Sid

Re: CTI - Making a decision for glibc.

[Zack Weinberg]

On Tue, Jan 27, 2026, at 11:15 AM, Carlos O'Donell wrote:
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do
> this to meet the present and future needs of glibc and the GNU
> Toolchain. We want secure, robust, and sustainable infrastructure,
> balanced against the needs of developers and the community to
> collaborate and innovate, with reliable funding to support the
> infrastructure in the long term.

I had a strong opinion about this the last time it was brought up, so it
seems to me I should express some kind of opinion again.  I have not
been closely following either this subject or glibc development in
general for quite a while, so my opinion is less well-formed, but I do
still have one, and it is that I still don't think the move should
go forward, because:

1. It's my impression that there are a small number of people (Carlos
   O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
   who feel strongly that glibc should move off of sourceware.org, and
   *everyone else* with a stake in the matter is somewhere on a spectrum
   between neutral and a strong belief that glibc *shouldn't* move, or
   at least, should not move to infrastructure hosted by the Linux
   Foundation.

   *Whenever* you have a small group of people trying to push a change
   that a larger group of people feels indifferently to negatively
   toward, the onus is on the small group to make the case for the
   change, and only when the larger group's opinion has shifted to
   "positive to indifferent" should the change proceed.

2. I have never seen what I'd consider to be an adequate explanation for
   *why* O'Donell, Edelsohn, and Myers feel so strongly that glibc needs
   to move.  This paragraph of the announcement...

> were coming to improve the toolchain cyber-security posture, these
> requirements were not clear to all project developers. As part of
> receiving this feedback we have worked to document and define a secure
> development policy for glibc and at a higher level the GNU Toolchain.
> While Sourceware has started making some critical technical changes,
> the GNU Toolchain still faces serious, systemic concerns about
> securing a global, highly available service and building a
> sustainable, diverse sponsorship model. At the same time we are
> freeing up the GNU Toolchain developers and volunteers to focus on next-
> generation work, such as Sourceware’s post-commit CI and Forge-based
> workflows.

   ...*states* that concrete concerns exist, that they have been raised
   with the sourceware maintainers, and not addressed to the proponents'
   satisfaction -- but it *doesn't say what the concerns actually are*,
   nor does it say where I could find more detail.

   Myers has raised a few concrete technical concerns in the past, and
   again in this very thread, but it seemed to me that all of them
   should be straightforward to solve in the existing setup and that
   that should be *less* work than moving the whole megillah to new
   hosting.  Now, perhaps he did try to get them solved in the existing
   setup, and couldn't, but then he should have said *that*, and
   explained why it was intractable.  Conversely, Mark Wielaard has
   repeatedly said that he stands ready to assist the glibc community
   with any problems they have with sourceware, but (as I understand it)
   that no one has actually asked him for help.

   Meanwhile, glibc is a small project, and as far as I can tell, the
   recent DDoS attacks were the only time in *decades* where
   sourceware.org's services were inadequate to the load.  A big
   disruptive change like transferring hosting to an entirely different
   provider requires a big reason.  It may well be that there are
   excellent reasons, technical or otherwise, why a move off of
   sourceware is a really good idea.  Please!  Explain those reasons.
   Be candid.  Be detailed.  Let the rest of us understand your
   thinking.  Because right now, knowing only what I know, it seems to
   me that a move is *unnecessary*.

3. My final reason is closely related to the previous paragraph: You say

> While consensus for the move among GNU Maintainers for glibc is not
> unanimous, most of the maintainers endorse the move, and key
> developers have expressed their support in the upstream discussions.

   I have not seen any such endorsements or expressions of support,
   because, despite what I said last time, you (proponents) have
   continued to push for this move exclusively via backchannels.
   And that is just plain not acceptable.

   Consensus for this move needs to be sought IN PUBLIC.  In public
   means ON THIS MAILING LIST and nowhere else.  Consensus needs to be
   *achieved* among the entire community of glibc developers, not just
   the people who can afford to make it to the Cauldron conferences.

   Additionally, I don't even know which of the core glibc developers
   are or are not "GNU Maintainers for glibc".  That is a narrowly
   scoped role which has very little to do with who's actually doing
   all the work.  Consensus for a change this large needs to come from,
   again, the entire community of developers.

zw

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> On 2026-01-28 12:32, Alexandre Oliva wrote:
>> On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>> 
>>> I see a strong need for a dedicated team to work full time to support
>>> critical infrastructure that glibc uses
>> Better look elsewhere, then, because the that dedicated team you're
>> thinking of already works full time to support critical infrastructure
>> for other projects that are more important to the LF than GNU libc.  And
>> if they're going to take in even more projects, their time will be
>> further divided.  If we need a full time team, we'd be heading down the
>> wrong path with this choice.

> That's not how paid support contracts work, but I know that you know that :)

Yeah, and that's exactly my point.  If "the strong need for a dedicated
team to work full time to support critical infrastructure that glibc
uses" is there, then getting a support team that will at best devote a
small fraction of their time to glibc's needs is not it.  It's not even
evident that it would be any better than the situation we have now.
It's an argument that may sound good, but that doesn't offer any support
to what you think it does.  Like all of the other arguments that have
been put forth so far.

>>> and a stable source of funding with the assurance that
>>> the hosting follows the GNU ethical hosting guidelines.
>> How about SaaSS?
>> Can you tell which services, or which components thereof, that are
>> being
>> proposed for hosting by the LF, are or aren't SaaSS?
>> Can you at least reassure me that this concern has been taken into
>> account?

> I don't think claims of SaaSS violation are substantiated here

They don't need to be at this point in which I'm only asking *whether*
the issue was taken into account.

The problem is that hosting arrangements are very diverse in nature, and
while some of them are not SaaSS, many of them are, so unless you are
aware and paying attention to the matter, odds are you will end up in a
SaaSS situation.

Unfortunately, the hand-waving and reflection I've consistently got from
*everyone* involved in this project hasn't inspired any confidence, it
has only raised concerns that we'll end up in a situation in which free
software is deployed to render computing services for us, but that free
software runs under someone else's control, so it won't be free software
for us.

SaaSS is a common trap that people who come more from the open source
side often fall for, because open source hasn't realized (or hasn't
cared) that denying users control over their computing by controlling
the otherwise-free programs in their deployment setting, so that the
operators get the freedoms but the users don't, has an even worse end
result for the users' freedom than denying users control through NDAs or
restrictive copyrights.

Free Software philosophy, however, for its focus since its inception on
users' control of the software used to do their computing, both
individually and collectively, has long recognized this practice as yet
another attack vector on users' freedom.

We, collectively, are the users, when it comes to the computing done for
the GNU libc package.  If we handed control over our own computing (*)
to a third party, we would be doing exactly what the free software
movement has always said we shouldn't do.

(*) publishing and communication, by themselves, are not regarded as our
own computing, under free software philosophy pertaining to SaaSS,
because they always necessarily involve third parties; it's other
computing activities that are our own that are my concern.

> unless you claim that the "right" of sourceware overseers to
> administer systems that host the glibc project are being restricted,

Nope, that's not it.  It has nothing to do with sourceware.  It has to
do with our collective control over our project's computing.

You may consider the LF friendly and servient, so you can't fathom that,
today, it might act, or refuse to act, in a way that deviates from the
determinations of our community, or even of a self-appointed committee
that represented our community.

But that you consider it friendly and servient today doesn't make it
true today (I'm not going to argue that opinion though); more
importantly, it doesn't make it so in the future.  Things change, and if
you didn't think of ensuring you retained control over your computing
during friendlier times, you're going to pay dearly when they change,
you become hostage, and you find it's too late to get control back.

Just like people say one should write laws thinking of how your worst
enemies would use them against you once they got in power, you should
think of computing services as if your worst enemies would some day get
in charge of rendering those services to you.

If you don't like that picture, in which your worst enemies take over
the hosting services you're considering handing to the LF, if you think
you'd worry about it then, you'd better worry about keeping control now.

Because if the funds cannot be used elsewhere as you say, that *will* be
used against us for us to accept progressively worse conditions (surely
you've heard of enshittification; what you may not have heard is that
software freedom is the antidote and the vaccine against it).

We don't want to wait until our data and our key services are hostage
and we're trying to figure out whether we can give up the funds and the
services, and how we're going to exfiltrate our data, to think about our
freedom.  We should think about it first and foremost.

> The infrastructure services will be all FOSS too, so there's no agenda
> here to push proprietary software under the hood.

Are you taking into account, in this statement, that SaaSS deployments
turn free software into nonfree software for the relevant users,
ourselves?

> We'll know in future when that happens but in the worst case it will
> likely mean walking away from the stable funding.

And you don't consider that bait manipulative at all?!?

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

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-28 16:45, Zack Weinberg wrote:
> 1. It's my impression that there are a small number of people (Carlos
>     O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
>     who feel strongly that glibc should move off of sourceware.org, and
>     *everyone else* with a stake in the matter is somewhere on a spectrum
>     between neutral and a strong belief that glibc *shouldn't* move, or
>     at least, should not move to infrastructure hosted by the Linux
>     Foundation.

If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph 
Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and 
Andreas Huettel who have vocally supported the move in this thread, 
while many others (who I hope will chime in too) who contribute on a day 
to day basis, have expressed support offline in the past.  Your base 
characterization of the situation is flawed I'm afraid.

Sid

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Wed, Jan 28, 2026 at 2:13 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 2026-01-28 16:45, Zack Weinberg wrote:
> > 1. It's my impression that there are a small number of people (Carlos
> >     O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
> >     who feel strongly that glibc should move off of sourceware.org, and
> >     *everyone else* with a stake in the matter is somewhere on a spectrum
> >     between neutral and a strong belief that glibc *shouldn't* move, or
> >     at least, should not move to infrastructure hosted by the Linux
> >     Foundation.
>
> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph
> Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and
> Andreas Huettel who have vocally supported the move in this thread,
> while many others (who I hope will chime in too) who contribute on a day
> to day basis, have expressed support offline in the past.  Your base
> characterization of the situation is flawed I'm afraid.

Let me speak up on why sometimes the characterization of the
situtation gets flawed here.
The issue is hosting on sourceware vs LF IT doing the hosting is being
conflated with the security side of things.
And the only side that is doing that conflated is the side that has
been very vocal on moving to LT IT.

So let's step back both sides on this and talk about one thing and
only one thing. That is the hosting of glibc project.
Security issues do have dependency on which side is chosen to some
extent. BUT from the contract of CTI and LF IT before it was still
most of the heavy lifting was going to be the community rather than
the LF IT.
Which brings up another point why LF IT why not LLVM foundation IT (if
it exists any more)? Or say Rust foundation or Mozilla foundation IT?
It was seemed like there was only one choice and ever once one choice.
Why not use FSF IT instead?

Also I am still wondering about this statement what changed after it:
As of 2025-08-11 moving to new infrastructure is on hold as we discuss
the core reasons for the migration.

yes I saw this:
As of 2025-08-19 an evaluation of glibc moving from git to gitolite is
in progress.
But that can be done with any hosting including sourceware.
So the bigger question what forced this statement.
Which also gives way to this from
https://lore.kernel.org/cti-tac/3b1aaa90-9b46-4ce3-9209-4b9c358107d9@redhat.com/:
  * Carlos to post to the glibc mailing list to raise infrastructure move again.

From https://lore.kernel.org/cti-tac/4c7f3274-1c2d-4ae6-935a-5ceb656d71c4@redhat.com/
  * Disucssed 5 whys and why we're still on existing infrastructure
versus a transition.

So what is the 5 whys?

Thanks,
Andrew






>
> Sid

Re: CTI - Making a decision for glibc.

[DJ Delorie]

I don't really have a dog in this fight, but...

Alexandre Oliva <oliva@gnu.org> writes:
> This is not about the hosting service per se,
> it's about the hostility of the hosting provider.

The only hostility I sense here is you using overly-strong words to make
anyone who doesn't agree with your version of reality "evil".  Please
stop it.  We all have the same general goal, but we all have different
ideas on how to achieve that goal.  Please be respectful of all
involved, including LF.

> merely communication and publishing, they're computing, and, when
> performed by a third party, amount to SaaSS (Service as a Software
> Substitute), a malpractice that is worse than proprietary software to
> the user whose computing is so done.

Based on RMS's definition of SaaSS, Sourceware is also SaaSS, so we
should immediately move off it.  Thanks for the warning!

And before you say I'm wrong... RMS has explicitly asked me to stop
running gcc-as-a-service on my web site, and that's GNU.  It has nothing
to do with "propriatary" and everything to do with whether someone
else's computer is running the software you use.  Which is the whole
*purpose* of Sourceware.

And yes, I see the irony here.  If the need to avoid SaaSS is absolute,
it becomes impossible to collaborate on the internet.

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-28 16:59, Alexandre Oliva wrote:
>> That's not how paid support contracts work, but I know that you know that :)
> 
> Yeah, and that's exactly my point.  If "the strong need for a dedicated
> team to work full time to support critical infrastructure that glibc
> uses" is there, then getting a support team that will at best devote a
> small fraction of their time to glibc's needs is not it.  It's not even
> evident that it would be any better than the situation we have now.
> It's an argument that may sound good, but that doesn't offer any support
> to what you think it does.  Like all of the other arguments that have
> been put forth so far.

You're continuing to pretend that full time paid support contracts are 
the same as volunteer support, so I don't think we have a way to reach 
an agreement here.

>> I don't think claims of SaaSS violation are substantiated here
> 
> They don't need to be at this point in which I'm only asking *whether*
> the issue was taken into account.
> 
> The problem is that hosting arrangements are very diverse in nature, and
> while some of them are not SaaSS, many of them are, so unless you are
> aware and paying attention to the matter, odds are you will end up in a
> SaaSS situation.
> 
> Unfortunately, the hand-waving and reflection I've consistently got from
> *everyone* involved in this project hasn't inspired any confidence, it
> has only raised concerns that we'll end up in a situation in which free
> software is deployed to render computing services for us, but that free
> software runs under someone else's control, so it won't be free software
> for us.
> 
> SaaSS is a common trap that people who come more from the open source
> side often fall for, because open source hasn't realized (or hasn't
> cared) that denying users control over their computing by controlling
> the otherwise-free programs in their deployment setting, so that the
> operators get the freedoms but the users don't, has an even worse end
> result for the users' freedom than denying users control through NDAs or
> restrictive copyrights.
> 
> Free Software philosophy, however, for its focus since its inception on
> users' control of the software used to do their computing, both
> individually and collectively, has long recognized this practice as yet
> another attack vector on users' freedom.
> 
> We, collectively, are the users, when it comes to the computing done for
> the GNU libc package.  If we handed control over our own computing (*)
> to a third party, we would be doing exactly what the free software
> movement has always said we shouldn't do.
> 
> (*) publishing and communication, by themselves, are not regarded as our
> own computing, under free software philosophy pertaining to SaaSS,
> because they always necessarily involve third parties; it's other
> computing activities that are our own that are my concern.
> 
>> unless you claim that the "right" of sourceware overseers to
>> administer systems that host the glibc project are being restricted,
> 
> Nope, that's not it.  It has nothing to do with sourceware.  It has to
> do with our collective control over our project's computing.
> 
> You may consider the LF friendly and servient, so you can't fathom that,
> today, it might act, or refuse to act, in a way that deviates from the
> determinations of our community, or even of a self-appointed committee
> that represented our community.
> 
> But that you consider it friendly and servient today doesn't make it
> true today (I'm not going to argue that opinion though); more
> importantly, it doesn't make it so in the future.  Things change, and if
> you didn't think of ensuring you retained control over your computing
> during friendlier times, you're going to pay dearly when they change,
> you become hostage, and you find it's too late to get control back.
> 
> Just like people say one should write laws thinking of how your worst
> enemies would use them against you once they got in power, you should
> think of computing services as if your worst enemies would some day get
> in charge of rendering those services to you.
> 
> If you don't like that picture, in which your worst enemies take over
> the hosting services you're considering handing to the LF, if you think
> you'd worry about it then, you'd better worry about keeping control now.
> 
> Because if the funds cannot be used elsewhere as you say, that *will* be
> used against us for us to accept progressively worse conditions (surely
> you've heard of enshittification; what you may not have heard is that
> software freedom is the antidote and the vaccine against it).
> 
> We don't want to wait until our data and our key services are hostage
> and we're trying to figure out whether we can give up the funds and the
> services, and how we're going to exfiltrate our data, to think about our
> freedom.  We should think about it first and foremost.
> 
>> The infrastructure services will be all FOSS too, so there's no agenda
>> here to push proprietary software under the hood.
> 
> Are you taking into account, in this statement, that SaaSS deployments
> turn free software into nonfree software for the relevant users,
> ourselves?
> 
>> We'll know in future when that happens but in the worst case it will
>> likely mean walking away from the stable funding.
> 
> And you don't consider that bait manipulative at all?!?

I consider your comments manipulative at the moment because you're 
forcing analogies and doomsday scenarios to try and make a point. 
That's fine because you too are trying to negotiate a position, but 
unfortunately your point is still not coercive enough to be taken 
seriously.  The side-effect though is that you continually trying to 
stretch Free Software talking points in this manner only contributes to 
trivializing it and in the FSF conceding ground to other FOSS foundations.

Sid

Re: CTI - Making a decision for glibc.

[Andreas K. Huettel]

> 
> Based on RMS's definition of SaaSS, Sourceware is also SaaSS, so we
> should immediately move off it.  Thanks for the warning!
> 
> And before you say I'm wrong... RMS has explicitly asked me to stop
> running gcc-as-a-service on my web site, and that's GNU.  It has nothing
> to do with "propriatary" and everything to do with whether someone
> else's computer is running the software you use.  Which is the whole
> *purpose* of Sourceware.
> 
> And yes, I see the irony here.  If the need to avoid SaaSS is absolute,
> it becomes impossible to collaborate on the internet.

Not everyone cares what RMS thinks.

-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail mail@akhuettel.de
http://www.akhuettel.de/

Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Andreas K. Huettel]

> Rendering control over a key piece of GNU to a hostile party is
> obviously not being done for GNU's benefit, for GNU's sake, on its
> behalf, or even in agreement with GNU leadership. 

Please forgive my ignorance, but... What's so horrible about the 
Linux Foundation?

The whole discussion feels a bit like "People's Front of Judea versus
Judean People's Front".

Please remember, we're doing software here, not fundamentalist 
sectarianism.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> You're continuing to pretend that full time paid support contracts are
> the same as volunteer support

I'm not.  I'm merely pointing out that our alleged "full time support"
needs can't be met by any contractor whose dedication is not full time
devoted exclusively to our project.  Either the needs are for full time
support, or a part-time contractor or volunteer may be as enough as a
full-time contractor with divided dedication.  You can't have both.

> I consider your comments manipulative at the moment because you're
> forcing analogies and doomsday scenarios to try and make a point. 

Enshittification is inevitable when you don't keep your freedom.
Keeping our freedom is the only known way to avoid doomsday under
current circumstances.  You seem determined to defy that, in the hope of
not getting hurt in the process.  That's a foolish pursuit.

> The side-effect though is that you continually trying to
> stretch Free Software talking points

I'm not.  Again, your lack of knowledge of free software philosophy and
GNU principles doesn't make what I'm saying a stretch.  It's the same
foundational principle, it is widely documented in Free Software
philosophy writings.

Maybe this time you should read and understand these pieces:

https://web.archive.org/web/20260122093930/https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html
https://web.archive.org/web/20260106003257/http://www.gnu.org/philosophy/who-does-that-server-really-serve.html

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, DJ Delorie <dj@redhat.com> wrote:

> Sourceware is also SaaSS

I believe that's correct, overall.  It is concerning indeed.

AFAIK we (glibc) are not using any of its SaaSSs.

> so we should immediately move off it

If we are using any of its SaaSSs, discontinuing their use is probably
much saner than rushing to move out, especially to a provider that would
make that worse.

> running gcc-as-a-service on my web site

Yeah, that sounds like SaaSS to me.

> It has nothing to do with "propriatary" and everything to do with
> whether someone else's computer is running the software you use.

It's not so much about whose computer it is, but about who has control
over it.

Using a rented computer from a VPS is not SaaSS, if you control it.

Hiring services controlled by others to do your own computing is SaaSS.

Publishing a GIT repository (publishing) or hosting a mailing list
(communication and publishing) are not SaaSS.

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

Running your CI on a third party-controlled server is SaaSS.  (whereas a
third party running its own CI under its own control and sharing results
with the community is not SaaSS)

Hosting and publishing data is probably not SaaSS, but processing
queries on a database could be.

Authentication and digital signing services could be SaaSS depending on
the deployment and on whose computing they perform.

> If the need to avoid SaaSS is absolute, it becomes impossible to
> collaborate on the internet.

That sounds like a common mischaracterization of SaaSS, from people who
don't really understand it, and generally don't care about control over
one's own computing (which is free software movement's raison d'être) to
the point of realizing the SaaSS prevents that control, whereas various
forms of collaboration on the Internet aren't any of the participant's
own computing, but the group of participant's computing.

Is this your case, maybe?

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

Re: CTI - Making a decision for glibc.

[Carlos O'Donell]

On 1/28/26 5:26 PM, Andrew Pinski wrote:
> On Wed, Jan 28, 2026 at 2:13 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2026-01-28 16:45, Zack Weinberg wrote:
>>> 1. It's my impression that there are a small number of people (Carlos
>>>      O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
>>>      who feel strongly that glibc should move off of sourceware.org, and
>>>      *everyone else* with a stake in the matter is somewhere on a spectrum
>>>      between neutral and a strong belief that glibc *shouldn't* move, or
>>>      at least, should not move to infrastructure hosted by the Linux
>>>      Foundation.
>>
>> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph
>> Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and
>> Andreas Huettel who have vocally supported the move in this thread,
>> while many others (who I hope will chime in too) who contribute on a day
>> to day basis, have expressed support offline in the past.  Your base
>> characterization of the situation is flawed I'm afraid.
> 
> Let me speak up on why sometimes the characterization of the 
> situtation gets flawed here. The issue is hosting on sourceware vs
> LF IT doing the hosting is being conflated with the security side of
> things. And the only side that is doing that conflated is the side
> that has been very vocal on moving to LT IT.

A proposal should consider multiple factors.

(1) Security.

We could solve security with any FOSS-based solution so long as those
solutions meet our SSDLC.

In fact in the SSDLC for glibc I note that we'll continue to use
the GNU Project services for uploading signed binary artifacts
because it is a requirement of the GNU Project and it is a well
designed robust, isolated, and simple system.

It isn't the best we can do, but it's good enough to recommend and
changing that process requires more conversations with the GNU Project
and project developers. CTI is not a governance or workflow change.

Solving security issues is still a *timely* problem as downstreams
continue to ask questions about robustness and availability along with
security. We want the ecosystem to trust FOSS-based solutions, and
to use them first.

(2) Sponsorship.

We are looking for a straight forward mechanism to fund infrastructure
by reaching out to the largest companies that benefit directly downstream
from GNU Toolchain development.

Those sponsors including AMD, arm, IBM, Intel, NVIDIA, Oracle, Red Hat,
Qualcomm, are all part of the Linux Foundation (a chamber of commerce),
and so no matter the IT team we'd still likely create an Associated
Directed Fund at the LF to gather sponsorship.

I am one of 3 trustees in the GNU Toolchain Fund at the FSF, but there
is not enough money there to fund this type of initiative in the long
run. We need larger corporate sponsors.

David Edelsohn, Joel Brobekcer, and I know how hard it is to get real
money on the table, and I'm empathetic with Sourceware's work with the
SFC to raise funds.

Lastly, we could attempt to route more funding to either the FSF or
the SFC, but both are US charities. This means that the donations are
arms length, which means we can't say "this money shall be used for
X" and instead the charity decides what to do with the funds against
their charitable mission. Now, the distinction is germane because
while the FSF has been amazing at helping us run the GNU Toolchain
Fund, what is harder is convincing other large sponsors, that might
not have the same relationship, to give a fully charitable donation.
In the context of an LF ADF, we have a charter, and sponsors can be
fiscally accountable for the spend. The distinction is real and some
sponsors prefer it because they can say "We spent directly on X to
improve security." rather than "We donated to a charity."

(3) Experience.

Whoever implements the solution should have experience with FOSS-based
solutions.

LLVM Foundation, and I've talked to Tom Stellard about them, is using
Github, and that doesn't match our community values.

Rust Foundation, and I've talked to Josh Stone about their development
process, is using Github, and that doesn't match our community values.

Mozilla Foundation is struggling and also uses Github for all of their
official repositories as far as I know, and that doesn't match our
community values.

If you look across the landscape, many projects turn towards the lowest
cost and simplest path of using Github, or Gitlab, and that isn't a
direction aligned with our values.

FOSS using IT teams today include LF IT, Sourceware and probably the
Fedora Community Infrastructure team, along with downstream distros
and many more self-hosted companies.

The teams with the longest established records are probably Sourceware,
FSF IT/GNU Project, and LF IT.

I have excluded the distribution teams because I expect this would put
a disproportionate load on their volunteers and I expect the larger
distributions should support the toolchain financially (see (2)).

> So let's step back both sides on this and talk about one thing and 
> only one thing. That is the hosting of glibc project. Security
> issues do have dependency on which side is chosen to some extent.
> BUT from the contract of CTI and LF IT before it was still most of
> the heavy lifting was going to be the community rather than the LF
> IT. Which brings up another point why LF IT why not LLVM foundation
> IT (if it exists any more)? Or say Rust foundation or Mozilla
> foundation IT? It was seemed like there was only one choice and ever
> once one choice. Why not use FSF IT instead?

The LF IT contract had two parts:

  (1) Moving the infrastructure from Sourceware to LF IT.

  (2) Operation of the services.

The community has to be involved in (1) to make sure it goes smoothly.

When it comes to (2), we aren't doing any heavy lifting, and we're back
to operation as normal, but with paid IT, the benefits as discussed,
and our normal workflows.

You ask "Why LF IT?" see the combination of (1)(2)(3).

My position is that for the level of infrastructure spending we need
it's hard to get fully charitable donations, so in combination it is
simpler to use a chamber of commerce structure, followed by a team
already at the chamber of commerce that meets our requirements.
  
> Also I am still wondering about this statement what changed after it:
> As of 2025-08-11 moving to new infrastructure is on hold as we discuss
> the core reasons for the migration.

I have finished writing SSDLC's with requirements for glibc:
https://inbox.sourceware.org/libc-alpha/4e9f65ea-a1bf-4d69-9dd5-63aa301f0b42@redhat.com/

We have started using the SSDLC, for example to raise issue with
Sourceware's current operations:
https://inbox.sourceware.org/overseers/d894fead-dff1-46c5-9b1f-8a5dade9b986@redhat.com/

I also wrote a comparison of Sourceware's checklist to the recommendations for glibc:
https://sourceware.org/glibc/wiki/SSDLC/Policy/Sourceware

Again, this only considers (1), not (2) or (3).

> yes I saw this:
> As of 2025-08-19 an evaluation of glibc moving from git to gitolite is
> in progress.
> But that can be done with any hosting including sourceware.

Which doesn't consider the sustainability of the solution, or the robustness
or availability?

Frank said Sourceware has $0 for operations and capital spending:
https://inbox.sourceware.org/overseers/20251029171555.GB21228@redhat.com/

See (2).

> Which also gives way to this from
> https://lore.kernel.org/cti-tac/3b1aaa90-9b46-4ce3-9209-4b9c358107d9@redhat.com/:
>    * Carlos to post to the glibc mailing list to raise infrastructure move again.
> 
>  From https://lore.kernel.org/cti-tac/4c7f3274-1c2d-4ae6-935a-5ceb656d71c4@redhat.com/
>    * Disucssed 5 whys and why we're still on existing infrastructure
> versus a transition.
> 
> So what is the 5 whys?
The "5 Whys" is a technique to arrive at the root cause of something.

Why are we still using Sourceware infrastructure?
1. Because we still had some questions to answer around defining an SDLC.
Why?
2. To go through the steps of evaluating more of the project life-cycle and requirements.
Why?
3. To determine if there are other requirements we didn't consider.
Why?
4. The requirements might change our choice of IT team or sponsors.
Why?
5. Because we want to make lasting durable choice.

-- 
Cheers,
Carlos.

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Wed, Jan 28, 2026 at 4:00 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 1/28/26 5:26 PM, Andrew Pinski wrote:
> > On Wed, Jan 28, 2026 at 2:13 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> >>
> >> On 2026-01-28 16:45, Zack Weinberg wrote:
> >>> 1. It's my impression that there are a small number of people (Carlos
> >>>      O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
> >>>      who feel strongly that glibc should move off of sourceware.org, and
> >>>      *everyone else* with a stake in the matter is somewhere on a spectrum
> >>>      between neutral and a strong belief that glibc *shouldn't* move, or
> >>>      at least, should not move to infrastructure hosted by the Linux
> >>>      Foundation.
> >>
> >> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph
> >> Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and
> >> Andreas Huettel who have vocally supported the move in this thread,
> >> while many others (who I hope will chime in too) who contribute on a day
> >> to day basis, have expressed support offline in the past.  Your base
> >> characterization of the situation is flawed I'm afraid.
> >
> > Let me speak up on why sometimes the characterization of the
> > situtation gets flawed here. The issue is hosting on sourceware vs
> > LF IT doing the hosting is being conflated with the security side of
> > things. And the only side that is doing that conflated is the side
> > that has been very vocal on moving to LT IT.
>
> A proposal should consider multiple factors.
>
> (1) Security.
>
> We could solve security with any FOSS-based solution so long as those
> solutions meet our SSDLC.
>
> In fact in the SSDLC for glibc I note that we'll continue to use
> the GNU Project services for uploading signed binary artifacts
> because it is a requirement of the GNU Project and it is a well
> designed robust, isolated, and simple system.
>
> It isn't the best we can do, but it's good enough to recommend and
> changing that process requires more conversations with the GNU Project
> and project developers. CTI is not a governance or workflow change.
>
> Solving security issues is still a *timely* problem as downstreams
> continue to ask questions about robustness and availability along with
> security. We want the ecosystem to trust FOSS-based solutions, and
> to use them first.
>
> (2) Sponsorship.
>
> We are looking for a straight forward mechanism to fund infrastructure
> by reaching out to the largest companies that benefit directly downstream
> from GNU Toolchain development.
>
> Those sponsors including AMD, arm, IBM, Intel, NVIDIA, Oracle, Red Hat,
> Qualcomm, are all part of the Linux Foundation (a chamber of commerce),
> and so no matter the IT team we'd still likely create an Associated
> Directed Fund at the LF to gather sponsorship.
>
> I am one of 3 trustees in the GNU Toolchain Fund at the FSF, but there
> is not enough money there to fund this type of initiative in the long
> run. We need larger corporate sponsors.
>
> David Edelsohn, Joel Brobekcer, and I know how hard it is to get real
> money on the table, and I'm empathetic with Sourceware's work with the
> SFC to raise funds.
>
> Lastly, we could attempt to route more funding to either the FSF or
> the SFC, but both are US charities. This means that the donations are
> arms length, which means we can't say "this money shall be used for
> X" and instead the charity decides what to do with the funds against
> their charitable mission. Now, the distinction is germane because
> while the FSF has been amazing at helping us run the GNU Toolchain
> Fund, what is harder is convincing other large sponsors, that might
> not have the same relationship, to give a fully charitable donation.
> In the context of an LF ADF, we have a charter, and sponsors can be
> fiscally accountable for the spend. The distinction is real and some
> sponsors prefer it because they can say "We spent directly on X to
> improve security." rather than "We donated to a charity."
>
> (3) Experience.
>
> Whoever implements the solution should have experience with FOSS-based
> solutions.
>
> LLVM Foundation, and I've talked to Tom Stellard about them, is using
> Github, and that doesn't match our community values.
>
> Rust Foundation, and I've talked to Josh Stone about their development
> process, is using Github, and that doesn't match our community values.
>
> Mozilla Foundation is struggling and also uses Github for all of their
> official repositories as far as I know, and that doesn't match our
> community values.
>
> If you look across the landscape, many projects turn towards the lowest
> cost and simplest path of using Github, or Gitlab, and that isn't a
> direction aligned with our values.
>
> FOSS using IT teams today include LF IT, Sourceware and probably the
> Fedora Community Infrastructure team, along with downstream distros
> and many more self-hosted companies.
>
> The teams with the longest established records are probably Sourceware,
> FSF IT/GNU Project, and LF IT.
>
> I have excluded the distribution teams because I expect this would put
> a disproportionate load on their volunteers and I expect the larger
> distributions should support the toolchain financially (see (2)).
>
> > So let's step back both sides on this and talk about one thing and
> > only one thing. That is the hosting of glibc project. Security
> > issues do have dependency on which side is chosen to some extent.
> > BUT from the contract of CTI and LF IT before it was still most of
> > the heavy lifting was going to be the community rather than the LF
> > IT. Which brings up another point why LF IT why not LLVM foundation
> > IT (if it exists any more)? Or say Rust foundation or Mozilla
> > foundation IT? It was seemed like there was only one choice and ever
> > once one choice. Why not use FSF IT instead?
>
> The LF IT contract had two parts:
>
>   (1) Moving the infrastructure from Sourceware to LF IT.
>
>   (2) Operation of the services.
>
> The community has to be involved in (1) to make sure it goes smoothly.
>
> When it comes to (2), we aren't doing any heavy lifting, and we're back
> to operation as normal, but with paid IT, the benefits as discussed,
> and our normal workflows.

There is something which you missed from my previous email which ties
into (1) and (2). Here.
What is the support path? From say someone in the community noticing
something is not working to LF IT?
This is just as important as figuring out if moving and using LF IT
(or anyone else really). Right now there
is both a form path via bugzilla infstructure issues and an inform one
via email and IRC. This is really important when stuff comes up like
the recent AI bot scrappers attacks. And it is also important when
there has been in the past with locks needing to be removed (e.g. git
locks up in some cases due to large number of commits due to the
post-recievce hooks).
Does it need to go to CTI (or a representative) first or is there a
direct line for all community members? That is the bigger question and
part of the problem I see with the out sourceing of IT support here.
Also is there future cost of including new infrastrcture needs in?
Like say a new bugzilla instance or a forge that has been already
planned out.


>
> You ask "Why LF IT?" see the combination of (1)(2)(3).
>
> My position is that for the level of infrastructure spending we need
> it's hard to get fully charitable donations, so in combination it is
> simpler to use a chamber of commerce structure, followed by a team
> already at the chamber of commerce that meets our requirements.
>
> > Also I am still wondering about this statement what changed after it:
> > As of 2025-08-11 moving to new infrastructure is on hold as we discuss
> > the core reasons for the migration.
>
> I have finished writing SSDLC's with requirements for glibc:
> https://inbox.sourceware.org/libc-alpha/4e9f65ea-a1bf-4d69-9dd5-63aa301f0b42@redhat.com/
>
> We have started using the SSDLC, for example to raise issue with
> Sourceware's current operations:
> https://inbox.sourceware.org/overseers/d894fead-dff1-46c5-9b1f-8a5dade9b986@redhat.com/
>
> I also wrote a comparison of Sourceware's checklist to the recommendations for glibc:
> https://sourceware.org/glibc/wiki/SSDLC/Policy/Sourceware
>
> Again, this only considers (1), not (2) or (3).
>
> > yes I saw this:
> > As of 2025-08-19 an evaluation of glibc moving from git to gitolite is
> > in progress.
> > But that can be done with any hosting including sourceware.
>
> Which doesn't consider the sustainability of the solution, or the robustness
> or availability?
>
> Frank said Sourceware has $0 for operations and capital spending:
> https://inbox.sourceware.org/overseers/20251029171555.GB21228@redhat.com/
>
> See (2).
>
> > Which also gives way to this from
> > https://lore.kernel.org/cti-tac/3b1aaa90-9b46-4ce3-9209-4b9c358107d9@redhat.com/:
> >    * Carlos to post to the glibc mailing list to raise infrastructure move again.
> >
> >  From https://lore.kernel.org/cti-tac/4c7f3274-1c2d-4ae6-935a-5ceb656d71c4@redhat.com/
> >    * Disucssed 5 whys and why we're still on existing infrastructure
> > versus a transition.
> >
> > So what is the 5 whys?
> The "5 Whys" is a technique to arrive at the root cause of something.
>
> Why are we still using Sourceware infrastructure?
> 1. Because we still had some questions to answer around defining an SDLC.
> Why?
> 2. To go through the steps of evaluating more of the project life-cycle and requirements.
> Why?
> 3. To determine if there are other requirements we didn't consider.
> Why?
> 4. The requirements might change our choice of IT team or sponsors.
> Why?
> 5. Because we want to make lasting durable choice.
>
> --
> Cheers,
> Carlos.
>

Clarification Re: CTI - Making a decision for glibc.

[Frank Ch. Eigler]

Hi -


> Frank said Sourceware has $0 for operations and capital spending:
> https://inbox.sourceware.org/overseers/20251029171555.GB21228@redhat.com/

That is a misquote.  Sourceware HAS $ for future needs.  Sourceware
currently BUDGETS $0 for "OPEX/CAPEX", because the community has
proven over 27+ years, that a staff of few quasi-volunteers, with
generously donated hosting and purchased+donated hardware, are
SUFFICIENT to keep this important community forge running and
improving and growing.

It has run well enough that the biggest concrete complaint in this
entire thread has been a few-day outage of just one anonymous-git-read
service from the server, during a holiday DDoS attack that no known
free git service could have withstood.  That is reason to be proud.


- FChE

Re: Unpopular opinion (Re: CTI - Making a decision for glibc.)

[Mark Wielaard]

Hi Andreas,

On Wed, 2026-01-28 at 13:47 +0100, Andreas K. Huettel wrote:
> I'm coming from a Linux distribution that is entirely noncommercial and
> has in the past internally rejected the Linux Foundation as service provider,
> because, err, it seemed way too corporate to us. In addition, right now all
> my involvment with Gentoo and glibc is as an unpaid volunteer. That said...
> 
> > Basically this proposal is for setting up a directed fund controlled
> > by the Linux Foundation into which corporations can donate money if
> > they first become a LF member company. In exchange these companies
> > will get a board seat to control what happens to this money and may
> > appoint a technical advisary member....
> 
> I'm citing Mark here because this is a nice example, but my mail is
> directed not to him specifically, just to make this clear.
> 
> Please get a grip. We are for now talking here about who is hosting git,
> mailing lists, and bugzilla. Git and mailing lists are by definition
> decentral, bugzilla is an SQL database which can easily be dumped and
> restored elsewhere.
> [...]
> As someone who is keeping track of the mailing list and patchwork,  I would
> guess that roughly 90% of contributed code in glibc these day comes from people
> who work for corporations with a stake in glibc. So, Gnu or not, complaining
> about the Linux Foundation is somewhat hypocritical then.
> [...]
> Making a stand over where services are hosted is mostly just throwing
> flashbangs.

Obviously I care a little more about where and how community services
are hosted than you. But sure it isn't rocket science, we know how to
do it. Also your point about having 90% people being payed to work on
glibc is great. I am happy they are. You could make conspiracy theories
about that, but I know that for most the project/community comes first,
then the corporation they work for.

Corporations aren't evil by design. But corporate politics and
bureaucracy are real. We have mostly been able to keep them out of the
Sourceware hosting services even though of course some of our sponsors,
hardware and service partners are corporations.

My main complaint is "meta". We have an IMHO good structure to manage
the services and hosting. I don't see a reason to add a completely
corporate controlled directed fund with a whole extra corporate
bureaucratic layer that is going to move services around. That just
sounds like extra corporate overhead we really don't need. It would be
much better IMHO if we can get new (corporate) sponsors to work with
the Sourceware PLC and Conservancy staff improving the hosting services
with the existing sponsors without having to move them around and
invent a whole new hosting management structure.

Cheers,

Mark

Re: CTI - Making a decision for glibc.

[Mark Wielaard]

Hi Carlos,

I have added Karen Sandler, the SFC Director, Zoë Kooyman, the FSF
Director and Ian Kelling, the FSF president, sysadmin and of course
Sourceware PLC member to the CC. I'll meet them this weekend at Fosdem
and they might be able to help you with some of your questions about
coordinating funding for hosting to help us with making a descision for
glibc.

On Wed, 2026-01-28 at 19:00 -0500, Carlos O'Donell wrote:
> (2) Sponsorship.
> 
> We are looking for a straight forward mechanism to fund infrastructure
> by reaching out to the largest companies that benefit directly downstream
> from GNU Toolchain development.
> 
> Those sponsors including AMD, arm, IBM, Intel, NVIDIA, Oracle, Red Hat,
> Qualcomm, are all part of the Linux Foundation (a chamber of commerce),
> and so no matter the IT team we'd still likely create an Associated
> Directed Fund at the LF to gather sponsorship.
> 
> I am one of 3 trustees in the GNU Toolchain Fund at the FSF, but there
> is not enough money there to fund this type of initiative in the long
> run. We need larger corporate sponsors.
> 
> David Edelsohn, Joel Brobekcer, and I know how hard it is to get real
> money on the table, and I'm empathetic with Sourceware's work with the
> SFC to raise funds.
> 
> Lastly, we could attempt to route more funding to either the FSF or
> the SFC, but both are US charities. This means that the donations are
> arms length, which means we can't say "this money shall be used for
> X" and instead the charity decides what to do with the funds against
> their charitable mission. Now, the distinction is germane because
> while the FSF has been amazing at helping us run the GNU Toolchain
> Fund, what is harder is convincing other large sponsors, that might
> not have the same relationship, to give a fully charitable donation.
> In the context of an LF ADF, we have a charter, and sponsors can be
> fiscally accountable for the spend. The distinction is real and some
> sponsors prefer it because they can say "We spent directly on X to
> improve security." rather than "We donated to a charity."

I note that most of those same companies are already or have been
supporting Sourceware through the SFC or the GNU Toolchain through the
FSF Working together fund. I am sure Zoë and Karen can explain how we
can properly thank sponsors when we are using their donations for
something like improving security. Please bring such sponsors in
contact with either to see what we can work out.

We have a list of projects that can be funded:
https://sourceware.org/sourceware-security-vision.html
Please see our donation and sponsor page if you would like to
accelerate some of our (security) plans.
https://sourceware.org/donate.html

> LLVM Foundation, and I've talked to Tom Stellard about them, is using
> Github, and that doesn't match our community values.
> 
> Rust Foundation, and I've talked to Josh Stone about their development
> process, is using Github, and that doesn't match our community values.
> 
> Mozilla Foundation is struggling and also uses Github for all of their
> official repositories as far as I know, and that doesn't match our
> community values.
> 
> If you look across the landscape, many projects turn towards the lowest
> cost and simplest path of using Github, or Gitlab, and that isn't a
> direction aligned with our values.

Right. And that is why we are experimenting with forge.sourceware.org
using forgejo. Claudio is really doing a great thing there. And we are
closely watching the Fedora project making the switch.

> FOSS using IT teams today include LF IT, Sourceware and probably the
> Fedora Community Infrastructure team, along with downstream distros
> and many more self-hosted companies.
> 
> The teams with the longest established records are probably Sourceware,
> FSF IT/GNU Project, and LF IT.

Don't forget the OSUOSL which is also a Sourceware partner.

> My position is that for the level of infrastructure spending we need
> it's hard to get fully charitable donations, so in combination it is
> simpler to use a chamber of commerce structure, followed by a team
> already at the chamber of commerce that meets our requirements.

I'll talk to Zoë, Karen and Ian to see if we can better understand how
others are doing this. But I am pretty sure there are other teams, like
the FSF tech team itself, the Reproducible Builds team, the Python
Foundation, various community distros, etc. that manage that.

> I have finished writing SSDLC's with requirements for glibc:
> https://inbox.sourceware.org/libc-alpha/4e9f65ea-a1bf-4d69-9dd5-63aa301f0b42@redhat.com/

I have a script that does that with the current setup that takes the
sourceware account emeritus process (account retirement) into account
so it doesn't have some false positives. After I am back from Fosdem
I'll make sure to use it to update the glibc developer account status.

> We have started using the SSDLC, for example to raise issue with
> Sourceware's current operations:
> https://inbox.sourceware.org/overseers/d894fead-dff1-46c5-9b1f-8a5dade9b986@redhat.com/

It is good to prefer https over git when possible. It adds a layer that
authenticates the server hosting (a copy of) the git repo. But don't
let that give you a false sense of "security". To authenticate the
actual commits you still need to check against a signed (release) tag.
This is why we have the "Signed-commit census leaderboard" in our
quarterly reports and the gitsigur project to get attention to projects
using signed commits more.

> I also wrote a comparison of Sourceware's checklist to the recommendations for glibc:
> https://sourceware.org/glibc/wiki/SSDLC/Policy/Sourceware

It is good to see you find the Sourceware policy useful.
Yes, it is a subset of items from the Secure Software Development
Framework (NIST SP 800-218) but that wasn't the direct source (although
the PLC did study that). It was mostly written following advise around
the EU Cyber Resilience Act (EU CRA). I don't think all items in NIST
SP 800-218 make sense for a community project because it wasn't written
for that. But you can of course use it to get some kind of overview.
See also https://sourceware.org/cyber-security-faq.html

> Frank said Sourceware has $0 for operations and capital spending:
> https://inbox.sourceware.org/overseers/20251029171555.GB21228@redhat.com/

:) Frank already explained how to interpret that. You are asking about
OPEX/CAPEX budgetting, which is not how we currently work (of course
some of our hardware/service sponsors are, but they mostly absorb those
costs, so we don't have to). I will also meet with the SFC fiscal team
at Fosdem and will ask if we can write up a budget in a way that meets
your curiosity about these matters.


Cheers,

Mark

Re: CTI - Making a decision for glibc.

[Karen M. Sandler]

On 2026-01-29 10:20, Mark Wielaard wrote:
> Hi Carlos,
> 
> I have added Karen Sandler, the SFC Director, Zoë Kooyman, the FSF
> Director and Ian Kelling, the FSF president, sysadmin and of course
> Sourceware PLC member to the CC. I'll meet them this weekend at Fosdem
> and they might be able to help you with some of your questions about
> coordinating funding for hosting to help us with making a descision for
> glibc.

Yes, I would be happy to discuss this at FOSDEM.

Just a few small clarifications:

>> Those sponsors including AMD, arm, IBM, Intel, NVIDIA, Oracle, Red 
>> Hat,
>> Qualcomm

I confirm that these companies have done sponsorships to SFC in the 
past, and we should be set up in almost all of their payment systems 
already.

>> Lastly, we could attempt to route more funding to either the FSF or
>> the SFC, but both are US charities. This means that the donations are
>> arms length, which means we can't say "this money shall be used for
>> X" and instead the charity decides what to do with the funds against
>> their charitable mission. Now, the distinction is germane because
>> while the FSF has been amazing at helping us run the GNU Toolchain
>> Fund, what is harder is convincing other large sponsors, that might
>> not have the same relationship, to give a fully charitable donation.
>> In the context of an LF ADF, we have a charter, and sponsors can be
>> fiscally accountable for the spend. The distinction is real and some
>> sponsors prefer it because they can say "We spent directly on X to
>> improve security." rather than "We donated to a charity."

Charities can definitely take in funds that are restricted for a 
particular purpose. While this would indeed subject to our charitable 
mission, that mission is to support free and open source software. We 
also couldn't use any funds to unduly benefit one company or individual 
(called "private inurement"), but it's hard to imagine any serious 
proposal here that would veer into that territory.

Companies regularly treat their contributions as business expenses 
rather than charitable donations, depending on their individual tax 
situations. Happy to explore all of this in further detail with you.

karen

Re: Unpopular opinion (Re: CTI - Making a decision for glibc.)

[Joseph Myers]

On Thu, 29 Jan 2026, Mark Wielaard wrote:

> My main complaint is "meta". We have an IMHO good structure to manage
> the services and hosting. I don't see a reason to add a completely

I'm concerned with service isolation for security - meaning isolation for 
the existing services.  I haven't seen progress on that arising from the 
existing structures since I raised it as a serious issue at Cauldron 2022 
- whereas in CTI, for example, we've done and published all the analysis 
of existing services and their interactions that's a necessary 
prerequisite of having properly isolated services.  A huge amount of the 
work done on Sourceware has been necessary *simply to stay in the same 
place* (for example, migrating the existing services, with their existing 
lack of isolation, to a new server) - and that sort of routine move 
between different hardware seems like exactly the kind of thing it makes 
sense to contract out to people who do it routinely rather than having it 
take up community time and thought.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Unpopular opinion (Re: CTI - Making a decision for glibc.)

[Andrew Pinski]

On Thu, Jan 29, 2026 at 2:06 PM Joseph Myers via Overseers
<overseers@sourceware.org> wrote:
>
> On Thu, 29 Jan 2026, Mark Wielaard wrote:
>
> > My main complaint is "meta". We have an IMHO good structure to manage
> > the services and hosting. I don't see a reason to add a completely
>
> I'm concerned with service isolation for security - meaning isolation for
> the existing services.  I haven't seen progress on that arising from the
> existing structures since I raised it as a serious issue at Cauldron 2022

This is definitely not true.
https://sourceware.org/sourceware-security-vision.html
Update May 2025 We have been isolating processes using systemd
services and resource controls and have separated various services
running over http. This has helped separate anubis protection per
service. In 2025 Q3 an extra (bigger) server will be used that will be
setup with a VM setup in mind to prepares moving some services into
their own VM.

https://inbox.sourceware.org/overseers/20251029103556.GB26406@gnu.wildebeest.org/

  In the new datacenter we will have multiple public ipv4 (and ipv6)
  addresses that can be used by VMs. We have currently setup 8
  separate VMs which can run services in isolation. The first two VMs
  are for the forgejo staging server forge-stage.sourceware.org and
  the debuginfod.elfutils.org services. The next VMs will probably be
  used for patchwork.sourceware.org, inbox.sourceware.org,
  builder.sourceware.org and bunsen.




> - whereas in CTI, for example, we've done and published all the analysis
> of existing services and their interactions that's a necessary
> prerequisite of having properly isolated services.  A huge amount of the
> work done on Sourceware has been necessary *simply to stay in the same
> place* (for example, migrating the existing services, with their existing
> lack of isolation, to a new server)
Huh? See  https://inbox.sourceware.org/overseers/20251029103556.GB26406@gnu.wildebeest.org/
.

> - and that sort of routine move
> between different hardware seems like exactly the kind of thing it makes
> sense to contract out to people who do it routinely rather than having it
> take up community time and thought.
>
> --
> Joseph S. Myers
> josmyers@redhat.com
>

Re: CTI - Making a decision for glibc.

[Carlos O'Donell]

On 1/28/26 7:11 PM, Andrew Pinski wrote:
> On Wed, Jan 28, 2026 at 4:00 PM Carlos O'Donell <carlos@redhat.com>
> wrote: There is something which you missed from my previous email
> which ties into (1) and (2). Here. What is the support path? From
> say someone in the community noticing something is not working to LF
> IT? This is just as important as figuring out if moving and using LF
> IT (or anyone else really). Right now there is both a form path via
> bugzilla infstructure issues and an inform one via email and IRC.

tl;dr Today the CTI, on behalf of glibc and the GNU Toolchain,
emails the LF IT ticket queue e.g. please make a new BBB room with
the following people as room admin.

Just like we evolved this with Sourceware, we get to evolve this with
CTI into something that supports glibc and the GNU Toolchain and works
for LF IT.

There are 3 points I think we should consider in this area.

(1) Developer led.

Project developers should own and lead the process.

We will own several parts of the process of maintaining our
infrastructure e.g. gitolite keyring repo, mailing list moderation.

We should be opinionated about what we want, the services
are for us and serve us to improve the GNU Toolchain.

We should identify who wants to step into that role and empower
them to write up what a reasonable support path should look like.

There may be infrastructure issues that just turn out to be
help requests, and as a community we should help with those.

(2) Data driven.

If we have an infrastructure issue, and I'm opinionated here,
we should *always* file an infrastructure bug.

Without those issues we have no way to look back on the year, and
reflect on the problems we might have had and how we can improve
things (also not surprisingly a part of the SSDLC).

The data here should also include:

  * talking to other shared-infra users for consensus

  * approval for the change.

  * what was done to workaround or correct the issue so we can
    review what did and didn't work.

(3) With the option to escalate.

We always need an escalation path in case something serious goes
wrong and we need it escalated.

We need to collaborate with LF IT to determine what this would look
like and under what conditions we should escalate (see (1)) and
who can escalate.

Today there isn't a documented escalation path in the SOW, but it
can and should be discussed.

Today CTI sends an email.

See (1) about this needing to be developer led.

---

Joseph Myers has raised this issue a few times in previous threads,
and I want to raise it again.

On occasion we sometimes jump to implement changes in our
infrastructure because someone said something on IRC, or emailed
the right person, but these changes sometimes needed broader
consideration for the shared teams using that infrastructure.

Such changes are not always recorded anywhere so we can't review
them or decide if they were the wrong thing to do in the long run.
Including auditing them for security impact e.g. disabling https.

I think a coordinated approach with a team of developers being
our IT liasons would be very valuable, in fact I think a rotating
team lead could be very effective (like we are doing with the glibc
security team).

I suggest attending the Office Hours for CTI on Friday, or a
subsequent office hours. We will rotate them around timezones.

I've setup #cti-help on OFTC for asynchronous discussions.

> This is really important when stuff comes up like the recent AI bot
> scrappers attacks. And it is also important when there has been in
> the past with locks needing to be removed (e.g. git locks up in some
> cases due to large number of commits due to the post-recievce
> hooks). Does it need to go to CTI (or a representative) first or is
> there a direct line for all community members? That is the bigger
> question and part of the problem I see with the out sourceing of IT
> support here. Also is there future cost of including new
> infrastrcture needs in? Like say a new bugzilla instance or a forge
> that has been already planned out.

This last paragraph has a lot of questions that I am splitting here.

(a) Option to escalate I covered in (3).

(b) New infrastructure needs should be discussed, and the GNU Toolchain
     working with the CTI TAC needs to put together a proposal that we
     can evaluate for cost, now and over time.

(c) If we have new infrastructure needs beyond what we have in our
     SOW, then we need to cost them out, and determine if we can pay
     them.

(d) Forge hosting should be evaluated as new infrastructure with
     an eye towards figuring out the current cost and long-term costs,
     along with security and maintenance. This is absolutely something
     we can do, but was not part of the original SOW as it is still
     an evolving discussion. Right now for glibc there is no plan to
     use a forge, and any workflow changes have to come from the
     developers. I expect here that you're talking about gcc.

-- 
Cheers,
Carlos.

[1] https://codeberg.org/Codeberg-Infrastructure/meta

Re: CTI - Making a decision for glibc.

[Carlos O'Donell]

On 1/29/26 6:12 PM, Carlos O'Donell wrote:
> [1] https://codeberg.org/Codeberg-Infrastructure/meta

I included a footnote I meant to use, but didn't.

The point here is that Codeberg for their own Forgejo
hosting uses 5 physical servers (production, testing
and experimental setups), 2 backup servers, and 2 virtual
cloud servers. This is a lot of infrastructure, along with
the included Ceph Cluster to ensure any given server doesn't
run out of storage.

Forgejo support needs significant planning, both in short
term, and long term, so we have something maintainable,
supportable, secure, robust and reliable.

By the time we are done... should we have just paid
Codeberg e. V. for hosting?

This option needs much more evaluation and discussion and
it outside the scope of this initial migration to CTI, but not
outside the scope of CTI overall to help plan, fund, and secure.

-- 
Cheers,
Carlos.

Re: CTI - Making a decision for glibc.

[Andrew Pinski]

On Thu, Jan 29, 2026 at 3:13 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 1/28/26 7:11 PM, Andrew Pinski wrote:
> > On Wed, Jan 28, 2026 at 4:00 PM Carlos O'Donell <carlos@redhat.com>
> > wrote: There is something which you missed from my previous email
> > which ties into (1) and (2). Here. What is the support path? From
> > say someone in the community noticing something is not working to LF
> > IT? This is just as important as figuring out if moving and using LF
> > IT (or anyone else really). Right now there is both a form path via
> > bugzilla infstructure issues and an inform one via email and IRC.
>
> tl;dr Today the CTI, on behalf of glibc and the GNU Toolchain,
> emails the LF IT ticket queue e.g. please make a new BBB room with
> the following people as room admin.
>
> Just like we evolved this with Sourceware, we get to evolve this with
> CTI into something that supports glibc and the GNU Toolchain and works
> for LF IT.
>
> There are 3 points I think we should consider in this area.
>
> (1) Developer led.
>
> Project developers should own and lead the process.
>
> We will own several parts of the process of maintaining our
> infrastructure e.g. gitolite keyring repo, mailing list moderation.

Who is "we"? It is not obvious if that is CTI or representation of
developers/maintains/reviews or what?

>
> We should be opinionated about what we want, the services
> are for us and serve us to improve the GNU Toolchain.
>
> We should identify who wants to step into that role and empower
> them to write up what a reasonable support path should look like.

So there was no support path in place in the first place how can move
happen without that?

>
> There may be infrastructure issues that just turn out to be
> help requests, and as a community we should help with those.
>
> (2) Data driven.
>
> If we have an infrastructure issue, and I'm opinionated here,
> we should *always* file an infrastructure bug.
>
> Without those issues we have no way to look back on the year, and
> reflect on the problems we might have had and how we can improve
> things (also not surprisingly a part of the SSDLC).
>
> The data here should also include:
>
>   * talking to other shared-infra users for consensus
>
>   * approval for the change.
>
>   * what was done to workaround or correct the issue so we can
>     review what did and didn't work.
>
> (3) With the option to escalate.
>
> We always need an escalation path in case something serious goes
> wrong and we need it escalated.
>
> We need to collaborate with LF IT to determine what this would look
> like and under what conditions we should escalate (see (1)) and
> who can escalate.
>
> Today there isn't a documented escalation path in the SOW, but it
> can and should be discussed.
>
> Today CTI sends an email.
>
> See (1) about this needing to be developer led.
>
> ---
>
> Joseph Myers has raised this issue a few times in previous threads,
> and I want to raise it again.
>
> On occasion we sometimes jump to implement changes in our
> infrastructure because someone said something on IRC, or emailed
> the right person, but these changes sometimes needed broader
> consideration for the shared teams using that infrastructure.

Give an example (which was not an emergency change that was needed here)?
The shutting down https git access was an emergancy change needed for
the night and was wrote to the lists telling people it happened and
why.

>
> Such changes are not always recorded anywhere so we can't review
> them or decide if they were the wrong thing to do in the long run.
> Including auditing them for security impact e.g. disabling https.

This is lie. And you know it is lie. disabling https git access was an
emergancy change. It was not something done lightly either.

>
> I think a coordinated approach with a team of developers being
> our IT liasons would be very valuable, in fact I think a rotating
> team lead could be very effective (like we are doing with the glibc
> security team).

So how do is the team voted upon or appointed? But still I think this
is more layers for what end?

>
> I suggest attending the Office Hours for CTI on Friday, or a
> subsequent office hours. We will rotate them around timezones.
>
> I've setup #cti-help on OFTC for asynchronous discussions.
>
> > This is really important when stuff comes up like the recent AI bot
> > scrappers attacks. And it is also important when there has been in
> > the past with locks needing to be removed (e.g. git locks up in some
> > cases due to large number of commits due to the post-recievce
> > hooks). Does it need to go to CTI (or a representative) first or is
> > there a direct line for all community members? That is the bigger
> > question and part of the problem I see with the out sourceing of IT
> > support here. Also is there future cost of including new
> > infrastrcture needs in? Like say a new bugzilla instance or a forge
> > that has been already planned out.
>
> This last paragraph has a lot of questions that I am splitting here.
>
> (a) Option to escalate I covered in (3).
>
> (b) New infrastructure needs should be discussed, and the GNU Toolchain
>      working with the CTI TAC needs to put together a proposal that we
>      can evaluate for cost, now and over time.

Which we is this we here?

>
> (c) If we have new infrastructure needs beyond what we have in our
>      SOW, then we need to cost them out, and determine if we can pay
>      them.

Who is we here? CTI TAC or some other group?
CTI TAC is not voted upon by developers so it does not represent
developers of the project.

>
> (d) Forge hosting should be evaluated as new infrastructure with
>      an eye towards figuring out the current cost and long-term costs,
>      along with security and maintenance. This is absolutely something
>      we can do, but was not part of the original SOW as it is still
>      an evolving discussion. Right now for glibc there is no plan to
>      use a forge, and any workflow changes have to come from the
>      developers. I expect here that you're talking about gcc.

I think I am talking about more than gcc but glibc should really think
about doing the forge instead for new developers and such.

>
> --
> Cheers,
> Carlos.
>
> [1] https://codeberg.org/Codeberg-Infrastructure/meta
>

Re: CTI - Making a decision for glibc.

[Zoë Kooyman]

On 1/29/26 18:05, Karen M. Sandler wrote:
> On 2026-01-29 10:20, Mark Wielaard wrote:
>> Hi Carlos,
>>
>> I have added Karen Sandler, the SFC Director, Zoë Kooyman, the FSF
>> Director and Ian Kelling, the FSF president, sysadmin and of course
>> Sourceware PLC member to the CC. I'll meet them this weekend at Fosdem
>> and they might be able to help you with some of your questions about
>> coordinating funding for hosting to help us with making a descision for
>> glibc.
> 
> Yes, I would be happy to discuss this at FOSDEM.
> 
Yes, I would be available as well.

Zoë

Re: Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Jan 28, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

>> Rendering control over a key piece of GNU to a hostile party is
>> obviously not being done for GNU's benefit, for GNU's sake, on its
>> behalf, or even in agreement with GNU leadership. 

> Please forgive my ignorance, but... What's so horrible about the 
> Linux Foundation?

It's controlled by GPL violators.

It's historically claimed GNU packages to be its own Linux thing.

It's historically worked hard to erase GNU from history.

Inasmuchas we recognize ourselves as GNU, LF is openly hostile to us.

Now, people who step on others' toes often don't feel as hurt as those
whose toes have been stepped on.

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, Andrew Pinski <pinskia@gmail.com> wrote:

> Does it need to go to CTI (or a representative) first or is there a
> direct line for all community members? That is the bigger question and
> part of the problem I see with the out sourceing of IT support here.
> Also is there future cost of including new infrastrcture needs in?
> Like say a new bugzilla instance or a forge that has been already
> planned out.

All great questions.

Of course at this point people are comparing the actual experience from
a solid and reliable provider with what's essentially salespeople's
promises.

We'd only know how empty the promises are, and how they translate to
actual deliveries, by actually trying them.

Maybe it would make sense to try them out with things that would be
actually useful, not risky, and not viable for our current providers to
offer, such as git and web mirrors run by separate organizations,
bringing about some of the redundancy that I mentioned as potentially
useful back when this started being discussed.

We will never be able to know whether the services are being rendered
using exclusively Free Software (the LF is not exactly reliable in
telling what is FLOSS, since they claim the kernel Linux is OSS, while
it contains pieces licensed under very obnoxious nonfree licenses), but
these would be services, so it is not an ethical imperative for them to
be implemented with free software, and if they aren't, it's the
operator's freedom that's on the line, not ours.

And since mirrors are about (re)publishing, these service wouldn't be
SaaSS.

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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 29, 2026, "Carlos O'Donell" <carlos@redhat.com> wrote:

> should we have just paid Codeberg e. V. for hosting?

Forge hosting is extremely likely to be SaaSS if done by a third party.

If you wanted to claim honestly to be in line with Free Software values
and policies or whatever word you used in your claim, you shouldn't even
be considering a SaaSS arrangement.  It should have been unfathomable.

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

Re: CTI - Making a decision for glibc.

[Collin Funk]

Alexandre Oliva <oliva@gnu.org> writes:

> On Jan 29, 2026, "Carlos O'Donell" <carlos@redhat.com> wrote:
>
>> should we have just paid Codeberg e. V. for hosting?
>
> Forge hosting is extremely likely to be SaaSS if done by a third party.
>
> If you wanted to claim honestly to be in line with Free Software values
> and policies or whatever word you used in your claim, you shouldn't even
> be considering a SaaSS arrangement.  It should have been unfathomable.

Codeberg e.V is a non-profit [1]. Maybe by "paid", Carlos probably meant
something like setting up a recurring donation to make sure they are
supported.

Codeberg generally only allows projects with free software licenses [2],
and explicitly recommends picking one from the GPL family [3].

A few GNU projects have started to use it after the unfortunate DDoSing
situation Savannah has to deal with.

Collin

[1] https://docs.codeberg.org/getting-started/what-is-codeberg/
[2] https://docs.codeberg.org/getting-started/faq/#can-i-host-content-without-a-free-and-open-source-license%3F
[3] https://docs.codeberg.org/getting-started/licensing/#recommendations-for-software%2C-hardware-and-other-projects

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 29, 2026, Collin Funk <collin.funk1@gmail.com> wrote:

> Alexandre Oliva <oliva@gnu.org> writes:

>> Forge hosting is extremely likely to be SaaSS if done by a third party.

> Codeberg e.V is a non-profit [1]. Maybe by "paid", Carlos probably meant
> something like setting up a recurring donation to make sure they are
> supported.

> Codeberg generally only allows projects with free software licenses [2],
> and explicitly recommends picking one from the GPL family [3].

I'm familiar with Codeberg.  None of what you say changes the fact that
it would be an external third party doing our computing for us under
their control instead of ours.

Even if the FSF would hypothetically host such a forge for the Linux
Foundation, or for some third party Free Software project, it would
still be SaaSS: it would still be a case in which the users whose
computing the software does don't have control over the software, only
those who control the software do.

This is the fundamental ethical problem of nonfree software, and it is
the same ethical problem of SaaSS.  So they're both instances of the
same kind of ethical problem, they're both violations of software
freedom, and they're both described as such under free software
philosophy.

It's getting more and more clear that a lot of people here don't really
get this essential aspect of free software, which weakens any claims
that the proposal abides by them.

> A few GNU projects have started to use it after the unfortunate DDoSing
> situation Savannah has to deal with.

Yeah, that's quite unfortunate.

Hopefully they're self hosting, or avoiding the features that make such
forges SaaSS.

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

Re: CTI - Making a decision for glibc.

[Adhemerval Zanella Netto]

On 28/01/26 19:12, Siddhesh Poyarekar wrote:
> On 2026-01-28 16:45, Zack Weinberg wrote:
>> 1. It's my impression that there are a small number of people (Carlos
>>     O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
>>     who feel strongly that glibc should move off of sourceware.org, and
>>     *everyone else* with a stake in the matter is somewhere on a spectrum
>>     between neutral and a strong belief that glibc *shouldn't* move, or
>>     at least, should not move to infrastructure hosted by the Linux
>>     Foundation.
> 
> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and Andreas Huettel who have vocally supported the move in this thread, while many others (who I hope will chime in too) who contribute on a day to day basis, have expressed support offline in the past.  Your base characterization of the situation is flawed I'm afraid.

You can include me on this list, although I am not a GNU maintainer. As I noted
in earlier email we can make the CTI migration as an experiment, evaluate, and
rollback if it does not work with the expected quality or requisites.

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-01-29 18:24, Andrew Pinski wrote:
>> There are 3 points I think we should consider in this area.
>>
>> (1) Developer led.
>>
>> Project developers should own and lead the process.
>>
>> We will own several parts of the process of maintaining our
>> infrastructure e.g. gitolite keyring repo, mailing list moderation.
> 
> Who is "we"? It is not obvious if that is CTI or representation of
> developers/maintains/reviews or what?

They're not different people (and will never be, since the TAC will 
always be a representation of the GNU toolchain community[1]), but if 
you mean in terms of roles, this falls on the broader glibc community; I 
mean Carlos did start with "Project developers should own and lead the 
process" :)

>> We should be opinionated about what we want, the services
>> are for us and serve us to improve the GNU Toolchain.
>>
>> We should identify who wants to step into that role and empower
>> them to write up what a reasonable support path should look like.
> 
> So there was no support path in place in the first place how can move
> happen without that?

We (the TAC) did the groundwork:

https://cti.coretoolchain.dev/projects/enum.html

and iterated on an action plan, that we've now announced here.  All this 
while we have been talking to key glibc contributors to be sure that 
we're listening to them.

>> There may be infrastructure issues that just turn out to be
>> help requests, and as a community we should help with those.
>>
>> (2) Data driven.
>>
>> If we have an infrastructure issue, and I'm opinionated here,
>> we should *always* file an infrastructure bug.
>>
>> Without those issues we have no way to look back on the year, and
>> reflect on the problems we might have had and how we can improve
>> things (also not surprisingly a part of the SSDLC).
>>
>> The data here should also include:
>>
>>    * talking to other shared-infra users for consensus
>>
>>    * approval for the change.
>>
>>    * what was done to workaround or correct the issue so we can
>>      review what did and didn't work.
>>
>> (3) With the option to escalate.
>>
>> We always need an escalation path in case something serious goes
>> wrong and we need it escalated.
>>
>> We need to collaborate with LF IT to determine what this would look
>> like and under what conditions we should escalate (see (1)) and
>> who can escalate.
>>
>> Today there isn't a documented escalation path in the SOW, but it
>> can and should be discussed.
>>
>> Today CTI sends an email.
>>
>> See (1) about this needing to be developer led.
>>
>> ---
>>
>> Joseph Myers has raised this issue a few times in previous threads,
>> and I want to raise it again.
>>
>> On occasion we sometimes jump to implement changes in our
>> infrastructure because someone said something on IRC, or emailed
>> the right person, but these changes sometimes needed broader
>> consideration for the shared teams using that infrastructure.
> 
> Give an example (which was not an emergency change that was needed here)?
> The shutting down https git access was an emergancy change needed for
> the night and was wrote to the lists telling people it happened and
> why.

This does happen, you know that.  Things may have improved somewhat over 
time, especially with the CTI initiative forcing the overseers to try 
and clamp things down too, but it is how we've operated and I personally 
like the community aspect of it all.  I mean you yourself pointed out 
how it's easy to just catch hold of an overseer on IRC and request them 
to do something for you.

>> Such changes are not always recorded anywhere so we can't review
>> them or decide if they were the wrong thing to do in the long run.
>> Including auditing them for security impact e.g. disabling https.
> 
> This is lie. And you know it is lie. disabling https git access was an
> emergancy change. It was not something done lightly either.

I don't think that's a lie and no, the git https issue was handled in a 
manner that is consistent with sourceware maintenance over the years.

>> I think a coordinated approach with a team of developers being
>> our IT liasons would be very valuable, in fact I think a rotating
>> team lead could be very effective (like we are doing with the glibc
>> security team).
> 
> So how do is the team voted upon or appointed? But still I think this
> is more layers for what end?

This first TAC is essentially self-appointed because they're the ones 
who have gone out and built this whole solution.  As the glibc 
community, we can absolutely set up a process to do this once the 
migration is done.

>> I suggest attending the Office Hours for CTI on Friday, or a
>> subsequent office hours. We will rotate them around timezones.
>>
>> I've setup #cti-help on OFTC for asynchronous discussions.
>>
>>> This is really important when stuff comes up like the recent AI bot
>>> scrappers attacks. And it is also important when there has been in
>>> the past with locks needing to be removed (e.g. git locks up in some
>>> cases due to large number of commits due to the post-recievce
>>> hooks). Does it need to go to CTI (or a representative) first or is
>>> there a direct line for all community members? That is the bigger
>>> question and part of the problem I see with the out sourceing of IT
>>> support here. Also is there future cost of including new
>>> infrastrcture needs in? Like say a new bugzilla instance or a forge
>>> that has been already planned out.
>>
>> This last paragraph has a lot of questions that I am splitting here.
>>
>> (a) Option to escalate I covered in (3).
>>
>> (b) New infrastructure needs should be discussed, and the GNU Toolchain
>>       working with the CTI TAC needs to put together a proposal that we
>>       can evaluate for cost, now and over time.
> 
> Which we is this we here?

The TAC for the most part, with us looking at the community to tell us 
their pain points.  Think of us as overseers but without root, which by 
the way is why the overseers were the first people to be invited to join 
the TAC, of which Frank is still on it.

>> (c) If we have new infrastructure needs beyond what we have in our
>>       SOW, then we need to cost them out, and determine if we can pay
>>       them.
> 
> Who is we here? CTI TAC or some other group?

This is the TAC.

> CTI TAC is not voted upon by developers so it does not represent
> developers of the project.

This is a bootstrap and *all* members of the TAC have been GNU toolchain 
developers or maintainers for decades so I reject your claim that the 
TAC does not represent developers of the project.  The GNU project has 
never been a classical democracy, so that claim doesn't make sense at all.

That said though, I am absolutely in favour of putting together a 
process to nominate and onboard new TAC members[2] once the contracts 
are in place and we've started the migration.  In my experience over the 
years though, few people in the broader GNU toolchain community are 
actually interested in these roles; they're much happier hacking on the 
code.

>> (d) Forge hosting should be evaluated as new infrastructure with
>>       an eye towards figuring out the current cost and long-term costs,
>>       along with security and maintenance. This is absolutely something
>>       we can do, but was not part of the original SOW as it is still
>>       an evolving discussion. Right now for glibc there is no plan to
>>       use a forge, and any workflow changes have to come from the
>>       developers. I expect here that you're talking about gcc.
> 
> I think I am talking about more than gcc but glibc should really think
> about doing the forge instead for new developers and such.

I agree.

Sid

[1] https://cti.coretoolchain.dev/tac/index.html
[2] I'd love to see us do the same for the projects themselves too but 
that's a different subject.

VMs and isolation (Re: Unpopular opinion)

[Mark Wielaard]

Hi,

On Thu, Jan 29, 2026 at 02:39:42PM -0800, Andrew Pinski wrote:
> On Thu, Jan 29, 2026 at 2:06 PM Joseph Myers via Overseers
> <overseers@sourceware.org> wrote:
> >
> > On Thu, 29 Jan 2026, Mark Wielaard wrote:
> >
> > > My main complaint is "meta". We have an IMHO good structure to manage
> > > the services and hosting. I don't see a reason to add a completely
> >
> > I'm concerned with service isolation for security - meaning isolation for
> > the existing services.  I haven't seen progress on that arising from the
> > existing structures since I raised it as a serious issue at Cauldron 2022
> 
> This is definitely not true.
> https://sourceware.org/sourceware-security-vision.html
> Update May 2025 We have been isolating processes using systemd
> services and resource controls and have separated various services
> running over http. This has helped separate anubis protection per
> service. In 2025 Q3 an extra (bigger) server will be used that will be
> setup with a VM setup in mind to prepares moving some services into
> their own VM.
> 
> https://inbox.sourceware.org/overseers/20251029103556.GB26406@gnu.wildebeest.org/
> 
>   In the new datacenter we will have multiple public ipv4 (and ipv6)
>   addresses that can be used by VMs. We have currently setup 8
>   separate VMs which can run services in isolation. The first two VMs
>   are for the forgejo staging server forge-stage.sourceware.org and
>   the debuginfod.elfutils.org services. The next VMs will probably be
>   used for patchwork.sourceware.org, inbox.sourceware.org,
>   builder.sourceware.org and bunsen.
> 
> > - whereas in CTI, for example, we've done and published all the analysis
> > of existing services and their interactions that's a necessary
> > prerequisite of having properly isolated services.  A huge amount of the
> > work done on Sourceware has been necessary *simply to stay in the same
> > place* (for example, migrating the existing services, with their existing
> > lack of isolation, to a new server)
>
> Huh? See  https://inbox.sourceware.org/overseers/20251029103556.GB26406@gnu.wildebeest.org/
> 
> > - and that sort of routine move
> > between different hardware seems like exactly the kind of thing it makes
> > sense to contract out to people who do it routinely rather than having it
> > take up community time and thought.

Thanks Andrew for digging up the progress we have made over the
years. But Joseph is right that isolation is important and that the
untangling of services has been going slowly. However we are now close
to our goal to not have any services running on bare metal and put
everything into VMs. That will make the next steps much easier.

In two weeks the last two backup servers (server2 and server3) will
move from the RDU2 to the RDU3 datacenter and then those will also be
setup as VM only servers.

That way the hardware should not really matter when moving things
around. For example last month the snapshots.sourceware.org VM was
moved by OSUOSL for us onto bigger faster hardware with a minimum of
downtime (minutes). After the move we just had a faster server.

It also simplifies backups, which are now done through lv
snapshots. And because the VMs have their own IP addresses the
services are running as if running on separate isolated machines.

Cheers,

Mark

Mirror services (Re: CTI - Making a decision for glibc.)

[Mark Wielaard]

Hi Alex,

On Thu, Jan 29, 2026 at 11:26:06PM -0300, Alexandre Oliva wrote:
> Maybe it would make sense to try them out with things that would be
> actually useful, not risky, and not viable for our current providers to
> offer, such as git and web mirrors run by separate organizations,
> bringing about some of the redundancy that I mentioned as potentially
> useful back when this started being discussed.

I think this is a good suggestion. Having (read-only) mirrors of git
repos and the mailinglists seem like safe things the LF could provide
that would add value. We can setup grokmirror for the git repos and
the LF already knows how to handle public-inbox archives.

Cheers,

Mark

Re: CTI - Making a decision for glibc.

[Yury Khrustalev]

On Tue, Jan 27, 2026 at 11:15:28AM -0500, Carlos O'Donell wrote:
> tl;dr The GNU Maintainers for the GNU C Library (glibc) plan to move
> core services to infrastructure hosted by the Core Toolchain
> Infrastructure (CTI) project. As maintainers for the project we do this
> to meet the present and future needs of glibc and the GNU Toolchain. We
> want secure, robust, and sustainable infrastructure, balanced against
> the needs of developers and the community to collaborate and innovate,
> with reliable funding to support the infrastructure in the long term.

I think that this is a move in the right direction. A lot of questions
and concerns have been raised, rightfully so, but I believe that we
should be moving ahead to facilitate work of the ever growing community.
There will never be a perfect solution.

> ...

> Action plan:
> 
>  * Weekly office hours for CTI to provide an open space for discussion
>    of infrastructure improvements
> 
>  * Work with LF IT to update the CY24 statement of work and discuss with
>    the glibc developers
> 
>  * Work towards migrating glibc git and mailing lists as first priority
>    since these match our security priorities.

I'm glad that we move glibc first. I think it's a good choice.

Thanks,
Yury

forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Mark Wielaard]

Hi,

Combining some emails and changing subject to not make this thread
even larger.

On Thu, Jan 29, 2026 at 03:24:37PM -0800, Andrew Pinski wrote:
> On Thu, Jan 29, 2026 at 3:13 PM Carlos O'Donell <carlos@redhat.com> wrote:
> This is lie. And you know it is lie. disabling https git access was an
> emergancy change. It was not something done lightly either.
> > (d) Forge hosting should be evaluated as new infrastructure with
> >      an eye towards figuring out the current cost and long-term costs,
> >      along with security and maintenance. This is absolutely something
> >      we can do, but was not part of the original SOW as it is still
> >      an evolving discussion. Right now for glibc there is no plan to
> >      use a forge, and any workflow changes have to come from the
> >      developers. I expect here that you're talking about gcc.
> 
> I think I am talking about more than gcc but glibc should really think
> about doing the forge instead for new developers and such.

I agree with Andrew here. This was really driven home for me by Arjun
and Guinevere's presentation at last Cauldron. We don't have to get
rid of the email workflow completely, but especially for new (and some
corporate) developers email and tracking progress of their patches
through email are a realy pain point. We risk loosing new contributors
if we don't provide a non-email workflow option.

A forge also allows defining better subteams, branch and tag
protection and group permissions:
https://forgejo.org/docs/latest/user/protection/
https://forgejo.org/docs/latest/user/repo-permissions/

It would be really nice to coordinate this between the core toolchain
and developer tool projects. Not all projects might end up with the
same kind of workflow and permission structure, but I suspect they
will be somewhat similar. Also because various developers work across
various toolchain projects.

This is not unlike our shared git setup. There are two Sourceware
teams, cygwin and the DWARF committee, who use gitolite, but they are
kind of separate from the rest of the core toolchain and developer
tool projects. So I would suggest to look at the forge first instead
of experimenting with gitolite, which would separate you from the
other toolchain projects even more. Even without using a new workflow
or even any of the website, you can use the forge as a plain git
repository with slightly different access control, but sharing
accounts with the other projects.

On Thu, Jan 29, 2026 at 06:20:27PM -0500, Carlos O'Donell wrote:
> On 1/29/26 6:12 PM, Carlos O'Donell wrote:
> >[1] https://codeberg.org/Codeberg-Infrastructure/meta
>
> I included a footnote I meant to use, but didn't.
>
> The point here is that Codeberg for their own Forgejo
> hosting uses 5 physical servers (production, testing
> and experimental setups), 2 backup servers, and 2 virtual
> cloud servers. This is a lot of infrastructure, along with
> the included Ceph Cluster to ensure any given server doesn't
> run out of storage.

We are using a similar setup with separate testing, staging and
production servers, where the production and staging are also
backuped. All setup described in (branches of)
https://forge.sourceware.org/forge/forge/

Of course our setup is smaller because we have just ~15 projects. And
people cannot just add their own projects but have to join one of the
existing ones.

> Forgejo support needs significant planning, both in short
> term, and long term, so we have something maintainable,
> supportable, secure, robust and reliable.

Yes, that is why we have already started on that. So far the
experiment is going really well. Forgejo is really nible. We are
migrating it from a 3 cpu with 6GB memory machine to something larger
now. But even with those limited resources things were working just
fine.

> By the time we are done... should we have just paid
> Codeberg e. V. for hosting?

No. The issue isn't hosting, that is kind of the easy part. The issue
is defining the workflow. Currently forgejo is modeled after github
focussed on open registration where people can setup projects however
they like, which isn't ideal. So we are trying to make it integrate
better with the current email workflow focussing on developers who
just want to work together on a handful of (toolchain and developer
tool) projects.

At Fosdem Claudio and I will go talk to the forgejo developers about
what does and what doesn't work for us. We need to start defining
developer workflows that make sense for us. If we don't they will not
magically appear.

Cheers,

Mark

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

Do you have any plans to avoid the SaaSS features of typical forges?

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Simon Marchi]

On 2026-01-31 02:11, Alexandre Oliva via Overseers wrote:
> Do you have any plans to avoid the SaaSS features of typical forges?

Can you explain what the SaaSS features of typical forges are?

Thanks,

Simon

Re: CTI - Making a decision for glibc.

[Sachin Monga]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]


On 29/01/26 3:42 am, Siddhesh Poyarekar wrote:
> On 2026-01-28 16:45, Zack Weinberg wrote:
>> 1. It's my impression that there are a small number of people (Carlos
>>     O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
>>     who feel strongly that glibc should move off of sourceware.org, and
>>     *everyone else* with a stake in the matter is somewhere on a 
>> spectrum
>>     between neutral and a strong belief that glibc *shouldn't* move, or
>>     at least, should not move to infrastructure hosted by the Linux
>>     Foundation.
>
> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph 
> Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law 
> and Andreas Huettel who have vocally supported the move in this 
> thread, while many others (who I hope will chime in too) who 
> contribute on a day to day basis, have expressed support offline in 
> the past.  Your base characterization of the situation is flawed I'm 
> afraid.
>
> Sid


As the powerpc port maintainer, I support this transition move and fully 
trust the repeated assurance that governance would remain the same.

This aligns with our needs for secure, sustainable infrastructure while 
preserving community control.

Regards: Sachin

Re: Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Am Freitag, 30. Januar 2026, 03:09:19 Mitteleuropäische Normalzeit schrieb Alexandre Oliva:
> On Jan 28, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 
> >> Rendering control over a key piece of GNU to a hostile party is
> >> obviously not being done for GNU's benefit, for GNU's sake, on its
> >> behalf, or even in agreement with GNU leadership. 
> 
> > Please forgive my ignorance, but... What's so horrible about the 
> > Linux Foundation?
> 
> It's controlled by GPL violators.

[citation needed]

> It's historically claimed GNU packages to be its own Linux thing.

[citation needed]

That said, GNU isn't really reluctant to claim the entire Linux its own.

> It's historically worked hard to erase GNU from history.

[citation needed]

> 
> Inasmuchas we recognize ourselves as GNU, LF is openly hostile to us.
> 
> Now, people who step on others' toes often don't feel as hurt as those
> whose toes have been stepped on.
> 
> 


-- 
PD Dr. Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Jan 31, 2026, Simon Marchi <simark@simark.ca> wrote:

> On 2026-01-31 02:11, Alexandre Oliva via Overseers wrote:
>> Do you have any plans to avoid the SaaSS features of typical forges?

> Can you explain what the SaaSS features of typical forges are?

I don't have an exhaustive list, but the computing activities that first
come to mind, that I've already mentioned in this thread, are patch
merging and CI/CD.

There may be more, even though most of the computing done by forges is
publishing and communication, which are not SaaSS because they are
activities that necessarily involve other parties, so they can't be a
single party's 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/

Re: Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Jan 31, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Freitag, 30. Januar 2026, 03:09:19 Mitteleuropäische Normalzeit
> schrieb Alexandre Oliva:
>> On Jan 28, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>> 
>> >> Rendering control over a key piece of GNU to a hostile party is
>> >> obviously not being done for GNU's benefit, for GNU's sake, on its
>> >> behalf, or even in agreement with GNU leadership. 
>> 
>> > Please forgive my ignorance, but... What's so horrible about the 
>> > Linux Foundation?
>> 
>> It's controlled by GPL violators.

> [citation needed]

https://www.linuxfoundation.org/about/

Under that, see board membership, leadership, corporate members.

You'll probably be able to see a lot more than I can, because the site
is heavily javascrippled.

I recall seeing a screenshot that felt like a wall of shame of GPL
violations and disregard for users' freedom.


>> It's historically claimed GNU packages to be its own Linux thing.

> [citation needed]

Again, I refer you to that javascrippled website, but I recall seeing
public certification, training and whatnot projects there that referred
by name to GNU packages typically included in GNU/Linux distros as parts
of "Linux".

I guess I could also refer you to this email (message-id) as evidence of
(downstream?) influence of the GNU-erasing campaign they participate in:
<3438495.44csPzL39Z@noumea>

Particularly the following passage:

> That said, GNU isn't really reluctant to claim the entire Linux its own.

Erhm.  Linux is a non-free kernel.  We have to maintain our own free
fork thereof, but we do give the credit that's due by naming that GNU
package as Linux-libre.  We don't claim Linux, we claim GNU's
overwhelming majority of the combination of the GNU operating system
with the kernel Linux.

The non-kernel pieces of the operating system included in typical
GNU/Linux distros are not Linux, by the simple fact that they aren't
part of the kernel distributed as linux-v$KV.tar.*, despite LF's and
others' attempts to label them as such.


>> It's historically worked hard to erase GNU from history.

> [citation needed]

Search for "site:linuxfoundation.org GNU" on your favorite web search
engine, and contrast that with the amount of GNU software that they
claim to be part of "Linux".

Also look at this thread and the strong push for LF to progressively
coopt and swallow key GNU packages, the few that they used to recognize
as GNU.


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

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

On Jan 28, 2026, David Edelsohn <dje.gcc@gmail.com> wrote:

> The mission of the GNU Project shouldn't expand and shift based
> on the loudest voices.

It needs not and should not expand or shift.

It shouldn't shrink either, even if people who don't get software
freedom gang up to do so.

I see you don't approve of persistent dissent.

Do you approve of crowding upon dissenters?

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Gabriel Ravier]

On 2/1/26 6:24 PM, Alexandre Oliva wrote:
> On Jan 31, 2026, Simon Marchi <simark@simark.ca> wrote:
>
>> On 2026-01-31 02:11, Alexandre Oliva via Overseers wrote:
>>> Do you have any plans to avoid the SaaSS features of typical forges?
>> Can you explain what the SaaSS features of typical forges are?
> I don't have an exhaustive list, but the computing activities that first
> come to mind, that I've already mentioned in this thread, are patch
> merging and CI/CD.
>
> There may be more, even though most of the computing done by forges is
> publishing and communication, which are not SaaSS because they are
> activities that necessarily involve other parties, so they can't be a
> single party's computing.
>
I don't get what the issue with patch merging is, exactly. It is an 
operation which the user can easily fall back to doing on their own 
machine (i.e. running git merge/apply/am themselves), of which the user 
already has to transmit all the data involved to the server even if they 
do it themselves (that is, the information transmitted to the server 
when doing a merge locally and when doing it on the server directly is 
the same), and which is trivially verifiable by them (if the server did 
something else than what would have been done locally, this would be 
trivially detectable and pretty systematically so, too). I would have 
assumed SaaSS was the result of, at the very least, one of these things 
being false.

Re: CTI - Making a decision for glibc.

[Arsen Arsenović]

-text follows this line--
<#secure method=pgpmime mode=sign>
Hi,

Alexandre Oliva <oliva@gnu.org> writes:

> On Jan 28, 2026, DJ Delorie <dj@redhat.com> wrote:
>
>> Sourceware is also SaaSS
>
> I believe that's correct, overall.  It is concerning indeed.

I see no valid concern in the Sourceware context (and, even by the looks
of it, in the CTI/LF context.  I'm not a fan of the LF, and I'd prefer
personally if nothing moved to their infrastructure, but Andreas is
right in that my opinion on the matter doesn't actually count as I'm an
infrequent contributor, and LF seems to be okay with respecting the
requirements we do have).

I, frankly, support offloading (substituting, if you will) work of
maintainers onto (with) Sourceware infrastructure.

The infrastructure need be Free, of course, and the processes
reproducible (for practical and principal reasons), but it is not "good"
to require drudgery from contributors.  And it is.

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

> AFAIK we (glibc) are not using any of its SaaSSs.
>
>> so we should immediately move off it
>
> If we are using any of its SaaSSs, discontinuing their use is probably
> much saner than rushing to move out, especially to a provider that
> would make that worse.
>
>> running gcc-as-a-service on my web site
>
> Yeah, that sounds like SaaSS to me.

It sounds practically insignificant to me.  I have to say that I'd have
rejected the request.

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.

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 has nothing to do with "propriatary" and everything to do with
>> whether someone else's computer is running the software you use.
>
> It's not so much about whose computer it is, but about who has control
> over it.
>
> Using a rented computer from a VPS is not SaaSS, if you control it.
>
> Hiring services controlled by others to do your own computing is SaaSS.
>
> Publishing a GIT repository (publishing) or hosting a mailing list
> (communication and publishing) are not SaaSS.
>
> 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.

Pushing this to contributors means no contributors can ever actually
contribute, as very few have access to the cfarm, and getting cfarm
access is too high a barrier to entry, or that they simply don't test
extensively (as happens in practice).

Pushing this onto maintainers is frankly a waste of scarce time of
already overburdened people.

Pushing this drudgery, these steps that can be performed perfectly
automatically, onto a machine, is exactly the right thing to do.  This
reduces maintainer load and *INCREASES* quality, as the chance of error
is significantly lowered.  As we expect contributors to be, well,
people, in different circumstances, these machines logically fall into
the hands of their common factor: the project being contributed to.

Obviously, this doesn't mean that contributors shouldn't or couldn't run
tests.  That'd be ridiculous.  But, as a real-world example, I frankly
don't want to have to deal with, say, AIX, while developing a patch.
Issues with my patches on AIX et al. can be discovered by an automated
system without wasting my time in the happy path.  The same tools that
such an automation (commonly called CI) would use are already present in
the GCC repository and would be invokable by me on the cfarm AIX machine
(assuming it's still around; I haven't checked).

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.

Have a lovely night.
-- 
Arsen Arsenović

Re: Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Maxim Kuvyrkov]

> On Feb 2, 2026, at 06:46, Alexandre Oliva <oliva@gnu.org> wrote:
> 
> On Jan 31, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 
>> Am Freitag, 30. Januar 2026, 03:09:19 Mitteleuropäische Normalzeit
>> schrieb Alexandre Oliva:
>>> On Jan 28, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>>> 
>>>>> Rendering control over a key piece of GNU to a hostile party is
>>>>> obviously not being done for GNU's benefit, for GNU's sake, on its
>>>>> behalf, or even in agreement with GNU leadership. 
>>> 
>>>> Please forgive my ignorance, but... What's so horrible about the 
>>>> Linux Foundation?
>>> 
>>> It's controlled by GPL violators.
> 
>> [citation needed]
> 
> https://www.linuxfoundation.org/about/
> 
> Under that, see board membership, leadership, corporate members.
> 
> You'll probably be able to see a lot more than I can, because the site
> is heavily javascrippled.
> 
> I recall seeing a screenshot that felt like a wall of shame of GPL
> violations and disregard for users' freedom.

Alexandre,

Could you, please, clarify, what do you mean by "controlled" in "It's controlled by GPL violators." ?

My viewing of https://www.linuxfoundation.org/about/members shows hundreds of companies big and small.

Are they the ones controlling LF?

Are all of them present GPL violators?

Are some of them present GPL violators?

Do you have knowledge of present GPL violators having majority control of LF?


My point here is that if one takes a large-enough set of companies, there ought to be some better and some worse companies in that set by whatever metric one selects.  However, making a conclusion that the worst of the set define the properties of the whole set is just a logical error.

Looking at it from a business point of view: if LF was controlled by a small of companies -- whether GPL violators or some other small set -- it would not make business sense for the other hundreds of companies to join a foundation where their voices would not be heard.  Since that's NOT the observed case -- LF, indeed, has hundreds of members -- I don't think your statement is accurate.


Finally, I do appreciate and consider your position and your opinion in this discussion, it brings a different-than-mine perspective.  I do, however, find it difficult to consider strong statements, which could be shown to be partially incorrect.  It is difficult for me to distinguish what you say as your opinion from what you state as an objective fact.  I, personally, like to add terms like "may be", "in my opinion", etc. when I present my opinion.  And I try to add citations and references when I'm stating an objective fact.

Kind regards,

--
Maxim Kuvyrkov
https://www.linaro.org


> 
> 
>>> It's historically claimed GNU packages to be its own Linux thing.
> 
>> [citation needed]
> 
> Again, I refer you to that javascrippled website, but I recall seeing
> public certification, training and whatnot projects there that referred
> by name to GNU packages typically included in GNU/Linux distros as parts
> of "Linux".
> 
> I guess I could also refer you to this email (message-id) as evidence of
> (downstream?) influence of the GNU-erasing campaign they participate in:
> <3438495.44csPzL39Z@noumea>
> 
> Particularly the following passage:
> 
>> That said, GNU isn't really reluctant to claim the entire Linux its own.
> 
> Erhm.  Linux is a non-free kernel.  We have to maintain our own free
> fork thereof, but we do give the credit that's due by naming that GNU
> package as Linux-libre.  We don't claim Linux, we claim GNU's
> overwhelming majority of the combination of the GNU operating system
> with the kernel Linux.
> 
> The non-kernel pieces of the operating system included in typical
> GNU/Linux distros are not Linux, by the simple fact that they aren't
> part of the kernel distributed as linux-v$KV.tar.*, despite LF's and
> others' attempts to label them as such.
> 
> 
>>> It's historically worked hard to erase GNU from history.
> 
>> [citation needed]
> 
> Search for "site:linuxfoundation.org GNU" on your favorite web search
> engine, and contrast that with the amount of GNU software that they
> claim to be part of "Linux".
> 
> Also look at this thread and the strong push for LF to progressively
> coopt and swallow key GNU packages, the few that they used to recognize
> as GNU.
> 
> 
> -- 
> 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/

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Florian Weimer]

* Alexandre Oliva via Overseers:

> On Jan 31, 2026, Simon Marchi <simark@simark.ca> wrote:
>
>> On 2026-01-31 02:11, Alexandre Oliva via Overseers wrote:
>>> Do you have any plans to avoid the SaaSS features of typical forges?
>
>> Can you explain what the SaaSS features of typical forges are?
>
> I don't have an exhaustive list, but the computing activities that first
> come to mind, that I've already mentioned in this thread, are patch
> merging and CI/CD.

I don't understand this kind of objection.

It's pretty much a given that in a functioning developer community that
people run software on their machines on your behalf, even if you could
in theory run the testing locally on your own hardware (if you owned
such hardware).  CI/CD merely automates that process.  Of course it
cedes control, but without that, collaboration isn't possible.

Keep in mind that they I don't think there should be a firm line between
developers and users.  I believe software freedom requires that users
can turn into developers.  Forges and CI/CD can be an important tool to
enabled.  I'm rather sad that the users-to-developers idea is somewhat
controversial within the GNU project (and my impression is not mainly
based on opposition to forges, it's that many components are so very
difficult to build from source on common platforms).

Thanks,
Florian

Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Mark Wielaard]

Hi All,

On Fri, Jan 30, 2026 at 02:13:57AM +0100, Zoë Kooyman via Overseers wrote:
> On 1/29/26 18:05, Karen M. Sandler wrote:
> >On 2026-01-29 10:20, Mark Wielaard wrote:
> >>I have added Karen Sandler, the SFC Director, Zoë Kooyman, the FSF
> >>Director and Ian Kelling, the FSF president, sysadmin and of course
> >>Sourceware PLC member to the CC. I'll meet them this weekend at Fosdem
> >>and they might be able to help you with some of your questions about
> >>coordinating funding for hosting to help us with making a decision for
> >>glibc.
> >
> >Yes, I would be happy to discuss this at FOSDEM.
> >
> Yes, I would be available as well.

Thanks so much for meeting with me, but especially meeting and talking
to each other at Fosdem. Which was wonderful, but also very chaotic
(in a good way!)

I had a really nice chat with Kris Borchers (added to CC) from the
OpenSSF/LF. Zoë and Kris made an appointment to discuss the situation
and what are appropriate followup steps.

I think everybody agreed that breaking off existing services from
Sourceware would be very painful and counterproductive if done for no
good reason. But that if other foundations do have the money to
provide additional mirrors of existing services, provide additional
hardware for build/CI servers or money to hire staff/contractors to
assist the community running the services that would certainly be
appreciated.

There seems to be real confusion about the necessity of setting up yet
another "foundation" to handle the funding for the community or
whether (directed funding) to hiring extra staff or contractors to
assist the community in doing more tasks was possible. As Karen
explained the existing foundations/funds can of course handle that,
even for really big corporations (which in general already have good
relationships with the existing foundations).

But there was also some criticism (even from our own fiscal sponsor)
of the Sourceware Project Leadership Committee for not being more
proactive and ambitious about publishing budgets and plans that could
use funding. So Tracy, Bradley (from the SFC) and I sat down to write
down a budget for the current running costs and as if we would hire
contractors/payed staff to fund all our plans. The Sourceware PLC will
work those out and present them to the community, OpenSSF and others
to consider.

It is unfortunate that it takes meeting in person to get some heat out
of the discussion. Various glibc developers I spoke to seemed kind of
afraid to engage in a 100+ message thread. Some said they didn't
engage because they felt there was no need for change since things
were fine and they had seen these ideas before. Since there was no
real plan for any transition, it would probably all go away anyway
(for better or worse). Some felt their voice didn't count because they
weren't paid full time to work on glibc. Some felt they (where "they"
ranged from me personally, to the corporate industrial complex) had
already ruined what little there was left of the Free Software
community around glibc. I hope I can share a little from all sides in
this discussion (hopefully without adding another 100 messages to this
already long thread). Thanks to those who talked honestly with
me. Meeting face to face it was clear people weren't really angry, but
clearly disappointed and sad about the tone on the list and at people
talking at/past each other. Lets see if we can change that.

One thing that I hadn't heard/realized before is how much people
appreciate the glibc Weekly Patch Review meetings. Even though (or
maybe precisely because?) it takes place at a fixed time during US
working hours. People really don't want to loose that. So in case it
is necessary the SFC has offered the use of their BBB server to run
such meetings to all Sourceware hosted projects (some other Sourceware
hosted projects are already using it). https://bbb.sfconservancy.org/
Please ask if you want an account to setup such meetings.

Cheers,

Mark

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Siddhesh Poyarekar]

On 2026-02-02 09:38, Mark Wielaard wrote:
> were fine and they had seen these ideas before. Since there was no
> real plan for any transition, it would probably all go away anyway
> (for better or worse). Some felt their voice didn't count because they

There's a lot to unpack in what you've written and I can't engage with 
it all right now, but really, please stop saying this.  The original 
email is quite clear in its intent, backed publicly by a significant 
number of GNU toolchain contributors and maintainers and you constantly 
misrepresenting the situation is not helping things at all.

Sid

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[DJ Delorie]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> On 2026-02-02 09:38, Mark Wielaard wrote:
>> were fine and they had seen these ideas before. Since there was no
>> real plan for any transition, it would probably all go away anyway
>> (for better or worse). Some felt their voice didn't count because they
>
> There's a lot to unpack in what you've written and I can't engage with 
> it all right now, but really, please stop saying this.  The original 
> email is quite clear in its intent, backed publicly by a significant 
> number of GNU toolchain contributors and maintainers and you constantly 
> misrepresenting the situation is not helping things at all.

Please assume good intent here.  I read mjw's comment as "some people
think that since there was no real plan...", which is a perfectly valid
thing to report on.

And while you say intents are clear, I'm one of the doubters.  Folks
have been "clear on intent" for years now, but it's all behind the
scenes and so far nothing has come of it.  From the point of view of the
regular contributors, all we see is two sides saying "our side is better
and we're doing things our way" but such anti-discussions do not
generate trust and confidence that something useful will happen.

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Joseph Myers]

On Mon, 2 Feb 2026, Mark Wielaard wrote:

> I think everybody agreed that breaking off existing services from
> Sourceware would be very painful and counterproductive if done for no
> good reason. But that if other foundations do have the money to

The main thing that needs a lot of work and changes to how services 
operate internally, and sometimes to the hostnames people use to access 
them, is simply isolating services properly from each other, which I 
consider essential security work that should have been done long before I 
raised it at the 2022 Cauldron.  The physical location of those services 
makes much less difference, except that the LF is already set up to run 
various key services in an isolated setup - whereas, as I said at Cauldron 
2022, anything that isolates the services used by the toolchain into maybe 
50 separate VMs would look very different to Sourceware as it was then.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[DJ Delorie]

Joseph Myers <josmyers@redhat.com> writes:
> The main thing that needs a lot of work and changes to how services 
> operate internally, and sometimes to the hostnames people use to access 
> them,

gcc already has gcc.sourceware.org

We could add a glibc.sourceware.org etc.

Even if we don't split up the machine, at least we can get the world
used to using the project-specific dns names, making future changes
easier.

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Joseph Myers]

On Mon, 2 Feb 2026, DJ Delorie wrote:

> Joseph Myers <josmyers@redhat.com> writes:
> > The main thing that needs a lot of work and changes to how services 
> > operate internally, and sometimes to the hostnames people use to access 
> > them,
> 
> gcc already has gcc.sourceware.org
> 
> We could add a glibc.sourceware.org etc.
> 
> Even if we don't split up the machine, at least we can get the world
> used to using the project-specific dns names, making future changes
> easier.

That's potentially (project, service)-specific (e.g. 
bugzilla.glibc.sourceware.org; or different names for git write access 
versus anonymous read access).

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

DJ Delorie <dj@redhat.com> writes:

> Joseph Myers <josmyers@redhat.com> writes:
>> The main thing that needs a lot of work and changes to how services 
>> operate internally, and sometimes to the hostnames people use to access 
>> them,
>
> gcc already has gcc.sourceware.org
>
> We could add a glibc.sourceware.org etc.
>
> Even if we don't split up the machine, at least we can get the world
> used to using the project-specific dns names, making future changes
> easier.

I'm actually somewhat of the opposite stance.

Such splitting per-project is more theater than security IMO.
Obviously, isolating otherwise services by e.g. containerizing them has
a real security effect, but I doubt splitting by project does especially
when e.g. editbugs is granted automatically based on email, which anyone
on one project has on the others.  Similarly, there's an effect to be
gained by centralizing authentication.

I'm of the opinion that in the long-term it'd be good to standardize
across and combine the toolchain projects into one.  This is no small
feat and won't likely ever fully happen, but there's clear overlap
(demonstrated by, for instance, somewhat frequently needing to resolve
PRs as MOVED to other projects), and the toolchain components share many
concerns (and can share code, and should share significantly more code
than they do right now, I think).

Have a lovely night.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Siddhesh Poyarekar]

On 2026-02-02 12:15, DJ Delorie wrote:
> Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>> On 2026-02-02 09:38, Mark Wielaard wrote:
>>> were fine and they had seen these ideas before. Since there was no
>>> real plan for any transition, it would probably all go away anyway
>>> (for better or worse). Some felt their voice didn't count because they
>>
>> There's a lot to unpack in what you've written and I can't engage with
>> it all right now, but really, please stop saying this.  The original
>> email is quite clear in its intent, backed publicly by a significant
>> number of GNU toolchain contributors and maintainers and you constantly
>> misrepresenting the situation is not helping things at all.
> 
> Please assume good intent here.  I read mjw's comment as "some people
> think that since there was no real plan...", which is a perfectly valid
> thing to report on.

I agree it's a valid thing to report on, but that has been repeated 
enough in this thread despite constant clarification to the contrary.

> And while you say intents are clear, I'm one of the doubters.  Folks
> have been "clear on intent" for years now, but it's all behind the
> scenes and so far nothing has come of it.  From the point of view of the
> regular contributors, all we see is two sides saying "our side is better
> and we're doing things our way" but such anti-discussions do not
> generate trust and confidence that something useful will happen.

I get that, and I agree that we share some of the blame for not being 
communicative enough (on my own part it's been mostly to spare myself 
the stress of these engagements since Mark rightly pointed out, they can 
be quite draining), but I thought the responses to this thread (we've 
worked *very* hard to get people at the table this time and not wait at 
the sidelines for something to happen) would have ended this speculation.

We've got the open office hours every Friday and we're trying to ensure 
that we continue the engagement this time, even if just to say that hey, 
this is on track and we're slowly getting closer to it.

Maybe I should have a cron job send out an email every fortnight with a 
reminder that we're doing this :)

Sid

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[DJ Delorie]

Arsen Arsenovi‡ <arsen@aarsen.me> writes:
> Such splitting per-project is more theater than security IMO.

I intended neither.  Keeping the URLs of the projects separate allows IT
to choose how to merge or isolate each project's services without having
to worry about changing the public face of each project, or retraining
users.  That's all.

As long as projects have common domains, IT's choices are more limited.

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[DJ Delorie]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> We've got the open office hours every Friday and we're trying to ensure 
> that we continue the engagement this time, even if just to say that hey, 
> this is on track and we're slowly getting closer to it.
>
> Maybe I should have a cron job send out an email every fortnight with a 
> reminder that we're doing this :)

Or send out the minutes of the open office hours every week?

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Siddhesh Poyarekar]

On 2026-02-02 19:17, DJ Delorie wrote:
> Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>> We've got the open office hours every Friday and we're trying to ensure
>> that we continue the engagement this time, even if just to say that hey,
>> this is on track and we're slowly getting closer to it.
>>
>> Maybe I should have a cron job send out an email every fortnight with a
>> reminder that we're doing this :)
> 
> Or send out the minutes of the open office hours every week?
> 

That's too easy, Carlos is already doing it :)

Sid

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  2, 2026, Florian Weimer <fweimer@redhat.com> wrote:

> * Alexandre Oliva via Overseers:
>> On Jan 31, 2026, Simon Marchi <simark@simark.ca> wrote:
>> 
>>> On 2026-01-31 02:11, Alexandre Oliva via Overseers wrote:
>>>> Do you have any plans to avoid the SaaSS features of typical forges?
>> 
>>> Can you explain what the SaaSS features of typical forges are?
>> 
>> I don't have an exhaustive list, but the computing activities that first
>> come to mind, that I've already mentioned in this thread, are patch
>> merging and CI/CD.

> I don't understand this kind of objection.

> It's pretty much a given that in a functioning developer community that
> people run software on their machines on your behalf, even if you could
> in theory run the testing locally on your own hardware (if you owned
> such hardware).  CI/CD merely automates that process.  Of course it
> cedes control, but without that, collaboration isn't possible.

It's not relevant who owns it, but who controls it.

when you do your own computing, you can do it on your own computer using
free software, then you have control over it.  Or you can rent or borrow
a computer that you can control, install free software on it, and do
your computing there, still under your control.

When we talk about a community's computing, the same things should
apply: the community can use its own computers, or it can rent or borrow
others' computers so that the community can install free software on it
and the ndo its computing under the community's control.

The problem is when the computing is done by computers under control of
third parties.  For this point, it doesn't matter whether the third
party is friendly or hostile, trustworthy or suspicious.  What matters
is that it is a third party, that control over the computing is not in
the community's hands.  Whether it's the FSF, the LF, Google, Oracle,
Microsoft, Amazon, or your friendly neighbor's app hosting service,
*they* would control our computing, while *we* should control it.

> Keep in mind that they I don't think there should be a firm line between
> developers and users.

I agree entirely with this point.  Indeed, you shouldn't assign the
point you disputed based on a false assumption to anyone or any group
just because of this false assumption, that would be misguided.

This point is also entirely irrelevant to the issue of SaaSS, I hope you
can see now.

> Forges and CI/CD can be an important tool to enabled.

CI can be done in a non-SaaSS way, by third parties who wish to
contribute to the community.  We see some of that in GCC.

Forges are an aggregate of too many disparate features to be able to
reason clearly about.  We should look at features individually to tell
which of them are clearly not SaaSS (publishing git repositories and web
pages, for example), which of them would be SaaSS if placed under
third-party control while doing the community's computing, and which of
them could be contributed by interested parties as their own computing,
ran under their own control, but in a way that benefits the community.

> I'm rather sad that the users-to-developers idea is somewhat
> controversial within the GNU project (and my impression is not mainly
> based on opposition to forges, it's that many components are so very
> difficult to build from source on common platforms).

GNU pretty much invented "./configure; make; make install".

That's how hard it typically is to build GNU software from sources, and
that's how easy it's supposed to be.

If that's not working for you, I wonder what you're trying to do, or how
you're trying to do it.

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  1, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:

> I don't get what the issue with patch merging is, exactly.

The issue is precisely that it's your computing, so you should do it
under your control.  If you do that under someone else's control, that's
the definition of SaaSS.

We can consider it the community's computing, at which point it should
run under the community's control.  If the Forge runs under the
community's control, that would be fine, it wouldn't be SaaSS.  But if
the Forge is controlled by a third party, then we have a freedom
problem, because it would be SaaSS.


> It is an operation which the user can easily fall back to doing on
> their own machine (i.e. running git merge/apply/am themselves), of
> which the user already has to transmit all the data involved to the
> server even if they do it themselves (that is, the information
> transmitted to the server when doing a merge locally and when doing it
> on the server directly is the same), and which is trivially verifiable
> by them (if the server did something else than what would have been
> done locally, this would be trivially detectable and pretty
> systematically so, too). I would have assumed SaaSS was the result of,
> at the very least, one of these things being false.

It's not.  Even if multiple people set out to build the same program in
a reproducible way, or to perform any other reproducible computation
that (by definition) yields the same results, each party's computing
ought to be done under the party's own control.

Maybe it shouldn't be that way.  I've been thinking lately, prompted by
this very thread and earlier iterations thereof, that it might make
sense to carve out an exception for such reproducible computations.  I'm
glad you seem to have grasped the notion of SaaSS and come to similar
thoughts that I have: we're probably on the same track to a useful
conclusion.

The end result I imagine is to be able to carve out another exception to
distinguish SaaSS from SaaS.  Just like publishing and mediation of
communications are not SaaSS because they're no single party's
computing, reproducible computations could also be reasonably argued to
be no single party's computing.

However, the line has to be drawn very carefully to avoid turning any
SaaS whatsoever into something you could do on your computer, but you do
under someone else's control and it's the same because you could have
done it on your computer.  There must be more than that for the
distinction and the exception to be useful, to avoid enabling a truck to
go through.

In my developing thoughts, publicity of the process [to the target
community] may be a requirement, so that anyone else [in the community],
or at least many third parties, could have all the data and the software
required to verify the results.

Perhaps some amount of statistical or competitive verification should
also be a requirement for it not to turn into blind trust, which would
IMHO make it SaaSS.

In order to make a useful and solid distinction, we also have to look at
the flip side, and have examples of computing that should *not* fit in
this exception, even if they could conceivably be reproduced on the
user's end.  This would help identify where to draw the line without
going too far either way.

Thanks for your collaboration,

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

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

Re: Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  1, 2026, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:

> Could you, please, clarify, what do you mean by "controlled" in "It's
> controlled by GPL violators." ?

I can try to hand wave a little further, but it probably won't be
convincing to you.

You look at the companies that fund the LF, you get a large number of
companies that ship products that contain Linux the kernel, but that
don't make corresponding sources available to those who buy their
products.  You get companies that make proprietary drivers that work
with the kernel Linux.  LF (board?) membership seems to be often
perceived as a licensing fee to overstep the permissions granted by the
GPL without consequences.

> Are some of them present GPL violators?

Depends on whom you ask, I guess.

Some will insist that, until they're sued and found to be, erhm, guilty
of violation, they are to be presumed innocent.  (This is not a matter
of criminal law, but you'll find such reasoning out there)

Some will buy their products and rationalize that they wouldn't use the
source code anyway, so why even bother trying to get it?

Some will try to get the sources and run into walls.

Some will see the proprietary drivers and conclude that they're proof of
GPL violation.  (that conclusion is not a given, but there you go)

Some will see the obnoxiously-licensed firmware (disguised binary blobs)
that still ship inside the kernel Linux so-called "sources", and
conclude (also not a given) that Torvalds himself would be violating the
GPL if these blobs actually existed.  They do, but the conclusion
doesn't follow.  It is hostile to user freedom nevertheless, and so is
the dependence on blobs distributed separately.

Some will look at all the SaaSS, and all programs that LF
controllers/members use to deny users freedom, and see a pattern of
misalignment with the ideals of Free Software, and even with those of
Open Source, wherein Linux is at best a commoditized layer they can use
to push their proprietary or SaaSS stuff with.

> Do you have knowledge of present GPL violators having majority control of LF?

I can't even view their web pages, because their server demands me to
(automatically) install and run software under their control on my own
computer.  Software that would be nonfree to me, because it's under
their control.  I won't allow that, so I can't even see what's there.
That's how freedom-unfriendly they are to me.

But I can see (some of) their public actions, and how they (fail to)
align with the notions of software freedom.

> My point here is that if one takes a large-enough set of companies,
> there ought to be some better and some worse companies in that set by
> whatever metric one selects.

Point taken.

It could be that it's not the controlling community of companies that is
freedom-hostile.  It could be that LF is freedom-hostile out of its own
volition (if there is such a thing), and that the controlling community
of companies merely tolerates that for whatever reason.

That alternative doesn't offer me much relief, to be honest.

> Looking at it from a business point of view: if LF was controlled by a
> small of companies -- whether GPL violators or some other small set --
> it would not make business sense for the other hundreds of companies
> to join a foundation where their voices would not be heard.  Since
> that's NOT the observed case -- LF, indeed, has hundreds of members --
> I don't think your statement is accurate.

I don't see that their voices aren't heard.  I mean, not literally, but
it's pretty clear to me that the LF promotes the business interests of
those who exploit FLOSS in ways that aren't exactly respectful of users
freedom.  It makes perfect sense for such businesses to fund the LF and
make it stronger, because they're aligned.

What they aren't aligned with is software freedom.
And that's my gripe with them all.

> I do, however, find it difficult to consider strong statements, which
> could be shown to be partially incorrect.  It is difficult for me to
> distinguish what you say as your opinion from what you state as an
> objective fact.

That's fair.

I'm surprised it's not widely-known that the LF is more friendly to
exploitative business intersts than to software freedom.

But then, I guess I shouldn't be surprised.  A lot of people here don't
(or hopefully didn't) even get that SaaSS is fundamentally opposite to
software freedom.

You know that the kernel Linux, that gives the LF its name, contains
obnoxiously-licensed programs disguised as source code, don't you?

You know that the LF claims all GNU software typically included in
GNU/Linux distros to be "Linux", right?

You know nearly all (dare I say actually all?) LF members distribute
nonfree software and/or offer SaaSS?  (Could anyone expect the
organization they collectivey "own" to be any different?)

I mean, these are such obvious truths to me that what you ask of me is
like asking me to prove that 2+2=4.

So people who claim or show alignment with the LF come across to me as
bringing the hostility that the LF has historically had to software
freedom, to the free software movement, and to GNU.

But maybe they don't mean that.  Maybe they don't know.  Maybe because
they don't know they think the LF could be friendly, and even an ally in
the pursuit of software freedom for all.

But then they listen to the LF, who uses carefully crafted language
stating "it's going to be FOSS", without saying "it's going to respect
your freedom", which those who can't tell the difference might mistake
for the same.  And they won't listen to me when I try to point out the
difference.  At which point, whether or not they meant to be hostile at
first, they end up being hostile to me and to software freedom.

> I, personally, like to add terms like "may be", "in
> my opinion", etc. when I present my opinion.  And I try to add
> citations and references when I'm stating an objective fact.

That's good advice.  I wish I could follow it.

I mean, I know I can't lie (so if I state something as fact, I believe
it to be so), but I can be wrong, so it would be good to follow it.

Alas, very often, I find that I can't.

Quite often it's because I'm not organized to save my sources and
references to be able to find them when needed.  I merge the new facts
with my prior knowledge and go from there, and then, later on, if I try
to find where I got a certain piece of information, I fail to find it.

Sometimes it's because the resources are just inaccessible to me (like
LF's webpages), or, in rare cases, I've been shown something in
confidence and I'm not in possession of a copy, or I'm not allowed to
share the evidence (it hurts when this happens).

In other circumstances, I am not prevented from showing it, except by my
own conscience.  For example, when people ask me for proof that Linux
contains nonfree software, I face a hard time, because I know exactly
where that is, but I refuse to direct people at nonfree software.

Sucks to be me, I guess :-/

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

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Mark Wielaard]

Hi DJ, Hi Sid,

On Mon, Feb 02, 2026 at 12:15:27PM -0500, DJ Delorie wrote:
> Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> > On 2026-02-02 09:38, Mark Wielaard wrote:
> >> were fine and they had seen these ideas before. Since there was no
> >> real plan for any transition, it would probably all go away anyway
> >> (for better or worse). Some felt their voice didn't count because they
> >
> > There's a lot to unpack in what you've written and I can't engage with 
> > it all right now

Please don't feel like you have to, the summary was meant to be just
that. An overview of what was discussed (in a very ad-hoc matter) and
what is being worked on to see if we can resolve some disagreements
and/or confusion. Hopefully without raising the temperature of this
thread.

> , but really, please stop saying this.  The original 
> > email is quite clear in its intent, backed publicly by a significant 
> > number of GNU toolchain contributors and maintainers and you constantly 
> > misrepresenting the situation is not helping things at all.
> 
> Please assume good intent here.  I read mjw's comment as "some people
> think that since there was no real plan...", which is a perfectly valid
> thing to report on.

Yes, I really didn't mean this as saying I agree or disagree with some
of the stuff people said. It is also a bit of a sanity check for
myself. I was glad that people did give me their opinion even if they
didn't wanted to "pick sides" as DJ calls it below. They even were
(brutally) honest to tell me what I was missing (without implying that
I was wrong, just that I have my blindspots). I hope you also see
that. But I think mainly people have seen this come up every couple of
years and feel they already know how it will play out, so they don't
feel they have to repeat their opinion yet again.

> And while you say intents are clear, I'm one of the doubters.  Folks
> have been "clear on intent" for years now, but it's all behind the
> scenes and so far nothing has come of it.  From the point of view of the
> regular contributors, all we see is two sides saying "our side is better
> and we're doing things our way" but such anti-discussions do not
> generate trust and confidence that something useful will happen.

Yeah, this is the problem. People don't want to choose sides they just
want to work together. I am really sad that it feels like this. It is
as if some minor misunderstandings over how to manage (community)
funding for infrastructure like Sourceware created totally opposing
groups of people in the same community about who is "right" in the
abstract.

We now have 3 "foundations" that want to help the community out. But
it is clear there is some serious confusion/conflict on what their
organizational roles are. So I was really happy that they managed to
come together at Fosdem and agreed to have a meeting about this.
Hopefully something good comes out of that.

Cheers,

Mark

Re: Fosdem Summary (Re: CTI - Making a decision for glibc.)

[Siddhesh Poyarekar]

On 2026-02-03 06:58, Mark Wielaard wrote:
> We now have 3 "foundations" that want to help the community out. But
> it is clear there is some serious confusion/conflict on what their
> organizational roles are. So I was really happy that they managed to
> come together at Fosdem and agreed to have a meeting about this.
> Hopefully something good comes out of that.

FWIW, I do hope additional funding comes the way of sourceware in 
future.  We need the kind of flexibility that sourceware provides to try 
out new tools and workflows.

Thanks,
Sid

Re: Hostile party WTF? (Re: CTI - Making a decision for glibc.)

[Carlos O'Donell]

On 2/1/26 8:44 PM, Maxim Kuvyrkov wrote:
> Looking at it from a business point of view: if LF was controlled by
> a small of companies -- whether GPL violators or some other small
> set -- it would not make business sense for the other hundreds of
> companies to join a foundation where their voices would not be
> heard.  Since that's NOT the observed case -- LF, indeed, has
> hundreds of members -- I don't think your statement is accurate.

Agreed.

Also as a chamber of commerce, any subset of that group of companies,
can work with us to support the GNU Toolchain financially *for
whatever internal reasons* (same as developers may have different
internal reasons for contributing) so long as they meet our
requirements.

The question at hand is if the GNU Toolchain, or glibc, can
negotiate such requirements effectively and get support from
sponsors. The answer to that question is a resounding "Yes." since
it's something we've been doing for decades at this point.

-- 
Cheers,
Carlos.

Re: CTI - Making a decision for glibc.

[Carlos O'Donell]

On 1/31/26 10:44 AM, Sachin Monga wrote:
> 
> On 29/01/26 3:42 am, Siddhesh Poyarekar wrote:
>> On 2026-01-28 16:45, Zack Weinberg wrote:
>>> 1. It's my impression that there are a small number of people
>>> (Carlos O'Donell, David Edelsohn, Joseph Myers, and possibly *no
>>> one else*) who feel strongly that glibc should move off of
>>> sourceware.org, and *everyone else* with a stake in the matter
>>> is somewhere on a spectrum between neutral and a strong belief
>>> that glibc *shouldn't* move, or at least, should not move to
>>> infrastructure hosted by the Linux Foundation.
>> 
>> If you're naming names it's Carlos O'Donell, David Edelsohn,
>> Joseph Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov,
>> Jeff Law and Andreas Huettel who have vocally supported the move
>> in this thread, while many others (who I hope will chime in too)
>> who contribute on a day to day basis, have expressed support
>> offline in the past.  Your base characterization of the situation
>> is flawed I'm afraid.
>> 
>> Sid
> 
> 
> As the powerpc port maintainer, I support this transition move and
> fully trust the repeated assurance that governance would remain the
> same.
> 
> This aligns with our needs for secure, sustainable infrastructure
> while preserving community control.

Thank you for your support Sachin!

-- 
Cheers,
Carlos.

Re: Mirror services (Re: CTI - Making a decision for glibc.)

[Carlos O'Donell]

On 1/30/26 11:06 AM, Mark Wielaard wrote:
> Hi Alex,
> 
> On Thu, Jan 29, 2026 at 11:26:06PM -0300, Alexandre Oliva wrote:
>> Maybe it would make sense to try them out with things that would be
>> actually useful, not risky, and not viable for our current providers to
>> offer, such as git and web mirrors run by separate organizations,
>> bringing about some of the redundancy that I mentioned as potentially
>> useful back when this started being discussed.
> 
> I think this is a good suggestion. Having (read-only) mirrors of git
> repos and the mailinglists seem like safe things the LF could provide
> that would add value. We can setup grokmirror for the git repos and
> the LF already knows how to handle public-inbox archives.

I agree.

In practice for a move for glibc we could retain the Sourceware git
repos as read-only grokmirror repos?

It was already suggested in the Office Hours for CTI that we could
start by mirroring GCC's repos to review the size requirements.

-- 
Cheers,
Carlos.

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Zack Weinberg]

On Mon, Feb 2, 2026, at 10:18 PM, Alexandre Oliva wrote:
> On Feb  1, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:
>
>> I don't get what the issue with patch merging is, exactly.
>
> The issue is precisely that it's your computing, so you should do it
> under your control.  If you do that under someone else's control,
> that's the definition of SaaSS.
>
> We can consider it the community's computing, at which point it should
> run under the community's control.  If the Forge runs under the
> community's control, that would be fine, it wouldn't be SaaSS.  But if
> the Forge is controlled by a third party, then we have a freedom
> problem, because it would be SaaSS.

This aspect of the argument is sufficiently esoteric to me that I need
to ask for clarification.

The thrust of the _rationale_ presented for avoiding SaaSS is that we're
giving up control over what software is used on the service provider's
machines and how it's configured, but this is a problem for services
provided by the community as well.  Savannah, for instance, is
unambiguously a service provided by the community.  Its Git server is
running an old version of sshd that doesn't understand SSH keys stored
on a hardware security module.  This forces me to keep an old, short,
RSA-based ssh key around on my personal computer, which is a security
issue for the entire community -- it would be significantly easier for
someone who cracked my PC to use that weak key to compromise Savannah
git repositories, than any other git repo I have push access to. I asked
the Savannah maintainers when sshd would be updated and was told that
there was no schedule for this.

Also, consider the Compile Farm.  It is run by people who I don't know
well, and who actively refused to update sshd on Farm machines, when I
made the same request to them.  They are probably within the "community"
if that is defined in a broad sense, but I do not see a good way to
define the boundary of "the community" such that it includes the Compile
Farm's maintainers but does not include the Linux Foundation.

So I don't currently see how insisting on avoiding use of services
provided by organizations who are more on the "open source" side of the
large "FLOSS" umbrella actually gains us much of anything in practical
terms, assuming Andrew Pinski's concerns re synchronous support are
addressed.

I'd appreciate any clarifications Alexandre, or anyone else taking the
same position, can provide.

zw

Re: CTI - Making a decision for glibc.

[Zack Weinberg]

On Wed, Jan 28, 2026, at 7:00 PM, Carlos O'Donell wrote:
> On 1/28/26 5:26 PM, Andrew Pinski wrote:
>> On Wed, Jan 28, 2026 at 2:13 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>>
>>> On 2026-01-28 16:45, Zack Weinberg wrote:
>>>> 1. It's my impression that there are a small number of people (Carlos
>>>>      O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
>>>>      who feel strongly that glibc should move off of sourceware.org, and
>>>>      *everyone else* with a stake in the matter is somewhere on a spectrum
>>>>      between neutral and a strong belief that glibc *shouldn't* move, or
>>>>      at least, should not move to infrastructure hosted by the Linux
>>>>      Foundation.
>>>
>>> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph
>>> Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and
>>> Andreas Huettel who have vocally supported the move in this thread,
>>> while many others (who I hope will chime in too) who contribute on a day
>>> to day basis, have expressed support offline in the past.  Your base
>>> characterization of the situation is flawed I'm afraid.

I regret the error.  It is difficult for me, as a very occasional
contributor who is way behind on the mailing list and cannot attend
any in-person meetings, to keep track of who is on what side of which
fence.

...
> A proposal should consider multiple factors.
>
> (1) Security.
> (2) Sponsorship.
> (3) Experience.
>
> Whoever implements the solution...

I cut all of Carlos’s exposition down to just this skeleton because I
want to make a very high level point:

The entire argument as he laid it out, reads to me as a solution
in search of a problem.

Again, I’m a very occasional contributor who is barely affected by any
of the things that have come up in this thread, and will be barely
affected by a move, if and when it happens.  But I’m just not seeing
enough of a reason put forward to *bother* moving glibc.  A variety of
problems with sourceware have been articulated, but all of them strike
me as *easier* to fix in situ than by moving to new infrastructure.
A desire for additional funding has been articulated, but the primary
reason I’m aware of why money would be needed, is to pay developers
to work more on glibc, and salaries should have no reason to be tied
to hosting for the canonical VCS repository and bug tracker.

So, as I said last time around: Proponents, please *explain your
reasons for seeking to move glibc*.  Not the criteria you chose
for evaluating funding and/or hosting source, but the reasons
why you were out there looking for funding and/or hosting sources
in the first place!

Explain how you have tried and failed to fix the technical issues
in situ; explain why it wouldn’t be *more work* to fix them in
conjunction with a move.  Explain what you plan to do with the money,
and why you consider “only if we also provide the hosting” an
acceptable condition attached to the money.

Go all the way back to the beginning of your thought process.
Be specific.  Be detailed.  Be candid.  Let the rest of us understand
your thinking.  Because right now, I repeat, knowing only what I know,
it seems to me that a move is *unnecessary*.

zw

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-02-03 13:54, Zack Weinberg wrote:
> Again, I’m a very occasional contributor who is barely affected by any
> of the things that have come up in this thread, and will be barely
> affected by a move, if and when it happens.  But I’m just not seeing
> enough of a reason put forward to *bother* moving glibc.  A variety of
> problems with sourceware have been articulated, but all of them strike
> me as *easier* to fix in situ than by moving to new infrastructure.

The trouble is that technical arguments are easy to argue in an email 
thread and non-technical ones are even easier to take personally and 
hence tend to either get overlooked or are subject to personal 
interpretation.

> A desire for additional funding has been articulated, but the primary
> reason I’m aware of why money would be needed, is to pay developers
> to work more on glibc, and salaries should have no reason to be tied
> to hosting for the canonical VCS repository and bug tracker.
> 
> So, as I said last time around: Proponents, please *explain your
> reasons for seeking to move glibc*.  Not the criteria you chose
> for evaluating funding and/or hosting source, but the reasons
> why you were out there looking for funding and/or hosting sources
> in the first place!
> 
> Explain how you have tried and failed to fix the technical issues
> in situ; explain why it wouldn’t be *more work* to fix them in
> conjunction with a move.  Explain what you plan to do with the money,
> and why you consider “only if we also provide the hosting” an
> acceptable condition attached to the money.
> 
> Go all the way back to the beginning of your thought process.
> Be specific.  Be detailed.  Be candid.  Let the rest of us understand
> your thinking.  Because right now, I repeat, knowing only what I know,
> it seems to me that a move is *unnecessary*.

OK, I'll bite.  Let me share my personal perspective.  It's candid (as 
you requested) and it is opinionated and hopefully spells out why I 
strongly back the migration of GNU toolchain services.  Others may have 
a different view of all of these events and I can live with that.

Anyway, here we go:

My first discussions around infrastructure were when I migrated my 
patchwork instance (patchwork.sourceware.org used to be 
patchwork.siddhesh.in until around 2014 IIRC) over to sourceware and 
started maintaining it, I'd say around 2015/2016.  I was feeling the 
discomfort of maintaining patchwork (Mark was very helpful, but it was 
still quite a bit of learning for both of us) and I expressed the 
concern in one of the Cauldrons that there were barely a handful of us 
doing this work in our spare time and that doesn't seem scalable, nor 
the fact that we're not really full time system administrators (I guess 
I'm not a "real programmer").

This was apparently a known concern for a while, especially because the 
infrastructure story was struggling on multiple fronts: the number of 
active volunteer overseers were dwindling (2 then and still the same 
now) and the sourceware hardware that hosts core services for the GNU 
toolchain was (and still is) funded solely by Red Hat, hosted in a Red 
Hat datacentre.  It was 2 machines then (3 now) including backups, 
running *all* of the core infrastructure.  Everything ran on those 
machines, alongside each other.  Compromising one service would mean 
pretty much everything would be compromised.  I remember Carlos talking 
about service isolation (and how we can't really do it on sourceware 
because we don't have the hardware capacity to do that) as far back as 
our first conversation in 2016 when I complained about patchwork 
maintenance.

David and Carlos had been working on getting funding for GNU toolchain 
projects for some time (e.g. the GNU Toolchain Fund[1]), and they 
started looking for funding sources for the infrastructure as well. 
Unfortunately we had the pandemic disruption which sent a lot of things 
awry but closer to around 2021/2022 things started to coalesce around an 
LF/OpenSSF solution, which is when I was again involved.

As we were doing this, there was news of upcoming FEDRAMP and rumours of 
a similar EU legislation and ISTM it made an excellent formal framing of 
the concerns we already had.  FWIW, you say that those issues could be 
fixed in situ, but they were summarily dismissed when we raised them in 
2022.  Changes have happened for the better over the years since, but 
they have been limited because there's no funding and people are working 
in their spare time to support this.

Having a registered vendor account with large companies is one thing and 
getting those large companies to actually pay up for a cause is quite 
another.  I've seen Carlos and David run from pillar to post all these 
years, trying to drum up sponsors for everything from the Cauldron to 
the infrastructure, it's hard and I know for a fact that what we've 
ended up with is not a solution looking for a problem.  It is a solution 
that neatly fits a problem that we've discussed for over a decade.

To conclude, I wanted a FOSS-friendly hosting solution that has full 
time specialists taking care of the infrastructure for the GNU toolchain 
and the OpenSSF/LF-IT solution provides exactly that.  I do not think a 
part time volunteer based maintenance model is a viable solution for 
hosting the toolchain infrastructure in the long term, not in terms of 
reliability, nor financial viability nor funding.  This is especially 
true with a community that is slowly dwindling.  Our users are working 
around our deficiencies; wolfi and others use mirrors for their 
downstream distros because sourceware cannot handle that load and in 
some cases, has outright banned their IPs.  We have disruptions that we 
take in our stride because we're friends helping friends, and friends 
cannot be ungrateful to friends by saying that their work is not enough. 
  I love that, and I greatly respect the work and the expertise of the 
overseers, but I also see it as a threat to the viability of the project.

Sid

[1] https://gcc.gnu.org/wiki/GNUToolchainFund

Re: CTI - Making a decision for glibc.

[Siddhesh Poyarekar]

On 2026-02-03 15:46, Siddhesh Poyarekar wrote:
> To conclude, I wanted a FOSS-friendly hosting solution that has full 
> time specialists taking care of the infrastructure for the GNU toolchain 
> and the OpenSSF/LF-IT solution provides exactly that.  I do not think a 

I forgot to add: full time specialists that are excellent citizens of 
the FOSS community.  For me personally, that is the clincher; I am quite 
glad that we'll have the likes of Konstantin and his team maintain our 
infrastructure, understand where we come from when we make our requests 
for FOSS-only tools and continually innovate in the open, as they do.

Sid

Re: CTI - Making a decision for glibc.

[Alexandre Oliva]

Thanks a lot for the writeup.

On Feb  3, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> I forgot to add: full time specialists that are excellent citizens of
> the FOSS community.  For me personally, that is the clincher; I am
> quite glad that we'll have the likes of Konstantin and his team
> maintain our infrastructure, understand where we come from when we
> make our requests for FOSS-only tools and continually innovate in the
> open, as they do.

I'd be happy to have him and the people in his team working in our
infrastructure, FWIW.

But see, I'm talking about the people, *not* the organization they work
for.

Because that makes a huge difference.

When we speak of having people's help to run our servers, those are
*our* servers.  We choose how to operate them, and tell the people
who're working for us so.  If people move on, or if they fail to live up
to the expectations, we part ways but keep the servers.  And the issues
of SaaSS don't come about, because our community's computing will be
running on servers under our communitary control.

Whereas when we speak of moving our computing into servers owned and
operated by third parties, that's not the case.  Whenever we consider
parting ways, the questions of where to move to, and of the cost
involved, necessarily come about.  Whenever they tell us they're moving
on, those questions come about with urgency.  We become utterly
dependent, we lose our autonomy, and thus become vulnerable to
arm-twisting, and not only through the control afforded to the operator
by means of SaaSS.

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  3, 2026, "Zack Weinberg" <zack@owlfolio.org> wrote:

> On Mon, Feb 2, 2026, at 10:18 PM, Alexandre Oliva wrote:
>> On Feb  1, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:
>> 
>>> I don't get what the issue with patch merging is, exactly.
>> 
>> The issue is precisely that it's your computing, so you should do it
>> under your control.  If you do that under someone else's control,
>> that's the definition of SaaSS.
>> 
>> We can consider it the community's computing, at which point it should
>> run under the community's control.  If the Forge runs under the
>> community's control, that would be fine, it wouldn't be SaaSS.  But if
>> the Forge is controlled by a third party, then we have a freedom
>> problem, because it would be SaaSS.

> The thrust of the _rationale_ presented for avoiding SaaSS is that we're
> giving up control over what software is used on the service provider's
> machines and how it's configured,

Not quite.  Those are practical consequences of that, but the core of
the argument against SaaSS is the same ethical argument against nonfree
software: you deserve control over your computing.  If it's your
computing, and you don't have control over it, whoever has that control
holds unjust power over you through your computing.

So the two questions that need to be asked to tell whether there's an
ethical problem and an injustice are:

1. whose computing is it, and

2. who controls it

If it's not the same person, the same party, the same group, that's the
freedom problem that the free software movement set out to solve.


When we speak of a community's computing, the community should control
it.  So programs it installs and runs on computers it operates should be
free software, and services provided by third parties should not be
SaaSS.


When we talk about communities, boundaries and governance matters, and
nesting structures also matter.

Say, a glibc test run could be conceived as your own computing, or as
glibc community's computing, or as GNU computing, or even as Free
Software community's computing, or even FLOSS computing or humankind
computing.

Some of these probably don't make much sense, but I mention them for
completeness.

Which of these is the right answer depends largely on intent, and on
belonging IMHO.

If you're running the tests for yourself, then it's your computing, even
if you will share the results with others.  So you should have control
over it.

If you're running the tests on behalf of any of these communities, as in
at its request, or under an assignment, then that's the community that
should have control over it.

So this is not about our being part of a huge community with fuzzy
boundaries.  We can and should be strict about who controls our
computing, including our computing devices, just as we can and should be
strict about who governs our community.  If we were to think of
"community" too broadly, we'd end up submitting our community's
governance and control over computing to the UNO or somesuch, and that
probably wouldn't do us good WRT our autonomy.

Does that make sense?  I think community boundaries make as much sense
when it comes governance and autonomy as when it comes to computing
autonomy.  The latter is part of governance and autonomy, after all.


Now, let's look at the concrete examples you named.


Savannah is operated by GNU Project's representatives, for the GNU
Project.  Whatever runs there is presumaby GNU Project's computing.
That said, most of what that server actually does is publishing and
mediating communication, that aren't regarded as any specific party's
computing, because at least two parties might claim it to be their own
computing, but they likely wouldn't have a stronger claim than the other
parties.  So those features can even be used by third parties who don't
belong to the GNU Project, without that being SaaSS for them.

When you ssh into Savannah, you're presumably engaged in GNU Project's
computing.  So it's reasonable for the GNU Project to have control over
that computing.  So it's not objectionable, freedom wise, that they
choose (or can't help) to keep running an old version of ssh on their
end.  It's also unfortunate that this requires you to keep a weak key on
your computers.  But it is their prerogative to decide what to run on
their servers, under their control.  Just as it is your prerogative to
decide what to install on yours.  Depending on decisions from both
parties, you may or may not be able to interact.

> Also, consider the Compile Farm.  It is run by people who I don't know
> well, and who actively refused to update sshd on Farm machines, when I
> made the same request to them.  They are probably within the "community"
> if that is defined in a broad sense

We are certainly part of the same broad community they are, but I don't
think they've ever submitted full control or governance over their
machines to us, so at another level we are different communities, and
they're entitled to control their machines as they wish, and to hand us
as much control as they like.

If they offer our community enough control that we can have control over
our own computing if it runs there, we can then use those computing
resources for our community's own computing and purposes.

If, however, they only offer access and control to individuals, who also
happen to be members of our community, then instead of an institutional
relationship, we'd have multiple individual relationships.  This may be
enough for individuals to run their own computing there, or even for the
community to assign individuals to run community computing there, but
would that be our community doing its computing there?  I'm not sure, I
don't think this is a settled matter, but I'm inclined to think that
this kind of arrangement might make the individual a provider of SaaSS
to the community, because ISTM the community wouldn't have control over
the computing, only the individual would.


So, you see, the issue of SaaSS is not at all about where in the FLOSS
spectrum the operator is.  The issue, first and foremost, is whether it
is SaaSS at all.  And then, if it is SaaSS, we shouldn't use it, but if
someone insists on using it anyway, then choosing a misaligned provider
aggravates the SaaSS problem, because it's not only relinquishing
control over our computing, it's turning the control over to a
misaligned party.

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

Re: Mirror services (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  3, 2026, "Carlos O'Donell" <carlos@redhat.com> wrote:

> On 1/30/26 11:06 AM, Mark Wielaard wrote:
>> Hi Alex,
>> On Thu, Jan 29, 2026 at 11:26:06PM -0300, Alexandre Oliva wrote:
>>> Maybe it would make sense to try them out with things that would be
>>> actually useful, not risky, and not viable for our current providers to
>>> offer, such as git and web mirrors run by separate organizations,
>>> bringing about some of the redundancy that I mentioned as potentially
>>> useful back when this started being discussed.
>> I think this is a good suggestion. Having (read-only) mirrors of git
>> repos and the mailinglists seem like safe things the LF could provide
>> that would add value. We can setup grokmirror for the git repos and
>> the LF already knows how to handle public-inbox archives.

> In practice for a move for glibc we could retain the Sourceware git
> repos as read-only grokmirror repos?

For avoidance of doubt, my suggestion was to set up a git mirror at the
LF, as an experiment, not to move the primary to the LF with a mirror at
Sourceware.  I'm not sure that got through.

Now, if it were up to me, we'd be going for live-replicated git hosting,
so you could push to or pull from any of them interchangeably.  I even
said that before, long ago.

Has anyone looked into https://radicle.xyz?  Maybe it could be used on
the server side to keep the repos in sync, so that people wouldn't
*have* to use radicle to collaborate, but they still *could* if we make
it so.  I may have mentioned this before, but I'm not sure.  I haven't
used it myself, but the idea behind it fascinates me.

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

[OT, attempt at humor] Compiler Explorer misuse

[Alexandre Oliva]

On Feb  3, 2026, Alexandre Oliva <oliva@gnu.org> wrote:

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

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

BTW, has anyone figured out how to use C++ Template metaprogramming to
mine cryptocurrencies on Compiler Explorer instances yet? :-)

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

Re: Mirror services (Re: CTI - Making a decision for glibc.)

[Mark Wielaard]

Hi Carlos,

On Tue, Feb 03, 2026 at 08:31:40AM -0500, Carlos O'Donell wrote:
> On 1/30/26 11:06 AM, Mark Wielaard wrote:
> >On Thu, Jan 29, 2026 at 11:26:06PM -0300, Alexandre Oliva wrote:
> >>Maybe it would make sense to try them out with things that would be
> >>actually useful, not risky, and not viable for our current providers to
> >>offer, such as git and web mirrors run by separate organizations,
> >>bringing about some of the redundancy that I mentioned as potentially
> >>useful back when this started being discussed.
> >
> >I think this is a good suggestion. Having (read-only) mirrors of git
> >repos and the mailinglists seem like safe things the LF could provide
> >that would add value. We can setup grokmirror for the git repos and
> >the LF already knows how to handle public-inbox archives.
> 
> I agree.
> 
> In practice for a move for glibc we could retain the Sourceware git
> repos as read-only grokmirror repos?

No. The suggestion is for the LF to setup mirrors for glibc and other
Sourceware hosted project git repositories. That would be something
nobody would find controversial and would be genuinely useful.

> It was already suggested in the Office Hours for CTI that we could
> start by mirroring GCC's repos to review the size requirements.

GCC is bigger than most other Sourceware hosted project repos, but not
the biggest. Take a look at the libabigail-tests, abidb or bunsendb
git repos for something that is.

Sourceware hosts a lot of git repositories both really small and
really big. So concretely if the LF wants to help out in a
non-controversial way then they would make everybody really happy by
setting up mirrors for all of them.

The 54 repositories listed here:
https://sourceware.org/cgit/
The 3600 cygwin repositories listed here:
https://sourceware.org/cgit/
The 3 gcc repostories listed here:
https://gcc.gnu.org/cgit/
And the 4 DWARF standard repositories:
https://git.dwarfstd.org/

Let me know if they are interested in that and if we can set things up
to make that as easy as possible for them.

Cheers,

Mark

Re: CTI - Making a decision for glibc.

[Mark Wielaard]

Hi Zack, Hi Sid,

On Tue, Feb 03, 2026 at 03:46:12PM -0500, Siddhesh Poyarekar wrote:
> On 2026-02-03 13:54, Zack Weinberg wrote:
> >But I’m just not seeing
> >enough of a reason put forward to *bother* moving glibc.  A variety of
> >problems with sourceware have been articulated, but all of them strike
> >me as *easier* to fix in situ than by moving to new infrastructure.

Thanks for asking these questions, I am also a bit puzzled. There
indeed seems to be some miscommunication going on. I'll try to listen,
but maybe I also should communicate better how Sourceware as an
organization works.

> >A desire for additional funding has been articulated, but the primary
> >reason I’m aware of why money would be needed, is to pay developers
> >to work more on glibc, and salaries should have no reason to be tied
> >to hosting for the canonical VCS repository and bug tracker.

I do note that additional funding is always appreciated. And the
Sourceware PLC (with the help of the SFC) have done pretty well
imho. https://sourceware.org/mission.html#plc

The whole transition from bare metal servers to having everything run
in (bigger) VMs was funded through a grant, individual donations and
(in kind) organizational/corporate sponsorship. We now also have an
hopefully sustainable hardware replacement fund so we are good for the
next couple of years with hardware (which is less critical now that we
can just move VMs around).

And I think there is a valid criticism that we don't publish budgets
for how to run some of the services with some extra paid staff. We did
create such a budget for the security plans a few years back
https://sourceware.org/sourceware-security-vision.html
And we discussed concrete numbers with the OpenSSF which seemed
interested in funding such plans. But in the end they said they
couldn't fund that. So I am happy to hear they now apparently do have
some funds available and we'll update the plans and budget and try to
reconnect (I had a nice chat with the OpenSSF program manager at
Fosdem).

Also Zoe, the FSF Director, is going to talk with the LF/OpenSSF about
funding for the GNU Toolchain. The FSF was created specifically to
fundraise for the GNU projects, so there are some legitimate questions
about moving that activity to some other entity.

> >So, as I said last time around: Proponents, please *explain your
> >reasons for seeking to move glibc*.  Not the criteria you chose
> >for evaluating funding and/or hosting source, but the reasons
> >why you were out there looking for funding and/or hosting sources
> >in the first place!
> >
> >Explain how you have tried and failed to fix the technical issues
> >in situ; explain why it wouldn’t be *more work* to fix them in
> >conjunction with a move.  Explain what you plan to do with the money,
> >and why you consider “only if we also provide the hosting” an
> >acceptable condition attached to the money.
> >
> >Go all the way back to the beginning of your thought process.
> >Be specific.  Be detailed.  Be candid.  Let the rest of us understand
> >your thinking.  Because right now, I repeat, knowing only what I know,
> >it seems to me that a move is *unnecessary*.
> 
> OK, I'll bite.  Let me share my personal perspective.  It's candid
> (as you requested) and it is opinionated and hopefully spells out
> why I strongly back the migration of GNU toolchain services.  Others
> may have a different view of all of these events and I can live with
> that.

I won't try to "correct" you, this is how you experienced things. I
obviously experienced them slightly differently. I'll just note that
some of the issues you encountered are entirely new to me. Please in
the future always communicate these. I am not saying they aren't
issues. In general the reported issues (especially with service
availability) are resolved within 24 hours. There are various ways to
report issues: https://sourceware.org/mission.html#organization

The Sourceware PLC does take the various cyber security regulations
serious and with the help of the SFC and FSFE we have been updating
our proposed policies and guidelines for hosted projects:
https://sourceware.org/cyber-security-faq.html

In general I think Sourceware would love to get more paid staff, but
in a sustainable way. We are updating our budget proposal for that
right now. We already have diverse funding through grants, individual
donations and (in kind) corporate and organizational sponsorship. More
is always welcome and we'll make sure companies can donate for
specific spends. The SFC already has those vendor accounts with large
companies setup precisely because those companies have already donated
through them for various projects.

Cheers,

Mark

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Am Mittwoch, 4. Februar 2026, 08:45:07 Mitteleuropäische Normalzeit schrieb Alexandre Oliva:
> 
> When you ssh into Savannah, you're presumably engaged in GNU Project's
> computing.  So it's reasonable for the GNU Project to have control over
> that computing.  So it's not objectionable, freedom wise, that they
> choose (or can't help) to keep running an old version of ssh on their
> end.  It's also unfortunate that this requires you to keep a weak key on
> your computers.  But it is their prerogative to decide what to run on
> their servers, under their control.  Just as it is your prerogative to
> decide what to install on yours.  Depending on decisions from both
> parties, you may or may not be able to interact.
> 

If the GNU Project has the freedom to run old version of ssh, then the
GPL luckily also provides the freedom to take a project elsewhere.
How about defending that freedom instead?

Sorry, but I'm getting seriously annoyed at the tetrapilotomy, and the
ideological discussions do *not* help the point of sourceware.

Here's an ELI5 version:

* Security-relevant world-facing software is outdated = BAD

* Not supporting the update because, uhm, ideology = WORSE

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 1018 bytes --]

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[DJ Delorie]

Alexandre Oliva <oliva@gnu.org> writes:
> but the core of the argument against SaaSS is the same ethical
> argument against nonfree software: you deserve control over your
> computing.

I'd like to take a moment to point out the irony here.  You tell us we
deserve control over our computing, then tell us we cannot choose how to
do our computing.  You tell us our computing must be in our control,
then tell us to cede that control to sourceware.

This is the problem with the SaaSS argument.  You can draw the line
wherever you like, to make whatever argument you like, but in the end
you don't really want the user to be free to do what they want.

So can we please stop using this argument as a hammer?  The LF people
can be just as much "on our team" as the Sourceware people, and when
things to bad, either can be just as much out of our control.

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  4, 2026, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> If the GNU Project has the freedom to run old version of ssh, then the
> GPL luckily also provides the freedom to take a project elsewhere.

This is not a software licensing matter.  Software licenses won't help
you with that.  I realize you're just snapping out of miscommunication.


> * Security-relevant world-facing software is outdated = BAD

I've seen enough fake claims of security be used to push user-hostile
and user-controlling software (*) to doubt such absolutes, but I agree
with the jist of it when it's not security theater that trades user
security in favor of supplier security, like imposed software tends to
do, because users get no security from (as in against) the supplier with
such arrangements.

(*) Think banking software and protocols that used to work on secure
computers, but that gets phased out in favor of software that demands a
leaky and remotely-controlled snoop phone.  That's presented as
security, but it's the opposite of that.


> * Not supporting the update because, uhm, ideology = WORSE

Woah, woah, woah.  What kind of projection is that, to claim I don't
support it?  Where did you get that false notion?  Surely it wasn't from
my philosophical analysis of who should be in charge of what.  That kind
of made-up accusation is not cool.


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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  4, 2026, DJ Delorie <dj@redhat.com> wrote:

> Alexandre Oliva <oliva@gnu.org> writes:
>> but the core of the argument against SaaSS is the same ethical
>> argument against nonfree software: you deserve control over your
>> computing.

> I'd like to take a moment to point out the irony here.  You tell us we
> deserve control over our computing, then tell us we cannot choose how to
> do our computing.  You tell us our computing must be in our control,
> then tell us to cede that control to sourceware.

No, that's a misunderstanding, and a misrepresentation of what I'm
saying.

We're not doing our computing on Sourceware.  The services we're using
aren't SaaSS, to the best of my knowledge, they're publishing and
communication, which aren't our computing, so relying on a third party
for them doesn't affect our control over our computing.

If we were to start using SaaSS from Sourceware, from Codeberg, or even
from the FSF, you could expect about as much opposition from me as in
this case.  Ok, maybe not as much because I have other reasons to
dislike and distrust the LF, even WRT services that aren't SaaSS.

> This is the problem with the SaaSS argument.  You can draw the line
> wherever you like, to make whatever argument you like, but in the end
> you don't really want the user to be free to do what they want.

That's the age old philosophical argument of the supposed freedom to
enslave oneself.  Once you admit the existence of such a freedom and
exercise it, you're no longer free.

I want users, including ourselves, to keep our freedom, so that we don't
make poor choices today that curtail our present and future freedom, by
giving others power over us and those who come after us in the community.


I disregard the rest of your argument because it was built on an unsound
premise.


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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Gabriel Ravier]

On 2/5/26 9:29 PM, Alexandre Oliva wrote:
> On Feb  4, 2026, DJ Delorie <dj@redhat.com> wrote:
>
>> Alexandre Oliva <oliva@gnu.org> writes:
>>> but the core of the argument against SaaSS is the same ethical
>>> argument against nonfree software: you deserve control over your
>>> computing.
>> I'd like to take a moment to point out the irony here.  You tell us we
>> deserve control over our computing, then tell us we cannot choose how to
>> do our computing.  You tell us our computing must be in our control,
>> then tell us to cede that control to sourceware.
> No, that's a misunderstanding, and a misrepresentation of what I'm
> saying.
>
> We're not doing our computing on Sourceware.  The services we're using
> aren't SaaSS, to the best of my knowledge, they're publishing and
> communication, which aren't our computing, so relying on a third party
> for them doesn't affect our control over our computing.
>
> If we were to start using SaaSS from Sourceware, from Codeberg, or even
> from the FSF, you could expect about as much opposition from me as in
> this case.  Ok, maybe not as much because I have other reasons to
> dislike and distrust the LF, even WRT services that aren't SaaSS.


Wait, so what about the transition is SaaSS, then ? Does the transition 
also involve using a bunch of new LF services (with no currently-used 
Sourceware equivalent) that you would consider SaaSS ? Or are certain 
(otherwise identical) services that are not SaaSS when done on 
Sourceware but are SaaSS when done on LF ? Or is the fear that glibc 
*might* end up using SaaSS from LF in the future ???


>
>> This is the problem with the SaaSS argument.  You can draw the line
>> wherever you like, to make whatever argument you like, but in the end
>> you don't really want the user to be free to do what they want.
> That's the age old philosophical argument of the supposed freedom to
> enslave oneself.  Once you admit the existence of such a freedom and
> exercise it, you're no longer free.
>
> I want users, including ourselves, to keep our freedom, so that we don't
> make poor choices today that curtail our present and future freedom, by
> giving others power over us and those who come after us in the community.
>
>
> I disregard the rest of your argument because it was built on an unsound
> premise.
>
>

I will say, I think that SaaSS and slavery aren't exactly comparable.

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Florian Weimer]

* Alexandre Oliva via Overseers:

> We're not doing our computing on Sourceware.  The services we're using
> aren't SaaSS, to the best of my knowledge, they're publishing and
> communication, which aren't our computing, so relying on a third party
> for them doesn't affect our control over our computing.

We have buildbots for post-commit CI on Sourceware.  The pre-commit CI
through Patchwork has builders, too, but they do not run on Sourceware
infrastructure AFAIK.

Thanks,
Florian

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  6, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:

> Wait, so what about the transition is SaaSS, then ?

TBH, I don't really know.  I was worried because nobody seemed to be
taking this possibility into account, and it looks like I was right, and
that it's already much worse than I thought.

> Or are certain (otherwise identical) services that are not SaaSS when
> done on Sourceware but are SaaSS when done on LF ?

No, the only ways to make them non-SaaSS would be for them to run under
our control, for them to be someone else's computing, or for them not to
run at all.

> Or is the fear that glibc *might* end up using SaaSS from LF in the
> future ???

Yeah, this has been largely my concern.  The intentions I heard about
made me very worried that these concerns weren't even in the radar, and
that's a sure way to make mistakes that will cost us our freedom and our
autonomy.  Since the whole thing already sounded like bait for a power
grab, there was plenty of reason to be concerned.

> I will say, I think that SaaSS and slavery aren't exactly comparable.

You may indeed argue that the losses of freedom in these two cases are
of different degrees, and I'd agree with that, but I don't think they're
of fundamentally different nature.  That makes them comparable, even if
they're not even close.

But it's not my fault that the philosophical argument is from a time in
which slavery was common practice, so that it happened to be the topic
in which the fallacy was described and called out.  If it had been
coined in present days, it would probably be about how people lose their
freedom and autonomy willingly through technology.  In both cases, the
fallacy is the same, about a supposed freedom to give up freedom that
isn't a freedom because it leads to loss of freedom.


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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  6, 2026, Florian Weimer <fweimer@redhat.com> wrote:

> * Alexandre Oliva via Overseers:
>> We're not doing our computing on Sourceware.  The services we're using
>> aren't SaaSS, to the best of my knowledge, they're publishing and
>> communication, which aren't our computing, so relying on a third party
>> for them doesn't affect our control over our computing.

> We have buildbots for post-commit CI on Sourceware.

Ugh.  That sucks.  Thanks for bringing this problem to my attention!

Can we please make it a priority to fix this?

Could we possibly run it on a machine under our control?  Even a rented
virtual machine would do.  Could we use OpenSSF money, or the GNU
Toolchain funds, to rent a VPS?  Could we use OpenSSF money to pay for
LF personnel to help us set it up and to maintain in, but in such a way
that it remains under our control?

Now, CI specifically doesn't even have to be our own computing.  If
someone else were to run it, and then share the results with us, that
would make it their computing, not ours.  It could even be multiple
"someone else"s, each targeting a different arch or something.  These
would be useful and valuable contributions to the project, without
making them SaaSS for us.


> The pre-commit CI through Patchwork has builders, too, but they do not
> run on Sourceware infrastructure AFAIK.

Could someone who knows please confirm whether or not this is indeed the
case?

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Frank Ch. Eigler]

Hi -

> > We have buildbots for post-commit CI on Sourceware.
> 
> Ugh.  That sucks.  Thanks for bringing this problem to my attention!
> Can we please make it a priority to fix this?

?

> Could we possibly run it on a machine under our control?  Even a rented
> virtual machine would do.  [...]

Who is the "us" you are talking about?  Sourceware buildbots are
operated by a bunch of community member donors.

> Now, CI specifically doesn't even have to be our own computing.  If
> someone else were to run it, and then share the results with us, that
> would make it their computing, not ours.  It could even be multiple
> "someone else"s, each targeting a different arch or something.  These
> would be useful and valuable contributions to the project, without
> making them SaaSS for us. [...]

I'm afraid I don't understand what the problem is, or how you believe
this paragraph is aspirational, instead of what's already going on.

- FChE

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  7, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:

>> > We have buildbots for post-commit CI on Sourceware.
>> 
>> Ugh.  That sucks.  Thanks for bringing this problem to my attention!
>> Can we please make it a priority to fix this?

> ?

AFAICT it's SaaSS, Service as a Software Substitute.  It's software that
does our computing, and that should thus be running under our control,
but that is instead operated by someone else who controls it and runs it
on our behalf.

SaaSS is even more of a software freedom problem than relying on nonfree
software.

I'm not surprised that the LF doesn't see a problem there, or even that
it wants to promote that kind of practice, but I'd be very surprised if
SFC didn't see a problem in that sort of practice.


>> Could we possibly run it on a machine under our control?  Even a rented
>> virtual machine would do.  [...]

> Who is the "us" you are talking about?

The GNU libc collective, within its governance structure.  That
governance structure should control our collective computing, instead of
having it done by third parties.

> Sourceware buildbots are
> operated by a bunch of community member donors.

Are these the post-commit CI?  The arrangement is not clear to me.  I
may need a lot more detail to understand what's going on, as in who
controls what.

The quote at the top says those are "on Sourceware", which I take it as
meaning "under Sourceware control".  Sourceware is a separate
organization, with a separate governance structure, so if it does our
computing for us, that's SaaSS, and that's a freedom problem.

Using Sourceware services is acceptable for hosting of non-SaaSS
(publishing, mediation of communication, because those are not *our*
computing), but not at all fine for SaaSS.

Maybe knowing more details about how this is arranged will lead to a
conclusion that this case is not SaaSS, after all, or point at other
ways to make it non-SaaSS.


>> Now, CI specifically doesn't even have to be our own computing.

> I'm afraid I don't understand what the problem is,

Sourceware, a separate entity, seems to be doing our computing under its
control, instead of our doing our computing under our control.


> how you believe this paragraph is aspirational,

It really isn't.  It's suggests a fallback workaround position in case
the ideal of doing all of the computing that we might wish autonomously
can't be achieved in the short term.


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

Re: CTI - Making a decision for glibc.

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 11080 bytes --]

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.

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

I don't even particularly support the CTI move (because I know the
Sourceware folk better, which is a reflection of my position as an
infrequent visitor to libc), but this doesn't seem correct to me.

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

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

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.

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

Here I agree.  It'd be neat to have a local CE instance.  But, the
people working on CE are also in the GCC community.

> 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.
I'm not convinced.

> ... would be a constant risk of DoS and possibly security issues for
> the server operator, ...

This is correct.  It is a massive load on the CE hackers.  But, not one
that's impossible to overcome.  The Linux family of kernels has decent
namespacing support, which goes a long way in the security department.
DoS is manageable with rate limiting (which is also part of what makes
it not viable to substitute a compiler with CE)

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

> Web access logs contain semi-anonymised IP addresses (we remove parts
> of the IP address to make them less identifying) but no other personal
> information. When you visit a long Compiler Explorer URL (the ones
> with # in them), your code stays in your browser and isn't logged. If
> you visit a short URL we created (like godbolt.org/z/abc123), then we
> can potentially retrieve your code from our logs.
> 
> Compilation logs are separate analytics logs that record which
> compilers and settings people use. These analytics help us understand
> usage patterns and plan improvements. We store a fingerprint (hash) of
> your source code along with compiler options, filters, and libraries
> used, but we can't reverse this to see your actual code. These
> analytics are kept for up to 1 year. We may share aggregate statistics
> about compiler usage publicly, but these never include individual
> usage patterns or any way to identify specific users.
> 
> Amazon infrastructure logs: We use Amazon's servers to run Compiler
> Explorer. Their logs (which help us debug issues and block attacks)
> contain full IP addresses and are kept for up to 32 days, then
> permanently deleted.
> 
> For error reporting: If something goes wrong in your browser, we use
> Sentry to help us fix it. This keeps your IP address and browser
> information for up to 90 days.
>
> If we need to share data with new third-party services in the future,
> we'll update this privacy policy accordingly.

There's more details, but this paste is already quite long.  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).

> ... how the submitted programs end up being used, ...

They get compiled.  Compilation results and side effects are sent back.
Then they're deleted.

If shared, they're stored for longer, as detailed in the policy.

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

What?  What could be twisted here?

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

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

I'm aware.  You can locally run CE just fine.  And, as I went over, you
can't reasonably substitute compilers with CE.

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

The point of contention was not what exactly 'merge' meant.  I
understood it as 'patch application.  So that's fine.

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

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

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?

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.

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

What SaaSS is there on Sourceware then?  Is it not the case that
Sourceware, as part of our community, running software, cannot be SaaSS?
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?
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: [OT, attempt at humor] Compiler Explorer misuse

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

Alexandre Oliva <oliva@gnu.org> writes:

> BTW, has anyone figured out how to use C++ Template metaprogramming to
> mine cryptocurrencies on Compiler Explorer instances yet? :-)

There was a (joking) talk on this topic.  I can't find it :-(

I'll send it your way if I do ;)
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

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

Working together and gaining trust

[Mark Wielaard]

Hi,

On Sat, Feb 07, 2026 at 11:07:27PM -0300, Alexandre Oliva wrote:
> On Feb  7, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:
> >> Could we possibly run it on a machine under our control?
> 
> > Who is the "us" you are talking about?
>
> [...]
> Sourceware, a separate entity, seems to be doing our computing under
> its control, instead of our doing our computing under our control.

Please stop this "us" versus "them". And this is not just directed at
you. You and Carlos are glibc GNU package maintainers that are
supposed to help us reach consensus as a community, but instead you
both are creating division by manufacturing crisis, branding some
people in the community as "them" as if they are actively working
against the community's goals. This is such bullshit. From both sides.

The Sourceware Project Leadership Committee is Frank Ch. Eigler, Ian
Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard
and Elena Zannoni. https://sourceware.org/mission.html#plc

Both of you know these people, they have been part of our community
for decades, their dedication to community and Free Software is well
known. You should be able to trust these people to make sure that the
community will always be in control of their own computing.

These people are us. They took up responsibility for the long term
sustainability and funding of our infrastructure. Providing services
to projects that their communities control collectively. And guiding
hosted projects to follow secure practices and new cyber security
regulations where appropriate. If you don't trust them personally then
you can rely on the Fiscal Sponsorhip Agreement they all signed with
the SFC. https://sourceware.org/Conservancy-Sourceware-FSA.pdf

It makes sure to explicitly list our purpose as supporting/hosting
Free Software communities and that we use (and publish) as free
software the services provided.

For things like builder CI and the Forge this means there are
repositories containing the whole setup, so that you cannot just
replicate the service locally, but also you can control what "compute"
it does for the community as a whole (they operate just like other
projects, your patches get reviewed first).
https://sourceware.org/cgit/builder/
https://forge.sourceware.org/forge/

Lets see if we can expand "us". Zoe is talking to the LF/OpenSSF right
now. Lets give her some credit for defining what is acceptable for the
FSF. What would your requirements be for the CTI charter to accept
them as "us"? In which way would you want the LF support to come? How
do you see the collaboration of LF with Sourceware? What kind of
services would you feel comfortable LF providing? And in what way?

Cheers,

Mark

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb  8, 2026, Mark Wielaard <mark@klomp.org> wrote:

> Hi,
> On Sat, Feb 07, 2026 at 11:07:27PM -0300, Alexandre Oliva wrote:
>> On Feb  7, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:
>> >> Could we possibly run it on a machine under our control?
>> 
>> > Who is the "us" you are talking about?
>> 
>> [...]
>> Sourceware, a separate entity, seems to be doing our computing under
>> its control, instead of our doing our computing under our control.

> Please stop this "us" versus "them".

There's no "versus" here.  It's just that there are boundaries between
individuals, between organisms, between organizations, and those make a
difference.

For example, if a piece of software is developed within one
organization, it can be used in freedom within that organization.  But
if anyone else, any other organization, wishes to use that program in
freedom, a free software license needs to be granted covering that
software.  It doesn't matter if the two parties are best friends,
partner organizations, or members of the same community.  It won't be
free software without a license from the originator that grants the
other party the freedoms needed to control the software.

If the originator doesn't grant those permissions, the other party
doesn't have control over the software.  Having to ask for further
permissions, even if you expect to get them, is not equivalent to
freedom, it is rather evidence of lack of freedom.


The same boundaries apply to SaaSS.  If anyone else, any other
organization, offers to do your computing for you, under their control,
even if you're best friends, closest partners, members of the same
community, that's SaaSS.  It won't be free software for you because it's
a premise that, if it's under their control, it's not under yours.  No
amount of licensing can fix that.

Unless the other organization, the one that controls the computing, is
itself under your control, at least WRT your computing, you won't have
control over the software that does your computing.  Having to ask the
other party to do what you should be free to do to begin with, and
having depend on the other party's willingness to do it, is not freedom,
it is evidence of lack of freedom.


So, you see, if we (glibc) run something on shared rather than
autonomous infrastructure, and we ask you (Sourceware) to make a change
for us, and you refuse on the grounds that, for example, it's shared
infrastructure, that's a symptom that we are not free.  It doesn't mean
your not our friends, our partners, or part of our community, it just
means that we don't have control over our computing, and that's
unacceptable for any part of the GNU Project.  I wish it were not
tolerated by any other part of the free software community either, or by
anyone, really, because we all deserve software freedom.


> instead you both are creating division by manufacturing crisis

I get where that feeling is coming from, but I don't accept that I'm
manufacturing crisis or creating division.  Opposing SaaSS is a
foundational principle of the free software movement and of the GNU
Project.

If upholding that principle amounted to creating division, then standing
for the four freedoms necessary for users to control their computing
would amount to creating division as well.  If it were so, we would have
been infiltrated by people who oppose software freedom.  I hope that is
not the case.  I hope people just haven't realized that it's the same
issue of control over one's computing, of the freedoms necessary to
attain that control, and that nonfree software and SaaSS are just two
slightly different ways to deny that control and those freedoms.

I'm not manufacturing crisis either.  The crisis, namely the threat to
our software freedom principles with the possibility of moving to a
freedom-hostile provider, was in place when I joined the discussion.
Upholding our principles is nothing to take blame for.  Indeed, if this
has given us an opportunity to highlight the growing problem of SaaSS,
to make sure we don't fall in such traps, and to step out of any such
circumstances we might have fallen into, that's bit is not a crisis,
that's progress towards software freedom.

Now, if others were to push against our principles, that would be a
crisis indeed, but it wouldn't be one I could be accused of promoting,
would it?

But I don't think that's what we have; I see people who did not
*realize* that SaaSS is just another way to deny the four freedoms, so
if we care for software freedom, we should avoid SaaSS just like all the
other forms of nonfree software.  After all, if doesn't matter if it's
nonfree because we don't have sources, we don't have a license, we
signed an NDA, we accepted a restrictive patent license, we see
restrictive trademarks too enmeshed in the software, or if it's deployed
Tivoized or as SaaSS or under any other number of circumstances that
deny us control over the software: it's not free, and that means we
don't control it, and someone else does, and so, if we use it to do our
computing, that someone else could control us through our computing.

> Both of you know these people, they have been part of our community
> for decades

I know those people indeed, and I'm happy they're in these positions of
leadership in the Sourceware community.  That's been good for all the
larger community of projects served by Sourceware, and that's been good
for the even larger community of free software users and developers.

But what does this have to do with any of what I'm saying?

I'm not denying that we're part of the same communities.  I'm not saying
we don't belong together, or that we can't trust each other.

Trust is just not enough for freedom.

All individuals, all organizations, all communities deserve freedom, at
all scales.  If some computing pertains to an individual, that's who
should control it.  If it pertains to an organization, that's who should
control it.  If it pertains to a specific community, that's who should
control it.

If an individual is a member of a community, it doesn't follow that the
community should control that individual's computing, nor that it would
be ok for other members of the community to control it.

Lkewise, if that specific community is encompassed by a larger
community, it doesn't follow that the larger community should control
the computing of the specific community, or that other members of the
larger community should control it.

Sourceware is a welcome member in various communities, but control over
the communities' computing doesn't belong with Sourceware, any more than
control over individual members's computing belong with Sourceware.
That's not a matter of trust, that's a matter of who the computing
pertains to; what follows from that is who should control it, and who
shouldn't.

> You should be able to trust these people to make sure that the
> community will always be in control of their own computing.

You may indeed be right about that.  From our private conversation, I've
learned that the arrangement with containers to run glibc's CI builders
autonomously, wherein we have control over the configuration of the
containers and of what runs inside them, has largely alleviated my
concerns that this arrangement might be SaaSS.  Thank you very much!

It would also be quite a relief to learn that Sourceware commits to not
offering SaaSS.  I'm no longer sure that this is the case, but I used to
expect that, whether out of its own volition, or perhaps from the SFC.
The ongoing arrangements with CIs and Forges and whatnot make me wary,
because of the risk of tripping on SaaSS; it would be really great to be
reassured that Sourceware not only understands this matter, but is also
adamant about respecting the freedoms of projects, contributors and
users, by ensuring that Sourceware won't be a party to denying them
freedom, whether through software that is distributed, run or relied on
by Sourceware for its hosted projects.  I didn't mention SaaSS
explicitly here because it's redundant: it follows from "[not] denying
them freedom [...] through software [...] run [...] for [...] its hosted
projects".  (I wouldn't mind if Sourceware made such commitments as to
its own computing too, but that's its own freedom, inasmuchas ours is
not on the line.)


> you can control what "compute" it does for the community as a whole
> (they operate just like other projects, your patches get reviewed
> first).

Hmm, that aspect of having to get approval from others to be allowed to
make changes to our own computing seems doubtful to me.  It suggests our
autonomy (and thus freedom) is limited here.  Could this possibly be
improved, by segregating different project's configurations or somesuch?

> https://forge.sourceware.org/forge/

Say, if we (glibc) wanted to apply a patch to our forge so that we could
apply our patches in a more convenient way (recursion is fun :-) could
we do that autonomously?  Could we do that ourselves?

I pick applying patches specifically because several other aspects of
typical forges are not strictly our computing, but applying (and
rebasing) our patches is.  So we should have control over that.


> Lets see if we can expand "us".

I'm all for growing our communities, but this seems to be missing the
point.  Growing the free software community, or the Sourceware
community, or the GNU Toolchain community, or the glibc community
couldn't possibly solve any SaaSS problem.  If some computing pertains
to glibc, running it under control of any other member of the community
would still be SaaSS.

> Zoe is talking to the LF/OpenSSF right now. Lets give her some credit
> for defining what is acceptable for the FSF.

Erhm.  This calls for some clarification.  It's great that she's doing
that.  As for me, I don't speak for the FSF.  I'm wearing my GNU hat
here (some people conflate them, but GNU is an independent project
supported by the FSF, it's not the FSF; GNU welcomes FSF's support and
dedication), but it's not like I am representing GNU leadership either,
or the GNU advisory committee.

I am a GNU Speaker, which implies I'm recognized as having significant
understanding of free software philosophy, and that's what I'm bringing
here.  I am also assigned some (mainly political, as of many many years
ago) maintainership responsibilities over GNU libc, which require me to
uphold and stand for GNU philosophy (Free Software principles, really)
at least in this context (which doesn't stop me from taking them to
heart and to life at large).  These are my personal responsibilities
regardless of any other arrangements or agreements.


As for your questions about CTI/LF...  Some of them are confusing to me
because "us" is unclear and possibly not relevant.

The bare minimum for me would be a commitment to uphold free software
principles, particularly the strict avoidance of nonfree software,
including SaaSS deployments.

I've made it clear that I consider the LF a hostile organization, but I
would welcome financial support from it, without strings attached, as I
would from anyone I can think of.  I'd also welcome hardware (ideally
RYF-certified, or at least capable of running fully-free GNU/Linux
distros), connectivity, and virtual machines, provided that we could
control what runs on them.  I'd also welcome contributions in the form
of labor, say from sysadmins and the likes, provided that they were
assigned to abide by our requests.  I'd also welcome code contributions,
documentation, testing, bug reports...  There are so many ways to
contribute to glibc!  I'm not picky about accepting contributions.  I am
very picky, however, about things that would take away our freedoms, or
that of our users.

I've long proposed collaboration between LF and Sourceware in the form
of replicating the hosting services we rely on, so that we wouldn't
depend on any single organization; so that we could replicate to other
parties; so that if any party temporarily went down the remaining
parties could keep the services going, and the other would catch up when
it came back.

This would be the most useful, though somewhat pipe-dreamy, way the LF
(or anyone, really) could contribute to our infrastructure.

Failing that, it would be great if LF were to help Sourceware, instead
of trying to replace it, so as to raise all the boats and cross-polinate
the knowledge on how to do the technically solid stuff you and they do,
inasmuchas it is freedom-respecting.  Taking things over doesn't help
glibc or Sourceware, it's disruptive and risky.  Growing the pie instead
of fighting over it would be actual help; sowing division by offering
bait circular money and misleading commitments that promise free
software but don't rule out SaaSS isn't help.

I wouldn't be comfortable with the LF hosting stuff for projects I'm
involved in any more than I'd be comfortable in the vicinity of a river
infested with hungry crocodiles; corporations (including it and those
that control it) are reptiles, not friends.
https://webmink.com/essays/reptiles/

I could live with its hosting things we publish, ideally replicated with
other parties.  I wouldn't tolerate SaaSS, but that's not because it's
the LF, it's because SaaSS is unacceptable regardless of the service
provider.

I realize the reptilian "instincts" apply to Sourceware's corporate
support as well.  That's why freedom, autonomy, and
replication/redundancy are so appealing to me.

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Florian Weimer]

* DJ Delorie via Overseers:

> Alexandre Oliva <oliva@gnu.org> writes:
>> but the core of the argument against SaaSS is the same ethical
>> argument against nonfree software: you deserve control over your
>> computing.
>
> I'd like to take a moment to point out the irony here.  You tell us we
> deserve control over our computing, then tell us we cannot choose how to
> do our computing.  You tell us our computing must be in our control,
> then tell us to cede that control to sourceware.
>
> This is the problem with the SaaSS argument.  You can draw the line
> wherever you like, to make whatever argument you like, but in the end
> you don't really want the user to be free to do what they want.
>
> So can we please stop using this argument as a hammer?  The LF people
> can be just as much "on our team" as the Sourceware people, and when
> things to bad, either can be just as much out of our control.

Thanks for posting this.  I don't think this discussion is going down a
productive path because it requires us to make a determination who is
part of the glibc community and who is not.  I would prefer if it didn't
come to that.

Thanks,
Florian

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  9, 2026, Florian Weimer <fweimer@redhat.com> wrote:

> because it requires us to make a determination who is
> part of the glibc community and who is not.  I would prefer if it didn't
> come to that.

Your wish is granted.  There's no such need, as far as SaaSS is
concerned.  I wonder where this notion even comes from.  Surely I've
failed in communicating the concept of SaaSS, or in overriding other
preconceived notions, but I wish I could at least get to understand how
that came to be so that this misconception can be avoided and corrected.


It matters not at all whether someone is a member of a community, to
determine whether the community's computing is done as SaaSS.

If we were to outsource our community computing to you (an active
member), me (an inactive member), or any random third party out there
(who's never been a member), so that the one controlling the computing
is the person running it, rather than the community through its
governance structure, then it is SaaSS.

Whereas if the community computing takes place under control of the
community, so that its autonomy is not curtailed by the person who
carries out the computing on our behalf, then it is not SaaSS.

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Frank Ch. Eigler]

Hi -

> [...]  Whereas if the community computing takes place under control
> of the community, so that its autonomy is not curtailed by the
> person who carries out the computing on our behalf, then it is not
> SaaSS. [...]

I am skeptical that a concept such as "community computing" is
coherent, especially when it is applied to someone running testsuites
and reporting results.  Putting such activities under "control of the
community" appears a literal violation of FSD Freedom #0.  Let's stay
on topic.

- FChE

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb  9, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:

> Hi -
>> [...]  Whereas if the community computing takes place under control
>> of the community, so that its autonomy is not curtailed by the
>> person who carries out the computing on our behalf, then it is not
>> SaaSS. [...]

> I am skeptical that a concept such as "community computing" is
> coherent, especially when it is applied to someone running testsuites
> and reporting results.  Putting such activities under "control of the
> community" appears a literal violation of FSD Freedom #0.  Let's stay
> on topic.

Yeah, let's.  There's clearly some mental model mismatch here.  I can't
quite make sense of what you're trying to get at, there seems to be a
deep disconnect.  Can we please dig deeper so as to increase our common,
shared understanding, instead of leaving it alone, pretending it's not
there and reinforcing the miscommunication?


When I speak of "community computing" in the context of running
testsuites and reporting results, I'm speaking of those testsuite runs
and reported results that are made by decision of the community
governance.

I am *not* speaking of third party test runs done independently.

I'm *not* speaking of test runs done independently even by community
members.

Anyone is still free to run the tests however they wish: it is their own
computing, after all, so they should be sovereign and autonomous WRT to
them.


What I'm speaking of is the runs done on behalf of our collective
organization, GNU libc, in response to collective decision taken by its
governance structure.

We shouldn't run those as SaaSS, but that's not because our freedom is
curtailed (the supposed freedom #0 violation you mentioned), but rather
to stop it from being curtailed.  We should refrain from entering SaaSS
arrangements not because someone prohibits us from doing so, but because
it is foolish and self-defeating to give up our freedom.  That should be
avoided out of our own volition, out of our alignment with free software
values and principles, and out of our alignment with the GNU Project's
goals and example-setting.

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Gabriel Ravier]

[-- Attachment #1: Type: text/plain, Size: 6291 bytes --]

On 2/9/26 7:30 PM, Alexandre Oliva wrote:
> On Feb  9, 2026, "Frank Ch. Eigler"<fche@elastic.org> wrote:
>
>> Hi -
>>> [...]  Whereas if the community computing takes place under control
>>> of the community, so that its autonomy is not curtailed by the
>>> person who carries out the computing on our behalf, then it is not
>>> SaaSS. [...]
>> I am skeptical that a concept such as "community computing" is
>> coherent, especially when it is applied to someone running testsuites
>> and reporting results.  Putting such activities under "control of the
>> community" appears a literal violation of FSD Freedom #0.  Let's stay
>> on topic.
> Yeah, let's.  There's clearly some mental model mismatch here.  I can't
> quite make sense of what you're trying to get at, there seems to be a
> deep disconnect.  Can we please dig deeper so as to increase our common,
> shared understanding, instead of leaving it alone, pretending it's not
> there and reinforcing the miscommunication?
>
>
> When I speak of "community computing" in the context of running
> testsuites and reporting results, I'm speaking of those testsuite runs
> and reported results that are made by decision of the community
> governance.
>
> I am *not* speaking of third party test runs done independently.
>
> I'm *not* speaking of test runs done independently even by community
> members.
>
> Anyone is still free to run the tests however they wish: it is their own
> computing, after all, so they should be sovereign and autonomous WRT to
> them.
>
>
> What I'm speaking of is the runs done on behalf of our collective
> organization, GNU libc, in response to collective decision taken by its
> governance structure.
>
> We shouldn't run those as SaaSS, but that's not because our freedom is
> curtailed (the supposed freedom #0 violation you mentioned), but rather
> to stop it from being curtailed.  We should refrain from entering SaaSS
> arrangements not because someone prohibits us from doing so, but because
> it is foolish and self-defeating to give up our freedom.  That should be
> avoided out of our own volition, out of our alignment with free software
> values and principles, and out of our alignment with the GNU Project's
> goals and example-setting.
>

I think the issue here is more that there appears to be a disconnect as 
to what exactly is SaaSS (or at least an "acceptable" thing for the 
glibc project to do) in the context of stuff like running tests 
automatically. Let's say that today, there is one s390x machine running 
tests (or arc, csky, or1k, sh or some other esoteric architecture - the 
specifics aren't super important), and that the project "relies" on this 
to make sure random commits don't break on s390x. Would this be SaaSS ? 
Would whether such is SaaSS rely on the precise manner in which the 
tests are used ? e.g.:
- Is it SaaSS if we consider that the machine is required for s390x 
support, and if it is retracted with no replacement, s390x support will 
be officially dropped ?
- Is it SaaSS if we consider that the machine is a non-required courtesy 
- if it is available, we make sure as often as possible to not break 
s390x, but if it isn't/is retracted in the future, we simply decide that 
some other interested s390x user can provide their machine if they want 
better support/to make sure random commits don't break s390x, and if no 
one provides one just support s390x somewhat less well ?
- Is it SaaSS if the machine is of a more common architecture that we 
could "test ourselves" ? How common would it have to be ? Does e.g. any 
architecture with QEMU support qualify ? (even if running the tests 
would take much longer there, almost impractically so)
- Is it SaaSS depending on *who asked* the machines to run the tests 
(e.g. because the glibc project kindly asked the owner of the machine to 
do so, or because the owner of the machine simply decided to do so), and 
if so, does it matter at all how the tests are used after someone 
"independently" (or not) ran the tests ?

Note that in none of these cases we would have direct control over the 
machine - at least insofar as the machine could be legally retracted at 
any time should the owner of the machine not like whatever specific 
things we're doing on it/need it for something else/any reason they want.

Reading the SaaSS definition RMS gives seems to imply the answer is 
"yes" to almost all my questions (except perhaps the last one) but it 
gets pretty impractical in many cases - do you consider dropping Itanium 
because testing it is basically impossible without some form of SaaSS to 
be the correct choice because, technically, we could go spend a bunch of 
money on Itanium blades for and spend weeks getting them working, or 
develop an Itanium implementation for QEMU and run it on that, and that 
the choice should be either doing that or dropping Itanium, because 
anything else would be SaaSS ?


PS: As to my last question, it seems like an oddly simple structural 
run-around-the-rules to say that the tests are being "run independently" 
if glibc developers regularly consult the tests and use them to improve 
the project (regardless of how "officially" this is integrated into the 
workflow). For instance, a simple example would be to replace "the 
project relying on the particular machine" with "the project simply 
waiting on someone to independently decide to run the tests and posting 
the results publicly somewhere" (which would likely end up with a single 
practical provider for most architecture in practice, even if 
bureaucratically mildly different) within the context of the first two 
questions - would this be SaaSS in either the "required for architecture 
support" or the "courtesy" scenarios ? I would like to note this already 
effectively exists for the courtesy scenario on pretty much any project, 
insofar as that's effectively just the equivalent of someone deciding to 
run the tests on a particular architecture and posting the results to 
the mailing list in response to someone posting a patch - which doesn't 
seem particularly different in practice to having those machines run the 
tests because the glibc project asked them to do so, given the final 
practical usage of them is the same if it's not e.g. required for 
architecture support.

Re: Working together and gaining trust

[Claudio Bantaloukas]

On 09/02/2026 01:47, Alexandre Oliva via Overseers wrote:
> On Feb  8, 2026, Mark Wielaard <mark@klomp.org> wrote:
> 
>> Hi,
>> On Sat, Feb 07, 2026 at 11:07:27PM -0300, Alexandre Oliva wrote:
>>> On Feb  7, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:
>>>>> Could we possibly run it on a machine under our control?
>>>
>>>> Who is the "us" you are talking about?
>>>
>>> [...]
>>> Sourceware, a separate entity, seems to be doing our computing under
>>> its control, instead of our doing our computing under our control.
> 
>> Please stop this "us" versus "them".
> 
> There's no "versus" here.  It's just that there are boundaries between
> individuals, between organisms, between organizations, and those make a
> difference.
> 
> For example, if a piece of software is developed within one
> organization, it can be used in freedom within that organization.  But
> if anyone else, any other organization, wishes to use that program in
> freedom, a free software license needs to be granted covering that
> software.  It doesn't matter if the two parties are best friends,
> partner organizations, or members of the same community.  It won't be
> free software without a license from the originator that grants the
> other party the freedoms needed to control the software.
> 
> If the originator doesn't grant those permissions, the other party
> doesn't have control over the software.  Having to ask for further
> permissions, even if you expect to get them, is not equivalent to
> freedom, it is rather evidence of lack of freedom.
> 
> 
> The same boundaries apply to SaaSS.  If anyone else, any other
> organization, offers to do your computing for you, under their control,
> even if you're best friends, closest partners, members of the same
> community, that's SaaSS.  It won't be free software for you because it's
> a premise that, if it's under their control, it's not under yours.  No
> amount of licensing can fix that.
> 
> Unless the other organization, the one that controls the computing, is
> itself under your control, at least WRT your computing, you won't have
> control over the software that does your computing.  Having to ask the
> other party to do what you should be free to do to begin with, and
> having depend on the other party's willingness to do it, is not freedom,
> it is evidence of lack of freedom.
> 
> 
> So, you see, if we (glibc) run something on shared rather than
> autonomous infrastructure, and we ask you (Sourceware) to make a change
> for us, and you refuse on the grounds that, for example, it's shared
> infrastructure, that's a symptom that we are not free.  It doesn't mean
> your not our friends, our partners, or part of our community, it just
> means that we don't have control over our computing, and that's
> unacceptable for any part of the GNU Project.  I wish it were not
> tolerated by any other part of the free software community either, or by
> anyone, really, because we all deserve software freedom.
> 
> 
>> instead you both are creating division by manufacturing crisis
> 
> I get where that feeling is coming from, but I don't accept that I'm
> manufacturing crisis or creating division.  Opposing SaaSS is a
> foundational principle of the free software movement and of the GNU
> Project.
> 
> If upholding that principle amounted to creating division, then standing
> for the four freedoms necessary for users to control their computing
> would amount to creating division as well.  If it were so, we would have
> been infiltrated by people who oppose software freedom.  I hope that is
> not the case.  I hope people just haven't realized that it's the same
> issue of control over one's computing, of the freedoms necessary to
> attain that control, and that nonfree software and SaaSS are just two
> slightly different ways to deny that control and those freedoms.
> 
> I'm not manufacturing crisis either.  The crisis, namely the threat to
> our software freedom principles with the possibility of moving to a
> freedom-hostile provider, was in place when I joined the discussion.
> Upholding our principles is nothing to take blame for.  Indeed, if this
> has given us an opportunity to highlight the growing problem of SaaSS,
> to make sure we don't fall in such traps, and to step out of any such
> circumstances we might have fallen into, that's bit is not a crisis,
> that's progress towards software freedom.
> 
> Now, if others were to push against our principles, that would be a
> crisis indeed, but it wouldn't be one I could be accused of promoting,
> would it?
> 
> But I don't think that's what we have; I see people who did not
> *realize* that SaaSS is just another way to deny the four freedoms, so
> if we care for software freedom, we should avoid SaaSS just like all the
> other forms of nonfree software.  After all, if doesn't matter if it's
> nonfree because we don't have sources, we don't have a license, we
> signed an NDA, we accepted a restrictive patent license, we see
> restrictive trademarks too enmeshed in the software, or if it's deployed
> Tivoized or as SaaSS or under any other number of circumstances that
> deny us control over the software: it's not free, and that means we
> don't control it, and someone else does, and so, if we use it to do our
> computing, that someone else could control us through our computing.
> 
>> Both of you know these people, they have been part of our community
>> for decades
> 
> I know those people indeed, and I'm happy they're in these positions of
> leadership in the Sourceware community.  That's been good for all the
> larger community of projects served by Sourceware, and that's been good
> for the even larger community of free software users and developers.
> 
> But what does this have to do with any of what I'm saying?
> 
> I'm not denying that we're part of the same communities.  I'm not saying
> we don't belong together, or that we can't trust each other.
> 
> Trust is just not enough for freedom.
> 
> All individuals, all organizations, all communities deserve freedom, at
> all scales.  If some computing pertains to an individual, that's who
> should control it.  If it pertains to an organization, that's who should
> control it.  If it pertains to a specific community, that's who should
> control it.
> 

Dear Alexandre,

Boundaries are made for self determination but also for exploration, 
communication and mixing. How they are used is a (messy!) choice we face 
every day of our lives and I am sad because you seem to choose 
consistenly in favour of the former and at the expense of the latter. I 
hope you experiment with the ideas below.

I think the statement you wrote above (all individuals...) is a 
fundamental vulnerability in your reasoning. You are collapsing 
incompatible meanings of freedom into a single slogan and then applying 
it universally, which makes it incoherent.

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.

Similar simplifications are the biggest problem I have with 
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
If you only read the headline and fail to go down the entirety of the 
text, you'll likely reject the whole idea rms is trying to convey.

To be clear, I have no problem with the concept that using SaaSS is 
"bad" and depending on it *worse* where individuals are concerned.

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.

This is even more the case in this community, where some parts possess 
unique abilities. Some people and/or companies (givers) have hardware 
that they must *choose* to provide access to. 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.
And yes, there must be something in it for them or they would not be 
providing the service at all.

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.

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.

> If an individual is a member of a community, it doesn't follow that the
> community should control that individual's computing, nor that it would
> be ok for other members of the community to control it.
> 
> Lkewise, if that specific community is encompassed by a larger
> community, it doesn't follow that the larger community should control
> the computing of the specific community, or that other members of the
> larger community should control it.
> 
> Sourceware is a welcome member in various communities, but control over
> the communities' computing doesn't belong with Sourceware, any more than
> control over individual members's computing belong with Sourceware.
> That's not a matter of trust, that's a matter of who the computing
> pertains to; what follows from that is who should control it, and who
> shouldn't.
> 
>> You should be able to trust these people to make sure that the
>> community will always be in control of their own computing.
> 
> You may indeed be right about that.  From our private conversation, I've
> learned that the arrangement with containers to run glibc's CI builders
> autonomously, wherein we have control over the configuration of the
> containers and of what runs inside them, has largely alleviated my
> concerns that this arrangement might be SaaSS.  Thank you very much!
> 
> It would also be quite a relief to learn that Sourceware commits to not
> offering SaaSS.  I'm no longer sure that this is the case, but I used to
> expect that, whether out of its own volition, or perhaps from the SFC.
> The ongoing arrangements with CIs and Forges and whatnot make me wary,
> because of the risk of tripping on SaaSS; it would be really great to be
> reassured that Sourceware not only understands this matter, but is also
> adamant about respecting the freedoms of projects, contributors and
> users, by ensuring that Sourceware won't be a party to denying them
> freedom, whether through software that is distributed, run or relied on
> by Sourceware for its hosted projects.  I didn't mention SaaSS
> explicitly here because it's redundant: it follows from "[not] denying
> them freedom [...] through software [...] run [...] for [...] its hosted
> projects".  (I wouldn't mind if Sourceware made such commitments as to
> its own computing too, but that's its own freedom, inasmuchas ours is
> not on the line.)
> 
> 
>> you can control what "compute" it does for the community as a whole
>> (they operate just like other projects, your patches get reviewed
>> first).
> 
> Hmm, that aspect of having to get approval from others to be allowed to
> make changes to our own computing seems doubtful to me.  It suggests our
> autonomy (and thus freedom) is limited here.  Could this possibly be
> improved, by segregating different project's configurations or somesuch?
> 
>> https://forge.sourceware.org/forge/
> 
> Say, if we (glibc) wanted to apply a patch to our forge so that we could
> apply our patches in a more convenient way (recursion is fun :-) could
> we do that autonomously?  Could we do that ourselves?
> 
> I pick applying patches specifically because several other aspects of
> typical forges are not strictly our computing, but applying (and
> rebasing) our patches is.  So we should have control over that.
> 

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

All four freedoms are intact.

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 is not reduction of freedom. That's negotiation and convincing 
people that an idea is a good one, of the kind we routinely do in 
mailing lists and on merge requests.

I think it's very reasonable that the people maintaining infrastructure 
should push back against patches that risk making such infrastructure 
unworkable or unmaintainable.

For example, I was asked to make the forge use the term "merge request" 
rather than "pull request" because PR conflicts with bugzilla terminology.
I pushed back initially because the way the forge was set up would have 
created a significant maintenance burden.
But in https://forge.sourceware.org/forge/forge/pulls/16 I managed to 
find a way that makes that possible without making updating the forge 
too laborious and error prone. And so the wish can be granted.

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.
Burnout is real. Life is short. We must take care of our maintainers, 
sysadmins, volunteers and developers. Not just our users.

> 
>> Lets see if we can expand "us".
> 
> I'm all for growing our communities, but this seems to be missing the
> point.  Growing the free software community, or the Sourceware
> community, or the GNU Toolchain community, or the glibc community
> couldn't possibly solve any SaaSS problem.  If some computing pertains
> to glibc, running it under control of any other member of the community
> would still be SaaSS.
> 
>> Zoe is talking to the LF/OpenSSF right now. Lets give her some credit
>> for defining what is acceptable for the FSF.
> 
> Erhm.  This calls for some clarification.  It's great that she's doing
> that.  As for me, I don't speak for the FSF.  I'm wearing my GNU hat
> here (some people conflate them, but GNU is an independent project
> supported by the FSF, it's not the FSF; GNU welcomes FSF's support and
> dedication), but it's not like I am representing GNU leadership either,
> or the GNU advisory committee.
> 
> I am a GNU Speaker, which implies I'm recognized as having significant
> understanding of free software philosophy, and that's what I'm bringing
> here.  I am also assigned some (mainly political, as of many many years
> ago) maintainership responsibilities over GNU libc, which require me to
> uphold and stand for GNU philosophy (Free Software principles, really)
> at least in this context (which doesn't stop me from taking them to
> heart and to life at large).  These are my personal responsibilities
> regardless of any other arrangements or agreements.
> 

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.

> 
> As for your questions about CTI/LF...  Some of them are confusing to me
> because "us" is unclear and possibly not relevant.
> 
> The bare minimum for me would be a commitment to uphold free software
> principles, particularly the strict avoidance of nonfree software,
> including SaaSS deployments.
> 
> I've made it clear that I consider the LF a hostile organization, but I
> would welcome financial support from it, without strings attached, as I
> would from anyone I can think of.  I'd also welcome hardware (ideally
> RYF-certified, or at least capable of running fully-free GNU/Linux
> distros), connectivity, and virtual machines, provided that we could
> control what runs on them.  I'd also welcome contributions in the form
> of labor, say from sysadmins and the likes, provided that they were
> assigned to abide by our requests.  I'd also welcome code contributions,
> documentation, testing, bug reports...  There are so many ways to
> contribute to glibc!  I'm not picky about accepting contributions.  I am
> very picky, however, about things that would take away our freedoms, or
> that of our users.
> 
> I've long proposed collaboration between LF and Sourceware in the form
> of replicating the hosting services we rely on, so that we wouldn't
> depend on any single organization; so that we could replicate to other
> parties; so that if any party temporarily went down the remaining
> parties could keep the services going, and the other would catch up when
> it came back.
> 
> This would be the most useful, though somewhat pipe-dreamy, way the LF
> (or anyone, really) could contribute to our infrastructure.
> 
> Failing that, it would be great if LF were to help Sourceware, instead
> of trying to replace it, so as to raise all the boats and cross-polinate
> the knowledge on how to do the technically solid stuff you and they do,
> inasmuchas it is freedom-respecting.  Taking things over doesn't help
> glibc or Sourceware, it's disruptive and risky.  Growing the pie instead
> of fighting over it would be actual help; sowing division by offering
> bait circular money and misleading commitments that promise free
> software but don't rule out SaaSS isn't help.
> 
> I wouldn't be comfortable with the LF hosting stuff for projects I'm
> involved in any more than I'd be comfortable in the vicinity of a river
> infested with hungry crocodiles; corporations (including it and those
> that control it) are reptiles, not friends.
> https://webmink.com/essays/reptiles/
> 
> I could live with its hosting things we publish, ideally replicated with
> other parties.  I wouldn't tolerate SaaSS, but that's not because it's
> the LF, it's because SaaSS is unacceptable regardless of the service
> provider.
> 
> I realize the reptilian "instincts" apply to Sourceware's corporate
> support as well.  That's why freedom, autonomy, and
> replication/redundancy are so appealing to me.
> 

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.
And again, whether you like it or not, the people being employed to do 
work on this project represent their companies.
Calling organizations who do something good out of "impure" motives 
"reptiles" as you do here is not just unhelpful. It has a negative 
impact on the very people that do their best to be helpful and 
principled in the face of potentially conflicting priorities.

You seemed like a great person when we met in person at the cauldron and 
I know you can do better than that.

Claudio Bantaloukas

All the opinions expressed here are my own and not my employer's.

Re: Working together and gaining trust

[Mark Wielaard]

Hi Alex,

On Sun, Feb 08, 2026 at 10:47:45PM -0300, Alexandre Oliva wrote:
> On Feb  8, 2026, Mark Wielaard <mark@klomp.org> wrote:
> > On Sat, Feb 07, 2026 at 11:07:27PM -0300, Alexandre Oliva wrote:
> >> On Feb  7, 2026, "Frank Ch. Eigler" <fche@elastic.org> wrote:
> >> >> Could we possibly run it on a machine under our control?
> >> 
> >> > Who is the "us" you are talking about?
> >> 
> >> [...]
> >> Sourceware, a separate entity, seems to be doing our computing under
> >> its control, instead of our doing our computing under our control.
> 
> > Please stop this "us" versus "them".
> 
> There's no "versus" here.  It's just that there are boundaries between
> individuals, between organisms, between organizations, and those make a
> difference.

Lets break down those boundaries. Individuals can cross these
boundaries and be part of multiple communities. And one can give
another control of their computing over these boundaries.

> So, you see, if we (glibc) run something on shared rather than
> autonomous infrastructure, and we ask you (Sourceware) to make a change
> for us, and you refuse on the grounds that, for example, it's shared
> infrastructure, that's a symptom that we are not free.

But what happens in practice is that the sharing is between people in
both the (for example) glibc and binutils communities. And if you
really are unable to share we (all of us together) would split the
infrastructure in two, so that the communities both have autonomous
control.

> > instead you both are creating division by manufacturing crisis
> 
> I get where that feeling is coming from, but I don't accept that I'm
> manufacturing crisis or creating division. [...] I'm not
> manufacturing crisis either.  The crisis, namely the threat to our
> software freedom principles with the possibility of moving to a
> freedom-hostile provider, was in place when I joined the discussion.

Right. I do see that. And that upsets me to. That was clearly an
hostile threat trying to run around getting community consensus and a
break down of project governance. It is unacceptable.

But I don't think the solution is to divide people even more by trying
to define who is in and who is out of the community or place
unnecessary boundaries around them. I know it is hard with the current
break of governance. But lets fix this together. Lets make sure we
define the community and the governance/control in a way that we all
have Free Software with control over our own and/or community compute
on our joint project's servers.

Cheers,

Mark

glibc CI (Re: forge vs gitolite)

[Mark Wielaard]

Hi Gabriel,

On Tue, Feb 10, 2026 at 01:50:31AM +0100, Gabriel Ravier wrote:
> I think the issue here is more that there appears to be a disconnect
> as to what exactly is SaaSS (or at least an "acceptable" thing for
> the glibc project to do) in the context of stuff like running tests
> automatically. Let's say that today, there is one s390x machine
> running tests (or arc, csky, or1k, sh or some other esoteric
> architecture - the specifics aren't super important), and that the
> project "relies" on this to make sure random commits don't break on
> s390x. Would this be SaaSS ? Would whether such is SaaSS rely on the
> precise manner in which the tests are used ? e.g.:
> - Is it SaaSS if we consider that the machine is required for s390x
> support, and if it is retracted with no replacement, s390x support
> will be officially dropped ?
> - Is it SaaSS if we consider that the machine is a non-required
> courtesy - if it is available, we make sure as often as possible to
> not break s390x, but if it isn't/is retracted in the future, we
> simply decide that some other interested s390x user can provide
> their machine if they want better support/to make sure random
> commits don't break s390x, and if no one provides one just support
> s390x somewhat less well ?
> - Is it SaaSS if the machine is of a more common architecture that
> we could "test ourselves" ? How common would it have to be ? Does
> e.g. any architecture with QEMU support qualify ? (even if running
> the tests would take much longer there, almost impractically so)
> - Is it SaaSS depending on *who asked* the machines to run the tests
> (e.g. because the glibc project kindly asked the owner of the
> machine to do so, or because the owner of the machine simply decided
> to do so), and if so, does it matter at all how the tests are used
> after someone "independently" (or not) ran the tests ?

Nice questions. To make it a little more concrete, let me describe how
the current glibc CI tests are done for s390x and x86_64 through
builder.sourceware.org.

s390x
Builds:
https://builder.sourceware.org/buildbot/#builders/glibc-fedora-s390x
Results:
https://builder.sourceware.org/testruns/?has_keyvalue_op=glob&has_keyvalue_k=testrun.gitdescribe&has_keyvalue_v=buildbot/glibc-fedora-s390x/%2A
Git file that describes what gets run:
https://sourceware.org/cgit/builder/tree/builder/master.cfg#n4452
glibc buildbot maintainers:
https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_BuildBot
But anybody can submit a patch to the builder project which then get
reviewed and integrated:
https://sourceware.org/mailman/listinfo/buildbot
Marist University hosts the server and lets us (through our Fedora
affiliate) install any software we need to run (on our VM) and
individual hackers can get access if they want to interactively debug
some issue. It has mock installed so you can install your own versions.

x86_64
Builds:
https://builder.sourceware.org/buildbot/#builders/glibc-fedora-x86_64
Results:
https://builder.sourceware.org/testruns/?has_keyvalue_op=glob&has_keyvalue_k=testrun.gitdescribe&has_keyvalue_v=buildbot/glibc-fedora-x86_64/%2A
The same git file describes what to run.
But in the x86_64 case also the Container file is in the builder repo:
https://sourceware.org/cgit/builder/tree/builder/containers
These containers are run in VMs on two servers from OSUOSL that they
own but we paid for some disks and control all installation of
software (both the bare metal OS and the VMs).
You can also use these container files to run the exact same set of
tests locally:
https://sourceware.org/cgit/builder/tree/README_containers

Cheers,

Mark

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

Thanks, these were useful questions.

I hope the answers bring more clarity.

On Feb  9, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:

> Let's say that today, there is one s390x machine
> running tests (or arc, csky, or1k, sh or some other esoteric
> architecture - the specifics aren't super important), and that the
> project "relies" on this to make sure random commits don't break on
> s390x. Would this be SaaSS ?

It depends.  If that testing is our computing, and we control it, then
it's not SaaSS, regardless of who offers us the hardware.  If that's
some third party's computing, and that third party controls it, then
it's not SaaSS either.  But if it's our computing, and someone else
controls it, it's SaaSS and it takes our freedom away.  Whereas if it's
someone else's computing, and a third party controls it, it's SaaSS for
that someone else, but it doesn't affect our freedom.

> - Is it SaaSS if we consider that the machine is required for s390x
>   support, and if it is retracted with no replacement, s390x support
>  will be officially dropped ?

No.  That someone else owns the machine and can terminate our access to
it doesn't make it SaaSS.  It's our control over our computing that we
run on it, as long as we have access, that determines whether it's
SaaSS.

We don't even need exclusive access to the machine.  We just need
control over the computing we do there.

> - Is it SaaSS if we consider that the machine is a non-required
>   courtesy

That's not a relevant consideration.  What matters to tell whether it's
SaaSS is whether we control our computing that runs on it, or someone
else does.

> - Is it SaaSS if the machine is of a more common architecture that we
>   could "test ourselves" ?

How common the architecture is makes no difference.  What makes a
difference is whether we control our computing that runs on it.

> - Is it SaaSS depending on *who asked* the machines to run the tests
>   (e.g. because the glibc project kindly asked the owner of the
>  machine to do so, or because the owner of the machine simply decided
> to do so), and if so, does it matter at all how the tests are used
> after someone "independently" (or not) ran the tests ?

The "who asked" could be either that whose computing the machine runs,
or that who commanded the machine to do the computing.  If they're the
same party (individual or group), then it's not SaaSS.

But if you ask some third party (who's not your agent, under your
control as to this process) to do the computing for you, and that third
party asks the machine to do the computing (under their control rather
than yours), then it's SaaSS.

If someone else takes the initiative of running the tests, and
volunteers the results to us, we can use them, and that makes no
difference to our software freedom even if it was SaaS to that someone
else, because that wasn't our computing, so we shoudn't expect to have
control over it.

> Note that in none of these cases we would have direct control over the
> machine

*nod*.  using a VPS, a VM, a container, or even access to a shared
machine doesn't take your freedom away inasmuchas it doesn't take
control of the computing you do there.  If the machine (virtual or not)
follows your commands and instructions towards that computing (therefore
within the boundaries of access you were granted), you have control of
your computing (which is what matters as far as software freedom is
concerned), if you don't fully control the machine on which it runs.


> PS: As to my last question, it seems like an oddly simple structural
> run-around-the-rules to say that the tests are being "run
> independently" if glibc developers regularly consult the tests and use
> them to improve the project

You could frame it that way, and I guess if such a practice is adopted
as a workaround for SaaSS, that's what it would amount to.

But see, GCC has very long had a dedicated mailing list that receives
test results from runs by independent contributors, and we regularly
consult those results.  That definitely doesn't take our freedoms away,
even if it's quite useful for us.

If we chose to do our own testing that way, though, it would be our
computing, and we would be relinquishing control over it => SaaSS.

> would this be SaaSS in either the
> "required for architecture support" or the "courtesy" scenarios ?

The answer to this is question is a little fuzzy.  The more we want,
expect and depend on those results, and the more disruptive not having
them would be to our workflows, the clearer it is that it is our
computing in disguise after all, and so the more it is SaaSS.

I wish we wouldn't try to explore the exact boundary to figure out just
how much we can afford to give up of our freedom.  That would be an
unfortunate outcome for this conversation.  I wish we'd instead strive
to do our computing in freedom, i.e., under our own control.

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

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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Gabriel Ravier]

On 2/11/26 11:11 AM, Alexandre Oliva wrote:
> Thanks, these were useful questions.
>
> I hope the answers bring more clarity.
>
> On Feb  9, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:
>> would this be SaaSS in either the
>> "required for architecture support" or the "courtesy" scenarios ?
> The answer to this is question is a little fuzzy.  The more we want,
> expect and depend on those results, and the more disruptive not having
> them would be to our workflows, the clearer it is that it is our
> computing in disguise after all, and so the more it is SaaSS.
>
> I wish we wouldn't try to explore the exact boundary to figure out just
> how much we can afford to give up of our freedom.  That would be an
> unfortunate outcome for this conversation.  I wish we'd instead strive
> to do our computing in freedom, i.e., under our own control.
>

My objective certainly isn't to find where the boundary is, then demand 
the glibc project jump up to right below that boundary and say "it's all 
technically OK we're right below the boundary" - it is rather more that 
I was uncertain what some of the specific standards here were, and how 
they should be evaluated (e.g. the specific ways some certain things 
would have to be altered to stop being SaaSS, or not altered so as to 
not become SaaSS). In a way, the idea is to know where the boundary is, 
so that we know where the boundary isn't (it is particularly useful to 
know how far some given things are from it, since it lets us know how 
much effort/resources need be expended to get rid of SaaSS, for instance).

Re: 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

Re: forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Alexandre Oliva]

On Feb 11, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:

> My objective certainly isn't to find where the boundary is

Great!  I didn't mean to direct that wish specifically to you, BTW.
It's just that we're among plenty of engineers here, and many of us,
myself included, tend to be attracted to seeking the limits and
"optimizing" towards them, and there have been so many misunderstandings
in this multithread that I wanted to try to set a different, more useful
optimization goal.

> it is particularly useful to know how far some given things are from
> it, since it lets us know how much effort/resources need be expended
> to get rid of SaaSS, for instance).

*nod*

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

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 10, 2026, Mark Wielaard <mark@klomp.org> wrote:

>> There's no "versus" here.  It's just that there are boundaries between
>> individuals, between organisms, between organizations, and those make a
>> difference.

> Lets break down those boundaries.

Are you suggesting to unify Sourceware and CTI and Glibc and binutils
and GDB and GCC and GNU Toolchain and GNU governance into a single
decision-making body?  That could address pretty much any risk of SaaSS,
but it sounds very very hard.

And as long as we aren't there, we have different governance structures,
each with its computing needs, each with its autonomy and freedom that
needs to be respected.

> Individuals can cross these
> boundaries and be part of multiple communities.

Sure, but how is this relevant to this conversation?

> And one can give
> another control of their computing over these boundaries.

One can; the point is one shouldn't, for the sake of one's freedom.

Giving others power over you is a sure way to get a poor deal.


>> So, you see, if we (glibc) run something on shared rather than
>> autonomous infrastructure, and we ask you (Sourceware) to make a change
>> for us, and you refuse on the grounds that, for example, it's shared
>> infrastructure, that's a symptom that we are not free.

> But what happens in practice is that the sharing is between people in
> both the (for example) glibc and binutils communities. And if you
> really are unable to share we (all of us together) would split the
> infrastructure in two, so that the communities both have autonomous
> control.

I can see how this could work.

It still makes me uncomfortable to be in a situation in which a service
provider can say 'no', and then our only recourse is to move our
infrastructure elsewhere.

Keep in mind that this matter of providers saying 'no' is at the very
core of free software philosophy.  Back in the days before minds were
clouded, people installed and ran programs on personal computers.  If
those programs were nonfree, their users had to beg the suppliers for
changes, and even if the suppliers were to tend to the users' every
request, such programs would still be regarded as nonfree, because the
users depended on the supplier to make the change.

We've fought that power imbalance and subjugation with free software.

Do you see that SaaSS brings that power imbalance and subjugation back?

Do you see that minimizing them because you're nice and friendly
providers is no different from minimizing them for nonfree software
whose supplier puts on a friendly face?  It's "trust me to have
power over your computing" all over again.

> But I don't think the solution is to divide people even more by trying
> to define who is in and who is out of the community or place
> unnecessary boundaries around them.

This seems to follow from miscommunication.

I'm not trying to divide communities, they already exist as independent
entities, and the need for freedoms follows from that.

Who belongs in each community is not even relevant to the SaaSS
argument.  It seems to be a common misconception that keeps coming back.

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

Re: Working together and gaining trust

[Alexandre Oliva]

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.

(the main reason I'm investing so much time and effort in this thread is
to spread awareness and intuitions about SaaSS, so that I don't have to
be the pest pointing out when there's a problem, but rather that we all
work together to avoid even getting to the point of having a problem :-)

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

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

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

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

The moment you start doing computing for others, however, then SaaSS
becomes (or should become) a concern, and then you may find that what it
takes for your individual and organizational users to retain their
control over their own computing might require from small tweaks to your
infrastructure to opening things up so much to others' control that
you're no longer willing to offer the service in a way that respects
their freedom on your own machines.

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

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

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

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

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

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

Re: 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

Re: Working together and gaining trust

[Mark Wielaard]

Hi Alex,

On Wed, Feb 11, 2026 at 11:45:12PM -0300, Alexandre Oliva wrote:
> On Feb 10, 2026, Mark Wielaard <mark@klomp.org> wrote:
> 
> >> There's no "versus" here.  It's just that there are boundaries between
> >> individuals, between organisms, between organizations, and those make a
> >> difference.
> 
> > Lets break down those boundaries.
> 
> Are you suggesting to unify Sourceware and CTI and Glibc and binutils
> and GDB and GCC and GNU Toolchain and GNU governance into a single
> decision-making body?  That could address pretty much any risk of SaaSS,
> but it sounds very very hard.
> 
> And as long as we aren't there, we have different governance structures,
> each with its computing needs, each with its autonomy and freedom that
> needs to be respected.

I wouldn't try to include the CTI, but would include the FSF (and
tech-team). Those organisations/projects have a somewhat hierarchical
relationship and strong Free Software charters and governance
structures. Some literally only exist to support the others. They are
kind of a big (sometimes slightly disfunctional) family. They don't
need to become one single decision-making body, they can certainly
keep their autonomy. But their core values and their infrastructure
needs are so similar that it makes sense to share some of it (see
below).

The issue with trying to include CTI is that it has a charter and
governance that is totally opposite to that of the existing
organizations/projects. The charter doesn't even mention Free
Software, GNU or any other goal than raising money by companies for
companies. They do appoint an advisory committee, but even there the
condition is just who pays most. The LF then also says all "outreach,
website and marketing activities" need to be coordinated by them.

It feels like it is just taking over the FSF Working Together Fund
from the FSF without the FSF's permission. I think it is up to the FSF
to first make sure that charter is rewritten to guarantee Software
Freedom for the community.

That doesn't mean OpenSSF/LF cannot meaningfully provide support to
the community. As we discussed there are several very useful ways that
don't impact the communities freedom, autonamy and control.

I know I am a little naive, especially with just trusting other people
doing the right thing, and I know you don't like looking or the
boundary of what is/isn't acceptable. But I hope you can be a little
flexible wrt those organisations/communities who have similar Free
Software goals. But I am certainly not that naive to suggest we just
share control with an entity that isn't willing to put at least a
minimum of guarantees around Free Software goals in their charter.

> > Individuals can cross these
> > boundaries and be part of multiple communities.
> 
> Sure, but how is this relevant to this conversation?

Because I believe that, people, is how you share. e.g. gcc and glibc
are people, some of these same people were delegated by their
communities to setup some shared infrastructure for these projects to
use. The leadership of Sourceware comes from these same
people. Technically they might be separate organisations, but they are
family.

> >> So, you see, if we (glibc) run something on shared rather than
> >> autonomous infrastructure, and we ask you (Sourceware) to make a change
> >> for us, and you refuse on the grounds that, for example, it's shared
> >> infrastructure, that's a symptom that we are not free.
> 
> > But what happens in practice is that the sharing is between people in
> > both the (for example) glibc and binutils communities. And if you
> > really are unable to share we (all of us together) would split the
> > infrastructure in two, so that the communities both have autonomous
> > control.
> 
> I can see how this could work.
> 
> It still makes me uncomfortable to be in a situation in which a service
> provider can say 'no', and then our only recourse is to move our
> infrastructure elsewhere.

Sure, but not all "service providers" are the same. If you see
Sourceware/SFC as a separate service provider/organisation you can
rely on their official agreement to provide you with Free Software
"solutions". We will go out of our way to put things into separate VMs
or run them in containers under your control. If say gcc and glibc
really cannot agree upon sharing a service we will try to make sure
you get separate VMs for them. And I think you can get similar
guarantees from the FSF tech-team for example. The Sourceware PLC and
the FSF tech-team even share "leadership" positions.

> Keep in mind that this matter of providers saying 'no' is at the very
> core of free software philosophy.  Back in the days before minds were
> clouded, people installed and ran programs on personal computers.  If
> those programs were nonfree, their users had to beg the suppliers for
> changes, and even if the suppliers were to tend to the users' every
> request, such programs would still be regarded as nonfree, because the
> users depended on the supplier to make the change.
> 
> We've fought that power imbalance and subjugation with free software.
> 
> Do you see that SaaSS brings that power imbalance and subjugation back?

Yes, of course.
 
> Do you see that minimizing them because you're nice and friendly
> providers is no different from minimizing them for nonfree software
> whose supplier puts on a friendly face?  It's "trust me to have
> power over your computing" all over again.

Yes, I do see I am a little naive at times. But I also believe that in
some cases it isn't just "puts on a friendly face". I believe that we
can put in place some minimal guarantees that show communities and
entities working together are in fact friendly. And that it matters
which people are in a leadership position.

> > But I don't think the solution is to divide people even more by trying
> > to define who is in and who is out of the community or place
> > unnecessary boundaries around them.
> 
> This seems to follow from miscommunication.
> 
> I'm not trying to divide communities, they already exist as independent
> entities, and the need for freedoms follows from that.
> 
> Who belongs in each community is not even relevant to the SaaSS
> argument.  It seems to be a common misconception that keeps coming back.

Sorry for using hash words like dividing communities. I really do mean
that I like our communities to feel more like one with a shared
mission and a shared goal of Software Freedom. I do honestly believe
that if the communities believe they are sharing control over their
(shared) infrastructure they cannot fall into the SaaSS trap. Maybe
that is naive and we need more concrete agreements in place to make
sure they don't. But even then I think we can and have provided such
agreements (at least between the FSF, GNU Toolchain projects and
Sourceware/SFC).

Cheers,

Mark

Re: Working together and gaining trust

[Jeffrey Law]

On 2/13/2026 8:34 AM, Mark Wielaard via Overseers wrote:
>
> The issue with trying to include CTI is that it has a charter and
> governance that is totally opposite to that of the existing
> organizations/projects. The charter doesn't even mention Free
> Software, GNU or any other goal than raising money by companies for
> companies. They do appoint an advisory committee, but even there the
> condition is just who pays most. The LF then also says all "outreach,
> website and marketing activities" need to be coordinated by them.
I think we're still missing a key point.  Namely that from a fundraising 
standpoint there are companies out there that are not willing to channel 
money to Red Hat to run sourceware, nor are they willing to fund via the 
FSF.   As soon as you bring in Red Hat or the FSF you cut off those 
sources of funding.  They are willing to fund infrastructure (via the 
CTI) outside the Red Hat and FSF organizations.

Jeff

Re: Working together and gaining trust

[Frank Ch. Eigler]

Hi -

> I think we're still missing a key point.  Namely that from a fundraising
> standpoint there are companies out there that are not willing to channel
> money to Red Hat to run sourceware, nor are they willing to fund via the
> FSF. [...]

They are in luck, for neither Red Hat nor the FSF has not solicited
funding in this area.  Sourceware's modest financial needs are taken
care of by donors to the Software Freedom Conservancy, a 501c(3) org.
The SFC has channeled money from many large corporations and from many
individuals to various projects.

- FChE

Re: Working together and gaining trust

[Mark Wielaard]

Hi Jeff,

On Fri, Feb 13, 2026 at 09:27:56AM -0700, Jeffrey Law wrote:
> I think we're still missing a key point.  Namely that from a
> fundraising standpoint there are companies out there that are not
> willing to channel money to Red Hat to run sourceware, nor are they
> willing to fund via the FSF.

I am not sure if you were still at Red Hat, but we split out
Sourceware as a separate entity a couple of years ago. Like Frank said
that means that funding goes through Sourceware/SFC directly. And I
think we have been somewhat successful with that.

There is a Sourceware Leadership Committee who oversees this:
https://sourceware.org/mission.html#plc (Frank Ch. Eigler, Ian
Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard
and Elena Zannoni)

Alex points out that makes us a seperate organization from the hosted
projects. And with that there is a risk of one organization
controlling the computing done of another group. I do see how this
could result in SaaSS. But I am arguing that a) these people would
never allow that given they are themselves part of the hosted
projects, and b) our charter also doesn't allow it
https://sourceware.org/Conservancy-Sourceware-FSA.pdf

Cheers,

Mark

Re: Working together and gaining trust

[Bradley M. Kuhn]

Jeff,

Jeffrey Law wrote earlier today:
> I think we're still missing a key point.  Namely that from a fundraising
> standpoint there are companies out there that are not willing to channel
> money to Red Hat to run sourceware, nor are they willing to fund via the
> FSF.   As soon as you bring in Red Hat or the FSF you cut off those sources
> of funding.  They are willing to fund infrastructure (via the CTI) outside
> the Red Hat and FSF organizations.

Could you please name the specific organization(s) that would make a
substantial ( ≥ $10k) contribution to fund Sourceware and/or infrastructure
for glibc that would be unwilling to give such funds to all of the following
organizations: { Red Hat, FSF, FSF Europe, Software Freedom Conservancy }

It would surprise me that such a donor exists — particularly given that they
could earmark these donations specifically to support Sourceware
infrastructure, or even Sourceware infrastructure specifically for glibc.

But, if there is an example of such an organization, we should make it
publicly known.  And we should ask these organizations why they have
blackballed such a large swath of FOSS organizations, and they should answer
this publicly — in the spirit or transparency and software freedom.

--
Bradley M. Kühn - he/them - Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
     I answer email slowly; feel free to book a chat w/ me: https://sfc.ngo/book/bkuhn
           On the Fediverse (via Mastodon) at https://fedi.copyleft.org/@bkuhn

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 13, 2026, Mark Wielaard <mark@klomp.org> wrote:

> They don't need to become one single decision-making body, they can
> certainly keep their autonomy. But their core values and their
> infrastructure needs are so similar that it makes sense to share some
> of it (see below).

Inasmuchas it doesn't curtail their autonomy.

>> > Individuals can cross these
>> > boundaries and be part of multiple communities.
>> 
>> Sure, but how is this relevant to this conversation?

> Because I believe that, people, is how you share. e.g. gcc and glibc
> are people, some of these same people were delegated by their
> communities to setup some shared infrastructure for these projects to
> use. The leadership of Sourceware comes from these same
> people. Technically they might be separate organisations, but they are
> family.

No problem with sharing where that makes sense.  The making sense,
however, encopasses respecting each collective's software freedom,
especially when the involved collectives are devoted to advancing
software freedom.

I still don't see the connection you were getting at, though.
Individual's belonging to multiple communities does not alleviate SaaSS.

>> It still makes me uncomfortable to be in a situation in which a service
>> provider can say 'no', and then our only recourse is to move our
>> infrastructure elsewhere.

> Sure, but not all "service providers" are the same.

*nod*

> If you see Sourceware/SFC as a separate service provider/organisation
> you can rely on their official agreement to provide you with Free
> Software "solutions". We will go out of our way to put things into
> separate VMs or run them in containers under your control. If say gcc
> and glibc really cannot agree upon sharing a service we will try to
> make sure you get separate VMs for them. And I think you can get
> similar guarantees from the FSF tech-team for example. The Sourceware
> PLC and the FSF tech-team even share "leadership" positions.

This is all great.

My dream scenario would be for Sourceware to become some sort of
pipeline in which new projects that need hosting services can find
freedom-respecting hosting that are so respectful of their autonomy
that, when they're ready to graduate to self hosting, they don't even
need to interrupt the services, because Sourceware will ahve it all
figured out to enable live unsharing and migration of VMs/containers.

> But I also believe that in
> some cases it isn't just "puts on a friendly face".

*nod*

> I believe that we
> can put in place some minimal guarantees that show communities and
> entities working together are in fact friendly.

Those are nice ot have, but most young projects wouldn't be in a
position to enforce the offer of any such guarantees, though, in case...

> And that it matters
> which people are in a leadership position.

... an unfortunate (hostile?) change of leadership turns things sour.

Depending, for your own peace of mind, on having friends in leadership
positions where your stuff is hosted is a sign that you're missing some
essential freedom.

That said, having freedom *and* friends makes for something even better
than just peace of mind ;-)

> Sorry for using hash words like dividing communities.

No worries.

> I really do mean that I like our communities to feel more like one
> with a shared mission and a shared goal of Software Freedom.

I see.  Well, we've got GNU ;-) so I sort of get the feeling.

GNU doesn't cover all of Sourceware though.

We've got the Free Software Movement, but maybe that's too broad.

> I do honestly believe
> that if the communities believe they are sharing control over their
> (shared) infrastructure they cannot fall into the SaaSS trap.

You're probably right about that.

What seems to be missing in that reasoning is that sharing control may
become a trap not to the provider, but to each other, in case a
project's evolving needs and preferences lead them to make different
choices from the other rpojects.

Then, having to share infrastructure may become a power struggle between
them, whereas ease to split the sharing (with or without moving) so that
whoever wants to take a different path is free to do so removes that
potential conflict while recognizing and reinforcing autonomy.

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

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 13, 2026, Claudio Bantaloukas <claudio.bantaloukas@arm.com> wrote:

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

[...]
> then freedom is maintained for all entities involved.

*nod*

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

At that point I wasn't.  These are important bits of computing as well.
But I was really thinking of the computing that goes into running patch
or git am or git rebase to apply a patch onto a different tree (or
detect conflicts that need manual resolution).


> In the native way of using forgejo, each project defines workflows
[...]
> Control is with the project, it's just that the way it's applied is
> unfamiliar to some people.

Are you familiar with Github Actions?  I can't be used by Github myself,
but I've loooked into this feature's documentation very briefly
recently, for something I'm writing about Github for GNU, and one could
come out of your description with the notion that projects have about as
much control about the computing performed as part of the defined
workflows in both cases.  Would you agree with that assessment?

Now, that, along with enabling runners on project-controlled machines,
could make it seem like none of this is SaaSS.

But ISTM that the orchestration (I don't think it uses this term) of
actions (their triggering, sequencing, parallelization, conditional
execution, loops and whatnot), and the interpretation of the language in
which these concepts are expressed by the project to the workflow
engine, are also important project's computing, and AFAICT there are
fundamental barriers for projects to take control of these computing
activities in Github.

E.g., if you wanted to extend the orchestration language or the workflow
engine, Github wouldn't allow you.  That's IMHO a freedom bug, a case of
SaaSS.

Doesn't this apply to Forĝejo as well?

> The documentation of forgejo's signing feature is here
> https://forgejo.org/docs/latest/admin/advanced/signing/

Thanks.

> When it comes to originator-signed commits, server side rebases lose
> the original signature.

Yeah, that was the concern.  I figured it would be a problem if the
server could make a new signature as if it had been made by myself.  But
if it is a project's rebase signature, that makes sense from a security
standpoint, and if it refers back to the contributor-signed commit
somehow, even the provenance can be tracked.  OTOH, this would be
project's computing (so SaaSS if done under other's control), and this
would be security sensitive, so keeping keys under control of third
parties would be very questionable IMHO.

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

I'm afraid I don't see it as anything but the project's own computing.
Who else might be involved ot the point of having a claim over it?

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

These all seem important reasons to me.  So important that, to bypass
confidently each of these (presumably) self-imposed project
requirements, the project needs to place plenty of trust on the rebasing
engine.  Which brings us back to the importance of the project's having
control over that simple but very critical computing detail.



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

Me too.  But is it gitolite itself that performs it?  I figured (from
the bit about delegating user and group management in your email) that
it would be a different component, that presumably also does
authentication, though even these two processes may be detached.

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

I can think of at least another reason that's kind of important to me:
project's freedom/autonomy/self-control.  Not having security from the
provider/supplier is typical of SaaSS/nonfree arrangements.

> 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 looks like you've broadened "publishing" to "web serving".

The way I understand and mean it, publishing makes very little room for
servers to make decisions.  They take what's given them to publish, and
make it available to anyone who requests it.  Think uploading a
formatted PDF for publishing, so that then anyone can download it from
that server.


Now, publishing a git repository is a little more involved than that.
There is server-side computing to figure out what blobs and deltas to
send based on what the other end already has, but the ultimate goal is
to deliver the bits in the requested commits/refs to the other party.
That's publishing.  Computing the pack to send efficiently is
legitimately the server operator's computing, involving some
communication with the other party.


Likewise, some of the web server scenarios you mentioned may also
qualify as legitimate server operator's computing.


It is not infrequent for something that we often think of as a single
bundle involves various different computing activities, and in some
cases, they don't all pertain to the same party.  Self-hosting makes it
easier to figure out because host and guest collapse into a single
party, but third-party hosting requires figuring out who deserves to
control each piece.

> I can't find a coherent argument as to why publishing and mediation of
> communication is "no single party's computing".

The arguments are different.  I went through publishing above.

Communication is easier, because it necessarily involves more than one
party, and it very often involves mediation.  When I hit send in my MUA
I might conceive of it as my own computing, but it will take various
other parties' computing for it to reach you.  From my MTA, it will go
to GNU's MTA, then on to Sourceware and to your employer's MTA, and
eventually you'll do your own computing and open your inbox to read
this.  Even if we were holding a private conversation and only used our
own private MTAs, the communication would still necessarily involve two
different parties who each lays a legitimate claim to the part of the
required computing that occurs on their own MTA and MUA.  It wouldn't
make sense for the entirety of the computing necessary for the
communication to be under control of either one of us: it takes two
(presumed autonomous) parties for communication to take place.

As for mediation...  even if my MTA talked "directly" to yours, that
would go through network interfaces, routers, and other network
components that do computing that implements lower-layer networking.
Routing and delivering network packets in lower layers is not very
conceptually or ethically different from routing and delivering
networked application (higher level) packets.  This mediation
legitimately belongs with the mediators, and control over our
communicating agents legitimately belongs with each of us.

But none of the three or more parties could legitimately lay a claim for
all the computing encompassed by this communication, so it's "no single
party's computing".


Now, if we were talking about internal communication between
parties/agents within a single organization, then it might make sense to
insist that the organization should have control over both ends, and
even over the network they use to communicate.  But even if it resorts
to third-party transport of packets, say between different buildings or
even different countries (planets anyone? ;-) that wouldn't amount to
SaaSS, because the routing, transport and delivery are not the
organization's own computing.


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

That seems a stretch.  The rebasing could be each of the three parties'
computing if done for each one's own sake.  But when it's done by the
project's forge to integrate a commit into a project's branch, it's hard
for me to conceive of it as anything but the project's computing.

> Or a system that applies a specific logic on whether to authorize a
> user because it involves the same three parties.

Authorization is not computing that involves the possibly-authorized
party, it's the project's computing to figure out whether the project
wishes to authorize the party to do something.  Authentication is
similar in most respects (the project wishes to verify the party's
identity), though it may also involve some computing on the requesting
party's end to prove the claimed identity (and that could be the
autonomous party's computing, or the organization's computing).

>> Not the sort of analysis that could
>> be done in a battlefield, for sure.

> I'm glad we're debating in good spirit :)

Oh, the two of us absolutely are.  Some others are, too.  But the
initial hostility I got from others is surely not gone; if they're even
paying attention, it's presumably dormant.

>> Another important consideration, that I realized after posting my
>> earlier message to you, is what recourse the project has if a service
>> provider refuses.

> 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's a concern even when it comes to free software running on one's
own computer, it doesn't render the software nonfree.

Giving up control over your computing to a third party who discourages
you from controlling your own computing whether through self-hosting or
by giving you enough control to the third party's infrastructure that
would do your computing, doesn't sound like a great idea.  Do you see
how threatening and manipulative that would sound? :-)

> That risk is the reason why shared infrastructure projects like
> sourceware, savannah, gitlab and github are such successes.

I don't think so.

I've seen enough replication of anti-patterns made popular by
exploitative providers, wherein the patterns become prevalent and
familiar because they serve the provider's exploitative business not
becuase they serve users, and they're pushed into popularity not by
their own merits or user preference, but by sheer market power of the
provider.  I'm thinking of things like doom infinite scrolling, user
tracking for ad placement, instant messaging expectations of zero-rating
and message presentation, imposition of LLMs, ...

The list is huge, and I know that pushing businesses and users to rely
on the so-called cloud (somebody else's computer) was largely driven by
claims of cost savings that match perfectly the early days of services
that eventually lock users in and then change the deal towards
enshittification so that the provider can finally reallocate the value
that previously attracted users to itself.

That Free Software projects often imitate these anti-patterns is
sometimes an unfortunate consequence of pursuing familiarity, but other
times it seems to be mindless imitation without understanding the
purpose behind design decisions that, in the original, are meant to
benefit the provider despite the harm brought upon the users, which
doesn't belong in user freedom-respecting projects.

When it comes to community hosting and forges, there are far superior
designs that don't enable the centralization and transfer of power over
the project to third parties, without loss of convenience to users.  GIT
is a great example of the sort of decentralization and avoidance of
power-over-others, but instead of going for something like peer-to-peer
hosting with client-side operations (as in git-ssb, gittorrent,
radicle), with issues and whatnot replicated along with the project's
code (as in pagure IIRC), we got Github with recentralization and tons
of plugs for lock in.

That's driven by market power, and lock in motivations, not by superior
user-driven design.

It's not a model to be mindlessly imitated, but to be questioned and
avoided, for our own sake.  Projects should aim to graduate to
autonomous self hosting, and good hosts, like good parents, should
encourage and facilitate that, rather than foment dependencies.

> - People who historically agreed with the four freedoms may disagree
>   with subsequent philosophical additions like SaaSS.

They may fail to realize that SaaSS brings about the same denial of
freedoms, but if they actually agree with the four essential freedoms
for users to control their computing, once they realize that SaaSS
denies them, and does so for the same reasons, either they embrace that,
or they didn't agree with the four freedoms to begin with.

> - People can disagree over details of what is and isn't SaaSS.

That's undeniable, but it's not as important as whether the disagreement
is well founded on Free Software philosophy and values, or based on a
reckless or ignorant disregard for our freedoms, for our control over
our computing.

> - People who are aware of the notion of SaaSS can disagree over what
>   the risk is and what to do about it.

That is true, and the same goes for programs that are widely recognized
as nonfree software.  When people deal with their own personal
computing, their risk assessments are up to themselves.  When we speak
of the GNU project, or a key part thereof, GNU values are paramount, and
GNU maintainers ought to uphold them, even if in their personal digital
lives they might be willing to be more reckless and less concerned about
their own freedom.

> - Most importantly, people mey be using a different thought framework

People in general may; GNU maintainers shouldn't.  Especially while
claiming to be aligned with GNU and Free Software values.

> I doubt that Carlos, David and Joseph are unaware or uncaring of FSF's
> position on this matter.

Their obligations towards the FSF are governed by the Working Together
fiscal sponsorship, but I guess that's not what you're speaking of.

I think you mean GNU.

They have responsibilities towards GNU as appointed GNU maintainers.

Their actions as maintainers have to be in line with that.

I have no evidence (I) that they understood SaaSS and why everyone
should avoid it just like nonfree software, and GNU packages more so; or
(ii) that they as much as care about what GNU leadership thinks about
the proposal at hand.

GNU maintainership is a delegated responsibility, and it's not
unbounded.  It doesn't look like they care about that either.
Unfortunately, getting money flowing from one of LF's hands to the other
to corrupt key pieces of GNU into giving up their own software freedom
is notably a lot higher in their priorities than caring about GNU values
and leadership structure.

> The whole point of that setup is to make 
> funding available for the projects that the sponsors depend on.

The funding is not available for the project, alas.  From all I've
heard, it can't be used by the project except to pay back that who
offers us the funds.

It's a divisive maneuver that offers "help" we haven't wanted, saught or
needed, to drive us to betray our values.

The proper term for that is corruption.


It also "buys" control of critical infrastructure, and for nothing,
because the money all necessarily goes back to the buyer.

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

We're on infrastructure that appears to care about enabling our
autonomy, even at its own inconvenience.

Whereas the proposed infrastructure seems to be attempting to mislead us
by insisting that everything would be implemented with free software,
without disclosing that it would mostly be SaaSS; heck, without even
understanding what SaaSS is, and that it renders otherwise-free software
nonfree, to the point of *attacking* and *dismissing* objections to
SaaSS.

It doesn't look good at all.

> 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

I've managed to find the patch in that web page.  It's pretty hard to
find.  The page looks like a nightmare to me; it doesn't seem to be at
all interested in cooperating with users who wish to keep control over
what software runs on their browsers.  On my personal computers, I don't
allow third parties to install and run arbitrary programs under their
control, because they would be nonfree for me even if they're free
software for the server operator.

As for the patch proper, I don't think I'm the person you're looking for
to review this, for it goes way over the top of my head.  I'm not at all
familiar with the technologies you're using there, so my review wouldn't
be of much use; I certainly wouldn't be comfortable approving this
because I can't tell what the implications are of the changes.

I do have one point of concern, though: I followed a URL in public
archives, I didn't have to authenticate, and yet I could see a patch
that changes a secrets file, including the addition of a private key.
That feels disturbing.

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

Re: Working together and gaining trust

[Mark Wielaard]

Hi Bradley, Hi Jeff,

On Fri, Feb 13, 2026 at 06:43:18PM -0800, Bradley M. Kuhn wrote:
> Jeffrey Law wrote earlier today:
> > I think we're still missing a key point.  Namely that from a
> > fundraising standpoint there are companies out there that are not
> > willing to channel money to Red Hat to run sourceware, nor are
> > they willing to fund via the FSF.   As soon as you bring in Red
> > Hat or the FSF you cut off those sources of funding.  They are
> > willing to fund infrastructure (via the CTI) outside the Red Hat
> > and FSF organizations.
> 
> Could you please name the specific organization(s) that would make a
> substantial ( ≥ $10k) contribution to fund Sourceware and/or
> infrastructure for glibc that would be unwilling to give such funds
> to all of the following organizations: { Red Hat, FSF, FSF Europe,
> Software Freedom Conservancy }
> 
> It would surprise me that such a donor exists — particularly given
> that they could earmark these donations specifically to support
> Sourceware infrastructure, or even Sourceware infrastructure
> specifically for glibc.

I think you are both right. Just talking about different subsets of
organizations and timeframes.

Five years ago, when Jeff was still at Red Hat, we were genuinely
worried about the specific relationship of the FSF and Red Hat
[1]. And multiple other organizations (not just corporations) made
similar statements about the FSF back then. At the same time it was
kind of silly to have just Red Hat fund the infrastructure especially
since it was mostly community run and hosted projects beyond the GNU
Toolchain, some of which Red Hat no longer had a financial interest
in. So the question became how do we do infrastructure in a way that
we can get funding to it, isnt the sole responsibility of the FSF or
Red Hat, and do it in a way that respects the community and the Free
Software ideals. Which is when the process of looking for a good home
for Sourceware started where everybody, not just Red Hat and/or the
FSF could contribute [2].

Now, five years later, after lots of discussions on the mailinglists,
at conferences like Cauldron and Fosdem, joining the SFC as member
project and with the formation of a Sourceware Project Leadership
Committee I think we have achieved that. Now all the organizations
that Bradley names can and do work together. And we have shown that
infrastructure can be funded by a combination of grants, corporate
sponsorship and community donations.

> But, if there is an example of such an organization, we should make
> it publicly known.  And we should ask these organizations why they
> have blackballed such a large swath of FOSS organizations, and they
> should answer this publicly — in the spirit or transparency and
> software freedom.

I think it is more subtle than that. And also works the other way
around. For example I talked to potential corporate sponsors that
didn't like they would needed to become LF members before being
allowed to donate money. But there are also corporations that, if
there are competing organizations that say to represent the same
community, pick supporting a business league that puts corporate
interests first and doesn't explicitly commit to Software Freedom or
community interests.

Which is why it is so important that before this CTI plan proceeds the
FSF as the original fund raising organiation for the GNU Toolchain
signs off on it and makes sure that a clear charter and board that
works in the interest of the community and guarantees the money is
spend on Free Software.

Although personally I don't see why we really need such an
organization when we already have Sourceware.

Cheers,

Mark

[1] https://www.redhat.com/en/blog/red-hat-statement-about-richard-stallmans-return-free-software-foundation-board
[2] https://inbox.sourceware.org/overseers/Yw5Q4b%2F2nqvAi3K4@elastic.org/

Re: Working together and gaining trust

[Siddhesh Poyarekar]

On 2026-02-16 05:14, Mark Wielaard wrote:
> Five years ago, when Jeff was still at Red Hat, we were genuinely
> worried about the specific relationship of the FSF and Red Hat
> [1]

Like I said earlier, the CTI efforts predate that by another 5 years. 
This had nothing to do with the RMS/FSF debacle; FSF has always found it 
hard to attract donations from companies beyond a certain point, despite 
the Working Together fund.

> So the question became how do we do infrastructure in a way that
> we can get funding to it, isnt the sole responsibility of the FSF or
> Red Hat, and do it in a way that respects the community and the Free
> Software ideals. Which is when the process of looking for a good home
> for Sourceware started where everybody, not just Red Hat and/or the
> FSF could contribute [2].

Oh come on Mark, please do not deceive yourself.  The overseers, 
including you, were made aware of the GTI project since well before 
Frank's call to support sourceware.  You reached out to the SFC after 
you learned about the GTI and did not like the idea.  I can respect that 
you didn't like the idea, but "forgetting" details that are inconvenient 
to your argument is inexcusable.

> Now, five years later, after lots of discussions on the mailinglists,
> at conferences like Cauldron and Fosdem, joining the SFC as member
> project and with the formation of a Sourceware Project Leadership
> Committee I think we have achieved that.

There is one thing we have ended up acheiving.  With sourceware forming 
its own PLC, we have multiple avenues of funding.

> I think it is more subtle than that. And also works the other way
> around. For example I talked to potential corporate sponsors that
> didn't like they would needed to become LF members before being

Please make sure you secure funding from them for Sourceware.  It's 
perfect that we turned out to have two sets of infrastructure, one to 
try things out and one to host stable core infrastructure.

> allowed to donate money. But there are also corporations that, if
> there are competing organizations that say to represent the same
> community, pick supporting a business league that puts corporate
> interests first and doesn't explicitly commit to Software Freedom or
> community interests.

That's a feeble excuse, here's another way to look at it: there are 
organizations that cannot justify funding a group that is basically a 
couple of volunteer administrators with little oversight.  However like 
I said, with CTI, Sourceware PLC and the GCC compile farm, ISTM that we 
have a wide funding net for infrastructure, core, ancillary as well as 
experimental.

> Which is why it is so important that before this CTI plan proceeds the
> FSF as the original fund raising organiation for the GNU Toolchain
> signs off on it and makes sure that a clear charter and board that
> works in the interest of the community and guarantees the money is
> spend on Free Software.

Nope, you're just inventing new governance rules now and creating 
friction where none exists.

Sid

Re: Working together and gaining trust

[Jeffrey Law]

On 2/13/2026 7:43 PM, Bradley M. Kuhn wrote:
> Jeff,
>
> Jeffrey Law wrote earlier today:
>> I think we're still missing a key point.  Namely that from a fundraising
>> standpoint there are companies out there that are not willing to channel
>> money to Red Hat to run sourceware, nor are they willing to fund via the
>> FSF.   As soon as you bring in Red Hat or the FSF you cut off those sources
>> of funding.  They are willing to fund infrastructure (via the CTI) outside
>> the Red Hat and FSF organizations.
> Could you please name the specific organization(s) that would make a
> substantial ( ≥ $10k) contribution to fund Sourceware and/or infrastructure
> for glibc that would be unwilling to give such funds to all of the following
> organizations: { Red Hat, FSF, FSF Europe, Software Freedom Conservancy }
I'm not going to call them out like that.


>
> But, if there is an example of such an organization, we should make it
> publicly known.  And we should ask these organizations why they have
> blackballed such a large swath of FOSS organizations, and they should answer
> this publicly — in the spirit or transparency and software freedom.
No, I'm not going to do that.  Sorry.

jeff

Re: Working together and gaining trust

[Joseph Myers]

On Sun, 15 Feb 2026, Alexandre Oliva wrote:

> > I doubt that Carlos, David and Joseph are unaware or uncaring of FSF's
> > position on this matter.
> 
> Their obligations towards the FSF are governed by the Working Together
> fiscal sponsorship, but I guess that's not what you're speaking of.
> 
> I think you mean GNU.
> 
> They have responsibilities towards GNU as appointed GNU maintainers.
> 
> Their actions as maintainers have to be in line with that.

The relevant criteria for GNU package hosting are the GNU ethical 
repository criteria, grade C or above.  As far as I know, both Sourceware 
and LF hosting meet those criteria.

All the other lengthy discussion about SaaSS philosophy in general seems 
offtopic for libc-alpha to me, and would better go somewhere else; I think 
gnu-misc-discuss might be the traditional location for such discussion.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Working together and gaining trust

[Mark Wielaard]

Hi Sid,

I genuinely believe we should try to work together by gaining trust. I
don't find your tone very useful to achieve that. We aren't enemies
deliberately trying to work against each other. We just have slightly
different priorities to work towards a common goal. Please be
respectful of others.

On Mon, Feb 16, 2026 at 08:18:04AM -0500, Siddhesh Poyarekar wrote:
> >So the question became how do we do infrastructure in a way that
> >we can get funding to it, isnt the sole responsibility of the FSF or
> >Red Hat, and do it in a way that respects the community and the Free
> >Software ideals. Which is when the process of looking for a good home
> >for Sourceware started where everybody, not just Red Hat and/or the
> >FSF could contribute [2].
> 
> Oh come on Mark, please do not deceive yourself.  The overseers,
> including you, were made aware of the GTI project since well before
> Frank's call to support sourceware.  You reached out to the SFC
> after you learned about the GTI and did not like the idea.  I can
> respect that you didn't like the idea, but "forgetting" details that
> are inconvenient to your argument is inexcusable.

You make it sound like we didn't like the idea of making Sourceware
independent from Red Hat or that reaching out to the SFC to setup a
proper Sourceware organisation was somehow not part of this plan. I
believe all overseers (whether they happened to work for Red Hat or
not) were initially enthousiastic about the idea to get more resources
for Sourceware. We even started making public resource estimates and
technical plans [1] [2]. The only detail some of us were worried about
was how we would make sure the community could be in control of the
assets, like new machines or contracts with payed staff. And Carlos
agreed with that worry and suggested we made sure Sourceware as
organization/community should be part of a 501(c)3 public benefit
(which is how https://www.kernel.org/nonprofit.html is also setup). So
we went with that idea, asked the SFC if they would like to help and
did a couple of months public consultation with the community (and
obviously Red Hat and the FSF) to make sure everyone was OK with that
and that it achieved those goals.

> there are organizations that cannot justify funding a group that is
> basically a couple of volunteer administrators with little
> oversight.

Which is precisely why we setup Sourceware as a Software Freedom
Conservancy member project. We now have staff that can help us buy our
own equipment, are experienced in drawing up contracts for paid
contractors or admin staff. Overseen by a Project Leadership Committee
with more than 100 years of combined experience hosting and
maintaining core toolchain and developer tool projects as Free
Software communities. We organize monthly meetups to coordinate with
all hosted projects, admins and the volunteers. Produce quarterly and
yearly progress reports. And coordinate the fundraising and all the
work the paid staff at the various organizations do to keep all
infrastructure running.

> >Which is why it is so important that before this CTI plan proceeds the
> >FSF as the original fund raising organiation for the GNU Toolchain
> >signs off on it and makes sure that a clear charter and board that
> >works in the interest of the community and guarantees the money is
> >spend on Free Software.
> 
> Nope, you're just inventing new governance rules now and creating
> friction where none exists.

I am not inventing, the friction is already there. The FSF has real
issues with this idea [3]. And given that the FSF is legally the
steward of the GNU Toolchain it is only professional for the LF to
discuss with the FSF if they want to take over some of that to make
sure they align on the goals.

And they aren't the only ones, other people have raised the same or
similar concerns. Lets try to address those. I hope we are still
trying to achieve community concensus. I have my own issues with the
FSF but that doesn't mean I don't take them serious and won't talk to
them. In fact I found them very cooperating. They do have paid staff
themselves which take care of various infrastructure for GNU
projects. We now help each other out where possible.

Cheers,

Mark

[1] https://inbox.sourceware.org/overseers/YpU+o8C8hyFsgtuP@wildebeest.org/
[2] https://lwn.net/Articles/898655/
[3] https://inbox.sourceware.org/f20ce996-e9c6-4b6c-856d-eec6e14af26e@fsf.org

Re: Working together and gaining trust

[Siddhesh Poyarekar]

On 2026-02-17 06:36, Mark Wielaard wrote:
> Hi Sid,
> 
> I genuinely believe we should try to work together by gaining trust. I

I agree a 100% that we should try to work together, but by omitting the 
parallels in the timelines you're trying to put out a narrative that the 
CTI initiative was sprung up on you after you had reached out to the SFC 
and done all of these things leading up to Cauldron 2022, which is 
simply not true.

This makes it hard for me to gain trust to the level I had 5 years ago, 
but I've worked in environments where I don't have ultimate trust in a 
person or organization's motives and I can live with having to work 
together without that implicit trust.

> don't find your tone very useful to achieve that. We aren't enemies
> deliberately trying to work against each other. We just have slightly
> different priorities to work towards a common goal. Please be
> respectful of others.

I apologize if I put anything out disrespectfully, I don't mean to 
disrespect you by calling you out on what I see as misrepresentation of 
events, I'm only pointing out that you're twisting the narrative to suit 
your argument.  I don't even mean to imply that it's malicious on your 
part, it could well be a detail that you've repeatedly missed addressing 
or simply don't remember.

> On Mon, Feb 16, 2026 at 08:18:04AM -0500, Siddhesh Poyarekar wrote:
>> Oh come on Mark, please do not deceive yourself.  The overseers,
>> including you, were made aware of the GTI project since well before
>> Frank's call to support sourceware.  You reached out to the SFC
>> after you learned about the GTI and did not like the idea.  I can
>> respect that you didn't like the idea, but "forgetting" details that
>> are inconvenient to your argument is inexcusable.
> 
> You make it sound like we didn't like the idea of making Sourceware
> independent from Red Hat or that reaching out to the SFC to setup a
> proper Sourceware organisation was somehow not part of this plan. I
> believe all overseers (whether they happened to work for Red Hat or
> not) were initially enthousiastic about the idea to get more resources
> for Sourceware. We even started making public resource estimates and
> technical plans [1] [2]. The only detail some of us were worried about

I don't deny that you didn't dislike the idea of being solely dependent 
on Red Hat for funding but again, you're sharing links that simply 
reinforce my conviction that reaching out to SFC was a reaction to 
disliking the LF IT proposal, which you were made aware of much before 
you let on in these public conversations.  It's absolutely OK if it was 
a reaction, it's fine too if you may have had reached out to SFC before 
or around the time that you got to know about the LF IT proposal.  But 
pretending that you didn't know about it until much later is 
disingenuous and doesn't invoke trust.

But you know what, it doesn't matter as far as the practical 
consequences are concerned because FWIW we've actually ended up in a 
better state where sourceware overseers have an avenue where they can 
continue to have full sysadmin control over their machines, we (the 
glibc project) has multiple avenues that it can tap into for infrastructure.

I have moved on from being upset at the Sourceware overseers playing 
politics to understanding that it all ended up being for the better of 
the ecosystem.

> was how we would make sure the community could be in control of the
> assets, like new machines or contracts with payed staff. And Carlos
> agreed with that worry and suggested we made sure Sourceware as
> organization/community should be part of a 501(c)3 public benefit
> (which is how https://www.kernel.org/nonprofit.html is also setup). So
> we went with that idea, asked the SFC if they would like to help and
> did a couple of months public consultation with the community (and
> obviously Red Hat and the FSF) to make sure everyone was OK with that
> and that it achieved those goals.
> 
>> there are organizations that cannot justify funding a group that is
>> basically a couple of volunteer administrators with little
>> oversight.
> 
> Which is precisely why we setup Sourceware as a Software Freedom
> Conservancy member project. We now have staff that can help us buy our
> own equipment, are experienced in drawing up contracts for paid
> contractors or admin staff. Overseen by a Project Leadership Committee
> with more than 100 years of combined experience hosting and
> maintaining core toolchain and developer tool projects as Free
> Software communities. We organize monthly meetups to coordinate with
> all hosted projects, admins and the volunteers. Produce quarterly and
> yearly progress reports. And coordinate the fundraising and all the
> work the paid staff at the various organizations do to keep all
> infrastructure running.

That's great, like I said, I've come to realize over the years that it 
doesn't have to be SFC vs CTI and that the two independent 
infrastructure avenues is a net positive outcome.  We're still going to 
continue using sourceware for a number of services, so I hope you're 
able to tap into more funding and volunteer admins to make that viable.

>>> Which is why it is so important that before this CTI plan proceeds the
>>> FSF as the original fund raising organiation for the GNU Toolchain
>>> signs off on it and makes sure that a clear charter and board that
>>> works in the interest of the community and guarantees the money is
>>> spend on Free Software.
>>
>> Nope, you're just inventing new governance rules now and creating
>> friction where none exists.
> 
> I am not inventing, the friction is already there. The FSF has real
> issues with this idea [3]. And given that the FSF is legally the
> steward of the GNU Toolchain it is only professional for the LF to
> discuss with the FSF if they want to take over some of that to make
> sure they align on the goals.

I'm referring to your claim of needing a signoff from the FSF; I don't 
think we need any such signoff since we satisfied their demand of not 
calling it GNU Toolchain Infrastructure.

> And they aren't the only ones, other people have raised the same or
> similar concerns. Lets try to address those. I hope we are still
> trying to achieve community concensus. I have my own issues with the

We've had most of the prominent glibc developers and maintainers respond 
to this thread with their support, and I thank them for doing this in 
public this time because I know it can be mentally draining to be 
involved in such discussions.  We're not going to make every single 
person happy here, but we can be extra vigilant with this knowledge and 
make sure that any worries that are expressed remain unfounded.

> FSF but that doesn't mean I don't take them serious and won't talk to
> them. In fact I found them very cooperating. They do have paid staff
> themselves which take care of various infrastructure for GNU
> projects. We now help each other out where possible.

I think we've addressed all concerns other than the "I don't like the 
LF", which I don't think we can address.  The best we can do is invoke 
our personal currency in the community as individuals in the TAC and say 
that we will ensure that if we're made aware of anything that goes 
against the principles of our community (which implicitly includes Free 
Software principles) we will do whatever it takes to remedy that, 
including moving infrastructure out if needed.

Sid

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 16, 2026, Joseph Myers <josmyers@redhat.com> wrote:

> The relevant criteria for GNU package hosting are the GNU ethical 
> repository criteria

Focus on hosting of software repositories, that's publishing and
therefore non-SaaSS.

Expanding the notion of hosting to encompass other computing activities
doesn't get them covered by those guidelines.

> All the other lengthy discussion about SaaSS philosophy in general seems 
> offtopic for libc-alpha to me

It's free software philosophy; SaaSS is just one of the means to deny
users the essential freedoms they deserve and need to control their
computing.

It's very concerning that you seem so willing to dismiss a key element
of free software philosophy, and so ready to give up our collective
freedoms.

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

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 17, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> say that we will ensure that if we're made aware of anything that goes 
> against the principles of our community (which implicitly includes
> Free Software principles) we will do whatever it takes to remedy that, 
> including moving infrastructure out if needed.

That's great news.  Can you share what has changed recently that brought
about this commitment to avoid the various means of denying users
control over their computing, from NDAs and denial of sorce code and
restrictive licenses to technical measures and SaaSS arrangements so as
to preserve our freedoms?

Or are you using the term "Free Software principles" in a twisted,
narrowed-down way to fit a narrative?


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

Re: Working together and gaining trust

[Siddhesh Poyarekar]

On 2026-02-17 18:50, Alexandre Oliva wrote:
> On Feb 17, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> say that we will ensure that if we're made aware of anything that goes
>> against the principles of our community (which implicitly includes
>> Free Software principles) we will do whatever it takes to remedy that,
>> including moving infrastructure out if needed.
> 
> That's great news.  Can you share what has changed recently that brought
> about this commitment to avoid the various means of denying users
> control over their computing, from NDAs and denial of sorce code and
> restrictive licenses to technical measures and SaaSS arrangements so as
> to preserve our freedoms?

The use of FOSS for all services we use is condition 0 for us, which in 
our case would be git, gitolite and mailing list using mlmmj (and BBB, 
which we have been using for some years now)  on a GNU/Linux based 
system.  I don't see any conflicts with our Free Software principles in 
this.

As for SaaSS, your definition keeps changing around based on who the 
parties involved are, so I'm afraid I don't see a serious point being 
made at all.  If glibc ever decides to use a forge, we would first pilot 
it with the sourceware instance, so maybe at that point you could try 
and come up with a SaaSS guideline that the community can review, 
hopefully without the inherent hatred towards specific individuals or 
organizations.

Sid

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 17, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> The use of FOSS for all services we use is condition 0 for us

Does that notion of FOSS exclude SaaSS, that renders software non-free
for the user that matters, or is that a way to weasel out of Free
Software principles while pretending to be in line with them?

> I don't see any conflicts with our Free Software
> principles in this.

You may be right about this limited set of services.

> As for SaaSS, your definition keeps changing around based on who the
> parties involved are,

Now, let's not be dishonest, please.

The definition has been set in stone for far more than a decade.

The difference you may be observing is in the commitment each party
displays to actual user freedom.

While some attempt to deny that SaaSS is an issue and not even think
about it, placing our freedom at risk, others strive to ensure users of
the service are in control rather than controlled (and helpless) because
of reliance on software that isn't free for them.

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

Re: Working together and gaining trust

[Siddhesh Poyarekar]

On 2026-02-18 05:34, Alexandre Oliva wrote:
> On Feb 17, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> The use of FOSS for all services we use is condition 0 for us
> 
> Does that notion of FOSS exclude SaaSS, that renders software non-free
> for the user that matters, or is that a way to weasel out of Free
> Software principles while pretending to be in line with them?

The trouble with including SaaSS unconditionally is that by nature the 
potential threats posed by SaaSS are more dependent on the parties 
involved and the perceived intent than straight up Free Software 
deployment.  That is why I requested that you build up an argument for 
that if/when we decide to adopt a service (e.g. a forge) that can 
potentially be a SaaSS threat.

>> I don't see any conflicts with our Free Software
>> principles in this.
> 
> You may be right about this limited set of services.
> 
>> As for SaaSS, your definition keeps changing around based on who the
>> parties involved are,
> 
> Now, let's not be dishonest, please.
> 
> The definition has been set in stone for far more than a decade.

The core idea of SaaSS may well be, but the idea itself in practice 
greatly depends on a number of factors involved as you've seen yourself 
in the discussions you've had in this thread.

> The difference you may be observing is in the commitment each party
> displays to actual user freedom.

The difference I observe is the varying standards applied to definition 
of user freedom commitment based on the parties involved and also how it 
varies based on the service involved.  It is inherent to the definition 
of SaaSS, which is why it's a task to consider each service (and take 
pains to make observations party-independent so as to not introduce 
personal biases) and not make a blanket statement about it.  This is 
also why your perception of SaaSS w.r.t. involved services and parties 
may not align with others'.

To repeat my request, please work out a SaaSS argument for a forge, 
independent of a vendor (e.g. what if the FSF gets a generous donor to 
host a forge and as a result the FSF is able to provide those services 
to GNU software?) so that we actually have concrete steps to meet if we 
ever decide to use a forge in glibc, like we have with the GNU Ethical 
Repository Criteria.  Maybe it could be an addendum to the GNU Ethical 
Repository Criteria.

Thanks,
Sid

Re: Working together and gaining trust

[Joseph Myers]

On Tue, 17 Feb 2026, Alexandre Oliva wrote:

> On Feb 16, 2026, Joseph Myers <josmyers@redhat.com> wrote:
> 
> > The relevant criteria for GNU package hosting are the GNU ethical 
> > repository criteria
> 
> Focus on hosting of software repositories, that's publishing and
> therefore non-SaaSS.

The active proposal for glibc is about repository and mailing list 
hosting.  This makes all the SaaSS discussion irrelevant to that proposal.  
All CI run in glibc development is particular people choosing to run CI 
for configurations they care about, and is their own computing, not the 
glibc project's computing and not SaaSS (and we don't have any proposal 
for moving such CI).

> > All the other lengthy discussion about SaaSS philosophy in general seems 
> > offtopic for libc-alpha to me
> 
> It's free software philosophy; SaaSS is just one of the means to deny
> users the essential freedoms they deserve and need to control their
> computing.
> 
> It's very concerning that you seem so willing to dismiss a key element
> of free software philosophy, and so ready to give up our collective
> freedoms.

I'm not dismissing it, I'm redirecting the discussions of it to more 
appropriate locations.  The GNU project has different mailing lists for 
discussion of different topics.  gnu-misc-discuss is the GNU project 
location for discussion of philosophical issues, and discussions about the 
development of glibc are offtopic there.  libc-alpha is the GNU project 
location for discussions related to development of glibc, and general 
philosophical discussions are offtopic there.  We don't have active 
proposals for more use of the Sourceware forge for glibc, but for anything 
about the forge in general, it also has its own mailing list, where 
discussions of the forge not relating to more specific uses for a specific 
project would be appropriate.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 18, 2026, Joseph Myers <josmyers@redhat.com> wrote:

> The active proposal for glibc is about repository and mailing list 
> hosting

... for now.

I'm sort of relieved that the proposal seems to (accidentally AFAICT)
not get us into any SaaSS scenarios.

But unless involved people take these issues into account, rather than
come across as dismissive and even hostile to these concerns, sooner or
later there will be proposals to bring us into such undesirable
scenarios.

>> It's very concerning that you seem so willing to dismiss a key element
>> of free software philosophy, and so ready to give up our collective
>> freedoms.

> I'm not dismissing it, I'm redirecting the discussions of it to more 
> appropriate locations.

It seems like you're attempting to censor dissent.

If this is the place to discuss proposals of moving important parts of
glibc infrastructure into the hands of third parties, this must also be
the place to discuss how to ensure alignment of such very proposals with
our values.

We can't afford to only discuss the philosophical issues that these
proposals must abide by elsewhere, especially while people in here show
time and again that they're significantly unaware of and unfamiliar with
foundational principles of the movement that incide directly on choices
being proposed and discussed here.

Discussing those values elsewhere will NOT solve this unawareness
problem that's become evident HERE.

If you wish to have such infrastructure proposals brought to the glibc
community and discussed in glibc fora where they belong, arguments both
for and against will be brought to glibc fora.  Neither infrastructure
nor GNU nor glibc are merely technical issues, so the discussion around
them is not to be limited to technical matters.

GNU and glibc's goals are not technical, they're social and political
*through* technical means, so pushing out the social and political
matters would be a severe mistake.

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

Re: Working together and gaining trust

[Alexandre Oliva]

On Feb 18, 2026, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> potential threats posed by SaaSS are more dependent on the parties 
> involved

No, no, the reasons to retain our software freedom are the same
regardless of what means would be used to take it away, or by whom.

It's a very common misconception that third parties that are friendly
now will remain friendly, or that hostile ones will remain hostile, but
that's not how things work.  Such alignments change, and that's why
keeping freedom is important: ceding control over ourselves to a hostile
party is immediately perceivable as foolish, but ceding control over
ourselves to a friendly party doesn't seem foolish immediately, it only
reveals itself as such later, when the alignment between us and the
friendly party changes, whether that's because they changed or because
we did.

And none of this has to do with SaaSS specifically.  If you install a
piece of nonfree software for use on your own computer, particularly of
the modern kind that calls home and auto-updates, it may also seem like
relying on a friendly supplier is less problem-prone than on a hostile
one, but once you've given control to the third party (through the
installed software, the information it collects and the universal
backdoor in its auto-update machinery), that control will make the
supplier a more attractive target for hostile take-overs, for corrupting
and enshittifying forces.

>> Now, let's not be dishonest, please.
>> The definition has been set in stone for far more than a decade.

> The core idea of SaaSS may well be, but the idea itself in practice
> greatly depends on a number of factors involved as you've seen
> yourself in the discussions you've had in this thread.

I suppose you mean the deal of determining whose computing a program or
service does, and whom it pertains to.  Yeah, it's not as immediately
obvious as when you do your computing on your own computers.

But that's not a reason to go recklessly doing your computing on others'
computers.  Quite the opposite: when it doubt, strive to do it on your
own computer.  If that proves to be impossible, because it involves
other parties, that may very well be a symptom that it's not your
computing.

> The difference I observe is the varying standards applied to
> definition of user freedom commitment based on the parties involved

Then we have to do some work on that misperception.

I guess my vocal dislike for the LF, and your favor to it, contribute to
bringing noise to your observation.

I suppose a mispresumption that I'm favorable to the Sourceware
arrangements, or aligned with those who favor Sourceware, contribute as
well.

Your being on the 'for' side can make it seem like everyone who's
'against' is a single block acting in unison.  That's a misassumption
that can further twist perceptions and observations.


My primary concern is to ensure we don't take steps that undermine our
freedoms.  As long as we do that, and more importantly, as long as the
community knows what to avoid to keep our freedom, there's very little
reason for me (or anyone) to be concerned about who offers us services.

But while a far-from-negligible fraction of the community takes an
ignorant, dismissive and even at times hostile attitude to taking
precautions to defend our freedoms from certain common lines of attack,
and seemingly insist on taking steps before as much as understanding
what, erhm, landmines (to keep with the analogy of steps) are, let alone
seeking assurance that there aren't any at the desired destination or on
the path towards it, I can't help feeling and raising concerns about it.

> This is also why your perception of SaaSS w.r.t. involved
> services and parties may not align with others'.

I have no evidence that it doesn't align with that of others who are
familiar with the concept.

I have plenty of evidence that it doesn't align with that of others who
aren't, but what are the odds that they would?

> To repeat my request, please work out a SaaSS argument for a forge,

That's not how it works.  "forge" is too abstract a concept, and one
that is not even familiar to me.  We have to look into each and every
piece of computing that you (and others) mean by "forge", and work out
how to reassure our control over the computing that is ours, in case we
decide to use a forge hosted by someone else.  That's a lot of labor.

Since there is likely to be some computing of ours involved in a forge,
I'd much rather we all agreed to *save* that labor by deciding to host
our forge under our own control, if we want a forge.

> (e.g. what if the FSF gets a generous donor to host a forge and as a
> result the FSF is able to provide those services to GNU software?)

You'd presumably get something like Savannah.  If you expect more of a
"forge", such as its doing some of the hosted project's computing, you'd
pretty much *necessarily* get into self-hosting territory.

It really is that simple.  Outsourcing your computing, so that it runs
under someone else's *control* (!= *computers*), is what SaaSS is about,
and since that takes your software freedom away, that's a no-no,
especially for the FSF and for GNU.

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

Re: Working together and gaining trust

[Joseph Myers]

On Wed, 18 Feb 2026, Alexandre Oliva wrote:

> >> It's very concerning that you seem so willing to dismiss a key element
> >> of free software philosophy, and so ready to give up our collective
> >> freedoms.
> 
> > I'm not dismissing it, I'm redirecting the discussions of it to more 
> > appropriate locations.
> 
> It seems like you're attempting to censor dissent.
> 
> If this is the place to discuss proposals of moving important parts of
> glibc infrastructure into the hands of third parties, this must also be
> the place to discuss how to ensure alignment of such very proposals with
> our values.

But not the place for very abstract discussions in general of how CI 
systems and forges relate to software freedom, divorced from any 
connection to any current glibc proposal.

As noted by someone else: maybe the GNU ethical repository criteria should 
have a companion discussing software freedom considerations for forges.  
But libc-alpha *is not the place to figure out the answers to such 
questions*.  Once they have been figured out *elsewhere*, then they may be 
a useful input to future discussions of such things for glibc.

Of course the people working on such a companion document need to have 
experience of forge-based / pull-request-based development, and of 
development using CI systems that enforce the "not rocket science rule", 
in order to understand the benefits of those things in practice.  Advice 
on how one way of acheiving those benefits is better than another way for 
software freedom can be useful.  Advice without experience of those 
things, or advice that prevents achieving those benefits, isn't.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Working together and gaining trust

[Mark Wielaard]

Hi all,

Sorry for not immediately replying to this discussion. I had a death
in the family which took a lot of (emotional) energy. And then there
was of course the Sourceware hardware refresh cycle to finalize last
week.

But I am happy the emotions seem to have calmed down and the proposal
now technically just amounts to a glibc git branch cleanup, which seem
way less controversial. But these controversial proposals seem to come
back every 9 to 15 months out of nowhere. So we probably should
discuss how to resolve this properly without all the drama. Also
because it eats up lots of energy which distracts from the actual
infrastructure improvements. So I hope the FSF, SFC, OpenSSF and LF
can just sit down and discuss how to efficiently move forward.

Part of the issue seems to be some events five years ago that resulted
in one of the people advocating for closer ties to the LF to start
yelling, screaming and punching people at the Cauldron event. This
obviously didn't improve the discussion back then. And seems to still
cause miscommunication and feelings of bad faith. Lets see if we can
get past that. I don't believe any of that was "against" each other,
just miscommunication and difference in expectations

Also in the last five years Sourceware diversified our hardware
partners and sponsors through grants and individual donations, setup
new services using containers and isolated VMs, investigated secure
supply chain issues and cyber security regulations, added redundant
mirrors, invested in open communication, open office hours and
introduced community oversight by the Sourceware Project Leadership
Committee with the help from the Software Freedom Conservancy

So the discussion is completely different from five years ago.
Ironically Sourceware became so "professional" that some people are
now apparently seeing it as "the other" that might control their
compute. But in reality the Sourceware PLC, overseers and admins are
still just members of the various hosted projects working on our
infrastructure together.

On Tue, Feb 17, 2026 at 07:58:37AM -0500, Siddhesh Poyarekar wrote:
> On 2026-02-17 06:36, Mark Wielaard wrote:
> >You make it sound like we didn't like the idea of making Sourceware
> >independent from Red Hat or that reaching out to the SFC to setup a
> >proper Sourceware organization was somehow not part of this plan. I
> >believe all overseers (whether they happened to work for Red Hat or
> >not) were initially enthusiastic about the idea to get more resources
> >for Sourceware. We even started making public resource estimates and
> >technical plans [1] [2]. The only detail some of us were worried about
> 
> I don't deny that you didn't dislike the idea of being solely
> dependent on Red Hat for funding but again, you're sharing links
> that simply reinforce my conviction that reaching out to SFC was a
> reaction to disliking the LF IT proposal, which you were made aware
> of much before you let on in these public conversations.  It's
> absolutely OK if it was a reaction, it's fine too if you may have
> had reached out to SFC before or around the time that you got to
> know about the LF IT proposal.  But pretending that you didn't know
> about it until much later is disingenuous and doesn't invoke trust.

This is 5 years ago, so we might misremember the timeline or what was
known to who. All I can say is that I don't remember involving the LF
IT really had been part of any of the discussions. And even if I knew
I wouldn't be against that because I know Konstantine and would have
liked the resources to hire him and working together. We did discuss
setting up Sourceware like kernel.org which also is a non-profit
getting sponsorship money through the LF. Which is why we reached out
to the SFC to help us with that. And it was actually Carlos that
suggested we do that so the community could hold assets and enter into
contracts, etc.

Same with the public resource estimates, technical plans and
presenting about the infrastructure services at Cauldron. We wanted to
let potential sponsors know what the community needed and were working
on. We just wanted to make sure that we had the organization and
community setup to start working with more corporate sponsors if they
would show up. Which I thought the LF plan was all about. So it
certainly wasn't against that. The idea was for us to work together
not against.

> >>>Which is why it is so important that before this CTI plan proceeds the
> >>>FSF as the original fund raising organization for the GNU Toolchain
> >>>signs off on it and makes sure that a clear charter and board that
> >>>works in the interest of the community and guarantees the money is
> >>>spend on Free Software.
> >>
> >>Nope, you're just inventing new governance rules now and creating
> >>friction where none exists.
> >
> >I am not inventing, the friction is already there. The FSF has real
> >issues with this idea [3]. And given that the FSF is legally the
> >steward of the GNU Toolchain it is only professional for the LF to
> >discuss with the FSF if they want to take over some of that to make
> >sure they align on the goals.
> 
> I'm referring to your claim of needing a signoff from the FSF; I
> don't think we need any such signoff since we satisfied their demand
> of not calling it GNU Toolchain Infrastructure.

I don't know if just changing the name suddenly makes it legitimate. I
guess the FSF and the LF will have to have a talk about the conditions
that would make it so.

But my main point really is that as a project we shouldn't just ignore
the FSF or do things they clearly don't agree with. We have a good
working relation now with the FSF and the FSF tech team, they have
paid staff which provides various services for some of our hosted
projects. Lets work together with them. If they point out issues that
concern them then lets make sure we address them together. We aren't
adversaries, we all just want to advance Free Software.

> I think we've addressed all concerns other than the "I don't like
> the LF", which I don't think we can address.  The best we can do is
> invoke our personal currency in the community as individuals in the
> TAC and say that we will ensure that if we're made aware of anything
> that goes against the principles of our community (which implicitly
> includes Free Software principles) we will do whatever it takes to
> remedy that, including moving infrastructure out if needed.

The best you could do is fix the charter and board requirements. It is
the shaky governance that people don't like. The charter doesn't even
talk about Free Software. The board just seems to be about who pays
most and then even decides who may "advise" them. Why not add some
guardrails to the charter by describing what raised money may be used
for. Make sure the board has at least the FSF as a member. It doesn't
have to rely on just "personal currency", you can just put down things
in writing you agree on.

But also the LF and OpenSSF could just work directly with the FSF,
SFC, Sourceware and the project community so we can improve the
infrastructure together.

Cheers,

Mark

Re: Working together and gaining trust

[Carlos O'Donell]

On 3/6/26 8:17 AM, Mark Wielaard via Overseers wrote:
> Sorry for not immediately replying to this discussion. I had a death
> in the family which took a lot of (emotional) energy. And then there
> was of course the Sourceware hardware refresh cycle to finalize last
> week.

I'm sorry to hear that :-(

Thank you for your support, but please take the time you need for your
family.
  
> But I am happy the emotions seem to have calmed down and the proposal
> now technically just amounts to a glibc git branch cleanup, which seem
> way less controversial. But these controversial proposals seem to come
> back every 9 to 15 months out of nowhere. So we probably should
> discuss how to resolve this properly without all the drama. Also
> because it eats up lots of energy which distracts from the actual
> infrastructure improvements. So I hope the FSF, SFC, OpenSSF and LF
> can just sit down and discuss how to efficiently move forward.

Please allow me to me clarify.

The branch cleanup is the first step to get a gitolite configuration
that is valid for a transition to CTI provided services.

Branch cleanup is not an end to itself, but a start.

We are proceeding down the path outlined in the announcement email.

> So the discussion is completely different from five years ago.
> Ironically Sourceware became so "professional" that some people are
> now apparently seeing it as "the other" that might control their
> compute. But in reality the Sourceware PLC, overseers and admins are
> still just members of the various hosted projects working on our
> infrastructure together.

Even if Sourceware is different from where it was five years ago, and
that's good, it still does not meet the requirements for security,
robustness, isolation and sustainability that the GNU Toolchain or
glibc need.

Are there services where we can work together? Absolutely, and I think
it's critical that Sourceware continue for those projects that decide
to use Sourceware and for other services where we need hands on
development efforts e.g. new workflows, pre/post-commit CI.

Are there core services which are going to be expensive to fund
sustainably and need a dedicated IT team to handle the isolation
and maintenance?

Yes, and CTI exists to meet those core service requirements with a
different and sustainable funding model.

> On Tue, Feb 17, 2026 at 07:58:37AM -0500, Siddhesh Poyarekar wrote:
>> On 2026-02-17 06:36, Mark Wielaard wrote:
>>> You make it sound like we didn't like the idea of making Sourceware
>>> independent from Red Hat or that reaching out to the SFC to setup a
>>> proper Sourceware organization was somehow not part of this plan. I
>>> believe all overseers (whether they happened to work for Red Hat or
>>> not) were initially enthusiastic about the idea to get more resources
>>> for Sourceware. We even started making public resource estimates and
>>> technical plans [1] [2]. The only detail some of us were worried about
>>
>> I don't deny that you didn't dislike the idea of being solely
>> dependent on Red Hat for funding but again, you're sharing links
>> that simply reinforce my conviction that reaching out to SFC was a
>> reaction to disliking the LF IT proposal, which you were made aware
>> of much before you let on in these public conversations.  It's
>> absolutely OK if it was a reaction, it's fine too if you may have
>> had reached out to SFC before or around the time that you got to
>> know about the LF IT proposal.  But pretending that you didn't know
>> about it until much later is disingenuous and doesn't invoke trust.
> 
> This is 5 years ago, so we might misremember the timeline or what was
> known to who. All I can say is that I don't remember involving the LF
> IT really had been part of any of the discussions. And even if I knew
> I wouldn't be against that because I know Konstantine and would have
> liked the resources to hire him and working together. We did discuss
> setting up Sourceware like kernel.org which also is a non-profit
> getting sponsorship money through the LF. Which is why we reached out
> to the SFC to help us with that. And it was actually Carlos that
> suggested we do that so the community could hold assets and enter into
> contracts, etc.

You were aware early that I was proposing delegating cores services to
a paid IT team, and that I have always been recommending LF IT from the
start given their FOSS alignment.

I advised you at the time to seek out additional sources of funding.

You did that by reaching out to the SFC.

> Same with the public resource estimates, technical plans and
> presenting about the infrastructure services at Cauldron. We wanted to
> let potential sponsors know what the community needed and were working
> on. We just wanted to make sure that we had the organization and
> community setup to start working with more corporate sponsors if they
> would show up. Which I thought the LF plan was all about. So it
> certainly wasn't against that. The idea was for us to work together
> not against.

I agree we should work together.

What does that look like to you going forward?

>>>>> Which is why it is so important that before this CTI plan proceeds the
>>>>> FSF as the original fund raising organization for the GNU Toolchain
>>>>> signs off on it and makes sure that a clear charter and board that
>>>>> works in the interest of the community and guarantees the money is
>>>>> spend on Free Software.
>>>>
>>>> Nope, you're just inventing new governance rules now and creating
>>>> friction where none exists.
>>>
>>> I am not inventing, the friction is already there. The FSF has real
>>> issues with this idea [3]. And given that the FSF is legally the
>>> steward of the GNU Toolchain it is only professional for the LF to
>>> discuss with the FSF if they want to take over some of that to make
>>> sure they align on the goals.
>>
>> I'm referring to your claim of needing a signoff from the FSF; I
>> don't think we need any such signoff since we satisfied their demand
>> of not calling it GNU Toolchain Infrastructure.
> 
> I don't know if just changing the name suddenly makes it legitimate. I
> guess the FSF and the LF will have to have a talk about the conditions
> that would make it so.

You have twice called into question the legitimacy of the GNU Project
to make decisions on both this mailing list and on the GCC mailing
list and both times you've been told you are not correct.

For reference:
https://inbox.sourceware.org/gcc/20250616165940.GS30295@gate.crashing.org/
https://inbox.sourceware.org/libc-alpha/c9ae9bf3-5f18-4493-8367-d613818ec916@redhat.com/

In this case you are also incorrect.

> But my main point really is that as a project we shouldn't just ignore
> the FSF or do things they clearly don't agree with. We have a good
> working relation now with the FSF and the FSF tech team, they have
> paid staff which provides various services for some of our hosted
> projects. Lets work together with them. If they point out issues that
> concern them then lets make sure we address them together. We aren't
> adversaries, we all just want to advance Free Software.

I agree we all want to advance Free Software.

We started conversations with the FSF very early to understand the
foundations position on this topic.

I'll continue to engage with the FSF and the GNU Project.
  
>> I think we've addressed all concerns other than the "I don't like
>> the LF", which I don't think we can address.  The best we can do is
>> invoke our personal currency in the community as individuals in the
>> TAC and say that we will ensure that if we're made aware of anything
>> that goes against the principles of our community (which implicitly
>> includes Free Software principles) we will do whatever it takes to
>> remedy that, including moving infrastructure out if needed.
> 
> The best you could do is fix the charter and board requirements. It is
> the shaky governance that people don't like. The charter doesn't even
> talk about Free Software. The board just seems to be about who pays
> most and then even decides who may "advise" them. Why not add some
> guardrails to the charter by describing what raised money may be used
> for. Make sure the board has at least the FSF as a member. It doesn't
> have to rely on just "personal currency", you can just put down things
> in writing you agree on.

In general "people" trust the GNU Toolchain leadership to negotiate,
like we have, for the last 30 years, to have sponsors that are aligned
with the mission and vision of the GNU Project and support the use of
FOSS.

Is the CTI charter the biggest concern you have today?

> But also the LF and OpenSSF could just work directly with the FSF,
> SFC, Sourceware and the project community so we can improve the
> infrastructure together.
This is a false dichotomy.

We can move the GNU Toolchain to CTI services using paid IT for
core infrastructure *in addition* to supporting Sourceware.

We are working with the project community.

We are improving infrastructure together.

-- 
Cheers,
Carlos.

Re: Working together and gaining trust

[Mark Wielaard]

Hi all,

On Fri, Mar 06, 2026 at 04:56:17PM -0500, Carlos O'Donell wrote:
> On 3/6/26 8:17 AM, Mark Wielaard via Overseers wrote:
> >So the discussion is completely different from five years ago.
> >Ironically Sourceware became so "professional" that some people are
> >now apparently seeing it as "the other" that might control their
> >compute. But in reality the Sourceware PLC, overseers and admins are
> >still just members of the various hosted projects working on our
> >infrastructure together.
> 
> Even if Sourceware is different from where it was five years ago, and
> that's good, it still does not meet the requirements for security,
> robustness, isolation and sustainability that the GNU Toolchain or
> glibc need.

So lets build on those improvements and see how we get there together.
And lets make sure those requirements are captured in our plans
https://sourceware.org/sourceware-security-vision.html#plans
so that we keep improving on those issues in a sustainable way.

> >This is 5 years ago, so we might misremember the timeline or what was
> >known to who. All I can say is that I don't remember involving the LF
> >IT really had been part of any of the discussions. And even if I knew
> >I wouldn't be against that because I know Konstantine and would have
> >liked the resources to hire him and working together. We did discuss
> >setting up Sourceware like kernel.org which also is a non-profit
> >getting sponsorship money through the LF. Which is why we reached out
> >to the SFC to help us with that. And it was actually Carlos that
> >suggested we do that so the community could hold assets and enter into
> >contracts, etc.
> 
> You were aware early that I was proposing delegating cores services to
> a paid IT team, and that I have always been recommending LF IT from the
> start given their FOSS alignment.
> 
> I advised you at the time to seek out additional sources of funding.
> 
> You did that by reaching out to the SFC.

Maybe I misremember your preference to do that specifically through
the LF IT, sorry. I believe hiring paid IT staff can be done in
various ways. The main point was that we agreed that even if we could
get corporate funding through the LF as a trade orginization and hire
paid IT staff we would still need community oversight through a public
charity, which you pointed out is how kernel.org is setup, and to
manage the assets and contracts. Secondary it was about long term
continuity, we wanted to setup something that would provide the
Sourceware communities with infrastructure they could trust for the
next 25 years without relying on just corporate goodwill. Funding
certainly is more stable and sustainable having not just corporate
sponsors but also being able to rely on grants and community
donations.

> >Same with the public resource estimates, technical plans and
> >presenting about the infrastructure services at Cauldron. We wanted to
> >let potential sponsors know what the community needed and were working
> >on. We just wanted to make sure that we had the organization and
> >community setup to start working with more corporate sponsors if they
> >would show up. Which I thought the LF plan was all about. So it
> >certainly wasn't against that. The idea was for us to work together
> >not against.
> 
> I agree we should work together.
> 
> What does that look like to you going forward?

Hopefully we could start public requirements discussions through this
overseers and project specific mailinglists and other public
communication channels the Sourceware Project Leadership Committee
setup https://sourceware.org/mission.html#organization

I must admit I don't realy know what to do about these CTI
proclamations you seem to sent out every 9 to 15 months. Like the one
that started this thread. I really dislike that style of communication.

> >>>>>Which is why it is so important that before this CTI plan proceeds the
> >>>>>FSF as the original fund raising organization for the GNU Toolchain
> >>>>>signs off on it and makes sure that a clear charter and board that
> >>>>>works in the interest of the community and guarantees the money is
> >>>>>spend on Free Software.
> >>>>
> >>>>Nope, you're just inventing new governance rules now and creating
> >>>>friction where none exists.
> >>>
> >>>I am not inventing, the friction is already there. The FSF has real
> >>>issues with this idea [3]. And given that the FSF is legally the
> >>>steward of the GNU Toolchain it is only professional for the LF to
> >>>discuss with the FSF if they want to take over some of that to make
> >>>sure they align on the goals.
> >>
> >>I'm referring to your claim of needing a signoff from the FSF; I
> >>don't think we need any such signoff since we satisfied their demand
> >>of not calling it GNU Toolchain Infrastructure.
> >
> >I don't know if just changing the name suddenly makes it legitimate. I
> >guess the FSF and the LF will have to have a talk about the conditions
> >that would make it so.
> 
> You have twice called into question the legitimacy of the GNU Project
> to make decisions on both this mailing list and on the GCC mailing
> list and both times you've been told you are not correct.

I think you are confusing how foundation staff/board work together
with how projects make decissions through a consensus process.

> For reference:
> https://inbox.sourceware.org/gcc/20250616165940.GS30295@gate.crashing.org/
> https://inbox.sourceware.org/libc-alpha/c9ae9bf3-5f18-4493-8367-d613818ec916@redhat.com/
> 
> In this case you are also incorrect.

It is never incorrect to support someones idea for a process
improvement if the current process seems stuck or broken. Sometimes
you conclude, collectively, the process can be fixed in a different
way, other times you conclude a change is necessary. That is simply
trying to find community concensus on how we work together. What would
be wrong is to not find a majority for your proposal, having sustained
opposition, and still insisting your proposal will be executed as is.

> >But my main point really is that as a project we shouldn't just ignore
> >the FSF or do things they clearly don't agree with. We have a good
> >working relation now with the FSF and the FSF tech team, they have
> >paid staff which provides various services for some of our hosted
> >projects. Lets work together with them. If they point out issues that
> >concern them then lets make sure we address them together. We aren't
> >adversaries, we all just want to advance Free Software.
> 
> I agree we all want to advance Free Software.
> 
> We started conversations with the FSF very early to understand the
> foundations position on this topic.
> 
> I'll continue to engage with the FSF and the GNU Project.

Lets make sure we do.

> >>I think we've addressed all concerns other than the "I don't like
> >>the LF", which I don't think we can address.  The best we can do is
> >>invoke our personal currency in the community as individuals in the
> >>TAC and say that we will ensure that if we're made aware of anything
> >>that goes against the principles of our community (which implicitly
> >>includes Free Software principles) we will do whatever it takes to
> >>remedy that, including moving infrastructure out if needed.
> >
> >The best you could do is fix the charter and board requirements. It is
> >the shaky governance that people don't like. The charter doesn't even
> >talk about Free Software. The board just seems to be about who pays
> >most and then even decides who may "advise" them. Why not add some
> >guardrails to the charter by describing what raised money may be used
> >for. Make sure the board has at least the FSF as a member. It doesn't
> >have to rely on just "personal currency", you can just put down things
> >in writing you agree on.
> 
> In general "people" trust the GNU Toolchain leadership to negotiate,
> like we have, for the last 30 years, to have sponsors that are aligned
> with the mission and vision of the GNU Project and support the use of
> FOSS.

And we should thank those individuals who did that in the past. But
when you setup an organization to help with that, then it does make
sense to write that down. So it isn't just the burden of specific
people to guard it, but a collective mission and vision (executed by
the paid staff of the organization).

> Is the CTI charter the biggest concern you have today?

It certainly starts with the proposed charter.

> >But also the LF and OpenSSF could just work directly with the FSF,
> >SFC, Sourceware and the project community so we can improve the
> >infrastructure together.
>
> This is a false dichotomy.

It isn't meant to be a division into two especially mutually exclusive
or contradictory groups or parts (sorry, I had to lookup the
definition of dichotomy). Precisely the opposite. It wasn't always
easy for the FSF/GNU, Sourceware and the SFC to work together, but we
made it work. Now when adding the LF/OpenSSF to the mix lets make sure
there aren't any trust issues between them by making them try to work
directly with each other first. So they can coordinate who does what
and why.

Cheers,

Mark

Re: Working together and gaining trust

[Siddhesh Poyarekar]

On 2026-03-12 07:55, Mark Wielaard wrote:
> I must admit I don't realy know what to do about these CTI
> proclamations you seem to sent out every 9 to 15 months. Like the one
> that started this thread. I really dislike that style of communication.
I think the dissonance here is that you're unwilling to acknowledge 
progress and keep insisting in every new thread that the discussion is 
over and CTI is gone.

We admittedly failed to push back consistently when you've said that in 
the past, but in this current thread, I'm trying hard to make sure that 
whenever you say that, I push back and point to the messages of support 
we've managed to gather publicly this time, but somehow you keep saying 
it again.  I don't know how to get you to accept this reality.

We have the office hour every Friday where we welcome people to come 
with questions.  Please engage if there's something that's still not 
clear to you in terms of what the next steps are here.

Sid