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
"Simon Marlow"
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?
If I am not mistaken (anything else wouldn't make much sense), what the license says is that only if the definition files (= .hi) are not changed, can you reasonably expect that re-linking works. This means, in Haskell, you can make very little change to the library. That's bad for the user and good for the vendor of the proprietary code if you like. I am quite sure that's that the interpretation, because otherwise it would mean that I can change a #define in a header of a lib and expect to relink successfully, which clearly can't be. This is something, I would also be happy to ask the FSF about if it helps.
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.
Modulo the question how much Core code corresponds to "10 lines of code", we can control it with -funfolding-creation-threshold. We can ask the FSF about what they exactly mean with 10 lines of code.
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.
It says that you may only inline functions with 10 lines or less. I understand it is merely as a provision against inlining arbitrarily large functions. Exactly the same as GHC threshold to not spit definitions over a certain size into the .hi.
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.
Ok, I'll write them an email, then.
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.
Ok, but it is a pretty rare case. If somebody really wants to do both, the person/company should better not use LGPLed libs.
* 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 think, the current wording is ok, but I agree that a clarification of exactly how it applies to Haskell is desirable. I'll contact the FSF regarding this. As all my Haskell code (except stuff for GHC) is (L)GPL, I want be sure that my interpretation of the license is correct.
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...
Fair enough - would be boring if everybody were of the same opinion ;-) Cheers, Manuel
participants (2)
-
Manuel M. T. Chakravarty -
Simon Marlow