Fri, 31 May 2002 08:13:54 -0700
Date: Fri, 31 May 2002 03:32:42 -0000
From: "Marc Santoro" <firstname.lastname@example.org>
Duane Rettig <email@example.com> said:
> Are you:
> 1. Protecting the LPGL from what you consider a threat to its
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
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
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.