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

Kudos to Nokia

[gavron]

If you cannot get the source to open-source, open-source the source.

Kudos to Nokia.

E

Re:Kudos to Nokia

[piquadratCH]

If you cannot get the source to open-source, open-source the source.

PyQt is open source. Or isn't the GPL considered open anymore?

Re:Kudos to Nokia

[Jurily]

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.

Re:Kudos to Nokia

[emanem]

Yeah but for utility libraries one expects to use them as LGPL, to encourage different kinds of developing.
Imagine if the gcc/g++ libraries were GPL only... who would ever sell an application for Linux.
Again, I'm in favour of open source, but in favour of a free choice for developers/publishers as well.
Hence for basic libraries the LGPL should be a must.

Cheers,

Re:Kudos to Nokia

[ChienAndalu]

It was already open-source, just under a different license.

It also looks like PySide is nearly 100% compatible with PyQt, which decreases the headache people who want to switch.

Re:Kudos to Nokia

[gavron]

The free version is licensed under the GPL. However, if you're complying with Qt's licenses, you have to pay to get the commercial PyQt to get a similarly licensed product. See http://www.riverbankcomputing.co.uk/software/pyqt/license. There are many open source licenses, and having a product that relies on a library have _different_ licenses than that same library unless one pays for it is not the open way.

Cheers

E

Re:Kudos to Nokia

[piquadratCH]

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.

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. Riverbank provided superb Python bindings for a long time and Phil (the guy behind PyQt and Riverbank) offered great support for GPL-users on the mailing list. PySide has a long way to go to offer a comparable experience (just read the blog post on PySide of the main PyKDE developer)

Re:Kudos to Nokia

[Anonymous Coward]

Riverbank provided superb Python bindings

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

[lokpest]

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:Kudos to Nokia

[Anonymous Coward]

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:Kudos to Nokia

[Jurily]

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:Kudos to Nokia

[Jurily]

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:Kudos to Nokia

[FooBarWidget]

"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. You're just being a freeloading leech right now.

Re:Kudos to Nokia

[Anonymous Coward]

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:Kudos to Nokia

[cowbutt]

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:Kudos to Nokia

[ultrabot]

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:Kudos to Nokia

[rohan972]

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
http://redhat.com/
http://www.novell.com/linux/

Re:Kudos to Nokia

[Jurily]

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:Kudos to Nokia

[petrus4]

PyQt is open source. Or isn't the GPL considered open anymore?

Version 2 I consider borderline. Version 3 isn't. It's a legal minefield; a poison pill in exactly the same sense that Microsoft's "Shared Source," was when Eric Raymond called it that.

Stallman corrupts everything he touches. The MIT/BSD license, without restriction or bias, entirely perpetuate the type of gift culture described here. With the GPL, Stallman created a mean spirited, twisted mockery of that, and version 3 has only made it worse. The other disastrous effect that Stallman has had, is to further muddying the waters by entangling the political doctrine(s) of Trotskyite Communism with software development.

The GPL's (and FSF's) influence on the Linux user and development community is plain to see. Its' most vocal members are avaricious, paranoid, howling fanatics who are terrified beyond all reason of Microsoft, and who spend far more of their time engaging in further paranoia about the amount that other people, "give back," than they devote to their own programming efforts.

The GPL and the organisation that spawned it are an infernal scourge; a pestilence on the face of Linux and greater UNIX, and it would do the world good if we could entirely get rid of both.

Re:Kudos to Nokia

[Jurily]

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:Kudos to Nokia

[Anonymous Coward]

But it's essential that we retain almost-1:1 C++ mapping

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).

making your skills & docs directly transferrable

Python bindings should be designed to accommodate Python programmers, not C++ programmers.

Anyway, the new signal/slot binding seems nice and indeed what I have been thinking of.

Re:Kudos to Nokia

[Anonymous Coward]

You might be interested in an upcoming debate entitled Which Open Source Licence is best? being held by the Free and Open Source Learning Centre. You can register and pose questions with the moderator (javascript required) but be quick I think the last day for that is tomorrow..

Re:Kudos to Nokia

[FooBarWidget]

"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:Kudos to Nokia

[FooBarWidget]

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:Kudos to Nokia

[Hognoxious]

My next phone is going to be a Nokia. They deserve it.

My current phone is a Nokia (E71), and it's bloody annoying. What they deserve is a kick up the arse.

Re:Kudos to Nokia

[noidentity]

PyQt is open source. Or isn't the GPL considered open anymore?

The GPL is too open-source, man! As a developer, I need to be able to put some locks and chains on it.

Re:Kudos to Nokia

[ultrabot]

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

[nstlgc]

You'll pay for my software exactly the amount that I'm asking you for it. If not, buzz off and go download somebody else's stuff.

Re:Kudos to Nokia

[Zero__Kelvin]

"It's leeching because apparently you want to make money off someone else's work without ever having to pay him."

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:Kudos to Nokia

[FooBarWidget]

You might have the right to say that after you pay for commercial licenses of the libraries you use.

Re:Kudos to Nokia

[FooBarWidget]

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:Kudos to Nokia

[Anonymous Coward]

Nokia excels at making cheap uncomplicated phones for making phone calls, with good battery life and so forth. From the 3310 onwards, they ruled that segment as far as I am concerned.

Can't speak to their wizbang do it all offerings though.

Re:Kudos to Nokia

[loufoque]

