[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r24647 - in branches/ctypes-python-bindings: . csvn/core wraptypes

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2007-04-25 21:10:19 CEST

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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 25 21:10:34 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.