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

Thu Dec 13 09:15:00 CET 2012

Let me just chime in to give my 2 cents; I quote Micheal 100%; if we want
to push Haskell out of the academic/open source world to the "real world",
well, GPL is not the way to go, due to its viral nature.

Cheers,
A.

On 13 December 2012 08:09, Michael Snoyman <michael at snoyman.com> wrote:

> To take this out of the academic realm and into the real-life realm: I've
> actually done projects for companies which have corporate policies
> disallowing the usage of any copyleft licenses in their toolset. My use
> case was a web application, which would not have been affected by a GPL
> library usage since we were not distributing binaries. Nonetheless, those
> clients would not have allowed usage of any such libraries. You can argue
> whether or not this is a good decision on their part, but I don't think the
> companies I interacted with were unique in this regard.
>
> So anyone who's considering selling Haskell-based services to companies
> could very well be in a situation where any (L)GPL libraries are
> non-starters, regardless of actual legal concerns. This affects the open
> source realm as well, because I think many of us want our libraries to be
> commercial-friendly (I know this is the case for Yesod).
>
> As one specific data point, I initially created the markdown package[1]
> because I couldn't use pandoc[2] in one of these situations due to its GPL
> license.
>
> MIchael
>
> [1] http://hackage.haskell.org/package/markdown
> [2] http://hackage.haskell.org/package/pandoc
>
>
> On Thu, Dec 13, 2012 at 10:00 AM, Petr P <petr.mvd at gmail.com> wrote:
>
>>   Hi Felipe,
>>
>> thanks for making me think about the licenses. Without your suggestion, I
>> wouldn't be aware of problems LGPL might cause for Haskell projects. And
>> I'm considering the possibility of using BSD (or a similar) license in the
>> future.
>>
>> I'm aware of the issues you pointed out. As you say, since tie-knot is a
>> small library, it's not really that important what license it has, it's
>> easy to re-implement it if needed. And, until some else contributes to the
>> library, anybody can ask me to release the code under a different license,
>> if needed.
>>
>> I'd say that the recent debate was a bit academic. (That wasn't bad at
>> all, it clarified many things for me.) Nobody actually said "I want to use
>> the library, but I cannot because of the license". Also we're talking about
>> LGPL, not GPL, and this makes thing different. Consider this: All packages
>> on Hackage have published their source codes. (More than 95% are open
>> source, and it's likely that those in "OtherLicence" are too.) With public
>> source codes, there is no problem using a LGPL-ed library! Anybody can
>> write a BSD licensed program which uses a LGPL library, and because all
>> sources are public, the requirement to allow re-linking is easily
>> satisfied. And nobody is forced to (L)GPL (unless the library is modified).
>> We can freely mix open-source projects that use LGPL and non-copyleft
>> licenses. The "LGPL problem" manifests only when someone wants to keep
>> source codes secret - then (s)he is forced to solve the problem with
>> re-linking. [With GPL, this would be very different, the whole project
>> would have to be GPL no matter what.]
>>
>> I think it would be interesting to make some kind of poll to see what
>> kind of software Haskell community writes (FOSS vs closed source) and what
>> licensing issues people have. But the usual problem with such polls is that
>> only people who have problems vote, so the results are very biased.
>>
>>   Best regards,
>>   Petr
>>
>>
>> 2012/12/12 Felipe Almeida Lessa <felipe.lessa at gmail.com>
>>
>>> 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.
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121213/0c203430/attachment.htm>