Subject: [clisp-list] CL-GTK and CLISP license?

From: Hannu Koivisto <[email-masked]>
Date: 22 May 2000 13:53:54 +0300

Greetings,

Some time ago I asked for clarification on CLISP's license but got
no answer.  I'll try once more from a bit different viewpoint.

Espen S. Johnsen has written GTK bindings that support CMUCL and
CLISP.  The package is distributed under LGPL license.  It uses
CLISP's FFI package (in #+clisp ... code).  Is this legal?  I've
tried to interpret GPL and LGPL but I just don't get it.  Somehow
based on the explanation of derivative work I get a feeling that it
/might/ be legal when distributed on its own, but I'm getting
headache when I think what happens if I actually try to use it with
CLISP to create a non-GPL application that doesn't use CLISP
internals but it uses CL-GTK that does.  Then again, when I read
Why-CLISP-is-under-GPL text I'm starting to doubt whether CL-GTK is
legal even if it is distributed on its own.

The reason I'm wondering this is that I'm trying to find a Common
Lisp implementation that I could use to create something along the
lines of Software Carpentry's
<URL:http://software-carpentry.codesourcery.com/> SC Build tool,
i.e. basically a make replacement.  CLISP is pretty much the only
alternative with regard to portability requirements, but since it
doesn't have good enough system interfaces for running external
programs etc. I would need to write them myself and thus need to
use CLISP-specific packages such as FFI.  However, I'd prefer this
build tool to be distributed under BSD license (or similar) and I
also don't want to impose any particular license on users'
"makefiles" that may contain arbitrary CL code (i.e. if they don't
use CLISP internals, they shouldn't need to make their "makefiles"
GPL'ed just because the build system they use uses CLISP
internals).

Thanks in advance,
-- 
Hannu

---

From: [email-masked] (Don Cohen)
Date: Mon, 22 May 2000 09:55:14 -0700 (PDT)

The original message from Hannu Koivisto asks whether one is allowed
to distribute non GPL applications built from Clisp plus other (L)GPL 
lisp code.

The basic problem is that (L)GPL is really meant for c code, not 
lisp code.  The Clisp copyright specifically weakens the requirements 
in an appropriate way.  
You can write a common lisp program and distribute it as a Clisp 
image if you also offer the customer all he needs in order to build 
that image, i.e., the appropriate version of Clisp, the files that 
have to be loaded into it, and the directions for doing that.

I see two probems when you want to distribute an application that
contains some other (L)GPL code.

1. The Clisp copyright says:
  You may copy and distribute memory image files generated by the
  function SAVEINITMEM, if it was generated only from CLISP and
  independent work ...
How about images generated from CLISP, other LGPL code, and 
independent work?  Of course, if the other LGPL code is independent
work, then the original copyright allows it.  What we need is 
permission if it's not.

2. It's not so clear whether your code is "derived from" that other 
LGPL code.

I notice that there's a file in the new Allegro web server that
specifically addresses this problem.  (Allegroserve is available 
from ftp://ftp.franz.com/pub/aserve/).  I include the file
license-allegroserve.txt below.
I'd like to thank Franz both for attempting to clarify this subject 
and for releasing code under that license.

I think it would be useful to add that sort of clarification to the
code in libraries (such as CLOCC).  I guess I'm proposing a new
license, the "LispGPL", which is suitable for lisp code.

================

Prequel to the Gnu Lesser General Public License

Copyright (c) 2000 Franz Inc., Berkeley, CA 94704

Franz Inc. has adopted the concept of the GNU Lesser General Public
License version 2.1 ("LGPL") to govern the use and distribution of
AllegroServe.  However, LGPL uses terminology that is more appropriate
for a program written in C than one written in Lisp.  Nevertheless,
LGPL can still be applied to a Lisp program if certain clarifications
are made.  This document details those clarifications.

Accordingly, the license for AllegroServe consists of this document
plus LGPL.  Wherever there is a conflict between this document and
LGPL, this document takes precedence over LGPL.

A "Library" in Lisp is a collection of Lisp functions, data and
foreign modules.  The form of the Library can be Lisp source code (for
processing by an interpreter) or object code (usually the result of
compilation of source code or built with some other
mechanisms). Foreign modules are object code in a form that can be
linked into a Lisp executable.  When we speak of functions we do so in
the most general way to include, in addition, methods and unnamed
functions. Lisp "data" is also a general term that includes the data
structures resulting from defining Lisp classes.

A Lisp application may include the same set of Lisp objects as does a
Library, but this does not mean that the application is necessarily a
"work based on the Library" it contains.

The AllegroServe Library consists of everything in the AllegroServe
distribution file set before any modifications are made to the files.
If any of the functions or classes in the AllegroServe Library are
redefined in other files, then those redefinitions ARE considered a
work based on the AllegroServe Library. If additional methods are
added to generic functions in the AllegroServe Library, those
additional methods are NOT considered a work based on the AllegroServe
Library. If AllegroServe classes are subclassed, these subclasses are
NOT considered a work based on the AllegroServe Library.  If the
AllegroServe Library is modified to explicitly call other functions
that are neither part of Lisp itself nor an available add-on module to
Lisp, then the functions called by the modified AllegroServe Library
ARE considered a work based on the AllegroServe Library.  The goal is
to ensure that the AllegroServe Library will compile and run without
getting undefined function errors.

It is permitted to add proprietary source code to the AllegroServe
Library, but it must be done in a way such that the AllegroServe
Library will still run without that proprietary code present.

Section 5 of the LGPL distinguishes between the case of a library
being dynamically linked at runtime and one being statically linked at
build time. Section 5 of the LGPL states that the former results in an
executable that is a "work that uses the Library."  Section 5 of the
LGPL states that the latter results in one that is a "derivative of
the Library", which is therefore covered by LGPL.  Since Lisp only
offers one choice, which is to link the Library into an executable at
build time, we declare that, for the purpose applying LGPL to the
AllegroServe Library, an executable that results from linking a "work
that uses the AllegroServe Library" with the Library is considered a
"work that uses the Library" and is therefore NOT covered by LGPL.
Because of this declaration, section 6 of LGPL is not applicable to
the AllegroServe Library.  However, in connection with each
distribution of this executable, you must also deliver, in accordance
with the terms and conditions of the LGPL, the source code of
AllegroServe Library (or your derivative thereof) that is incorporated
into this executable.