Linked by Eugenia Loli-Queru on Tue 3rd Mar 2009 10:55 UTC
Thread beginning with comment 351441
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
The difference is substantial. It means the difference between being able to create commercial closed source apps and not.
Not true. Riverbank offers commercial licenses of PyQt, so you can write closed source commercial apps with it just fine. You just can't do it for free.
If he doesn't LGPL it someone else will create an LGPL'd binding.
Highly unlikely, but anything is possible.
The difference is substantial. It means the difference between being able to create commercial closed source apps and not.
I'm not talking about the difference from the point of view of someone using the bindings, I'm talking about the point of view of this person who you expect to develop the bindings. You really believe someone is going to donate 1-2 years of their time in order that you don't have to pay 350 pounds or so for a commercial PyQt license? What's in it for them?
I think that vendor does no want to allow you and the others to use their work in order to create proprietary applications. They probably have some interest in doing so. Perhaps they want to retain an advantage over the other proprietary developers. They have every right to do that.
I think you may be waiting a long time. If there is already a high quality GPL'd version of a Python binding for Qt, why would anyone want to spend entire man-years redoing a new one with a slightly different license?
I think you're overstating it a bit. Riverbank is mostly a one-man operation. I don't want to understate the work involved, but I don't think it would amount to man-years to duplicate if someone or some group was intent on doing so.
Riverbank has every right to continue with the GPL/commercial model that Qt had. PyQt is a fine, and popular, product.
BUT, I suspect the LGPL announcement took the wind out of their sails. Compared to the license fee for Qt, a PyQt commerical license was incremental for commercial development. While it is still nominal in the overall scheme of things, at least in terms of commercial developers that measure value by ROI rather than absolute cost, it now stands out amongst an LGPL'd Qt field with LGPL'd bindings for other languages.
I don't begrudge Riverbank's model, all the more power to them for the time and effort they've extended over the years, I just suspect that they're going to have to figure out how to adapt to the new licensing scheme while still remaining viable. Nature abhors a vacuum, and I'd be surprised if an alternative didn't spring up otherwise.
[q]I think you may be waiting a long time. If there is already a high quality GPL'd version of a Python binding for Qt, why would anyone want to spend entire man-years redoing a new one with a slightly different license?
I think you're overstating it a bit. Riverbank is mostly a one-man operation. I don't want to understate the work involved, but I don't think it would amount to man-years to duplicate if someone or some group was intent on doing so.
You're welcome to believe what you like about the man effort involved in writing high quality complete bindings for the Qt apis.
I speak as the developer of several Qt language bindings (QtJava, QtRuby and Qyoto C#), and should have some idea of how much work is involved. For instance, I've been working on QtRuby for over five years, including 2 years full time, and I can tell you that I still have a big todo list.
There are python bindings based on PyQt for KDE too, and any replacement project would need to replace that work too, while managing to keep the community on their side.






Member since:
2005-07-22
I think you may be waiting a long time. If there is already a high quality GPL'd version of a Python binding for Qt, why would anyone want to spend entire man-years redoing a new one with a slightly different license?