On Wed, 25 Apr 2007, Garrett Rooney wrote:
> On 4/25/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> >On Fri, Apr 20, 2007 at 05:52:40AM -0700, David James wrote:
> >> > When you say "entirely separate", I'm confused - is the code it
> >> > generates not used _by_ the ctypes Python bindings?
> >> >
> >> > Does the generator have an explicit LGPL exemption in its license for
> >> > the code it generates, like the Bison license does?
> >>
> >> No, wraptypes does not have a special exception for generated code. I
> >> don't think this is necessary, however, given that the LGPL license is
> >> quite permissive.
> >>
> >
> >It occurred to me that the problems with Bison were that it was GPL, not
> >LGPL, and that it copied portions of itself into the output. As long as
> >wraptypes doesn't do that, I don't have a problem with it - I really
> >wouldn't want to release Python bindings that were effectively under an
> >LGPL license, though. (Though presumably we could build releases using
> >ctypeslib if that was thought to be a concern).
>
> +1 to all of that.
>
> Note also that I disagree with the assertion that "the LGPL license is
> quite permissive". I'm quite glad that these days we have the ability
> to ship releases that don't depend on any *GPLish code, and adding
> that kind of licensing back is a problem in my opinion. It's one
> thing if it's a build tool that doesn't infect any of its output, but
> it's totally different if it's anything more than that IMO.
>
> If you're really looking for a soft copyleft type license, there's any
> number of them out there that are less objectionable than the LGPL,
> FWIW. I'd have no objection with us depending on a library under the
> EPL, CDDL, MPL, or something similar, but LGPL has enough issues with
> it that I'd rather not go there if at all possible.
Garrett's comments really resonate with my feelings on this topic.
- application/pgp-signature attachment: stored
Received on Wed Apr 25 22:35:19 2007