Thinking about what's missing in our library coverage
Simon Marlow
marlowsd at gmail.com
Wed Aug 5 04:13:06 EDT 2009
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
More information about the Libraries
mailing list