[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: David James <james_at_cs.toronto.edu>
Date: 2007-04-26 00:02:36 CEST

On 4/25/07, Garrett Rooney <rooneg@electricjellyfish.net> 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.

I've moved all of the LGPL code out of the Subversion repository into
a separate repository, and renamed my patched version of wraptypes to
"ctypesgen". This library is now hosted at

Per section zero of the LGPL (and GPL), "the act of running a program
using the Library is not restricted, and output from such a program is
covered only if its contents constitute a work based on the Library
(independent of the use of the Library in a tool for writing it)." As
such, any output generated by the Library is only covered by the LGPL
if the output contains non-trivial code from the Library itself.

When you generate a Python wrapper for Subversion using ctypesgen, you
produce a simple Python file which contains ctypes wrappers. These
ctypes wrappers contain no significant or original code from ctypesgen
itself -- in fact, these output files are merely a direct translation
of the Subversion headers into Python following the instructions laid
out in the ctypes documentation. As such, I believe that any usage of
the output from ctypesgen is unrestricted by the LGPL and is in fact
only restricted by the license terms of the headers from which the
output was generated.

Using ctypesgen to generate Python libraries is just like using gcc to
generate binaries --> ctypesgen merely translates your header files
into Python, just like gcc translates your C files into object code.
As such, the output of these programs is only restricted by the
license terms of the files you use as input to gcc / ctypesgen.

I hope this post will clarify matters. I am by no means an expert on
licensing, but I believe that the LGPL and GPL are both clear on this



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 26 00:03:28 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.