LLGPL Clarification

[Duane Rettig]

--------
    Date:  Fri, 31 May 2002 03:32:42 -0000
    From:  "Marc Santoro" <ultima@tunes.org>

    Duane Rettig <duane@franz.com> said:
    
    > Are you:
    > 
    >  1. Protecting the LPGL from what you consider a threat to its
    > interpretation?
    Not really -- I have no desire to protect any particular license, but 
    rather use one that is ideal.
    >  2. Considering using LLPGL as an alternative form of licensing, based
    > on the metaprogramming issues you are surely facing?
    This is closer.
    >  3. ... ?
    
    Here we go. I would like to find a license that satisfies my desires 
    completely :) I am not a lawyer and I am not qualified to write a license 
    myself. But I do know that other licenses have serious inadequacies; the 
    BUGROFF license, as well as Public Domain, seem to be the best way to 
    release source code.

Perhaps then you should go with one of those licenses.  Alternatively, you
could write your own.  You seem to know what you want, so why not write one,
and then pay a lawyer for an hour or three to go over it and point out the
legal flaws?
    
    My primary concern in relation with the LLGPL is that after discovering a 
    license being promoted by one of the premier Lisp vendors, I find I would 
    not want to license my own code under it. Ideally, I would like Franz (or 
    anyone/group with enough legal expertise to write a license) to take my 
    ideas into consideration in preparing a revision of the LLGPL.
    
    Lisp shares a lot of traits with other languages, and I also feel that were
    a new, better license to be created, it could be created in a way that 
    would allow it to work for more languages. And if it was extremely well 
    developed, perhaps many of these squabbles would go away. I know of several
    other groups (such as the Squeak group) which have similar licensing issues
    because the language is too complicated for the license.
    
There is some sharing of issues which many extensible languages (forth, smalltalk,
lisp, etc) have in common, and for which the LGPL is not adequate, because it
has a C-based notion of what constitutes derivative work.  But this does not
work for languages whose primary purpose _is_ to be derivative (i.e., an
extension).  However, it is not at all a matter of the language being too
complicated, if you have the right model for the language.  Certainly, trying
to fit extensibility of language X into a C model makes language X too
complicated for the C model, but it just means that you are using the
wrong model.

John Foderaro has been trying to show you how macros are different between
Lisp and C.  That difference may seem to trivial to you.   But in fact,
it is part of the crux of the extensibility of Lisp vs C.  In fact, a Lisp
macro is really closer to a Lisp function than to a C macro.  As an example
of why this is so, take any ordinary lisp function, and instead of coding it to
actually do something, code it to return a Lisp form which will do that thing.
Then, call the function to get the form, and then call EVAL on that result.
You have effectively expanded and executed a simulated macro.  You simply
cannot do the same thing with C code in C within a single program.  There are
extensibility issues besides macro expansion, but since you chose to single out
macros, that is what we've been concentrating on.  Bottom line: Lisp is
extensible, C is not.

If you are looking for a license that covers your needs for a non-extensible
language, then LLGPL is not for you.  However, if you are looking for a license
that deals with common issues of extensible languages (such as treating code as
data) then the LGPL is too restrictive.

Duane