Re: [Action Required] glibc decision to use CTI services.

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

[adding libc-alpha, where GNU libc discussions are held]

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

> I propose the glibc project migrate to services provided by the 
> Core Toolchain Infrastructure (CTI) project, particularly services
> provided by the Linux Foundation IT team.

Nay.  I do not perceive any benefits to GNU's values in becoming
technologically dependent on an organization that never shared GNU's
values, that has constantly pretended GNU didn't exist, persistently
claimed our work to itself, and promotes and operates under values that
conflict deeply with those that GNU stands for.  It would amount to
shooting itself in the paws.

I acknowledge that the present supplier of equivalent services also
started in a hostile manner, but at this point it's the devil we know.

The plan should IMHO be to mitigate that dependency, not introduce
another or replace one with a worse one.

As I suggested back when this idea was first raised (and AFAICT there
have been no attempts to dispute that this would be a better path to
pursue), I'd be happy to accept this sort of contribution to GNU *iff*
the services were *actively* *replicated* among two or three separate
suppliers, so as to reduce the risk of dependency and of corrupting
pressure on us.

Even then, this would IMHO be a move for GNU to decide, or at the very
least be consulted on, according to its own values and priorities,
something that all mantainers appointed by GNU, myself included,
committed ourselves to observe, prioritize and uphold as maintainers of
GNU packages.  I encourage other maintainers to justify their responses
based on GNU's values and priorities, as they understand them.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[Joseph Myers]

On Wed, 30 Aug 2023, Alexandre Oliva wrote:

> Even then, this would IMHO be a move for GNU to decide, or at the very
> least be consulted on, according to its own values and priorities,
> something that all mantainers appointed by GNU, myself included,
> committed ourselves to observe, prioritize and uphold as maintainers of
> GNU packages.  I encourage other maintainers to justify their responses
> based on GNU's values and priorities, as they understand them.

I believe the LF has already agreed to implement the hosting entirely with 
free software.  Naturally we should make sure that other requirements from 
https://www.gnu.org/software/repo-criteria.en.html such as "Does not 
discriminate against classes of users, or against any country. (C2)" and 
"Permits access via Tor (we consider this an important site function). 
(C3)" are met, though I don't expect problems there.  Several criteria are 
trivally met or inapplicable simply because they concern things that are 
beyond the scope of this proposed hosting (for example, recommending 
particular choices of license, or offering choices of license, is entirely 
outside the scope of what these hosting facilities do, just as it's 
outside the scope of what Sourceware does - those are criteria for 
general-purpose hosting sites that anyone might add a package to).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Action Required] glibc decision to use CTI services.

[Paul Eggert]

On 2023-08-30 10:31, Joseph Myers wrote:
> I believe the LF has already agreed to implement the hosting entirely with
> free software.

Where is this agreement written down? I didn't see it in the URLs 
mentioned at the start of this thread.

Too often it is tempting to use non-free software in these enterprises, 
and we need to have an agreement and a commitment about an enforcement 
mechanism that detects and repairs things if somebody falls victim to 
this temptation (and of course that guides people away from succumbing 
to the temptation in the first place). This detection and enforcement 
mechanism has to be usable by glibc software contributors and 
maintainers, not just by the CTI providers.

As I'm new to this (I just read yesterday that a decision is wanted by 
today) I'll vote NAY until I see something more binding about this 
important issue.


> Naturally we should make sure that other requirements from 
> https://www.gnu.org/software/repo-criteria.en.html ...  are met, though I don't expect problems there.

Although I don't expect problems either, I'd like to see this written 
down as well.

Re: [Action Required] glibc decision to use CTI services.

[Sam James]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2023-08-30 10:31, Joseph Myers wrote:
>> I believe the LF has already agreed to implement the hosting entirely with
>> free software.
>
> Where is this agreement written down? I didn't see it in the URLs
> mentioned at the start of this thread.
>
> Too often it is tempting to use non-free software in these
> enterprises, and we need to have an agreement and a commitment about
> an enforcement mechanism that detects and repairs things if somebody
> falls victim to this temptation (and of course that guides people away
> from succumbing to the temptation in the first place). This detection
> and enforcement mechanism has to be usable by glibc software
> contributors and maintainers, not just by the CTI providers.
>
> As I'm new to this (I just read yesterday that a decision is wanted by
> today) I'll vote NAY until I see something more binding about this
> important issue.
>

It's still unclear to me what problems this will solve compared to
using sourceware.

As far as I've seen, the sourceware overseers handle requests
promptly. Is there something we've asked them to do which they've
been unable to fulfill?

thanks,
sam

Re: [Action Required] glibc decision to use CTI services.

[Florian Weimer]

* Sam James via Libc-alpha:

> As far as I've seen, the sourceware overseers handle requests
> promptly. Is there something we've asked them to do which they've
> been unable to fulfill?

Removing the From: header rewriting from the mailing lists, including
libc-alpha.  With the current list configuration, “git am” often does
not produce correct results.

Thanks,
Florian

Re: [Action Required] glibc decision to use CTI services.

[Sam James]

Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:

> * Sam James via Libc-alpha:
>
>> As far as I've seen, the sourceware overseers handle requests
>> promptly. Is there something we've asked them to do which they've
>> been unable to fulfill?
>
> Removing the From: header rewriting from the mailing lists, including
> libc-alpha.  With the current list configuration, “git am” often does
> not produce correct results.

Have we communicated that to the overseers though (that it's so serious
it's worth moving services over)? Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713
already from you, but that's not the same as "this is a showstopper".

I wasn't aware this was a serious blocker given b2 helps collect the
Reviewed-bys anyway. But I can understand it being a pain for some
people's workflows.

thanks,
sam

dmarc, dkim and From rewriting

[Mark Wielaard]

Hi,

On Fri, Sep 01, 2023 at 10:02:23AM +0100, Sam James via Libc-alpha wrote:
> Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
> > * Sam James via Libc-alpha:
> >
> >> As far as I've seen, the sourceware overseers handle requests
> >> promptly. Is there something we've asked them to do which they've
> >> been unable to fulfill?
> >
> > Removing the From: header rewriting from the mailing lists, including
> > libc-alpha.  With the current list configuration, “git am” often does
> > not produce correct results.
> 
> Have we communicated that to the overseers though (that it's so serious
> it's worth moving services over)?
> Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713
> already from you, but that's not the same as "this is a showstopper".
> 
> I wasn't aware this was a serious blocker given b2 helps collect the
> Reviewed-bys anyway. But I can understand it being a pain for some
> people's workflows.

Sorry this is being resolved slowly. But as you can see in the bug
progress is being made, we just upgraded our mailman instance again
last week. I had requested testers a couple of months ago [1], but
didn't get much/any response, so I thought this wasn't very urgent. I
think we are ready to switch the list to not use From rewriting for
lists that want that. We could test it next week?

Cheers,

Mark

[1] https://inbox.sourceware.org/libc-alpha/Y2GocuarFslwvb9j@wildebeest.org/

Re: dmarc, dkim and From rewriting

[Florian Weimer]

* Mark Wielaard:

> Sorry this is being resolved slowly. But as you can see in the bug
> progress is being made, we just upgraded our mailman instance again
> last week. I had requested testers a couple of months ago [1], but
> didn't get much/any response, so I thought this wasn't very urgent. I
> think we are ready to switch the list to not use From rewriting for
> lists that want that. We could test it next week?

> [1] https://inbox.sourceware.org/libc-alpha/Y2GocuarFslwvb9j@wildebeest.org/

I read <https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c35>
and comments in the vicinity as expressing a desire not to make the
change (i.e., keep From: header rewriting) for compatibility with
DKIM defaults in certain widely deploy free software MTAs.

Thanks,
Florian

Re: [Action Required] glibc decision to use CTI services.

[Andrew Pinski]

On Fri, Sep 1, 2023 at 1:56 AM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> * Sam James via Libc-alpha:
>
> > As far as I've seen, the sourceware overseers handle requests
> > promptly. Is there something we've asked them to do which they've
> > been unable to fulfill?
>
> Removing the From: header rewriting from the mailing lists, including
> libc-alpha.  With the current list configuration, “git am” often does
> not produce correct results.

Isn't that due to security (anti-spam) measures of many ISPs?
How can someone solve that issue without the rewriting due to mailing
lists and security measures not going hand in hand these days?

Thanks,
Andrew

>
> Thanks,
> Florian
>

Re: [Action Required] glibc decision to use CTI services.

[Florian Weimer]

* Andrew Pinski:

> On Fri, Sep 1, 2023 at 1:56 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> * Sam James via Libc-alpha:
>>
>> > As far as I've seen, the sourceware overseers handle requests
>> > promptly. Is there something we've asked them to do which they've
>> > been unable to fulfill?
>>
>> Removing the From: header rewriting from the mailing lists, including
>> libc-alpha.  With the current list configuration, “git am” often does
>> not produce correct results.
>
> Isn't that due to security (anti-spam) measures of many ISPs?

No, not really, it's about preserving the integrity of messages.
Something that we should interested in anyway, particularly for patches.
Historically, Mailman promoted editing of messages in various ways while
distributing them over the list, and DKIM/DMARC prevents that.

> How can someone solve that issue without the rewriting due to mailing
> lists and security measures not going hand in hand these days?

It's true that the default DKIM configuration in Debian & Co. prevents
forwarding of DKIM-signed mail over mailing lists while preserving the
signature: they explicitly sign message in such a way that they assert
the non-existence of headers related to mailing lists.

Empirically, the large mail operators and most corporations (as long as
they do not use Debian & Co.) simply don't do this.  Their signatures
only cover the body and critical headers already included in the message
(and which the mailing list software does not need to alter).  For
others, it's just a minor configuration change, which is hopefully easy
to implement for smaller organizations.

Mailing lists without From: rewriting are not unusual at all: gnu.org,
kernel.org, openjdk.java.net all operate in this way, to name just a
few.  So upstream participation often requires that you use a mail
service that does not prohibit distributing mail over mailing lists.

There's one remaining issue: what to do with mail that has HTML
alternate parts that you want to remove as a list policy matter.  This
requires stripping certain DKIM signatures, which in turn my necessitate
From: header rewriting, depending on the DMARC policy.  But this
unlikely to get implemented in the Red Hat version of Mailman 2 (that
sourceware.org uses).

Thanks,
Florian

Re: [Action Required] glibc decision to use CTI services.

[Frank Ch. Eigler]

fweimer wrote:

>> As far as I've seen, the sourceware overseers handle requests
>> promptly. Is there something we've asked them to do which they've
>> been unable to fulfill?
>
> Removing the From: header rewriting from the mailing lists, including
> libc-alpha.  [...]

Each mailing list has its own administrator, who has the power to switch
off these mailman2 spam-proofing measures (at their own risk of course).

- FChE

Re: [Action Required] glibc decision to use CTI services.

[Siddhesh Poyarekar]

On 2023-09-01 02:03, Sam James via Libc-alpha wrote:
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
>> On 2023-08-30 10:31, Joseph Myers wrote:
>>> I believe the LF has already agreed to implement the hosting entirely with
>>> free software.
>>
>> Where is this agreement written down? I didn't see it in the URLs
>> mentioned at the start of this thread.
>>
>> Too often it is tempting to use non-free software in these
>> enterprises, and we need to have an agreement and a commitment about
>> an enforcement mechanism that detects and repairs things if somebody
>> falls victim to this temptation (and of course that guides people away
>> from succumbing to the temptation in the first place). This detection
>> and enforcement mechanism has to be usable by glibc software
>> contributors and maintainers, not just by the CTI providers.

It is the Technical Advisory Committee that decides on the 
infrastructure tech and that is comprised completely of members from the 
GNU toolchain community.  We will make sure that glibc services are 
implemented using Free software.

>>
>> As I'm new to this (I just read yesterday that a decision is wanted by
>> today) I'll vote NAY until I see something more binding about this
>> important issue.
>>
> 
> It's still unclear to me what problems this will solve compared to
> using sourceware.
> 
> As far as I've seen, the sourceware overseers handle requests
> promptly. Is there something we've asked them to do which they've
> been unable to fulfill?

There was a fairly long thread here and on overseers list last year on 
the motivation for moving to LFIT, if that's what you're asking about. 
To summarize, it's not about the overseers, who have indeed been prompt 
in handling requests and providing support for existing infrastructure. 
It's about doing things like service isolation, future 
enhancements/scaling and dedicated devops, that current infrastructure 
(that we depend on Red Hat to provide) is unable to support. 
Essentially, this is a move from Red Hat to LF.

Sid

Re: [Action Required] glibc decision to use CTI services.

[Paul Eggert]

On 2023-09-01 05:30, Siddhesh Poyarekar wrote:

> It is the Technical Advisory Committee that decides on the 
> infrastructure tech and that is comprised completely of members from the 
> GNU toolchain community.  We will make sure that glibc services are 
> implemented using Free software.

This sounds good, but I don't see the Linux Foundation agreeing to it in 
the URLs Carlos mentioned at the start of this thread (see below). What 
I see are statements[1][2] from the GNU Toolchain Infrastructure project 
that GTI has "requested" that only free software be used. This is not 
the same thing.

It'd be helpful to have a statement from the Linux Foundation that they 
agree to use only free software to support glibc, and that GTI's 
Technical Advisory Committee is empowered to inspect the Core Toolchain 
Infrastructure used for glibc, so that the GTI TAC can verify that only 
free software is used.

This shouldn't be that much to ask for. And I would think that the Linux 
Foundation would welcome such an agreement, not only because the Linux 
Foundation wants to support free software, but because it wants its 
infrastructure to be open and checkable and usable by others.


> it's not about the overseers, who have indeed been prompt in handling requests and providing support for existing infrastructure. It's about doing things like service isolation, future enhancements/scaling and dedicated devops

It would indeed be nice to have things like that.


Here are the URLs from Carlos's earlier email.

> [1] https://sourceware.org/pipermail/overseers/2022q3/018896.html
> [2] https://sourceware.org/pipermail/overseers/2022q4/018981.html
> [3] https://lore.kernel.org/gti-tac/804cee43-a120-3acf-a302-b1640f2285a9@redhat.com/
> [4] https://lore.kernel.org/cti-tac/47d5d7a0-60ab-b400-2f75-880fdaae0738@redhat.com/T/#u
> [5] https://sourceware.org/pipermail/libc-alpha/2023-August/150610.html
> [6] https://sourceware.org/pipermail/libc-alpha/2023-July/150071.html

Re: [Action Required] glibc decision to use CTI services.

[Siddhesh Poyarekar]

On 2023-09-01 10:54, Paul Eggert wrote:
> On 2023-09-01 05:30, Siddhesh Poyarekar wrote:
> 
>> It is the Technical Advisory Committee that decides on the 
>> infrastructure tech and that is comprised completely of members from 
>> the GNU toolchain community.  We will make sure that glibc services 
>> are implemented using Free software.
> 
> This sounds good, but I don't see the Linux Foundation agreeing to it in 
> the URLs Carlos mentioned at the start of this thread (see below). What 
> I see are statements[1][2] from the GNU Toolchain Infrastructure project 
> that GTI has "requested" that only free software be used. This is not 
> the same thing.
> 
> It'd be helpful to have a statement from the Linux Foundation that they 
> agree to use only free software to support glibc, and that GTI's 
> Technical Advisory Committee is empowered to inspect the Core Toolchain 
> Infrastructure used for glibc, so that the GTI TAC can verify that only 
> free software is used.
> 
> This shouldn't be that much to ask for. And I would think that the Linux 
> Foundation would welcome such an agreement, not only because the Linux 
> Foundation wants to support free software, but because it wants its 
> infrastructure to be open and checkable and usable by others.

Ack, I'll leave this for Carlos to bring up with LF.  As far as my 
understanding goes, it's upon us as TAC to drive this but we can figure 
out the specifics.

Thanks,
Sid

Re: [Action Required] glibc decision to use CTI services.

[Sam James]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:

> On 2023-09-01 02:03, Sam James via Libc-alpha wrote:
>> Paul Eggert <eggert@cs.ucla.edu> writes:
>> 
>>> On 2023-08-30 10:31, Joseph Myers wrote:
>>>> I believe the LF has already agreed to implement the hosting entirely with
>>>> free software.
>>>
>>> Where is this agreement written down? I didn't see it in the URLs
>>> mentioned at the start of this thread.
>>>
>>> Too often it is tempting to use non-free software in these
>>> enterprises, and we need to have an agreement and a commitment about
>>> an enforcement mechanism that detects and repairs things if somebody
>>> falls victim to this temptation (and of course that guides people away
>>> from succumbing to the temptation in the first place). This detection
>>> and enforcement mechanism has to be usable by glibc software
>>> contributors and maintainers, not just by the CTI providers.
>
> It is the Technical Advisory Committee that decides on the
> infrastructure tech and that is comprised completely of members from
> the GNU toolchain community.  We will make sure that glibc services
> are implemented using Free software.

Thank you.

>
>>>
>>> As I'm new to this (I just read yesterday that a decision is wanted by
>>> today) I'll vote NAY until I see something more binding about this
>>> important issue.
>>>
>> It's still unclear to me what problems this will solve compared to
>> using sourceware.
>> As far as I've seen, the sourceware overseers handle requests
>> promptly. Is there something we've asked them to do which they've
>> been unable to fulfill?
>
> There was a fairly long thread here and on overseers list last year on
> the motivation for moving to LFIT, if that's what you're asking
> about.

Thanks - I did read that at the time, but I wasn't very specific here,
sorry. I guess I meant I don't really understand the transition plan
if it goes ahead.

While we know they handle kernel.org fine, I'm a bit nervous
about it being an unknown entity wrt glibc - and also whether
it needs to be all or nothing.

Could they not provide services in addition to sourceware,
at least initially? Do we need to move all the eggs?

Or, to put it another way: it just seems like a leap into the unknown
and I don't really get why it's worth it yet.

> To summarize, it's not about the overseers, who have indeed
> been prompt in handling requests and providing support for existing
> infrastructure. It's about doing things like service isolation, future
> enhancements/scaling and dedicated devops, that current infrastructure
> (that we depend on Red Hat to provide) is unable to
> support. Essentially, this is a move from Red Hat to LF.
>

Have we actually hit scaling issues? The only real thing we need to
scale up is our testing AFAIK - which we have builder.sourceware.org for now
and it's growing.

I can see the advantage in dedicated devops and service isolation -
although I don't know if sw has given an opinion on whether they can
do service isolation.

best,
sam

Re: [Action Required] glibc decision to use CTI services.

[Frank Ch. Eigler]

sam wrote:

> [...]  I can see the advantage in dedicated devops and service
> isolation - although I don't know if sw has given an opinion on
> whether they can do service isolation. [...]

