The next step

[Simon Marlow]

> > Here's why:
> >=20
> >   - 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=20
> situation,
> >     but I don't know what a "definitions file" is).
>=20
> 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.
>=20
> 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=20
> header files",
> >     in particular it says that inline functions may be "ten lines or
> >     less"  If we translate this to mean cross-module=20
> optimisation, it
> >     essentially means that we have to turn off this optimisation or
> >     change the license to say something that makes sense=20
> for Haskell.
>=20
> 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.
>=20
> Anyway, it is not true that you have to switch inlining off,
> you only have to set the appropriate value for
> -funfolding-creation-threshold.
>=20
> 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)=20
> compilers
> > are interchangeable.  Neither of these is true for Haskell=20
> (indeed, they
> > are becoming less true for C and C++ these days).
>=20
> I don't understand how you get to this conclusion.  From the
> above, there are two problems:
>=20
> * 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.
>=20
> 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. =20

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