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 46F54385702C; Sun, 23 Oct 2022 21:19:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46F54385702C 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 ([209.51.188.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 1omiNm-0000cx-Px; Sun, 23 Oct 2022 17:19:49 -0400 Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 29NLJXFZ044822 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 23 Oct 2022 18:19:35 -0300 From: Alexandre Oliva To: "Carlos O'Donell" Cc: overseers@sourceware.org, gcc@gcc.gnu.org, libc-alpha@sourceware.org, gdb@sourceware.org, binutils@sourceware.org Subject: Re: Toolchain Infrastructure project statement of support Organization: Free thinker, not speaking for the GNU Project References: <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> Errors-To: aoliva@lxoliva.fsfla.org Date: Sun, 23 Oct 2022 18:19:33 -0300 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,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 Oct 12, 2022, "Carlos O'Donell via Overseers" wrote: > The GNU Toolchain project leadership Is GNU Toolchain the name of a project? This term has usually meant a set of packages that are part of the GNU Project. Each package has its own set of maintainers appointed by GNU leadership, each one with a commitment to advance the goals of the GNU Project through their maintainership. GNU Project leadership hasn't been consulted, and the proposed move appears to be detrimental to the GNU Project, so it follows that these people are not acting in their capacity of GNU maintainers. As such, any kind of leadership and decision-making arising from these roles must be presumed void and null. Speaking specifically of the GCC Steering Committee, I quote from the very first sentence in https://gcc.gnu.org/steering.html The steering committee was founded in 1998 with the intent of *preventing* *any* particular individual, group or *organization* from *getting* *control* *over* *the* *project*. (highlights are mine) Turning over control over critical project infrastructure, in a way that seemingly places the packages under the umbrella of that single organization, is not in line with the existential reason of the GCC Steering Committee. As such, it must follow that the undersigners are not acting in their capacity of GCC Steering Committee members, which removes any decision-making weight that might have otherwise been presumed from them, due to expectations associated with these roles. That said, I acknowledge that several of them are prominent contributors to GCC, and the GNU Project is happy to welcome contributions from anyone willing to help advance its goals (please do not mistake this as speaking on behalf of the GNU project; I merely state GNU policies and positions to the extend that I'm familiar with and understand them). Several others were relevant developers, as I and RMS have been for quite some time in GNU libc and GCC, respectively. It's interesting to see that past contributors can have a voice, but it appears to me that there has been some bias in the selection of which past voices to actively seek out, and which to dismiss, that places the legitimacy of the pronouncement under further doubt. Anyhow, FWIW, I hereby raise my objection to the proposed outright move of our infrastructure out of Sourceware and into LF. I have a different proposal that is more in line with GNU policies, that GNU maintainers ought to uphold, and with the stated goals of the GCC SC quoted above. I wish to be clear on GNU policy of welcoming contributions that help advance its goals. I, as contributor to the affected packages, and as long-time GNU contributor, do not wish GNU to turn down the resources offered as part of this proposal, any more than I wish GNU to turn down the resources that have long been made available to us by Sourceware. There are significant upsides to using both, to increase our autonomy, rather than jumping from one single point of corporate dependence (AKA autonomy failure :-) to another. It seems fine to me, and also welcome, that groups of contributors pool their individual efforts towards finding resources for the GNU packages they wish to support. I have no objection in principle to our relying on these resources, be they financial or infrastructure, to advance our projects, even if the governance model of each supporting group is independent from and unrelated to the governance structure of GNU. After all, we have no say in Red Hat's internal governance structure and funding of Sourceware, and that hasn't stopped and IMHO shouldn't stop us from accepting that contribution either. So it shouldn't stop us from accepting contributions from the LF, even if we have no say in its governance structure or in the composition of the governing board of the organization or of the brands and subgroups that would affect directly their offer to our packages. As long as the offered resources advance our goals, they are welcome. I don't see that an outright move does, but I do see that increased autonomy and robustness through replication would. Should any such supporting group at any point in the future take actions that conflict with our goal, the GNU Project may then turn them down, and then, as long as critical project infrastructure doesn't make us hostage, we will be no worse off than if the contributions had never been offered in the first place, and presumably even a little ahead because of already-accepted past contributions. It seems very important, however, that we take steps to guard our own autonomy, so as to avoid the risks of finding ourselves in such a hostage situation or of being strongarmed into behaviors we'd not engage in out of our own volition, and even of having our governance structures confused, subverted or replaced by misperceptions about the nature of these supporting structures. To this end, it appears to me that the reliance on multiple supporting groups, each with their own independent governance structures, is a strength we should embrace, by keeping critical package resources replicated across multiple such groups, instead of placing all eggs in a single basket. I urge responsible maintainers of all encompassed projects to take this possibility into account, and also, while planning a transition hopefully into a multi-party infrastructure arrangements, to see what another organization that has long supported the GNU Project, namely the FSF, has to offer, and rely on its resources as well. I'd also encourage people involved in this initiative to look into directing part of the raised funds towards paying *other* organizations for infrastructure services, in addition to the LF itself. I expect the FSF could and would welcome this, and, just as there are contributors and users who trust the LF better than the FSF, there are others who trust the FSF better than the LF, and having trustworthy parties involved in offering replicated/redundant infrastructure would likely make everyone more comfortable. I'd perceive this decentralization as yet another positive development towards increasing our autonomy and robustness towards preventing any particular individual, group or organization from getting control over the project. Accepting multiple such contributions, we also preemptively dispell any potential assumptions that the GNU packages themselves, or their governance structures, are in any way under the authority of the governance structures of any of the infrastructure suppliers or funding channels. Please find a few other points below. > We believe that utilizing the experience and infrastructure of the LF IT team > that already is used by the Linux kernel community will provide the most > effective solution and best experience for the GNU Toolchain developer > community. I'm curious as to any facts that support this statement. Without risk-cost-benefit analyses of the actual offer, and comparison with at least a few alternatives, it feels more like an expression of enchantment for promises made by a politician during an electoral run than anything one could count on. Gratis offers are often bait-and-switch or other kinds of traps, so caution is advisable when accepting them. Considering that, in the end, the decisions wouldn't even be made by the proponents themselves, it doesn't smell good to me. But then, again, unless we're silly enough as to jump in without safety jackets, or we are dragged in by force, I have no objections to accepting contributions from this supporting group on a tentative basis. That means, at least at first, replicating rather than moving; rolling out new services (with viable plans to replicate them) rather than replacing existing ones. So far, there's no clarity to me as to the proposed plans of moving services and how this would impact or benefit us, which makes it impossible to have any rational grounds for any decision whatsoever. I look forward to tomorrow's presentation about expected benefits, so that we can reason about them and see how to retain them in the multi-party infrastructure scenario I propose. It doesn't smell good, however, that Sourceware has been prevented from presenting its own expansion plans and proposals at the Cauldron. I wish it too gets a chance to extend their offer. There's no basis for a rational decision in refusing to listen to alternatives; it comes across to me as acknowledgment that a weaker proposal wishes to prevail by denying others any consideration. > As with kernel.org, GTI has requested from the Linux Foundation IT that all > software implementing the infrastructure for the GNU Toolchain projects must > be Free Software. That is nice. What has LF IT responded? AFAICT, it doesn't look like they took it to heart. So far, not even the infrastructure for meetings has been based on Free Software, and that's not a very hopeful sign. Still, it's worth keeping in mind that, when it comes to infrastructure offered by third parties, the use of Free Software benefits the infrastructure providers, but as for the freedom of users of that infrastructure, both as people and as packages or projects, the arrangement is a Service as a Software Substitute, SaaSS, which is in most freedom-related aspects even worse than nonfree software. https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html Outsourcing key infrastructure (as opposed to relying on community members to maintain it) creates a detrimental power dynamic, that requires working harder to maintain a group's autonomy. Relying exclusively on Free Software alleviates some of the extra difficulties, but because of the SaaSS dynamics, it does not solve them entirely. Thus my recommendation to pursue multiple redundant infrastructure providers, for the sake of our autonomy. > If Free Software versions of necessary security tools are missing, GTI > will work with Free Software supporters to develop Free Software > alternatives. There are no "necessary security tools" for GNU that are nonfree, but an implication of this phrasing is that, if any are found or framed as such, they'd end up being used, because of "necessary", until an alternative is developed and readied for use. Still worrysome is that OpenSSF policies disfavor strong copyleft, so even if such tools end up being developed and released as Free Software, GNU might find itself relying on non-copyleft, push-over licenses. While these are not unethical, associating ourselves with an organization that has an anti-copyleft bias raises quite some red flags for me. Could your supporting infrastructure initiative negotiate some arrangement with the OpenSSF so that any "necessary security tools" developed in responses to our needs (even if addressing others' needs as well) be released under strong copyleft, such as GNU GPLv3+? Could they be contributed to the GNU Project? Thanks for listening, -- 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. Ask me about