Thinking about what's missing in our library coverage
marlowsd at gmail.com
Wed Aug 5 04:58:36 EDT 2009
On 04/08/2009 23:05, Don Stewart wrote:
>> 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.
I support the idea of having a separate LGPL platform. Furthermore, we
should strive to ensure that the BSD-only part of the platform covers
all the core functionality. I don't think that will be too much of a
burden, except in the case of a GUI lib where we'll be restricted to GLUT.
More information about the Libraries