> "Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> 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
