Thinking about what's missing in our library coverage

[Don Stewart]

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

I would appreciate input from the HaXml and HDBC authors (our most
popular LGPL-licensed Haskell libraries) about what they feel the 
licensing issues/constraints should be for the Haskell Platform.

Here for example, is how we satisfy LGPL with the C library GMP, which
is often statically linked,

    http://haskell.forkio.com/gmpwindows

I've not yet seen anyone publish something on how to satisfy LGPL
for Haskell libraries.

-- Don