Subject: Re: Exploring the limits of free software: Cygnus, and GPL
From: Ian Lance Taylor <>
Date: 26 May 1999 01:35:50 -0400

   From: "Stephen J. Turnbull" <>
   Content-Type: text/plain; charset=us-ascii

   >>>>> "Ian" == Ian Lance Taylor <> writes:

       Ian> I'll note that I don't think the free software community has
       Ian> yet shown itself to be very good at creating new standards,
       Ian> in the sense of clearly documented interfaces which other
       Ian> people can write code to.  Free software standards, such as
       Ian> they are, tend to be defined by an implementation rather than
       Ian> a specification.

   No free software people writing RFCs?

I don't actually know.  Are they?

There are DNS RFCs which I believe are essentially being funded by the
ISC.  I consider that to be more of an exception than the rule,

   Linux's FSSTND and the more general FHS?

Warmed over SVID.  They are also rather imprecise, and use qualifiers
like ``without good reason.''  But perhaps I am being too picky.

   The Debian and RedHat package managers?  Do a "ls | wc" on the
   contrib/ directory at  Even really bad programmers can 
   write to that interface!  %-P

It's defined by an implementation.

   What's CGI?

I could quibble, but I'll give you that one.

   Did you see Cox's comment about adding the whole IrDA interface at the
   Linux 2.2-pre4 (or so) stage?  It went something like "you may be
   wondering why I approved addition of an entire subsystem during an
   alleged `feature freeze'.  Well, the impact of this contribution on
   _all_ of the other code was three lines, two of which were `#ifdef
   IRDA' and `#endif'".  If that's not "in the sense of clearly
   documented interfaces which other people can write code to," what is?
   Sure, it doesn't make the port of the IrDA code to *BSD easier, but is
   that really a show-stopper?

The interface you describe is defined by an implementation.  A proper
standard lets me write either side of it.

   Why do our standards have to be mutually exclusive with proprietary
   ones (POSIX, Postscript)?  Little contribution to Postscript, I
   suppose, but surely the folks at Cygnus and many free software
   contributors with relevant day jobs have made important contributions
   to POSIX.

Actually, I doubt Cygnus folks have made many contributions to POSIX,
but some folks now at BSDI may have.  The name POSIX itself is of
course due to RMS.  There has been free software input into the ISO C
and C++ standardization efforts.

These standardization efforts are expensive to participate in, and are
not Internet driven as free software tends to be.  I think pounding
the standards into final form in particular is driven by proprietary
interests.  But perhaps I am being overly critical.

   Perl (the language, cf. Wall interview in recent Linux J), Python?
   Perl is a classic example of "implementation-defined" but a lot of its
   evolution has been according to classic patterns of standard setting.
   Note that in open source, it's likely that this kind of endogenous
   standard-setting will be very effective, although impossible to
   disentangle from implementation evolution.  Unless there are severe
   technical differences (like those that still plague Emacs and XEmacs),
   how would you ever know the difference?  Python is clearly a
   "designed" language.

I know the difference because I can't take the Perl documentation and
use it to write Perl itself.  I might get fairly close, but basically
Perl documentation is not a technical standard.  At some point I will
have to run Perl and see what it does.  People even talk about Perl
programs as ``works with perl 5.003;'' there seems to be some sort of
standardization failure going on there.

   I'm missing your point, I'm sure.  Please expand.

I program based on standards.  I keep the POSIX standards on my desk
and refer to them regularly.  I have the useful RFCs on my local disk,
and read them when I need to understand an interface.

Sometimes I want to use some feature invented by the free software
community, such as extended inline assembler or Linux packet driver
sockets or parsing debugging information generated by gcc.  These are
things which are best used with documentation along the lines of a
standard, such that I can write to a clearly and completely specified
interface without needing to examine the implementation which I know
will change in the future.

These are the sorts of standards which I do not see the free software
community writing.  I don't think it's impossible by any means, but,
as I said, I don't think the free software community has yet shown
itself to be good at this sort of thing.

   But mine is simply
   that what free software currently is mostly good at (unkindly called
   "taillight chasing") means that free software is unlikely to have
   standard specification as a fundamental design process; rather, free
   software developers are more likely to have effect on externally
   maintained standards than to write them themselves.  Those standards
   that they do write are likely to be "little standards" written for a
   given implementation's internal purposes.  But implementations with
   better "little standards" do better in the marketplace of ideas, I
   should think.  Data?  Anecdotes?

Probably.  But little standards, as you say, aren't especially helpful
if I'm not one of the internal developers, but I need to use the
interface anyhow.