On Fri, Sep 26, 2008 at 8:59 AM, Achim Schneider wrote: [..]

Concerning Haskell, just tell them to use the ghc-lib and link (or even compile) at runtime.

"ghc-lib", never heard of it, where can I find out more? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

On Fri, Sep 26, 2008 at 9:32 AM, Achim Schneider wrote:

"Magnus Therning" wrote:

...

On Fri, Sep 26, 2008 at 8:59 AM, Achim Schneider wrote: [..]

...

Concerning Haskell, just tell them to use the ghc-lib and link (or even compile) at runtime.

"ghc-lib", never heard of it, where can I find out more?

http://www.haskell.org/haskellwiki/GHC/As_a_library

As it's notoriously undocumented in places where the documentation isn't out of date, I recommend downloading the Yi[1] source and have a look at how it's done.

A cool thing, but I don't really see that more or less forcing people to use it in order to use my module is a lighter burden than to provide linkable object files. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Thomas Davie wrote:

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.

http://www.wizy.org/wiki/ZFS_on_FUSE I see no problem using FUSE, including stability. ntfs-3g does, too, and it works like a charm. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

Colin Paul Adams ha scritto:

...

...

...

...

...

"Thomas" == Thomas Davie 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

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

On Fri, Sep 26, 2008 at 11:17 AM, Thomas Davie 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

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

On Fri, Sep 26, 2008 at 12:07 PM, Dougal Stanton wrote:

On Fri, Sep 26, 2008 at 11:32 AM, Thomas Davie 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

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

On Fri, Sep 26, 2008 at 9:45 AM, 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.

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

Manlio Perillo wrote:

Colin Paul Adams ha scritto:

...

...

...

...

...

> "Thomas" == Thomas Davie 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 Thomas> want with a piece of code. The GPL/LGPL go completely Thomas> against this idea, in that they restrict what I can do Thomas> with the code to only things that are similarly Thomas> 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?

I think your example is a little flawed, I'd see it like this: Is the patient conscious? Is he still holding his gun? If yes, get the hell away. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

Op vrijdag 26-09-2008 om 11:45 uur [tijdzone -0400], schreef Stefan Monnier:

...

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?

My answer would be that he indeed should, at the condition that the patient will switch side. Oh wait, that's just what the GPL says.

This is a good requisition if he is sure that he is on the right side of the battle, which is a assumption the soldier probably does, but should the doctor do it too? Accept my truth or die.

Stefan "Analogies are broken"

Analogies doesn't have the pretension of being perfect. If they were, they wouldn't be analogies. Greetings. -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

Jonathan Cast wrote:

On Fri, 2008-09-26 at 13:01 -0300, Marco Túlio Gontijo e Silva wrote:

...

Op vrijdag 26-09-2008 om 11:45 uur [tijdzone -0400], schreef Stefan Monnier:

...

...

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?

My answer would be that he indeed should, at the condition that the patient will switch side. Oh wait, that's just what the GPL says.

This is a good requisition if he is sure that he is on the right side of the battle, which is a assumption the soldier probably does, but should the doctor do it too?

Yikes. I should go create a /. thread for this to move to.

The standard practise: http://en.wikipedia.org/wiki/Triage has enough moral compensations by itself to make you gulp. Medical personnel, in general, doesn't care about sides, morals or any such bickering but helps. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

Jonathan Cast wrote:

On Fri, 2008-09-26 at 18:26 +0200, Achim Schneider wrote:

...

Jonathan Cast wrote:

...

On Fri, 2008-09-26 at 13:01 -0300, Marco Túlio Gontijo e Silva wrote:

...

Op vrijdag 26-09-2008 om 11:45 uur [tijdzone -0400], schreef Stefan Monnier:

...

...

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?

My answer would be that he indeed should, at the condition that the patient will switch side. Oh wait, that's just what the GPL says.

This is a good requisition if he is sure that he is on the right side of the battle, which is a assumption the soldier probably does, but should the doctor do it too?

Yikes. I should go create a /. thread for this to move to.

