gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] A GCL license proposal


From: Camm Maguire
Subject: [Gcl-devel] A GCL license proposal
Date: 26 Jul 2003 12:21:41 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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 <address@hidden> 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                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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