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.'"
Kudos to Nokia.
E
This is especially interesting
with regard to the mobile platform:
Both Symbian (the most widely deployed smartphone OS)
and Maemo (Nokias linux-distribution for high end phones and tablets
(this is a unix-like OS, unlike android))
supports python and is working towards using QT as a (the) UI-toolkit,
so this likely to a major within scripting languages on mobile phones.
Taken from the arstechnica web site that also carried this story
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.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
So now mega corporations are out-sourcing open source companies to increase their properties... am i in a dream ?
As someone who enjoys raving on about the evils of the commercialization of open source i feel i have nowhere to go now (except maybe to the shop to buy a N900 so i can hook it up top my freerunner) ...
Applications gravitate towards being perfectly open-source. He's right. They do. If there's a closed-source app, eventually someone's going to sit down and clone it to be open-source. They'll do it because they need a version that they can access the source code for, and they'll do it because they're not willing to pay the license fees, and they'll do it because, hey, we went to all this work, why not let other people use it?
He's right.
But the license that code gravitates towards isn't the GPL.
The GPL is restrictive. The GPL is - in some senses - closed, rather than open. The GPL cannot be used for all purposes.
The license code gravitates towards is the BSD license. The MIT license. The libpng/zlib license. The license that says, in brief, "Hey. Here's some code. Don't sue us. Have fun."
Because every software package - every software package - is pushed by that same force, that force that says "I need software with specific allowances, and if I cannot find it, I will make it." And the GPL does not allow everything.
The GPL is a fantastic, amazing license. I've licensed code under it, and I'm glad it exists.
But it's a midpoint - not an endpoint.
Breaking Into the Industry - A development log about starting a game studio.
They couldn't arrive at an agreement with the other party. They tried to do it the easy way and it just didn't work out. But they didn't give up either -- they decided to do it themselves AND to contribute back to the OSS community in the process. I admire the do it yourself attitude as it reflects back to a time when software wasn't "a product" but a mean to solving a problem.
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?
Do you see the Linux kernel gravitating to BSD? Do you see GIMP gravitating to BSD? Do you see OO.o gravitating to BSD?
Sorry to shatter your masturbatory fantasies, but the GPL is still the most popular license among open source projects. The only "freedom" it removes is the freedom to harm the freedoms of other users of the software, much like the law restricts your freedom to stab me in the face. Calling it "closed" is utterly absurd. Most people, except for a tiny bit of fanatical free software advocates, prefer the LGPL over the GPL for libraries. Not because it's on the path to BSD-like permissive licenses, but because they feel it is more in line with their reason for using the GPL, i.e., to ensure their code stays open and other people can't make closed forks or incorporate parts of the code into closed projects. They object to the GPL for this purpose because when used for a library it ends up going beyond this and additionally forcing everyone who uses it (which is, you know, the whole point of libraries) to open their code. Nothing more.
You are just misinterpreting and distorting the facts and outright lying to support your deep-seated preconception that "OMG BSD LICENSE IS THE BEST THING EVER GPL SUXXX". To say your conclusions are on shaky ground would be the understatement of the millennium.
This is a very good thing for Maya scripters.
;-)
Maya introduced python support a while ago, but the Maya binding was just the same as MEL (Maya own script language). This isn't sooo bad, except when it comes to user interfaces, where it sucks very badly. I'm sorry, it does. Most people have been moving from MEL to python, and this makes the MEL interface stuff more of a sticking point because it looks even worse from a python perspective.
In a gernal effort of the Maya development team to make the Maya code common for all the platforms, they have moved the interface to QT for all platforms. There was excitement that this mean pyQT could be used for interfaces. But then their was liencing confusion. Can they use it, can they not? Would they have to get 'up top' to buy it so they could? Now with a LGPL everyone knows where they stand. They can use it and don't have to try and convice management to part with any money. Their stuff doesn't have to be openned (which often they want to do but are not allowed). This is a good thing for the Maya python scripters. Autodesk would be silly not to include this lib as part of Maya's standard python enviroment (but even if they didn't it could still be used). It's a good thing for the lib because it means any improvement/fixes that Autodesk deside to make, they have to give out. Everyone is a winner. Without the LGPL protection, Autodesk would "rape" this project. That is their way. Think Apple, but not as "cool" and more evil.
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- )
Someone know if there are plans to integrate Python and PySide to QtCreator ?
That would be really great to developpe python gui programs without hassle.
Wait, so does that mean there are no SWIG bindings for Qt? I just sort of assumed that for a big popular library like Qt, someone would have done a SWIG binding by now, simultaneously making it available in a whole bunch of languages..
What a nice ad-hominem you made there. The midas touch angle makes you look very academic, and the communism jibe shows your colours as a true blue american. Sadly though, there is not a lot of substantial argument behind your ranting (AKA none). You don't like the GPL, but why that is exactly you do not tell. ;)
The MIT and or BSD licenses you prefer have been a brake on the uptake/development of all the BSD's. Linux was late to the game of Open Source Unix-like OSes, but it magically overtook all of them by a large margin. That is in part thanks to it's license, that prevented leeches from exploiting the work of contributors. It is those contributors that make Linux what it is, and they like the GPL just fine.
You seem to like your precious opinion very much, but luckily that does not make a difference at all. Or should I have not fed the troll?
This space is intentionally staring blankly at you
Android has already been ported to Ubuntu and can run as an application on top of a regular Linux kernel. The same should be possible on the N900.
Wow, pots and kettles.
Both GObject and QObject are non-standard object models because neither base language (C, C++) supports an object model that is suitable for GUI development.
GObject is harder to develop for, but easier to integrate into other software.
QObject uses syntactic tricks in C++ to make it easier to develop for in C++, but it's harder to integrate into, and extend, in other languages.
An additional problem with QObject and Qt is that it doesn't even conform to C++ library standards very well.
What do you mean the proprietary PyQt is not compatible with the LGPL'd Qt? I should think you can indeed use the proprietary PyQt license with the LPGL'd Qt; the LGPL license certainly allows it.
Hear the cry of the freeloader!
I'm hearing the cry of scarcity thinking a lot around here recently, and I'm wondering why.
Someone being a freeloader is only a problem if software is somehow a finite resource, and you're scared of there eventually not being any left.
Are you scared of that?
Couldn't Nokia buy Riverbank like they did with Qt Software? Probably they did try, and this really was the last option available.
Qt is already extremely multiplatform -- it's the only language/toolkit (other than Java) where I can code on Win/Linux/Mac/Cell phone and have it just work.
Python's cross-platform nature makes it seem pretty natural to use with a cross-platform toolkit. But that's just me;)
-- Political fascism requires a Fuhrer.
Yeah... No.
The BSD "endpoint" just boomerangs you. Here's how that goes:
1. Yay ZorbaApp. It's great, 10 000 people use it. It's got a license that you can say out loud in one breath. Hooray. Up-and-coming shrinkwrap software company MicroOrange gives the "do as you please" license a big thumbs up.
2. Ooh, MicroOrangeApp. Like ZorbaApp, but with two cool features... and a marketing budget... and a license that forbids distribution in any form. But - hey, it's still zero cost and those features make it better than ZorbaApp.
3. ZorbaApp sees relatively little development. Anything new and worthwhile in ZorbaApp is quickly patched into MicroOrangeApp by its well paid developers. They're on the cover of TIME magazine, offering answers to questions like "What made you come up with MicroOrangeApp?". The handful of people screaming "They didn't they just ripped off ZorbaApp" are shouted down by people pointing out how damn cool MicroOrange are - and why not when their office has a Planetarium!
4. The new MicroOrangeApp with SuperAwesomeFeature costs $10. Which is annoying, but it's not like you'll go back to ZorbaApp now, does that even compile on a modern Orange computer? Not worth the time to find out. Anyway, it's free for 12 months if you sign up for LockinService.
5. LockinService has 50 million subscribers. Everyone you know is on it. When you suggest they try ZorbaApp, you have to explain why it doesn't do LockinService. Friends look at you pityingly. Why are you such a cheapskate
6. Some guy from Portugal with a silly name starts a GPL'd project PortugueseManOWar which is a bit like having LockinService, but for the brand new CrazyGadget, which MicroOrange have shunned. It doesn't have 50 million subscribers, or even 10 million but it has a lot of VIPs talking about it.
7. MicroOrange belatedly tries to push MicroOrangeApp for CrazyGadget, but now CrazyGadget is coming with PortugueseManOWar out of the box because that was so easy to do and cost CrazyGadget's makers nothing.
8. LockinService EOY figures reveal they've lost 8 million subscribers. Investors go nuts. MicroOrange give away MicroOrangeApp and announce "OpenOrange" project but it's all over, PortugueseManOWar has eaten their lunch. Now, someone just has to figure out how to actually make any money from it.
You start out "very very free" and someone exploits that, suddenly you're not free at all, everything you're doing gets absorbed into a non-free blob... and then someone comes up with a tangential GPL'd alternative, and we're back at the GPL. Boomerang. But it's painful getting hit by a boomerang. So avoid it. Don't use these "very very free" licenses unless the resulting proprietary software is in fact part of a higher purpose, e.g. spreading a new media codec.
Actually programs will still migrate towards GPL, because of the fear that the program to end up closed and out of their control again like it was in the first place. Releasing stuff as BSD/libpng/zlib is kind of pointless, because modifying closed versions will not help the open ones that people want in the first place. LGPL is actually the midpoint, and GPL is the endpoint.
Twinstiq, game news
I'm tired of choosing actions of life according to the paperwork of lawyers and accountants. I'm going to look for some way to do what's best for human beings, period.
Build your own energy sources from scratch. http://otherpower.com/