Submitted by “The PySide project provides LGPL-licensed Python bindings for the Qt cross-platform application and UI framework. PySide Qt bindings allow both free open source and proprietary software development and ultimately aim to support all of the platforms as Qt itself.” Previously, the PyQt bindings were not licensed LGPL. If one wished to make a commercial application, then one previously had to purchase a commercial license for PyQt. Now it is possible to dynamically link to the LGPL-licensed PySide bindings instead. The PySide bindings are API compatible with PyQt.
Interesting aspect here is that this binding is directly funded by Nokia; so this one probably won’t disappear quietly into the night.
API compatibility w/ PyQt is nice; you don’t have to wait for this binding to start a project but can proceed with PyQt (and stay with PyQt if the license is ok for your needs).
So was Jambi (by trolltech that is), but it managed to die a silent death anyway.
Its good news, but I don’t take it for granted that it will be a success anyway. Lets hope for the best.
That’s because Nokia is not horribly interested in Java, and Java community is not that much into Qt. Do not confuse stuff Nokia inherited with Trolltech acquisition and stuff they initiated themselves.
It’s not like Qt bindings for Python are a novell concept. PyQt is a success already, so there is clearly a need – and this is basically a same thing with a less controversial license.
They are indeed VERY interested in Java — Jave ME. All their devices run it, and it is one of the recommended platforms for S60 (the others are Web and C++, with Qt coming soon to blow Nokia C++ out of the way).
They have ported SWT to Java ME, so it is possible to use Java to write apps that integrate into S60 indistinguishably from native apps. It could well be say that, today, Java ME is the best language for S60 apps. When Qt comes, these apps should sail smoothly into the new world, via ESWT, unlike native Nokia C++ apps, which wont run after Symbian^3
Why not Jambi, then? I guess it’s because there is no Jambi ME, and because there is ESWT, which does about the same job quite nicely.
I’m trying to think of a scenario where you would choose riverbank for either GPL or the commercial one and I can’t.
If you want to develop an open source GPL project, make all your source GPL and link against the LGPL PySide.
If you want to develop a closed source commercial application, save some money and use LGPL PySide.
This seems like a kick in the crotch to Riverbank.
If it took several man years of effort they should have offered that amount of money for a Riverbank buyout rather than duplicate effort. That is, unless they didn’t like the PyQT implementation.
I’ve just tried PySide and my (fairly simple) code has failed with an error:
Boost.Python.ArgumentError: Python argument types in
QMainWindow.addDockWidget(MyWindow, DockWidgetArea, QDockWidget)
did not match C++ signature:
addDockWidget(QMainWindow {lvalue}, Qt::DockWidgetArea area, QDockWidget* dockwidget, Qt::Orientation orientation)
addDockWidget(QMainWindow {lvalue}, Qt::DockWidgetArea area, QDockWidget* dockwidget)
I will obviously keep an eye on this project but I don’t expect it to be in a usable state earlier than in a year or two.
As for PyQt, I am actually quite happy with it. It’s one of the best run opensource projects so I don’t think it will suddenly disappear. Still, having LGPL-ed Qt bindings would be great for both Python (it would be fantastic to have robust and portable GUI out of the box on all platforms) and Qt (it would radically lower the entry barrier for its users). It’s sad that Nokia hasn’t found an agreement with Riverbank.
Previously if Riverbank’s policy or FAQ or something stated that you were not allowed to use a commercial license for something that was developed using the GPL version. This was a restriction on the commercial license.
Now there is nothing saying that I can’t develop my closed source application in house using the GPL PyQT and switch to PySide when both my app and PySide are stable. If I made no distributions during development I don’t need to release any source.
BTW, I just finished my first set of Python bindings for an in-house C++ library. It actually wasn’t that bad. Pretty easy, but nowhere as big as Qt.
Its good to know there are more generators available but from what I’ve heard they are all garbage, especially SWIG.
The restrictions were exactly the same as for buying Qt commercial licences at that time: something which actually has nothing to do with either of the licences (despite uninformed whining from various people) and everything to do with the policy of selling commercial licences in the first place.
Some victory for Free Software that is.
With this particular project, Nokia has shown that its way of managing relationships with its corporate partners comes straight out of Microsoft’s playbook. Still, it’s yet one more area where Nokia gets to show off its complete lack of originality.
You weren’t in the room when they were talking to riverbank and neither was I. They tried to work out a deal and couldn’t agree on terms.
This doesn’t seem like Microsoft at all. They tried to work out a deal, couldn’t, and implemented it themselves from scratch, and released it as LGPL. In the end it is giving back to the community. If Nokia saw a benefit of releasing Qt under LGPL rather than GPL they certainly have that same benefit with any kind of bindings. Riverbank would never answer the question of whether it would change their license or not. Nokia didn’t do this in the dark pretending that PyQt didn’t exist.
It seems they are not starting completely from scratch; they are using boost::python and some binding generation stuff they used for Jambi.
Even better – building upon available infrastructure is one of the things that sets FOSS apart from the proprietary world…