Subject: Re: Free software (was Re: Where's your Lisp software, Janos Blazi?)
From: Erik Naggum <erik@naggum.net>
Date: Sat, 08 Sep 2001 09:52:53 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3208931568084195@naggum.net>

* jacobian@pacbell.net (Gavin E. Mendel-Gleason)
> I do feel I have the right to be demand this as a consumer of products.

  Do you also feel you have the right to get the source material for movies
  you see?  Actors learn to act based on published plays, which is source
  code for the stage performance, and playwrights learn to write new ones
  based on how old ones were written.  This is undoubtedly useful within
  the profession, but as a _consumer_?  The Free Software movement is also
  directed towards developers, not consumers.  My interest and investment
  in Free Software has been to advance education.  My acquisition editor at
  Prentice Hall told me that good authors have read at least 1000 times
  more than he publishes, and that the actual published book is often no
  more than a fifth of the volume of the text that has been written on it.

> I feel I have this right in the same way that I feel I have the right to
> demand that I be able to purchase a car that has good gas mileage.

  But do you demand the schematics and engineering documentation on the car?

> While not releasing the source may avoid this issue entirely, it is a
> rather extreme solution.  In lisp it would be easy to have the convention
> that packages would designate the boundaries based on what is an external
> and what is an internal symbol.

  Or you could publish the source code for exported packages.  Allegro CL
  comes with (well, you have to sign a license and send it in, but it is
  cost-free) sources to the Common Lisp package.  You can actually get a
  lot of customizations in there, and it does not change much from release
  to release, either.

> Emacs has managed to give away its source and support massive
> extensibility and it has not collapsed under the weight of backward
> compatibility.

  That is not _quite_ true.  For those of us who have worked on Emacs for a
  good number of years, the inability to separate internal from external
  symbols and functionality has always been a source of problems.  Users
  depend on bugs, implementation quirks, and information they should not
  have needed and whent they get it, could only misuse.  Most of my gripes
  with Emacs come from its lack of commitment to a specification -- that
  is, people add stuff all the time without consideration for a planned
  design, and backward compatibility problems set in as soon as it has been
  released: reversing a bad design decision in Emacs is nigh impossible.

> Open source may not be the only model that gives extensibility though.
> It is simply the most obvious, especially when coming from a
> *nix/c/windows world.

  This is odd to hear.  The Unix world has had scripting languages forever,
  and those are essentially "half-open source": You get source access to
  all the scripts, and you can extend the system freely with scripts that
  tie well into the functions-on-disk (executables) that are designed to be
  building blocks.  Unix has taught users to expect parts of their system
  to be _in_ source form.  Take Perl (please! :), which excellently shows
  this point.  Few people venture into the Perl sources itself, but lots of
  people deal with other people's Perl code.

> It may be that an appropriate solution to the overly static nature of
> applications is to make them programming languages themselves.  Lisp of
> course is well suited to deliver in this area.

  Precisely, and that is why I think Open Source in the Common Lisp world
  is a very different beast from what it has to mean in th Closed Source
  world.  In effect, Common Lisp is already half-open by virtue of its
  retention of source-level information in the compiled system.

///