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

[Adam Warner]

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.

>   In any case, there is a
>    *long* history of GCL usage in this mode, which it would be
>    completely unfair to suddenly disrupt.  I repeat I will do all in
>    my power to avoid this.

Great.

By the way in regard to the readline issue, one could just completely
exorcise the readline code. rlwarp allows end-users to independently
choose whether to "wrap" a readline interface around a product. As you
would no longer be distributing readline at all you would no longer be
under any obligation to GPL GCL.

This is the first time I have been aware that rlwrap is distributed with
Debian:
http://packages.debian.org/unstable/editors/rlwrap.html
http://utopia.knoware.nl/~hlub/uck/rlwrap/
http://utopia.knoware.nl/~hlub/uck/rlwrap/README.txt

> 5) From the perspective of fairness, this 'common lisp usage' as
>    outlined in 4) cuts both ways.  Say someone writes a two line BSD
>    lisp file which modifies the compiler to print 'hello world' when
>    compiling a file.  Say the resulting image is BSD licensed.  Then
>    someone could make a proprietary fork, release a binary with no
>    source, and effectively hijack GCL.  Even if the image had some
>    intermediate license which required the distributor to just
>    distribute the GCL source, we've effectively permitted someone to
>    distribute a modified GCL compiler without releasing their
>    modifications, which is against even the LGPL.  
> 
>    On the other hand, it is quite unfair I feel to force large user
>    space programs like maxima, acl2 and axiom to choose the GPL for
>    their substantial code base because of GCL.  The way this is
>    typically handled in LGPL situations is to define an 'application
>    interface' as a wall between an LGPL'ed "library" and the user's
>    main code.  Any changes on one side of the wall must have
>    modifications distributed in source, whereas there are no
>    restrictions to changes on the other side of this 'wall'.  Perhaps
>    the common lisp hyperspec could be a definition of such an
>    interface.  Code using functions in this spec might be
>    unrestricted, whereas modification of the functions themselves
>    would be LGPL'ed.  I feel this is what clisp was trying to achieve
>    with its exception clause, but I'm really just speculating here.

I agree that this is sort of what CLISP is trying to achieve with their
exception clause, and it is done so quite successfully by simply
referencing package names and external symbols as defined in the ANSI CL
standard.

Note that the moment one references a non-specified CLISP package or
non-external symbol at least part of the code is no longer an
independent work:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/clisp/clisp/COPYRIGHT

It appears to have been revised for memory images. It seems fair that if
one references a non-external, etc. symbol that only the sources to all
the parts that are not defined as "independent work" must be disclosed.

...

> 7) I realize these issues are important, as demonstrated with
>    exceptional clarity recently by this SCO/Linux mess.  (Can anyone
>    imagine how much worse the situation might be had SCO not
>    itself distributed Linux under the GPL?)  But I must confess I'm a
>    bit tired of this discussion, and its eating up what little time I
>    have to push GCL forward.  Can we please get back to the code now?
>    I trust a solution will present itself in time, and until then, we
>    should be content with the status quo.

Then I believe my suggestion to completely remove readline support and
just let users choose whether to wrap readline functionality around GCL
will allow you to get back to pushing GCL forward.

Be aware of the arguments that Stallman made in 1992 in insisting that
CLISP be GPLed:
http://clisp.cons.org/faq.html#gpl
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL

Regards,
Adam