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.'"
Kudos to Nokia (Score:5, Funny)
Kudos to Nokia.
E
Comment removed (Score:5, Informative)
Re:Kudos to Nokia (Score:5, Insightful)
Or isn't the GPL considered open anymore?
Not if you want to write commercial software on top of it, which is what Nokia wants to enable. Just as they did with releasing Qt under the LGPL.
It also helps integration if you can get both from the same vendor, and for a project like this, integration is the goal. From now on, you can expect simultaneous and/or bundled releases.
Comment removed (Score:5, Insightful)
Re: (Score:3, Informative)
While I'm not disputing the usefulness of their bindings, I'd describe them as "working", but not necessarily "superb". Their API is not very pythonic or concise and feels pretty much like writing C++, without the segfaults :P
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).
Re: (Score:3, Insightful)
Why? I see no point, Python and C++ are two vastly different languages. It's essential that all the capabilities of Qt are exposed, but not necessarily in the exact same form. (ie. fields vs setters/getters, signal/slot objects vs signal/slot strings).
Python bindings should be designed to accommodate Python programmers, not C++ programmers.
Anyway, the new signal/slot binding seems nice and indeed what
Re: (Score:2)
[quote]It's essential that all the capabilities of Qt are exposed, but not necessarily in the exact same form. (ie. fields vs setters/getters, signal/slot objects vs signal/slot strings).[/quote]
The C++ Qt interface sucks from a C++ point of view too.
The reason it's like this is historic.
It depends whether they want to design an API for stuff that already exists or one that would only work for new projects. But if I were to make a new project, personally, I'd certainly not use Qt but rather a much more mode
Re: (Score:2)
But if I were to make a new project, personally, I'd certainly not use Qt but rather a much more modern technology.
Such as...
?
Re: (Score:2)
Such as a declarative one.
The future Qt declarative UI system is a step in the right direction, but not really there yet.
Re: (Score:3, Informative)
Such as a declarative one.
Such as... ? If it doesn't exist yet, it's not modern, it's futuristic.
Re: (Score:3, Insightful)
Python bindings should be designed to accommodate Python programmers, not C++ programmers.
I don't think we really want a big divide between Python and C++ programmers. The programming model of C++ Qt programming is not fundamentally broken, so it's not something that needs to be fixed more than what was already done. I'd like to see future breed of Qt programmers proficient wth both C++ and Python, not one over the other (Python isn't "dumb man's c++", it's "busy man's C++"). Both have their place.
Any friendly additions for python programmers can be done over the existing "raw" binding.
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:5, Informative)
Put yourself in Nokia's shoes. They need a scripting interface to encourage development on their platform. How much would you pay riverbank for a product that does not exactly meet your needs? The GPL is simply not going to work in the phone environment because not everybody is going to want to license their apps under the GPL. The LGPL has proven to be a far superior compromise as evidenced by the fact that Qt (when it was GPL) previously lost traction to inferior products due to their GPL licensing.
Re: (Score:2, Insightful)
How do you know they wanted it for free? Perhaps this has been discussed somewhere, but I don't think the details of the discussion have been made public.
It seems to me that this is exactly what happened years ago before Qt was GPL'd. People were unhappy with the terms of the Qt license and so they made GTK. In the end, I think we are all better off and I have no reason to suspect differently this time. Competition is good.
Re: (Score:2, Informative)
How did this get modded up to 5? There's no indication anywhere that Nokia demanded PyQt for free.
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: (Score:3, Insightful)
A bit like Microsoft, yes. But MS would've been more like "Sell/give us your technology for next-to-nothing, or we'll buy someone else's inferior competing software, market the fuck out of it, and ruin you."
Re: (Score:3, Insightful)
Insightful post! QT wouldn't be where it is without the income it made licensing software, but at the same time, it couldn't dominate because of the license fees. I think Nokia has the kind of deep pockets to really put QT development on track. I think development will accelerate. Of course, I made my bet, and chose QT 4.5 for my company's next product, so now I have a vested interest in QT winning. Further, I'm learning QT, which I feel is about as hard as learning a foreign language (that is, to lear
Re:Kudos to Nokia (Score:4, Insightful)
I looked at Qt for internal software development at my company. In the end we chose WxWidgets. It was a pain in the ass for years.. but we did it because I wasn't interested in feeding Trolltech's cockamamie pricing scheme. One license per (named) developer per platform? Can only change developers once every 6 months? Ridiculous. We employ co-op programmers who come and go every 4 months. Simply not workable.
I asked more than once for them to sell the product as a package.. a site license or something pro-rated based on the number of developers (1-5, 5-10, whatever).. I also asked them to simply offer a paid yearly support contract which I would gladly buy since our biggest complaint with Wx was the lack of support. No across the board from Trolltech.
So.. we found an alternative.. a free one, as it happens.. but money wasn't the issue.
For the kind of small-scale internal commercial development we do Trolltech's business model was not workable.
Re: (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.
Re: (Score:3, Insightful)
Writing good wrappers isn't trivial. If what they did was trivial, someone would come along, redo it, and put them out of business. Turns out that, for a long time, their work was worth paying for. It took a company as big as Nokia, with a vested interest, to decide it was better for them to do it themselves.
It's not like you NEED PyQT to use QT.
Re:Kudos to Nokia (Score:5, Insightful)
I simply think it's unfair to make Riverbank look like the bad guys and Nokia the saviours.
Nobody wants to make Riverbank look bad. However, Nokia is doing something bigger now: they're gathering all the little pieces you previously needed to find yourself (MinGW, Qt, an IDE, and now PyQT), bundling them up, and releasing them as one package. Open Source GUI programming on Windows has literally never been easier.
My next phone is going to be a Nokia. They deserve it.
Re: (Score:2)
My current phone is a Nokia (E71), and it's bloody annoying. What they deserve is a kick up the arse.
Re: (Score:2)
I know the terms of the GPL and LGPL, thank you. I simply think it's unfair to make Riverbank look like the bad guys and Nokia the saviours.
Well, Trolltech insisted on not LGPL'ing their code, and therefore, requiring a commercial license to deliver Qt applications. This was very inconvenient for small business and independent developers, who had to resort to using other toolkits like wxWidgets (eew) or GTK (double eew). Do you know how painful it is to write GUI applications with GTK?
Nokia ARE heroes by allowing us to use Qt instead of GTK for proprietary applications (we have to pay the bills, youknow). Riverbank is becoming an obstacle to Py
Re: (Score:2)
"Do you know how painful it is to write GUI applications with GTK?"
It seems not painful enough to make paying Troll Tech's fee (which was not excesive) worth it.
Re:Kudos to Nokia (Score:4, Insightful)
Now drop the MOC from QT and everybody might consider your platform.
Eh? Moc is crucial for tiny little features like signals and slots (and through that, the event system, and basically everything you want to do with an event-based application). It's the main selling point for Qt. Dropping it would require a complete rewrite, with perhaps QString being the only class that doesn't use it.
Besides, "their platform" already knows about it, and it's completely transparent unless you write your Makefiles by hand.
Re: (Score:2, Insightful)
I've never worked on Qt, but doesn't the boost signals2 library now offer a superior signals and slots implementation in standard C++? Or does Qt depend on some features not available in the boost signals2 library?
Of course rewriting Qt to use another would be a monumental undertaking and it's probably not worth it merely to improve compatibility with other libraries and toolchains. Nokia seems to agree that can get much more developer mindshare by offering Python bindings.
Re: (Score:3, Informative)
In addition to providing the signals and slots mechanism for communication between objects (the main reason for introducing the system), the meta-object code provides the following additional features:
QObject::metaObject() returns the associated meta-object for the class.
QMetaObject::className() returns the class name as a string at run-time, without requiring native run-time type information (RTTI) support through the C++ compiler.
QObject::inherits() function returns whether an object is an instance of a class that inherits a specified class within the QObject inheritance tree.
QObject::tr() and QObject::trUtf8() translate strings for internationalization.
QObject::setProperty() and QObject::property() dynamically set and get properties by name.
QMetaObject::newInstance() constructs a new instance of the class.
It is also possible to perform dynamic casts using qobject_cast() on QObject classes. The qobject_cast() function behaves similarly to the standard C++ dynamic_cast(), with the advantages that it doesn't require RTTI support and it works across dynamic library boundaries.
Re: (Score:2)
wxWindows does not have slots/signals nor meta objects and nobody misses them in fact MOC is the main reason wxWindows users are not switching to QT. To do lots of "casts" stinks in general also.
What casts are you talking about?
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: (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. Th
Re: (Score:2)
POV, also MOC makes you dependent on Trolltechs toolchain, namely QMake and Qt-Creator
KDE3 used autotools, KDE4 uses cmake. There are integration plugins for Eclipse and Visual Studio as well. You were saying?
The build speed is terrible
That's true, if you include everything. But that's not because of moc, that's because Qt is huge. On my first project, I got a 3x faster build by only including classes I used. It also helps if you separate your functionality so none of your files have to include more than one additional Qt module (The first one being QtCore).
Qt is big because it isn't just a GUI toolkit:
QtCore Core non-graphical classes used by other modules
QtGui Graphical user interface (GUI) components
QtNetwork Classes for network programming
QtOpenGL OpenGL support classes
QtScript Classes for evaluating Qt Scripts
QtScriptTools Additional Qt Script components
QtSql Classes for database integration using SQL
QtSvg Classes for displaying the contents of SVG files
QtWebKit Classes for displaying and editing Web content
QtXml Classes for handling XML
QtXmlPatterns An XQuery & XPath engine for XML and custom data models
Phonon Multimedia framework classes
Qt3Support Qt 3 compatibility classes
QtDesigner Classes for extending Qt Designer
QtUiTools Classes for handling Qt Designer forms in applications
QtHelp Classes for online help
QtAssistant Support for online help
QtTest Tool classes for unit testing
QtDBus Classes for Inter-Process Communication using the D-Bus
Re: (Score:2)
Wow, that was quite an entertaining rant! I'm a new Qt user, but MOC doesn't bother me at all. It's less invasive than "MFC Class Wizard", and the extension to native C++ syntax is nice IMO, vs embedded pragmas. And that's some impressive nit-picking... "Fragments drive", well, only true on Windows, and I'm not. Should I also be against compilation of C++ into object files? "char const*"? Why on earth would I want to write that? Porting complication? Geeze, C++ has been a disaster for portability fo
Re: (Score:2, Informative)
Not if you want to write commercial software on top of it...
s/commercial/proprietary (or non-free)
The GPL is a commercial license. It clearly permits the licensed software to be sold.
Re: (Score:2, Informative)
Just because GPL allows selling commercial software, it doesn't mean that it is very feasible.
I hear that said, yet it happens.
http://ask.slashdot.org/story/09/08/01/169247/The-Ethics-of-Selling-GPLed-Software-For-the-iPhone [slashdot.org]
http://redhat.com/ [redhat.com]
http://www.novell.com/linux/ [novell.com]
Re: (Score:2)
I hear that said, yet it happens.
Oh, and it's a real cash cow, too. Don't make me laugh. The only way to make money from GPL'ed software is to sell support.
Re:Kudos to Nokia (Score:4, Informative)
"Not if you want to write commercial software on top of it, which is what Nokia wants to enable. Just as they did with releasing Qt under the LGPL."
Bullshit. PyQT also has a commercial license. [riverbankcomputing.co.uk] You're just being a freeloading leech right now.
Re:Kudos to Nokia (Score:5, Insightful)
PyQT also has a commercial license. You're just being a freeloading leech right now.
The availability of commercial licenses for PyQt show that Riverbank has no philosophical objection to people writing and distributing GPL-incompatible code that uses it, but they'd like some money for that use (which is fair enough; they're the authors after all).
Now, Nokia seems to be standardising on Maemo/Qt for their future phones, and part of that is that they'd like to build a viable application marketplace for their phones, a la the iPhone. Keeping it free (gratis) to develop for their platform will encourage developers, which suits their goals. Presumably after asking nicely, they also offered Riverbank some cash or equivalent, at least equal to the costs they eventually incurred in developing PySide. Presumably Riverbank didn't think that was enough, and decline (which is still their perogative).
Re: (Score:3, Insightful)
"especially if we want to write proprietary code in it"? So you want to make money off someone else's product without ever having to pay him a penny, and you think that's ok? Wow. Just... wow.
It's 2009 and we shouldn't have to pay for whatever proprietary software it is that you're writing.
Re: (Score:2, Funny)
Re: (Score:2)
You might have the right to say that after you pay for commercial licenses of the libraries you use.
Re: (Score:2)
Interesting that you got modded negative... Anyway, it's in Nokia's interest for QT to "win" vs other solutions, like GTK+ and wxWindows. Having good Python bindings which users can use in their commercial software without paying for a license is an important step for Nokia. I don't know anyone who thinks GTK+ is superior to QT, so why did it win so far? It's not as portable, less well documented, etc. I think because it's LGPL, not GPL. It makes total sense.
Nokia's goal here seems pretty clear: They w
Re: (Score:3, Insightful)
You're just being a freeloading leech right now.
Dude, they're bindings from one third-party platform to another. How is it leeching to suggest that a license fully compatible with both of these is a good thing?
Re: (Score:3, Insightful)
It's leeching because apparently you want to make money off someone else's work without ever having to pay him. After reading your post it's painfully obvious that you only care about it being gratis, not about it being open source.
Re: (Score:2)
By that argument anyone who has ever sold a commercial Windows program leeched from Microsoft because their software only works if the underlying Windows calls are available. Either you haven't thought this out very well, or you don't understand the situation. Either way you are phenomenally far off base.
Re: (Score:2)
How's that the same thing? Assuming the developer didn't pirate Windows, he paid for it. The situation I'm talking about is like a baker wanting to sell bread without paying the flour supplier.
Re: (Score:2)
Who cares if the developer even had a copy of Windows? Maybe he developed it cross platform on Linux, and it runs on Windows also. The issue has absolutely nothing to do with the tools the developer used, and everything to do with deployment. No offense, but you don't understand this issue at all.
Re: (Score:2)
My point wasn't about possible deployment issues to users. I'm criticizing his attitude of wanting to be able to profit off someone else's work without allowing that someone to profit off it as well. It's like a baker wanting to sell bread without paying his flour supplier.
Re: (Score:2)
Right. I already stated that you have no idea what you are talking about, and make no valid point. Stop pulling out the "bake bread but don't pay for the flour" analogy, because it doesn't even remotely fit into the situation. In essence, you have openly admitted that you are not concerned with the issue, nor do you intend to educate yourself enough to speak intelligently about it. I get it. Thanks. No need to keep driving the "point" home ..
Re: (Score:2)
It's leeching because apparently you want to make money off someone else's work without ever having to pay him.
What's wrong with that? Nokia is releasing Python bindings under the LGPL in an effort to build market share for other products. It's a loss leader, like milk sold below cost at a supermarket.
Do you think that people who go to the store and buy cheap milk are leeches, too?
Re: (Score:2)
Ah, the old open-source vs commercial flame-war. I write both. I'm very happy the Python QT bindings will be LGPL. That way, I can continue to contribute to the open-source community without having to learn two different GUI toolkits - one for open-source work, and one for commercial work. Do you know what a PITA it is to explain to management we need to negotiate a software license for a mysterious language like Python's mysterious QT binding library? Unless it costs under $1K, I have to explain that
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: (Score:3, Informative)
How does having the GPL as an option rather than not having it at all inconvenience ANYONE? Also ANYTHING under the GPL can be forked. Don't be a tool.
The only point you can make is that people might refrain from contributing to the project under the GPL because the company can then use their hard work to profit.
Re: (Score:2)
So I do not see why it matter whether it is GPL or LGPL. I am not going to link against PyQt when I can link directly against Qt, and the viral effect of the GPL does not exten
Re: (Score:2)
Or isn't the GPL considered open anymore?
Not if you want to write commercial software on top of it
That makes no sense. You're essentially saying the GPL isn't open because you can't take code licensed under it and then close it. The GPL is precisely about keeping things open. It is the most Free license out there precisely because it forces people to either play by the open source rules or go write their own.
I bet you thought the GPL's Free was about the programmer's freedom. Sorry, it's not, it's about the code's freedom.
Re: (Score:2)
Re: (Score:2)
Cheers
E
Re: (Score:2)
The GPL is too open-source, man! As a developer, I need to be able to put some locks and chains on it.
Re: (Score:2)
"for utility libraries one expects to use them as LGPL"
For utility libraries *you* expect to use them as GPL.
"Again, I'm in favour of open source, but in favour of a free choice for developers/publishers as well."
Sorry, but I don't eat that dogfood. You are free to use the library as GPL *or* pay for its proprietary license, so you can choose to develop under GPL *or* under your proprietary license of choice.
You are not in favour to choose but in favour to leech (you want to develop proprietary software us
Re: (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 yoursel
Re: (Score:2)
It was already open-source, just under a different license.
It also looks like PySide is nearly 100% compatible [pyside.org] with PyQt, which decreases the headache people who want to switch.
bizzaro world (Score:2)
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) ...
Nokia Makes LGPL Version of PyQt (Score:4, Informative)
Taken from the arstechnica [arstechnica.com] web site that also carried this story
Nokia & OSS (Score:5, Interesting)
Re: (Score:2)
RMS was right, but got one detail wrong. (Score:5, Insightful)
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.
Re: (Score:3, Informative)
You're confusing the GPL and the LGPL. The LGPL is a perfectly fine license, and it happens to be what Nokia chose.
The BSD/MIT/... license has specific problems and pitfalls relative to the LGPL; in particular, it raises the possibility of a proprietary fork. Both Apple and Microsoft have made proprietary forks of BSD/MIT-licensed projects, with arguably worse outcomes than if they had been forced to open source under the LGPL.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
He is "confusing" it in the sense of using Nokia's GPL-to-LGPL change in order to argue that the "end point" is a BSD/MIT/Apache license. In fact, I would argue that the natural "end point" for licenses is the LGPL, not the BSD license. There are good reasons to rewrite a GPL'ed library in LGPL or Apache form (I have done that myself). But people don't usually rewrite LGPL libraries under BSD/MIT/Apache form, and if they do, there is no reason to believe that the BSD/MIT/Apache version is going to be more
Re: (Score:2)
I disagree, I think applications gravitate to the GPL license since it means that any distributed improvements are available to all, which reduces the likelihood of private forks. This comes at the possible cost of discouraging some improvements altogether (i.e. from people who want - for sake of business model or ego - to have their improvements exclusive to their fork).
Now, canoncial implementations of standards such as file formats and network protocols probably do gravitate to BSD or similar, since this
Re: (Score:2)
That's absolutely right. There's not one "best" license. The GPL, LGPL and an MIT/BSD style license cover the main spectrum of Free/Open Source needs and there are many examples of successful projects using each. However, I think most other licenses are unnecessary, so hopefully the gravitation is toward one of those three options.
Re: (Score:2)
Re: (Score:2)
"You are not considering the main point of the argument: that GPL is more restrictive than BSD, and that someday, somebody will have a problem with those restrictions and he/she will sit down and create a BSD version."
That both seems illogical and contrary to observed reality. More a form of whisful thinking (in that you *want* to believe others will develop code under BSD than you in fact getting to develop it yourself) than a fact.
If I need to go through the nuisance of writing enterilly from the bottom
Re: (Score:2)
Thank Kali that the parent is modded +5, Insightful, as it richly deserves to be.
There are times when I still fear that Stallman's legion of cultists have completely overrun Slashdot. It is extremely heartening to occasionally see indications that that is not the case.
Re: (Score:2)
But it's a midpoint - not an endpoint.
That's an incredibly simplistic and unimaginative view of the situation. You're assuming that commercial software will always reign supreme, but that is a bad assumption. The evidence points overwhelmingly to the contrary. Linux is still GPL, and still gaining market share faster than anyone. The GPL is for those who play well with others. Over time, what they can produce is superior, not least because the license permits total code re-use! You don't have to throw away big hunks of code unless they are infe
Re: (Score:2)
Re: (Score:2)
I don't think you got this right, PyQt is already available GPL licensed, and that is not acceptable for Nokia, so they moved to LGPL.
The important thing here is that, if a company wants to promote any infrastructure component, GPL is a horrible license to do that. If you release a library of even a device driver as GPL, you are imposing a very strict condition on your customers, that they have to be GPL too.
This is no way acceptable for most people, and that is why LGPL or BSD licensing is attractive in
Re: (Score:3, Insightful)
>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.
Except that restricting my freedom to "stab you in the face" isn't going to upset many people. But restricting the abilities of companies to develop products that the vast majority of us would like them to make, is.
Re: (Score:3, Informative)
Licensing software under GPL does not restrict the ability of companies to develop products. But the GPL does restrict the ability of companies to prevent other competing companies from developing products.
Re: (Score:3, Informative)
The LGPL does that. The GPL forces me to offer my software for free, and that may very well be an important factor for a company deciding whether or not to develop a product.
If I don't want to offer my software for free, I may very well write up a library to take the place of a GPLed library. After doing that, I may very well license that library using a BSD/MIT or LGPL license, illustrating the original point, that if licenses tend to evolve toward the GPL then they will continue to evolve toward somethi
Re: (Score:3)
The GPL forces me to offer my software for free
No, it forces you to offer your software for Free. You can charge whatever you want for it.
Re: (Score:2)
Re: (Score:2)
>The GPL doesn't restrict your ability to develop products. It restricts your ability to take an existing product, modify it, and lock it up solely for your own benefit
I see this argument occasionally, and I always think, "Is this guy an idiot?"
We're talking about the use of the LGPL.
The LGPL does not allow you to modify code and lock it up. It allows you to *use* someones code, and lock your own code, if you choose.
It's about choice, and freedom. I have the freedom to release my code under the LGPL and
Re: (Score:2)
Sorry to shatter your masturbatory fantasies, but the GPL is still the most popular license among open source projects.
The standard calling card of a member of the Stallmanite demographic; lashings of ad hominem, bookending a diatribe of raw, unadulterated mind control.
Re: (Score:2, Insightful)
Re: (Score:2, Informative)
even close source it and sell it, with no modification
That is utterly false.
The BSD license gives you no right to relicense it. It gives you an unrestricted right to distribute it in source or binary forms, but NOT any right to relicense it.
It also gives you utterly no right to claim it as your own work, in fact, it explicitly states that you must leave the copyright notice intact - the copyright notice which will contain the name of the original author.
The terms of the BSD license are:
You must acknowledge the source by retaining the copyright notice (the GPL
I say kudos for a different reason (Score:2)
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.
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: (Score:3, Insightful)
Nokia is probably focusing right now on the Linux implementation because they want to use it in Linux.
So you know, implementations doesn't just happen by them selves, they need man-hours. So Man-Up and give it to them. But don't whine.
Re: (Score:2)
Sorry if my post came out as a whine, wasnt my intention.
Of course anybody could do it in therory, but I'm not that guy.
My intention wasnt to slam the initiative, just a comment that so far its linux only, since that isnt the platform Im using, it just means that I have to wait a while until I can port my stuff to the Maemo platform.
Re: (Score:2)
Sorry if my post came out as a whine, wasnt my intention.
Of course anybody could do it in therory, but I'm not that guy.
My intention wasnt to slam the initiative, just a comment that so far its linux only, since that isnt the platform Im using, it just means that I have to wait a while until I can port my stuff to the Maemo platform.
You don't have to wait. You can use PyQt on all platforms already, and can switch to PySide when time is right. They are API compatible.
Re: (Score:3, Informative)
Because Linux isn't just a desktop or server OS...it's a bit more than that.
Symbian's not where Nokia's going, apparently- it's Maemo/Qt. Symbian may be a slightly "tighter" OS where the codespace for the OS is concerned, but coding applications for it is an unmitigated pain.
Maemo's much, much easier and only requires slightly more resources (most of which checked in with the Cortex-A8 class SoC's being fielded for most modern smartphones and handheld devices right at the moment...)- so with the current cr
Autodesk Maya (Score:2)
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
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:Size and speed (Score:4, Insightful)
I can't see why I would use PySide
Because you won't have a choice if you want to develop for Nokia phones. Nokia will ship PySide as part of the base install and it will be used by their Maemo GUI. Nokia isn't interested in competing with PyQt for that £350 of developer cash - they're interested in shipping millions of QT based Maemo phones with an app store that supports Python applications.
Re: (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 prefer
Re:Size and speed (Score:5, Informative)
Hi,
I'm the Nokia guy responsible for the project.
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.
You're right: the current size of PySide is an issue, especially if you consider mobile environments such as Maemo, let alone the S60 platform. However, that's also why we are working on Shiboken, an alternate binding component which would create CPython extensions directly instead of using Boost.Python as an intermediate layer. Shiboken is still in its infancy, but we expect we'll be able to solve the size issues for once and all, while retaining full Python-level compatibility with the current bindings.
Unfortunately, there's not much info on this yet, but check our repo for the source code: qt.gitorius.org/pyside [gitorious.org].
No swig? (Score:2)
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..
Re: (Score:2, Funny)
working towards using QT as a (the) UI-toolkit
If they're going to be using Apple QuickTime as the user interface toolkit, I predict it's going to be a fucking disaster.
Perhaps they should consider using Qt instead.