Nokia Makes LGPL Version of PyQt

EtaCarinae writes "Nokia didn't succeed in convincing Riverbank to change its licensing terms on PyQt, and so decided to create their own LGPL'ed version of it. From the FAQ at the PySide site: 'Nokia's initial research into Python bindings for Qt involved speaking with Riverbank Computing, the makers of PyQt. We had several discussions with them to see if it was possible to use PyQt to achieve our goals. Unfortunately, a common agreement could not be found , so in the end we decided to proceed with PySide.'"

Comments

Nokia & OSS

[mcelrath]

I'm liking this new approach of Nokia toward open source, with Maemo and Qt. It's a smart move. Python bindings will make for rapid app development. They should soon have armies of OSS developers making apps for their new phone (N900). I must be dreaming, to have both Google's Android and Maemo available on what is historically the most closed computing platform in recent history (cell phones). It seems it will be possible to install both on their new phones. I hope for lots of cross-pollenation, and an app list that puts the proprietary iCrap to shame.

Size and speed

[paugq]

This is what Richard Dale (the main author of SMOKE and the Ruby and C# bindings for Qt and KDE, and C, Objective C and Java bindings in the past, to) said about PySide:

Currently the total size of the PySide libs for all the Qt modueles is 30 Mb. For just QtCore and QtGui they are 22.5 Mb. These are really high figures, and about twice the size of the existing PyQt libs. They are five or six (!) times larger than the Smoke libraries, which weigh in at just over 5 Mb for all the Qt modules. The Smoke libraries can be used by Ruby, C#, Perl, Common Lisp and PHP, not just a single language too. The large size is caused by the heavy use of C++ templates in Boost::Python.

Qt alone has about 500 classes, whereas the current KDE bindings like Python and Ruby wrap over 1500 classes, which would give a combined shared library size of 90 Mb or so assuming the same size per class as Qt. So as PySide stands, I would personally consider that these figures are just too high.

There is a hack in the generate code of doing '#define protected public', to allow protected methods to be called. This certainly won't work on Windows. Fixing it properly will require extra code to be generated to subclass each class with protected methods, and add a public method that calls a corresponding method in the class to be wrapped. This will add some extra code obviously.

It looks like PySide are huge (3x the size of PyQt and 6x the size of SMOKE-generated bindings!) and there is very little improvement they can do if they keep on using Boost::Python to generate PySide.

Given that PyQt costs only £350 (roughly 400 EUR) with full support and is much lighter and mature, I can't see why I would use PySide (unless Nokia gives me full, free, support with my commercial C++ license, of course, which I think they won't be doing because they required you to buy a 1000 EUR separate license for Qt Jambi -the Java bindings- )

Re:Kudos to Nokia

[wowbagger]

Full disclosure:
At work, I have a PyQT commercial license. I've had to look into the licensing issues around Qt and PyQt. The following is based upon my reading of the various licences and issues. I am an engineer, not an IP lawyer, and even were I a lawyer, I am not your lawyer - so do your own research.

I am all for supporting companies like Riverbend who offer both GPL and proprietary licenses.

However, there is a complication that Nokia was trying to address here. Whatever license you are using for PyQT you must also be using for Qt, due to the way they are linked.

Now, with Riverbend, the only licenses they offer are GPL and proprietary. That means that if I want to release a proprietary application using PyQt, I must use the proprietary PyQt. However, that means that I now must use the proprietary license for Qt as well. But that now means I have to buy the developer licenses for my team from Nokia - again, not a big deal from an initial monetary outlay.

Now, for my application I cannot use the GPL license because parts of my application are licensed from other people who don't want to GPL their code - it sucks, and I'd rather not deal with it, but when you are in the RF communications business and you have to support CDMA, you HAVE to do business with Qualcomm, and they will NOT change their minds.

So when I ship my app as a Windows or GNU/Linux application, I cannot use the GPL. Now, just considering Qt, I can use the LGPL - the library is dynamically linked against my code, the user can replace the library, all is right with the world.

Except that I cannot use the LGPL for Qt and use PyQt, as PyQt does not support LGPL. So, in case you cannot draw the Venn diagram for yourself, I am left with using the proprietary license for both Qt and PyQt. Now, even though the licensing terms are pretty generous, I still have to track all the licensed code I ship - so you just added a bunch of cost to my accounting of program. This gets even worse when the program is freely available (remember, you can be free and not be Free).

I had contacted Riverbend when Nokia announced the LGPL'ing of Qt, and at that time they said they were considering it. Obviously, they decided they couldn't do it and remain viable as a business - and while that sucks for me, I can certainly understand their point of view. But without the ability to use the LGPL version of Qt from Python, the utility of Qt is greatly diminished. I can understand why Nokia did what they did. Yes, it would have been nice if Nokia could have worked out a way to fund Riverbend such that Riverbend could have LGPL'ed PyQt, but evidently that couldn't happen.

Re:Kudos to Nokia

[WaywardGeek]

I'm personally a fan of what Nokia is doing. In general, the big GUI libraries need to be LGPL or BSD to gain the widest acceptance. Requiring license fees for non-GPL leaves companies like Nokia flapping in the wind with no solution. This is also why GTK gained so much momentum at Qt's expense. This allows me to learn one way to write code, and to be able to either contribute it to the open-source community (which I do often), or to sell it through my work (which I actually get paid for).

However, this is a troubling new way for a big company to crush a small one... "Give me your technology for free, or I'll rewrite it and then give it to the world for free." It sounds a bit like Microsoft.