"Simon Marlow" wrote,

...

"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.

I don't agree, because I believe that you mis-read the LGPL.

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).

Never used Modula-2? ;-) If you change a signature or other type in the library you cannot expect that you can re-link. In Haskell this translates to whenever the .hi files changes, you cannot re-link. So, I think, your interpretation is wrong, you don't have to turn all cross-module optimisation off.

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.

Inlining enforced by the compiler is an interesting point. Technically speaking an unfolding in a GHC .hi file is always a single line of code, but that might not save us. Anyway, it is not true that you have to switch inlining off, you only have to set the appropriate value for -funfolding-creation-threshold. By my experience of looking at .hi files, the standard value of -funfolding-creation-threshold restricts unfoldings to a size that should be within this "ten lines or less" limit. However, as the unfoldings are not really verbatim excerpts from the source (but may be heavily changed by optimisations and other inlining), it would be interesting to know whether they really fall under this clause at all. Moreover, they are effectively expressed in another language (namely, Core) and may be regarded as a high-level object code. If you are really concerned about this one, I think, we should ask the FSF for clarification.

- 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).

That's a valid point, due to GHC's structure.

- Similarly, you can't use a non-free compiler.

You can as long as you provide it with the program you are distributing. This may sometimes be a restriction, but it is one generally present with the LGPL if you use non-standard tools to produce your executables.

- 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.

A LGPL library that depends on stuff that is not free is a bit pointless anyway, isn't it. Moreover, I don't see how this is special in Haskell.

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).

I don't understand how you get to this conclusion. From the above, there are two problems: * applications where somebody wants to make proprietary changes to GHC and * maybe automatic cross-module inlining if you want high values of -funfolding-creation-threshold. Both are special - and I believe rare - cases; the second may even not apply at all. I am keen to have companies using Haskell for their development, but I don't think that we have to free them of all obligations to contribute back to the community from which they take. How did the second to last paragraph of http://perens.com/Articles/StandTogether.html say so nicely: We urge Microsoft to go the rest of the way in embracing the Open Source software development paradigm. Stop asking for one-way sharing, and accept the responsibility to share and share alike that comes with the benefits of Open Source. Acknowledge that it is compatible with business. ;-) Cheers, Manuel