gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Thomas
Subject: [Gcl-devel] RE: GCL compliance and Bill Schelter
Date: Thu, 24 Jul 2003 15:08:05 +1000

Hi Tim.

| The AKCL tarballs are a non-issue as I believe it can be shown that
| Bill rewrote the KCL portion of the system. I know it was his intention
| to do so quite early in the game and he had about 10 years to achieve it.

Just to clarify my point, I'm not talking about the implications of the
Kyoto Common Lisp (KCL) licence for the later usage of AKCL.

Rather, I am talking about the implications of those items of source code in
the purely AKCL, Bill Schelter enhanced/added parts of those tarballs.  That
code includes unexec and gnumalloc, neither of which appear to have been
substantially written by Bill and both of which are GPL with the exception
of the HP code which stands in an ambiguous position due to a lack of a
licence statement in the particular tarballs under consideration, but which
seems to have been intended for use in Emacs.  In fact I think that the HP
code is NOT GPL, but I would not like to bet on it and so that possibility
is worth consideration.

This is not, by the way, intended to minimise the relevance of KCL to AKCL
licencing from a legal point of view - in that part of my last email I was
just considering the potential implications of the GPL code in AKCL for the
commercial branch of Macsyma.

Incidentally, the V directory in each of those tarballs mentioned in my
earlier email contains the patches needed to produce AKCL from the original
KCL sources as mentioned by yourself earlier.

| We could probably compare the KCL and GCL sources if necessary. Else we
| could contact the KCL people who may no longer care if it is GPLed.
| I know for a fact that the AKCL merge mechanism is no longer used.
| This mechanism allowed Bill to patch the KCL sources to make AKCL.

Agreed.

| The copyright for GCL would follow Bill's estate so his son, who I've
| spoken to in the past, is the likely holder-of-record for the copyright.
| However, an argument could be made for "abandonment" (since I believe
| his son has taken no interest in GCL) making Camm the potential
| copyright holder-of-record.
|
| It is entirely possible that the portions of Emacs that exist in GCL
| were authored by Bill. I know that I sat at his elbow when he found a
| problem with using gdb under a shell in an Emacs buffer. He stopped
| what we were debugging, downloaded the Emacs sources, fixed the problem,
| and uploaded a patch. So I know for a fact that he has authored code
| in Emacs. I don't know where or how to verify who authored unexec.

Spencer W. Thomas, Bob Desinger (at least) for the various unexec files in
the early AKCL tarball, and at least three authors without surnames or just
represented by initials for GNU malloc.  Also M. Frigo for the Linux unexec
in the later tarball.

| Suppose I write a common lisp program like Axiom (licensed under
| modified BSD). Suppose I use a GPLed Common Lisp and save a binary
| image of the loaded program. If saving the image requires my common lisp
| program to ALSO be GPLed then it is not possible to develop programs
| using a GPLed Common Lisp. Some consideration has to be made of the
| fact that GPL grew up in a C world where compilers, not interpreters,
| were the norm. Either that or GCL should be very careful about declaring
| itself to be GPLed as the save-system mechanism (as well as other
| mechanisms) become useless. I don't believe it is the intention of
| GPL to require every Common Lisp programmer to GPL their code. The
| language should be separate from the programs written in that language.

I agree in relation to the language per se (the purely linguistic elements),
but I think that the library implementations are another matter (regrettably
in the case of languages such as Lisp which of course have substantial
runtimes and are traditionally saved out to form new images).

Equally unfortunate in this case is that one Common Lisp does not equal
another when it comes to portability so it is easy to get stuck with one
implementation of the language.

| It should be sufficient to ensure that the GPLed (or LGPLed) Common
| Lisp sources and Axiom sources are available to rebuild the system. If
| saving the image requires Axiom to also be GPLed then I cannot work.

Yes, it's a nasty bind and particularly galling considering the amount of
work that has recently gone into making Axiom work with GCL.

| I
| do not have the copyright and could not GPL Axiom even if it were
| required.

To clarify, I underatand that (IBM or NAG?) released the code with licencing
conditions on it which cannot be changed.

>From a practical point of view, I would hate to look a gift horse (free BSD
Axiom)in the mouth when the gift came from such an appalling example (IBM,
at the very least from the Thomas J Watson years apparently) of the
subjugation of moral responsibility to commercial and 20th century right
wing political imperatives.

Cheers

Mike Thomas.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]