Re: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B)

Dear Gershom / GHC development team,
The provided windows version of GHC contains lib-gmp.
Hence, this version enforces a LGPL license on my code
(see e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes for more info) .
Unfortunately, this license is unacceptable for me.
For me this raises the question: What is the strategy of GHC with respect to licensing?
In particularly,
* Why considers GHC a LGPL license for all the code developed by their users acceptable?
* Is GHC considering to allow their user to standardly develop their code under a license of their own choice?
* Are there plans to offer the GHC users an opportunity to choose the license in the near future?
e.g. by distributing GHC binary distributions with integer-gmp and integer-simple.
Thanks in advance for your answers,
Pierre van de Laar
---------------------------------------------------------------------
Date: Wed, 8 May 2019 16:28:21 -0400
From: Gershom B

Am 14.05.19 um 09:05 schrieb Pierre_van_der_Laar (Functional Account) via Haskell-Cafe:
Dear Gershom / GHC development team,
The provided windows version of GHC contains lib-gmp. Hence, this version enforces a LGPL license on my code (see e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes for more info) . Unfortunately, this license is unacceptable for me.
What is making the LGPL inacceptable for you? The usual understanding of the LGPL enforces the LGPL license only on the lib-gmp code itself and any modifications you make to it, not on any other parts of the code. Regards, Jo

Hi Joachim, On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote:
The usual understanding of the LGPL enforces the LGPL license only on the lib-gmp code itself and any modifications you make to it, not on any other parts of the code.
if you follow the LGPL strictly - which I think almost nobody does - you also have to provide a development kit for you application, that users can relink your application with newer versions of the lib-gmp. Greetings, Daniel

On Tue, May 14, 2019 at 05:21:09PM +0200, Daniel Trstenjak wrote:
if you follow the LGPL strictly - which I think almost nobody does - you also have to provide a development kit for you application, that users can relink your application with newer versions of the lib-gmp.
I should have added, that you should be fine - no need for a development kit - as long as you don't statically link the lib-gmp. Greetings, Daniel

Am 14.05.19 um 17:21 schrieb Daniel Trstenjak:
Hi Joachim,
On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote:
The usual understanding of the LGPL enforces the LGPL license only on the lib-gmp code itself and any modifications you make to it, not on any other parts of the code.
if you follow the LGPL strictly - which I think almost nobody does - you also have to provide a development kit for you application, that users can relink your application with newer versions of the lib-gmp.
Mmm... sort-of. You have to make sure that people can take lib-gmp, change it, and relink your application with it. A reference to a standard build environment should be enough to fulfil that requirement, though it can become a bit more difficult if you have packaging steps after linking.

Most of the builds use a system or packaged libgmp of some variety, so it's
not even bundled with ghc. (This includes Windows builds, using the package
from msys2.)
On Tue, May 14, 2019 at 2:42 PM Joachim Durchholz
Hi Joachim,
On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote:
The usual understanding of the LGPL enforces the LGPL license only on
Am 14.05.19 um 17:21 schrieb Daniel Trstenjak: the
lib-gmp code itself and any modifications you make to it, not on any other parts of the code.
if you follow the LGPL strictly - which I think almost nobody does - you also have to provide a development kit for you application, that users can relink your application with newer versions of the lib-gmp.
Mmm... sort-of. You have to make sure that people can take lib-gmp, change it, and relink your application with it. A reference to a standard build environment should be enough to fulfil that requirement, though it can become a bit more difficult if you have packaging steps after linking. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh allbery.b@gmail.com

Most of the builds use a system or packaged libgmp of some variety, so it's not even bundled with ghc. (This includes Windows builds, using the package from msys2.)
Windows uses a statistically linked gmp built from source during the ghc
bootstrap. It does not use libgmp from msys2.
The difficulty here is that Haskell programs should work regardless of if
you're running in msys2 or not. Compared to other languages that are
dynamically linked ghc has no "runtime libraries". You'd have to ship
libgmp with every application you make.
On Tue, May 14, 2019, 19:47 Brandon Allbery
Most of the builds use a system or packaged libgmp of some variety, so it's not even bundled with ghc. (This includes Windows builds, using the package from msys2.)
On Tue, May 14, 2019 at 2:42 PM Joachim Durchholz
wrote: Hi Joachim,
On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote:
The usual understanding of the LGPL enforces the LGPL license only on
Am 14.05.19 um 17:21 schrieb Daniel Trstenjak: the
lib-gmp code itself and any modifications you make to it, not on any other parts of the code.
if you follow the LGPL strictly - which I think almost nobody does - you also have to provide a development kit for you application, that users can relink your application with newer versions of the lib-gmp.
Mmm... sort-of. You have to make sure that people can take lib-gmp, change it, and relink your application with it. A reference to a standard build environment should be enough to fulfil that requirement, though it can become a bit more difficult if you have packaging steps after linking. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

The provided windows version of GHC contains lib-gmp. Hence, this version enforces a LGPL license on my code
I think you're confusing the GPL and the LGPL here. Otherwise, please clarify what you mean by "enforces a LGPL license on my code". Stefan

Hello Pierre, On 21/05/2019 11:54 AM, Pierre_van_der_Laar (Functional Account) via Haskell-Cafe wrote:
Whenever a program is compiled with GHC and is distributed on another platform than OS X, anybody can claim that the source code of that program must be provided due to the LGPL license, since integer-gmp, the ghc code, and that program's code are statically linked!
Some facts on Linux: libgmp code is *not* typically statically linked into executables created with GHC. Consider this hello-world program built with `ghc --make`: % ldd Hello linux-vdso.so.1 => (0x00007ffe1d1ad000) ... libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f710fe3e000) As you can see, this program is dynamically linked against my system libgmp.so. As an end user of this program I can compile my own libgmp and make the program use that instead. Only if you pass flags to GHC to indicate that you want libgmp linked statically will it do so. In that static-linking case, you need to ensure that your program, when distributed, satisfies the requirements that gmp's LGPL has on being linked statically. For the cases where you do not want to use libgmp at all, you can use * integer-simple * integer-openssl (upcoming, see https://github.com/ch1bo/integer-openssl/issues/3) Hope this helps, Niklas
participants (7)
-
Brandon Allbery
-
Daniel Trstenjak
-
Joachim Durchholz
-
Niklas Hambüchen
-
Phyx
-
Pierre_van_der_Laar (Functional Account)
-
Stefan Monnier