Re: Toolchain Infrastructure project statement of support

[Alexandre Oliva <oliva@gnu.org>]

On Oct 12, 2022, "Carlos O'Donell via Overseers" <overseers@sourceware.org> 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 <https://stallmansupport.org>