On Mon, 7 Oct 2013 10:54:01 +0200 Juan Jose Garcia-Ripoll <juanjose.garciarip...@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 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
