[Ecls-list] Project status and changes (please read)

Matthew Mondor mm_lists at pulsar-zone.net
Thu Oct 10 21:51:14 UTC 2013


On Mon, 7 Oct 2013 10:54:01 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> * The consequence is that the time I can devote to ECL has serious ups and
> downs. In an environment of rapidly developing tools and libraries, this is
> quite unfortunate, as the project may lag behind and become obsolete. This
> is indeed what has happened with several of the ports out there.

It was indeed my impression that this would eventually occur.  I'm very
sorry about this, although it did seem inevitable someday...  I want to
thank you for the work you could do on ECL so far.

> * *I am resigning and opening the position of ECL maintainer for anyone to
> take*. I will grant him or her with full administrative rights and full
> responsibility over the project's future. No need to fork the project: if
> you really feel you can make it better, step ahead and take it. I will
> remain as a support developer and help you as much as I can.

I love the project, but unfortunately doubt in my time and
qualifications to lead it.  I can from time to time suggest changes and
provide diffs, and for now am still an active user of ECL (my web site
is hosted on it among others), and will keep contributing to this
mailing list unless it completely dies.

> * I am not going to change ECL's license. LGPL3's restrictions on web
> applications seem stupid to me and, as experience has shown, making such a
> move will only make things worse. Already LGPL2 is a hindrance, but I can
> live with it.

This is something I'd like to understand better: what restrictions does
LGPL3 add on network services?  Does it have to do with the fact that
web applications disclose source, versus my example of using a web
server compiled using ECL?

Some here might already know my preference for MIT/BSD licenses, but in
this case even if ECL was relicensed I don't see how it could solve the
dependency on LGPL3 GMP/MPIR anyway...

> * This said, GMP v5 is insufficient for several platforms but I will
> maintain it as it is. *On platforms where GMP becomes obsolete, it will
> shift to building with "C"* (i.e. no optimized assembly code). I tested
> this on Cygwin/64 and it works -- *indeed it is part of the source tree
> right now*. If you need a better GMP, build ECL with the one that your
> operating system provides and be tied to its license.

This seems like a good compromise to me.
-- 
Matt




More information about the ecl-devel mailing list