The standard practise:

http://en.wikipedia.org/wiki/Triage

has enough moral compensations by itself to make you gulp.

Huh? Has that page been edited since you last looked at it? It doesn't say a thing about military practice, specifically, except that it originated *behind the French lines* in WWI, which I guess is where all those German soldiers were taken so they could be patched up and returned to their own side.

Indeed it doesn't and neither did my civil protection training, and I didn't intend to post a link containing such information. I wasn't told anything about enemies, either, but since I'd be there in official office, not helping would not only mean risking getting sentenced on the grounds of failure to aid, but negligent homicide. I don't know about military paramedics, but the same law should apply. Self-preservation, OTOH, is the first duty of all medical personnel. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

On Fri, 2008-09-26 at 09:48 -0700, Jonathan Cast wrote:

On Fri, 2008-09-26 at 18:50 +0200, Achim Schneider wrote:

...

Jonathan Cast wrote:

...

On Fri, 2008-09-26 at 18:26 +0200, Achim Schneider wrote:

...

Jonathan Cast wrote:

...

On Fri, 2008-09-26 at 13:01 -0300, Marco Túlio Gontijo e Silva wrote:

...

Op vrijdag 26-09-2008 om 11:45 uur [tijdzone -0400], schreef Stefan Monnier: > > 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? > > My answer would be that he indeed should, at the condition > that the patient will switch side. Oh wait, that's just what > the GPL says.

This is a good requisition if he is sure that he is on the right side of the battle, which is a assumption the soldier probably does, but should the doctor do it too?

Yikes. I should go create a /. thread for this to move to.

The standard practise:

http://en.wikipedia.org/wiki/Triage

has enough moral compensations by itself to make you gulp.

Huh? Has that page been edited since you last looked at it? It doesn't say a thing about military practice, specifically, except that it originated *behind the French lines* in WWI, which I guess is where all those German soldiers were taken so they could be patched up and returned to their own side.

Indeed it doesn't and neither did my civil protection training, and I didn't intend to post a link containing such information.

I wasn't told anything about enemies, either, but since I'd be there in official office, not helping would not only mean risking getting sentenced on the grounds of failure to aid, but negligent homicide.

I don't know about military paramedics, but the same law should apply.

I don't trust your instincts w.r.t. `should' as applied to the military.

Nevertheless, this thread has gone *far* off-topic. It no longer has any relation to software licensing, software, or Haskell, and I will personally no longer contribute to it. I will also be deleting any further emails unread. jcc

Thomas Davie wrote:

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.

Btw: The BSD license is GPL-compatible, it's the CDDL that's not. Blame Sun, not the GPL. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

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

On Sun, Sep 28, 2008 at 12:20 PM, 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

Wolfgang Jeltsch wrote:

Am Freitag, 26. September 2008 09:24 schrieb Magnus Therning:

...

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.

That utterly depends on circumstance. Consider SDL and e.g. the id engine: Indeed every SDL user is given the freedom to link the engine to any SDL version he chooses, thus making it possible for arcane-private-os user XYZ to quake to his heart's content. The BSD is geared towards freedom of developers, the LGPL is geared towards freedom of developers _and_ users, the GPL itself towards freedom of all software. As with everything trying to influence everything that isn't itself everything, it has serious issues with reality compatibility. I still think that the proper solution to the OP's problem isn't yet another licence those vultures called lawyers can nitpick about, but to support painless dynamic linking. That means statically compiling Haskell to a .so or, preferable for applications that are written in Haskell, loading .hi/.ho combinations or even whole collections of those packed in a .hso or something. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

Hello Magnus, Saturday, September 27, 2008, 3:48:27 PM, you wrote:

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.

compiled haskell module represented in ghc as a .hi+.o files, installed libraries as a .a plus a set of .h files (you may find lots of .hi in your ghc installation) afaiu, .hi files contains parts f source haskell code in some partially compiled form. ability to perform inter-module and inter-library inlining is a key to efficiency of ghc-compiled programs, specially for polymorphic functions. when you use such functions as head, you are definitely got them inlined -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 2008 Sep 27, at 11:59, Simon Marlow wrote:

