public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@gnu.org>
To: Mark Wielaard <mark@klomp.org>
Cc: Jakub Jelinek <jakub@redhat.com>,
	libc-alpha <libc-alpha@sourceware.org>,
	Andreas Schwab <schwab@suse.de>,
	Joseph Myers <joseph@codesourcery.com>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Subject: Re: [Action Required] glibc decision to use CTI services.
Date: Fri, 01 Sep 2023 12:08:53 -0300	[thread overview]
Message-ID: <orbkemhqwq.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <20230831083749.GA12940@gnu.wildebeest.org> (Mark Wielaard's message of "Thu, 31 Aug 2023 10:37:49 +0200")

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

  reply	other threads:[~2023-09-01 17:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b84ea4a5-651a-1a4c-06c8-e9ade4b7d702@redhat.com>
2023-08-30 17:19 ` Alexandre Oliva
2023-08-30 17:31   ` Joseph Myers
2023-08-31 19:59     ` Paul Eggert
2023-09-01  6:03       ` Sam James
2023-09-01  8:55         ` Florian Weimer
2023-09-01  9:02           ` Sam James
2023-09-01  9:21             ` dmarc, dkim and From rewriting Mark Wielaard
2023-09-01 11:52               ` Florian Weimer
2023-09-01  9:03           ` [Action Required] glibc decision to use CTI services Andrew Pinski
2023-09-01 11:49             ` Florian Weimer
2023-09-01 13:32           ` Frank Ch. Eigler
2023-09-01 12:30         ` Siddhesh Poyarekar
2023-09-01 14:54           ` Paul Eggert
2023-09-01 16:08             ` Siddhesh Poyarekar
2023-09-01 15:01           ` Sam James
2023-09-01 16:19             ` Frank Ch. Eigler
2023-09-01 16:30             ` Siddhesh Poyarekar
2023-09-02 18:25             ` Mark Wielaard
2023-09-01  9:08       ` Mark Wielaard
2023-09-03  6:31       ` Alexandre Oliva
2023-09-27 13:49       ` Carlos O'Donell
2023-10-04  0:09         ` Paul Eggert
2023-09-01 15:09     ` Alexandre Oliva
2023-09-27 13:50     ` Carlos O'Donell
2024-02-13  0:43       ` Carlos O'Donell
2024-02-19 21:22         ` Alexandre Oliva
2024-02-19 22:03           ` DJ Delorie
2024-02-20  1:49             ` Mark Wielaard
2024-02-20  3:01             ` Alexandre Oliva
2023-08-31  8:37   ` Mark Wielaard
2023-09-01 15:08     ` Alexandre Oliva [this message]
2023-08-31 10:34   ` Florian Weimer
2023-09-04  6:09     ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orbkemhqwq.fsf@lxoliva.fsfla.org \
    --to=oliva@gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=mark@klomp.org \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).