Status of GHC runtime dependency on GNU multi precision arithmetic library

[Brian Hulley]

Stefan O'Rear wrote:
> On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote:
>   
>> ... I was 
>> wondering if there are any plans to remove the GNU mp library from the 
>> runtime
> ... http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
>   
Thanks for the link.
>> ... although the program 
>> includes code that is libre/gratis free the program is not itself free etc 
>> etc...
>>     
>
> Huh? ...

I meant if you are distributing a proprietary program then you have the 
problem of trying to explain to an end-user all the intricacies involved 
with the LGPL without conveying the impression that the whole program is 
free. My impression is that someone who doesn't know anything about 
programming might have a hard time understanding the LGPL correctly.


Ian Lynagh wrote:
> I'll be looking at making it optional once 6.8.1 is out of the way, but
> you will need to use a GHC compiled with an alternative; you won't be
> able to make a non-GMP program with a GMP GHC.
>   
Thanks, that's good news.
Perhaps one option for the non-GMP version of GHC would be to have a 
large integer library written in Haskell itself, since it is useful to 
have large integers even if they are not as fast as those provided by 
GMP (eg when writing a lexer it is useful to have large integers to 
correctly lex integer literals (ie without silently truncating them to 
the capacity of an Int) but speed here is not that important).
To get high speed for stuff in external libs, perhaps some way of 
extending the foreign interface to allow direct access to the Haskell 
heap instead of always having to copy via the C heap, would be useful.


Duncan Coutts wrote:
> Sounds to me like the simlest solution for you would be if GHC could use
> a dynamically linked gmp.dll on Windows. That also sounds like much less
> work that replacing gmp completely.
This would certainly make things easier though it doesn't solve every 
problem. For example, the LGPL requires you to give permission to people 
to reverse engineer your application, in order for them to be able to 
understand it enough to get it to work with an updated version of the 
LGPL component. Although this is perfectly reasonable imho, it leaves me 
with a problem if my application also needs to make use of eg Microsoft 
runtime components or third party proprietary statically linked 
libraries since there are parts of my program binary for which I do not 
have the authority to grant permission to reverse engineer thus it may 
not even be possible for me to comply with the terms of the LGPL.

Of course I am not a lawyer so I may have got this wrong, but since I 
can't possibly afford to hire a lawyer to look into all of this I have 
to play it safe and therefore would prefer to avoid any use of LGPL 
components in a proprietary app.

Thanks also to everyone else who replied,

Brian.