gcl-devel
[Top][All Lists]
Advanced

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

Re: [Maxima] Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656]


From: Camm Maguire
Subject: Re: [Maxima] Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL
Date: 18 Jul 2003 15:18:03 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks for your input! 

I agree that the LGPL would be better, and I think the FSF agrees too
for this application.  The problem appears to be in weighing this
against our need/desire to use readline, bfd, unexec in making GCL a
better product.  In any case, were we to go GPL, I think at the
minimum we would want to use a proprietary code allowing clause along
the lines of clisp.  I'm still not terribly clear on what the
difference is between such a setup and the LGPL.

The goal, here, IMHO, is to make GCL as beneficial to the most number
of people, users and developers, as possible, and of course to advance
the cause of free software lisp.  What that means in practice is again
dependent on an assessment of the current state of the free software
lisp world.  What stands out to me in making this assessment are
chiefly two things, 1) there are a number of high quality alternatives
to GCL available, and 2) there is a comparative dearth of free
programs being written in lisp, and/or a particular comparative
historical bias toward proprietary software in the lisp community.

Point 1) would certainly indicate that the LGPL is better for GCL in a
sense, but if that means that we have to reinvent every wheel with our
limited resources from scratch, then GCL won't measure up to the
competition in any case.  Personally, I think the best chance for long
term GCL survival, and even for the increased usage of lisp in free
software, is to capitalize on GCL's relationship with gcc, and to make
it function optionally as an official common lisp front end to
gcc. This bears on point 2), as thinking of GCL as primarily a lisp
*compiler*, the analogy with gcc would appear to clearly indicate that
one should be able to produce programs with it with the license of the
author's choosing.  gcc appears to be able to do this being licensed
under the GPL.  Perhaps this is a signpost for us.

In any case, I feel we need to hear what the FSF would like to do --
GCL is after all the official common lisp of the FSF.  It appears we
have, as before stated, two broad options (corrections welcome):

1) LGPL when not using readline/bfd.  Depends on permission to use
   unexec from emacs.
2) GPL with clisp and/or gcc text along use as a compiler of
   proprietary programs.

Take care,


"Stavros Macrakis" <address@hidden> writes:

> > How much of an issue is it really if we just place GCL under 
> > the GPL? Do we know of anyone who would be inconvenienced by this?
> 
> Camm,
> 
> Personally, I think LGPL is a better license.  It means I can write
> something and be sure it doesn't get hijacked into a commercial product,
> but doesn't prevent others from building proprietary things that depend
> on it.
> 
> Obviously, FSF disagrees.  The GPL is intended to build a brick wall
> between proprietary and GPL software.  I prefer peaceful cooperation and
> coexistence.
> 
> I find it especially annoying that the GPL prevents you from building
> something *on top of* GCL.  That is, not only would a GCL with a fancier
> GUI-building system be contaminated, but even (as in the previous
> example) a spreadsheet built on top of GCL would be.
> 
>        -s
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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