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
interoperabilit y 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
the software).
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 incompatibiliti es with other software, ad
nauseam.
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*
copyrights involved)):
* 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
interface.
* 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.
Good luck,
Mike (again, so not a lawyer it's funny)
_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/ 