[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 modern technology.

Re:Kudos to Nokia

[ultrabot]

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

[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

[Zero__Kelvin]

"How's that the same thing? Assuming the developer didn't pirate Windows, he paid for it."

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:Kudos to Nokia

[ultrabot]

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: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.

Re:Kudos to Nokia

[ultrabot]

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

[ceoyoyo]

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

[Jurily]

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:Kudos to Nokia

[WaywardGeek]

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 for 20 years, and GUI toolkits have been prime suspects. I doubt MOC makes things significantly worse, and at least Qt already has been ported everywhere. Slows rebuild? Compared too exactly which C++ GUI toolkit? In my experience so far, Qt is the fastest of the bunch, probably because Qt doesn't just include one huge GUI header file everywhere. Can't understand inner classes and templates? This is GUI code. If you use inner classes and templates, you lose 80% of all the GUI programmers out there. Save that stuff for the hard-core code that actually does interesting work. At least there, you can expect the reader of your code to be brilliant. GUI is art, but not exactly rocket science.

Re:Kudos to Nokia

[loufoque]

Such as a declarative one.

The future Qt declarative UI system is a step in the right direction, but not really there yet.

Re:Kudos to Nokia

[iamwahoo2]

According to the GNU FAQ, "The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone."

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 extend to the python scripts that I write.

Re:Kudos to Nokia

[Jurily]

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

[FooBarWidget]

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:Kudos to Nokia

[WaywardGeek]

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 want to own the future of UI development. This will give them an advantage in every computing market they're in. They seem to be willing to give us all free software, and I mean "all" of us - those writing open-source software, and those writing commercial software, so long as they can drive it. So far, they seem like good stewards of their free software. Personally, I'm rooting for them. In fact, I'm new QT user. I'm using QT 4.5, but previous to that I used GTK and MFC. For better portability, we had made the decision to go with wxWindows, and then Nokia announced they were LGPL-ing QT. That was enough for me to scrap about a month of work I already had in wxWindows. Not that wxWindows is lame or anything, but QT is more mature. With Nokia backing it, I think it's odds of "winning" increase dramatically, and I don't want to be stuck maintaining an application developed with a toolkit that lost.

Now, I would be very interested in the details of the interaction between Nokia and Riverbank. Is Nokia showing an evil side, or was Riverbank pig-headed? It's just not cool for giants like Nokia to squash little guys like Riverbank. Did they at least offer to buy them for some real cash, like $1M? That's chump-change for Nokia, and would go far to further improve their "good guy" image in the open-source community.

Re:Kudos to Nokia

[Zero__Kelvin]

"My point wasn't about possible deployment issues to users."

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:Kudos to Nokia

[Spy der Mann]

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 Python developers just as Trolltech was for C++ developers. In my eyes, they're nothing but a bunch of greedy bastards.

Re:Kudos to Nokia

[iamwahoo2]

It appears that Nokia most likely wants to bundle the PyQt package into their phones. The problem arises that when the binding is linked against both Python and Qt, the GPL then extends to those products (according to the GNU website). Nokia is a business, if Riverbank had offered their product under a desired license to Nokia at a price that is less than what they could have developed it themselves, then they would have gotten paid for PyQt.

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:Kudos to Nokia

[WaywardGeek]

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 all the way up to our CEO. It's easier to just use some other software solution.

Re:Kudos to Nokia

[Eponymous Coward]

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:Kudos to Nokia

[Anonymous Coward]

POV, also MOC makes you dependent on Trolltechs toolchain, namely QMake and Qt-Creator, not everybody love those tools, especially when compared to Microsoft's or even KDevelop offerings. Has the QtCreator got any class view already ? The build speed is terrible, even using QtCreator (I tested some early one) the build process took ages using normal 1.5GHz notebook, not everybody has oveclocked 4GHz-Alienware-rig to work on, MOC only slows down already slow build process. Who needs another preprocessor? especially when C++ has one of the most powerful and advanced preprocessors already.

Re:Kudos to Nokia

[Z8]

I see how this is inconvenient for you, but you seem to be making this whole thing more confusing than it needs to be. You're shipping a proprietary application. Therefore you can't use GPL code in it, and must rely on proprietary code. But whenever you use proprietary code, you have to worry about the license, whether the proprietary code is from Riverbank, Nokia, or Qualcomm. If you try to sell your application, your customers will have to worry about your proprietary license too.

Re:Kudos to Nokia

[turbidostato]

"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

[Jurily]

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:Kudos to Nokia

[RedK]

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:Kudos to Nokia

[turbidostato]

"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 using others' code so others will pay for your code but you don't want to pay in turn those whose code you're using for a foundation).

Re:Kudos to Nokia

[Waffle Iron]

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:Kudos to Nokia

[squiggleslash]

Nothing in the GPL forbids the use of software licensed under the GPL in commercial software. The GPL only forbids incorporation into proprietary software. Yes, the distinction does matter.

Re:Kudos to Nokia

[Anonymous Coward]

How did this get modded up to 5? There's no indication anywhere that Nokia demanded PyQt for free.

Re:Kudos to Nokia

[Jurily]

Hell will freeze over before you'll see Qt embracing GObject.

Let's take C, pretend it's an object-oriented language, and then port our already much better real OO toolkit to it! That'd be awesome!

I wonder why nobody did it before...

Re:Kudos to Nokia

[FooBarWidget]

I might as well asking you a similar question: what's wrong with letting the authors profit off the thing that you're using to make profit?

Of course people who buy cheap milk are not leeches. But they don't demand free milk in order to profit off it.

Re:Kudos to Nokia

[7-Vodka]

Let's follow your argument for a second.
1. That means that if I want to release a proprietary application using PyQt
Ok so you want to release proprietary.

2. Now, for my application I cannot use the GPL license...Qualcomm
Great! that's what you want from point 1.

3. 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
What!? See point #1. You said you want to release a proprietary app and this is what started the chain of events. You CAN use the GPL if you want. Just drop the Qualcomm stuff. Oh wait.. you say you can't? Maybe that's the real reason you can't GPL, point #2. What exactly is your goal here?

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.
Hate to break it to you but you have to do that because (#1) your app is proprietary and so is the (#2)Qualcomm stuff.

Except that I cannot use the LGPL for Qt and use PyQt, as PyQt does not support LGPL.
I think you are mistaken. You can use LGPL for QT because PyQT is GPL and they go together quite well. Again the only reason you can't GPL everything are point #1: Because you don't want to and point #2: because of the OTHER proprietary stuff you're using.

Re:Kudos to Nokia

[Joutsa]

My current phone is a Nokia (E71), and it's bloody annoying. What they deserve is a kick up the arse.

E71 has Avkon and Symbian. They are pretty impossible to develop for, and it shows in the end result. There is a reason they are switching to Qt, Linux and Python.

Re:Kudos to Nokia

[Anonymous Coward]

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

[Kjella]

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

[Waffle Iron]

what's wrong with letting the authors profit off the thing that you're using to make profit?

Nothing. But there's nothing wrong with pointing out that in the current market, development tools and libraries often cost nothing, even to use in proprietary products.

If I say "Store A can't expect to milk at a 50% markup when all the other stores in town sell it at below cost. I want cheap milk. I won't pay that price.", it's a demand I'm entitled to make.

Store A doesn't have to listen to my demand, but they might very well find out that they don't sell much milk. Righteous indignation about Store A's right to make a profit won't change the facts. People are going to expect cheap milk, and they're going to complain about and avoid stores that don't offer it.

Re:Kudos to Nokia

[Fringe]

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

[turbidostato]

"At $1500 per head using the tool for proprietary solutions, most companies will put up with a lot of unpleasantries. "

That pays for about 15~30 hours per developer; I don't think that covers for "a lot" of unpleasantries.

Re:Kudos to Nokia

[WaywardGeek]

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 learn all of QT). By choosing this skill for myself rather than GTK+ or wxWindows, I force myself into a position with a strong vested interest in QT's domination.

Re:Kudos to Nokia

[speedtux]

Anybody who releases software under a dual GPL/commercial license is a "freeloading leech": they are trying to use the FOSS community to do their marketing for them, and anybody who contributes to such a project has to assign rights to the company. Dual licensing is better than closed source software, but it does not conform to the goals of open source software.

Re:Kudos to Nokia

[WaywardGeek]

Microsoft's usual mode of operation is "Give me your technology for free, or I'll rewrite it and then bundle it for free in Windows." It's almost the same thing.

Re:Kudos to Nokia

[berj]

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:Kudos to Nokia

[jgrahn]

I'm a new Qt user, but MOC doesn't bother me at all. It's less invasive than "MFC Class Wizard"

Google "damning with faint praise" ... :-)

I don't do GUI programming ... and I'm not likely to start if it means wizards, new preprocessors, new build systems, new casts, new bloody string classes ... I don't see why *this* particular problem has to be so complex.

Re:Kudos to Nokia

[speedtux]

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

I don't, and for just the reasons you give. Dual-licensed libraries use the GPL as a nuisance license; that's not its intent or purpose. Furthermore, dual-licensed code makes it impossible for others to contribute to the code on the same terms as the licensor. Dual-licensed projects can't really be forked either, and that's a bad thing, too. Dual-licensing just doesn't work well for open source projects, and the best thing to do is to stay away from dual-licensed projects altogether. Qt used to have this problem. For PyQt, Nokia has fixed it now. Java still has this problem, although maybe Oracle will fix it.

Re:Kudos to Nokia

[petrus4]

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

[rohan972]

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.

RedHat doesn't sell copies? Where are the free downloads of RHEL binaries? Or is RedHat not making money now?

Re:Kudos to Nokia

[m50d]

I've never worked on Qt, but doesn't the boost signals2 library now offer a superior signals and slots implementation in standard C++?

It's entirely possible, if by "standard C++" you mean very extensive use of templates. Qt's signals/slots could have been written that way, but Trolltech took the pragmatic decision to sacrifice standards compliance for practicality - moc gets you readable error messages, and doesn't have the long compile times. (Also remember that compiler support for templates was a lot worse when qt was started than it is now; I suspect you couldn't have written signals2 five years ago)

Re:Kudos to Nokia

