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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >>> 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 >>> <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> wrote: >>> >>> >>> >>> On Wed, 12 Dec 2012 10:06:23 +0100 Petr P <[email protected]> >>> wrote: >>> >>> >>> >>> > 2012/12/12 David Thomas <[email protected]> >>> >>> > >>> >>> > 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 >>> >>> [email protected] >>> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Haskell-Cafe mailing list >>> >> [email protected] >>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >>> > >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > [email protected] >>> > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >>> >>> -- >>> Felipe. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
