From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id D894C3858D20 for ; Fri, 1 Sep 2023 17:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D894C3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from linux-libre.fsfla.org ([2001:470:142:5::54] helo=free.home) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc7kC-00065F-PM; Fri, 01 Sep 2023 13:15:41 -0400 Received: from libre (libre.home [172.31.160.3]) by free.home (8.15.2/8.15.2) with ESMTPS id 381F8r1v005688 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 1 Sep 2023 12:08:55 -0300 From: Alexandre Oliva To: Mark Wielaard Cc: Jakub Jelinek , libc-alpha , Andreas Schwab , Joseph Myers , Maxim Kuvyrkov Subject: Re: [Action Required] glibc decision to use CTI services. Organization: Free thinker, not speaking for the GNU Project References: <20230831083749.GA12940@gnu.wildebeest.org> Errors-To: aoliva@lxoliva.fsfla.org Date: Fri, 01 Sep 2023 12:08:53 -0300 In-Reply-To: <20230831083749.GA12940@gnu.wildebeest.org> (Mark Wielaard's message of "Thu, 31 Aug 2023 10:37:49 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Aug 31, 2023, Mark Wielaard 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=C3=AB 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. --=20 Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lx= o/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice b= ut very few check the facts. Think Assange & Stallman. The empires strike ba= ck