Re: [Gcl-devel] Re: Re: GCL compliance and Bill Schelter

[Adam Warner]

Hi Camm Maguire,

> Greetings!
> 
> Adam Warner <address@hidden> writes:
> 
>> On Fri, 2003-07-25 at 09:24, Camm Maguire wrote:
>> > Greetings, gentle people!
>> > 
>> > I must confess that I don't even have time now to adequately ponder
>> > the flurry of latest emails.  I'd like to make the following points,
>> > which I hope will calm and clarify.
>> 
>> ...
>> 
>> > 4) The basic confusion surrounding this discussion stems from a
>> >    misunderstanding, IMHO, of how GCL (or lisp in general) works
>> >    technically.  Tim basically hit the nail on the head.  I will try
>> >    to summarize separately in a note to RMS, but the basic idea is
>> >    that unlike in C programming, lisp executables have the entire
>> >    compiler, linker, and image saver -- basically all of GCL -- in
>> >    the executable itself.  I'm still not sure to what extent this is
>> >    as a result of an early GCL design decision, or to what extent it
>> >    is mandated by the Common Lisp standard.
>> 
>> Camm, having the entire compiler is necessary for the full power of
>> Lisp to be available at runtime.
>> 
>> 
> I take it this means also the ability to link in binary object modules
> into the running image.  Does it also mean the ability to dump the
> memory image to a file?

No. I believe this is no more than nice functionality not covered by the
ANSI Common Lisp specification. You raised three issues: "the entire
compiler, linker, and image saver". I believe only one is necessary for a
conforming Lisp implementation: the compiler being available at runtime,
in whatever form or forms it is available at what would typically be
considered compile time in a static language (that is, even though what
the complier does is implementation dependent it should work consistently
within the implementation. Perhaps this interpretation is still too
demanding. Someone like Kent M Pitman would be a good person to ask). This
does imply one should be able to LOAD source or compiled code and use
COMPILE-FILE at any defined time. For GCL this may imply having "the
ability to link in binary object modules." For CLISP it merely means being
able to load or compile source code or byte code.

We're probably only having this discussion because you've been using GPLed
code to dump memory images. As you reminded me a main issue is libbfd. I
find this is a GPLed utility which is part of GNU binutils.

So long as you have a way of building GCL from source and the GPLed code
is not needed to use COMPILE-FILE it would seem that you could remove it.
I shudder at the technicalities but perhaps some of CMUCL or SBCL's public
domain/BSD-licensed code (without advertising clause) could be used to
eventually reimplement the dumping of arbitrary memory images.

By the way (and I understand Stallman made this point earlier) it is not
sufficient for you simply shift to the GPL with an exception. You could
only do that if you were the copyright holder of all the GPL code you were
using. Then you could grant whatever exceptions you felt like. In the
absence of this you either move to the GPL WITHOUT exception or ask the
copyright holders to grant you an exception.

The Common Lisp community generally understands the implications of
placing a CL implementation under the GPL without exception (it's likely
that any user code must be GPLed if distributed) and it is clear few would
use such an implementation or distribute their code compiled for such an
implementation.

In the absence of the FSF granting you a sufficiently broad exception to
the GPLed code you are presently using (and then shifting GCL to a
GPL+exception licence) you have compelling reasons to remove your
dependence upon the GPLed code.

Good luck,
Adam