Licensing of wrappers around C/C++ code under more restrictive licensing.

[Mike C. Fletcher]

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 
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 incompatibilities 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/