[Openmcl-devel] Question about redistribution

Gary Byers gb at clozure.com
Wed Nov 27 13:27:18 PST 2002

On Wed, 27 Nov 2002, Dan Bothell wrote:

> If I use save-application to create an image of an application can I
> distribute that along with the lisp kernel (dppccl) to end users, and if so,
> what notices/licenses, if any, do I need to include with it?  Sorry if this is
> answered in the documentation somewhere, but I couldn't find it.
> Thanks,
> Dan
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel

The LGPL is included in OpenMCL source and binary distributions as
the file "ccl:LICENSE".  It's written to cover more traditional
cases where a "library" (probably a static or dynamic object file
of some sort) is linked against by an application.  Lisp generally
works a little differently: a lisp function "links to" the library
function OPEN (for instance) by referring to it, so some of the
provisions of the LGPL require interpretation.

(I believe that Franz Inc has drafted a modified version of the LGPL
which clarifies how that license can reasonably be applied to Lisp.  I
also believe that the following is a reasonable interpretation of how
the LGPL applies to copying, distributing, and modifying OpenMCL.  If
people would be more comfortable seeing some of this "interpretation"
stated more concretely in the license, I'll see what I can do about

The set of Lisp functions and runtime support derived from LGPL'ed
OpenMCL sources constitute the "library" to which the LGPL applies
(and this is typically distributed as an executable kernel and a heap
image.)  An "application that uses that library" is another set of
Lisp functions which call into and/or depend on runtime support
provided by that library.  It happens that an application is typically
packaged as an augmented heap image; it could also be distributed as
a set of FASL files that could be loaded into a "library" image.
The "application" (e.g., your code) is not covered by the LGPL (unless
you, as copyright holder, decide to license it that way.)

The first four sections of the LGPL describe the terms under which the
library itself can be distributed.  Note that you're allowed to
distribute unmodified copies of the library and are allowed to
distribute modified copies of the library provided that those
modifications are licensed under the LGPL.  (If you find that your
application works better if OpenMCL's garbage collector or sequence
functions are replaced with your own versions, you can replace
OpenMCL's code with your own, but have to - among other things -
provide source for your changes to the library.)

Sections 5 and 6 of the LGPL describe how an application that uses the
library can be distributed.  Section 5 describes what you need to do
if your application is distributed in "unlinked form" (e.g., as a set
of FASL files and loader scripts.)  The short version is that you
really don't need to do anything else in that case.

Section 6 describes the case where your appliction is distributed
in "linked form" (e.g., as a heap image which also contains the
"library".)  The LGPL requires that the end-user of an application
that uses an LGPL-ed library distributed in this form be able to
"link" the application with another (interface-compatible) version
of the library.  There seem to be at least two ways of accomplishing

  a) Make FASL files available to end users of your application,
     so that they can rebuild it themselves.

  b) Make the lisp development facilities in OpenMCL (at least the
     fasl loader) available in your application, so that the end user
     can "link with a new version of the library" by compiling
     OpenMCL fasl files with OpenMCL and loading those FASL files
     into your application.

I can't think of a more reasonable interpretation of the term "library"
as it applies to OpenMCL and the LGPL than that presented here.  Again,
if people would be more comfortable if the lisp-specific aspects of
that interpretation were more clearly stated in the license I'll see
what I can do to clarify that.

Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list