Nokia Makes LGPL Version of PyQt 263
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.'"
Nokia & OSS (Score:5, Interesting)
Re:Kudos to Nokia (Score:3, Interesting)
The problem with PyQt was that as it was the only python binding, you had no choice but to pay to riverbank. Considering that they don't own Qt themselves, they got a slight "monopoly"/gatekeeper position on other people's code.
Also, PyQt was not all *that* open source, you couldn't fork it because they only release the generated code.
multiplatform? (Score:4, Interesting)
Also worth to mention is that this implementation is linux only. Isnt on of the main purposes with languages like python/perl/java that they should be platform neutral?
Re:Kudos to Nokia (Score:4, Interesting)
The point of PyQt is to remain faithful to the official C++ Qt API, making your skills & docs directly transferrable and code easy to port over in either direction.
PyQt has added a new, more pythonic API for signals, and PySide will do the same thing eventually. But it's essential that we retain almost-1:1 C++ mapping (though losing trivial stuff like QString).
Size and speed (Score:5, Interesting)
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 [kdenews.org] 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 (Score:4, Interesting)
Hell will freeze over before you'll see Qt embracing GObject. GObject is actually one of the things driving people to Qt.
Re:Kudos to Nokia (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Re:Kudos to Nokia (Score:3, Interesting)
1) complicates the build process
The build process is already needlessly complicated. One more preprocessor won't hurt.
2) pollutes the global namespace terribly (emit, signals, etc.)
"If you're worried about namespace pollution, you can disable this macro by adding the following line to your .pro file:
CONFIG += no_keywords"
3) slows rebuild as MOC has to inspect the code and regenerate MOC files if needed
gcc is orders of magnitude slower than moc.
4) cannot understand normal and common C++ code (inner class, templates)
6) doesn't know const char * vs. char const * are the same
7) same goes for any other compatible but not strictly-exact prototype
Use the subset that moc understands. Problem solved.
5) causes binding errors that are (maybe not) discovered at runtime
That's a valid point, but what do you recommend to fix it? These errors disappeared when I switched to Qt Creator. There's autocomplete for signals and slots there.
8) adding one more tool/compiler to code generation (to make, compiler, resource compilers, linker..)
Yes, one more. The toolchain is already long, it doesn't matter. Yacc and bison do the same, yet nobody complains.
9) complicates porting to emerging or not supported platforms as you have to port MOC compiler first
Other than "make moc"? Could you show me one instance where moc interfered with porting? If there's a platform where parsing text files can cause problems, why bother?
10) MOC 'invents' its own non-standard non-ISO C++ syntax
That's exactly why I like it: Qt C++ basically looks like a scripting language. And you're not forced to use it, anyway.
11) fragments drive as every MOC dependent file has to be frequently overwritten
You clearly made this one up to make your list longer. How many temporary files do you have in a standard make build?
12) is redundant as Boost already and clearly shows
Qt predates Boost signals. Port both Qt and my applications to Boost and we'll talk.
Re:Size and speed (Score:3, Interesting)
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
For me, it's partly philosophical. Python is available under a BSD-like license. Qt is available under the LGPL. However, to make Python talk to Qt, you currently have to add the extra restrictions of the GPL. Not to give short shrift to Riverbank, but I thought it was pretty silly that the most restrictive license in that chain was in the glue that connected the more permissive components.
If PySide makes it to Windows soon, this will probably be my company's GUI development platform. I'd always preferred Qt, but GTK's use of the LGPL made it an easier sell to my boss. Thanks, Nokia! I'll remember this next time I'm buying or recommending equipment.
Re:Kudos to Nokia (Score:1, Interesting)
The difference between GObject/C and C++ is that the former has a well specified ABI you can link against from virtually any language. Qt's public interface uses features that no language besides C++ can use, and you end up with bindings that convert string and list parameters on every call.
Re:Kudos to Nokia (Score:4, Interesting)
This is also why GTK gained so much momentum at Qt's expense.
At the same time, what would Qt be without the license income from commercial licenses? Nokia can justify putting money into it to support their products, but Trolltech was a software company. I did look at both GTK and Qt for hobby development and Qt was much higher quality in my personal opinion, and that's because they had real income to hire dedicated developers and make a kick-ass development platform. McDonald's is cheap and popular, that's what GTK is to companies but it doesn't imply that it's good food.
I often find the development of open source projects painfully slow (yes, this is from the and-I-want-a-free-pony-too department) but Qt has always been a positive high note. I love how they take top notch things like WebKit and make them incredibly easy to use in QtWekKit. They're a little bit like Apple, except for developers - they take what's out there and really everybody's doing already but is difficult, package it up in a great way to make it easy for the win.
One thing I really like is that they have, unlike much other open source stuck in the 20th century, embraced long function names and code completion. I just tried to check what the longest function name was and "availableAudioOutputDevicesChanged()" is pretty close. But since it's object oriented, you type the ./-> and the autocomplete list appears. Unlike the fcntl vs iocntl or whatever article that was here recently, it's retarded naming for people still using text editors (let the flamewars begin).
In short, you talk about how much momentum Qt would make, I'm hoping it won't lose any of the momentum it has had. It's basically the standard library C++ should have had to compete with Java/C#...
Re:Kudos to Nokia (Score:2, Interesting)
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.
Does it now? What source has Microsoft rewritten and released? Actually, I was thinking that Riverbank sounded like Microsoft... tightly controlling the terms away from true freedom. Nokia donated development effort to get around that. Why do you consider only some freedom good?
Re:Kudos to Nokia (Score:3, Interesting)
Some of your arguments sound like the arguments of a religious or political fanatic - sorry.
If there aren't a lot of copies of your work already in circulation, or you're worried about someone making a product out of your work and then removing all trace of the master copy, (which I have seen done in the case of some public domain books, for instance) a copyleft license can be an appropriate choice.
It depends also on what your motivations are. If you have no intention of making money from your work yourself, and simply want to try and ensure that it survives in some form, the GPL is fine. If you want to develop it economically, however, it really isn't the best license.
Red Hat found that out when Oracle started a Linux distribution which included some of Red Hat's own code, which due to the GPL, they legally had to allow. Red Hat are now using the Apache License for JBoss; they got burned, and have learned from the experience.
Re:Kudos to Nokia (Score:2, Interesting)
More python apis would be great. If they followed PEP-8, even better.
Describing PyQt as "C++ without the segfaults" is only partially true, though. I've segfaulted the latest PyQt4 (by accident, of course), and it's not too hard to make it happen in different parts of the Qt4 api if you're not too careful.
See, for example:
http://github.com/davvid/git-cola/commit/944ca1252f2f5e6bbd17f8a6fc4718144138bd26 [github.com]
Undo that commit and you, too, can segfault PyQt4 4.5 ;-)
For the curious, there was a change in behavior between PyQt4 4.{3,4} and 4.5. Older versions coped with the original code without a problem. Fedora 11 users reported the problem; my debian install wasn't tickling the bug (probably cos my lib was too old?)
If pyside can help me do away with these workarounds then I'll be quite pleased.
Right now I'm even carrying around setup.py compatibility hacks for older versions of 'pyuic4' that shipped without a proper shebang line. Grr.
I'm sure porting to pyside's going to suck, but if I get a more stable lib then it's worth it. Until they've proven themselves, though, I'll have to deal with the hacks/workarounds[*].
The python guys came up with a py2to3 script for going from python2 to python3. If pyside can come up with a similar script for PyQt4 to pyside then they'll have an easier time winning over existing PyQt4 users.
BTW did anyone else wonder about the name? WTF is pyside? The FAQ doesn't even mention why it has that name.
[*] I know I'll be waiting a bit, though, since Mac and Win support aren't the top item on the pyside todo list a.t.m.