Greetings! I've been mulling this over and think I have the beginning
of an idea which I hope will make everyone happy.
Here are my preliminary thoughts:
1) In an ideal world, GCL can do for lisp what gcc has done for C. I
see a strong parallel here, and would like to strengthen the
connections between the projects to the benefit of lisp developers
and free software users alike.
As pointed out before, C development in the free software world
looks like this: a GPL'ed compiler and linker, an LGPL'ed libc
'runtime', and user object code/executables licensed as they wish,
as long as they just reference the LGPL'ed libraries. I think that
everyone is happy with this situation. I know I am; and I believe
it has served the cause of free software development in C
outstandingly well.
The problem when extending this to lisp is that, in typical usage,
each executable has the compiler, the linker/dumper, the 'runtime'
and the users code all dumped into one image. This is of course
not the only way in which binaries can be produced and distributed,
but is very convenient. One could also distribute one or more .o
files, and have the user load them themselves.
So say we followed the C model, and GPL'ed the 'compiler', which
includes the linker and dumper, LGPL'ed the 'runtime', which are
all the other functions specified in the common lisp spec, and
maintained that user produced .o file have the license of the
user's choosing. As GCL produces these via .c, .h, and .data
files, and in some cases writes some of itself into the .c files,
(specifically cmpinclude.h), we might apply the 'bison exception'
in this case if needed. What would this mean for GCL users? Here
is how I think it would work:
1) Someone ships a 'traditional' image produced by save-system
with all of GCL and their code in it together. This
distributed 'combination' image would be GPL, and the user
must supply the source. The user supplied non-GCL source
could be more permissively licensed under BSD as in the case
of axiom, as BSD is compatible with GPL.
2) Someone ships a 'new' image produced by an (as yet to be
written) save-system variant which would leave out the
compiler, linker, and dumper from the image. This
'combination' image would be treated the same as someone
statically linking in libc. I'm not sure of the details, but
the gist would be that user source which did not directly
affect the 'runtime' GCL code would not have to be supplied.
3) Someone ships binary only .o files according to the license of
their choosing, as long as they reference only the LGPL'ed
'runtime' functions and not the compiler, linker, or dumper.
This is closest to the model of proprietary binaries shipped
for GNU/Linux systems today. Here the user's running GCL is
analogous to the OS, their execution of the 'load' command to
load the .o files analogous to the action of ld.so in
GNU/Linux, and the .o files' invocation of the common lisp
runtime functions analogous to proprietary binaries' calling
libc functions.
4) Someone ships the program in source form according to the
license of their choosing for the user's GCL to compile.
Can't see a problem here.
It is my preliminary opinion that this would inconvenience no one,
make everyone happy, and be arguably fairer all around than the
current setup. In particular, it would free GCL to build upon the
excellent GPL'ed compiler/linker infrastructure from the C world,
which I think is critical for GCL's long term future. As I've
stated before, I'd like to eventually have GCL act as a gcc
frontend in addition to its current mode of operation. These
license issues would doubtlessly only get worse as such a project
would unfold.
2) I think that unexec is a nice feature in GCL, as is the bfd
linking, and I don't want to have to get into the business of
emasculating the program for licensing reasons, especially as I
have yet to hear from anyone who needs/wants a closed source GCL
binary. I don't even relish the idea of trying to reconstruct
what happened more than 10 years ago with unexec and Dr. Schelter,
though my opinion is that it is very likely he got some permission
to uses these files in GCL. But these files are being continually
developed under the GPL, making 'grandfathering' exceptions a bit
messy from unexec developers' points of view. I hope the setup
outlined above would enable us to focus on quality, and leave these
matters behind us once and for all.
3) I would like to hear from as many GCL users as possible regarding
their opinions on how this would affect their work. My
understanding is that it would not affect GCL's current main
users -- maxima, acl2, and axiom, at all.
Take care,
Richard Stallman <rms@gnu.org> writes:
> We should think seriously about switching GCL to the GPL,
> not assume that the goal is to avoid this.
>
> 2) I am concerned with free software authors who might insist for some
> reason on a BSD-like license. Specifically axiom.
>
> Would they have any particular rational reason for thinking they need
> this? Note that we have no intention of changing to either of the BSD
> licenses.
>
> 3) I feel that any 'predominant' free compiler for a given language
> will likely not restrict the license of code merely compiled with
> it.
>
> That is true in any case. Code compiled with GCL's compiler is
> copyright by its author, not by the copyright holders of GCL.
>
> 6) Its obviously not right to use emacs' unexec under the LGPL without
> special permission. I'm confused as to how this situation arose.
> I find some unexec files in the May 10 1994 release of gcl-1.0.
> Did Dr. Schelter ever discuss this with you or any other emacs
> developers?
>
> Alas, there is no chance I would remember after ten years, sorry.
>
>
>
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah