In article <··············@eho.eaglets.com>,
Sam Steingold <···@goems.com> wrote:
>
>Note that CLISP is GPLed, so you *must* make the file `myfile.lsp'
>available if you distribute the binaries.
>
Is that so?
Suppose I only distribute `myfile.bin' and rely on the user to acquire
CLISP? Isn't that similar to compiling `myfile.c' with the GPLed GCC
and distributing the respective binary? So would I have to make
`myfile.c' available, because I used GCC to compile it?
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
········@korb.ai.univie.ac.at (Bernhard Pfahringer) writes:
> In article <··············@eho.eaglets.com>,
> Sam Steingold <···@goems.com> wrote:
> >
> >Note that CLISP is GPLed, so you *must* make the file `myfile.lsp'
> >available if you distribute the binaries.
> >
>
> Is that so?
>
> Suppose I only distribute `myfile.bin' and rely on the user to acquire
> CLISP? Isn't that similar to compiling `myfile.c' with the GPLed GCC
> and distributing the respective binary? So would I have to make
> `myfile.c' available, because I used GCC to compile it?
If CLISP is an incremental compiler, it's by no means similar to gcc.
It would translate mylisp.lsp into an intermediate C file which contains
essential parts of the sourcecode of CLISP, making it a derivative work. Then
the restrictions of the GNU GPL apply to the derived work.
Klaus Schilling
Bernhard Pfahringer wrote:
[Sam Steingold said:]
>> Note that CLISP is GPLed, so you *must* make the file `myfile.lsp'
>> available if you distribute the binaries.
>
> Is that so?
>
> Suppose I only distribute `myfile.bin' and rely on the user to acquire
> CLISP? Isn't that similar to compiling `myfile.c' with the GPLed GCC
> and distributing the respective binary? So would I have to make
> `myfile.c' available, because I used GCC to compile it?
It's not quite the same. What Sam was suggesting distributing
wasn't the fasl file derived from "myfile.lsp", but a CLISP
memory image, which would include not only the compiled "myfile"
but also (e.g.) CLISP's compiler. This stuff would all be
tangled up in the memory image in a way that would, I think,
make it difficult to talk of "mere aggregation". So, you'd be
distributing a derived work from CLISP, so the GPL would require
that you make available the source code to the *whole* thing,
including "myfile.lsp".
If you just distributed the fasl file, that wouldn't happen,
of course.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
········@korb.ai.univie.ac.at (Bernhard Pfahringer) writes:
> >Note that CLISP is GPLed, so you *must* make the file `myfile.lsp'
> >available if you distribute the binaries.
> >
>
> Is that so?
>
> Suppose I only distribute `myfile.bin' and rely on the user to acquire
> CLISP? Isn't that similar to compiling `myfile.c' with the GPLed GCC
> and distributing the respective binary? So would I have to make
> `myfile.c' available, because I used GCC to compile it?
No, but if the libc you linked against was distributed under the GPL,
you would have to distribute myfile.c. In this way the GPL "infects"
your part of the application, because you are not merely aggregating
your application on the same medium, but actively integrating with it,
i.e. it would be argued that your work is a derived work.
This is precisely the reason why the _LGPL_ exists.
Similar points restricted the usage of bison in the past, because the
included parser skeleton was under the GPL. A few years ago this
skeleton was released to the PD, so now you can use bison to create
parsers that are integrated into non-GPL programs.
WRT to CLISP, it might be debatable whether the *.{fas,lib}
byte-compiled files created by clisp's #'compile-file are derived
works or merely output of the program. So you might get away with
distributing *.{fas,lib}, and aggregating with it a complete
independant copy of clisp on the same medium, and arranging for your
start-up script to load your application into a clisp process. But I
wouldn't depend on this arangement holding up in court (IANAL).
OTOH it seems clear beyond doubt that a clisp saved-image (dump) --
which incorporates a large amount of implementation-code -- would be
considered a derived work under the GPL, thus bringing your whole
application under the GPL.
So if you're developing an application not to be placed under the GPL,
I'd suggest either not using clisp, and/or consulting the authors of
CLISP and a copyright-lawyer to either clarify the implications of the
GPL, or get written permission to use CLISP under a different licence
for your application.
Regs, Pierre.
PS: The usual disclaimers apply, i.e. I am not a lawyer.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Sam Steingold <···@goems.com> wrote:
> Note that CLISP is GPLed, so you *must* make the file `myfile.lsp'
> available if you distribute the binaries.
This would be true if CLISP was under GPL without exception. However,
the copyright file contained in CLISP's sources and binary distributions
contains a paragraph designed to clarify the points explained by
Bernhard Pfahringer and Pierre Mai.
------- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----
Note:
This copyright does *not* cover user programs that run in CLISP, if
they don't reference symbols in CLISP's built-in packages (except
the packages LISP, USER, COMMON-LISP, COMMON-LISP-USER, KEYWORD),
i.e. if they don't rely on CLISP internals and would as well run in any
other Common Lisp implementation. Such user programs are not covered
by the term "derived work" used in the GNU GPL. Neither is their
compiled code, i.e. the result of compiling them by use of the function
COMPILE-FILE. We refer to such user programs as "independent work".
You may copy and distribute memory image files generated by the
function SAVEINITMEM, if it was generated only from CLISP and independent
work, and provided that you accompany them, in the sense of section 3
of the GNU GPL, with the source code of CLISP - precisely the same CLISP
version that was used to build the memory image -, the source or compiled
code of the user programs needed to rebuild the memory image (source
code for all the parts that are not independent work, see above), and
a precise description how to rebuild the memory image from these.
------- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----
Pierre Mai <····@acm.org> writes:
> WRT to CLISP, it might be debatable whether the *.{fas,lib}
> byte-compiled files created by clisp's #'compile-file are derived
> works or merely output of the program.
Yes, it would be debatable without that additional note. I hope
the note above draws a clear line between fas files which are extensions
to CLISP and those which are independent work.
> OTOH it seems clear beyond doubt that a clisp saved-image (dump) --
> which incorporates a large amount of implementation-code -- would be
> considered a derived work under the GPL, thus bringing your whole
> application under the GPL.
The GPL does not have means to measure an "amount". Even if a your custom
memory image dump is 1000 times bigger than clisp's 1-meg lispinit.mem file,
it is covered by GPL and you have to follow the second paragraph of the
note. The purpose of this restriction is, that the end user be able to
modify the CLISP on which your application is built.
Bruno http://clisp.cons.org/~haible/
----------------------------------------------------------------------------
Bruno Haible email: <······@ilog.fr>
ILOG S.A. tel: +33 1 4908 3585
9, rue de Verdun - BP 85 fax: +33 1 4908 3510
94253 Gentilly Cedex url: http://www.ilog.fr/
France running Sparc-Linux-BSD-GNU-X11-KDE
······@clisp.cons.org (Bruno Haible) writes:
[clarifications of CLISP's interpretation of the GPL omitted]
> > OTOH it seems clear beyond doubt that a clisp saved-image (dump) --
> > which incorporates a large amount of implementation-code -- would be
> > considered a derived work under the GPL, thus bringing your whole
> > application under the GPL.
>
> The GPL does not have means to measure an "amount". Even if a your custom
> memory image dump is 1000 times bigger than clisp's 1-meg lispinit.mem file,
> it is covered by GPL and you have to follow the second paragraph of the
> note. The purpose of this restriction is, that the end user be able to
> modify the CLISP on which your application is built.
ACK. I only mentioned the fact that a dump incorporates a large
amount, to visualize the "fairness" of this. For all legal purposes
the amount incorporated does not matter (see the discussion of bison's
parser skeleton, which is probably tiny compared to most serious
programs, yet when it was GPLed, incorporation would infect the whole
program. Thus it was changed to be PD, to avoid this).
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]