New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LGPL licensing restrictions on Windows because of integer-gmp #399

Closed
quyse opened this Issue Jun 24, 2015 · 93 comments

Comments

Projects
None yet
@quyse
Contributor

quyse commented Jun 24, 2015

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:

@vyp

This comment has been minimized.

Contributor

vyp commented Jun 24, 2015

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

This comment has been minimized.

andrewthad commented Jun 24, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

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?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 25, 2015

@kantp

This comment has been minimized.

Contributor

kantp commented Jun 25, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

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

This comment has been minimized.

Contributor

kantp commented Jun 25, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

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

This comment has been minimized.

Contributor

quyse commented Jun 25, 2015

@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

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

@quyse Thanks!

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

@kantp Has provided the following GHC bindists:

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

This comment has been minimized.

Contributor

quyse commented Jun 25, 2015

@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

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@3noch

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

This comment has been minimized.

hvr commented Jun 26, 2015

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

This comment has been minimized.

Contributor

kantp commented Jun 26, 2015

@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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@3noch

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

hvr commented Jun 26, 2015

@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

@tejon

This comment has been minimized.

Contributor

tejon commented Jun 26, 2015

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

@quyse

This comment has been minimized.

Contributor

quyse commented Jun 26, 2015

@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

This comment has been minimized.

Contributor

quyse commented Jun 26, 2015

@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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@3noch

This comment has been minimized.

Member

3noch commented Aug 27, 2015

@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

This comment has been minimized.

Jookia commented Aug 27, 2015

The section says this:

  1. 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

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

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

@rvion

This comment has been minimized.

Contributor

rvion commented Sep 8, 2015

would ghc-musl make a better bindist default ?

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

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

This comment has been minimized.

Contributor

rvion commented Sep 8, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 21, 2015

No objection given to my question about closing.

@varosi

This comment has been minimized.

varosi commented Jun 22, 2016

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

This comment has been minimized.

Contributor

borsboom commented Jun 22, 2016

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

stack setup --ghc-variant=integersimple
@varosi

This comment has been minimized.

varosi commented Jun 22, 2016

@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

This comment has been minimized.

Contributor

borsboom commented Jun 22, 2016

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

This comment has been minimized.

Member

3noch commented Jun 22, 2016

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

This comment has been minimized.

Contributor

borsboom commented Jun 22, 2016

@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

This comment has been minimized.

Member

3noch commented Jun 22, 2016

@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.

@leohaskell

This comment has been minimized.

leohaskell commented Oct 12, 2016

@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..

@leohaskell

This comment has been minimized.

leohaskell commented Oct 14, 2016

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

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 22, 2016

@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.

@leohaskell

This comment has been minimized.

leohaskell commented Nov 23, 2016

The following is working:

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

This comment has been minimized.

leohaskell commented Dec 15, 2016

@borsboom, it's still not official?

@leohaskell

This comment has been minimized.

leohaskell commented Jan 6, 2017

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

@PierreVDL

This comment has been minimized.

PierreVDL commented Jan 10, 2017

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

This comment has been minimized.

Contributor

snoyberg commented Jan 10, 2017

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

This comment has been minimized.

Contributor

quyse commented Jan 23, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment