Re: Removal of support for GCC hosted on UWIN

[cgd@netbsd.org (Chris G. Demetriou)]

[ i've cc'd RMS since you suggested that we ask the FSF about this and
he's probably the right person. ]

mark@codesourcery.com (Mark Mitchell) writes:
> The FSF owns the rights to the code, and so the FSF can make decisions
> like this without consulting anybody.  (Of course, the GPL itself
> gives everyone certain rights with respect to the code that would be
> hard for the FSF to revoke.)

The FSF can make decisions like this without consulting anybody,
certainly.  And the steering committee, as an instrument (to some
degree) of the FSF is responsible for carrying out the FSF's wishes.

I don't think anybody -- except U/WIN users and people who time and
effort into the U/WIN code -- is going to care overly much about the
fate of U/WIN support.  It's the process and reasoning for making the
decision to remove U/WIN support that's concerning.

GCC is a technical project, but it's been used for what amount to
political purposes in the past.  It's the perogative of the owner of
the source to decide what is to be included, and what is not, and if
that is done for political ends, so be it.

However, the developers who are contributing code to gcc have a right
to know what positions their code is being used as a 'lever' to
advocate.  Not a legal right, certainly (at least, I didn't see
anything in the assignment form that promised that 8-), but I'd say a
moral one.

Therefore, in my opinion, not telling contributors is unfair to them,
and, as far as I'm concerned, also casts doubt on the motives of the
SC and the FSF for demanding that the source be changed for no given
reason.


By the way, I don't see anything on the GCC mission statement that
says that when the FSF or RMS says "jump," the GCC project (as steered
by the steering committee) has to say "how high."  Certainly there's
some motivation for that, but if the demand is to make a change which
is not technically sound, there should, in my opinion, be pushback.
(I don't see how a change which, for no documented reason removes
support for a platform, to the detriment of that platform's users and
creating extra work for developers can be considered "sound."
Reasoning is needed.)

I do, on the other hand, see things like:

	* Supporting the goals of the GNU project, as defined by the FSF.

The way I read that, if changes are being made to support those goals,
both those goals and the reason for the changes should be enunciated.
Otherwise, you can get into the situation where the FSF has the
ability to effectively 'black-list' companies or groups, without the
public even having any real notion that it's happening.


I've not seen any justification for removing the U/WIN support here
other than the flawed (AFAICT) logic in the original message you sent
(since it discounted the notion of u/win users building their own
binaries which from commentary by others seems a reasonable
proposition) and the appeal to authority ("ask the FSF").

I can imagine a whole host of reasons why the FSF would make the
request, pretty much all of which are reasonable as long as they are
honest.

However, not providing a reason at all seems quite unreasonable.


The consequences of not providing justification in this case seem
relatively minor, but the precedent is a bit unsettling.  All it can
do is lead to distrust within, and fragmentation of, the user
community.



cgd
--
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD or my employer, just expressing my
own opinion.