clarification on clisp license

[Hoehle, Joerg-C. <Joe...@t-...>]

Don Cohen wrote:

>exports ext2:FOREIGN-CALL-OUT, defined as FFI::FOREIGN-CALL-OUT
Why do you want to call ffi::foreign-call-out? If you have a =
foreign-function object, you just FUNCALL it. If you don't have a =
foreign-function object, then foreign-call-out is of no help either.

>My position is
>that your code does not depend on the internals of clisp, other than
>the fact that clisp has an FFI.  You could do the same thing in any
>other common lisp implementation with an FFI.
Then the easy solution seems to name FFI beside EXT as usable packages =
in the COPYRIGHT.

"exactly the same" not so, maybe "something similar". That's the issue =
that I try to address in my articles.
http://article.gmane.org/gmane.lisp.clisp.devel/9958
http://article.gmane.org/gmane.lisp.clisp.devel/9900

The question can be rephrased: if somebody implements the FFI API =
described in impnotes/dffi.html for one of CMUCL, OpenMCL, ACL, =
Lispworks, CormannLisp (say, as UFFI v2), does that still make GPL code =
when an application uses this API?

The person writing this could sit on CMUCL, never use CLISP, just love =
the expressiveness of the FFI API. Bruno stressed the fact that =
"whether you actually do so, is irrelevant."

The application could be written in a way never to exihbit a =
#+clisp(ffi:...) or #+(or clisp ffi-api)(ffi:...) pattern. Yet it would =
run in CLISP with FFI, and not in a CLISP --without-dynamic-ffi.

>Since the license says that ext is fair game, the critical question
>becomes what you put in ext.  I think that the basic FFI ought to be
>there.=20
I'm against having EXT: re-export all of FFI. What does it help?
I'm in favour of having COPYRIGHT be more explicit.

Regards,
	J=F6rg H=F6hle.