From: John Thingstad
Subject: Re: CL Insight...
Date: 
Message-ID: <op.szmz31tdpqzri1@mjolner.upc.no>
On Wed, 02 Nov 2005 23:58:29 +0100, J.C. Roberts <unknown <@abac.com>>  
wrote:


> Yep, I'm looking at what I call "FrankenSource" -a mish mash of
> various parts, taken from different places, casually stitched
> together, and somehow given life by subjecting it to lightning.
>

lol.. FrankenSource.. I call it hetogenous programming.

> The problem is the only Common Lisp implementations I've found that
> support lots of different platforms are all commercial. Needing to pay
> $1000+ USD for a commercial Common Lisp implementation is no big deal
> to me but what about other developers on the planet? -The $50 USD cost
> of a single technical book in the US can be a month's wages in other
> parts of the world.

You might want to look into SBCL and Corman Lisp.
Corman lisp is commecial but the run time is free.
Just use my instructions for using it with emacs.

> Would I be better off buying LispWorks "Pro" license for doing the
> releases myself and hope other developers can live with the 5hour/heap
> limitations of the LispWorks "Free" version?  -Wouldn't releasing
> binaries from code made with the LispWorks "Free" version be a
> violation of the LispWorks "Pro" license?

I use LispWorks these days. Personal edition for now.
I expect to get a professianal version next month.
Heap limits are less of a problem than in the last version.
Nevertheless having the system abort without the possibility to save is  
annoying.
If you want to release code you need the proffesional version.

>
> Is my only viable option porting SBCL to MS-Windows and getting the
> whole SBCL project out of "beta" status?

No.. Corman runtime.. Avoid the time limited GUI.

> Any insight would be appreciated.
>
> Kind Regards,
> JCR

Hope this helps.

John

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From: John Thingstad
Subject: Re: CL Insight...
Date: 
Message-ID: <op.szm0dx1mpqzri1@mjolner.upc.no>
On Thu, 03 Nov 2005 00:41:51 +0100, John Thingstad  
<··············@chello.no> wrote:

> lol.. FrankenSource.. I call it hetogenous programming.

well.. polygynous actualy.
From: Sam Steingold
Subject: Re: CL Insight...
Date: 
Message-ID: <usluezch6.fsf@gnu.org>
> * J.C. Roberts <·······@nonp.pbz> [2005-11-02 18:19:41 -0800]:
>
> maintainers of CLISP have added some poorly worded conditions to the
> GPL in their "COPYRIGHT.txt" file to allow some form of closed source
> binary releases under rare conditions but it seems they have failed to
> actually read the GPL in the first place

false.

> since the GPL clearly states you can not add conditions to it.

(we are not _adding_ conditions, merely _clarifying_ what it means for a
 program to _extend_ clisp as opposed to being an independent work).


> More importantly, CLISP requires cygwin to run on MS-Windows

false.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.iris.org.il> <http://www.jihadwatch.org/> <http://truepeace.org>
<http://www.openvotingconsortium.org/> <http://www.memri.org/>
Lisp is a language for doing what you've been told is impossible. - Kent Pitman
From: Cameron MacKinnon
Subject: Re: CL Insight...
Date: 
Message-ID: <hq-dnWu7Kvp5EvTeRVn-jw@rogers.com>
Sam Steingold wrote:
>>* J.C. Roberts <·······@nonp.pbz> [2005-11-02 18:19:41 -0800]:
>>
>>maintainers of CLISP have added some poorly worded conditions to the
>>GPL in their "COPYRIGHT.txt" file to allow some form of closed source
>>binary releases under rare conditions but it seems they have failed to
>>actually read the GPL in the first place
> 
> false.
> 
>>since the GPL clearly states you can not add conditions to it.
> 
> (we are not _adding_ conditions, merely _clarifying_ what it means for a
>  program to _extend_ clisp as opposed to being an independent work).

CLISP comes with two text files that address copyright issues. It is 
obvious that they were written by two different "people" at different 
times, and it's not obvious that they were both lawyers. It doesn't 
really matter whether YOU think/claim that one merely clarifies the 
other while other people think that it attempts to modify the rights 
granted in the other license. Any IP lawyer would advise his client NOT 
TO TOUCH THIS CODE WITH A TEN FOOT POLE, because of the obvious 
ambiguity and risk (The real question is "What would a judge think?" and 
the answer is "Who the hell knows. Would you care to bet?").

The all-too-sad irony here is that the whole reason CLISP is GPL in the 
first place is that it got sucked into it -- against its creator's 
wishes -- because of a misunderstanding[1] about the GPL.

Further, the OP's misunderstanding of your intent shows that, at least 
for some people, your attempts at clarification have failed. Perhaps 
further clarification is in order? Hmm... Nope. You can't integrate the 
clarifications into the GPL you ship with since you can't change it 
without the consent of all of your contributors (including GNU readline, 
which is highly unlikely), and without changing to a single license 
file, you've still got the "two licenses, one drafted by an amateur" 
problem that makes any lawyer cringe.


[1] - 
http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL
From: Sam Steingold
Subject: Re: CL Insight...
Date: 
Message-ID: <usludwb15.fsf@gnu.org>
> * J.C. Roberts <·······@nonp.pbz> [2005-11-03 15:14:51 -0800]:
>
> On Wed, 02 Nov 2005 21:33:57 -0500, Sam Steingold <···@gnu.org> wrote:
>
>>(we are not _adding_ conditions, merely _clarifying_ what it means for a
>> program to _extend_ clisp as opposed to being an independent work).
>
> http://clisp.cons.org/impnotes.html
> 31.7. Application delivery with CLISP
>
> <FROM_PAGE>
> CLISP extensions, i.e. programs which need to access non-portable 
> CLISP internal symbols (in the packages "SYSTEM", "CLOS", "FFI", ...),
> must be covered by GNU GPL as well.
> </FROM_PAGE>
>
> Does this mean if you link a DLL/SO written in C to a CLISP program,
> the whole thing accidentally becomes GPL'ed?

the DLL does not extend CLISP, so it is not affected by the GNU GPL at all.
e.g., CLISP comes with a Matlab interface, but that does not make Matlab
a GNU GPL program.

the ANSI CL part of your program is not CLISP-specific (i.e., will run
in any implementation), so it is not affected by the GNU GPL at all.

the part that makes the DLL functionality callable from CLISP (the CLISP
module glue code or the CLISP FFI forms &c) constitutes a CLISP extension
and is covered by the GNU GPL.

Your lisp program that uses the DLL functionality via CLISP is _not_
affected by the GNU GPL ___PROVIDED___ the DLL functionality is _ALSO_
available from some other LISP implementation (i.e., your program that
uses the DLL functionality via CLISP uses it through a compatibility
layer).

So, suppose foo.dll exports the function
    int foo (int);
in foo.h that you want to call it from your lisp program.

1. foo.dll and foo.h are _not_ covered by GNU GPL, no matter what you do.

2. file foo.lisp (the compatibility layer) with the forms

(defpackage #:foo (:export #:foo))
#+clisp
(ffi:def-call-out foo (:name "foo") (:library "foo.dll")
  (:arguments (num int)) (:return-value int))
#+cmucl
(def-alien-routine "foo" int (num int)) ; what else does CMUCL need?

   _is_ covered by the GNU GPL, no matter what you do.

3. your CL program that uses FOO:FOO is _not_ covered by the GNU GPL,
   provided the the CMUCL - or some other implementation - forms are not
   a sham, i.e., are runnable in CMUCL: this makes your program _not_ an
   extension of CLISP, but a portable program that runs in a number of
   CL implementations.


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.savegushkatif.org>
<http://pmw.org.il/> <http://truepeace.org> <http://www.honestreporting.com>
Life is a sexually transmitted disease with 100% mortality.
From: Cameron MacKinnon
Subject: Re: CL Insight...
Date: 
Message-ID: <ZoOdnQjuwqPMMffenZ2dnUVZ_tCdnZ2d@rogers.com>
J.C. Roberts wrote:
> <FROM_PAGE>
> CLISP extensions, i.e. programs which need to access non-portable 
> CLISP internal symbols (in the packages �SYSTEM�, �CLOS�, �FFI�, ...),
> must be covered by GNU GPL as well.
> </FROM_PAGE>

What's that sucking sound? Did CFFI just get dragged into the GNU license?
From: bradb
Subject: Re: CL Insight...
Date: 
Message-ID: <1131075794.533647.205210@g44g2000cwa.googlegroups.com>
Only if you redistribute a system that needs Clisp & CFFI.
It appears to me that neither the GPL nor the LGPL are very good
licenses for Lisp implementations.  GPL and LGPL are confusing enough,
even with the reasonably clear C distinction of compiling/linking.
With Lisp's very murky compile/link/whole image paradigm the GPL
doesn't suit.  Of course, the copyright holders are responsible for
actually enforcing their rights, so the GPL can be as strong or as weak
as the copyright holder wants.  Witness the Linux kernel's take on
binary modules being linked to a running kernel - strictly it probably
violates the GPL, but Linus has said it is kosher in his GPL
interpretation, so people can do it with confidence.

Cheers
Brad
From: Raffael Cavallaro
Subject: Re: CL Insight...
Date: 
Message-ID: <2005110323294275249%raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2005-11-03 22:43:14 -0500, "bradb" <··············@gmail.com> said:

> It appears to me that neither the GPL nor the LGPL are very good
> licenses for Lisp implementations.  GPL and LGPL are confusing enough,
> even with the reasonably clear C distinction of compiling/linking.
> With Lisp's very murky compile/link/whole image paradigm the GPL
> doesn't suit.

Which is of course why for lisp there is the LLGPL:

<http://opensource.franz.com/preamble.html>
and
<http://opensource.franz.com/>

regards
From: bradb
Subject: Re: CL Insight...
Date: 
Message-ID: <1131087584.625485.195170@g44g2000cwa.googlegroups.com>
> Unfortunately, in spite of all the good intentions, it seems both you
> and Franz have failed to grasp an important fact about licensing; the
> supposed "preamble" actually means nothing legally since it is not
> actually part of the license.
Why not?  I agree that you cannot relicense something that is GPL
unless you are the copyright holder.  However, if you hold the
copyright then you can license under whatever terms you like.  If you
attach a preamble, or further clauses to the GPL, then you have created
a new license of your own design that is based around the GPL.  To me
the Franz license appears valid, take document A, add document B, where
they don't agree B wins.  You can't really call the new license GPL,
but they can have the same philosophical underpinnings.
The Franz license appears relatively clear, any changes you make to the
library must be under the same license & returned to the community.
Otherwise you can do what you like - very much in the spirit of the
LGPL, but clarified to suit the Lisp environment.

> Similar is true for "clarification" statements which are not part of
> the license itself. If terms need to be clearly defined to prevent
> ambiguity, such definitions and clarifications must be included in the
> license itself (or be attached to the original license as an addendum)
> in order to be legally valid.
I would imagine that if the copyright holder issues a clarification of
their interpretation of a license, then that should hold water.  If the
person in a position to take you to court tells you that what you're
doing is OK, then you should be OK.

Of course, I'm not a lawyer :) 

Brad
From: Cameron MacKinnon
Subject: Re: CL Insight...
Date: 
Message-ID: <S--dnVX9Ws_uifbeRVn-vA@rogers.com>
J.C. Roberts wrote:
> On Thu, 3 Nov 2005 23:29:42 -0500, Raffael Cavallaro
> <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> 
>>Which is of course why for lisp there is the LLGPL:
>>
>><http://opensource.franz.com/preamble.html>
>>and
>><http://opensource.franz.com/>
>>
> 
> Unfortunately, in spite of all the good intentions, it seems both you
> and Franz have failed to grasp an important fact about licensing; the
> supposed "preamble" actually means nothing legally since it is not
> actually part of the license.

I don't know how far I'd go in asserting that. In the GNU licenses, the 
language makes it clear that the preamble is a preamble and the license 
follows; they practically use the "cut here" ---8<---- lines of yore.

Franz's LLGPL (i.e. the Franz Preamble) is, on the other hand, also 
quite clear in its intentions. It is NOT to be taken as mere preamble:

"Accordingly, the license for the open-source Lisp applications consists 
of this document plus the LGPL. Wherever there is a conflict between 
this document and the LGPL, this document takes precedence over the LGPL."

That's clear and unambiguous language, and I doubt that the contract 
would be held unenforceable as written due to ambiguity. That said, 
labelling it a preamble and having the contract in two partially 
contradictory parts (two files) are both dumb moves. There's just no 
excuse for giving a potential adversary excuses.

> Similar is true for "clarification" statements which are not part of
> the license itself. If terms need to be clearly defined to prevent
> ambiguity, such definitions and clarifications must be included in the
> license itself (or be attached to the original license as an addendum)
> in order to be legally valid.

If you're referring to the CLisp schmozzle, I agree completely. But not, 
perhaps, for the reasons you think. If A and B have a contract and B 
later sends A a letter saying "I won't hold you to clause 23," they 
don't have to rewrite or amend the contract, and A may subsequently rely 
on B's letter. In the unfortunate case of CLisp, however, 'B' would be 
everyone who's ever contributed code to the project. Since they haven't 
(I presume) delegated their rights to change the conditions under which 
they've licensed their code, one person can't make representations on 
behalf of the whole project, and A would need representations from 
everybody, alternately relying only on the terms of the original license.

> If any contract lawyer around here would like to attempt to refute the
> above points, please do so with references to case law.

I am not a lawyer. This isn't legal advice. Even if you'd like to use it 
as such, free legal advice is probably worth less than what you paid for it.

While trying to find Portland Van on the web, I came across (at 
drudge.com, no less!) some other poor fool who'd transcribed from his 
Black's, thus saving me the trouble:

Black's law dictionary, Sixth edition

Preamble: A clause at the beginning of a constitution or statute 
explanatory of the reasons for its enactment and the objects sought to 
be accomplished. Generally, a preamble is a declaration by the 
legislature of the reasons for the passage of the statute and is helpful 
in the interpretation of any ambiguities within the statute to which it 
is prefixed. Griffith v. New Mexico Public Service Comm., 86 N.M. 113, 
520 P2d 269, 271. It has been held however to not be an essential part 
of act, and neither enlarges nor confers powers. Portland Van and 
storage Co. v. Hoss, 139 Or. 434, 9 P.2d 122, 126.


Go crazy. Keep in mind, though, that a contract is a meeting of minds. 
If it's clear to a reasonable man what Franz is trying to say, arguing 
that it shouldn't count because it's labelled 'Preamble' isn't likely to 
get one very far. It's a private contract involving neither the 
necessities of life nor the coercive power of the state.


Some people may think this stuff doesn't matter, that we're all friends 
here in the Lisp community, and we can be reasonably certain of not 
being slapped with a lawsuit, because we all understand the 'special' 
nature of Lisp execution environments. Let me paint an alternate 
scenario. Say X has developed a product or program which -- he thinks -- 
uses but doesn't extend or modify CLisp. In his mind there's a bright 
line between his code and CLisp, and he's not worried about being sued. 
He wants to sell all rights to WidgetCo, and they send in the land 
sharks to do "due dilligence," basically ensuring that he's selling them 
what he says he is. Once they see that license, the deal's off.
From: Alain Picard
Subject: Re: CL Insight...
Date: 
Message-ID: <87vez8948m.fsf@memetrics.com>
J.C. Roberts <unknown(NO_SPAM)@abac.com> writes:

>
> Unfortunately, in spite of all the good intentions, it seems both you
> and Franz have failed to grasp an important fact about licensing; the
> supposed "preamble" actually means nothing legally since it is not
> actually part of the license.

Fortunately, it seems you have failed to grasp an important
fact about licensing: _intention_ matters.  When I (and, I
presume, others) use the LLGPL on our code, we're doing so
_explicitly_ to allow you to use the code in a non-viral,
commercial environment.  Since the only people with a chance
of winning a suit in court are the copyright holders, and
they're explictly telling you it's ok to use the software in
a certain way, it seems one has little to fear.

The company I work for happily uses LLGPL code in its commercial
product; in fact, I recently commissioned such code to be written
specifically under that license.  We're not losing any sleep over it.

                                            --ap
From: Ulrich Hobelmann
Subject: Re: CL Insight...
Date: 
Message-ID: <3t0qt2Fqa825U1@individual.net>
bradb wrote:
> Only if you redistribute a system that needs Clisp & CFFI.
> It appears to me that neither the GPL nor the LGPL are very good
> licenses for Lisp implementations.  GPL and LGPL are confusing enough,
> even with the reasonably clear C distinction of compiling/linking.
> With Lisp's very murky compile/link/whole image paradigm the GPL
> doesn't suit.  Of course, the copyright holders are responsible for
> actually enforcing their rights, so the GPL can be as strong or as weak
> as the copyright holder wants.  Witness the Linux kernel's take on
> binary modules being linked to a running kernel - strictly it probably
> violates the GPL, but Linus has said it is kosher in his GPL
> interpretation, so people can do it with confidence.

With Linux that's a problem indeed.  Everybody wants accelerated OpenGL 
for their graphics cards, so everybody shuts up about the issue, but 
strictly speaking binary modules violate the GPL and anybody that 
contributed GPL code to the kernel could sue.  (I'm actually surprised 
that nobody has done it so far...  And after all, if the users and 
nVidia didn't like this simple fact about the GPL, they could switch to 
some BSD, so basically they're violating the license voluntarily.)

Exactly for this reason I think that a kernel should have a smaller 
interface that's outside the kernel, and a Lisp shouldn't really be 
GPLed either, for the reasons you state.

-- 
The road to hell is paved with good intentions.
From: Surendra Singhi
Subject: Re: CL Insight...
Date: 
Message-ID: <fyqcj3i2.fsf@netscape.net>
Cameron MacKinnon <··········@clearspot.net> writes:

> J.C. Roberts wrote:
>> <FROM_PAGE>
>> CLISP extensions, i.e. programs which need to access non-portable
>> CLISP internal symbols (in the packages �SYSTEM�, �CLOS�, �FFI�,
>> ...),
>> must be covered by GNU GPL as well.
>> </FROM_PAGE>
>
> What's that sucking sound? Did CFFI just get dragged into the GNU license?

From my understanding, one can distribute source code, even dependent on FFI,
or any other clisp internal symbols, under _any_ license. And thats why we are able
to distribute wxCL under wxWidgets license.

The GPL only comes into action, when one tries to distribute binaries compiled
by clisp, or clisp packaged as part of the application.

-- 
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html

The best-laid plans of mice and men go oft astray.
From: Surendra Singhi
Subject: Re: CL Insight...
Date: 
Message-ID: <br10j30k.fsf@netscape.net>
J.C. Roberts <unknown(NO_SPAM)@abac.com> writes:

> Thanks for the reply. So in terms a simpleton like me can understand,
> as long as someone is not trying to use CLISP source to create a new
> implementation of Common LISP and their stick to the external symbols
> provided by the COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS, GRAY,
> and EXT packages, they will probably not accidentally inherit the GPL
> as a license?
>
> I'm very curious why the GPL was used instead of LGPL? Is this because
> the project was started before there was an LGPL or is there some
> other reason why?

Are you trolling? Please read the clisp FAQ, and also have a look at the
download page to see the list of clisp binaries.  

-- 
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html

,----
| "All animals are equal, but some animals are more equal than others."
|     -- Orwell, Animal Farm, 1945
`----
From: Surendra Singhi
Subject: Re: CL Insight...
Date: 
Message-ID: <64r8j20q.fsf@netscape.net>
Surendra Singhi <·········@netscape.net> writes:

> J.C. Roberts <unknown(NO_SPAM)@abac.com> writes:
>
>> Thanks for the reply. So in terms a simpleton like me can understand,
>> as long as someone is not trying to use CLISP source to create a new
>> implementation of Common LISP and their stick to the external symbols
>> provided by the COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS, GRAY,
>> and EXT packages, they will probably not accidentally inherit the GPL
>> as a license?
>>
>> I'm very curious why the GPL was used instead of LGPL? Is this because
>> the project was started before there was an LGPL or is there some
>> other reason why?
>
> Are you trolling? 

Sorry, for the harsh word.

-- 
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html

,----
| "All animals are equal, but some animals are more equal than others."
|     -- Orwell, Animal Farm, 1945
`----
From: Cameron MacKinnon
Subject: Re: CL Insight...
Date: 
Message-ID: <6dSdnRdeMamouPbenZ2dnUVZ_tadnZ2d@rogers.com>
J.C. Roberts wrote:
> The problem is the GPL does not allow for modification.

I've addressed this in another post. Say 'A' modified the GPL and 
released ORIGINAL software under the new license, 'B' used it and there 
was a lawsuit. Do you seriously think a judge would say "A modified this 
contract, but the text is sacred, so I'm going to put it back the way it 
was and enforce a contract that neither party agreed to." Of course not.
The FSF, OSI etcetera wouldn't even have standing in the case unless 
invited in by one of the litigants.

Not that this applies to CLisp. Since it is a derivative of GPL licensed 
software, it inherits the original GPL.

> Unfortunately, according to the law the COPYRIGHT.txt file is not the
> license for the software and hence, it clarifies/changes nothing in
> the license. If you don't believe me, please talk to the lawyers who
> work on the Open Source Initiative (OSI):

A) Please provide citations, if you were given any. B) What if I don't 
believe those lawyers?

> The lawyers at the Free Software Foundation (GNU) will also tell you
> the exact same thing that I have told you.

Of course they will! That's their position, and the one they want you to 
believe. But (and this is key) none of those lawyers wrote the software 
in question, so they don't have any say in the licensing terms. If some 
hypothetical person wants to ship software with nine different files 
purporting to be the license, referencing each other, all slightly 
contradictory and none definitive, he can. All one can say with any 
certainty about any resulting litigation is that, should the parties 
decide not to settle, it will be long and expensive. But for someone who 
isn't the author (or his agent) to point to one of the nine files and 
say "that's the definitive one, all the rest are to be ignored totally" 
is preposterous.
From: Pascal Bourguignon
Subject: Re: CL Insight...
Date: 
Message-ID: <878xw4k6jb.fsf@thalassa.informatimago.com>
J.C. Roberts <unknown(NO_SPAM)@abac.com> writes:
> http://clisp.cons.org/impnotes/faq.html
>   A.1.1.1.	
>   License - why GNU GPL?
>   Because CLISP uses GNU readline.
>   Note that this does not necessarily prevent you from distributing  
>   your proprietary products based on CLISP. See Note in COPYRIGHT.
>
> If this single piece of code is the problem causing all of CLISP to be
> distributed under the GPL rather than the LGPL, the GNU-readline
> should be replaced.

Since 1) today clisp can be compiled without readline,
and   2) today there exist readline replacement libraries,
if it was the wish of the authors of clisp, they could distribute it, 
or even a separate version, under a different license.

Moreover nowadays, I'd bet 90% of the users of clisp use it under
emacs (inferior-lisp or slime) and therefore don't even use the
readline linked into clisp!


> Putting a LISP variant language implementation (a giant library of
> symbols/functions) under the GPL without modifying the GPL with the
> needed exceptions that allow for the use of external symbols by
> software with other licenses, results in a language implementation
> that is only usable to create GPL software.

And I understand it exactly like this.  The authors of GPL meta
software want to promote further GPL software creations.  Feels good.


> [...]
> Please don't misunderstand me. I think CLISP is beautiful software and
> I really do want to use it but if using it requires me to disregard
> the rights of others, then I will not use it. Making certain all
> licensing terms are as clear as possible in a legal sense is the only
> way to respect the rights of the authors.

One defense is to always write only portable code.  You should be able
to switch tools and targets at will at any time.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: CL Insight...
Date: 
Message-ID: <87br10h5v6.fsf@qrnik.zagroda>
Pascal Bourguignon <····@mouse-potato.com> writes:

> Since 1) today clisp can be compiled without readline,
> and   2) today there exist readline replacement libraries,
> if it was the wish of the authors of clisp, they could distribute it, 
> or even a separate version, under a different license.

I'm glad that it's available with sources, because I could look up
algorithms for computing possible rational results from transcendental
functions applied to rational arguments, like logarithm.

(Unfortunately CLISP doesn't return a rational result in all cases
when it's possible, but it tries pretty hard.)

-- 
   __("<         Marcin Kowalczyk
   \__/       ······@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/
From: John Thingstad
Subject: Re: CL Insight...
Date: 
Message-ID: <op.szm8y4x5pqzri1@mjolner.upc.no>
On Thu, 03 Nov 2005 03:19:41 +0100, J.C. Roberts <unknown <@abac.com>>  
wrote:

>
> I looked at Corman Lisp previously but it is a MS-Windows only
> solution so it fails to meet the cross-platform requirements.
>

Obviously Corman is Windows only. Just as SBCL (for now) is Unix only.
The idea was that if the code was ANSI CL it might be doable to
use SBCL on Unix and Corman on Windows. At least they both allow
binary's to be distributed without charge. I don't have any experience with
SBCL (some with CMUCL) but Corman lisp has some wrinkels when it comes
to ANSI compatibillity. This might be a problem.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/