[rohan972]

Yea, and when somebody does it they get an article on Slashdot questioning their ethics. Good point.

Irrelevant to my point and generally irrelevant anyway. What can you do that someone won't criticize?

Re:Kudos to Nokia

[m50d]

you seem to be making this whole thing more confusing than it needs to be. You're shipping a proprietary application. Therefore you can't use GPL code in it

But he'd expect to be able to use LGPL code in it, i.e. the LGPL version of Qt. And he can't. Which is somewhat confusing.

Re:Kudos to Nokia

[ultrabot]

In what way is GObject driving people to Qt? That's totally irrelevant. There are fantastic C++, C#, and Python bindings (plus tons of other stuff like Ruby, Haskell, Java, and whatever else you can name).

I have heard only good things about PyGtk.

However, the "native" Gtk coding still happens in C. If the C++ binding was all that great, wouldn't people prefer it to the C binding? That doesn't seem to be the case; huge majority of Gnome core is written in C.

If C + Gtk (what we think of as "GObject" coding) was halfway decent, we wouldn't have things like Vala.

Re:Kudos to Nokia

[7-Vodka]

You must be genuinely retarded.

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:Kudos to Nokia

[emanem]

Oh, yes, then if I would use gcc/g++ to compiler my code shall I feel forced to released the app under the GPL?
The same applies to the GUI libraries.
Really would you prefer a gcc/g++, gtk+ under GPL or LGPL?
gcc/g++ and gui libraries are so generic, I mean, I'm not talking about some specific software, but to the most generic libraries that are building blocks of everything else...
Be honest...

Re:Kudos to Nokia

[mweather]

Such as a declarative one.

Such as... ? If it doesn't exist yet, it's not modern, it's futuristic.

Re:Kudos to Nokia

[mweather]

I wouldn't say we're better off for having GTK, or at last we're not better off having GTK be as popular as it is. Choice is good, but Linux would be much further toward acceptance on the Desktop with one main GUI toolkit. We'd be better off had GTK completely killed off QT, or if it hadn't been created at all. We ended up with the worst possible outcome. I can't think of anything that could slow down Desktop Linux development more than two major competing DEs duplicating each other's efforts.

Re:Kudos to Nokia

[ultrabot]

actually it can do it already, done by Qt guys themselves, Qt can be integrated into glib mainloop and use GObject just fine

I think the original wish was to expose Qt api through GObject, which doesn't seem likely.

Re:Kudos to Nokia

[Lord Kano]

Not if you want to write commercial software on top of it, which is what Nokia wants to enable.

The problem isn't with commercial software. It's with proprietary software.

LK

Re:Kudos to Nokia

[jedidiah]

You are remarkably naieve.

The split between GTK and QT has nothing to do with the
fact that Linux hasn't killed off Microsoft yet. The Mac
should be ample demonstration of that.

MacOS was unable to gain traction on MS-DOS of all things.

You're not going to leash all dogs to one sled. This doesn't
even happen in Windows. The fact that there is one monopolist
that controls the basic user and developer experience doesn't
impact much else. There are still myriads of commercial and
shareware developers making denizens of crappy, unreliable or
overly complex solutions for any problem you can think of.

If you want there to be one and only one of something then you
are kind of barking in the wrong forrest with any Unix.

I'm glad there's an alternative to iTunes, iPhoto, iMovie and iDVD.

Re:Kudos to Nokia

[Lord Kano]

The GPL's (and FSF's) influence on the Linux user and development community is plain to see.

Yes, without them Linux would have been a one semester project for Linus. It was the GPL that gave all kinds of coders all around the world the incentive to work for free on it. Without the guarantee that they could benefit from their own work, they would have never done it.

LK

Re:Kudos to Nokia

[iamwahoo2]

How is this a misconception? It was stated explicitly in what I quoted from GNUs own website. Not somebodies blog. I am not really sure where you are going with the other paragraph from the GNU FAQ. The fact that the interpreter would become GPL by extension is completely irrelevant because it does not effect either a) programs that are written using Qt, or b) programs that are written in python using PyQt or PySide.

Re:Kudos to Nokia

[jedidiah]

As a license for libraries, the GPL specifically is meant to discriminate against
a particular class of end users. This is contrary to the entire spirit of the GPL.

A GPL work can be forked but the fork will be forced to have the same underlying problem.

That is why Nokia recreated pyqt to begin with.

Now they have equal standing as the original author to determine what sort of
people can "mooch" or "leech" as they have put a similar amount of work into
their version.

"cheap knockoffs from the competition" is part of free enterprise.

Re:Kudos to Nokia

[CAIMLAS]

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:Kudos to Nokia

[master5o1]

Damn. I wanted to get past you so I could go and enter the Viridian forest. I suppose I really do have to go back to Professor Oak and deliver that god damn package. Dammit old man. I want to go through! I'll go back to Pallet town now. But I will return!

Re:Kudos to Nokia

[petrus4]

Yes, without them Linux would have been a one semester project for Linus. It was the GPL that gave all kinds of coders all around the world the incentive to work for free on it.

Here's what I don't get. If the above is true, why is there such a depth of paranoia in needing to continually make sure that everyone knows about it? Surely if it was the case, the implications would be obvious; there wouldn't need to be a group of people repeating ad nauseum, as the FSF's fans around here do, I've noticed.

The difference that I've noticed between Linus and Larry Wall, on the one hand, and Stallman/the FSF's fans on the other, is that to a very large extent, the former two individuals are extremely self-deprecating. For the most part, they don't draw attention to their own work at all, and so as a result, it is all the more self-evident. Linus has told people in interviews that he doesn't like the amount of hype he's received.

Stallman and the FSF, by contrast, seem to be exactly the opposite. There is the insistence on the GNU prefix, and the continual need to make sure that everyone knows about the enormous degree that the GPL has supposedly saved them. The FSF, on a continual basis, tries to take as much credit as it can, for as many different things as it possibly can.

The contrast really is not pretty. On the one hand I'm seeing a fair amount of humility, (not total; Linus can also be arrogant on the mailing lists at times) but on the other, rank, spotlight-hogging narcissism.

Re:Kudos to Nokia

[thesupraman]

Umm, Python runs just fine on the e71?

http://wiki.opensource.nokia.com/projects/PyS60_applications
http://nocivus.posterous.com/python-on-my-e71-sweet
http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/Runtimes/Python_for_S60/

I find my E71 just great, of course would now love the new N900, but that will wait.

Re:Kudos to Nokia

[turbidostato]

!Oh, yes, then if I would use gcc/g++ to compiler my code shall I feel forced to released the app under the GPL?"

1) That's false. Code compiled with GCC is forced to be released under the GPL no more than text edited with emacs is force to be released under the GPL
2) Even if that wasn't false, compile it with Intel's or Microsoft, or anyother else's compiler; nobody forces you to use GCC.
3) Even if there would no other choice than GCC and GCC would force you to release under the GPL, develop your own compiler if usage terms of GCC are such a burden to you. I find Microsoft's Visual Studio to be too much a burden to me, therefore I don't ask them to release it under GPL, I simply don't use it.

Again, you are trying to leech others' efforts to your own purpouses against the voluntee of those that made the work.

Re:Kudos to Nokia

[Qubit]

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.

This is the key to the whole post. If he could have used GPLed code from Qualcomm, then he could have used the GPL license for QT and for the PyQt bindings.

But as we all know, it's not over until the Fat Gnu sings.

The Qualcomm stuff wasn't GPLed, so that makes me wonder: Why do you have to talk to Qualcomm to deal with CDMA stuff? Do they have patents on the protocols?

If there are patents that Qualcomm is enforcing -- software patents, in this case -- then that rather sucks. It makes me wonder about any licensing hurdles that might exist for GSM and UMTS. Is it much easier to develop Free Software for devices that have GSM/UMTS radios than for CDMA radios?

