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.
1) I will do everything in my power to ensure that GCL's license will
never force a license onto projects that use it as a compiler.
This is not only achievable, but from my understanding, not even
controversial among the existing participants of this
discussion. Please, everyone, rest assured.
2) There are several different ways to achieve 1), some more difficult
than others, including possibly doing nothing at all if it can be
shown that Dr. Schelter received permission to use unexec more than
10 years ago. Frankly I think this is the most likely actuality,
especially given his work with emacs over the years. But the
actual path to 1) is not yet clear in my mind, and probably won't
be for some time. In the mean time, we have the status quo, which,
with all its ambiguities, is just as functional as its always been.
3) This having been said, it is my opinion that axiom would be better
served by a GPL license. It is of course completely up to the
axiom developers and any other relevant parties, certainly not me,
but I feel that the existing BSD license places all the volunteer
work being poured into axiom at risk of being hijacked by a
commercial fork of the code. The last thing I am is a lawyer, but
my understanding of the BSD license is that anyone, including the
developers, can, if they so chose, relicense their copy/modified
version of the code under the GPL. This does not violate the BSD
license, to my understanding, and should require no special
permission. After all, one can make a commercial fork of BSD code
without permission, so one should certainly be able also to make a
GPL fork of said code.
Again, this decision lies in the hands of others than me; I just
state this here to clarify the point that should a GPL license for
axiom ever be desired, it should not require extensive negotiations
with other parties, who are free to continue to distribute the code
prior to such a fork under a BSD license.
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. 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.
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.
6) I'd be interested to know from the perspective of maxima, acl2, and
axiom users whether typical usage of the *final distributed binary*
(as opposed to intermediate images in the build process) would
require the ability to dump new images and/or load compiled
modules.
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.
Take care,
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah