Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:

Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to.

I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only allows linking, as far as I understand. I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library. Best wishes, Wolfgang

Conrad Meyer wrote:

On Wednesday 25 February 2009 07:47:16 am Wolfgang Jeltsch wrote:

...

Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:

...

Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only allows linking, as far as I understand.

I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library.

Best wishes, Wolfgang

Alternatively Haskell could add shared library support, like every other language.

As has already been discussed on this list, shared library support to obtain substitutability of libraries is problematic in a language like Haskell too, at least AFAIU. Just consider cross .o inlining... (Using shared libraries in order to decrease system-wide memory footprint of Haskell binaries is however a bit easier.) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts

On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek wrote:

* An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library.

Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine...

So that is interesting. If you don't distribute a program that makes use of LPGL libs (e.g. a downloadable EXE), but you provide a remote view (in this case a web) on a server that runs that program, then the license does not apply... Oh well I should just let the lawyers look into all these licenses, it's not my domain. 2009/2/25 Tristan Seligmann

* Peter Verswyvelen [2009-02-25 23:15:24 +0100]:

...

On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek wrote:

...

* An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library.

Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine...

Google doesn't distribute code or binaries for google.com, though (although there is the appliance stuff..) -- mithrandi, i Ainil en-Balandor, a faer Ambar

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmlx4YACgkQpNuXDQIV94rO6gCeLp5pkzXQkXIfFmwwCSWHQX3o QscAn1ipd1Sft/K5QKiYtT9y15ssdnrk =sZXJ -----END PGP SIGNATURE-----

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

Peter Verswyvelen wrote:

On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek wrote:

...

* An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library.

Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine...

I think so. If you acknowledge them as legitimate users and you distribute the free program then you must allow them to upgrade the LGPL library. With Haskell this may mean releasing the source code. I'm vary about this part though. *.o and *.hi may be enough since: * GHC is not LGPL but some kind of BSD * only the gmp and gtk2hs are LGPL * so you do not need to make sure ghc can be upgraded * you need to make sure gmp can be upgraded and gtk2hs can be upgraded but forcing users on the same version of ghc * requirement to allow upgrade is there only while the LGPL library does not change interface The above should allow to distribute only *.o and *.hi files. If user wants to to upgrade GMP or GTK2HS they can do it and recompile with the old version of GHC (the one for which you provided *.o and *.hi files. So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking script are OK too As for as Google: That is a different case. The GPL/LGPL limitations kick in *only* when you redistribute your program. Goolge is not redistributing their search engine! They only provide you a service over internet! That is very different. Peter.

Wolfgang Jeltsch wrote:

Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek:

...

So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking script are OK too

I think, it’s technically not possible to let your Haskell application use another library version when you just have the .o and .hi files of the new library version. The .hi files typically contain code which is inlined by the application, so you have to be able to recompile the application. Or am I misunderstanding you?

You may be right. I do not know. Compiler authors would know. But if the *only* problem is the inlined functions then it may not be that bad. Depends whether the depth of inlining has some limit and whether a change of code which is not inlined any more results in failure to link correctly too. The point is that inlining itself is not a problem simply the code which is inlined represents the interface and you need to provide an option to upgrade to a newer library with the same interface only. The same problem is with shared objects in C. The header files may contains macros (which are inlined) and you are not forced to provide source code of your app despite the fact that compilation inlines some code from the LGPL library used. Simply that code is part of the interface and changing it changes the interface. The acceptable size of inlined fuctions for a C code is about 10 lines. I did not read any info how it would be for Haskell. Peter.

Peter Hercek writes:

...

Relinking against newer Gtk2Hs versions might not work.

You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you?

...

I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it.

Of course there is a difference and a *significant* one.

* A GPL library will force commercial users of the library to release their code under GPL.

* An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library.

Am I missing something?

Yes. At least in my jurisdiction, the *intent* of the licensing matters. I think it is fair to say that the intent of the LGPL is maintaned as long as you redistribute any modifications you make to the LGPL library. An easy thing to do here would be to get a written statement from the author about the interpretation with regard to what you intend to do - like Duncan posted.

...

If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library

There is also a rather significant difference for open source software - if I use BSD, somebody might modify and ship closed versions of my library. If I use LGPL, somebody can combine it with other open source code, with licenses that may not be GPL-compatible. So I believe LGPL is less "viral" than GPL. This is just opinion, but if you wanted guarantees, you'd talk to a lawyer, and not post on a mailing list. -k -- If I haven't seen further, it is by standing in the footprints of giants

Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:

Peter Hercek writes:

...

...

Relinking against newer Gtk2Hs versions might not work.

You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you?

Relinking is technically not possible because of inlining. Best wishes, Wolfgang

Am Donnerstag, 26. Februar 2009 20:20 schrieb Achim Schneider:

Wolfgang Jeltsch wrote:

...

Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:

...

Peter Hercek writes:

...

...

Relinking against newer Gtk2Hs versions might not work.

You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you?

Relinking is technically not possible because of inlining.

I don't think the situation is any different from providing C headers that contain macros or inline functions.

But as Peter Hercek said, the LGPL limits the amount of macro expansion for C libraries. And the amount of GHC’s inlining would probably exceed all limits. ;-) Best wishes, Wolfgang

On Wed, 2009-02-25 at 16:47 +0100, Wolfgang Jeltsch wrote:

Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:

...

Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to.

I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know.

I recall from a FSF FAQ on this issue that it doesn't need to be easy, just technically possible. There does not need to be a well designed stable ABI.

Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking.

It is pure linking. It's just not easily achievable from the source level using standard compilers and tools. Yes if you change the sources you change the ABI (even when you did not change the API). That's not a problem as far as the license is concerned (I think).

However, the LGPL only allows linking, as far as I understand.

I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library.

But of course that is not the only difference. Assuming we can work around the linking issue the main point for someone to choose LGPL is guaranteeing that changes are contributed back. We should not tell people who want to use LGPL that they should just use BSD. That's changing the spirit of the license for the sake of a mere technicality. If they want to use the LGPL then we should encourage them to use a linking exception. It's also worth looking at what the LGPL-3 has done about this issue. Duncan (who takes no position on BSD vs LGPL and has used both)