The next step

[Simon Marlow]

> "Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:
>=20
> > 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.
>=20
> 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?
>=20
> 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.
 =20
  - 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). =20

  - 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