[Ecls-list] success, was: broken local installation of ecl

Oliver Kullmann O.Kullmann at swansea.ac.uk
Thu Aug 28 20:42:17 UTC 2008


On Thu, Aug 28, 2008 at 09:42:57PM +0200, Juan Jose Garcia-Ripoll wrote:
> On Thu, Aug 28, 2008 at 9:23 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> >> Sorry, but that's nonsense.
> 
> No, it is not. Obviously you know very little about the story of free
> software, lisp and CLISP in particular. The problem with readline is
> real: it is a GPL library, not LGPL. That means any software that
> links with a GPL library has to become GPL itself. ECL on the other
> hand is LGPL, which allows to link it with proprietary software
> including software that is to be sold and closed source.
>

I'm aware of these things (to a certain degree: for my own library I had
and have to consider them); unfortunately, the GPLv2 and GPLv3 are under
heavy influence of US-american law, which makes them, under the influence
of a case-based juristical system, un-intelligible when it comes to
the details (it seems to me that the new European open-source licence
is much clearer) --- nevertheless I think me that these statements
like you cite below are not based on the original intentions (and what
really is written).
 
> >> By using gcc (GPL) or readline or
> >> whatsoever you do not need to take over the GPL, since it's just a tool.
> >> These things are discussed at many places at length, see for example
> >> http://www.softwarefreedom.org/resources/2008/compliance-guide.html.
> >> (Just an example: FreeBSD uses readline.)
> 
> FreeBSD is an operating system and it includes readline in components,
> but editline was born indeed in the NetBSD community to avoid the
> poisoning effect of that license.
>

But the FreeBSD-people have also a *political agenda*.
 
> >> So, please, say what you really mean, and this open on the project
> >> web page: You fight certain forms of open source/ free software, and
> >> thus you will not use some software (don't hide behind fake technical argumentation).
> >> (I'm not arguing here against political decisions: The point is honesty.)
> 
> Come on, do not be cynical. I am not fighting _ANYTHING_ (*). I am
> just trying to let ECL survive in a confusing environment. You as
> individual user may say whatever, but any visum of a legal problem
> scare some people away from certain useful open projects, such as
> CLISP. I do not want that to happen with ECL, where we have seen
> significant improvements coming indeed from non-hobbyists and
> supporting companies
> 

On the one hand, I think freedom needs fight.
And on the other hand it seems really rather clear to me, that even when it comes
to the worst case (which I think is unlikely), then all what needs to happen is 
to remove in this case readline --- nothing more!

But the following seems actually far more important here:

Whatever is "rational" or "irrational" here is very hard to judge, since
we are living in a deeply irrational society.
What one needs to do is to try not to become a slave of all these "undercurrents",
the scars accumulated over the individual and collective history.

But exactly this is what happens here. So I stipulate that these undercurrents
prevent in this case the creation of for example some simple advice in the
documentation: "By the way, the ECL frontend is by itself not able to handle
certain actions one is used from the command line, and to get it, the
following options exist: ...". (We would need (in general) much of such advice,
but one reason that they are not there I believe is the avoidance of pain,
due to the history of violence.)


The causes are always minor (technically the problem at hand seems
to be solved now), but in your first reaction I felt this sub-conscious
pain, to which I reacted, and you then reacted further. (Thus the above
talk of "honesty" is of course in a certain sense ridiculous, but
also half-true.)

I hope we don't need a "flame war" here ;-)

Running Ecl it seems to be quite a bit quicker then clisp, so
I hope furthermore that as a result of these interactions the
ECL build process might become perhaps a bit stronger, while
my applications run faster.

Thanks for your attention!

Oliver





More information about the ecl-devel mailing list