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? ;-)
not since 1988 :)
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.
I agree with what you're saying, but with cross-module optimisation turned on in GHC, virtually any non-trivial change to the implementation of a module causes a change in the .hi file. So *unless* you turn off cross-module optimisation between the application and the library, you have vitually no hope of ever successfully re-linking the application with a modified version of the library. That would be in violation of the license, no?
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.
True, but we don't have any way to enforce or check this. The problem I have is that the restriction is vague and arbitrary, and it doesn't apply in a direct way to the way we compile Haskell. It's not clear to me whether we violate the restriction or not, so I wouldn't feel comfortable about using the license in its present form.
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.
IANAL, but isn't the unfolding a "derived work", so including the unfoldings in an application would make the application a "combined work" - the "ten lines or less" clause is an exception to this rule, when the work is derived from ten lines or less of source code.
If you are really concerned about this one, I think, we should ask the FSF for clarification.
Yes I'm concerned, and yes I think clarification would help.
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
Making proprietary changes to GHC is allowed. Linking a non-free app to LGPL libs is allowed. Doing *both* is not - this is an unexpected, and IMHO unwanted, interaction.
* 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 still believe the cross-module inlining problem is serious - at the least, it requires you to compile LGPL libs in a different way and lose some performance (but only if you're making a non-free app that you want to distribute, I suppose). I'd be much happier with the license if it didn't have this requirement that you have to be able to re-link an application with a modified version of the library. At least the license should be worded in such a way that it can be applied to Haskell without any ambiguity.
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.
This is a point on which we appear to differ, but that's another discussion... Oh well, back to making libraries. Cheers, Simon