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