
On 11/11/2010 20:29, Duncan Coutts wrote:
On 11 November 2010 14:50, Simon Marlow
wrote: But I vote against allowing LGPL libs in. For a start, wouldn't it have to be LGPL + static linking exception anyway?
In principle no static linking exception is required. It is possible to ship code in a relinkable form.
What you do is to compile your app to .o files, link them together into one big app.o file, then link this statically with the dependent packages to make your app.exe. Then you ship the app.exe and the app.o (or a promise to provide it). Any user can then relink the app.o to get the app.exe.
I have done this and automated it with Cabal. It would probably be useful to other people to add this feature to Cabal directly (I implemented it in a Setup.hs).
Obviously it is rather tricky to generate a modified library that has the same ABI but the LGPL makes allowance for that. The LGPL-2.1 states: "It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.". Current GHC does put us at the rather extreme end of that interpretation. Of course there is the same ABI issue with shared libs.
Right, my main objection has always been that since GHC makes it impractical to do the modify/relink that the LGPL requires, LGPL Haskell code isn't really complying with the spirit of the LGPL here. I get the impression that people who use the LGPL for Haskell don't care deeply about this - they're using the LGPL because they want modifications contributed back. In which case, wouldn't it make sense to add an exception for the modify/relink too? Are there Haskell authors out there using the LGPL who really do care about modify/relink? Cheers, Simon