From: <don...@is...> - 2003-05-19 18:27:35
|
[with apologies to those who have already seen my earlier failed attempts to send to this list] Bruno Haible writes: > a new package to it? My proposal is: Let the contributor decide > whether the new package shall be considered a "clisp internal" or a > "public package" (like #<PACKAGE EXT>). This doesn't work. I could then write a package, ext2, defining ext2:foreign-call-out in terms of FFI::FOREIGN-CALL-OUT and declare ext2 to be "public". I argue that you should be able to sell a proprietary package containing c code that you write for your application (not related at all to clisp) and common lisp code that calls that c code but doesn't use clisp internals other than the published FFI for creating the interface from clisp to the c code. This is something you could do in any common lisp containing an FFI. At most, I think it would be fair to require you to put the interface code (calls to such things as FFI::FOREIGN-CALL-OUT) under GPL. I have two alternative suggestions. The simpler one is to put the FFI functions in ext, which seems to be the normal way to control what's "contaminated" by GPL. The other is to explicitly say in the license that while code that calls FFI functions is considered to use clisp internals, code that only uses the interfaces created by that code is NOT considered to use clisp internals. The second alternative would mean that when you write your application partly in c and partly in lisp, there is one small part of it that would have to be under GPL. If your c code is used only by you, this probably does not significantly reduce your proprietary control. However, if the c code is widely used, such as win32 or openGL, then you have to release something very useful to the rest of us. There may be different views on whether that's a good thing. I've reread the messages related to readline and conclude (though, of course, IANAL) that RMS had a very weak case. Clisp is really under GPL because Bruno decided he wanted it there. RMS likes to point out cases where aggressive contamination has the desirable effect of adding to the open source collection, but it can also have the opposite effect of forcing those who wish to maintain proprietary interest in SOME of their code to avoid GPL software, resulting in the loss to open source of other code that they might have been willing to release. |