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