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

[Graham Dumpleton]

On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:

> Graham Dumpleton wrote:
>> 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.
> ...

Thanks for the comments. It gives me more things to think about.

As far as ditching the QPL for the C/C++ library and using the LGPL, I 
am not sure
that I can. The whole situation is made more complicated for me, 
because although
I wrote all the code, it was originally developed while I worked for a 
specific
company. I did obtain a license from that company to continue to 
develop the code
and to distribute the result, including being able to sub-license 
others to also
distribute the code, but the language of that license may well prevent 
me from
applying a license such as the LGPL. This is because with the LGPL, 
someone could
cherry pick code out of the library and use it in something else to the 
extent that
the LGPL allows. At least I don't believe the LGPL would stop this 
although the
application or library which used the "cherry picked" code would itself 
have to be
LGPL or GPL I would imagine.

The reason why the QPL is working for me so far is that the QPL 
essentially restricts
someone to distributing it as is. That is, any changes must be 
distributed as a
separate patch. This in effect means that someone can't just cherry 
pick code from
it and use it separately. To that end I believe I am working within the 
spirit of
my original license obtained from the company who I was originally 
working for as
the manner in which I am licensing it and distributing it preserves the 
integrity
of the package and people in the main have to use it as distributed. 
They can still
make changes if they need to, but if distributing it further, these 
would have to
be as a patch.

I'll have to look more at my license for using the original code, but I 
think I would
be pushing it to release my current C++ code, based on the original 
code, under a
license that allows a free for all. My Python wrappers don't have this 
problem as
such because I developed them all on my own time and by itself it 
doesn't include
any of the original code. Now one may say that I should have negotiated 
a better
license on the original code, but this was back in 1993 before Open 
Source took
off to the extent that it has. It wasn't necessarily possible back then 
to anticipate
how things would change

Thanks again.