For what it's worth, I don't recall seeing an actual complete worked-out
plan for precisely what kinds of isolation are desired (never mind why),
and how they would all be provided at LF.  Therefore, it has not been
possible for sourceware folks to contemplate providing an equivalent.

- FChE

Re: [Action Required] glibc decision to use CTI services.

[Siddhesh Poyarekar]

On 2023-09-01 11:01, Sam James wrote:
> Thanks - I did read that at the time, but I wasn't very specific here,
> sorry. I guess I meant I don't really understand the transition plan
> if it goes ahead.

We've been discussing it in some detail on the CTI TAG mailing list[1]. 
The actual transition plan will come when the stewards vote to actually 
approve this.  It would be a waste of time if there's no interest among 
the stewards to move services to LFIT.

> While we know they handle kernel.org fine, I'm a bit nervous
> about it being an unknown entity wrt glibc - and also whether
> it needs to be all or nothing.

Yes there are differences but they're all workflow related.  In terms of 
setup and scale though, glibc is in the noise compared to the kernel and 
what we're really hoping for is to pick up some of the infrastructure 
they already have for the kernel, e.g. patchwork automation and 
pre-commit CI.  At the moment there are at least 3 people (including me) 
spending time on this when we could be doing something else.

It's also not really all or nothing.  I expect some services to remain 
on sourceware because they're distributed by default, e.g. builder.

> Could they not provide services in addition to sourceware,
> at least initially? Do we need to move all the eggs?
> 
> Or, to put it another way: it just seems like a leap into the unknown
> and I don't really get why it's worth it yet.

We've been discussing this for some years now (in the true spirit of 
conservatism that is prevalent in the GNU toolchain community when it 
comes to major changes), so I don't know if it's fair to look at it as a 
leap into the unknown :)

>> To summarize, it's not about the overseers, who have indeed
>> been prompt in handling requests and providing support for existing
>> infrastructure. It's about doing things like service isolation, future
>> enhancements/scaling and dedicated devops, that current infrastructure
>> (that we depend on Red Hat to provide) is unable to
>> support. Essentially, this is a move from Red Hat to LF.
>>
> 
> Have we actually hit scaling issues? The only real thing we need to
> scale up is our testing AFAIK - which we have builder.sourceware.org for now
> and it's growing.

The builder doesn't really need the sourceware server to scale.  I don't 
think glibc singularly has hit scaling issues but it shares the same 
instance of most services with most other sourceware projects, not to 
mention the fact that it's all on one machine.  That is a *lot* of core 
software crammed into a single box.

> I can see the advantage in dedicated devops and service isolation -
> although I don't know if sw has given an opinion on whether they can
> do service isolation.

I don't think Red Hat has the infrastructure behind sourceware to do 
anything more than it currently does.  It's all just one machine.  I 
don't know if anybody made requests for it though.

Thanks,
Sid

[1] 
https://lore.kernel.org/cti-tac/b1fa024-2144-2645-bdc5-96588a529cf0@codesourcery.com/T/#t

Re: [Action Required] glibc decision to use CTI services.

[Mark Wielaard]

Hi Sam,

On Fri, Sep 01, 2023 at 04:01:02PM +0100, Sam James wrote:
> >>> As I'm new to this (I just read yesterday that a decision is wanted by
> >>> today) I'll vote NAY until I see something more binding about this
> >>> important issue.
> >>>
> >> It's still unclear to me what problems this will solve compared to
> >> using sourceware.
> >> As far as I've seen, the sourceware overseers handle requests
> >> promptly. Is there something we've asked them to do which they've
> >> been unable to fulfill?
> >
> > There was a fairly long thread here and on overseers list last year on
> > the motivation for moving to LFIT, if that's what you're asking
> > about.
> 
> Thanks - I did read that at the time, but I wasn't very specific here,
> sorry. I guess I meant I don't really understand the transition plan
> if it goes ahead.
> 
> While we know they handle kernel.org fine, I'm a bit nervous
> about it being an unknown entity wrt glibc - and also whether
> it needs to be all or nothing.
> 
> Could they not provide services in addition to sourceware,
> at least initially? Do we need to move all the eggs?
> 
> Or, to put it another way: it just seems like a leap into the unknown
> and I don't really get why it's worth it yet.

As others said there is no transition plan, just a list of services
Sourceware currently provides, some of which LF IT might also be able
to provide. There are also (less detailed) Sourceware services lists
at https://sourceware.org/mission.html#services and per project at
https://sourceware.org/projects.html

There doesn't need to be a transition (plan) if people are ok with
staying with Sourceware. There is a roadmap and people dedicated to
maintaining and expanding the services together with various hardware
and services partners.

https://sourceware.org/mission.html#organization
https://sourceware.org/sourceware-25-roadmap.html

And of course before creating any transition plan there is the
question of the governance of this proposed new organization. Does it
give the same guarantees of money being used for Software Freedom and
community focus as the Sourceware/SFC setup?

https://sourceware.org/mission.html#plc
https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

> Have we actually hit scaling issues? The only real thing we need to
> scale up is our testing AFAIK - which we have builder.sourceware.org
> for now and it's growing.
> 
> I can see the advantage in dedicated devops and service isolation -
> although I don't know if sw has given an opinion on whether they can
> do service isolation.

I am sure the Sourceware project can. As you say we have been scaling
builder.sourceware.org very nicely so it is doing 15.000+ builds a
month across 28 bare metal, VMs and container workers. And we have
multiple hardware and service partners now.

https://sourceware.org/mission.html#sponsors

Next to the two servers Red Hat provides we also have three from
OSUOSL. So some of the new services are already running on separate
machines in different datacenters. Other services have been setup so
they can be easily migrated to VMs or separate servers.

We also have good working relationships with the FSF tech-team, which
already runs various services for the GNU projects, and the OSUOSL,
which we have asked to run services, like the mattermost server, where
they have more expertise. Both have paid staff to look after servers
and services.

We have monthly Open Office hours to learn from the community about
any (scaling) issues and then the Sourceware Project Leadership
Committee meets to discuss any issues, set priorities and decide how
to spend any funds and/or negotiate with hardware and service partners
to resolve them together with the Software Freedom Conservancy staff.

