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