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

Petr P petr.mvd at gmail.com
Thu Dec 13 09:00:30 CET 2012


  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121213/3de167e3/attachment.htm>


More information about the Haskell-Cafe mailing list