Cheers,

Mark

Re: [Action Required] glibc decision to use CTI services.

[Mark Wielaard]

Hi Paul,

On Thu, Aug 31, 2023 at 12:59:11PM -0700, Paul Eggert wrote:
> On 2023-08-30 10:31, Joseph Myers wrote:
> >I believe the LF has already agreed to implement the hosting entirely with
> >free software.
> 
> Where is this agreement written down? I didn't see it in the URLs
> mentioned at the start of this thread.
> 
> Too often it is tempting to use non-free software in these
> enterprises, and we need to have an agreement and a commitment about
> an enforcement mechanism that detects and repairs things if somebody
> falls victim to this temptation (and of course that guides people
> away from succumbing to the temptation in the first place). This
> detection and enforcement mechanism has to be usable by glibc
> software contributors and maintainers, not just by the CTI
> providers.
> 
> As I'm new to this (I just read yesterday that a decision is wanted
> by today) I'll vote NAY until I see something more binding about
> this important issue.

What I understand from the earlier GTI proposal last year (which
caused so much drama around the 2022 Cauldron [1]) nothing about this
was written down.

The idea was to set up a directed fund operated by the Linux
Foundation. Paying members of the Linux Foundation would then be able
to put money into this fund in exchange for board seats. The community
would get an advisory role on how to spend these funds.

One proposal was to use some of these funds to have the Linux
Foundation IT team provide shared services which they already provide
for the linux kernel project. The LF IT team was asked to only use
Free Software to provide those services. And that if Free Software
versions of necessary tools are missing, to work with Free Software
supporters to develop Free Software alternatives. But no agreement
about using Free Software was made when funds are spend any other way.

I cannot tell whether this new CTI proposal has fixed these flaws
because I was not involved. But I can tell you what we did for
Sourceware to address these issues and what has been written down.

Sourceware is a Software Freedom Conservancy member project [2]. The
SFC accepts earmarked donations for Sourceware from anybody,
individuals, corporations or grant organizations. The SFC does receive
a handling fee for providing the Fiscal Sponsorship services [3] and
so the project avoids non-profit administrivia. This money will be
spend according to the mission of the SFC to support community-driven
free software.

Sourceware community is represented by the Sourceware Project
Leadership Committee [4]. The Sourceware PLC makes all financial
decisions. The PLC includes (old) overseers, hosted project
representatives, steering committee and GNU maintainers. The current
members are Elena Zannoni, Ian Lance Taylor, Ian Kelling, Frank
Ch. Eigler, Christopher Faylor, Jon Turney, Tom Tromey and me.

The Fiscal Sponsorship Agreement [5] between the SFC and Sourceware
states that for projects Sourceware hosts everything will be
distributed solely as Free Software and that we will publish all
services as free software. We follow a conflict of interest policy
[6].

Cheers,

Mark

[1] https://lwn.net/Articles/908638/
[2] https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/
[3] https://sfconservancy.org/projects/services/
[4] https://sourceware.org/mission.html#plc
[5] https://sourceware.org/Conservancy-Sourceware-FSA.pdf
[6] https://sfconservancy.org/projects/policies/conflict-of-interest-policy.html

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

On Aug 31, 2023, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 2023-08-30 10:31, Joseph Myers wrote:
>> I believe the LF has already agreed to implement the hosting entirely with
>> free software.

> Where is this agreement written down?

To the best of my knowledge, it just isn't.  It's the sort of commitment
that's not worth the paper it's written on.

Besides, LF is not really about Free Software, and never has been.  They
might as well prefer to refer to it with such weasel words as Open
Source Software, that when it comes to the software mean pretty much the
same, but that shift the focus and motivations away from the freedom
that software users deserve.

One of the consequences of this shift is that people who swallow their
terms are more prone to make mistakes and forget that when doing your
computing through third-party services, the software that the
third-party uses, if free, respects the service *provider*'s freedom,
not the service *users*' freedom, and the users end up even more
helpless than in the case of proprietary software.

That's how SaaSS providers have managed to fool some Free
Software-caring people time and again, making them believe that it's
enough for the software to respect someone else's freedom.  Multiple
businesses have engaged in lock in through SaaSS, and we need to make
sure we avoid such traps.


And then, even if there was a written agreement, the other relevant
question is who'd enforce it.  Just like a strong copyleft without
enforcement is little different from de-facto optional compliance, LF's
making an alleged commitment to a group without any leverage or means
for enforcement is little different from the group's having begging
rights.  That's not a position I want us to be in.

It's not like the LF has a long history of respecting or caring for
software freedom that could make their unwritten allegation more
trustworthy.  The kernel Linux, that they're named after, contains
binary blobs, after all.  Their board is packed with companies who have
long disregarded provisions of the GNU GPL, even when it comes to Linux.

If the LF were at a bank trying to borrow some money, these factors
would demand the bank to require *more* assurance from the borrower, not
less, than from a random borrower without such a history of not living
up to commitments to others.