Magnus Therning wrote:

...

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?

When optimisation is turned on, you have virtually no control over how much code GHC will copy from one module to another, which is why several people (me included) have expressed concerns about the use of an unmodified LGPL with Haskell code in the past. I believe at one stage we even asked for clarification from the FSF, but I don't recall getting an answer.

As for confirmation, try ghc --dump-iface on a .hi file, often you will see GHC Core in the .hi so that it can be inlined in modules importing it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

"Magnus Therning" wrote:

On Sat, Sep 27, 2008 at 4:59 PM, Simon Marlow wrote: [..]

...

...

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?

When optimisation is turned on, you have virtually no control over how much code GHC will copy from one module to another, which is why several people (me included) have expressed concerns about the use of an unmodified LGPL with Haskell code in the past. I believe at one stage we even asked for clarification from the FSF, but I don't recall getting an answer.

Thanks for this clarification. In my limited understanding of licenses this would mean that in the Haskell world LGPL and GPL basically are the same. I suppose it's an excellent example of just how difficult it is for "law" to keep up with technology, even when the "law" is written by technologists.

I guess it means I might as well relicense all my Haskell code under GPL instead.

I'm also disappointed to hear that the FSF hasn't bothered responding to this issue. What part of the FSF was approached? Does someone still have copies of the letters/email that was sent?

IMHO, and IANAL, inlining core from .hi's shouldn't be any different than calling a macro out of a .h... http://www.wxwidgets.org/about/newlicen.htm might be an interesting read regarding that topic, as wxwidgets heavily relies on macros for declarations. In another sphere (lua, that is) there is spring[1], whose developers more or less say that the FSF has lost its mind by interpreting mods as derived works, thus requiring them to be published under the GPL. [1] http://spring.clan-sy.com -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

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

"Bit Connor" 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

magnus:

2008/9/29 Bit Connor : [..]

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

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

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

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

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 ==============================================================================

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

On Fri, 2008-10-03 at 10:08 -0700, David Leimbach wrote:

On Fri, Oct 3, 2008 at 4:36 AM, minh thu wrote: 2008/10/3 Mitchell, Neil :

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

On Thu, Oct 2, 2008 at 11:25 AM, Wolfgang Jeltsch < g9ks157k@acme.softbase.org> 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

On Mon, Sep 29, 2008 at 10:39 PM, Don Stewart wrote:

magnus:

...

2008/9/29 Bit Connor : [..]

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

"Jeremy O'Donoghue" 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

On Tue, Sep 30, 2008 at 8:54 PM, Stefan Monnier wrote:

...

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.

It *does* allow commercial use. Your example just shows that some people may decide not to take advantage of it, based not on problematic restrictions but just on paranoia.

I was confused and worried about this subject lately, too; at some point in the future, I may want to ship closed-source commercial software that uses various LGPL libraries. But it doesn't seem to be as big a problem as I imagined. My understanding is that I can satisfy the requirements of the LGPL by dynamically linking, and that's already happening. Is there something else to worry about? I'd be in violation if I shipped something statically linked, but cabal doesn't seem inclined to do that by default.

On Wed, Oct 1, 2008 at 3:31 AM, brian wrote: [..]

as big a problem as I imagined. My understanding is that I can satisfy the requirements of the LGPL by dynamically linking, and that's already happening. Is there something else to worry about? I'd be in violation if I shipped something statically linked, but cabal doesn't seem inclined to do that by default.

I'm not sure I understand you here. Would you clarify your words here, bearing in mind that GHC doesn't do dynamic linking of Haskell modules? Cheers, M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Just a small nuance to what Don wrote:

* Haskell libraries are always statically linked and agressively inlined,

But only for GHC (and jhc?).

so opinion seems to be that LGPL licensed *Haskell libaries* are unsuitable for any projects you want to ship commercially, without source code.

Unless you use a different compiler. Regards, Malcolm "keeping the dream of multiple implementations alive" Wallace

