From: Hoehle, Joerg-C. <Joe...@t-...> - 2003-05-21 08:29:14
|
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. |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2003-05-23 09:26:17
|
Hi again, here's another POV on the issue: not me (or whoever) releasing a package which possibly starts out on CLISP first, but trying to add CLISP support to other packages: Here's a comment from Jochen Schmidt w.r.t. CL-SSL >Well if including CLISP FFI code into cl-ssl would make it GPL I would vote >against doing so. Currently, I cannot repsond to the implicit question. 1. Would inclusion of #+CLISP FFI code make CL-SSL GPL? It seems so, by the letter??? 2. If yes, what would need to be changed to e.g. CLISP COPYRIGHT -- if such a change is possible at all? I see a difference between providing a CL-SSL compatible API as part of the CLISP distribution (or via any Web-Server) and integration of some CLISP-specific code into the CL-SSL CVS tree. The former implements compatibility to the API as it was at one point in time. The latter may automatically upgrade when CL-SSL is modified (depends on which part of it - some changes may break CLISP/LW/CormanLisp support in CL-SSL if nobody tests that). Regards, Jorg Hohle. |
From: <don...@is...> - 2003-05-21 17:19:33
|
Hoehle, Joerg-Cyril writes: > Don Cohen wrote: > > >exports ext2:FOREIGN-CALL-OUT, defined as FFI::FOREIGN-CALL-OUT > Why do you want to call ffi::foreign-call-out? My mistake. I really meant to use as an example something like def-call-out. But the point is the same: the ability to use internals in a package that creates interfaces that you declare to be public can be used to make everything public. So if the distinction is to have any meaning then packages that use internals must, in general, be restricted. I'm now ready to revise my position on what the license ought to say. I think the intent is (or at least should be) to distinguish between use of established/public interfaces and internal implementation. I suggest that the documentation be used as the basis for this distinction. That is, whatever is described in impnotes, unless stated otherwise (in impnotes) ought to be usable in non GPL code. The question remains: under what circumstances should an extension to clisp (code that depends on the internals, hence must be GPL) be usable in non-GPL code? My example above (simply exposing what was previously internal) shows that the answer should not be "always". But clearly it should also not be "never". The intent of GPL is, after all, to encourage people to improve the code and make their improvements available to all. (Even those who want to write proprietary code!) I think the answer is that if your code uses internal code then you need the permission of the copyright holder for that internal code in order to make your interfaces public. In that case, of course, you should also publish these interfaces. One way to do that would be to make your code part of clisp and add the documentation to impnotes. Of course, code that does not depend on clisp internals could be treated the same way except that no permission is required of the clisp copyright holder to make the interfaces public. |