Re: [Haskell-cafe] ANNOUNCE: tie-knot library
Brandon Allbery allber...@gmail.com writes: Haskell libraries are mostly BSD licensed, as is GHC itself. (Oddly enough, GPL is not the only open source license.) btw, what about GHC's reliance on the LGPLed GMP library? Doesn't that already taint the whole GHC eco-system? Quoting [1]: | GMP is licensed under the GNU Lesser General Public License (LGPL), a | kind of copyleft license. According to the terms of the LGPL, | paragraph 5, you may distribute a program that is designed to be | compiled and dynamically linked with the library under the terms of | your choice (i.e., commercially) but if your program incorporates | portions of the library, if it is linked statically, then your program | is a derivative--a work based on the library--and according to | paragraph 2, section c, you must cause the whole of the work to be | licensed under the terms of the LGPL (including for free). | | The LGPL licensing for GMP is a problem for the overall licensing of | binary programs compiled with GHC because most distributions (and | builds) of GHC use static libraries. (Dynamic libraries are currently | distributed only for OS X.) The LGPL licensing situation may be worse: | even though The Glasgow Haskell Compiler License is essentially a | free software license (BSD3), according to paragraph 2 of the LGPL, | GHC must be distributed under the terms of the LGPL! [1]: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplacingGMPastheBignumlibrary cheers, hvr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tie-knot library
Yes, if you link statically, if you want to distribute without giving away source (or relinkable object files) you can link dynamically or use integer-simple in your GHC. Niklas - Ursprungligt meddelande - Från: Herbert Valerio Riedel h...@gnu.org Skickat: 2012-12-14 11:55 Till: Brandon Allbery allber...@gmail.com Kopia: Ramana Kumar ramana.ku...@cl.cam.ac.uk; haskell-cafe haskell-cafe@haskell.org Ämne: Re: [Haskell-cafe] ANNOUNCE: tie-knot library Brandon Allbery allber...@gmail.com writes: Haskell libraries are mostly BSD licensed, as is GHC itself. (Oddly enough, GPL is not the only open source license.) btw, what about GHC's reliance on the LGPLed GMP library? Doesn't that already taint the whole GHC eco-system? Quoting [1]: | GMP is licensed under the GNU Lesser General Public License (LGPL), a | kind of copyleft license. According to the terms of the LGPL, | paragraph 5, you may distribute a program that is designed to be | compiled and dynamically linked with the library under the terms of | your choice (i.e., commercially) but if your program incorporates | portions of the library, if it is linked statically, then your program | is a derivative--a work based on the library--and according to | paragraph 2, section c, you must cause the whole of the work to be | licensed under the terms of the LGPL (including for free). | | The LGPL licensing for GMP is a problem for the overall licensing of | binary programs compiled with GHC because most distributions (and | builds) of GHC use static libraries. (Dynamic libraries are currently | distributed only for OS X.) The LGPL licensing situation may be worse: | even though The Glasgow Haskell Compiler License is essentially a | free software license (BSD3), according to paragraph 2 of the LGPL, | GHC must be distributed under the terms of the LGPL! [1]: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplacingGMPastheBignumlibrary cheers, hvr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can cabal be turned into a package manager?
On Thu, Dec 13, 2012 at 11:46 PM, Badi' Abdul-Wahid abdulwah...@gmail.comwrote: Just my two cents: Nix is great, Modules is not perfect, but it is good. I think that Nix solves a lot of the problems, but will likely take a while to be adopted. I'm still exploring Nix and NixOS, but I have to say: I really like it. I've found that a practical solution for my own development work has been the modules project [1]. Thanks. modules looks quite low level. Better low level and working!! Do you know about emacs/ghci integration? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tie-knot library
GHC's reliance on the LGPLed GMP library ... use integer-simple in your GHC I think this can still use some attention. GHC requires an integer library internally, so to switch to integer-simple, you need to build GHC from source. Has anyone reviewed of the performance implications of this switch? +the new GHC Performance Team, Johan and Bryan Thanks, Greg On Fri, Dec 14, 2012 at 4:21 AM, Niklas Larsson metanik...@gmail.comwrote: Yes, if you link statically, if you want to distribute without giving away source (or relinkable object files) you can link dynamically or use integer-simple in your GHC. Niklas -- Från: Herbert Valerio Riedel h...@gnu.org Skickat: 2012-12-14 11:55 Till: Brandon Allbery allber...@gmail.com Kopia: Ramana Kumar ramana.ku...@cl.cam.ac.uk; haskell-cafehaskell-cafe@haskell.org Ämne: Re: [Haskell-cafe] ANNOUNCE: tie-knot library Brandon Allbery allber...@gmail.com writes: Haskell libraries are mostly BSD licensed, as is GHC itself. (Oddly enough, GPL is not the only open source license.) btw, what about GHC's reliance on the LGPLed GMP library? Doesn't that already taint the whole GHC eco-system? Quoting [1]: | GMP is licensed under the GNU Lesser General Public License (LGPL), a | kind of copyleft license. According to the terms of the LGPL, | paragraph 5, you may distribute a program that is designed to be | compiled and dynamically linked with the library under the terms of | your choice (i.e., commercially) but if your program incorporates | portions of the library, if it is linked statically, then your program | is a derivative--a work based on the library--and according to | paragraph 2, section c, you must cause the whole of the work to be | licensed under the terms of the LGPL (including for free). | | The LGPL licensing for GMP is a problem for the overall licensing of | binary programs compiled with GHC because most distributions (and | builds) of GHC use static libraries. (Dynamic libraries are currently | distributed only for OS X.) The LGPL licensing situation may be worse: | even though The Glasgow Haskell Compiler License is essentially a | free software license (BSD3), according to paragraph 2 of the LGPL, | GHC must be distributed under the terms of the LGPL! [1]: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplacingGMPastheBignumlibrary cheers, hvr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can cabal be turned into a package manager?
On Fri, Dec 14, 2012 at 12:10 PM, Rustom Mody rustompm...@gmail.com wrote: Do you know about emacs/ghci integration? Cabal-install appears to have a --prefix flag, and running ghci with -package-db seems promising, eg $ ghci -package-db dist/package.conf.inplace I'm still finding my way through the Haskell ecosystem myself, so I don't know yet how well this integrates with the rest of cabal-install-managed packages. -- Badi' Abdul-Wahid ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)
That very much mirrors my experience. As there is not settled case law in all jurisdictions many companies would simply rather not risk it. Simply having a court in the US set some precedents would not be enough. A company which operated globally could be sued in many different venues which are free to make up their own interpretations. While these fears may be somewhat irrational they are still there. The cost of building a replacement to a library may be far less than what the cost of being found guilty of infringement may be. In any case I mostly see GPL effecting smaller organizations anyhow as many big organizations don't use much outside code. It is true that in a hosted world the GPL doesn't matter much. So long as the product that we ship to our customers is not software it doesn't matter too much. If we were to ship code we would have to replace any GPLed packages with something else. The other thing I have found interesting is the notion that the GPL can infect your codecase just by looking at GPLed code. If that it is true, and I don't know that it is, it would seem that looking at any code released under the GPL would be just as dangerous as looking at a patent. Although I don't know that the offending party would be liable for triple damages. Interesting food for thought and it would be nice if there was a clarification somewhere. Steve On Thu, Dec 13, 2012 at 9:58 PM, wren ng thornton w...@freegeek.org wrote: On 12/13/12 3:14 AM, Colin Adams wrote: Presumably you are talking about companies who want to distribute programs (a very small minority of companies, I would think)? Not at all. In addition to Michael's own rebuttal, I'll add my own. There are many companies which *fear* the L/GPL. The important thing to note here is this: The Actual Legal Requirements of Copyleft Licenses are IRRELEVANT. This simple fact is consistently ignored by advocates of the GPL (of which I number myself, FWIW). The great majority of all software produced in the world is developed for in-house use, and thus would not be subject to any of the bad side effects from using copyleft software. And yet, in spite of this fact, there are a great many companies which have official policies forbidding the use of copyleft software. Why is that? It's because companies have legal departments whose jobs it is to ensure that the company won't be destroyed by legal action. And because there isn't an extensive record of actual court rulings regarding purported violations of the GPL, lawyers are rightly wary of it. Companies do not (generally) avoid the GPL because of understanding its requirements and refusing to abide by them. Companies avoid the GPL because they do not know what it means! More particularly, because they do not know what the courts will think it means, and that's too much uncertainty to risk your company over. Any actual commercial burden imposed by the GPL re distributing software is beside the point. Corporate lawyers (for these companies) won't risk getting close enough to even evaluate what that burden would amount to. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] edge: compile testing
Hey guys, to teach myself Haskell I wrote a little arcade game called The Edge, built on gloss. It is in hackage under the package name edge. Are there a few kind souls who would be willing to compile it on their machines and let me know if there are any problems at the compiling level? In the past, I've had issues with Haskell code compiling fine on my development system but not on others (due to dependency-related issues). I want to double check this before I try to make any distro-specific packages. I developed with GHC 7.4 and cabal-install 1.16.0.2 on a Gentoo system. Requires OpenGL and OpenAL (for sound). cabal update cabal install edge -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] edge: compile testing
The OpenAL bindings aren't building for me on GHC 7.6: Sound/OpenAL/ALC/QueryUtils.hs:66:1: Unacceptable argument type in foreign declaration: ALCdevice When checking declaration: foreign import ccall unsafe static alcGetString alcGetString :: ALCdevice - ALCenum - IO (Ptr ALCchar) Sound/OpenAL/ALC/QueryUtils.hs:102:1: Unacceptable argument type in foreign declaration: ALCdevice When checking declaration: foreign import ccall unsafe static alcGetIntegerv alcGetIntegerv :: ALCdevice - ALCenum - ALCsizei - Ptr ALCint - IO () Sound/OpenAL/ALC/QueryUtils.hs:120:1: Unacceptable argument type in foreign declaration: ALCdevice When checking declaration: foreign import ccall unsafe static alcIsExtensionPresent alcIsExtensionPresent_ :: ALCdevice - Ptr ALCchar - IO ALCboolean Failed to install OpenAL-1.4.0.1 On Fri, Dec 14, 2012 at 10:52 PM, Christopher Howard christopher.how...@frigidcode.com wrote: Hey guys, to teach myself Haskell I wrote a little arcade game called The Edge, built on gloss. It is in hackage under the package name edge. Are there a few kind souls who would be willing to compile it on their machines and let me know if there are any problems at the compiling level? In the past, I've had issues with Haskell code compiling fine on my development system but not on others (due to dependency-related issues). I want to double check this before I try to make any distro-specific packages. I developed with GHC 7.4 and cabal-install 1.16.0.2 on a Gentoo system. Requires OpenGL and OpenAL (for sound). cabal update cabal install edge -- frigidcode.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] edge: compile testing
On 12/14/2012 07:05 PM, Clark Gaebel wrote: Unacceptable argument type in foreign declaration Thanks for giving it a try. Could you send off a bug report to the OpenAL Haskell module maintainer? sven.pa...@aedion.de (I might offer to do it, but I tried to e-mail him once about a different issue and never heard back. Probably didn't make it through his spam filter.) -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Template Haskell Splicing
Is there any way to splice declarations inside where? If not, then what is the reason for not supporting this? -Satvik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package
This is strange, I thought that cpphs should be specified in build-tools:, not in build-depends:. http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information Best regards, Petr 2012/12/13 Michael Snoyman mich...@snoyman.com On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak daniel.trsten...@gmail.com wrote: On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote: If you have a commercial use for cpphs, and feel the terms of the (L)GPL are too onerous, you have the option of distributing unmodified binaries (only, not sources) under the terms of a different licence (see LICENCE-commercial). I think that depedencies to binaries, like cpphs, should be treated differently than depedencies to libraries, because using a (L)GPL-ed binary mostly hasn't any implications for a commercial user and also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't apply. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe In the case of cpphs, there's no way to determine that we're using it as a library or an executable, since it's just listed in the build-depends. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
