[PyQt] LGPL license.

Giovanni Bajo rasky at develer.com
Wed Feb 11 13:27:44 GMT 2009

On 2/11/2009 4:32 AM, Brian Kelley wrote:
> What are the alternative options so PyQt  can be LGPLd?  I can see three:
>    1. PyQt is LGPL’d but support costs money.  (I would still pay for
>       support, not that I actually have needed it, mind you, Phil is
>       usually on top of the ball as far as I’m concerned)

I don't think there could be enough business coming off support for 
PyQt, unless Phil also leaves this mailing list.

>    2. Phil LGPL’s PyQt and abandons it for us to support since he has no
>       income from the project.  Personally, I’m not actually happy with
>       this one as I (selfishly) imagine it has the most disruption.

That's because PyQt has a bus-factor of 1. If Phil is gone for any 
reason, the project is basically dead and it would be very hard to find 
a new reasonable maintainer.

There are a few reasons why this happens; I'll name the main ones:

  * the SVN where it's developed is not public, so it's impossible to 
investigate the history of the project, which is vital to dig into an 
existing code-base.

  * Internal implementation choices are never discussed in mailing list. 
There is some discussion about public APIs or design choices (like the 
roadmap), but the implemention of PyQt and SIP is a black-box for most 
people. I consider myself familiar with PyQt and SIP source code (as I 
have provided trivial patches and bugfixes to it), but I still 
understand them barely.

  * PyQt is automatically generated through a tool called MetaSIP which 
was never released in any form to the public. Without MetaSIP, one would 
have to manually maintain PyQt in sync with Qt, which is not impossible 
but surely much harder (given how large is Qt nowadays).

I am of course not whining here, just citing facts. I would be pleased 
if it was possible to migrate to a different development model where 
there are more PyQt maintainers (keeping Phil's own business intact, of 

>    3. Nokia realizes that PyQt is indispensible to KDE and pays Phil to
>       keep up support.  (I can dream, can’t I?)

I think that, if anything, Nokia would just make a takeover bid on 
Riverbank and SIP/PyQt, so to start maintaining and shipping PyQt just 
like they do with Jambi.

> Anyway, I appreciate Phil’s effort, and as long as I get new versions of 
> PyQt I’ll be happy whatever he chooses.
> And to Mr. Knapp, have you considered GPL’ing your software and also 
> selling it?  You know you can do both, and you don’t have to pay a dime 
> for Qt or PyQt. If it is a content driven application, the content does 
> not have to be GPL’d, just the source.  I.e. While people can distribute 
> the source code to whatever engine you produce, they cannot distribute 
> assets the engine uses.  Most users will never know, nor care about the 
> difference.

That can't be done on most software.

I would instead suggest Mr. Knapp to evaluate buying a license of PyQt. 
Now that Qt is LGPL, the price for building a commercial PyQt solution 
is really really low. I can't understand why it wouldn't be a suitable 
solution for his software.
Giovanni Bajo
Develer S.r.l.

More information about the PyQt mailing list