Re:Kudos to Nokia

[daveinthesky]

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

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.

Re:Kudos to Nokia

[beguyld]

You must have been blowing the Qt sales guy... We were paying $3330 for a Windows license for one developer. At least the first year. Additional years were $650 support/mainentance.

Any additional platforms were an additional $1650 for the first year, plus half that as well for support/maintenance in subsequent years.

And then there was run-time licenses for Qt Embedded, even with negotiation that meant another $5K up front in addition to developer licenses.

The money adds up pretty fast. And as someone else noted, it made it very difficult to have bring in contract help on a temporary basis.

Still, we use Qt, because it's better than anything else, but we're happy about the new licensing. We do still pay for support, because it seems worth it, but overall, that can be an order of magnitude cheaper if need to just bring in extra help, or add new people, or start shipping Qt Embedded.

Re:Kudos to Nokia

[beguyld]

You must be genuinely retarded.

Can 7 year olds really post on /. and even get modded +5 Informative? What a place! Now I know how the oppressed people in other countries feel like when they think of coming to the U. S. of A.

If I call someone a "poopyhead" is that worth +5 too?

Re:Kudos to Nokia

[emanem]

Hahaha, you're totally wrong.
You're such in case of epic failure:
- Here is the license for the C++ runtime library (an example).
- Here you can read about the license of gtk+ library, and its purpose.
Again, basic OS libraries should be given under the LGPL or special license as the gcc/g++ exceptions.
You should clarify your mind. gcc/g++ is GPL, bu the GPL part applies to the compiler itself. And indeed, the runtime libraries, needed to run the code compiled with gcc/g++ are under a LGPL like license.
Why should I use gcc/g++ under Linux?
- Best compiler, always up to date
- Best support under this OS
- Sort of reference-like amogst the c/c++ compilers?
Have fun,

Re:Kudos to Nokia

[loufoque]

There are a lot of declarative languages for UIs out there.
The most popular one must be HTML/CSS.

There are also, in non particular order, XUL, XAML, Bling, JavaFX, Adam&Eve, Tk, REBOL, Shoes...
Functional languages such as Haskell or OCaml also have tons of declarative UI libraries based on Functional Reactive Programming. (Fudgets, Fruit, ...)

A lot of such libraries are also in development and research at the experimental stage.

Re:Kudos to Nokia

[Lord Kano]

Surely if it was the case, the implications would be obvious; there wouldn't need to be a group of people repeating ad nauseum, as the FSF's fans around here do, I've noticed.

What we have is the equivalent of people thinking that food comes from the grocery store. We all understand that trucks bring the food from distributors and thoese distributors get the food from farmers or manufacturers. We don't need to explain this. Most people are ignorant about what goes on inside of their computers. They don't understand how the software that they use was produced. That's why it's necessary to remind them. Otherwise, we'll end up with a bunch of people thinking that food "comes from" the grocery store.

LK

Re:Kudos to Nokia

[MynockGuano]

I wouldn't say we're better off for having GTK, or at last we're not better off having GTK be as popular as it is. Choice is good, but Linux would be much further toward acceptance on the Desktop with one main GUI toolkit.

We'd be better off had GTK completely killed off QT, or if it hadn't been created at all. We ended up with the worst possible outcome. I can't think of anything that could slow down Desktop Linux development more than two major competing DEs duplicating each other's efforts.

What makes you think that there wouldn't be two major competing DEs, both using the same toolkit? KDE and Gnome are different enough, philosophically, that we'd likely still have both.

Re:Kudos to Nokia

[DragonWriter]

I see how this is inconvenient for you, but you seem to be making this whole thing more confusing than it needs to be. You're shipping a proprietary application. Therefore you can't use GPL code in it, and must rely on proprietary code.

Wrong. While its true you can't use GPL code in a non-GPL application, whether proprietary or not, you can use software licensed under the LGPL, Apache License 2.0, Artistic License 2.0, 2- or 3-clause BSD license, or any of variety other F/OSS licenses, or software dedicated expressly to the public domain like SQLite, in proprietary software; it is not the case that you "must rely on proprietary code".

Re:Kudos to Nokia

[mweather]

We'd have plenty, just as we have now, but without any real reason to switch, they'd be as popular as fluxbox or xfce.

Re:Kudos to Nokia

[Z8]

That would be true if PyQt was available under any of those licenses. However, Riverbank only offers proprietary and GPL. So since he wants to make a proprietary application, he must use the proprietary version.

Python and QT going mobile.

[Anonymous Coward]

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.

Re:Python and QT going mobile.

[Anonymous Coward]

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.

Re:Python and QT going mobile.

[voidphoenix]

There really should be a -1 Smartass mod...

Re:Python and QT going mobile.

[nstlgc]

Make that -1, Social misfit.

Nokia Makes LGPL Version of PyQt

[omar.sahal]

Don't forget to give credit where it's due.

OpenBossa is a division of INdT, a nonprofit research institute in Brazil that was founded by Nokia and the Brazilian government. OpenBossa has close ties with Nokia and is well-known in the Maemo community

Taken from the arstechnica web site that also carried this story

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.

Re:Nokia & OSS

[togashi06]

Is it already known if it will be possible to have a functional android port on the n900? I read that nokia pushed several drivers for the device to the kernel but I'm still not sure if the parts like the GSM radio have been open sourced. Without that the port wouldn't be too useful...

Re:Nokia & OSS

[mcelrath]

Good question. I don't think anyone knows yet. People have gotten Android on the N800. So it's likely a similar recipe will work on the N900. Of course those "internet tablets" didn't have a GSM radio.

Re:Nokia & OSS

[wasabioss]

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.

Will you put your cell phone into a dual boot configuration?

Re:Nokia & OSS

[Svartalf]

You can always pull the components out and apply them to your Android distribution you want to assemble on the N900. As it stands, the Maemo 5 runs rather well on a Beagleboard...

Keep in mind, unless the GSM radio is on a USB interfaced device, key parts of that interface will have to be Open Sourced as it will have to be in the Kernel- and to ship without the sources to that being made available is a breach of the GPLv2 licensing on the Kernel they use for it. And, even if it's a userland USB device driver, you can always figure out the driver and pluck it out and put it in the Android distribution image as well. The deltas in the libraries should be minimal and shouldn't preclude you doing that and having it work right.

Re:Nokia & OSS

[togashi06]

But wouldn't it be possible for them to release the corresponding module as a binary blob? In that case, unless there was an android kernel with the exact same version it wouldn't be of any use, I suppose.

Re:Nokia & OSS

[togashi06]

I will :)

Re:Nokia & OSS

[markdavis]

>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).

Um, you completely forgot about Palm's Linux (WebOS) on the Pre and soon to be other models too. Development potential is heating up there, also. The future for Linux/FOSS phones is quite bright.

Re:Nokia & OSS

[Locutus]

From that I'd read, Maemo apps are generally written in Python so this was pretty much a requirement if Nokia really wanted to migrate Maemo from gtk+ to Qt. It is sad that both sides could not work out something. On one side is a commercial interest to allow proprietary code to run on the platform and most likely on the other side is desire to keep things open source. Both camps will exist for a long time to come and these kinds of fractures aren't good for either side.

LoB

bizzaro world

[bug1]

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) ...

RMS was right, but got one detail wrong.

[ZorbaTHut]

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:RMS was right, but got one detail wrong.

[speedtux]

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:RMS was right, but got one detail wrong.

[cowbutt]

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 encourages everyone to include support in their products, even if they're an Evil Proprietary Vendor, which in turn makes the standard more useful due to its widespread support. LGPL can be seen as a variant of this that prevents said Evil Proprietary Vendors from 'Embracing and Extending' without contributing their extensions back.

