Licensing and portability

Hi Marco,

Sorry for the late reply but I don't seem to get messages from
matlisp-users although
I am subscribed. I'll try to fix this. 

> What is the license?  You have a GPL file in the top-level, but then
> all (most) the files contain the BDS like license?

The license is UC Berkeley.  The gpl file on the top-level is to satisfy 
the demand of the headers in config.guess and congif.sub

> Could you make it consistently LGPL or BSD?

Perhaps.  But why, do you think LGPL works well with CL code.  It sort
of
inhibits all successors of the code (even if they only use it) and
discourages development.

> Also, what would it take to make it work under a different CL system?
> Are all the CL implementation dependecies in the fortran.lisp file?

It should be easy to make it work with Allegro (which I've looked into)
but did not pursue,
since Allegro is not a free implementation.  It will work immediately
with CLISP as soon
as CLISP has arrays specialized to DOUBLE-FLOAT with the specialization
having a contiguous
allocation of DOUBLE-FLOAT's the same size as a C double (I have some
ideas on checking
these sizes with configure and writing fortran.lisp automatically).

All dependecies were tried to put in fortran.lisp but this is only
partially true.
This is true if the lisp has arrays specialized to double-floats.  I
think, it is
possible to avoid this dependency (at least conceptually by naming
functions differently)
but I'd rather wait to do this to see if there is some serious interest
in matlisp.

As an example, look at src/copy.lisp and see the use of a global
specialized 1 element
double-float array.  This should also be defined in fortran.lisp.  But
that is about 
all there is to non-portability issues.

Otherwise, the setup (IMO) is pretty compact and seems to work well
under CMUCL (solaris,linux).

Tunc