LGPL licensing restrictions on Windows because of integer-gmp

[quyse]

Default version of GHC on Windows produces binaries with integer-gmp linked statically. As integer-gmp's license is LGPL, it means that resulting binaries should be provided with source code or object files. I guess that's not a thing everyone would want.

On UNIXes integer-gmp is linked dynamically, so these restrictions don't apply.

So, in order to fix that we can either:

• Provide a version of GHC which builds Windows executables with integer-gmp linked dynamically (haven't tried, but seems like it's possible).
• Provide a version of GHC with integer-simple wired in instead of integer-gmp (some packages have problems, but overall works good for me).
• Or at least write a big red warning on stack's homepage that your Haskell software on Windows has to be essentially a free software.

Additional Links:
ReplacingGMPNotes

UPDATE:

• More up-to-date link: Design/IntegerGmp2
• Clarification, just to avoid confusion: license of integer-gmp (the Haskell library) is BSD3, but it uses C library The GNU Multiple Precision Arithmetic Library which is LGPL.

[vyp]

Might help: http://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-11100011.5

N.B. Have no idea if that website/document can be considered legal advice.

[andrewthad]

I would love it if there was a way to use integer-simple with stackage. As a warning, blaze-textual, which is supported by stackage, has a very long standing issue that prevents it from working with integer-simple (and this library is used by postgres-simple, which is used by a lot of people). If stackage were to start supporting integer-simple GHC builds, some packages would have to get patched first.

[snoyberg]

I don't think a big red warning is the right answer, but having this well documented in the FAQ seems reasonable. I would love to get rid of the LGPL code entirely, but as @andrewthad points out, there's no real chance of being able to do that right now.

@quyse Would you be able to add a FAQ entry for this?

[kantp]

Having the option of using integer-simple (without compiling ghc oneself) for those projects that do not rely on integer-gmp would be a nice convenience, and greatly appreciated.

[snoyberg]

I have no objection to adding such support. Would someone be able to build
Windows bindists for that?

On Thu, Jun 25, 2015, 9:40 AM Philipp notifications@github.com wrote:

Having the option of using integer-simple (without compiling ghc oneself)
for those projects that do not rely on integer-gmp would be a nice
convenience, and greatly appreciated.

—
Reply to this email directly or view it on GitHub
#399 (comment)
.

[kantp]

I guess if I want the feature, it's only fair if I provide the windows binaries :-)

Which versions of ghc does stack support? 7.8.4 onwards, or also earlier?

[snoyberg]

It theoretically supports any version requested by the user, but 7.8.4 and
on is probably what people care about.

On Thu, Jun 25, 2015, 12:26 PM Philipp notifications@github.com wrote:

I guess if I want the feature, it's only fair if I provide the windows
binaries :-)

Which versions of ghc does stack support? 7.8.4 onwards, or also earlier?

—
Reply to this email directly or view it on GitHub
#399 (comment)
.

[quyse]

@snoyberg I've added a short entry to the FAQ pointing to this issue.

By the way, I was thinking it's Windows-only limitation, as I've checked that on Linux GMP is linked dynamically. But now I found this comment which made me worried about OS X. I don't work with OS X, does anyone know about the situation there?

[snoyberg]

@quyse Thanks!

[snoyberg]

@kantp Has provided the following GHC bindists:

• https://s3-eu-west-1.amazonaws.com/ghc-integer-simple/ghc-7.8.4-x86_64-unknown-mingw32.tar.bz2
• https://s3-eu-west-1.amazonaws.com/ghc-integer-simple/ghc-7.10.1-x86_64-unknown-mingw32.tar.bz2

My thought is that we would add a new command line option that- like --arch- would control which GHC to use. Either that, or have a fake OS of windowsnolgpl or something like that. What would help with getting this moving is if others could test out these bindists and report results.

[quyse]

@snoyberg @kantp That's great, thanks for getting back so quickly! I just tested your GHC (only 7.10.1 for the moment), and I was able to build and run my project which uses about 30 packages, and I wasn't able to build my another project because of issue with network. Quick notes:

• Three packages in my experiment required special care, those are cryptonite, hashable and text. They all have configure flags to disable use of integer-gmp. hashable also has a fix on its github which isn't uploaded to hackage yet, so I had to put it locally. Here is excerpt of stack.yaml worked for me:

resolver: nightly-2015-06-23
arch: x86_64
extra-deps: ['cryptonite-0.5', 'hashable-1.2.3.2', 'text-1.2.1.1']
flags:
  cryptonite:
    'integer-gmp': false
  hashable:
    'integer-gmp': false
  text:
    'integer-simple': true
packages:
- '../../thirdparty/tibbe-hashable'

• I wasn't able to use network package because of well-known issue with it:

Configuring network-2.6.2.0...
Setup.hs: The package has a './configure' script. This requires a Unix
compatibility toolchain such as MinGW+MSYS or Cygwin.

