Can someone tell me if the following is correct?
You can freely use those CLOCC lisp libraries, and provide them
to a customer as FASL files or a DLL to be loaded at runtime;
but if you deliver your executable application with them already
linked in, then your program itself is thereby infected with the LGPL.
In other words, you may not deliver a proprietary executable
application that was compiled with the CLOCC libraries.
> * In message <·············@spacy.Boston.MA.US>
> * On the subject of "LGPL question"
> * Sent on Mon, 3 Sep 2001 06:46:49 GMT
> * Honorable Christopher Stacy <······@spacy.Boston.MA.US> writes:
>
> You can freely use those CLOCC lisp libraries, and provide them to a
> customer as FASL files or a DLL to be loaded at runtime; but if you
> deliver your executable application with them already linked in, then
> your program itself is thereby infected with the LGPL.
> In other words, you may not deliver a proprietary executable
> application that was compiled with the CLOCC libraries.
I don't think this is correct.
CLOCC is big - some parts are under GPL, some are under LGPL, some are
under other licenses.
you would be much better off asking this on <clocc-list>.
As for LGPL, my understanding of it is that if you distribute an
application which uses, say, CLOCC/PORT (written by me, released under
LGPL), you have to supply full sources for CLOCC/PORT, plus "sufficient
data to rebuild your application after changing CLOCC/PORT".
Additionally, if you change CLOCC/PORT and _release_ the changes, they
must be released under LGPL too.
E.g., you wrote a program "foo" which uses a modified CLOCC/PORT and you
compile it with CLISP and distribute it as 3 files:
lisp.exe
lispinit.mem
foo.bat which calls "lisp.exe -M lispinit.mem"
then you must also distribute the modified CLOCC/PORT (licensed under
LGPL) and with the instructions like these:
if you modify CLOCC/PORT, you have to rebuild FOO like this:
lisp.exe -M lispinit.mem -i clocc/src/port/ext.fas -i ... \
-x '(saveinitmem "lispinit.mem" :init-function #'"'"foo:run-foo)'
[CLISP is covered by GPL, but you _can_ distribute proprietary
applications built with CLISP provided they do not refer to any CLISP
internal symbol, see file COPYRIGHT in the CLISP distribution for
reference and the precise conditions]
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
The only thing worse than X Windows: (X Windows) - X
Sam Steingold <···@gnu.org> writes:
> As for LGPL, my understanding of it is that if you distribute an
> application which uses, say, CLOCC/PORT (written by me, released under
> LGPL), you have to supply full sources for CLOCC/PORT, plus "sufficient
> data to rebuild your application after changing CLOCC/PORT".
> Additionally, if you change CLOCC/PORT and _release_ the changes, they
> must be released under LGPL too.
Worth noting in connection with releasing Lisp code under the LGPL is
the example of AllegroServe. AllegroServe is available under the
LGPL, but as "LGPL uses terminology that is more appropriate for a
program written in C than one written in Lisp", they have written a
prequel to define more exactly what they mean
http://allegroserve.sourceforge.net/license-allegroserve.txt
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
I agree with this and I'd like add one comment related to
what Sam Steingold wrote about the general LGPL.
If you distribute an application using AllegroServe or your
modified AllegroServe we do *not* require you to distribute files
that allow your 'customer' to build the application with
their own AllegroServe. We do this because it *could*
be a difficult thing for you to do and we don't want to
inhibit your using AllegroServe in something you distribute.
All we ask is that you distribute (or make available)
the source for the version of AllegroServe you used to
make your application).
John Foderaro <···@xspammerx.franz.com> writes:
> I agree with this and I'd like add one comment related to
> what Sam Steingold wrote about the general LGPL.
>
> If you distribute an application using AllegroServe or your
> modified AllegroServe we do *not* require you to distribute files
> that allow your 'customer' to build the application with
> their own AllegroServe. We do this because it *could*
> be a difficult thing for you to do and we don't want to
> inhibit your using AllegroServe in something you distribute.
>
> All we ask is that you distribute (or make available)
> the source for the version of AllegroServe you used to
> make your application).
These changes make the license not very LGPL-like. Not that there's
anything wrong with the resulting license, but it avoids one of the
points of the LGPL, which (for the sake of those who don't know) is
this:
Say I write a TransformFoo library, and release it under LGPL. Now a
friend of mine buys a commercial application SuperFooBar Generator,
which uses my library to transform Foo's, and its own to transform
Bar's. Now my friend comes to me and complains that my library is
incompatible with the slightly non-standard Foo's generated by MS
VisualFoo. So I go and fix my library. Because I LGPL'ed it, he can
now rebuild the library, and use the improvements with SuperFooBar
Generator.
This could be accomplished in a Lisp system by distributing
TransformFoo in FASL form, and having it loaded when the app starts
up, so I don't think it's incompatible with Lisp.
Again, there's nothing wrong with the AllegroServe license per se, but
calling it LGPL could lead people to assume things about it that
aren't true (which I had, until just now).