The next step

Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Fri, 01 Jun 2001 13:05:47 +1000


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

> > "Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:
> > 
> > > However, many libraries in the current hslibs and, judging
> > > from the discussion so far, many new libraries are not
> > > belonging to this core.  What is the problem if they are
> > > LGPL?  LGPL code can be linked into proprietary code without
> > > any problems.  There is lots of proprietary code being based
> > > on code generated by gcc and linked against its C library.
> > 
> > To link your code with LGPL code, you effectively must either provide
> > the user with object files for your code, or arrange for the LGPL code
> > to be contained in a shared library (the actual requirement is that
> > the user be able to modify the LGPL code and obtain a version of your
> > program that uses these modifications).  The former option is a
> > significant cost in terms of how annoying it is to distribute your
> > code.  I don't know if the latter is even possible -- can all the
> > Haskell implementations create shared libraries?
> > 
> > At any rate, while it is certainly possible to link proprietary code
> > with LGPL code, I wouldn't say that the combination is "without any
> > problems".
> 
> Thanks, I wasn't aware of that particular restriction in the LGPL.  And
> having thought about it, I don't think it is reasonable to put libraries
> under the  standard LGPL in Haskell.  

I don't agree, because I believe that you mis-read the LGPL.

> 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? ;-)  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.

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

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.

If you are really concerned about this one, I think, we
should ask the FSF for clarification.

>   - You can't make any local incompatible modifications to GHC and
>     not distribute them, if you intend to link your non-free program
>     with LGPL libs (since you have to be able to recompile modified
>     versions of the libs and re-link to the original program).  

That's a valid point, due to GHC's structure.

>   - Similarly, you can't use a non-free compiler.

You can as long as you provide it with the program you are
distributing.  This may sometimes be a restriction, but it
is one generally present with the LGPL if you use
non-standard tools to produce your executables.  

>   - You have to be able to compile your modified version of the
>     library. That means the library can't depend on any non-free
>     libraries, which places extra restrictions on what you can do with
>     any BSD licensed libraries you're using, if I'm not mistaken.

A LGPL library that depends on stuff that is not free is a
bit pointless anyway, isn't it.  Moreover, I don't see how
this is special in Haskell.

> 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
* 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 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.  How did the second to last paragraph of
<http://perens.com/Articles/StandTogether.html> say so
nicely:

  We urge Microsoft to go the rest of the way in embracing
  the Open Source software development paradigm. Stop asking
  for one-way sharing, and accept the responsibility to
  share and share alike that comes with the benefits of Open
  Source. Acknowledge that it is compatible with business.

;-)

Cheers,
Manuel