Usually I workaround this by using cabal install network --configure-option --build=x86_64-w64-mingw32 in Cygwin, but this time it doesn't work, as there's no cabal, and I wasn't able to construct some similar command line with stack instead of cabal, getting the same error. The strange thing is that with default GHC-7.10.1 downloaded by stack setup it installs network without any trouble (and without using Cygwin). I was setting up custom GHC by just placing it in PATH:

set PATH=D:\programs\ghc-7.10.1\bin;D:\programs\ghc-7.10.1\mingw\bin;D:\programs\ghc-7.10.1\mingw\x86_64-w64-mingw32\bin;D:\programs\ghc-7.10.1\mingw\libexec\gcc\x86_64-w64-mingw32\4.6.3;

Am I missing something?

[snoyberg]

stack typically solves this by including PortableGit's msys implementation on the PATH, which will allow configure scripts to run. Can you try adding that and trying again?

[3noch]

Would it make sense to add a custom "arch" or "os" for GHC's built with no gmp-integer? You could minimally support the last two GHC versions on whatever OS you have a build for. In other words, could you add an "os" that's "windows-no-gmp" for the time being? Or perhaps add it to the arch? That would basically make stack the single best way to get a commercial-haskell GHC.

[3noch]

Just realized you already had that idea. I'm all for it, or something like it.

[3noch]

If I can get builds working, I'll supply as many builds for Windows as my machine can crank out. This applies to MinGHC too.

[hvr]

Minor note:

https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes is kinda obsolete as the GMP library was rewritten from scratch for GHC 7.10 (https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2),

Personally, I'd like to get rid of integer-simple altogether (to avoid having different surface APIs, and avoid all that conditional CPP/cabal-flag mess we have right now), and rather be able to select the integer-gmp backend at link-time in the same way you can switch between e.g. the threaded and the non-threaded runtime. Therefore allow you to say e.g. ghc --make -O -finteger-library=bsdnt Hello.hs and then not link the GMP into your binary, but rather e.g. a bsdnt based implementation of the integer-gmp primitives. It's not difficult to implement... but as usual time is a scarce resource :-/

/cc @thoughtpolice

[kantp]

@hvr That sounds like the Right Thing to do, very nice.

In the meantime, if there is a switch for the integer library, I think it would make sense to have this orthogonal to the choice of the operating system.

[3noch]

@quyse hashable was just updated, now for a stackage release including it.

[3noch]

@snoyberg... Wow. You don't miss a beat. Stackage part already being done

[snoyberg]

I can't take credit, it's just the daily Stackage builds doing their thing.

IIUC, this means that the LGPL concern will not apply to the normal GHC bindist in the near future. Is that the case? I should probably say that IANAL, so some of this goes over my head. Perhaps we can have a thread on ghc-dev about this, I'd definitely like to understand this better and understand what work still needs to be done.

[hvr]

@snoyberg feel free to start a thread, I'll chime in and try to answer as best as I can any questions you put forward

[akhra]

Hackage says the license is BSD3, and it says so for both versions...

[quyse]

@tejon Sorry, I just added an update to the first post with clarification about integer-gmp and GMP. I was using names integer-gmp and GMP interchangeably.

[quyse]

@snoyberg Yes, finally I was able to install network from MSYS command line, thanks for help! For me everything works now. As a side note, maybe it's worth to implement --with-compiler setting similar to cabal's? It would be more convenient to use non-standard compiler rather than manually adding it to PATH, and stack would treat it in the same way as automatically installed ones, i.e. add msys and stuff.

@3noch Cool, that's fast :)

[3noch]

So all we need to do is not link in integer-gmp? No special build of GHC required?

[3noch]

@tejon I think I'm beginning to see it from your perspective. If that's the case, then this could be really good news for folks like me, except for the points brought up by @mwu-tow and @ezyang.

[Jookia]

The section says this:

0. Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

I think this is clear that that's the case.

[snoyberg]

Given the work on alternative bindists, should this be closed?

[rvion]

would ghc-musl make a better bindist default ?

[snoyberg]

I don't think so:

• It's much less tested than standard GHC
• I don't think it works at all on Windows
• Static linking would just make the specific problem being discussed (LGPL libraries being linked in) even worse

[rvion]

Thanks for those infos
(not sure about the 3rd point: musl seems to be able to dynamic link anything just fine)

[snoyberg]

No objection given to my question about closing.

[varosi]

stack build --os windowsintegersimple

Did not find .cabal file for stack-1.1.2 with Git SHA of 78d31fa4367593f8408ac142d2c3b40da54c247b
Right Nothing
Did not find .cabal file for opaleye-0.4.2.0 with Git SHA of bd719541cfb6d6eefe00172d228bb3331c73704b
Right Nothing
Did not find .cabal file for irc-dcc-1.2.1 with Git SHA of 34ed39699e28cadbdcec2601622b39198dbffabc
Right Nothing
No compiler found, expected minor version match with ghc-7.10.3 (x86_64) (based on resolver setting in ...\stack.yaml).
Try running "stack setup" to install the correct GHC into C:\stack\programs\x86_64-windowsintegersimple\