Re:RMS was right, but got one detail wrong.

[agnosticnixie]

That's what LGPL is.

Re:RMS was right, but got one detail wrong.

[petrus4]

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:RMS was right, but got one detail wrong.

[salted-fry]

He's not confusing anything. This story is about Nokia rewriting a GPL library and using the LGPL for the rewrite. His comment about software becoming progressively free-er is entirely relevant.

Re:RMS was right, but got one detail wrong.

[Anonymous Coward]

with no modification, claim it's my own and get merit even trough i didn't do anything.
sorry, but i'll work for other people only if they help me, or at least if they use, but don't steal my code.

Maybe you should RTFL. You can do what you want with BSD licensed code except claiming it as your own. You can do what you want, but you need to keep the credits in.

Re:RMS was right, but got one detail wrong.

[mabinogi]

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 requires this too) - either by leaving it in the source, if you distribute source, or by putting it in the docco, or similar if you distribute the binary.
You mustn't use the author's name to promote software based on this software.

If explicitly grants you the right to distribute the source or the binary with or without modification, if and only if those conditions are met.

A company distributing a BSD licensed product that does not include the copy of the BSD license from the product they distributed is in violation of the license.

So when you BSD license your code, you are not allowing people to steal it. You are giving it to anyone to use for any purpose, but they must acknowledge where they got it from. (For as far as their derivative works still meet the Copyright Law definition of derivative work)

Re:RMS was right, but got one detail wrong.

[drinkypoo]

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 inferior.

Re:RMS was right, but got one detail wrong.

[Bralkein]

I don't really see that this is the case. Just because some software (in this case, Qt and Python Qt bindings) have gravitated towards LGPL from GPL, doesn't mean that you can infer that eventually they will gravitate to BSD. What about what happened to Wine? Wine gravitated from MIT to LGPL, because of concerns about proprietary forks not giving anything back. Could it not be that for many cases, LGPL is a perfectly fine licence for software libraries, and that there is no great pressure for a BSD alternative to be created? Could it not be that within the spectrum of licences, there is a "sweet spot", which varies for each project, which represents the most practical set of freedoms and limitations that will best ensure the success of that project?

As Ben Goldacre might say, it's just not that simple. There's more to free software than the GPL, and there's more to free software than BSD. Consider your options, consider the project's needs and make a judgement call that best befits the situation. Don't just do as the last flag-waver told you.

Re:RMS was right, but got one detail wrong.

[jchandra]

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 this situation.

RMS has got it wrong, actuall if RMS had got his way, GLIBC would be GPL and most of the commerical guys would have to get out of developing on Linux.

Re:RMS was right, but got one detail wrong.

[obi]

While I might agree with you on the GPL, do you really think they'd sit down and write a BSD version if there's a LGPL version?

Re:RMS was right, but got one detail wrong.

[Jonner]

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:RMS was right, but got one detail wrong.

[turbidostato]

"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 up, specially if that's so I can add my propritary bits on top of it, what makes you think I'll "gift" my hard work to anyone else? If I'm going to enterily rewrite it, I'd better license it under proprietary terms if I want to recover my efforts in money or under GPL if I don't want others to go through my same problems ever again.

Re:RMS was right, but got one detail wrong.

[turbidostato]

"Wine gravitated from MIT to LGPL, because of concerns about proprietary forks not giving anything back."

In fact, I'd consider better aligned to reality that LGPL is the middleground towards GPL, not GPL towards BSD. LGPL works because still a lot of software producers think that there's bussiness in proprietary software, and their believes are backed up in the fact that most end users won't give a damn about the modification and redistribution licenses the software given to them comes with.

