Linked by Eugenia Loli on Tue 3rd Mar 2009 10:55 UTC
Qt Nokia today announced the availability of version 4.5 of the Qt cross-platform application and UI framework. It also introduced Qt Creator, a new lightweight cross-platform IDE. Qt 4.5 and Qt Creator combined comprises the Qt SDK, an easy to install package that will let developers create applications quickly and easily. "Qt 4.5 is setting the benchmark for application development," said Benoit Schillings, Chief Technologist, Qt Software, Nokia (and for those who remember, one of the original BeOS developers). It's also the first release of Qt under the LGPL.
Thread beginning with comment 351441
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: pyqt
by Richard Dale on Tue 3rd Mar 2009 16:26 UTC in reply to "pyqt"
Richard Dale
Member since:
2005-07-22

Waiting to see if PyQt will be LGPL so I will know whether to throw my book away and wait for someone else to create LGPL QT bindings for python.


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?

Reply Parent Score: 3

RE[2]: pyqt
by FunkyELF on Tue 3rd Mar 2009 17:32 in reply to "RE: pyqt"
FunkyELF Member since:
2006-07-26

The difference is substantial. It means the difference between being able to create commercial closed source apps and not.

If he doesn't LGPL it someone else will create an LGPL'd binding.

Reply Parent Score: 2

RE[3]: pyqt
by leos on Tue 3rd Mar 2009 17:44 in reply to "RE[2]: pyqt"
leos Member since:
2005-09-21

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.

Reply Parent Score: 5

RE[3]: pyqt
by Richard Dale on Tue 3rd Mar 2009 17:48 in reply to "RE[2]: pyqt"
Richard Dale Member since:
2005-07-22

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?

Reply Parent Score: 3

RE[3]: pyqt
by trenchsol on Tue 3rd Mar 2009 18:56 in reply to "RE[2]: pyqt"
trenchsol Member since:
2006-12-07

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.

Reply Parent Score: 1

RE[2]: pyqt
by elsewhere on Wed 4th Mar 2009 06:28 in reply to "RE: pyqt"
elsewhere Member since:
2005-07-13

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.

Reply Parent Score: 4

RE[3]: pyqt
by Richard Dale on Wed 4th Mar 2009 11:19 in reply to "RE[2]: pyqt"
Richard Dale Member since:
2005-07-22

[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.

Reply Parent Score: 4