We should be no less careful than this hypothetical bank in protecting
our collective assets, particularly our freedom.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[Carlos O'Donell]

On 8/31/23 15:59, Paul Eggert wrote:
> On 2023-08-30 10:31, Joseph Myers wrote:
>> I believe the LF has already agreed to implement the hosting
>> entirely with free software.
> 
> Where is this agreement written down? I didn't see it in the URLs
> mentioned at the start of this thread.

CTI is the project providing the services. CTI asks the provider, LF IT, to adhere
to our requirements which include the use of only FOSS in the deployment of the
services.

I will work with the CTI TAC and LF IT to setup documents that detail the requests
and what will be provided and I'll publish those publicly.

We have also had requests for ensuring that we have a proper strategy for changing
providers. I will document those also. Some services are quite hard in reality
like Bugzilla or Patchwork which have databases that need duplication.

> Too often it is tempting to use non-free software in these
> enterprises, and we need to have an agreement and a commitment about
> an enforcement mechanism that detects and repairs things if somebody
> falls victim to this temptation (and of course that guides people
> away from succumbing to the temptation in the first place). This
> detection and enforcement mechanism has to be usable by glibc
> software contributors and maintainers, not just by the CTI
> providers.

Thanks for that input.

-- 
Cheers,
Carlos.

Re: [Action Required] glibc decision to use CTI services.

[Paul Eggert]

On 9/27/23 06:49, Carlos O'Donell wrote:
> CTI is the project providing the services. CTI asks the provider, LF IT, to adhere
> to our requirements which include the use of only FOSS in the deployment of the
> services.
> 
> I will work with the CTI TAC and LF IT to setup documents that detail the requests
> and what will be provided and I'll publish those publicly.
> 
> We have also had requests for ensuring that we have a proper strategy for changing
> providers. I will document those also. Some services are quite hard in reality
> like Bugzilla or Patchwork which have databases that need duplication.

Thanks, this is exactly the sort of thing I was looking for.

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

On Aug 30, 2023, Joseph Myers <joseph@codesourcery.com> wrote:

> On Wed, 30 Aug 2023, Alexandre Oliva wrote:
>> Even then, this would IMHO be a move for GNU to decide, or at the very
>> least be consulted on, according to its own values and priorities,
>> something that all mantainers appointed by GNU, myself included,
>> committed ourselves to observe, prioritize and uphold as maintainers of
>> GNU packages.  I encourage other maintainers to justify their responses
>> based on GNU's values and priorities, as they understand them.

> I believe the LF has already agreed to implement the hosting entirely with 
> free software.

Meeting basic requirements that, if not met, would make the service
provider profoundly hostile to software freedom is a far cry from being
in line with the movement's values.

Are you familiar with the notion of SaaSS, Service as a Software
Substitute?

"LF has agreed to such and such" doesn't sound good for me.  "We the
community have decided to implement our own services so and so" would
have made a lot of difference in avoiding the ills of SaaSS, but that
doesn't seem to even be in the radar of the path that is being proposed.

Now, this doesn't pertain to activities of publishing source code;
publishing is not SaaSS.  Remote merging, building, testing, and other
activities that are being bundled with source code publishing services,
however, are computing, community computing, and communities of such key
projects ought to not only be careful to avoid enabling third parties to
subjugate us through SaaSS, but also show other communities how to go
about avoiding that.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[Carlos O'Donell]

On 8/30/23 13:31, Joseph Myers wrote:
> On Wed, 30 Aug 2023, Alexandre Oliva wrote:
> 
>> Even then, this would IMHO be a move for GNU to decide, or at the very
>> least be consulted on, according to its own values and priorities,
>> something that all mantainers appointed by GNU, myself included,
>> committed ourselves to observe, prioritize and uphold as maintainers of
>> GNU packages.  I encourage other maintainers to justify their responses
>> based on GNU's values and priorities, as they understand them.
> 
> I believe the LF has already agreed to implement the hosting entirely with 
> free software.  Naturally we should make sure that other requirements from 
> https://www.gnu.org/software/repo-criteria.en.html such as "Does not 
> discriminate against classes of users, or against any country. (C2)" and 
> "Permits access via Tor (we consider this an important site function). 
> (C3)" are met, though I don't expect problems there.  Several criteria are 
> trivally met or inapplicable simply because they concern things that are 
> beyond the scope of this proposed hosting (for example, recommending 
> particular choices of license, or offering choices of license, is entirely 
> outside the scope of what these hosting facilities do, just as it's 
> outside the scope of what Sourceware does - those are criteria for 
> general-purpose hosting sites that anyone might add a package to).
 
The LF IT has agreed to implement hosting entirely with FOSS.

I agree completely with Joseph here that the repo criteria [1] are the relevant
criteria to apply in this case.

I'll reach out to LF IT to work through the repo criteria.

Likewise I will create documents to answer and cover some of Paul Eggert's questions.

-- 
Cheers,
Carlos.

[1] https://www.gnu.org/software/repo-criteria.en.html

Re: [Action Required] glibc decision to use CTI services.

[Carlos O'Donell]

On 9/27/23 09:50, Carlos O'Donell wrote:
> I agree completely with Joseph here that the repo criteria [1] are the relevant
> criteria to apply in this case.

We believe that we are satisfying all of the requirements that the FSF
and the GNU Project are requiring. Do you wish to raise any other FSF
or GNU Project requirements?

> I'll reach out to LF IT to work through the repo criteria.

The CTI TAC did an initial review with LF IT and our expectation is that
CTI services will meet B for "Good enough to recommend" if not better.

-- 
Cheers,
Carlos.

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

On Feb 12, 2024, "Carlos O'Donell" <carlos@redhat.com> wrote:

> On 9/27/23 09:50, Carlos O'Donell wrote:
>> I agree completely with Joseph here that the repo criteria [1] are the relevant
>> criteria to apply in this case.

> We believe that we are satisfying all of the requirements that the FSF
> and the GNU Project are requiring. Do you wish to raise any other FSF
> or GNU Project requirements?

I don't speak for the FSF or for GNU, and I'm not a party to any of the
agreements you may have made with them, but I'd be surprised if the
requirements were indeed satisfied.

Outsourcing an individual's or a group's computing is SaaSS even when
using Free Software, and SaaSS triggers basically the same obstacles to
users' freedom that nonfree software does, but in a way that makes users
even more helpless, so our movement rules out both SaaSS and nonfree
software.

From what I know of the FSF and of the GNU project, they surely wouldn't
be on board with that sort of outsourcing, and AFAICT that sort of
outsourcing is precisely what's being proposed, so I recommend you check
back with them.

When you do, I suspect you'll find that your belief arises out of some
sort of misunderstanding as to the requirements.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[DJ Delorie]

Alexandre Oliva <oliva@gnu.org> writes:
> Outsourcing an individual's or a group's computing is SaaSS even when
> using Free Software,

You just argued that we should all stop using sourceware.org or gnu.org.

I respect the SaaSS argument, but we have to draw the line somewhere or
we can't work together at all.  Trust has to be a factor.

Re: [Action Required] glibc decision to use CTI services.

[Mark Wielaard]

Hi,

On Mon, Feb 19, 2024 at 05:03:31PM -0500, DJ Delorie wrote:
> Alexandre Oliva <oliva@gnu.org> writes:
> > Outsourcing an individual's or a group's computing is SaaSS even when
> > using Free Software,
> 
> You just argued that we should all stop using sourceware.org or gnu.org.
> 
> I respect the SaaSS argument, but we have to draw the line somewhere or
> we can't work together at all.  Trust has to be a factor.

I do hope the glibc community trusts Sourceware.

The Sourceware Project Leadership Committee does have regular
discussions with the FSF and coordinates with the FSF tech-team around
shared services we provide to GNU projects like glibc.

Also we made sure that in our agreement with our fiscal sponsor, the
Software Freedom Conservancy, we put in writing that any
infrastructure software used is and will be published as Free
Software. See the Fiscal Sponsorship Agreement at
https://sourceware.org/mission.html#plc

If the glibc community has any concerns about the Sourceware
infrastructure and services, or simply would like to improve them,
then please do reach out:
https://sourceware.org/mission.html#organization

The Sourceware Project Leadership Committee also meets once a month to
discuss all community input, set priorities and decide how to spend
funds, etc.

Cheers,

Mark

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

On Feb 19, 2024, DJ Delorie <dj@redhat.com> wrote:

> Alexandre Oliva <oliva@gnu.org> writes:
>> Outsourcing an individual's or a group's computing is SaaSS even when
>> using Free Software,

> You just argued that we should all stop using sourceware.org or gnu.org.

Your response just confirms that there's some misunderstanding around
the notion of SaaSS.  You may be confusing it with SaSS.

The services that gnu.org and sourceware.org offer are publishing and
communication, that are not any one party's computing, and that
necessarily involve more than one party.  These are not SaaSS.
See "Distinguishing SaaSS from Other Network Services" on
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

You may also get a better understanding by reading "When the User Is a
Collective Activity Or an Organization" on the same web page.  It
applies to our case.

> I respect the SaaSS argument, but we have to draw the line somewhere or
> we can't work together at all.  Trust has to be a factor.

The line is drawn, it just needs to be understood and respected.

It has enabled us to work together for a long time.  Currently, we're
not outsourcing our computing, so there's no loss of software freedom,
regardless of whom we trust.

Trust may play a role when it comes to communication and publishing
services, and we have a reasonably trusted party we've all relied on for
a long time.  There's a push to move them to a third party that is not
uniformly better trusted, which is a problem in itself.

But the anathema IMHO is that the plans AFAICT involve outsourcing our
computing.  That would be crossing a line that nobody should cross, and
we, the Free Software movement, as the reference in this issue, must be
the change we wish to see in the world, not seek ways to compromise.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[Mark Wielaard]

Hi Alex,

On Wed, Aug 30, 2023 at 02:19:20PM -0300, Alexandre Oliva via Libc-alpha wrote:
> [adding libc-alpha, where GNU libc discussions are held]

Thanks. I am just a small contributor to glibc, but I do help out with
some of the infrastructure we use. So I am happy we are having this
discussion with all contributors.

I can only answer your concerns for the Sourceware project. I wasn't
included in this Linux Foundation CTI proposal.

> On Aug 29, 2023, "Carlos O'Donell" <carlos@redhat.com> wrote:
> > I propose the glibc project migrate to services provided by the 
> > Core Toolchain Infrastructure (CTI) project, particularly services
> > provided by the Linux Foundation IT team.
> 
> Nay.  I do not perceive any benefits to GNU's values in becoming
> technologically dependent on an organization that never shared GNU's
> values, that has constantly pretended GNU didn't exist, persistently
> claimed our work to itself, and promotes and operates under values that
> conflict deeply with those that GNU stands for.  It would amount to
> shooting itself in the paws.
> 
> I acknowledge that the present supplier of equivalent services also
> started in a hostile manner, but at this point it's the devil we know.

I assume you are referring to when egcs/sourceware were started. I
wasn't around then. But I note that these days we have a good working
relation with the FSF tech-team, Ian Kelling is one of the Sourceware
PLC members, and we talked through our plans to setup a non-profit
home for Sourceware as SFC member project with the FSF director, Zoë
Kooyman.

> The plan should IMHO be to mitigate that dependency, not introduce
> another or replace one with a worse one.

We also worked to diversify our hardware and services partners so we
are less reliant on just corporate sponsors.

See https://sourceware.org/sourceware-25-roadmap.html for the various
efforts.

> As I suggested back when this idea was first raised (and AFAICT there
> have been no attempts to dispute that this would be a better path to
> pursue), I'd be happy to accept this sort of contribution to GNU *iff*
> the services were *actively* *replicated* among two or three separate
> suppliers, so as to reduce the risk of dependency and of corrupting
> pressure on us.

I know this doesn't go far enough for you, but we have always provided
rsync services to make it easy to replicate the data needed for
various services. All the source code repositories are now actively
mirrored at the Software Heritage projects and the active git
repositories are also available at https://sr.ht/~sourceware/ With
public-inbox all public mailinglists are also easy to replicate and
access through various protocols.

For the main servers we do have "hot backups". Currently at the same
provider, but we are planning to have something similar at OSUOSL
and/or the FSF.
 
> Even then, this would IMHO be a move for GNU to decide, or at the very
> least be consulted on, according to its own values and priorities,
> something that all mantainers appointed by GNU, myself included,
> committed ourselves to observe, prioritize and uphold as maintainers of
> GNU packages.  I encourage other maintainers to justify their responses
> based on GNU's values and priorities, as they understand them.

For Sourceware we have the Sourceware Project Leadership committee
which includes various GNU Maintainers/Stewards. I hope the community
trusts them to uphold the values and priorities. You can find the
current members at https://sourceware.org/mission.html#plc which also
lists the legal agreements and conflict of interest policy.

Cheers,

Mark

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

On Aug 31, 2023, Mark Wielaard <mark@klomp.org> wrote:

>> I acknowledge that the present supplier of equivalent services also
>> started in a hostile manner, but at this point it's the devil we know.

> I assume you are referring to when egcs/sourceware were started.

Exactly.

> I note that these days we have a good working relation with the FSF
> tech-team, Ian Kelling is one of the Sourceware PLC members, and we
> talked through our plans to setup a non-profit home for Sourceware as
> SFC member project with the FSF director, Zoë Kooyman.

These are all desirable properties indeed, that are to the best of my
knowledge not valued by the other proposal, which by itself makes the
move less desirable than staying put.  But I don't conflate FSF and GNU,
those are separate entities, despite FSF's strong support for GNU, and I
express my position here strictly in my capacity of appointed GNU
co-maintainer.

> We also worked to diversify our hardware and services partners so we
> are less reliant on just corporate sponsors.

I don't see that GNU has a position of rejecting corporate support per
se, so that wouldn't be so much of an issue if it weren't for LF's long
history of disfavor to and attempted displacement of GNU.  These
concerns are reinforced by its corporate supporters' misalignment with
GNU's pursuit of software freedom for all users.

Freedom and autonomy are not something we generally expect others to
give us; they're something we need to constantly pursue and struggle
for.  Per my calculations, even if the proposed move were to bring us
any technical advantages, it would still be a risky proposition, but my
reading of the situation is that it's no more than an attempt of a
hostile take-over, in which the main factor driving others' preference
for the candidate supplier of hosting services over the present one is
ideological distance from GNU, rather than alignment with it.  I'd love
to be proven wrong in this reading, but I don't expect that.

There haven't been any arguments about what LF could offer through
strictly FS that SW couldn't or wouldn't, and anyone who understands
enough of FS, particularly that used for hosting services, should be
able to tell why there haven't been any such arguments: anything that
either can do with FS, so can the other.  It's no more than an exercise
of seeking excuses to push other agendas through.  I'd much rather we
were honest and debated those motivations instead.

> I know this doesn't go far enough for you, but we have always provided
> rsync services to make it easy to replicate the data needed for
> various services.

*nod*, that is desirable, but it would still be quite disruptive if any
service provider were to pull any such plugs, or use the influence
gained through these possibilities to advance detrimental agendas, even
if only temporarily.  Why take that risk?  Why centralize control,
especially in hostile hands, if there are means to retain our autonomy?
Why follow practices designed to take control away from users if we can
be leading examples of how to retain our autonomy without making room
for subjugation through control over SaaSS, that is even worse than
proprietary software even when implemented through Free Software?

LF has clearly been, erhm, hesitant to grant the community access to the
servers that host services for the community.  That, to me, makes most
services SaaSS, a practice that self-respecting communities shouldn't
adopt.  Being locked out of one's own servers is giving up control over
the community's computing, and that's exactly the core value of the Free
Software movement that is at risk here.

> For Sourceware we have the Sourceware Project Leadership committee
> which includes various GNU Maintainers/Stewards. I hope the community
> trusts them to uphold the values and priorities.

I'd like to, but I find it hard to find reason to be confident in that.
The notion of outsourcing the hosting of community services seems to
have become so prevalent and ingrained that most people don't appear to
realize the extent to which it becomes SaaSS when the community ends up
excluded from control over the hosting services, and how that loss of
control over one's individual and collective computing is exactly what
our movement has stood against since its inception.

Sharing the hosting of such services between multiple entities external
to a community does nothing to address this problem, even if it
mitigates other concerns about potential disruptions.  For the kind of
services that amount to a community's computing, only by involving
active members of the community in the hosting services for the
community can we avoid making the community a victim of SaaSS.  Enabling
some chosen community members to beg for a third-party hosting service
provider to do their bidding does not seem enough to me to avoid
betraying the core value of our movement.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[Florian Weimer]

* Alexandre Oliva via Libc-alpha:

> Even then, this would IMHO be a move for GNU to decide, or at the very
> least be consulted on, according to its own values and priorities,
> something that all mantainers appointed by GNU, myself included,
> committed ourselves to observe, prioritize and uphold as maintainers of
> GNU packages.  I encourage other maintainers to justify their responses
> based on GNU's values and priorities, as they understand them.

I'm not sure why “GNU” should have a say in this (whatever this is, you
do not quote enough context).  How would that even work?  I think we
don't have consensus what GNU's current decision-making structure looks
like.

I'm also puzzled why this was sent to the glibc stewards.  The main task
of this group these days seems to be to forward submissions to the
stewards to libc-alpha.  That doesn't seem to be very useful.

Thanks,
Florian

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

On Aug 31, 2023, Florian Weimer <fweimer@redhat.com> wrote:

> I'm not sure why “GNU” should have a say in this

GNU libc is part of the GNU Project.  GNU libc appointed maintainers
have formally accepted responsibilities to operate in line with the
project in our capacity as GNU maintainers.

We're being called to make a decision, as GNU maintainers, that pretty
much alienates from GNU the package entrusted to us.

Any legitimate decision-making powers we maintainers have over GNU libc,
it was delegated to us by GNU, conditioned on our observance of these
responsibilities.  We're expected to make sure that contributions that
are accepted advance the project's goals, and to ask for guidance when
there's uncertainty.

How could one possibly imagine that GNU should *not* have a say on it?

> How would that even work?

Ask some GNU-appointed maintainer you trust who hasn't gone rogue, they
should be able to convey that answer to you in a way you wouldn't doubt
as much as if it came from me.

> I think we don't have consensus what GNU's current decision-making
> structure looks like.

I realize there are people who'd like the GNU leadership structure to be
different from what it is, but that's at the peril of delegitimizing
their own roles appointed through the existing structure.

Anyhow, GNU mission and structure are not matters for consensus among
whoever wishes to share their opinions: those who agree to volunteer to
a cause don't get to redefine the cause, and making it so that they did
would make the cause too vulnerable to dilution and occupation.  Even
majority votes among the general population are a poor choice for
promoting social change: it captures where most of the population *is*,
which is by definition the opposite of social *change*.

GNU mission and structure are what they have been since long before any
of us started contributing to it.  They were designed to be reasonably
robust against hostile takeover, power grabs and attempts to dilute
GNU's goals or otherwise turn GNU into something else, while enabling
GNU to accept contributions from people and organizations who don't
share its values and goals.

Historically, most contributors haven't shared our values or goals, and
enabling them to reset our course would have been the surest way to get
none of the social change we hope to achieve.  Instead of striving for
an overall average likely influenced by extraneous interests, we're
better served by the strongest commitment to the cause, to the goals, to
the values, and the deepest understanding of the challenges we face.

That diversity of values, alignments, motivations and opinions among
potentially-misaligned contributors also makes room for some tension
when people and organizations attempt to project or even impose by force
onto GNU their own extraneous stances, without regard for the
decision-making structure, for why it is as it is, or for what we're up
for, up against, or up to.

These tensions are sometimes hard to navigate, but they strike an IMHO
ideal balance between accepting contributions from anyone willing to
contribute to the cause, and rejecting changes that would be detrimental
to the cause.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back