To take this out of the academic realm and into the real-life realm: I've actually done projects for companies which have corporate policies disallowing the usage of any copyleft licenses in their toolset. My use case was a web application, which would not have been affected by a GPL library usage since we were not distributing binaries. Nonetheless, those clients would not have allowed usage of any such libraries. You can argue whether or not this is a good decision on their part, but I don't think the companies I interacted with were unique in this regard.
So anyone who's considering selling Haskell-based services to companies could very well be in a situation where any (L)GPL libraries are non-starters, regardless of actual legal concerns. This affects the open source realm as well, because I think many of us want our libraries to be commercial-friendly (I know this is the case for Yesod). As one specific data point, I initially created the markdown package[1] because I couldn't use pandoc[2] in one of these situations due to its GPL license. MIchael [1] http://hackage.haskell.org/package/markdown [2] http://hackage.haskell.org/package/pandoc On Thu, Dec 13, 2012 at 10:00 AM, Petr P <petr....@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.le...@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 >> <odysso...@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 <cgae...@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 <kudahkuka...@gmail.com> wrote: >> >>> >> >>> On Wed, 12 Dec 2012 10:06:23 +0100 Petr P <petr....@gmail.com> wrote: >> >>> >> >>> > 2012/12/12 David Thomas <davidleotho...@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@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