Don "thinking that compiler developer fragmentation doesn't help now the language research is 'done'"

Language researchers should move to a new language? Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/

| > Unless you use a different compiler. | > | > Malcolm "keeping the dream of multiple implementations alive" | | And keep dividing our compiler teams' efforts, while | single-implementation languages conquer :) | | Don "thinking that compiler developer fragmentation doesn't help now the language research | is 'done'" Don, I usually agree with almost everything you say -- but not this! I think diversity in compilers is good. They tend to focus on different aspects (e.g. one might be small and accessible while another is more fully-featured but harder to modify), they keep each other on their toes, they serve as vehicles to explore different parts of the design space (eg jhc's implementation model is very different to ghc's). Furthermore, language research in Haskell is *far* from done. I regard GHC as a research platform, not as a product. These goals are in tension but not in conflict -- GHC's usefulness as a research platform is derived in large part from the fact that it is so widely used, which in turn is because it is a decent product. Yes, splitting effort has costs, and those costs are particularly apparent to you because of your fantastic work on libraries, packaging, and distribution. But diversity also has benefits that I would hate to lose. Much as I love GHC, my first baby, I'm glad GHC has siblings. Simon

Hello Don, Thursday, October 2, 2008, 12:07:47 PM, you wrote:

...

Don, I usually agree with almost everything you say -- but not this!

and i usually answer only in those few cases when i disagree ;)

My point was really that investing the effort required to get nhc98 into the shape that we could actually use it to ship the kind of code that we do with GHC -- to make nhc98 a GHC competitor product -- would not be as an efficient use of our researchers and engineers.

imho it's true for short-term, false for a longer terms. we need different haskell platforms, otherwise haskell will eventually die, and core libraries such as FPS are essential part of these platforms and according to my experience, writing s/w in portable way is easy if you care about it from the beginning of project. adding portability later costs much more -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2008/10/2 Darrin Thompson

On Wed, Oct 1, 2008 at 4:00 PM, Don Stewart wrote:

...

And keep dividing our compiler teams' efforts, while single-implementation languages conquer :)

Seems like Haskell has a pretty clear story about which is the right implementation for general purpose use. I don't see a Scheme problem here.

Just make Haskell more difficult to implement than Scheme and you've preemptively avoided that problem :-)

-- Darrin

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Gour wrote:

...

...

...

...

...

"Don" == Don Stewart writes:

Don> * Only a small percent of Haskell libarires are LGPL, and Don> nothing for which we don't have workarounds (e.g. HDBC vs Don> galois-sqlite3 vs takusen).

Hmm, Gtk2Hs & wxhaskell - major GUI libs...

wxHaskell uses a modified LGPL license (wxWidgets license). One that allows static linking. See http://www.haskell.org/haskellwiki/WxHaskell/License . From the description of the wxWidgets license http://www.wxwidgets.org/about/newlicen.htm : "The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWidgets, and also those producing proprietary software." Greetins, Mads Lindstrøm

Sincerely, Gour

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

brian wrote:

On Tue, Sep 30, 2008 at 8:54 PM, Stefan Monnier wrote:

...

...

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. It *does* allow commercial use. Your example just shows that some people may decide not to take advantage of it, based not on problematic restrictions but just on paranoia.

I was confused and worried about this subject lately, too; at some point in the future, I may want to ship closed-source commercial software that uses various LGPL libraries. But it doesn't seem to be as big a problem as I imagined. My understanding is that I can satisfy the requirements of the LGPL by dynamically linking, and that's already happening.

Dynamic linking doesn't solve all the problems, we still have the problem that GHC does a lot of cross-module inlining, regardless of whether dynamic linking is used. However, I really would like to have a way to have complete control over what is exposed across a package boundary. We need this not just for licensing reasons, but also for making a dynamic library with a fixed ABI, so it can be upgraded later. Incedentally the lack of this feature is one reason I've not being rushing to get shared libraries into GHC. They're just not that useful unless you can upgrade a library independently of the things it depends on. Cheers, Simon

