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
course).
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.
http://www.develer.com
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
