Status of GHC runtime dependency on GNU multi precision arithmetic library
Hi, I know this is a sensitive issue and I absolutely don't want to start any kind of discussion about the merits or otherwise of LGPL, but I was wondering if there are any plans to remove the GNU mp library from the runtime so that it would be possible to distribute native executables compiled with GHC without having to deal with the additional issues raised by the current inclusion of this LGPL component in the runtime. (Afaik everything else in ghc is under a BSD3 license.) It's less of an issue on Linux where libgmp is dynamically linked but when thinking about using Haskell ghc for creating Windows apps it is for me a real problem, because it would mean I'd have to distribute the code for my app as a library along with the code as an executable, thus doubling the download size for my apps as well as having to include a license that has to explain to a possibly non-technical user that although the program includes code that is libre/gratis free the program is not itself free etc etc... Regards, Brian.
On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote:
Hi, I know this is a sensitive issue and I absolutely don't want to start any kind of discussion about the merits or otherwise of LGPL, but I was wondering if there are any plans to remove the GNU mp library from the runtime so that it would be possible to distribute native executables compiled with GHC without having to deal with the additional issues raised by the current inclusion of this LGPL component in the runtime. (Afaik everything else in ghc is under a BSD3 license.)
There is an interest in removing GMP, motivated partly by licensing but also due to portabiltity concerns and the fact that the use of GHC's memory manager in GMP prevents FFI code from using GMP safely. http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
It's less of an issue on Linux where libgmp is dynamically linked but when thinking about using Haskell ghc for creating Windows apps it is for me a real problem, because it would mean I'd have to distribute the code for my app as a library along with the code as an executable, thus doubling the download size for my apps as well as having to include a license that has to explain to a possibly non-technical user that although the program includes code that is libre/gratis free the program is not itself free etc etc...
Huh? AFAIK the LGPL is only an issue for the commercial/proprietary users of Haskell; gratis/libre works would continue to be gratis/libre after linking with GMP. Stefan
From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Stefan O'Rear
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
It's less of an issue on Linux where libgmp is dynamically linked but when thinking about using Haskell ghc for creating Windows apps it is for me a real problem, because it would mean I'd have to distribute the code for my app as a library along with the code as an executable, thus doubling the download size for my apps as well as having to include a license that has to explain to a possibly non-technical user that although the program includes code that is libre/gratis free the program is not itself free etc etc...
Huh? AFAIK the LGPL is only an issue for the commercial/proprietary users of Haskell; gratis/libre works would continue to be gratis/libre after linking with GMP.
I could be wrong, but I believe that Brian's intention is indeed to release a commercial/proprietary app, hence it is possibly an issue for him. I'm not sure about having to distribute the code for his app; I thought the point of the LGPL license was to allow proprietary (non-GPL?) apps to link to LGPL libs. Wouldn't he just have to distribute the code for GMP? But then, I understand less about FSF licensing than pretty much everyone else on this list, so I'll shut up now... Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
On 8/16/07, Bayley, Alistair
I could be wrong, but I believe that Brian's intention is indeed to release a commercial/proprietary app, hence it is possibly an issue for him. I'm not sure about having to distribute the code for his app; I thought the point of the LGPL license was to allow proprietary (non-GPL?) apps to link to LGPL libs. Wouldn't he just have to distribute the code for GMP? But then, I understand less about FSF licensing than pretty much everyone else on this list, so I'll shut up now...
As long as GMP isn't modified, it is not even necessary to distribute the source code. It is only necessary to include the license information as part of the "combined work". (Sect. 4 of LGPL). Furthermore you need to make sure, that a user can replace the LGPL component with another version. Dynamic linking is the easiest way to do this. However, conveying object code that can be relinked statically seems to be OK too. I cannot say that I get the definition of "minimal corresponding code" in the LGPL completely. The essence however seems to be that users must be able to replace the LGPL component with another version. I also understand that it is not necessary to include it directly in your binary distribution, as long as you provide a mechanism through which the necessary material can be obtained (e.g. separate download). The idea is that if there is a bug in GMP but the author of the combined work isn't willing or able to provide an updated version of his app that is built with the fixed version, users must be able to create their own version that uses the fixed GMP version. Cheers, /Lars
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.
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
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: 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.
On Thu, 2007-08-16 at 14:22 +0100, Brian Hulley 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.
From the LGPL v3:
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: [list of stuff you have to do] So it looks like you only have not restrict reverse engineering for the purposes of making updated GMP libs work with your program. Since the MS Runtime components do not interact directly with the GMP at all you shouldn't need to grant users the right to reverse engineer those components. Indeed it's only ghc library and rts code that would interact with gmp.dll. BTW, I don't think it should be too hard to construct a notice that indicates that portions of the work are covered by specific copyright licences, the details of which are available. After all Microsoft have dozens of these notices for various bits of BSD code they use and nobody mistakes Windows for Free software.
Duncan Coutts wrote:
On Thu, 2007-08-16 at 14:22 +0100, Brian Hulley wrote:
.. For example, the LGPL requires you to give permission to people to reverse engineer your application... thus it may not even be possible for me to comply with the terms of the LGPL.
From the LGPL v3:
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: [list of stuff you have to do]
So it looks like you only have not restrict reverse engineering for the purposes of making updated GMP libs work with your program. Since the MS Runtime components do not interact directly with the GMP at all you shouldn't need to grant users the right to reverse engineer those components. Indeed it's only ghc library and rts code that would interact with gmp.dll.
Thanks for suggesting that. It sounds reasonable though I tend to get a bit paranoid when it comes to legal things - will the FSF agree with the above interpretation etc.
BTW, I don't think it should be too hard to construct a notice that indicates that portions of the work are covered by specific copyright licences, the details of which are available. After all Microsoft have dozens of these notices for various bits of BSD code they use and nobody mistakes Windows for Free software.
True, but if there's any chance of just getting rid of the GMP altogether from a version of GHC there would be no tricky issues when it comes to distributing proprietary apps, thus potentially increasing GHC's user base, making Haskell more popular, and hopefully leading to more BSD3 libs being written by those new users... ;-) Best regards, Brian.
| > I know this is a sensitive issue and I absolutely don't want to start any | > kind of discussion about the merits or otherwise of LGPL, but I was | > wondering if there are any plans to remove the GNU mp library from the | > runtime so that it would be possible to distribute native executables | > compiled with GHC without having to deal with the additional issues raised | > by the current inclusion of this LGPL component in the runtime. (Afaik | > everything else in ghc is under a BSD3 license.) | | There is an interest in removing GMP, motivated partly by licensing but | also due to portabiltity concerns and the fact that the use of GHC's | memory manager in GMP prevents FFI code from using GMP safely. | | http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Just to summarise our position at GHC HQ on this question: * We don't much like bundling GMP either. But it works and it's fast. * We'd be very happy to have others work on a replacement (a) using a another C library (b) using a Haskell library * Another alternative (c) to be able to build GHC two ways, - with GMP (fast, but with GMP) - with a Haskell library instead (probably slower but no GMP) Or perhaps arrange that GHC can generate code either assuming GMP or not assuming GMP (i.e. one compiler with a flag). BUT it's fiddly and painful to implement and maintain two paths. * To replace GMP altogether we'd need to be convinced that we would not lose much performance. * There are one or two arbitrary precision libraries in Haskell eg http://www.haskell.org/pipermail/libraries/2007-August/007909.html * Peter Tanksi did quite a lot of work on (a), but we're not sure how far he's got. The Wiki link above is his work. Thanks Peter! * This is a fiddly topic. GMP is connected to GHC in an unusually intimate way (because it allocates in GHC's heap). Care needed. In short, we just don't have the bandwidth to tackle this, but would be happy to help others who would like to. Although fiddly, it's a very clear topic for a project. Simon
On Wed, Aug 22, 2007 at 10:32:36AM +0100, Simon Peyton-Jones wrote:
| There is an interest in removing GMP, motivated partly by licensing but | also due to portabiltity concerns and the fact that the use of GHC's | memory manager in GMP prevents FFI code from using GMP safely. | | http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
Just to summarise our position at GHC HQ on this question:
* We don't much like bundling GMP either. But it works and it's fast. ... * We'd be very happy to have others work on a replacement (a) using a another C library (b) using a Haskell library ... * To replace GMP altogether we'd need to be convinced that we would not lose much performance. ... * There are one or two arbitrary precision libraries in Haskell eg http://www.haskell.org/pipermail/libraries/2007-August/007909.html
Another possibility that occured to me recently, is to switch Integer to a simpler (perhaps even pure-Haskell) representation, and provide (core? extra? Hackage?) a hsgmp package. If you have big numbers, switching is easy: import Prelude hiding(Integer) import Data.Integer.GMP type Integer = MPZ Stefan
Stefan O'Rear wrote:
Another possibility that occured to me recently, is to switch Integer to a simpler (perhaps even pure-Haskell) representation, and provide (core? extra? Hackage?) a hsgmp package. If you have big numbers, switching is easy:
import Prelude hiding(Integer) import Data.Integer.GMP type Integer = MPZ
except that lots of things depend on Prelude.Integer, such as class Num and Integral, potentially a fixed Enum, and who knows what functions that base exports. IMO there needs to be a standard Integer type for library APIs to use (unless making them all class-qualified like (Integral a) => is an acceptable substitute?). This does not fit well with different code using different Integers as they please, especially not if we want it to be likely/possible to be fast. Isaac
Isaac Dupree wrote:
Stefan O'Rear wrote:
Another possibility that occured to me recently, is to switch Integer to a simpler (perhaps even pure-Haskell) representation, and provide (core? extra? Hackage?) a hsgmp package. If you have big numbers, switching is easy:
import Prelude hiding(Integer) import Data.Integer.GMP type Integer = MPZ
except that
you also need to add "default (Integer, Double)" or similar. and Int is rather machine-dependent and "could" be implemented in Haskell, too. I definitely don't want programs using Int instead of Integer just because of Int being more standard and consistent. Isaac
On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote:
I know this is a sensitive issue and I absolutely don't want to start any kind of discussion about the merits or otherwise of LGPL, but I was wondering if there are any plans to remove the GNU mp library from the runtime
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.
(Afaik everything else in ghc is under a BSD3 license.)
Readline isn't, but is already optional, and won't get linked into programs you write unless you actually use it. Thanks Ian
On Wed, 2007-08-15 at 18:41 +0100, Brian Hulley wrote:
Hi, I know this is a sensitive issue and I absolutely don't want to start any kind of discussion about the merits or otherwise of LGPL, but I was wondering if there are any plans to remove the GNU mp library from the runtime so that it would be possible to distribute native executables compiled with GHC without having to deal with the additional issues raised by the current inclusion of this LGPL component in the runtime. (Afaik everything else in ghc is under a BSD3 license.)
It's less of an issue on Linux where libgmp is dynamically linked but when thinking about using Haskell ghc for creating Windows apps it is for me a real problem,
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. Has anyone tried this? Duncan
participants (8)
-
Bayley, Alistair -
Brian Hulley -
Duncan Coutts -
Ian Lynagh -
Isaac Dupree -
Lars Oppermann -
Simon Peyton-Jones -
Stefan O'Rear