Thinking about what's missing in our library coverage
dons at galois.com
Tue Aug 4 18:05:23 EDT 2009
> Don Stewart wrote:
>>>> 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
>> 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,
I've not yet seen anyone publish something on how to satisfy LGPL
for Haskell libraries.
More information about the Libraries