The more end users become accustomed to their advantages when using open source software (even if they are not going to modify/redistribute themselves) the less place proprietary software will have and the less for a need of a LGPL-like license in favour of a GPL-like one (would Nokia make this move towards LGPL -at a cost for them, if there were nobody interested on developing proprietary apps on top of Maemo? don't think so).

It's true that if such a path would eventually reach its end point, then wouldn't be a need for a copyright law-backed copyleft license (ala GPL), since it would be undistinguishable from a BSD-like in practical terms but still, I don't think we will ever proscribe proprietary licenses and even if we did, the GPL preventions would still be a (now unused) deterrent for future reborns of the proprietary path.

"There's more to free software than the GPL, and there's more to free software than BSD. Consider your options, consider the project's needs and make a judgement call that best befits the situation. Don't just do as the last flag-waver told you."

That's an insightfull down-to-earth consideration.

Re:RMS was right, but got one detail wrong.

[Jonner]

If the goal is for the maximum Freedom in the long run, strong copyleft is perfectly acceptable. Though it's a restriction on the most immediate user, it guarantees the same level of Freedom for any number of steps down the line. If most people find it unacceptable to release drivers under the GPL, why has Linux been so successful? Non-GPL drivers in Linux are pariahs.

I assume that by "commercial guys" you mean developers of proprietary applications rather than Red Hat and Canonical. If GlibC were GPL, one could still use other implementations such as uclibc and dietlibc. If RMS had really wanted to make it hard to release proprietary software that could run on GNU, he would have made GCC viral. Instead it has a specific exception that makes it acceptable to use for software of any license. Though GlibC is very important to GNU/Linux, GCC is absolutely essential as there's no complete alternative. GCC is essential to not all GNU/Linux systems but to most Free Software operating systems, including the FLOSS BSDs.

Re:RMS was right, but got one detail wrong.

[jchandra]

I assume that by "commercial guys" you mean developers of proprietary applications rather than Red Hat and Canonical. If GlibC were GPL, one could still use other implementations such as uclibc and dietlibc. If RMS had really wanted to make it hard to release proprietary software that could run on GNU, he would have made GCC viral. Instead it has a specific exception that makes it acceptable to use for software of any license. Though GlibC is very important to GNU/Linux, GCC is absolutely essential as there's no complete alternative. GCC is essential to not all GNU/Linux systems but to most Free Software operating systems, including the FLOSS BSDs.

I don't think RMS have GCC non-viral because of this reason. IMO, if he makes GCC more restrictive, he will lose his control because it will surely get replaced. And don't think this cannot happen, the other efforts in C compilers does not get any traction because GCC is good enough and it had a license you can live with.

You can see from the SSH and PF situation what people can do if pushed too hard.

Re:RMS was right, but got one detail wrong.

[speedtux]

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 successful than the LGPL form. Actually, BSD/MIT/Apache has potential problems from the point of view of long-term sustainability.

The error in his and your reasoning is to view licenses along a 1D continuum and to conclude that because it moves a little in one direction, it will move further. But the 1D view and the assumption of continued motion along it are fiction; there is no evidence for it.

Re:RMS was right, but got one detail wrong.

[petrus4]

I don't think RMS have GCC non-viral because of this reason. IMO, if he makes GCC more restrictive, he will lose his control because it will surely get replaced. And don't think this cannot happen, the other efforts in C compilers does not get any traction because GCC is good enough and it had a license you can live with.

Exactly the point. Stallman's use of the word "freedom," is doublespeak.

GCC also needs to be replaced; the FSF needs to be entirely routed around.

Re:RMS was right, but got one detail wrong.

[Jonner]

Well, get on it then. Nobody's stopping you. If you can replace GCC with something better, more power to you. Personally, I can't imagine why that would be worth the enormous effort.

Re:RMS was right, but got one detail wrong.

[petrus4]

If I had the requisite technical knowledge, I would.

As for why it's worth it; primarily so that I never have to listen to another GNU/drone smugly imply, "We have a giant monoculture, and our license governs everything, so if you don't like our terms, hit the road, Jack!"

I'd prefer to be able to tell the FSF to fuck off for once, rather than it always being the other way around.

Re:RMS was right, but got one detail wrong.

[Jonner]

So, you think RMS didn't make GCC non-viral because he wanted to prevent proprietary software from being developed to run on GNU? As you say, people needed a license they could live with, which would include both GPL-incompatible Free Software licenses and proprietary ones. I think RMS accepted that for people to start using the platform, he would have to allow both cases even though that wasn't his ideal scenario.

Overall GCC seems to be a great success, surviving a major fork and improving technically after RMS gave up direct technical control. The efforts to replace parts of it with alternatives seem promising as well.

Re:RMS was right, but got one detail wrong.

[Jonner]

You seem to misunderstand what the FSF is about. They have no problem with Free Software that is not under the GPL or LGPL as long as the license is compatible. Compatibility is purely a pragmatic issue and there are plenty of compatible license to choose from. GNU is most definitely not a monoculture. GNU packages include a huge range of types of software from a huge range of developers, many working for various corporations. My very uninformed impression is that the BSDs are much more monoculture, which is not necessarily a bad thing since they're more focused on specific technical priorities.

For a package to be considered part of the GNU project, it generally needs to be under the GPL or LGPL, but GNU people never say "you should use no non-GNU software." All they say is "you should not use non-Free software." Notice that though Linux is released under the GPL, it is not part of the GNU project and this doesn't prevent anyone (even RMS) from recommending Linux as part of a GNU-based system.

Where does your hostility come from? Does it make you angry that the FSF wants software to be as Free as possible for the maximum number of people? Of course if you had the time, you could write all of your own software which would give you personally maximum freedom, but that's not practical in the real world. Everyone has to depend on someone else's software at some point.

As for my personal software use, I prefer to use things that are Free or Open Source, whether it's GPL, LGPL, a BSD or X11-style license or any other. I know that if it's Free or Open Source, it won't stop me from doing anything I want with it. When I release code, the license depends on the situation. Often, it's an extension to existing code, so it makes the most sense to use the license of what I'm contributing to.

Re:RMS was right, but got one detail wrong.

[cowbutt]

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. So in the end, the license will gravitate towards the most free option: BSD (or equivalent).

I was going to counter that with "where are the BSD licensed (C/C++) compilers" but I see there are quite a few out there. However, I note whilst some have advantages compared with gcc (e.g. PCC appears to produce significantly faster code), they all also have significant disadvantages compared to gcc. So whilst one (or more) BSD-licensed clone(s) of a (L)GPL-licensed package may eventually show up, it will be harder for any one project to accrue critical mass and become the BSD licensed-clone. Now, if there's a clone out there that does everything you need, great, and there may even be something to be said for the evolutionary benefits of multiple clones with slightly different target uses, I find it unlikely that anyone would create a functionally-equivalent drop-in replacement for a (L)GPL package.

Re:RMS was right, but got one detail wrong.

[ZorbaTHut]

While I mostly haven't needed to respond to this debate, I thought I'd point out that GCC *is* being replaced . . . by a package with a BSD license.

(It'll take a bit, of course - something as huge as replacing GCC isn't an overnight thing.)

Re:RMS was right, but got one detail wrong.

[petrus4]

[quote]Where does your hostility come from? Does it make you angry that the FSF wants software to be
as Free as possible for the maximum number of people?[/quote]

Mostly just from the legions of myopic, condescending, cultic trolls who I keep encountering on this
site, to be honest.

Also, some of us recognise Stallman's use of the word, "free" as a classic cultic redefinition.
Version 3 of the GPL is probably the single most restrictive FOSS license in existence that can
still claim compliance with the OSD.

With non-copyleft licenses, you can do whatever you want with something that uses them. The
fear-based argument that copyleft is needed to preserve FOSS in general doesn't hold water either;
because if it did, the BSDs, Apache, and other such projects which use non-copyleft licenses
wouldn't continue to exist.

Pretty much the entirety of the FSF's ideology is based on fear and paranoia, and generally fairly
hollow paranoia at that. DRM didn't end up going anywhere. Binary video card drivers haven't meant
the end of FOSS in general, and nVidia are still one of very few companies in existence that offer
closed source drivers for hardware.

Anyone who thinks that the FSF is in any way responsible for the above things being non-issues, is
also delusional. Campaigns like Defective by Design are launched by and for the proverbial lunatic
fringe; they don't register with those of us who live above ground.

Essentially, the FSF are, as I've said, a fairly textbook cult, and I'm tired of contending with
people who haven't got the organisation's mind control out of their systems, on Slashdot.

Go and do some research on Stallman, and realise the extent to which you've been lied to. The
single main reason why I have as much of an issue with the man as I do, is because I did that, and I
realised just what a sham pretty much everything about the FSF really is.

If more people around here would do that, they might also stop parroting the FSF's propaganda
literally word for word like broken records as well, and my general stress level would decrease
accordingly. ;)

Re:RMS was right, but got one detail wrong.

[Jonner]

No, LLVM is a replacement of parts of GCC. Clang combined with LLVM doesn't need GCC to compile C code, but it's a long way from being mature and complete enough to replace GCC yet. It may be some day, which will be a good thing because competition will stimulate improvements.

It's also important to notice that the authors of LLVM and Clang didn't start those projects because they hate GNU, but because they had specific needs that GCC's design wasn't good enough for. Hopefully anybody who uses them does so for good reasons rather than an irrational hatred of GNU or the GPL.

Re:RMS was right, but got one detail wrong.

[Jonner]

Well, if the FSF is a cult, you must have drunk the kool-aid at some point. That would explain your irrational hostility. OTOH, I've never agreed completely with RMS. His belief that developing proprietary software is immoral can't be supported IMHO and therefore he is fringe. For him, Free Software may be close to a religion, which I can't subscribe to. However, that doesn't prevent me from seeing the value to society of Free Software (or libre or Open Source or whatever term you prefer).

The GPL is far from perfect and is not the right choice for all projects, as evidenced by the existence of many successful projects under other licenses. However, it's only more restrictive than other licenses when you narrow your focus to the first recipient of the source. If you consider all recipients of all derivatives of the original, the GPL provides exactly the same freedoms to everyone, while non-copyleft licenses don't. An author releasing under the GPL is restricting those who receive the source from him for the purpose of keeping the freedoms the same for recipients of derivative works.

It's ironic that some say that non-copyleft licenses are inherently more "commercial-friendly" when there are many examples of corporations releasing under the GPL because they realize it prevents competitors from benefiting unfairly. Which license is more "commercial-friendly" depends entirely on the circumstances.

Would you care to explain how DRM didn't end up going anywhere? If you think proprietary Linux drivers aren't a problem or are restricted to Nvidia hardware, you've obviously never encountered one of the numerous types of problematic WiFi chips. Also, can you point to a non-copyleft FLOSS kernel with as diverse hardware support as Linux? Or are you promoting proprietary ones?

Re:RMS was right, but got one detail wrong.

[larry bagina]

Take a look at llvm. Right now, it's useable with a gcc front end, but a free (as in BSD like) C/C++/Objective C front end is being developed.

Re:RMS was right, but got one detail wrong.

[ZorbaTHut]

I never claimed that this gradual push would happen entirely out of a hatred of GNU :P

Re:RMS was right, but got one detail wrong.

[jchandra]

Maybe you remember Cygnus and other numerous commercial contributors who have contributed significantly to GCC. They would have done that work if GCC was viral. And you know RMS views on Cygnus.

I still have a lot of respect for RMS ideals, his movement has spread an awareness and a framework in which you can discuss freedom of software. But I see the bad side too, and the worst of that is seen in the GPL3 debate and the Lignux debate.

Re:RMS was right, but got one detail wrong.

[makomk]

Clang combined with LLVM doesn't need GCC to compile C code, but it's a long way from being mature and complete enough to replace GCC yet.

