The next step

[Manuel M. T. Chakravarty]

"Simon Marlow" <simonmar@microsoft.com> wrote,

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