[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] CLISP and independent works [was Re: GCL compliance and Bill

From: Adam Warner
Subject: [Gcl-devel] CLISP and independent works [was Re: GCL compliance and Bill Schelter]
Date: 26 Jul 2003 11:16:28 +1200

On Sat, 2003-07-26 at 01:29, Sam Steingold wrote:
> > * In message <address@hidden>
> > * On the subject of "Re: [Maxima] Re: GCL compliance and Bill Schelter"
> > * Sent on 26 Jul 2003 00:16:50 +1200
> > * Honorable Adam Warner <address@hidden> writes:
> >
> > On Fri, 2003-07-25 at 20:33, Nicolas Neuss wrote:
> > > 
> > > Hmm.  What about interfacing via CLOCC?  By this reasoning, CLOCC
> > > has to be GPLed because it accesses internal symbols for CLISP.
> > > What about programs using CLOCC then?
> > 
> > As CLISP's copyright states, to be an independent work a program must
> > "only reference external symbols in CLISP's public packages (namely
> the crucial part is the next phrase you omitted:
> "i.e. if they don't rely on CLISP internals and would as well run in any
>  other Common Lisp implementation."
> the idea is that any application that does not _require_ CLISP to run
> is _not_ infected by CLISP GPL.

While it is nice to have such an optimistic interpretation in writing
could you please fix the licence so that it doesn't read completely

Note the word AND in the phrase I omitted and you quoted. To be an
independent work:
(a) the code must not rely on CLISP internals (i.e. the code only
references external symbols in CLISP's public packages (namely the
(b) "would as well run in any other Common Lisp implementation."

Obviously you shouldn't be needing to explain this contradiction to me
where you do not fulfil one of the criteria for an independent work upon
a plain reading of the COPYRIGHT file.

It appears you intend an OR (AND/OR is less ambiguous for legalese),
i.e. code only accesses the external symbols in public packages AND/OR
is written as a cross-platform portability kit.

The COPYRIGHT file also needs this clarification with an OR so that
one's code that only includes references to CLISP EXT symbols gets
classification as an independent work. The reason is that any reference
in code to EXT:GETENV, etc. certainly does not run as well "in any other
Common Lisp implementation."

And this raises another point. Your CLOCC code will not be an
independent work whenever a Common Lisp implementation exists that it
does not run in. "any other Common Lisp implementation" is too strict a
criteria (I'd suggest the phrase you used in explaining the licence to
me, i.e. the code is written as a cross-platform portability kit. And
that requires it to only run on two or more Common Lisp implementations,
not all. Would you claim that these early snippets of code I wrote are
not independent works:
<https://macrology.co.nz/lisp/cross-implementation.html>, since they
only work on CLISP and CMUCL?)

> CLOCC/PORT is, in fact, a cross-platform portability kit which runs
> under CLISP, CMUCL, ACL, LW (and soon GCL - as soon as they fix 

Then it also doesn't fulfil the criteria that it "would as well run in
any other Common Lisp implementation."

>   Therefore it is not covered by GNU GPL (but by GNU LGPL
> with Franz clarification).  I.e., it does _not_ infect software that
> uses CLOCC/PORT with GNU LGPL.
> Another example: FFI is not mentioned in the list of "public packages".
> This means that if you use CLISP FFI, you are under GNU GPL.
> Suppose UFFI (Unified FFI which supports CMUCL, LW, ACL and probably
> some others) is ported to CLISP FFI.
> Then UFFI is not affected by CLISP GPL and programs that use CLISP FFI
> via UFFI are not affected either.

So the UFFI authors could ignore the fact they are accessing internal
symbols simply because they are writing a program classified as a
portability kit? You need to include a definition of what type of
program is a portability kit. I have already noted that "would as well
run in any other Common Lisp implementation" is too strict a criteria.
Furthermore whether a program complies depends upon the number of Common
Lisp implementations that exist at any point in time. A code's status
could change over time (if there were 10 new Common Lisp implementations
tomorrow would your code comply?)

> >   #+clisp (sys::getenv (string var))
> >            ^^^^^
> > 
> > This however is almost certainly an oversight. GETENV is also exported
> > as part of the EXT package.
> which is not exported in CLISP - and probably won't be.

To really fix this up you should consider striking the portability kit
test completely and simply export those symbols to the public interfaces
that are intended for use by end users or for use in any cross-platform
portability kit.

> nevertheless, as explained above, since CLOCC/PORT runs under many CL
> implementations and does not _require_ CLISP, it is _not_ infected by

I suspect your redefinition in the paragraph above was unconscious. Are
you claiming the legal interpretation of "run in any other Common Lisp
implementation" is "run in many Common Lisp implementations".

> > I have CCed Sam Steingold so he can consider fixing this.
> I read both maxima and gcl-devel on gmane, so I got to read your
> message 3 times.  Thanks.

I have set the Reply-To to clisp-devel. And a one time BCC to you and
Bruno Haible. clisp-devel seems the appropriate place if there is any
further CLISP licensing discussion.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]