However, you still need some C++ compiler to compile LLVM itself - and that probably means GCC. (I don't think Clang's C++ support is even close to good enough for this.)

Re:RMS was right, but got one detail wrong.

[ZorbaTHut]

I think you need to go read my post over again, as never did I say anything that disagreed with any of that :P

I say kudos for a different reason

[erroneus]

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?

[jaclu]

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:multiplatform?

[summner]

umm it's open source. You want it to be better ? Contribute ! :]
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:multiplatform?

[jaclu]

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:multiplatform?

[ultrabot]

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:multiplatform?

[Svartalf]

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 crop of smart handhelds, it's a winner for them to consider that path. Moreover, it's easier to sell people on making applications (like games, for example...) on the platform than with something like Symbian. The N900 will have versions of the stuff I'm currently porting over to ARM Linux, as will the Pre, G1, etc.

Re:lol delusional BSDtards

[mustafap]

>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:lol delusional BSDtards

[petrus4]

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.

Autodesk Maya

[jabjoe]

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. ;-)

Re:lol delusional BSDtards

[mustafap]

>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 allow others to re-use it with their own code, which they release as *they* choose.

The GPL does not give either of us that freedom.

It's about freedom, right?

Re:lol delusional BSDtards

[Anonymous Coward]

It is...there was an article recently that proclaimed that the Apache license is applied to more newer projects in the commercial realm.

http://news.cnet.com/8301-13505_3-10319560-16.html

Re:lol delusional BSDtards

[janwedekind]

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.

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:Size and speed

[bert.cl]

Well, given what I read about Nokia releasing this bundle as a platform and the fact that PySide and PyQT are API compatible, I can imagine someone coding necessary features against PySide and then just decide whether a switch to a lighter version (i.e. PyQt) warrants the 400 EUR investement.

All in all, it's a smart move. You code in a standard environment and if your deployment gets too large, you can just drop in a cheap and qualitative replacement. The end result is the same: faster and more applications on a Nokia platform. This may even be a good thing for PyQT.

Re:Size and speed

[chrb]

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:Size and speed

[Just Some Guy]

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:Size and speed

[mairas]

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.

Re:Size and speed

[m50d]

New project in not yet being up to the standards of its mature competition shocker?

Re:Size and speed

[sandGorgons]

Isnt the Smoke library a good starting point for your effort?

I havent worked with either, however it sounds (http://www.kdedevelopers.org/node/427) quite interesting in its goals. I am speculating that Smoke was never seriously used for Python (instead it focussed on Ruby), because of the momentum behind PyQT.

However, given that it can interoperate with any scripting language (http://techbase.kde.org/Development/Languages/Smoke) - isn't it a good starting point ?

http://github.com/thephred/kdebindings/tree/35ba8e5eac62b1e7ab52ac439ea158963ece089b/smoke

Re:Size and speed

[maceru]

> Unfortunately, there's not much info on this yet, but check our repo for the source code: qt.gitorius.org/pyside [gitorious.org]. Mairas, I have just written some explanations about Shiboken on my personal blog: http://setanta.wordpress.com/2009/08/31/shiboken

Re:lol delusional BSDtards

[nstlgc]

"Shatter his masturbatory fantasies" ? "freedom to stab you in the face" ? "utterly absurd" ? "outright lying" ? "understatement of the millennium [sic]" ? You and your silly hyperbole are poster child for the entire GPL generation.

Re:lol delusional BSDtards

[pizzach]

Blanket statement. Yes it upsets some people in the same way a construction detour does. Just because they cry and swear about it and swear doesn't mean they can't still reach their final destination. You have to choose the road that suits you. I swear, slashdot has been filled with prima donna complaining about something that might break their nails.

Re:lol delusional BSDtards

[ceoyoyo]

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 something even freer.

No swig?

[radarsat1]

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:No swig?

[ultrabot]

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..

SWIG doesn't really cut it for a C++ project with these size/performance requirements.

Re:No swig?

[Simon]

SWIG doesn't really cut it for a C++ project with these size/performance requirements.

yep, and that is why Riverbank developed their binding tool SIP. Because SWIG wasn't good enough. That's also why the name SIP was chosen. A sip is a little swig.

Re:lol delusional BSDtards

[turbidostato]

"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."

True.

"After doing that, I may very well license that library using a BSD/MIT or LGPL license"

True... in theory. In practice what are the bets for a company that already wants to produce closed source software to distribute some parts of its hard earned codebase under a license any more free than that of its main product?

If they are going to develop such a library on its enterity on their own for the sole purpouse of being able to use it within their closed source application you can bet they'll distribute it under the very same closed-source license than their main app.

In fact, can you provide any example of software companies *not* doing that, given the case? For all that I know, companies only have developed from the ground up BSD-like software when trying to get into new markets by means of stablishing new standards (ala NFS). In all other cases companies have only develop free/open source when pushed by market forces (like the ability of being able to use 99% of a third party code base for free at the cost of being forced to follow the original license on their 1% addition). In those situations GPL will produce much new free software than LGPL or BSD by means of the snowball effect.

Re:lol delusional BSDtards

[RedK]

The GPL does not give either of us that freedom. It's about freedom, right?

It's about the code's freedom, not the programmer's freedom. The GPL is the only license that assures code will always be available and that the users of said code will always be able to use any modification made by anyone to that code. If you can't see that as an advantage, as the GP does not, then you don't understand what the GPL is all about.

Nice ad hominem

[nietsch]

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? ;)

Re:Nice ad hominem

[petrus4]

and the communism jibe shows your colours as a true blue american.

Take another look. A quote here
from Leon Trotsky, a reference to Anarchism (if not outright Anarcho-Communism) here, and information about research claiming that
economic reward is not a motivator for work.

The Debian Project and the FSF are both demonstrably Anarcho-Communist; it isn't simply a baseless stereotype. I
can find you more references if you'd like.

You don't like the GPL, but why that is exactly you do not tell.

You could have a look at one of the responses I had to the GP; but to explain it myself, the GPL v2 dictates downstream
use. Other licenses do not. The GPL v3 goes further than merely dictating downstream use of the software, and attempts
to dictate patent issues as well.

The MIT and or BSD licenses you prefer have been a brake on the uptake/development of all the BSD's.

Given the amount of heat and noise which Stallman and his aforementioned cultists have a tendency to generate, it was
predictable that, for a while, the GPL would hold sway. It's never really been used, by business at least, due to
genuine economic viability, but more primarily because of the amount of social pressure which the cult has tried to
exert on people.

However, the GPL was specifically designed and intended to be an anti-commercial license, and as we've seen reported in
a couple of articles here on Slashdot recently, vendors are slowly figuring that out, and gradually beginning to move to
non-copyleft licenses, particularly the Apache license. The GPL v2 fell below 50% usage for the first time, recently;
and indications are that that isn't because of uptake of v3, either.

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.

This is standard pro-FSF rhetoric; and I've written about reciprocity paranoia being expressed by such individuals
before. It's fear based and mean spirited, and apart from anything else, it's also scarcity-based thinking, which
illustrates that the speaker is not thinking from the vantage point of a genuine gift culture.

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? ;)

Smug condescension, and an attempt to minimise the percieved credibility of dissenting opinions, are also extremely commonly observed tactics among FSF/GPL advocates.

Re:lol delusional BSDtards

[turbidostato]

"You have obviously never been in the situation of discovering a thrid party library you'd love to use in your commercial application, only to discover its GPLd."

What does it mean? "I thought I could use all this good work for free but, alas, I can't"? What a pity.

"the LGPL is poorly understood and overly complicated"

What!!!??? You obviously never been in the situation of examining the legality of your contracts with third party vendors when you want to use their closed source codebases. LGPL is crystal-clear in comparation.

"and really - when it comes right down to it - just as unsuitable."