stack setup --os windowsintegersimple
I don't know how to install GHC for (OtherOS "windowsintegersimple",X86_64), please install manually

How it should be used with stack 1.1.2?

[borsboom]

@varosi: Don't have a Windows box available right now to try it, but it should be

stack setup --ghc-variant=integersimple

[varosi]

@borsboom, I have got this:

Downloaded lts-6.4 build plan.
Fetching package index ...remote: Counting objects: 1590, done.
remote: Compressing objects: 100% (1192/1192), done.
rRemote: Total 1590 (delta 403), reused 1427 (delta 365), pack-reused 0
Receiving objects: 100% (1590/1590), 500.58 KiB | 330.00 KiB/s, done.
Resolving deltas: 100% (403/403), completed with 199 local objects.
From https://github.com/commercialhaskell/all-cabal-hashes

• [tag update] current-hackage -> current-hackage
  Fetched package index.
  Populated index cache.
  No information found for ghc-7.10.3.
  Supported versions for OS key 'windows64-integersimple': GhcVersion 7.8.4, GhcVersion 7.10.1, GhcVersion 7.10.2

[borsboom]

Looks like @kantp provided the past integer-simple bindists, but we have not received any yet for GHC 7.10.3 or GHC 8.0.1.

[3noch]

I provided the bindists for 7.10.2, but unfortunately I no longer work with Windows and don't have access to my build machines.

[borsboom]

@3noch: Ah sorry, I missed that in reading the history of this issue. Do you happen to have the process to create them documented anywhere?

In any case, we'll be happy to add the metadata for 7.10.3 and 8.0.1 windows-integersimple bindists when we're provided with them (and, you can always add setup-info to your own config for custom bindists).

[3noch]

@borsboom: I followed the instructions on the GHC wiki (https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows) without too much trouble. Changing out the configuration to use integer-simple is not hard, but I don't recall the details. Hopping on to the GHC devs mailing list (I think they have an IRC channel too IIRC). For 32-bit bindists I literally fired up a 32-bit Windows VM, but that might be unnecessary.

[dtaskoff]

@borsboom , I'd like to provide a 7.10.3 windows-integersimple bindist if possible. Are there any special settings for the other bindists used by stack? BuildFlavor, etc..

[dtaskoff]

Here is an integersimple bindist built with the default build options. Please notify me if something else needs to be done.

[borsboom]

@leohaskell: did you test this bindist with stack setup? You can do so using stack setup --stack-setup-yaml <<<PATH>>> (with the <<<PATH>>> pointing to a modified version of stack-setup-2.yaml that adds your new bindist? If so, I'll put it somewhere official and add it to the normal stack-setup-2.yaml.

[dtaskoff]

The following is working:

stack setup --stack-setup-yaml <path-to-modified-setup.yaml> --ghc-variant=integersimple

[dtaskoff]

@borsboom, it's still not official?

[borsboom]

@leohaskell: Sorry for the delay. I've put it at https://github.com/commercialhaskell/ghc/releases/download/ghc-7.10.3-release/ghc-7.10.3-x86_64-unknown-mingw32-integer-simple.tar.bz2 and added it to https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml.

[dtaskoff]

@borsboom, here is a ghc-8.0.1 integersimple bindist (tested with stack setup).

[borsboom]

@leohaskell Thanks, I've uploaded it to https://github.com/commercialhaskell/ghc/releases/download/ghc-8.0.1-release/ghc-8.0.1-x86_64-unknown-mingw32-integer-simple.tar.xz and added a reference to https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml.

[PierreVDL]

With stack [[Version 1.3.0, Git revision 99b910d x86_64 hpack-0.15.0]]
I get when typing

stack setup --stack-setup-yaml stack.yaml --ghc-variant=integersimple

Warning: stack.yaml: Unrecognized fields in SetupInfo: extra-deps, extra-package-dbs, flags,
 packages, resolver
Unable to find installation URLs for OS key: windows64-integersimple

What am I doing wrong?

[snoyberg]

I don't think you want to have the --stack-setup-yaml argument, especially if it's pointed to your project's stack.yaml file.

[quyse]

I have a problem with CI builds on Windows. As I need to set flags for certain packages to allow them to build with integersimple (text, hashable, cryptonite, etc...), these packages and all packages transitively depending on them automatically become extra-deps, and compiled binaries end up in .stack-work directory. Now the problem is that .stack-work got removed (intentionally) before every CI build, for build to be certainly clean, so all those packages got rebuilt every time, and it takes forever.

Normally (without integersimple) packages from stackage go into snapshot directories and not cleaned up, so builds on Linux are fast. I've seen the "extensible snapshot" feature which should allow me to make a derived snapshot with changed flags, so all those packages will go to snapshot directory, and therefore won't be rebuilt every time. Unfortunately last time I tried that feature it didn't support setting ghc-variant for a custom snapshot. Could such a setting be added please? Or maybe I'm missing something obvious and there is other way?