autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal to fork the build-tools projects


From: Tom Lord
Subject: Re: proposal to fork the build-tools projects
Date: Tue, 22 Oct 2002 13:31:51 -0700 (PDT)


       > I just don't see it.  Unfortunately I can't afford to spend
       > time thinking about it.  There is too much else that I have
       > to do.

The GNU coding standards, and by extension the configure/build tools,
have a very large role in keeping GNU systems coherent and keeping it
practical for individuals to work with their source.  They also have a
sinister role (when they work poorly) of enabling vendor lock-in among
free software vendors.  If the effort to implement good standards
fails, the outcome is commercialized "free software" systems that
exhibit vendor lock-in and for which individual users are not, as a
practical matter, enabled to make any significant use of the source
themselves.  In other words, it is free software with few or none of
the benefits of sharing source.


       > If Autoconf developers start saying they think this will make
       > their work easier, that is something I will listen to.

But exactly what is "their work" in this case?

In the most negative light (i.e., painting the worst interpretation --
not making an accusation), the FSF looks like a pass-through, vetting
whatever the maintainers want to do (for whatever reason), asserting
the outcome as a GNU standard.  This is especially problematic when
the maintainers are working on infrastructure that's critical to their
employers; considering a proposal that is contradictory to their
employers' business plans and proprietary software; and, it is not
far-fetched to infer, gaining some standing with their employer by
virtue of their maintainership.  Is objective evaluation possible
under those circumstances?  Is it likely to occur?  How surprising
will it be if, when decision makers have those kinds of contraints,
they make decisions that impede free software progress but favor the
progress of companies making money from free software?  It doesn't
even require explicit or self-conscious malevolence for this kind of
decision making to raise conflicts of interest -- it's a structural
problem, arising out of an unbalanced weighting of some valid
perspectives to the exclusion of other valid perspectives.

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]