Unstated assertion, not backed by facts (my company develops on top of both GPL and LGPL code with no problems, thanks).

"Most business actually have no intention whatsoever of taking GPLd code and "locking it up"."

Maybe the fact that it's obviously unlegal and quite a bad press when discovered has something to do.

"why would I also want to maintain a copy of _someone else's_ code? There's no benefit in it to me."

Maybe you see it from the developer's point of view where less code in-house means less coders to maintain it and so, maybe you'll be fired. From the company's point of view, if helping maintaining _someone else's_ code means cheaper than fully maintaining _your own code_, it's a deal.

it runs Linux

[speedtux]

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.

are you kidding?

[speedtux]

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.

Re:are you kidding?

[ultrabot]

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.

QObject is not really "object model". Qt uses standard C++ objects, with some autogenerated .cpp files to provide for metaobject stuff. Everything still happens in confines of normal C++.

Also, the cpp files are autogenerated by moc, as opposed to having to write any of the boilerplate yourself.

GObject is harder to develop for, but easier to integrate into other software.

QObject stuff can be trivially integrated to existing C & C++ code. Apart from the moc phase, nothing that special is happening.

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.

Yeah, but bindings somehow manage to exist. They may not be trivial or small, but unless you are the binding author yourself you don't need to care that much.

An additional problem with QObject and Qt is that it doesn't even conform to C++ library standards very well.

Qt app code is perfectly standard C++. C++ standard has nothing to say about whether one/some of the files to compile were generated by a tool (in this case, moc), or whether it reserves a few macros for "creative" use.

Qt works in practice much better than it looks on paper. Same can't be said for GObject - stable C ABI sounds great, but the development is still very painful and annoying and you start wondering whether it's all worth it. YMMV, some people still like it - I like to think C++ exists for a reason.

Re:are you kidding?

[Tweenk]

QObject stuff can be trivially integrated to existing C & C++ code.

Duh, that's trivial. The hard part is integrating with other languages, which GObject does perfectly; most bindings for GObject-based libraries can be programatically generated. That's why most people writing a new language go for GTK bindings first.

Yeah, but bindings somehow manage to exist. They may not be trivial or small, but unless you are the binding author yourself you don't need to care that much.

More complicated bindings = more bugs and lower performance.

Same can't be said for GObject - stable C ABI sounds great, but the development is still very painful and annoying and you start wondering whether it's all worth it.

If you don't like C boilerplate, you can write in Vala, which compiles to C sources and therefore preserves all he benefits of GObject while giving you a modern language to work with.

Re:are you kidding?

[speedtux]

QObject stuff can be trivially integrated to existing C & C++ code. Apart from the moc phase, nothing that special is happening.

No, it cannot be "trivially integrated" with C code or any other language. Anything that involves C++ involves dealing with global constructors, initialization order, new-vs-malloc, destructors, name mangling, exception handling, STL, template expansion, and RTTI, among many other things. The C++ standard and runtime are an unportable, complicated mess, and it's getting worse and worse with every succeeding standard. And Qt makes the mess even worse by duplicating a lot of that functionality.

C is a necessary evil; C++ is a bloated evolutionary dead end.

Qt works in practice much better than it looks on paper.

If you want to program in C++, Gtkmm provides C++ programming support that is at least as good as Qt, it requires no preprocessor, and it is far more C++ standards conforming.

Re:are you kidding?

[ultrabot]

No, it cannot be "trivially integrated" with C code or another language. Anything that involves C++ involves dealing with global constructors, initialization order, new-vs-malloc, destructors, name mangling, exception handling, STL, template expansion, and RTTI, among many other things.

That's why you should use the C side from the C++ side. I've had no problems at all using C libs from C++.

If you want to program in C++, Gtkmm provides C++ programming support that is at least as good as Qt, it requires no preprocessor, and it is far more C++ standards conforming.

I'm more interested in productivity than "C++ standards conformance" (by which you probably mean using stl over homebrew containers).

I'm very suspicious about Gtkmm, as it doesn't seem to have a mindshare comparable to the C binding (actually it doesn't even come close). If even the Gnome community rejects it, why would outsiders pick it up?

I'd rather go with a toolkit where C++ (which is the language I'm using) is a first class citizen (like C in Gtk+). The bindings for Python are good enough for my needs.

How is LGPL Qt not compatible with PyQt?

[caseih]

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.

Re:How is LGPL Qt not compatible with PyQt?

[wowbagger]

"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."

Perhaps you think that, but Riverbank thinks otherwise, and states so very clearly - I've asked them. You must use the same license for Qt as you do Qt, you cannot use the proprietary PyQt with the LGPL Qt, and that is straight from Riverbank. I am more inclined to trust the word of the people who on the code than the opinions of a large number of Slashbots who have not personally looked into the issue (that's not directed at you, Caseih, but at the myriad of other posters on the board).

Re:Free as in freeloader

[petrus4]

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?

Nokia buying Riverbank

[renrutal]

Couldn't Nokia buy Riverbank like they did with Qt Software? Probably they did try, and this really was the last option available.

Re:Nokia buying Riverbank

[paugq]

"Buying Riverbank" means buying its assets and hiring Phil. It's a 1-man operation. If Phil likes his independence, Nokia has nothing to do.

Re:lol delusional BSDtards

[janwedekind]

There's a big difference between LGPL and BSD/MIT. But if you are arguing to release code under BSD/MIT in order to attract the interest of companies developing proprietary software "products", then your code is actually going to evolve into something much less free.

Good Point

[Prien715]

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;)

Re:lol delusional BSDtards

[ZorbaTHut]

Do you see the Linux kernel gravitating to BSD? Do you see GIMP gravitating to BSD? Do you see OO.o gravitating to BSD?

No. Never. The legal issues alone would be near-insurmountable.

I do, however, see a point where the Linux Kernel is Good Enough, and there are no longer major underlying improvements being made because, well, what would be improved? And on that day, the Linux kernel stops moving forward . . . and the BSD kernels don't stop moving forward, since they are not yet at that point . . . and eventually reach the Linux kernel in capabilities and stability.

And at that point, the Linux kernel goes away, and the BSD kernel becomes the norm.

It's a long ways off. But I think, long-term, it's inevitable, for much the same reason as Windows became Good Enough many years ago and the Linux kernel and applications have been catching up ever since.

I don't know of any immediate competitors to GIMP or OO.o. But I think, eventually, they'll show up. (It may take some time - office software is not as suspectible to this as operating systems and libraries are, simply because almost nobody needs to link them in.)

You may note that I've licensed several packages under the GPL. I'm no stranger to the GPL at all, and it's a good license. I just think it's rather inevitably going to give ground.

Re:lol delusional BSDtards

[RedK]

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:RMS was right about the details

[ZorbaTHut]

Yes, that's certainly what happened to the BSD kernel when Apple forked it.

Oh, wait, it wasn't at all.

The vast majority of people don't make open-source packages because they have something to sell, and they don't stop when people start selling it. (People sell open-source software even when it's GPL licensed, remember.) Some people do grab BSD-licensed things and improve them . . . and sometimes they contribute improvements back to the project. And sometimes they don't. Such is life.

People can't force BSD code to stop being free. I'm really not sure where that ever came from, but it's just complete falsehood. They can make their own improvements, and own those, but the core code?

Well, it's free - and chances are good that unless the improvements are a major, major amount of work, they'll end up implemented in the original version soon anyway.

I don't know of any case where the hypothetical situation you claim as inevitable has happened.

That's kinda silly reasoning

[HalAtWork]

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.

Re:That's kinda silly reasoning

[ZorbaTHut]

Considering that right here we have an example of a package being rewritten from GPL to LGPL, I can't say I agree with your logic.

Not every action is motivated by fear, you know.

We're all minions of accountants and lawyers

[h00manist]

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.