2012/12/12 David Thomas
<davidleothomas@gmail.com>
IANAL, but reviewing what others have written, it sounds like it may be possible to maintain *some* distinction between LGPL and GPL in Haskell, but it's a different distinction than with an LGPL shared library, so even if applicable it's certainly worth being aware of.
It sounds (and I'd very much like clarification) like providing source of an application to users *without* license to redistribute, which can be built using an LGPL library, would be compliant - whereas if the library was GPL this would not be the case?
As I understand it, this is one of the main differences: Using GPL-ed library forces the entire Combined Work to be GPL-ed (requiring to release the source codes), while using LGPL-ed library forces only the possibility to re-link with another version of it - you can distribute your own sources to users with whatever license you like (unless it's a modification of the library, of course). This could be an interesting question for FSF.
Thanks to all for valuable comments. I didn't want to start a discussion about (L)GPL vs others, but since that already happened, let me give my opinion:
The problem with LGPL is that it is apparently tailored to languages that strongly rely on dynamic linking. TBH I wasn't aware of this before. One solution (taken by wxWidgets for example) is to modify LGPL so that they explicitly allow distributing the software without the re-linking requirement (which grants a little less rights to end users). I tried asking that on StackExchange: "Is there a modified LGPL license that allows static linking?" <
http://programmers.stackexchange.com/q/179084/61231>
Anther solution would be to focus on improvements of dynamic linking. Some links I found:
Yet another solution would be what David Thomas suggest: To provide the source code to your users, but don't allow them to use the code for anything but relinking the program with a different version of the library (no distribution, no modification etc.).