No Gnus is good Gnus

[Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU]

Well, I wondered how long it would be until we heard from RMS.  Just about
24 hours, as it turns out.  Here is his message and my reply.  BTW, if
anyone within the group thinks seriously that we should be doing something
other than public-domain, I would be happy to discuss this.  It's hard to
discuss such things rationally with RMS, as he get a bit too passionate
about big evil companies.

-- Scott
===========================================================================
Date: Sun, 20 Oct 91 15:05:16 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
To: scott.fahlman@cs.cmu.edu
Subject: CMU Lisp

I hear that CMU Lisp has been released, and from the little I have
heard it seems like a good job.

However, I hear that it is in the public domain.  This suggests you
will have a problem with computer companies writing ports and not
giving them to you.  They might fix bugs and never tell you, and you
would not be able to find out from their users either.  Both of these
problems happen frequently with X-Windows and Berkeley Unix.

I would like to discuss with you the possibility you could apply some
version of the GPL, or some other set of terms requiring improvements
to be free, to the next version of CMU Lisp.  Can we discuss this?  If
you have considered and dismissed the idea, could you tell me your
reason?  Perhaps there is a way to design the terms so as to solve
whatever problem concerns you while still having the beneficial
effect.

===========================================================================
To: rms@GNU.AI.MIT.EDU (Richard Stallman)
Subject: Re: CMU Lisp 
Date: Sun, 20 Oct 91 17:54:23 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


Yes, the latest CMU Common Lisp system is public domain, like all previous
releases dating back to 1984 or so.  We decided on this course a long time
ago, long before people began using a "copyleft" to prevent the kinds of
problems you mention.  In fact, I seem to remember that you helped to
persuade me to go the public-domain route back when we were starting this
effort and were thinking about some sort of not-entirely-free licensing.

We've thought about switching to some sort of "copyleft" scheme at various
times (e.g. when the Python compiler, a big new chunk of code came out),
but always the hassles of trying to control our code that way seemed to
outweigh the potential problems.  After all these years, CMU still is
reluctant to provide us with regular access to legal advice, and that does
make public-domain look more attractive.  I get mildly upset when someone
uses our code without acknowledgment, but I'm not at all interested in
suing anyone over this issue.

Also, I'm not sure it's a bad thing to allow companies to build solid,
supported commercial releases on top of our code, since we don't want to
get into the support business ourselves.  I think this mode of operation
helped to get a lot of companies to join the Common Lisp bandwagon in the
early days.  I think that having to deal with a copyleft might have scared
many of these companies into trying to do proprietary versions in-house,
and a *lot* of them would have failed.

In practice, we've had no problems finding out about bug fixes.  Most
companies are quite eager to cooperate with us -- they need the help -- so
we have a certain amount of leverage without actually having to deal with
lawyers and the associated problems with DARPA.  We have had a couple of
problems with companies developing proprietary ports with our assistance
(paying us as consultants on the effort) and then suppressing the result.
Those were just bad deals we made, and now we know enough to insist that
the port becomes public domain if the company doesn't release it.

If we were starting today, we might well go with something very much
like the Gnu agreement, but it's too late now in any case.  Python has been
public-domain for over a year -- the only new element is the little bit of
code for the SunOS operating system that makes the code useful to a much
wider community.  The next substantial chunk of code we produce will
probably be our native CLOS, and that is at least 9 months in the future.
We'll think again about what to do when that is ready.

Regards,
Scott