Magnus Therning wrote:

On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow wrote: [..]

...

Dynamic linking doesn't solve all the problems, we still have the problem that GHC does a lot of cross-module inlining, regardless of whether dynamic linking is used. However, I really would like to have a way to have complete control over what is exposed across a package boundary. We need this not just for licensing reasons, but also for making a dynamic library with a fixed ABI, so it can be upgraded later.

I have a really hard time following this. Are you seriously saying that GHC is inlining code from modules _and_ link dynamically at the same time. That seems like a remarkably strange thing to do, or maybe I'm just missing something.

That's exactly what would happen, if we shipped dynamic linking support with GHC as it stands. It's just a linking mechanism, an alternative to static linking, and has no impact on the amount or nature of inter-module optimisation that GHC does.

My understanding from another thread on here was that dynamic linking isn't working reliably, not even on Windows, where it once was supported. It has never worked on any other platform.

The fundamental mechanisms are working on {x86, x86-64, PPC, PPC64} / {Linux, OS X, Windows} and possibly other OSs. However right now you need a few small patches to the source tree to get it to build. Most of the unresolved issues are around how to construct binary installs, and how executables will find their libraries when the run (e.g. if you install GHC privately in your home directory). Cheers, Simon

On Fri, 2008-10-03 at 16:25 +0100, Magnus Therning wrote:

Ah, now I understand. The object for GHC would be to reduce the system-wide use of memory rather than substitutability of DLLs then, right?

Why would it be interesting to have sharable objects without substitutability?

Hello world and plugins you want to load into foreign programs would be a few k rather than a few hundred or a few thousand k. Being able to substitute is something that may be possible later, at least for some packages. Simon has been mulling over some of the possibilities here. One idea is if you specifically want to build a .so or .dll with a stable ABI then you could declare that's what you want to do, and then not do cross-module inlining by default (except for those functions marked INLINE) then you can guarantee you're not breaking ABI so long as you do not change the types of exported functions or the implementations of functions marked INLINE. Extending the ABI in a compatible way needs more thought about a suitable mechanism. Duncan

On Tue, 30 Sep 2008 21:54:34 -0400, "Stefan Monnier" said:

...

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. [...] 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.

It *does* allow commercial use. Your example just shows that some people may decide not to take advantage of it, based not on problematic restrictions but just on paranoia.

The LGPL does not state that a "work that uses the library" may be distributed in conjunction with a closed source commercial program, although I grant that many (presumably including some who have actually consulted lawyers) believe that such an interpretation is reasonable. However, the policy in place in my workplace was designed by lawyers familiar with contract law in multiple jurisdictions worldwide. I may not personally agree with their conclusions in every respect, but I'd be hard pressed to consider them "paranoid" - they are simply doing their job, and have concluded that the potential risk of a court somewhere in the World taking an aggressive view of the provisions of clause 5 is unacceptable. I guess what I really mean is that if you choose LGPL as a license, some people who would like to use it in commercial products will do so, but others (who would have chosen to use the work if differently licensed) will not. Not a question of paranoia so much as corporate appetite for license risk. Regards Jeremy -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com

The GPL and LGPL are needlessly difficult for mere mortals to understand in their entirety, and as you've alluded to, many lawyers would interpret it differently. I suspect many different judges would too.

I think the evidence is rather to the contrary. Most lawsuits involving the GPL are settled out of court, precisely because the lawyers for the violating party tend to realise they have no leg to stand on. Of those few cases which have made it to court, the judge has always decided in favour of the GPL. That is, the GPL is as solid a guarantee of code freedom as you could wish for. The lesson, from the point of view of an entity that wants to distribute non-free code but making use of some free code, is simply to play nicely with the community whose work you are using gratis. Keeping to the original authors' intent is ultimately cheaper than either writing your own replacement code, or paying lawyers to fight it out. In addition, if you want legal certainty , most GPL authors would probably be happy to assign you a separate non-exclusive commercial license, in return for a small payment or royalty agreement. Regards, Malcolm