gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: GCL compliance and Bill Schelter


From: Adam Warner
Subject: [Gcl-devel] Re: GCL compliance and Bill Schelter
Date: Fri, 01 Aug 2003 13:36:39 +1200
User-agent: Pan/0.14.0 (I'm Being Nibbled to Death by Cats!)

Hi Bruno Haible,

> Sam Steingold wrote:
>>>As CLISP's copyright states, to be an independent work a program must
>>>"only reference external symbols in CLISP's public packages (namely the
>>>packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, EXT) ..."
>> 
>> 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.
> 
> That's nearly the idea. But the phrase is: "... would as well run in
> _any_ other Common Lisp implementation", not "... would as well run in
> _some_ other Common Lisp implementation". So the idea is that
> applications that are written in _portable_ Common Lisp are treated as
> independent work.

So programs that merely access exported symbols in the public packages but
are not "written in _portable_ Common Lisp" (i.e. their execution depends
upon calling CLISP-specific functionality from the EXT package) are not
treated as independent works?

[Perhaps it depends upon the open question as to what extent dynamic
linking can create a derivative work, which is a matter of general GPL
interpretation]

>> 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
>> DEFPACKAGE &c).  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.
> 
> I agree here. clocc/src/port/sys.lisp supports so many CL
> implementations that for practical purposes it meets the "in _any_ other
> Common Lisp implementation" clause.

So try answering a harder question. Is this an independent work and if so
what allows you to reach such a conclusion:
https://macrology.co.nz/lisp/cross-implementation.html

Does it for practical purposes meet an "in _any_ other Common Lisp
implementation" test?

How much more code has to be written before this code could be defined as
an independent work under your licence? Would the CLOCC code comply if it
was only half finished?

>> What's worse, VARIABLE-SPECIAL-P relies on SYS::SPECIAL-VARIABLE-P
>> which is not exported in CLISP - and probably won't be.
> 
> Nevertheless, the aim being to extend the limits of portability (not to
> hijack CLISP internals), this doesn't bring CLOCC's sys.lisp under GPL.

In the event that you classify the above code as an independent work say I
also rely on SYS::SPECIAL-VARIABLE-P but the code is still only portable
between CLISP and CMUCL. Would the code remain an independent work?

I'd appreciate knowing if you believe I'm breaching your licensing
conditions Bruno by claiming that I have released some public domain code
when it could be GPL encumbered. I have also released code with a GPL
exception that only references public symbols but is not portable. I
cannot grant any exception if the code is not an independent work.

While some of the code could be rewritten to access a portability kit
consider how onerous this may be. To portably abstract EXT:MAKE-ENCODING I
would have to add, at a minimum, Unicode and UTF-8 encoding and decoding
support to CMUCL.

Regards,
Adam





reply via email to

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