Licensing of wrappers around C/C++ code under more restrictive licensing.
Mike C. Fletcher
mcfletch at rogers.com
Sun Feb 29 06:09:14 CET 2004
Graham Dumpleton wrote:
>I would really like to hear other peoples ideas about how to address
>licensing where the Python code is actually a wrapper around a C/C++
>library under a QPL or GPL type license. Some people seem to believe
>that the use of the scripting language implies a line is drawn when
>people go to use it and thus what the library underneath is licensed
>under doesn't matter. Linking of the library still occurs though, so I
>don't believe this is necessarily the case.
(I'm not a lawyer, just someone who seems to get lectured at about
licenses a lot :) ).
If I understand correctly, copyright law does not directly grant one the
right to restrict distribution of *someone else's* copyrighted works
merely because they refer to one's own work. So, if your distributable
does not include any code created by someone else, then the other party
has no right to restrict its distribution based on copyright. So, if
your package connects to anything installed on the system which happens
to implement a given API but does not include any GPL code itself, you
can likely simply point to the fact that you haven't included any of the
GPL-licensed code and be fine.
The FSF peoples seem to have a different interpretation, as, last I
heard, they suggest that software that links to any GPL software, even
at run-time constitutes an infringement (regardless of your not having
distributed the GPL code yourself, and the end-user having a perfectly
valid license to link the two for personal use). Depending on a Free
Software Foundation owned library (i.e. one to which the author has
assigned their copyright to the FSF) in this type of scenario would
likely then be a little risky.
The question becomes murkier when you start to introduce, for instance,
the use of header files from a GPL program to create a SWIG .i file.
There are apparently cases where the use of headers for allowing
interoperability with commercial software was considered a fair-use
infringement (i.e. it is technically a copyright violation, but is
likely to be considered valid should it be brought before a court).
Apparently other cases suggest that the necessary functional
specification isn't actually copyrightable. The question comes down to
what is expression, and what is merely mechanics.
>So, how can one cast the licensing so as to provide an exception that
>provided the underlying C/C++ library isn't changed, that the Python
>wrappers can be used under a less restrictive license. I have control of
>the licensing on both so can stipulate exceptions, but what is the
>best way of doing it?
Sounds like what you really want is the LGPL for the C/C++ library?
That would keep the GPL-like restrictions for the C/C++ library, but
allow linking it into proprietary Python software. It would *not*
however restrict based on whether it's a Python or C/C++ application
doing the linking. It would also explicitly *not* prevent changes to
the C/C++ library (the whole point of Open Source licenses, particularly
GPL and LGPL being to allow the user to fix bugs and change operation of
You could add a clause to your license doing something silly like
requiring that a Python DLL be linked into the process to enable the
less restrictive license, but doing that means that you've suddenly got
a non-standard license, which requires everyone to hire a lawyer to
explain it to them, check for incompatibilities with other software, ad
Of course, the point of the GPL license (among other things) is to
strongly encourage others to use the license in order to give to users
access to ever-more GPL'd code. The so-called "viral" effects are
intentional. If I understand correctly, the QPL is basically a dual
license encouraging you to either pay Trolltech or GPL your software.
Finding ways *around* these licenses (I'm assuming that the QPL is being
inherited by including Qt or the like) might be considered rude at the
least if the license involves code which is not your own.
So, my suggestion would be (assuming this is possible (you own *all*
* Ditch QPL, license the C/C++ library as LGPL, license the Python
library as BSD/MIT or LGPL.
* Distribute the Python wrapper (with none of the C/C++ project's
code) as a separate project.
o Anyone who uses the C/C++ library is still bound by GPL rules.
o Anyone who combines and redistributes it will be bound by
the GPL, so they can't bundle it with proprietary code.
o The more permissive MIT/BSD license is GPL compatible, so
the wrapper itself can be bundled with the GPL code if desired.
o The wrapper can be bundled with the proprietary code so that
the user can simply install the C/C++ project using it's
installer and the proprietary code can find it at run time.
o Users must combine the system with any proprietary code
themselves. This can be fairly inconvenient.
* Descend into a morass of trying to legally define what it means to
"use" the Python-based interface and try to integrate that into
some Open Source license.
o Is someone allowed to use both interfaces under the less
restrictive license, or only the Python interface?
o Is someone allowed to call the Python interpreter from C/C++
solely to access the functionality?
o Figure out how to cripple the "modify as you wish" focus of
most of these licenses in the case of use of the Python
* Build your own license using your own high-priced lawyers :) .
The thing, IMO, to keep in mind, is that creating yet another Open
Source license is probably *not* a good idea, despite the fact that it
acts as a make-work project for copyright attorneys, who are obviously
needing more BMWs these days. Choosing one of the existing well
understood and fairly clear licenses (not, e.g. the PSF Python license,
which is an agglomeration of other licenses), such as MIT, BSD, GPL, or
LGPL is probably the best approach for minimising headache and effort.
Mike (again, so not a lawyer it's funny)
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list