RE: [Haskell-cafe] Hmm, what license to use?
Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. Thanks Neil == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
2008/10/3 Mitchell, Neil [EMAIL PROTECTED]: Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? Thanks, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Am Freitag, 3. Oktober 2008 13:36 schrieben Sie: […] What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? I've never heard about problems with macros etc. but I think that the LGPL is problematic if you use templates. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Oct 3, 2008 at 4:36 AM, minh thu [EMAIL PROTECTED] wrote: 2008/10/3 Mitchell, Neil [EMAIL PROTECTED]: Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? I don't know what happens on platforms that don't have shared libraries with LGPL. If you build stuff statically, I'm pretty sure you can't claim stuff is loosely coupled. Dave Thanks, Thu ___ 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] Hmm, what license to use?
On Fri, 2008-10-03 at 10:08 -0700, David Leimbach wrote: On Fri, Oct 3, 2008 at 4:36 AM, minh thu [EMAIL PROTECTED] wrote: 2008/10/3 Mitchell, Neil [EMAIL PROTECTED]: Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? I don't know what happens on platforms that don't have shared libraries with LGPL. If you build stuff statically, I'm pretty sure you can't claim stuff is loosely coupled. What I've always heard is that in that case you have to distribute object files. This would work for Haskell, except that changing the distributed library is still liable to invalidate the object files, due to cross-module inlining. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Jeltsch wrote: Am Donnerstag, 2. Oktober 2008 20:33 schrieben Sie: Wolfgang Jeltsch wrote: You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Maybe one of the GHC developers could comment on this? Perhaps the best approach currently for creating dynamically loadable modules in Haskell is to expose the interface via FFI, then? (I suspect that in most cases, you'd want to provide that as an option, but of course not as the only means of interfacing with the library, for those who don't want to make the DLL-vs-optimizations tradeoff.) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5lq/7M8hyUobTrERAn7aAJwPz4wbu0W4RPNhlgKGmd+2glZDewCfbi9d LQtahiILQg83vkzyfAR2BV4= =mjFe -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts: Yet another reason for getting dynamic linking / shared libs for Haskell packages working reliably on all platforms. You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Jeltsch wrote: Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts: Yet another reason for getting dynamic linking / shared libs for Haskell packages working reliably on all platforms. You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). Just because there's an important loss in value, doesn't mean there's not a significant net gain for some needs. Dynamically linked libs in Haskell have obvious benefits, as well as obvious drawbacks. - -- But hey, YMMV. Just my opinion. Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5RP37M8hyUobTrERAgn3AJ9JfWDY269PiRyh2hei1uH6W+dJ2wCfY/YG ztVcGYvH1+pQqG/fryr+YPw= =ekJT -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Am Donnerstag, 2. Oktober 2008 20:33 schrieben Sie: Wolfgang Jeltsch wrote: You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Maybe one of the GHC developers could comment on this? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Thu, Oct 2, 2008 at 11:25 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts: Yet another reason for getting dynamic linking / shared libs for Haskell packages working reliably on all platforms. You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Not all platforms even have shared libraries. Assuming that mechanism exists to begin with is somewhat flawed if you're interested in wide portability. Best wishes, Wolfgang ___ 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] Hmm, what license to use?
bulat.ziganshin: Hello Wolfgang, Thursday, October 2, 2008, 11:25:52 PM, you wrote: You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Maybe one of the GHC developers could comment on this? and type classes. once i've forget to addinline pragma, my program (serializing arrays) becomes 200x slower. it was due to use of hieararchy of several type classes. afaiu, their dictionaries are also lazily evaluated plus we have usual overhead of haskell closures that are ready for particular application How long ago was this, Bulat? I'd be interested to know if any of the compilers since 6.8.x, with all its inlining improvements, exhibited the same fragility. If I recall correctly, your experiments were around the 6.4.x series of compilers? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Don Stewart [EMAIL PROTECTED] writes: So if you use LGPL for your Haskell libraries, all of which are currently statically linked and non-replaceable at runtime, it is unlikely any commercial Haskell house can use the code. As already mentioned, you can ask the author nicely for a different license - BSD for instance. Or you can fix the dynamic linking issues in GHC, as Duncan points out. But you can also use it for *open source* software (which is non-proprietary, but may still be commercial). I think LGPL works nicely for open source software - unlike the GPL, which would force the entire program to be released under that license, there should be no problem shipping a BSD- or MPL-licensed program using an LGPL library, as long as source is available. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Mon, Sep 29, 2008 at 10:39 PM, Don Stewart [EMAIL PROTECTED] wrote: magnus: 2008/9/29 Bit Connor [EMAIL PROTECTED]: [..] Basically it seems to me that you believe in the benevolence and enligtenment of companies. Something I don't. I believe you are right in splitting the LGPL into two different objectives, and you are right in saying that I really only care about getting changes back. So in summary, if user freedom is important, then GPL is the way to go. If it's about encouraging the submission of patches and contributions, then the license won't help you, you simply have to rely on the good will of people. (But BSD will allow for a larger community) Well, I'm not convinced about this. I fail to see how your use of Apple is an example of this. Yes, they clearly didn't get it in the beginning, but now there seems to be a vibrant community around Webkit. Just as a point of comparison, did they do any better (in the beginning) with the BSD licensed code they use? I sure haven't heard anything along those lines anyways. The big problem with the LGPL and Haskell is static linking. We can't use anything we wish to ship commercially that relies on LGPLd-statically linked-and-inlined Haskell code at the moment. So if you use LGPL for your Haskell libraries, all of which are currently statically linked and non-replaceable at runtime, it is unlikely any commercial Haskell house can use the code. AFAIU you could, but you'd have to supply linkable objects of your proprietary code so that others can relink with a newer version of the LGPL'd module. It's a pain for sure and I've found no instructions anywhere for how to do that. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Mon, 29 Sep 2008 14:39:33 -0700, Don Stewart [EMAIL PROTECTED] said: magnus: 2008/9/29 Bit Connor [EMAIL PROTECTED]: [..] Basically it seems to me that you believe in the benevolence and enligtenment of companies. Something I don't. I believe you are right in splitting the LGPL into two different objectives, and you are right in saying that I really only care about getting changes back. So in summary, if user freedom is important, then GPL is the way to go. If it's about encouraging the submission of patches and contributions, then the license won't help you, you simply have to rely on the good will of people. (But BSD will allow for a larger community) [...] The big problem with the LGPL and Haskell is static linking. We can't use anything we wish to ship commercially that relies on LGPLd-statically linked-and-inlined Haskell code at the moment. So if you use LGPL for your Haskell libraries, all of which are currently statically linked and non-replaceable at runtime, it is unlikely any commercial Haskell house can use the code. Note that this *isn't* the case for C libraries, which are dynamically linked, like libgmp, which is just fine. I am not allowed to use such an interpretation. The (expensive and very carefully researched) legal advice used to shape the use of Open Source code at my employer has resulted in a no LGPL under any circumstances whatsoever policy. I believe that the core issue is that the terms of the LGPL are far more open to differing interpretations than GPL (which is pretty clear in its provisions). Therefore, I have to say that for at least some commercial users, LGPL will never be acceptable, and GPL is actually more acceptable because we know for sure what obligations it places on us. That still leaves anyone free to use LGPL if they want to, but please don't assume that it allows commercial use by all potential users. This is why the OCaml guys use their untested LGPL+static linking exception, I guess. The key word here being untested, although in *most* jurisdictions, the clear intention behind such a clause would probably be respected. wxWidgets (and wxHaskell, to which I contribute, and which of necessity takes the wxWidgets license) uses a similarly untested LGPL + you may use, copy, link, modify and distribute under your own terms, binary object code versions of works based on the Library clause. I can live with this as it's a hobby project for me, but my employer will probably never distribute software based on wxHaskell (Haskell is already a hard sell (for non-license reasons), although we're sneaking it in, bit by bit :-) Jeremy -- Jeremy O'Donoghue [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Jeremy O'Donoghue [EMAIL PROTECTED] writes: Therefore, I have to say that for at least some commercial users, LGPL will never be acceptable, and GPL is actually more acceptable because we know for sure what obligations it places on us. I don't see how this can be, since according to clause 2b of the LGPL, you are free to distribute modified copies under the GPL. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Bit Connor [EMAIL PROTECTED] writes: I believe that it's wrong to use a license to try to enforce such cooperation. Look what happened with KHTML when Apple started using it for their Safari web browser. I haven't followed this in detail, but I think that, even when a company is reluctant to cooporate, it is better to have their code available than not. Also, using the LGPL rather than BSD is a clear signal that contributions are expected for the library, BSD condones making proprietary forks. The FSF advises only to use LGPL in rare cases as a tactic to ensure greater freedom further down the line. They advise to use GPL instead, as a crowbar to force any applications using the library to be GPL as well. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Mon, Sep 29, 2008 at 4:06 AM, Michael Giagnocavo [EMAIL PROTECTED] wrote: Goal 2 (The open source angle): Developers who use the library should have to contribute their modifications of the library back to the community. I believe that it's wrong to use a license to try to enforce such cooperation. Look what happened with KHTML when Apple started using it for their Safari web browser. Even though KHTML was Well, the MPL helps out with this Goal 2 by requiring that you document all modifications (they recommend providing diffs). http://www.mozilla.org/MPL/MPL-1.1.html#section-3.3 However, because of this clause (and others), the MPL is incompatible with the GPL: http://www.gnu.org/philosophy/license-list.html#MPL http://www.tomhull.com/ocston/docs/mozgpl.html If it's not obvious why GPL compatibility is an important thing then the second link above provides some explanation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
2008/9/29 Bit Connor [EMAIL PROTECTED]: [..] Basically it seems to me that you believe in the benevolence and enligtenment of companies. Something I don't. I believe you are right in splitting the LGPL into two different objectives, and you are right in saying that I really only care about getting changes back. So in summary, if user freedom is important, then GPL is the way to go. If it's about encouraging the submission of patches and contributions, then the license won't help you, you simply have to rely on the good will of people. (But BSD will allow for a larger community) Well, I'm not convinced about this. I fail to see how your use of Apple is an example of this. Yes, they clearly didn't get it in the beginning, but now there seems to be a vibrant community around Webkit. Just as a point of comparison, did they do any better (in the beginning) with the BSD licensed code they use? I sure haven't heard anything along those lines anyways. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
magnus: 2008/9/29 Bit Connor [EMAIL PROTECTED]: [..] Basically it seems to me that you believe in the benevolence and enligtenment of companies. Something I don't. I believe you are right in splitting the LGPL into two different objectives, and you are right in saying that I really only care about getting changes back. So in summary, if user freedom is important, then GPL is the way to go. If it's about encouraging the submission of patches and contributions, then the license won't help you, you simply have to rely on the good will of people. (But BSD will allow for a larger community) Well, I'm not convinced about this. I fail to see how your use of Apple is an example of this. Yes, they clearly didn't get it in the beginning, but now there seems to be a vibrant community around Webkit. Just as a point of comparison, did they do any better (in the beginning) with the BSD licensed code they use? I sure haven't heard anything along those lines anyways. The big problem with the LGPL and Haskell is static linking. We can't use anything we wish to ship commercially that relies on LGPLd-statically linked-and-inlined Haskell code at the moment. So if you use LGPL for your Haskell libraries, all of which are currently statically linked and non-replaceable at runtime, it is unlikely any commercial Haskell house can use the code. Note that this *isn't* the case for C libraries, which are dynamically linked, like libgmp, which is just fine. This is why the OCaml guys use their untested LGPL+static linking exception, I guess. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
G'day all. Quoting Magnus Therning: Recently I received an email with a question regarding the licensing of a module I've written and uploaded to Hackage. I released it under LGPL. The sender wondered if I would consider re-licensing the code under BSD (or something similar) that would remove the need for users to provide linkable object files so that users can re-link programs against newer/modified versions of my library. Generally speaking, the Haskell community releases general-purpose libraries under a BSD-like licence. Programs are generally either released under the BSD-like licence or the GPL. The reason that we generally use the BSD-like licence for libraries is that libraries are intended to be maximally reusable. Hence, the de facto standard is a licence that allows for maximum reuse. There's nothing wrong with releasing a Haskell library under the LGPL. The biggest risk in doing so is that not everyone will use your library. The risk in picking yet another licence, one that satisfies your opinions on software freedom, is even more confusion. If the usual BSD-like licence doesn't do it for you, I would be concerned about adding yet another licence into the mix if you don't have to. Just use the LGPL, and add explicit exceptions if it makes you feel better. We know where we stand with GPL, LGPL and BSD. More licences causes more confusion. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Sun, Sep 28, 2008 at 12:20 PM, [EMAIL PROTECTED] wrote: [..] The risk in picking yet another licence, one that satisfies your opinions on software freedom, is even more confusion. If the usual BSD-like licence doesn't do it for you, I would be concerned about adding yet another licence into the mix if you don't have to. Just use the LGPL, and add explicit exceptions if it makes you feel better. We know where we stand with GPL, LGPL and BSD. More licences causes more confusion. Despite that there does seem to be some confusion relating to using the LGPL with an advanced compiler/linker as GHC I think you are right: adding more licenses to the mix is a serious problem. For now I will continue to release Haskell modules under LGPL and programs under GPL and if people would like to put the code to use in a non-free way they'll simply have to ask me. Hopefully this is something that people are used to doing. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On 26 Sep 2008, at 08:24, Magnus Therning wrote: I've heard that the OCaml crowd uses a modified LGPL with a static linking exception. Unfortunately I've also heard that their addition to LGPL hasn't gotten much review by lawyers, I'd much rather use something that feels less ad hoc, if you get what I mean. It's not just O'Caml that adds a static-linking exception clause to the LGPL. Examples of other projects using a similar exception include wxWidgetshttp://www.wxwidgets.org/about/newlicen.htm FLTK http://www.fltk.org/articles.php?L364+I0+TFAQ+M10+P1+Q and in the Haskell world: wxHaskellhttp://haskell.org/haskellwiki/WxHaskell/License HaXmlhttp://www.cs.york.ac.uk/fp/HaXml/COPYRIGHT Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Hmm, what license to use?
Goal 2 (The open source angle): Developers who use the library should have to contribute their modifications of the library back to the community. I believe that it's wrong to use a license to try to enforce such cooperation. Look what happened with KHTML when Apple started using it for their Safari web browser. Even though KHTML was Well, the MPL helps out with this Goal 2 by requiring that you document all modifications (they recommend providing diffs). http://www.mozilla.org/MPL/MPL-1.1.html#section-3.3 -Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Wolfgang Jeltsch wrote: Am Freitag, 26. September 2008 09:24 schrieb Magnus Therning: Recently I received an email with a question regarding the licensing of a module I've written and uploaded to Hackage. I released it under LGPL. The sender wondered if I would consider re-licensing the code under BSD (or something similar) that would remove the need for users to provide linkable object files so that users can re-link programs against newer/modified versions of my library. Since GHC does cross-package inlining, code of your library is directly included (not just linked) into code that uses the library. So I think that every code that uses your library will have to be released und the GPL or LGPL which is a very bad situation. People, don’t release Haskell libraries under the LGPL! That would be serious indeed, but before changing my ways I'd need more information to back up your statement. Could someone confirm that code from one installed module can be inlined into another? AFAIU you are saying that the linker is reaching into the module's .a file, pulling out the .o file, and then reaching into that .o file to pull out an individual function's ASM code. I believe that's a bit more than regular C linkers would do. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts 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] Hmm, what license to use?
Now I have fairly strong feelings about freedom of code and I everything I release is either under GPL or LGPL. What I like about those licenses is it protects freedom in a way that I think it should and it forces a sort of reciprocity which resonates very well with my selfishness. Re-licensing code under BSD is not something I'm willing to do without something that compensates for that reciprocity, and I can think of several kinds of compensation here but they all pretty much boil down to either fame or fortune. ;-) Sorry, this isn't the most relevant comment to the discussion, but I thought I'd add my own thought re the gpl/lgpl. My personal feeling is that the point of open source is to allow people the freedom to do what they want with a piece of code. The GPL/LGPL go completely against this idea, in that they restrict what I can do with the code to only things that are similarly licensed. I've seen this cause problems even in environments where there's no commercial gain to be had. Take for example the zfs file system. Sun have been kind enough to completely open source it. Unfortunately, linux users can never hope for stable version that works in the kernel, simply because the GPL stipulates that zfs must be relicensed to do so. That's my 2p's worth on why I use the BSD license over the GPL. In short, the GPL does not promote freedom, it promotes restrictions, just not the restrictions we've grown to hate from most companies. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Thomas == Thomas Davie [EMAIL PROTECTED] writes: Thomas Sorry, this isn't the most relevant comment to the Thomas discussion, but I thought I'd add my own thought re the Thomas gpl/lgpl. My personal feeling is that the point of open Thomas source is to allow people the freedom to do what they want Thomas with a piece of code. The GPL/LGPL go completely against Thomas this idea, in that they restrict what I can do with the Thomas code to only things that are similarly licensed. No, the point of free software is to prevent people from denying other people the right to use the code. Allowing people to do what they like at the expense of other people is not freedom. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Sep 26, 2008 at 9:12 AM, Thomas Davie [EMAIL PROTECTED] wrote: Now I have fairly strong feelings about freedom of code and I everything I release is either under GPL or LGPL. What I like about those licenses is it protects freedom in a way that I think it should and it forces a sort of reciprocity which resonates very well with my selfishness. Re-licensing code under BSD is not something I'm willing to do without something that compensates for that reciprocity, and I can think of several kinds of compensation here but they all pretty much boil down to either fame or fortune. ;-) Sorry, this isn't the most relevant comment to the discussion, but I thought I'd add my own thought re the gpl/lgpl. My personal feeling is that the point of open source is to allow people the freedom to do what they want with a piece of code. The GPL/LGPL go completely against this idea, in that they restrict what I can do with the code to only things that are similarly licensed. I've seen this cause problems even in environments where there's no commercial gain to be had. Take for example the zfs file system. Sun have been kind enough to completely open source it. Unfortunately, linux users can never hope for stable version that works in the kernel, simply because the GPL stipulates that zfs must be relicensed to do so. That's my 2p's worth on why I use the BSD license over the GPL. In short, the GPL does not promote freedom, it promotes restrictions, just not the restrictions we've grown to hate from most companies. You are completely right, both that the comment is a bit off-topic and in point. It can be argued that the (L)GPL is restrictive. However, I fall on the side of the freedom to take something free and make it proprietary is not a freedom worth protecting. Also, I'm a selfish bastard ;-) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Colin Paul Adams ha scritto: Thomas == Thomas Davie [EMAIL PROTECTED] writes: Thomas Sorry, this isn't the most relevant comment to the Thomas discussion, but I thought I'd add my own thought re the Thomas gpl/lgpl. My personal feeling is that the point of open Thomas source is to allow people the freedom to do what they want Thomas with a piece of code. The GPL/LGPL go completely against Thomas this idea, in that they restrict what I can do with the Thomas code to only things that are similarly licensed. No, the point of free software is to prevent people from denying other people the right to use the code. Allowing people to do what they like at the expense of other people is not freedom. When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On 26 Sep 2008, at 12:12, Janis Voigtlaender wrote: Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Thomas Davie wrote: On 26 Sep 2008, at 12:12, Janis Voigtlaender wrote: Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. Oh, but now you unfortunately spoiled my joy about not understanding such discussions ;-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Sep 26, 2008 at 11:17 AM, Thomas Davie [EMAIL PROTECTED] wrote: Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. That rather depends what you intend to give, doesn't it? :-) Though the analogy is inapt, because the GPL *doesn't* prevent use of software for things you don't like: http://www.gnu.org/licenses/gpl-faq.html#NoMilitary Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On 26 Sep 2008, at 12:28, Dougal Stanton wrote: On Fri, Sep 26, 2008 at 11:17 AM, Thomas Davie [EMAIL PROTECTED] wrote: Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. That rather depends what you intend to give, doesn't it? :-) Though the analogy is inapt, because the GPL *doesn't* prevent use of software for things you don't like: http://www.gnu.org/licenses/gpl-faq.html#NoMilitary Sure it does -- it prevents the use of software for things that are closed source. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Thomas Davie ha scritto: [...] Though the analogy is inapt, because the GPL *doesn't* prevent use of software for things you don't like: http://www.gnu.org/licenses/gpl-faq.html#NoMilitary Sure it does -- it prevents the use of software for things that are closed source. What worse, is that it prevents me to use a GPL library in a MIT library, unless there is an explicit extra clause in the license, like done by the library shipped with MySQL, and some (not so many) others: http://www.mysql.com/about/legal/licensing/foss-exception.html Bob Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Sep 26, 2008 at 11:32 AM, Thomas Davie [EMAIL PROTECTED] wrote: Sure it does -- it prevents the use of software for things that are closed source. Thing that are closed source is not a use of software. Programs don't become more or less capable of designing rockets or writing subversive literature because the licence changes. The GPL provides an identical number of restrictions in this case as the BSD licence. Either way, the OP subscribes to the GPL ethic. Such arguments cloud the real point of discussion --- which licence (if any) satisfies the permanent freedom clause with some flexibility for linking? D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Sep 26, 2008 at 12:07 PM, Dougal Stanton [EMAIL PROTECTED] wrote: On Fri, Sep 26, 2008 at 11:32 AM, Thomas Davie [EMAIL PROTECTED] wrote: Sure it does -- it prevents the use of software for things that are closed source. Thing that are closed source is not a use of software. Programs don't become more or less capable of designing rockets or writing subversive literature because the licence changes. The GPL provides an identical number of restrictions in this case as the BSD licence. Either way, the OP subscribes to the GPL ethic. Such arguments cloud the real point of discussion --- which licence (if any) satisfies the permanent freedom clause with some flexibility for linking? Thanks for trying to reign in this thread. It turns out my fears were confirmed, people jumped on the GPL vs. BSD path rather than offer suggestions of licenses that satisfy _my_beliefs_ in source freedom. I'm still hopeful someone will be able to inform me of some license that satisfies my needs. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Magnus Therning ha scritto: Recently I received an email with a question regarding the licensing of a module I've written and uploaded to Hackage. I released it under LGPL. The sender wondered if I would consider re-licensing the code under BSD (or something similar) that would remove the need for users to provide linkable object files so that users can re-link programs against newer/modified versions of my library. Now I have fairly strong feelings about freedom of code and I everything I release is either under GPL or LGPL. What I like about those licenses is it protects freedom in a way that I think it should and it forces a sort of reciprocity which resonates very well with my selfishness. Re-licensing code under BSD is not something I'm willing to do without something that compensates for that reciprocity, and I can think of several kinds of compensation here but they all pretty much boil down to either fame or fortune. ;-) Once GHC supports dynamic binding on all platforms (or at least the major ones) this issue will (largely) go away (thanks Andrew for reporting on the state of this), but until then LGPL does create a large burden for users of my module. Until that happens I wouldn't mind re-licensing the code under a license that has the reciprocity attribute of LGPL on the source level, but does allow for static linking without requiring the availability of linkable object files. Is there such a license? I've heard that the OCaml crowd uses a modified LGPL with a static linking exception. Unfortunately I've also heard that their addition to LGPL hasn't gotten much review by lawyers, I'd much rather use something that feels less ad hoc, if you get what I mean. Any suggestions? Sorry if I can't help, but I suggest you a quick check here: http://www.opensource.org/licenses/category /M Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Am Freitag, 26. September 2008 09:24 schrieb Magnus Therning: Recently I received an email with a question regarding the licensing of a module I've written and uploaded to Hackage. I released it under LGPL. The sender wondered if I would consider re-licensing the code under BSD (or something similar) that would remove the need for users to provide linkable object files so that users can re-link programs against newer/modified versions of my library. Since GHC does cross-package inlining, code of your library is directly included (not just linked) into code that uses the library. So I think that every code that uses your library will have to be released und the GPL or LGPL which is a very bad situation. People, don’t release Haskell libraries under the LGPL! Now I have fairly strong feelings about freedom of code and I everything I release is either under GPL or LGPL. Ah, the RMS prevarication. ;-) Honestly, copyleft gives the user *less* freedom because he can no longer choose a license for redistribution freely. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Hmm, what license to use?
Now I have fairly strong feelings about freedom of code and I everything I release is either under GPL or LGPL. What I like about those licenses is it protects freedom in a way that I think it should I'm afraid I'll just be boring and make a recommendation: http://www.mozilla.org/MPL/mpl-faq.html In short, it protects your source files and requires modifications to be contributed on a file-by-file basis. The downside as far as freedom-restrictions-or-whatever-you-wanna-call-it is that one can get around it by creating new source files and putting all their changes in there. But still, it provides some copyleft without the full, uh, impact, of LGPL. -Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, 2008-09-26 at 12:17 +0200, Thomas Davie wrote: On 26 Sep 2008, at 12:12, Janis Voigtlaender wrote: Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. I think the standard answer to your question is that you get the enemy to *surrender* first, patch him up enough to move him, and then stick him in a POW camp for the duration, or until you get something in return for releasing him. I would never patch someone up so he can go back to *shooting* at me, or my friends. Never. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On 26 Sep 2008, at 17:51, Jonathan Cast wrote: On Fri, 2008-09-26 at 12:17 +0200, Thomas Davie wrote: On 26 Sep 2008, at 12:12, Janis Voigtlaender wrote: Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. I think the standard answer to your question is that you get the enemy to *surrender* first, patch him up enough to move him, and then stick him in a POW camp for the duration, or until you get something in return for releasing him. I would never patch someone up so he can go back to *shooting* at me, or my friends. Never. Yet doctors all abide by the hypocratic(sp?) oath. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, 2008-09-26 at 18:45 +0200, Thomas Davie wrote: On 26 Sep 2008, at 17:51, Jonathan Cast wrote: On Fri, 2008-09-26 at 12:17 +0200, Thomas Davie wrote: On 26 Sep 2008, at 12:12, Janis Voigtlaender wrote: Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. I think the standard answer to your question is that you get the enemy to *surrender* first, patch him up enough to move him, and then stick him in a POW camp for the duration, or until you get something in return for releasing him. I would never patch someone up so he can go back to *shooting* at me, or my friends. Never. Yet doctors all abide by the hypocratic(sp?) oath. Really? Even medics? Got any evidence of that? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Sep 26, 2008 at 9:45 AM, Thomas Davie [EMAIL PROTECTED] wrote: On 26 Sep 2008, at 17:51, Jonathan Cast wrote: On Fri, 2008-09-26 at 12:17 +0200, Thomas Davie wrote: On 26 Sep 2008, at 12:12, Janis Voigtlaender wrote: Manlio Perillo wrote: When I compare GPL and MIT/BSD licenses, I do a simple reasoning. Suppose a doctor in a battle field meet a badly injuried enemy. Should he help the enemy? I'm so glad I don't understand this ;-) Should you decide not to give someone something based on the fact that you either don't like them, or don't like what they'll do with the thing you give them. I think the standard answer to your question is that you get the enemy to *surrender* first, patch him up enough to move him, and then stick him in a POW camp for the duration, or until you get something in return for releasing him. I would never patch someone up so he can go back to *shooting* at me, or my friends. Never. Yet doctors all abide by the hypocratic(sp?) oath. Although, I've heard that in the US taking the oath is now an optional part of graduation for doctors. Wikipedia seems to agree but without a citation: http://en.wikipedia.org/wiki/Hippocratic_Oath Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
