[PyQt] LGPL license.
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
* 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
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.
More information about the PyQt