Petr P | 12 Dec 10:06 2012
Picon

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


2012/12/12 David Thomas <davidleothomas <at> gmail.com>
IANAL, but reviewing what others have written, it sounds like it may be possible to maintain *some* distinction between LGPL and GPL in Haskell, but it's a different distinction than with an LGPL shared library, so even if applicable it's certainly worth being aware of.

It sounds (and I'd very much like clarification) like providing source of an application to users *without* license to redistribute, which can be built using an LGPL library, would be compliant - whereas if the library was GPL this would not be the case?

As I understand it, this is one of the main differences: Using GPL-ed library forces the entire Combined Work to be GPL-ed (requiring to release the source codes), while using LGPL-ed library forces only the possibility to re-link with another version of it - you can distribute your own sources to users with whatever license you like (unless it's a modification of the library, of course). This could be an interesting question for FSF.


Thanks to all for valuable comments. I didn't want to start a discussion about (L)GPL vs others, but since that already happened, let me give my opinion:


The problem with LGPL is that it is apparently tailored to languages that strongly rely on dynamic linking. TBH I wasn't aware of this before. One solution (taken by wxWidgets for example) is to modify LGPL so that they explicitly allow distributing the software without the re-linking requirement (which grants a little less rights to end users). I tried asking that on StackExchange: "Is there a modified LGPL license that allows static linking?" <http://programmers.stackexchange.com/q/179084/61231>
Anther solution would be to focus on improvements of dynamic linking. Some links I found:
Haskell Static vs Dynamic Linking in Deployment <http://stackoverflow.com/q/7854614/1333025>
Small Haskell program compiled with GHC into huge binary <http://stackoverflow.com/q/6115459>
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.).

Second, it's my wish to use (L)GPL for FOSS programs I write. My opinion has varied for many years, but in recent years I strongly incline to GPL-like licenses. We all know that GPL-like licenses make life more complicated for us programmers. Programmers want to use libraries with as little restrictions as possible. The main reason for me for choosing (L)GPL despite the complications is the protection and rights it gives to the *users* of a program. Sadly, no users are actually aware of  this and what they could gain by choosing GPL-ed programs (let me know if you find a non-programmer who is aware of GPL's benefits). Just imagine if Facebook had to use AGPL, or if your mobile phone software would be all GPL. (Knowing what a program does with your data is becoming more important, like the US intelligence report suggests: http://reut.rs/UxbLtv section "Technology ..").

The other reason for me that GPL-like licenses give an advantage to FOSS developers over private companies. I feel this is fair - anybody who develops something that can be used by everyone deserves an advantage.

Another thing to consider is the aspect of adoption/marketing strategy. Using a more permissive license can make adoption of a piece of software much faster. This can be desirable in some cases, like if the OS community wants to prevent the adoption of proprietary standards (like Vorbis VS MP3). Or in the case of Haskell, to motivate private companies to use it. Richard Stallman himself recommends this in some cases http://lwn.net/2001/0301/a/rms-ov-license.php3
But if a project is strong enough, using (L)GPL can actually strengthen it, like in the case of Linux VS NetBSD: http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
To quote: "So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved."

Of course I respect other opinions in that matter, every author is free to use whatever licence (s)he likes. After all, FOSS is about freedom. The important thing to know is what advantages and drawbacks each license has and what are the consequences of using them.

  Best regards,
  Petr

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
kudah | 12 Dec 15:51 2012
Picon

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

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.
Clark Gaebel | 12 Dec 17:00 2012
Picon
Picon

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

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
Jonathan Fischer Friberg | 12 Dec 17:12 2012
Picon

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

+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
>
Felipe Almeida Lessa | 12 Dec 19:36 2012
Picon

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

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.
Ramana Kumar | 12 Dec 22:58 2012
Picon
Picon

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

On Thu, Dec 13, 2012 at 5:36 AM, Felipe Almeida Lessa <felipe.lessa <at> 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.


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brandon Allbery | 12 Dec 23:13 2012
Picon

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

On Wed, Dec 12, 2012 at 4:58 PM, Ramana Kumar <Ramana.Kumar <at> cl.cam.ac.uk> wrote:
Using it has the advantage of offering a reason to push those on the fence about whether to make their software free.

As has already been pointed out, definitions of "free" differ. 

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mike Meyer | 13 Dec 10:17 2012
Face

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

On Thu, 13 Dec 2012 08:58:07 +1100
Ramana Kumar <Ramana.Kumar <at> cl.cam.ac.uk> wrote:
> On Thu, Dec 13, 2012 at 5:36 AM, Felipe Almeida Lessa <
> felipe.lessa <at> 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,

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.

	<mike
--

-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Petr P | 13 Dec 09:00 2012
Picon

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

  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
Michael Snoyman | 13 Dec 09:09 2012

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

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



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
Colin Adams | 13 Dec 09:14 2012
Picon

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

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.

Presumably you are talking about companies who want to distribute programs (a very small minority of companies, I would think)? 
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michael Snoyman | 13 Dec 10:09 2012

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




On Thu, Dec 13, 2012 at 10:14 AM, Colin Adams <colinpauladams <at> gmail.com> wrote:
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.

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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ramana Kumar | 13 Dec 10:35 2012
Picon
Picon

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

On Thu, Dec 13, 2012 at 8:09 PM, Michael Snoyman <michael <at> snoyman.com> 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michael Snoyman | 13 Dec 11:13 2012

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




On Thu, Dec 13, 2012 at 11:35 AM, Ramana Kumar <Ramana.Kumar <at> cl.cam.ac.uk> wrote:
On Thu, Dec 13, 2012 at 8:09 PM, Michael Snoyman <michael <at> snoyman.com> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Clark Gaebel | 13 Dec 14:01 2012
Picon
Picon

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

Outside of the Valley and FOSS movement, programs are still usually distributed as binaries.

For example, I have a secret, dirty desire to write a game in Haskell. This would be closed source, and if I'd have to rewrite most of the supporting libraries, it would be a nonstarter.

Plus, it's hard enough advocating for Haskell adoption because "it's hard" or "less experienced developers won't get it". It'd rather not add "the entire ecosystem is GPL, and there's no dynamic linking" to that list if I could avoid it.

   - Clark



On Thu, Dec 13, 2012 at 3:14 AM, Colin Adams <colinpauladams <at> gmail.com> wrote:
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.

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

_______________________________________________
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
wren ng thornton | 14 Dec 06:58 2012

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

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
Steve Severance | 14 Dec 23:14 2012

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

That very much mirrors my experience. As there is not settled case law
in all jurisdictions many companies would simply rather not risk it.
Simply having a court in the US set some precedents would not be
enough. A company which operated globally could be sued in many
different venues which are free to make up their own interpretations.

While these fears may be somewhat irrational they are still there. The
cost of building a replacement to a library may be far less than what
the cost of being found guilty of infringement may be. In any case I
mostly see GPL effecting smaller organizations anyhow as many big
organizations don't use much outside code.

It is true that in a hosted world the GPL doesn't matter much. So long
as the product that we ship to our customers is not software it
doesn't matter too much. If we were to ship code we would have to
replace any GPLed packages with something else.

The other thing I have found interesting is the notion that the GPL
can infect your codecase just by looking at GPLed code. If that it is
true, and I don't know that it is, it would seem that looking at any
code released under the GPL would be just as dangerous as looking at a
patent. Although I don't know that the offending party would be liable
for triple damages. Interesting food for thought and it would be nice
if there was a clarification somewhere.

Steve

On Thu, Dec 13, 2012 at 9:58 PM, wren ng thornton <wren <at> freegeek.org> wrote:
> 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
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Alfredo Di Napoli | 13 Dec 09:15 2012
Picon

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



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


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Herbert Valerio Riedel | 13 Dec 15:30 2012
Picon

Re: LGPL and Haskell

Alfredo Di Napoli <alfredo.dinapoli <at> gmail.com> 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...

cheers,
  hvr

 [1]: http://www.linuxinsider.com/story/38172.html
 [2]: http://www.oss-watch.ac.uk/resources/duallicence2
wren ng thornton | 14 Dec 07:05 2012

Re: LGPL and Haskell

On 12/13/12 9:30 AM, Herbert Valerio Riedel wrote:
> Alfredo Di Napoli <alfredo.dinapoli <at> gmail.com> 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

Gmane