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

On Thu, Dec 13, 2012 at 5:36 AM, Felipe Almeida Lessa < felipe.lessa@gmail.com> wrote:

A GPLed containers forces the library user to somehow get a way of complying to the license.

The language here needs some clarification: the GPL (or other free copyleft license) only "forces" someone to do something under very particular circumstances, which could be characterised as: 1. They are planning on distributing non-free software, and, 2. They haven't made a special agreement with the copyright holder. I would hope that condition 1 does not hold for a large proportion of library users. Those users should not be scared away from copyleft. Using it has the advantage of offering a reason to push those on the fence about whether to make their software free.

On Thu, 13 Dec 2012 08:58:07 +1100 Ramana Kumar wrote:

...

A GPLed containers forces the library user to somehow get a way of complying to the license. The language here needs some clarification: the GPL (or other free copyleft

On Thu, Dec 13, 2012 at 5:36 AM, Felipe Almeida Lessa < felipe.lessa@gmail.com> wrote: license) only "forces" someone to do something under very particular circumstances, which could be characterised as: 1. They are planning on distributing non-free software, and,

Or using a free license that isn't compatible with the GPL, or incorporating software that is covered by such a license. You can find a list of these licenses at: http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses and following, which lists licenses used for open source but aren't considered free licenses by the GNU folks. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

On Thu, Dec 13, 2012 at 10:14 AM, Colin Adams wrote:

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.

Presumably you are talking about companies who want to distribute programs (a very small minority of companies, I would think)?

No, read my use case again. I was creating a web application for a company. The company was not going to distribute my code in any way to their clients. Nonetheless, the company had a corporate policy to not use *any* copyleft licenses, and therefore I was unable to use a library such as Pandoc. (I believe this policy affected me at two separate companies, but I don't remember all the details tbh.) I also don't think that distributing programs is as small a market as you think, and should also be something we support for commercial users of Haskell. Michael

On Thu, Dec 13, 2012 at 11:35 AM, Ramana Kumar wrote:

On Thu, Dec 13, 2012 at 8:09 PM, Michael Snoyman wrote:

...

I also don't think that distributing programs is as small a market as you think, and should also be something we support for commercial users of Haskell.

Distributing programs commercially is compatible with distributing them as free software. I think it would be helpful not to use "commercial users" to refer to both those with policies against copyleft licenses and those who make money distributing software. Those groups are not even extensionally equal, and separating them further (by having companies reconsider such policies) is, I would think, an instrumental goal of the free software movement, which is one reason why these tensions arise.

I'm not saying that *every* commercial user of Haskell has these concerns. But I think it's a fair statement to say that a very large number of commercial users do not wish to give out their source code. If you want to claim that this isn't a commercial concern, but simply a concern of many companies, that's fine, but I think it's irrelevant to the point: in many cases, you will be unable to use GPLed libraries when creating software for companies. Ignoring semantics, are you arguing with that claim? If you want to try and convince companies to change their software policies by writing some incredibly compelling GPL libraries, more power to you, and I wish you the best. But I think that's quite separate to the question of whether usage of the GPL today will hinder your ability to sell your products or services to a company. Michael

On 12/13/12 3:14 AM, Colin Adams wrote:

Presumably you are talking about companies who want to distribute programs (a very small minority of companies, I would think)?

Not at all. In addition to Michael's own rebuttal, I'll add my own. There are many companies which *fear* the L/GPL. The important thing to note here is this: The Actual Legal Requirements of Copyleft Licenses are IRRELEVANT. This simple fact is consistently ignored by advocates of the GPL (of which I number myself, FWIW). The great majority of all software produced in the world is developed for in-house use, and thus would not be subject to any of the "bad" side effects from using copyleft software. And yet, in spite of this fact, there are a great many companies which have official policies forbidding the use of copyleft software. Why is that? It's because companies have legal departments whose jobs it is to ensure that the company won't be destroyed by legal action. And because there isn't an extensive record of actual court rulings regarding purported violations of the GPL, lawyers are rightly wary of it. Companies do not (generally) avoid the GPL because of understanding its requirements and refusing to abide by them. Companies avoid the GPL because they do not know what it means! More particularly, because they do not know what the courts will think it means, and that's too much uncertainty to risk your company over. Any actual commercial burden imposed by the GPL re distributing software is beside the point. Corporate lawyers (for these companies) won't risk getting close enough to even evaluate what that burden would amount to. -- Live well, ~wren

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

On 12/13/12 9:30 AM, Herbert Valerio Riedel wrote:

Alfredo Di Napoli writes:

...

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.

just to throw in a different argument: there's also the concept of dual-licensing[1,2] to accomodate both the F/OSS users as well as the commercial users...

I'm a big fan of dual-licensing. It's an underutilized tactic for overcoming the competing forces of commercial success and F/OSS success. Moreover, in my experience, those companies which refuse to have anything to do with the GPL tend to be more than willing to pay for a corporate license. Just remember: money isn't evil, it's proprietarism that's evil. -- Live well, ~wren