Thinking about what's missing in our library coverage

[Simon Marlow]

On 04/08/2009 23:02, Magnus Therning wrote:
> Don Stewart wrote:
>> malcolm.wallace:
>>>> As a Haskell Platform user, I really need the assurance that the
>>>> licensing situation is straightforward - especially if I'm to promote
>>>> Haskell at work :-)
>>>>
>>>> My vote would be that non-BSD/MIT license automatically excludes a
>>>> library from inclusion, even though it would exclude my own project.
>>> I wonder if it would be possible to split the Haskell Platform into
>>> two parts, platform-BSD and platform-LGPL? The LGPL packages could
>>> depend on packages from platform-BSD, but not the other way around.
>>> This would guarantee at least one aspect of licence compliance,
>>> whilst also making it clear to proprietary users that if they want to
>>> avoid the guarantee of freedom, they can simply avoid installing
>>> platform-LGPL.
>>>
>>
>> As an aside: are you aware of the problems using LGPL in the context of
>> GHC statically linking libraries by default (in that they degenerate to
>> GPL, or require significant extra workaround).
>>
>> I'm concerned the burden for satisfying the LGPL while GHC statically
>> links Haskell libraries is too great to impose.
>
> AFAIU the burden remains even when GHC supports dynamic linking of
> Haskell libraries. The goal of introducing dynamic lib support is
> sharing of code in system memory, the goal _isn't_ to allow upgrading
> libraries independently of the executables using them.

The latter is a goal, just not one that we'll be achieving right away. 
And indeed LGPL compliance is one good reason to want it.

In order to make a library that supports binary-compatible upgrades, you 
will have to sacrifice some of the cross-module optimisations that GHC 
does.  We plan to first of all make this possible, and secondly to allow 
some explicitly-declared cross-module optimisations to take place.

In GHC 6.12, each installed package will have a unique Id based on its 
visible ABI.  The hash is derived by GHC from the interface files. 
Package dependencies use this hash, so when upgrading a package we can 
detect when the replacement is not binary compatible, and the 
dependencies will be broken (none of this is actually committed yet, but 
I posted the first part on the cabal-devel list for review).

Once we have this working, we can start building support for compiling 
packages with a stable/predictable ABI.

Cheers,
	Simon