RE: The next step

"Manuel M. T. Chakravarty" writes:

...

However, many libraries in the current hslibs and, judging from the discussion so far, many new libraries are not belonging to this core. What is the problem if they are LGPL? LGPL code can be linked into proprietary code without any problems. There is lots of proprietary code being based on code generated by gcc and linked against its C library.

To link your code with LGPL code, you effectively must either provide the user with object files for your code, or arrange for the LGPL code to be contained in a shared library (the actual requirement is that the user be able to modify the LGPL code and obtain a version of your program that uses these modifications). The former option is a significant cost in terms of how annoying it is to distribute your code. I don't know if the latter is even possible -- can all the Haskell implementations create shared libraries?

At any rate, while it is certainly possible to link proprietary code with LGPL code, I wouldn't say that the combination is "without any problems".

Thanks, I wasn't aware of that particular restriction in the LGPL. And having thought about it, I don't think it is reasonable to put libraries under the standard LGPL in Haskell. Here's why: - the license requires that any program linked with the library is provided as object code that can be relinked with a modified version of the library. In order to do this with GHC, you have to compile your application with all cross-module optimisation turned off (although the license does have a cryptic sentence in section 6(a) that sounds like it might apply to this situation, but I don't know what a "definitions file" is). The LGPL also goes into some detail about when a program becomes a derived work by virtue of "including things from header files", in particular it says that inline functions may be "ten lines or less" If we translate this to mean cross-module optimisation, it essentially means that we have to turn off this optimisation or change the license to say something that makes sense for Haskell. - You can't make any local incompatible modifications to GHC and not distribute them, if you intend to link your non-free program with LGPL libs (since you have to be able to recompile modified versions of the libs and re-link to the original program). - Similarly, you can't use a non-free compiler. - You have to be able to compile your modified version of the library. That means the library can't depend on any non-free libraries, which places extra restrictions on what you can do with any BSD licensed libraries you're using, if I'm not mistaken. In a nutshell, the LGPL makes sense when (a) there is a well-defined calling convention between application and library, and (b) compilers are interchangeable. Neither of these is true for Haskell (indeed, they are becoming less true for C and C++ these days). Given these extra restrictions, I imagine that anyone producing a non-free program would have to avoid the LGPL libraries altogether. Cheers, Simon