ArmedBear Common Lisp relicensed!

From: Adam Warner (usenet_at_consulting.net.nz)
Date: 07/31/04 

Date: Sat, 31 Jul 2004 15:07:34 +1200

Hi all,

In what could turn out to be the most important event for the Common Lisp
community this decade, Peter Graves (the developer of ArmedBear Common
Lisp (hereinafter "ABCL")), relicensed his compiler on 21 July 2004:
<http://sourceforge.net/mailarchive/forum.php?thread_id=5178024&forum_id=9737>

The new exception permits the linking of ABCL "with independent modules to
produce an executable, regardless of the license terms of these
independent modules, and to copy and distribute the resulting executable
under terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that module."

GNU Classpath (GNU's core Java libraries) is licensed with a similar
exception (Peter Graves calls ABCL "this software" whereas GNU Classpath
is called "this library").

This GPL+exception licence is more permissive than the Lesser GPL since
static linking with independent modules is expressly permitted. An
independent module is defined as "a module which is not derived from or
based on this software." There is no longer uncertainty that the act of
dynamic or static linking of independently developed code creates a
derived work.

A very nice quality of the licence is that everyone may extend the
exception to new versions of the software. The Common Lisp community can
grow to depend upon the implementation with the long term security that
forking is always an option.

Peter Graves' expressed interpretation of the licence has been entirely
sensible and it resolves any ambiguities as to whether one may access
internal functions of ABCL via an "independent module":
<http://sourceforge.net/mailarchive/forum.php?thread_id=4977907&forum_id=10173>

   Well, if you MODIFY the internals of ABCL, you've created a derived
   work, and you need to publish the source of the modified ABCL. You
   don't need to GPL the application that you've built on top of the
   modified (or unmodified) ABCL, and you don't need to publish the
   application's source (but you are free to do so if you want).
 
   If you don't modify anything in the ABCL distribution, but (for
   example) your code calls some internal ABCL function, then you're
   still OK, as far as I'm concerned, from a legal point of view.
 
   From a technical point of view, internal functions (or, for that
   matter, any function whatsoever) may go away at any time, so your code
   might not run without modification on a newer version of ABCL. That's
   a technical problem, but not a legal one, as I see it. It's no problem
   at all if you just ship a snapshot of ABCL that you're happy with, and
   you don't care about running that same exact code on a newer version of
   ABCL that might not contain the function in question.

Brilliant. I suspect the first casualty of this relicensing will be CLISP
popularity as at least one CLISP developer has a rather novel view of
their licence exception (e.g. incorporating an external function like
EXT:CD explicitly in user code (to change the current directory) requires
the user's code to be GPLed if distributed when it only runs upon CLISP).

Furthermore ABCL can run upon far more advanced Just in Time compilers.
CLISP has a plain bytecode interpreter. Obviously CLISP is presently much
faster for some purposes because the bytecode is specifically designed to
evaluate Common Lisp and it uses some very fast native libraries. But in
some examples (e.g. Message ID <ce9b35$6jir0$1@hades.rz.uni-saarland.de>
with dual Pentium 4, 3.0 GHz, 1000 MB RAM, 512 KB cache as hardware) CLISP
was 20.27 times slower than the CMUCL 18e reference for computing 500!
1000 times. With the Sun 1.5.0 beta JDK ABCL was only 2.28 times slower
than CMUCL.

Longer term development of ABCL will threaten the general supremacy of the
native Common Lisp compilers. Vast resources continue to be devoted to
making Java bytecode run faster. Already we see ABCL beating every other
implementation in complex and double floating point Mandelbrot
calculations with the Sun 1.5.0 beta SDK. When run 1000 times on the
same hardware as listed above the code below evaluated almost three times
as fast as the closest implementation:

(defun mset-level/complex (c)
  (declare (type complex c))
  (loop :for z = #c(0 0) :then (+ (* z z) c)
        :for iter :from 1 :to 300
        :until (> (abs z) 4.0)
        :finally (return iter)))

(defun run-mandelbrot/complex ()
  (let ((n 100)
        (sum 0.0))
    (dotimes (i n)
      (incf sum (mset-level/complex (complex 0.0001d0 (/ i n 0.25d0)))))))

ABCL will also be a serious competitor to the proprietary Common Lisp
implementations which distinguish themselves through their superior cross
platform (particularly Windows) and GUI support. Java is just as portable
and even more importantly many people want to seamlessly interface with
Java libraries. Arguably the best cross platform GUI toolkit presently
available is IBM's SWT, a component of Eclipse (SWT also requires the
installation of platform specific libraries, e.g. a DLL on Windows). Great
looking native GUI and cross platform Lisp applications will now be easier
to develop. SWT has manual resource management and Lisp will be perfect as
always for abstracting most of the drudgery away.

ABCL will obtain all the benefits from AMD64 Java compiler optimisation.
The only significant limitation inherent in Java is that array indices are
constrained to 31 bits.

Last year Eric Marsden remarked about the "Holy Grail" of using ABCL to
producing a standalone Lisp executable using gcj. While technical issues
remain there no longer appears to be any legal impediment for this to
apply to "independent" non-GPL-compatibly licensed code.

My public thanks to Peter Graves for his generous contribution to the
Common Lisp community.

Regards,
Adam

Relevant Pages