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

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 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 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

...

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,

...

+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 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

...

...

exception in your (L)GPL license, it still may not hold up! Although

...

...

entire idea is untested in court, GHC can (and will!) inline

On Wed, Dec 12, 2012 at 2:12 PM, Jonathan Fischer Friberg wrote: linking the 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 wrote:

...

On Wed, 12 Dec 2012 10:06:23 +0100 Petr P

wrote:

...

> 2012/12/12 David Thomas > > 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

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

-- Felipe.

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

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

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