[Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Felipe Almeida Lessa]

When deciding what license to use, I think one should also think about
the role of their library.  For example, containers is quite central
to the Haskell community and not easily replaceable.  The tie-knot
library, OTOH, may be rewritten from scratch or even just skipped
(just tie the knot yourself).  A GPLed containers forces the library
user to somehow get a way of complying to the license.  A GPLed
tie-knot, OTOH, may be just ignored.

What I'm trying to say is that if your library is nice but someone may
just rewrite it without much effort, then using GPL will just drive
potential users of your library away, which is bad not just for the
library but also for those potential users as well.  Perhaps you have
a nice library but it may be replaced (with some small pain) by
another, similar library.

(In particular, I'm not saying that tie-knot is a library that should
be ignored.  On the contrary, I think it's quite nice and it would be
a shame if I had to ignore it when tying a knot just because of its
restrictive license.)

Of course, if everything on Hackage was GPLed, then it wouldn't make
sense to release something as BSD as you wouldn't be able to use it
anyway.  But the reality right now is that we have:

("Apache",3)
("BSD3",3359)
("BSD4",3)
("MIT",269)
("PublicDomain",142)

("GPL",409)
("GPL-2",27)
("GPL-3",147)
("LGPL",138)
("LGPL-2",2)
("LGPL-2.1",25)
("LGPL-3",21)

("OtherLicense",179)

This data comes from a quick shell session while considering the
latest .cabal of all Hackage packages, so take it with a grain of salt
=).

Cheers,

On Wed, Dec 12, 2012 at 2:12 PM, Jonathan Fischer Friberg
<odyssomay at gmail.com> wrote:
> +1
>
> Very similar to my point (see original thread), but put in a better way. :)
> As an interesting coincidence, this exact thing happened to someone
> just now. (thread "containers license issue")
>
> Jonathan
>
> On Wed, Dec 12, 2012 at 5:00 PM, Clark Gaebel <cgaebel at uwaterloo.ca> wrote:
>> Since we've already heard from the aggressive (L)GPL side of this "debate",
>> I think it's time for someone to provide the opposite opinion.
>>
>> I write code to help users. However, as a library designer, my users are
>> programmers just like me. Writing my Haskell libraries with restrictions
>> like the (L)GPL means my users need to jump through hoops to use my
>> software, and I personally find that unacceptable. Therefore, I gravitate
>> more towards BSD3 and "beer-ware" type licenses. This also means my users
>> aren't subjected to my religious views just because they want to use my
>> "ones and zeros".
>>
>> Also, with GHC's aggressive inlining, even if you do have a static linking
>> exception in your (L)GPL license, it still may not hold up! Although the
>> entire idea is untested in court, GHC can (and will!) inline potentially
>> huge parts of statically linked libraries into your code, and this would
>> force you to break the license terms if you were to distribute the software
>> without source code. In Haskell-land, the GPL is the ultimate in viral
>> licensing, and very hard to escape.
>>
>> That's why I don't use (L)GPL licenses.
>>
>> Just making sure both sides have a horse in this race :)
>>   - Clark
>>
>>
>> On Wed, Dec 12, 2012 at 9:51 AM, kudah <kudahkukarek at gmail.com> wrote:
>>>
>>> On Wed, 12 Dec 2012 10:06:23 +0100 Petr P <petr.mvd at gmail.com> wrote:
>>>
>>> > 2012/12/12 David Thomas <davidleothomas at gmail.com>
>>> >
>>> > 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.).
>>>
>>> You can also provide object code for linking, though I'm sure this
>>> will not work with Haskell object files. Providing alternative
>>> distribution of your program linked dynamically, or a promise to
>>> provide one on notice, also satisfies the LGPL as long as
>>> dynamic-version is as functional as the static and can be dropped-in
>>> as a replacement.
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Felipe.