On Wed, 2004-06-30 at 07:15, Dan Sugalski wrote:
> In all those cases you've got a binary-only distribution, and a valid
> one. (In fact, one that we want to encourage) Section 4, by my reading,
> means you've got to ship source to the LGPL component.
Well, "provide source" might be a better way of saying it. There's no
need to ship it with your product. You just need to make it available,
and include a note saying so in your README.
> This is not, in itself, a problem--that's the license, it's a fine
> license, and we respect people's licenses. Unfortunately adopting it means
> putting what I'd consider an unreasonable onus on the middle-level
> people/developers/distributors, and I don't want to do that.
So, if I understand, your worry is not so much about the technical
difficulty of complying with the LGPL (which appears trivial), but more
along lines of the BSD Attribution Clause? (Summary: BSD's requiring
attribution seemed perfectly reasonable at first, but it got out of hand
pretty as the number of BSD-licensed packages grew. Heck, half of some
product manuals were nothing but attributions...) It's true,
distributing Parrot would become onerous if it required you to also
manage the distribution of a number of other LGPLed libraries.
Parrot currently links to glibc even though glibc is LGPLed. This is
OK, though, because Parrot is able to link to alternative versions of
the C library when glibc isn't available. Maybe GMP could be handled in
the same way?
It could link to libgmp when it's available, or link to an alternative,
freer library when it's not. I know of a BSD-licensed bignum library,
but apparently it's nowhere near the quality of GMP. Allowing Parrot to
use either library gives either the performance of GMP or the freedom of
a less restricted library -- distributor's choice.
Hypothetically, in your opinion, would this be a reasonable solution?
- Scott
