OSNews

"It is perhaps the case where Trolltech does not feel it is economically profitable to support small ISVs and other small players. It is hard to say as the pricing model only supports two extremes today and I cannot find any information on what the future pricing models would be."

This is a good point. Business has never been easy for the small ISV. Did anyone really make money off of Windows 95 shareware? It's tough because it is likely in the current climate that someone will come along and marginalize your company's IP by releasing a similar product under a GPL-compatible license. Is it a better bet to release under GPL and attempt to leverage market share to monetize something (service or otherwise)? Is it better to develop in Java/Mono/Gtk+ and hope that KDE users will be a targetable audience for your commercial software? Or is it best in the long run to pay the Qt license and hope that the revenue stream eventually pays off?

As Eric's post points out, desktop Linux is not a friendly space for commercial ISVs at the moment. We don't pay for software. We'd rather miss the functionality for now and try to develop a free alternative as quickly as possible. When the real desktop Linux "tipping point" comes, it will still be the case that Linux users will not want to pay for software. There will be a niche market for commercial software on Linux, and this will probably be dominated by large ISVs with a proprietary software legacy (Adobe for example).

The Linux economy will be disappointing for ISVs. Markets are not usually created to serve and forever serve the best interests of the consumer, and this is what the GPL does. Vendors will have no choice since consumers will demand the best value. Service oriented businesses might see the Linux economy as a huge opportunity, however. In the long term (20 years?), the GPL will create the world's first monopoly that truly serves the consumer.

This is a good point. Business has never been easy for the small ISV. Did anyone really make money off of Windows 95 shareware? It's tough because it is likely in the current climate that someone will come along and marginalize your company's IP by releasing a similar product under a GPL-compatible license. Is it a better bet to release under GPL and attempt to leverage market share to monetize something (service or otherwise)? Is it better to develop in Java/Mono/Gtk+ and hope that KDE users will be a targetable audience for your commercial software? Or is it best in the long run to pay the Qt license and hope that the revenue stream eventually pays off?

The popular Windows shareware does pull in reasonable money. Look at something like WinZip for instance. Or before WinZip, PKZip for DOS/Windows. There are today many small companies (and individuals) making a living off of the various forms of shareware.

WinZip was recently sold to another company (for 3-4 million USD is what I hear) who will attempt to make the company profitable / more profitable. Here's what an analyst had to say:

“There aren’t that many free businesses out there that have converted to a paid model,” said Peter Coleman, senior application software analyst at ThinkEquity Partners, a research and investment banking firm. “Conceptually, it can work if you add value to the product and package it well for customers.”

There are no popular GPL shareware programs that I am aware of. Usually GPL programs are "free software" or "please donate ware".

The big issue with the GPL is that it destroys the software business model where your code is your IP. It allows any customer to take your code and do what they want with it, including reselling it for money and putting you out of business.

In return for destroying this common software business model, the GPL enables service software service business models. The revenue stream is not attached to the code anymore, but to ancillary services that presumably you have some core competence to deliver.

Two things come to mind on the GPL.

First is that for software that was formerly cheap, having a GPL-only option will eliminate the broad and thin code-based revenue pool. In its place will be add-on/support services. So more and more software will be designed to require more support/services as this is where the money is. If we look at many of the underdocumented and hard(er) to use Linux applications, we can see economic reinforcement is driving app development and the typical quality of Linux apps is a few big steps less than that of apps on Mac and Windows. Without the economic incentive to build quality apps, there may never been enough quality apps to ensure the success of a particular GPL-based platform.

Second is that for expensive applications, the GPL functions merely as an "early availability" code escrow. The cost of supporting the code for expensive apps will be factored into the cost of the apps driving the cost to the customer even higher.

So what comes of this WRT Qt?

To begin, as Qt is not economically viable for small ISVs, we will not see any large widget or component library for it as these libraries are usually built by small ISVs. As it is the small ISVs who would also be many of the customers for widget libraries (along with corporations), the lack of this layer in the food chain will lead to starvation at a number of layers in the ecosystem, ultimately inhibiting the sales of Qt to larger corporations. We will see small ISVs turn to other software ecosystems where the GPL is not required.

The large corporations that use Qt will simply absorb the high costs of the licenses. It is only for them that the relative cost of Qt is low. So nothing much will change here as large corporations already pay a lot of money for software.

Qt continue on as a part of the GPL ecosystem, but will not make any substantial inroads to anywhere else except for mobile phones.

And for GPL-based economies?

The GPL makes it more difficult for the small GPL developer to make money. As "time=money" and time is finite, these small developers will not participate in GPL markets as they cannot afford it economically. There is no pay-off as they are developing nothing of value which they ultimately own.

So who will participate in the GPL economy? Mostly large companies that depend on low quality software that requires a lot of support/services. So we find IBM a major backer of Linux. And Sun. And HP. And Oracle. And other companies who make a lot of money on services.

Thus one possible future of GPL economies is a split between large mega corporations and gentleman coders who can develop software for free as their livelihood does not depend on it. By the participants involved, we can see that in this future, GPL economies will belong only to the wealthy.

It is hard for me to imagine how the goals of mega corporations and gentleman coders are going to support desirable and admirable communities as time goes by.

It is even more difficult to imagine how there would ever be any system created here that serves the consumer. The gentleman coders cannot relate to the consumer and the large mega corporations that are funding the GPL programs just want to bleed the consumer for as much as possible.

We must not be so naive as to think the GPL does away with greed.

Of course, all this discourse depends on the evolution of the GPL itself. Who knows what 3.0/4.0 will be like.

To date, I do not believe the GPL has addressed the livelihood of the people whose IP is the code/product vs. services. The GPL may evolve to provide a better economic balance than it does today. If the GPL does not evolve, we will see a bifurcation of the software world -- lots of low quality software that requires a lot of service/support vs. quality products that require less service/support. It is already what we see today with Windows/Mac vs. Linux and this pattern, driven by the economics of the GPL, would likely continue.

There will be occasional dual-license companies such as MySQL. However, these companies are artificially propped up by massive VC investment hoping for an acquisition. Given a bit of time, only the software that is required for the service businesses of large enterprises will survive (and what the gentlemen coders provide pro bono).

I have little idea what this world will look like. I know today it is damn hard to get any work done with open source software unless you have already mastered a rough learning curve. With the additional time it takes to use open source tools, one would expect businesses where time is important to shy away from GPL programs and those businesses where time does not matter to invest in GPL programs. So maybe the important businesses of the future, wineries and distilleries, will all run GPL ;-)

Hmmmm. I think I will write this up in better form and offer it to OfB. See if they will publish it. There is a vast middle ground of opinion between Eric and Tim that would be interesting to talk about.

"Of course, all this discourse depends on the evolution of the GPL itself. Who knows what 3.0/4.0 will be like.

To date, I do not believe the GPL has addressed the livelihood of the people whose IP is the code/product vs. services. The GPL may evolve to provide a better economic balance than it does today. If the GPL does not evolve, we will see a bifurcation of the software world -- lots of low quality software that requires a lot of service/support vs. quality products that require less service/support. It is already what we see today with Windows/Mac vs. Linux and this pattern, driven by the economics of the GPL, would likely continue. "

Web services presently slot inbetween the two. Of course 3.0 could close that loophole.

Thanks for the thoughtful post.

The big issue with the GPL is that it destroys the software business model where your code is your IP. It allows any customer to take your code and do what they want with it, including reselling it for money and putting you out of business.

Let's be very clear here that noone is forcing anyone to license their original code under GPL or any other open license. So I'd roll back the "destroys the business model" rhetoric. If you want to keep your core business value in your code, then don't open the code. There's a little company in Seattle you might want to check out that follows this model and they seem to be doing very well for themselves. That model is going to be valid for quite a long time to come, if not indefinitely.

I question your basic premise. I think what we're seeeing with free and open licenses is the very slow, very gradual movement of a great deal of software to commodity status. (Server Linux is a good example, big-budget video games are a bad example.) And I think the overall effect on programmers will be... just about nil. Most coders don't make their living producing over-the-counter software anyway, they produce custom code for internal use. If all OTC software disappeared tomorrow (and it won't), the far majority of programmers would still have their jobs. Outsourcing is probably a much bigger issue in their lives. And even if that weren't true, commoditization isn't exactly something you can control. It happens to segments of all mature markets, and ultimately benefits companies and consumers.

So who will participate in the GPL economy? Mostly large companies that depend on low quality software that requires a lot of support/services.

The best, most successful, most mature example we have of a "GPL economy" so far is the Linux server space. And I think most sysadmins will disagree that Linux server solutions are necessarily any lower in quality or require more support and services than other, closed solutions. In particular situations, in particular match-ups, sure - Linux has advantages and disadvantages like anything else. (I'm not trying to start a Unix vs. Linux war here.) But the proprietary alternatives have similar advantages and disadvantages, and Linux does very well in that space.

In the "consumer app" space, probably the most successful single app is Firefox (GPL/MPL). Again, I'd question your premise that open = lower quality and requires more support. I don't think it's supported by the products we've seen so far.

While the option of a third toolkit/platform would give the Linux platform more choices, I believe that there may be "fix the economic issues" possibilities.

One possible option would be for a big company like IBM to purchase Trolltech and then redo the licensing structure to make Qt more affordable for small ISVs and remove some of the funny Trolltech restrictions (i.e. if you start developing a GPL app, you cannot then dual license this app later).

Then much as IBM did with Derby (Cloudscape), or Sun has done with various Apache bits, Qt's development could be fully open-sourced.

If Qt is recognized as being critical for the success of the Linux platform, then a Qt buyout will be looked at more closely.

Today, however, it seems that most of the big players have focused on GNOME and the various GNOME components. Even an investor in Trolltech, Borland, went in another direction vs. Qt after doing Kylix. So the probability of this option I am describing is quite unknown.

Hence your idea of developing another platform may end up as what really happens. There are probably technical issues that could be addressed as well. One thing that is good about Mono is that it provides something of a language neutral API. This may be an important feature to have in any future developments. If the big players fund a new platform (as Geronimo is being funded, say) then there will be new avenues for Linux to move forward without having to spend money on a Trolltech buyout.

And of course the GPL itself needs to keep evolving so that it is the foundation of a fair economic system and many diverse software ecologies.

One possible option would be for a big company like IBM to purchase Trolltech and then redo the licensing structure to make Qt more affordable for small ISVs and remove some of the funny Trolltech restrictions (i.e. if you start developing a GPL app, you cannot then dual license this app later).

Sounds like a great idea! But you're forgetting something. Who will maintain Qt then? IBM, if there's no profit? Or maybe the community? Well, we already have a community based toolkit, they are called GTK+, FLTK, FOX, wxWidgets, and the list goes on. For some wierd reason though, they all don't match the sheer beauty of Qt (API wise).

There's a reason why Qt is as powerful as it is today. It has a dedicated, motivated team that works on it EVERY DAY. Unless you start to pay volunteers to hack on it day after day (by which they won't be volunteers anymore, but employees) you won't see Qt develop as strong as it does today.

Okay I'm replying to myself here, that's not good...

Apparantly replying to posts when you just wake up is not a good idea. I somehow read the parent's post as "removing the propietary license and making it completely OpenSource".

Pravda in fact did not say this, so I look pretty stupid right now. Anyway, my comment were against OpenSource'ing Qt completely (I guess that's a new topic now). I hope you don't take offense, pravda

"What I think is interesting is that you can really notice how more people take an active stance against the GPL today... I guess this is also the reason why the BSDs are taking so many users from Linux... At some point the GPL community will implode and many will switch to other licenses"

Nope. The GPL community can never implode. The license prevents it. In the extreme worst case, all development halts, but the software remains free. The BSD license allows for implosion to occur, however.

I would be interested in seeing the BSD "switch" campaign show some figures. Desktop BSD is a particularly interesting phenomenon that is just getting started. Note I don't count MacOS as a BSD in this sense, since it doesn't qualify as a free software system by any stretch.

I think you're missing an important point here: the "GPL community" cannot "switch to other licenses." This would require, for example, that the Linux kernel and all of the GNU tools be scrapped for something else. Relicensing GPL software is a violation of copyright law, and the FSF would unleash their hairiest and dirtiest hippie lawyers.

People are taking a stance against the GPL in the same sense as 19th century industrialists took a stance against worker unions. The GPL is good for the common man and saps power and control from proprietary software firms (note that the GPL doesn't have any problem with commercial open source software unless it links to or derives from GPL code, and that GPL coexists with the LGPL on Linux systems).

The more I think about the Trolltech issue, the more I like what they're doing. They impose a penalty for developing commercial software as opposed to free software. It is by no means unprecedented to charge royalties for commercial use of development toolkits.

"Nope. The GPL community can never implode. The license prevents it. In the extreme worst case, all development halts, but the software remains free. The BSD license allows for implosion to occur, however. "

Er, no it doesn't. In both the BSD and GPL case what keeps them going is the easy availability of source code. Remove the Internet and I'd be willing to bet that both would suffer. Also the "lockin" argument (which you implied) only holds for the unique changes that someone adds. The original is quite whole, and available.

Relicensing GPL software is a violation of copyright law, and the FSF would unleash their hairiest and dirtiest hippie lawyers.

While I generally agree with what you wrote, this is incorrect.

Let's say I write any program -- a kernel module or a pretty pink calculator for my niece. I licence the program under the GPL.

Years go by, and along the way I get a contributor. I also get interest from a company to buy exclusive rights to the code. What can I do? Let's deal with the base facts, and from there look at options.

* The code I wrote I still own the copyright to.

* The code the contributor wrote is owned by the contributor.

* The GPL licenced code can not be relicenced to retroactively remove the GPL.

Screwed? Nope. Here are the options;

* As copyright owner of the code I wrote, I can relicence it as I feel fit.

* I can talk with my contributor and ask him to assign copyright to a fork of his code. He might even do so for free.

* I can re-write the code my contributor provided, making the program 100% mine under copyright...and then assign the code under any other licence I choose.

This depends entirely on who owns the copyright. The reason the FSF asks for copyright to be assigned to them is so that they can enforce that copyright when abused. It also means that the code will not likely be made propriatory and will remain to be under a free licence.

Yet, once GPLed, that distribution of code or binary is GPLed. Future ones, depending on the copyright holder's wishes, may not be.

Yeah right. In what universe do you live in? 3 years ago there were just as many anti-GPL zealots as today, and they were just as vocal. Heck, I dare to say that there are *less* anti-GPL zealots these days. 3 years ago, most posts on Slashdot were along the lines of "GPL is viral!", these days you see a lot less of them.

The GPL community is only "imploding" in your own little fantasy world.

TT opened up their lib, say LGPL,

Man, do you consider the Lesser GPL to be more open than the GPL itself ? You could say it's more corporate-friendly, but more OPEN ?!?! If you use the word OPEN as a synonyme of "friendly to closed-source apps", then you're doing doublespeak.

GNU Lesser General Public License, or GNU LGPL for short.

This is a free software license, but not a strong copyleft license, because it permits linking with non-free modules. It is compatible with the GNU GPL. We recommend it for special circumstances only.

Source : http://www.fsf.org/licensing/licenses/

Doublespeak? Someone's been sipping RMS's Kool-Aid.

The more you permit, the more open you are, not the other way around. The LGPL is certainly more open than the GPL -- it allows all the freedoms of the GPL and more.

Stallman has confuted this logic many times. Simply put, the freedom to remove freedom is a nonsense. Claiming that BSD or LGPL if "more free" because it gives you the freedom to remove freedom is just silly.

Stallman has confuted this logic many times. Simply put, the freedom to remove freedom is a nonsense. Claiming that BSD or LGPL if "more free" because it gives you the freedom to remove freedom is just silly.

Why can't the *creator* and *owner* of code decide to offer this code at the "freedom" level that the *owner* wants to?

The GPL *takes away* rights from the developer, creator, and inventor and gives those rights to the public. To people who have a small or zero investment in the original work.

So far as I can see, the GPL exists to fuck over the small developer as the GFL destroys the "the code is my IP" business model and replaces it with "somehow I must provide services to my customer".

This "services" model gives a positive incentive to produce low quality broken code that needs a lot of "service" to make it work.

To use a car analogy, the GPL will drive the development of lots of crappy cars that always need to go the shop for service.

What a great world that will be.

So far as I can tell, the GPL is only appropriate for "public services" type projects. It should be mandatory for all taxpayer-funded code. But it is not appropriate for private enterprise.

I'm confused. Are you suggesting some manner of nationalism? I'm sure Microsoft would like some of that.

"You don't have to pay to use the MS and Apple libraries!" I suppose in bizarro world where you don't have to pay for the Operating Systems they come on that would be true.. *You payed for the OS.* MS or Apple received money from you for their work. You may have paid them less for it than you would have paid Trolltech for Qt, but anybody who uses your program also paid MS or Apple.

The license per developer for a single platform is $3300 for the desktop. Let's compare with Apple: Mac OS X cost $129 per license. Vast difference there, aye? Though, admitably, Apple makes a bulk of their money from hardware sales. Microsoft sells Windows at retail for the professional edition at $300 retail. Even if you add MSDN membership (where there are open subscriptions so that the number of developers wouldn't change the cost - around $2,700 for the universal subscription), it is rather negliable.

Now, though Qt has many features Microsoft's Visual Studio has (which cost $2,299 per license, less if more than four, for the professional ed - still less than Qt's one platform).

Yet as I said earlier, if a business can't afford Qt, they are better off closing shop. However it doesn't mean they ought to use Qt - they may figure the opportunity cost for other toolkits is lower and decide based on that.

Hmmm, I can't see why you are saying "phenomenon" and "just getting", while FreeBSD being used as desktop for years and it is much simplier to support.

Really? Isn't it pretty obvious that he's talking about the recent proliferation of new FreeBSD-based distributions that especially focus on the needs of and cater to desktop users? Do we have to split every hair??

Yes, because charging a fee for proprietary usage of your toolkit is greedy, while expecting a company to let you freely use their assets for constructing your own proprietary software in order to make money is not.

Not to dismiss your point, as I think it is valid, it would be good to put numbers to all of this...

1) You need to buy a windows license for every developer machine

Windows XP Pro = About $300~ + shipping (boxed copy)

Substantially less if bought with hardware, though the real cost is unknown on a machine-by-machine basis by the public. To them it looks 'free'.

2) Althougth you can use a free compiler/language for windows development, most developers use proprietary and non-free IDEs and compilers like M$ Visual C++, M$ Visual Basic, Borland Delphi and son on. These softwares are not free and you have to buy one license for every developer you company has.

MS Visual C++ Pro = About $260~ + shipping.

3) Your clients will have to pay a windows license for run your proprietary application.

2x #1; About $300~, unknown but lower for OEM hardware bundles.

Total: About $860~ retail, OEM total is likely $420 ($260 VC++ retail + 2x$80 for OEM Windows XP).

The cost for QT is substantially higher;

http://www.trolltech.com/products/qt/pricing.html

4) Don't like Qt ? Use then GTK+, wxwidgets, Fox toolkit, etc. You have options for GUI development on linux.

Exactly.

One more point; Apple and Microsoft's tools, while cheaper over all, do not allow cross-platform development. They are subsidized to encourage lockin.

You use Apple's tools for OSX, you use Microsoft's tools for Windows...and this benifits both Apple's and Microsoft's platforms to the exclusion of other platforms. Porting with these tools is a real big deal.

If you want your development to benifit all systems and for you to have the flexability to sell just about anywhere, QT should be seriously considered as porting becomes much much easier and if you are careful a gimmie.

Windows XP Pro = About $300~ + shipping (boxed copy)

MS Visual C++ Pro = About $260~ + shipping.

2x #1; About $300~, unknown but lower for OEM hardware bundles.

Total: About $860~ retail, OEM total is likely $420 ($260 VC++ retail + 2x$80 for OEM Windows XP).

No actually. What you're buying into has a far, far higher cost. You're not just buying into Windows development tools, but the whole infrastructure you need to do it. Windows desktops, Windows servers, Office, Client Access Licenses, security problems..... By developing for Windows you ensure those costs stay in place. That's why Microsoft is able to pull the wool over peoples' eyes with these TCO studies.

With Qt and a desktop Linux infrastructure you're buying into something different, and you can start actually paying for stuff that makes sense.

With Qt and a desktop Linux infrastructure you're buying into something different, and you can start actually paying for stuff that makes sense.

This statement is very subjective.

The small ISV does not want to pay for libraries that should be part of Qt but are high-priced add-ons. The entire pricing structure for Qt and the never-ending support costs that run $2000/yr for two-platforms PER DEVELOPER do not make for a good feeling. The real cost structure of Qt is way beyond any company except the mega corporations.

Outside of Qt, any size ISV does not want to pay for hundreds of hours of testing on endless variations of Linux and all the infrastructure to support these variations.

Any size ISV does not want to pay to support all the hundreds of variations of Linux.

Any size ISV does not want to pay for "services" on how to use things because the developers don't write good software or provide good docs or examples so they can suck your blood for "services". This model does not scale and produces numerous "time to market" delays that may kill your business. It is just plain stupid.

Yes some few ISVs are making Linux software. But as a percentage of total ISVs the percentage probably is no more than 1%. And most of the ISVs in Linux are giant multi-national corporations.

For a small ISV or individual developer whose livelihood is the IP that is their code, Windows and Mac are the only platforms that they can make a profit. The development tools are reasonably priced and high value. There are many customers who believe in buying software. Sensible business models are there for entrepreneurs who want to create and innovate.

In the Linux world with Qt, there will never be any significant number of small ISVs or individuals developing commercial software using Qt.

The GPL destroys the ability of most individuals to make money being software developers. And the GPL edition of Qt on Windows is a pile of crap. It forces the developer to use shoddy tools (Ming etc) that simply have no place on Windows except to satisfy the religious beliefs of a few maniacs (misguided fools at best).

Without beating this horse to death, there really is no ISV opportunity on Linux for small ISVs and individuals.

The Linux platform is beginning to stumble as the vast universe of small ISVs and individual developers is what makes or breaks a platform. This force is what makes a platform come to life.

Not a small number of crappy mega corps who provide low quality software so they can soak you for services.

That GPL mega corp world is a world socialist wet dream. It is the end of individual opportunity for the software developer.

And for many people all over the world, this GPL vision is definitely not a good thing for them. There is no room for hard work and invention. History has shown us this very clearly. Just ask anyone who lived in the USSR or "Eastern bloc".

The small ISV does not want to pay for libraries that should be part of Qt but are high-priced add-ons.

What high-priced add-ons, and what do you think ISVs pay for now?

The real cost structure of Qt is way beyond any company except the mega corporations.

You haven't seen what the average ISV spends on Java app servers, Visual Studio and partners services. If you have an application that actually makes proper money, keeps a roof over your head and keeps your cashflow ticking over, it is not unreasonable at all. The days of crappy shareware and small ISVs knocking together very poor software and expecting to make a living are over.

In the Linux world with Qt, there will never be any significant number of small ISVs or individuals developing commercial software using Qt.

There are significant numbers of ISVs using Qt, not enough on Linux, but that's the way it is. The ISVs using totally free tools like GTK are non-existant, on Linux or otherwise.

Without beating this horse to death, there really is no ISV opportunity on Linux for small ISVs and individuals.

There isn't much of an ISV market around Linux right now because of the relative demand, not because of any perceived licensing issues. If there was demand most companies would do it tomorrow, but it's a chicken and egg scenario.

There is no room for hard work and invention. History has shown us this very clearly.

There certainly is. All that holds it back is demand, and certain other things which desktop Linux needs to get right like softeware installation.

I abond in your sense. Years ago, I was working in a Borland Delphi shop. The licensing cost was around the same as Qt is now, for the same kind of products. Ok, we were using what is know called the Architect version of Delphi, for a price tag of ~$6000 per seat. For the same amount of money, I can write cross platform proprietary desktop apps.

The fact is that Qt is not really expensive for an IDE of its kind, and more, for that money you get access to a bunch of helpful people, good documentation, and so on.

More : you are not required to pay the price tag each year, nor are you required to buy the license each time you have a proprietary app.

I think that Qt licensing is adequate. Really. I can write free apps, honing my skills without paying for this, and I can write as many apps as I have clients paying me to.

I abond in your sense. Years ago, I was working in a Borland Delphi shop. The licensing cost was around the same as Qt is now, for the same kind of products. Ok, we were using what is know called the Architect version of Delphi, for a price tag of ~$6000 per seat. For the same amount of money, I can write cross platform proprietary desktop apps.

The fact is that Qt is not really expensive for an IDE of its kind, and more, for that money you get access to a bunch of helpful people, good documentation, and so on.

The Architect version of Delphi is *lightyears* ahead of Qt in functionality!

And Delphi Architect is $2925, about the price of *single platform* edition of Qt.

http://www.componentsource.com/Catalog.asp?fl=&sc=CS&bc=&cv=re&ul=e...

Qt is *not* an IDE, not a visual database development environment, not a software modeling tool, not a source code control system, etc. Qt does not include the hundreds of components that Delphi does. Qt does not provide the clean Windows interfaces that Delphi does. The list goes on and on. Delphi is much more than Qt!

At best Qt is a graphics framework and cross-platform C++ library. It is *barely* an application framework by modern standards of this term. There are *zero* development tools for Qt that compare to Delphi or Visual Studio.

http://www.borland.com/us/products/delphi/index.html

Comparing Qt to Delphi Architect is like comparing a mud hut to the Parthenon.

The fact of the matter is undeniably that the commercial license of Qt is expensive. The price to own your code under Qt is a lot of money for most people.

The price of Qt is beyond the reach of the small developer. There is a version of Delphi that the small developer can afford. There is an academic version for students and education.

For all these versions, you can develop your own IP and sell it as closed source software. There is no "spit in the face of the small code developer" GPL requirement of the bogus Qt Open Source edition (that doesn't even support Visual Studio on Windows). The "free" edition of Qt on Windows forces the small developer to use fucked up tools. Now ain't that a privilege? Cruelty for free. God bless the GPL.

And that really is it. Other tools give you the ability to build great apps at a reasonable price where you can be a *software developer* where the code is your IP vs. some sort of "service provider" where you have no IP. Qt does not.

P.S. Sorry for the vulgar language. This comparison of a world-class development toolset to Qt was just too much for my delicate sensibilities to handle.

"""P.S. Sorry for the vulgar language. This comparison of a world-class development toolset to Qt was just too much for my delicate sensibilities to handle."""
You should perhaps get your fact rght before launching a full scale invasion...

Architect is actually $3,347.77 for the full license. It seams that it is in promotion these days.

From the Qt4 page : """The elegant Qt API includes a mature object model, a rich set of collection classes, and functionality for GUI programming, layout, database programming, networking, XML, internationalization, OpenGL integration and much more."""

http://www.trolltech.com/products/qt/index.html

Clearly it's more than just a GUI framework. Or I am probably under some sort of delusion and only think having written networked apps in it.

Ok, I admit freely that there is more tools into Delphi Architect that are not in Qt. But as a framwork, a cross platform framework, I think it does its job properly.

As the GPL flamewar go, I really think this is better that having a toned-down proprietary IDE like some from Borland. Anyway : i do not want to buy Visual Studio for writting free apps, it does not make sense.

"""P.S. Sorry for the vulgar language. This comparison of a world-class development toolset to Qt was just too much for my delicate sensibilities to handle."""
You should perhaps get your fact rght before launching a full scale invasion...

I just hate to see the work of all the fine people at Borland compared to something that I have used, Qt, and know is a steaming pile of crap compared to Delphi. Ooops. Vulgar language again. Rephrase. "Qt is primitive and dysfunctional compared to Delphi".

Architect is actually $3,347.77 for the full license. It seams that it is in promotion these days.

The price is still comparable to a single platform of Qt. I think you can find it for the ~$3000 price I mentioned in my link if you shop around a bit. For Qt, there is no shopping around.

From the Qt4 page : """The elegant Qt API includes a mature object model, a rich set of collection classes, and functionality for GUI programming, layout, database programming, networking, XML, internationalization, OpenGL integration and much more."""

http://www.trolltech.com/products/qt/index.html

Yes, Qt includes C++ classes for the functionality you mention. But what you get with Borland's tools is much broader and deeper. It is mature code that has been used in thousands of applications. Qt's code is not mature compared to Delphi. And a good chunk of Delphi functionality is visually integrated and has graphical tools. There is nothing like that for the Qt C++ class libraries.

Clearly it's more than just a GUI framework. Or I am probably under some sort of delusion and only think having written networked apps in it.

It is a graphics + a set of general purpose C++ classes. I have used it and written a number of apps with Qt. I am not trying to diminish it beyond what it actually is.

Ok, I admit freely that there is more tools into Delphi Architect that are not in Qt. But as a framwork, a cross platform framework, I think it does its job properly.

Agreed. Qt is a good cross-platform C++ class library. If you must do cross-platform C++, then Qt is not a bad choice provided you can afford it (commercial) or don't mind using fucked up tools on Windows (GPL version).

As the GPL flamewar go, I really think this is better that having a toned-down proprietary IDE like some from Borland. Anyway : i do not want to buy Visual Studio for writting free apps, it does not make sense

For writing any sorts of free apps on Windows, you will be far better off with the $105-$120 Visual Studio C++, C# or VB. This gives you a world class development tool that does not make you use the low quality Ming/GCC/GPL tools for Windows.

I make this recommendation if your goal as a developer is to produce good software vs. practice the GPL religion without making good software.

Ultimately it is up to each developer what is important. I am not a fan of the GPL except for taxpayer funded code that the public should own. For individual enterprise, I believe you should use the best tools to do a good job and that your IP belongs to you. If you choose to give it away, you can do so on your own terms, not some vendor's.

That earlier post was from me: didn't log in correctly.

Interesting POV. Hadn't considered shareware + GPLed software too much. Makes sense esp. irt. your intended customers and price point.

> You can develop for Windows without paying a dime, just
> use Cygwin's Win32 API or SWT or.... The Mac is
> similar.

Do you really mean Cygwin, or do you mean MinGW? If the latter, since you mention the Win32 API, then the core header and lib files provided for development of Win32 software isn't useful for testing, or actually running your software. You could include winelib, but since it isn't actually even close to fully compatible with the Win32 API yet, and since not all third-party code you might use in a Win32 program works yet, you'll still find yourself hard-pressed to develop and test your Win32 software without purchasing a licensed copy of Windows. If you really meant Cygwin, then I wish you the best of luck developing software for Windows that you expect the average Joe to pay you for. Especially considering Cygwin is licensed under the GPL, and if you want to do that you'll have to negotiate a proprietary license with Redhat.

As for MacOS X, that's an even more difficult task. GNUStep's implementation of OpenStep isn't yet complete, and OpenStep only accounts for a portion of one of the kits used for developing software on the Mac.

In both cases, attempting to avoid paying for a license of the operating system is costing you much more money than it's saving. If you're a small ISV unable to pay for Qt, then you're unable to waste money attempting to deploy against incomplete implementations of target APIs.

Then of course you miss the rest of the original point, which is that Apple and Microsoft recoup the costs of supporting developers through revenues obtained through selling licenses of their respective platforms.

Oh, and in your haste you neglected to mention the motivation for the GTK+ toolkit in the first place: Motif was a commercial library that required licensing fees to distribute along with your programs. Since the authors of the GIMP were unhappy with releasing their free software dependent on a proprietary toolkit (and the Hungry Programmers' implementation was inadequate for deploying the GIMP) they created GTK+. Motif wasn't released freely until well after it was worthless (unless you're JWZ and you think Motif is what everyone else is using), and neither Motif nor Athena are especially, well, relevant today.

And what window manager you use is completely irrelevant. You can use kwin and develop all of the proprietary software that you want.

do you mean MinGW?....provided for development of Win32 software isn't useful for testing, or actually running your software.

Why not? An API is an API, and if you need to ship with some MingGW libraries, it's no big deal. And of course, you can always use Fox/SWT/Gtk+/Tk/wxWidgets/Mono/JavaSwing/.... etc on Windows using your favourite language bindings. I agree that Motif and Athena aren't don't compare well to the other choices but they *are* no-cost options.

Apple and Microsoft recoup the costs of supporting developers through revenues obtained through selling licenses of their respective platforms.

Most PCs businesses by come with the Microsoft tax included, even if you want a "naked PC", so while it's unfair, it doesn't factor into it that much into the picture. Even if the business was able to buy a "naked PC" (we can where I live), the subsidies aren't really an issue. They chose a business model where development could be free. It's not uncommon in the industry to use money from support (Oracle), proprietary extensions (ArgoUML), or customization to subsidize development.

And what window manager you use is completely irrelevant. You can use kwin and develop all of the proprietary software that you want.

That's precisely the point. There really is no reason to try to get Trolltech to open source Qt or get KDE to move away from Qt. You have choiced besides Qt to develop and you can develop for KDE without Qt. The only reason to use Qt is because you like Qt and feel that it is worth the money. If it is not worth the money to you, then move on.

> Why not? An API is an API, and if you need to ship with
> some MingGW libraries, it's no big deal.

Because MinGW doesn't provide an implementation of the Win32 API. The provided lib files are for linking with Windows DLLs. It's just not useful by itself for testing and running the programs, because it isn't an execution environment.

> And of course, you can always use
> Fox/SWT/Gtk+/Tk/wxWidgets/Mono/JavaSwing/.... etc on
> Windows using your favourite language bindings.

I specifically only addressed those areas where there was any contention between our points of view. You can use different C++ frameworks, or eschew C++ altogether for other platforms like Java or .NET.

> Most PCs businesses by come with the Microsoft tax
> included, even if you want a "naked PC", so while
> it's unfair, it doesn't factor into it that much into
> the picture

The point is that these are not free; they're subsidized by the platform costs. Since Trolltech doesn't have the volume of sales nor the benefit of controlling these platforms, it's disingenuous to refer to development on these platforms as free while citing the cost of Trolltech's proprietary-friendly licensing fees. If you would rather have Dell give Trolltech $25 for every computer that they sell so that everyone has to subsidize your development costs with Qt, then please feel free to broker that arrangement.

> They chose a business model where development could be free.

It's about as free as the postal service.

> > They chose a business model where development could be free.
>
> It's about as free as the postal service.

In many cases it *is* free to develop for some business models. I can develop a Java/Oracle app without purchasing an Oracle license as long as I don't care about support. All I have to do is sell my app to someone who purchases an Oracle license for deployment. The subsidy money is still being paid, but not by me. Trolltech doesn't use this business model or the "shareware/ISVs authors pay nothing unless someone purchases their app" model or the "charge for support" model or the Alladin Ghostscript "street performer's protocol"-like model or the custom plugin model (of Reiser) or .... But who cares? Trolltech can choose whatever business model it wants as long as it is legal and ethical. Trolltech's business model passes both tests..

But getting back to the postal service analogy. As far as the average tax payer is concerned, they've already paid for postal service so it's what most people use because it is "free".

Companies like FedEx can't just bury their heads in the sand sand say it's unfair. They could try to lobby government to get rid of subsidized postal service, but it would more than likely be a wasted effort. If they want to have a business model that works, they need to accept reality and provide more value than typical postal service, which is what they do. If the value is worth the extra cost, you use FedEx (and FedEx is happy). If the value isn't worth the extra cost, you don't (and FedEx is sad).

Similarly, if Qt is worth the value to you, go ahead and use it and pay the fee. If not, then choose a free (or lower cost) alternative. No-one is holding your feet to the fire.

If the KDE community did decide to migrate to something like TnFox I'm sure all the helping hands could work out some of the annoyances.

Sure, and it it will take lots of helping hands. And they simply don't exist anywhere in the free software comunity. Let's just ignore the fact that TnFox is not even close to Qt in the case of functionality or quality, but for now asume they now are equal and no helping hans are needed to make them even. Then you still only need of something upwards to 50 dedicated fultime developers to ensure continious developmnet and maintainace of the toolkit, and do not forget QA and documentation. They have to be highly skilled too. Where are you suposing those developers are going to come from, when the single biggest problem in OSS are lack of manpower.

"""
Let's have quick look into a random Software Store to see how much "free" really is:

Windows XP Home Edition: € 237,-
Visual Studio .NET Pro 2003: € 930,-

This is about 1167 €.

It's not "extactly" free isn't it?
"""

First, why the hell are you including the price of a full copy of WinXP? An OEM copy of WinXP Home is less than $50 USD and is non negotiable from hardware vendors. You buy from Dell, HP, etc you cannot but a machine without Windows.

Second, VS.NET does a heck of a lot more than QTdevelop, absolutely no comparsion. You obviously have no clue. You don't even had to shell out the money for VS.NET if you don't want to, there are many free, high quality alternatives.

The .NET SDK is FREE for personal and commerical use.

"you cannot but a machine without Windows."

Ack *buy

Qt doesn't exactly compare favorably to an entire IDE. Chances are a person using Qt on Windows would be purchasing a Visual Studio license for use in conjunction with it, anyway. Not strictly necessary, but quite likely nonetheless. Also the cost of Windows licenses is variable. If you happen to have an OEM copy of Windows then the cost is considerably lower.

That doesn't negate your point, which is that the cost is nonzero. The actual individual cost doesn't matter all that much, either, since anyone that uses your software will also have to pay the platform cost. Of course the value for that cost might be much better both for your customers and yourself. Qt isn't an operating system. A Qt license doesn't permit you to run Illustrator to make a living.

If people don't like Qt's proprietary pricing, they can use something else. The sheer appearance of entitlement that comes with repeated whining about the cost to would-be shareware developers and proclamation that TrollTech should alter their business model to accomodate these developers is insufferably arrogant.

> Qt is too expensive. And this isn't just an opinion anymore.

Of course it's an opinion.

> See something wrong here? Remove the last one, and you
> can STILL develop desktop applications for this single
> platform! For $3,241.87 less!

Yes, you can remove Qt from the list and be left without a robust, multiplatform C++ framework--that should your market research deem profitable--can be leveraged on other platforms. You can enjoy working with that steaming pile of ass that is MFC, and enjoy all of the productivity that entails. Or you can always leverage the WTL, which itself is the least functional as a framework for developing software of the three. Or you can always make use of some other C++ framework. You could forego using C++ and move on to .NET with all of the pluses and minuses that entails. Or you could use Managed C++ and enjoy the clutter and performance woes that entails. Yes, you have many options available.

The question becomes whether $3k is worth more to you than whatever has motivated you to want to use Qt in the first place. Since if you don't want to use Qt, then its cost is completely inconsequential.

First, dual-license it with one of the licenses being straight GPL. That way you give the KDE people the ability to take the FSF position if they want to.

Trolltech put time effort and money into GPLing Qt. They could quite easily have thrown the towel in, said no or talked about owning the community like the head of JBoss does. They didn't do any of those things.

Anyway here is LSB's position on the problems with Qt
http://www.linuxbase.org/futures/ideas/issues/libqt/

The LSB, either deliberately or not, does not have the foggiest how Qt is licensed. On that page there are references to royalties, laughably inaccurate mailing list postings and a bizarre post about some sort of design-time restriction built into Qt. That was even after they'd had a conference call with Trolltech! I suggest they understand Qt before plucking reasons out of the air not to use it.

The LSB are a laughably immature bunch of people to be running what is supposed to be a professional organsation, but what do you expect from fanboys who argue in the playground about their licenses? The rest of the world simply passes them by and uses what they want to use. That's what happened to Unix in the 80s and 90s, no matter how many standards the fanboys came up with.

The second thing is to hire KDE people.

So it's wrong to do it then? There are over a thousand KDE developers. Only a handful are employed or sponsored by Trolltech. Guess who's going to win in any confrontation?

Did Novell employ some Gnome developers to pollute Gnome with Mono, or am I missing something in what you're inferring? Oh, and at least Trolltech actually have legitimate money to be able to hire open source developers and sponsor people. What goes around comes around ;-).

And companies like RedHat, Novell, and Sun don't want to invest in a desktop that is defacto controlled by Trolltech.

Well, I fail to see how a GPL'd piece of software (and always will be) and a desktop written with it by thousands of developers can be controlled by one company. Did I miss something? Microsoft controls Windows from top to bottom. How is Trolltech the same as that?

You can scrub Novell from your list because they use Qt exclusively in their core products, and Red Hat and Sun are where they've always been. Nothing has made any difference to Qt or KDE usage, quite the opposite in fact. The facts have become clear that you are simply a fanboy bedroom developer who creates mythical commercial software for nothing. I pity you and others to be honest. It's a very sad existance.

When KDE 4 comes around and development gathers pace on it this will all become even more irrelevant and laughable than it is now. That's really where all this GPL and Qt discussion came from, because it's perfectly possible to discuss the GPL without Qt. What about hardware manufacturers wanting to create closed-source Linux drivers? No one ever mentions that.

The fact is, the first two articles came out of fear of Qt and KDE 4 moving off over the horizon in the future and people need to dredge up some nice juicy stuff we've all heard before. I think Timothy Butler's prediction will prove to be very accurate ;-).

The LSB are a laughably immature bunch of people to be running what is supposed to be a professional organsation, but what do you expect from fanboys who argue in the playground about their licenses?

Instead of calling people names, try to understand the issues. If Qt is in the LSB, it becomes a RAND standard instead of a royalty-free, no-strings-attached standard. And they don't want to become a RAND standard. Got it? Great. Notice that this doesn't mean you can't use Qt, that KDE can't use Qt, that anything is wrong with Qt, that Qt isn't free or open source, and so on. Keep using and loving Qt all you want, it's a standard or available library on every distro, so absolutely nothing is changing. This is much ado about nothing, and your venom isn't helping.

Segedunum, sorry but the LSB and everybody else is fully aware of exactly how the Qt license works. It has "strings attached" for proprietary development and the LSB has a very clear position on that its not going to take a discriminatory position on closed source development, unlike Trolltech's position.

So you can try and wish away the issue, but it's not going to happen. In fact, the issue will only get bigger if Linux on the desktop ever moves out of the hobbyist phase.

As for the Novell situation. Yes, I understand that you absolutely hate that Novell bought Ximian and has a bunch of people working on Gnome and Mono. But why did Novell buy Ximian in the first place if Novell uses Qt in all its core products?

segedunum, its time for you post a little blog entry over at kdedevelopers.org where you and the other kde developers are in a habitual whine fest about Gnome.

Segedunum, sorry but the LSB and everybody else is fully aware of exactly how the Qt license works. It has "strings attached" for proprietary development and the LSB has a very clear position on that its not going to take a discriminatory position on closed source development, unlike Trolltech's position.

Err, not they don't - and their comments prove it conclusively. Try reading them.

In fact, the issue will only get bigger if Linux on the desktop ever moves out of the hobbyist phase.

Errr, yer! And moving out of the hobbyist phase means talking less crap, which you and others consistently don't do. People out in the world who aren't hobbyists simply don't care about the stuff you do. Your point is?

As for the Novell situation. Yes, I understand that you absolutely hate that Novell bought Ximian and has a bunch of people working on Gnome and Mono.

Yawn.

But why did Novell buy Ximian in the first place if Novell uses Qt in all its core products?

Because they're stupid. It's not unheard of.

segedunum, its time for you post a little blog entry over at kdedevelopers.org where you and the other kde developers are in a habitual whine fest about Gnome.

Yawn. You're well off the beaten track.

Err, not they don't - and their comments prove it conclusively. Try reading them.

Listen, here is the criteria

"The LSB license criteria currently states,

The component should have at least one compliant implementation
available under an Open Source license that also promotes a "No
Strings Attached" environment for developers. This means that the
developer would be able to develop and deploy their software however
they choose using at least one standard implementation. This is
interpreted to mean that at least one implementation is available
under a license that meets the Open Source Definition but it does not
prohibit propriatry usage. The rationale for this criteria is very
similar to that of the LGPL."

So Trolltech's business model and the criteria don't mesh. You don't have to like it, but that's just fact.
Granted, there was some guy from IBM who thought it was a royalty based license, but there was a march conference call where anybody that is involved should have had the licensing issues cleared up. Once again, the bottom line is that you have to pay Trolltech to write closed source apps.

Errr, yer! And moving out of the hobbyist phase means talking less crap, which you and others consistently don't do. People out in the world who aren't hobbyists simply don't care about the stuff you do. Your point is?

But once again, Sun, RedHat and Novell have made substantial investments in Gnome. So obviously some people that aren't hobbysists do care.

As for the Novell situation. Yes, I understand that you absolutely hate that Novell bought Ximian and has a bunch of people working on Gnome and Mono.

Yawn.

Translation - yes, I do hate that Novell bought Ximiam and spending money on Gnome and Mono, but I'll act like I don't care.


But why did Novell buy Ximian in the first place if Novell uses Qt in all its core products?

Because they're stupid. It's not unheard of.

First it was "yawn", now it's "because they were stupid". But of course you know more than Novell.

Well, I fail to see how a GPL'd piece of software (and always will be) and a desktop written with it by thousands of developers can be controlled by one company. Did I miss something? Microsoft controls Windows from top to bottom. How is Trolltech the same as that?

Very, very bad argument, he didn't bring up MS.

Very, very bad argument, he didn't bring up MS.

Very good argument actually. He wants to give the impression Trolltech totally controls KDE. It doesn't.

Very good argument actually. He wants to give the impression Trolltech totally controls KDE. It doesn't.

He brought up his very own brand new argument just to argue against it, very bad.

Not to mention

SWT
Vmware
Real 10
Adobe Reader
RealBasic
Flash 8 theming (Flash 7 uses GTK 1 IIRC)
Nvidia-settings
Various Game installers (Quake/Unreal Tournament/etc)
Yahoo messenger (complete POS but uses GTK1)
Moho (fantastic app, finally went and bought a copy)

Anyone that thinks QT has a relevant future in desktoplinux is delusional, plain and simple.

Always nice to see people compare two completely different things.

The reason that you buy a Qt license is to get full support. Those who think that support is free anywhere are a bit naive.



Quote:

"Not to mention

...
Adobe Reader
...

Anyone that thinks QT has a relevant future in desktoplinux is delusional, plain and simple."

So... Adobe uses GTK for one of their programs.
Do you know that they also use Qt for other programs?
Anyway, it's always nice not to mention Adobe using Qt in a more succesfull way


btw... kdelibs are lgpl !!!
No Qt tax for commercial KDE programs.

"Anyway, it's always nice not to mention Adobe using Qt in a more succesfull way "

What desktoplinux application that Adobe has created have I neglected to mention. Link?

"btw... kdelibs are lgpl !!!
No Qt tax for commercial KDE programs."

Straight from a KDE website:

You can write closed source applications for KDE - but you must aquire a Qt license from Trolltech to do so.

http://kdemyths.urbanlizard.com/viewMyth.php?mythID=59

Quote:
"What desktoplinux application that Adobe has created have I neglected to mention. Link?"

Not a linux app, but created with Qt:
http://www.adobe.com/products/photoshopalbum/main.html


And a little tip:
closed source software does not mean commercial software.

Whats your point?

Truthseeker -
"Anyone that thinks QT has a relevant future in desktoplinux is delusional, plain and simple."

"What desktoplinux application that Adobe has created have I neglected to mention. Link?"


My list were all desktoplinux applications and now your showing me one QT app Adobe developed for Windows.

People looking to develop proprietary shareware with Qt are OSS zealots how, exactly?

Its not about being technically superior. If this was about technology then yes, QT is obviously the victor.

GTK+ is superior because of:

1.) The license.

2.) Its the most desktop neutral toolkit currently in heavy usage.

3.) Avaliablity. Almost everyone has GTK+ installed not so for QT.

4.) Red Hat/Sun are the biggest vendors in the Linux/UNIX world and they both have standardized on Gnome. Gnome uses and heavily influences the development of GTK+.

This is why GTK+ is succeeding in attracting ISVs to Linux/UNIX moreso than QT.

GTK+ is good enough.

Avaliablity. Almost everyone has GTK+ installed not so for QT.

And stupid me thought that I had libraries installed because applications depend on them.

Good that I finally learn that libraries are installed for the pure chance of applications appearing that depend on them.

Interestingly the dependecy resolver of my package manager supports the first point of view.

But one thing is that I do not understand. If you do not like trolltech's licensing, why do you have bring it up, every time?

Why do people that don't like Microsoft windows comment on it? Why do people from Finland, like you, want to defend Trolltech? Why does the LSB give reasons on why QT can't be in the desktop standard?

http://www.linuxbase.org/futures/ideas/issues/libqt/

Why even comment on the thread if you don't like it? Why ask why?

Why do people that don't like Microsoft windows comment on it?

So you're simply commenting on Qt because you don't like it? Doesn't make it any more mature, does it?

Why do people from Finland, like you, want to defend Trolltech?

What's Finland got to do with it? Oh I see. You're gazing into your crystal ball and seeing a great big, white Scandinavian conspiracy ;-). Mature also.

Why even comment on the thread if you don't like it? Why ask why?

If you'd read Eric Laffoon's article at all you'd have realised this was a discussion for people who actually develop software for a living and know what it takes. You don't qualify on either count, neither does the LSB and neither do people like Timothy Butler. The world does not consist of people of people like you that worry about some of the nonsensical things you come out with. If there were we would still be using fifteen flavours of Unix and we'd still have massive standards wars whereby fanboys get involved in political bollocks to get their own pet projects accepted as standards. As desktop Linux very slowly gains traction and KDE gains more in popularity you will have a front-row seat to see that happen ;-).

So you're simply commenting on Qt because you don't like it? Doesn't make it any more mature, does it?

Try reading. I've never said that I don't like Qt, but have said that the Qt license will cause problems for KDE in the long term.

What's Finland got to do with it? Oh I see. You're gazing into your crystal ball and seeing a great big, white Scandinavian conspiracy ;-). Mature also.

And the number of germans using KDE has nothing to do with the number of developers from Germany. Try again.

If you'd read Eric Laffoon's article at all you'd have realised this was a discussion for people who actually develop software for a living and know what it takes. You don't qualify on either count, neither does the LSB and neither do people like Timothy Butler.

Once again, random KDE person is lashing out because he doesn't like to hear the truth. For the record, I've been programming on Linux professionally since 1997, so you might as well take your crybabying to your blog where you'll have a sympathetic ear with the other crybabies over kdedevelopers.org

Try reading. I've never said that I don't like Qt, but have said that the Qt license will cause problems for KDE in the long term.

I'd just like to point out that while I agree with most of what you've said in this thread, I see no reason why this has to be a problem for KDE in the long term. Multiple toolkits happily coexist on Windows and the Mac. Why can't the same be true on Linux? Only petty politics, not technical obstacles, keep us from full cross-desktop integration. Developers who insist on non-RAND libraries can just use GTK or something else, and those should be first-class apps on a KDE desktop (and the reverse). Developers who choose Qt can continue choosing Qt. Everybody's happy. The real question is, how do we get there?

Try reading. I've never said that I don't like Qt, but have said that the Qt license will cause problems for KDE in the long term.

I would try reading your own comments. That was in reply to what you wrote: Why do people that don't like Microsoft windows comment on it?. Ergo, you comment because you hate it.

And the number of germans using KDE has nothing to do with the number of developers from Germany. Try again.

Still just as meaningless.

Once again, random KDE person is lashing out because he doesn't like to hear the truth. For the record, I've been programming on Linux professionally since 1997,

Have you really?

so you might as well take your crybabying to your blog where you'll have a sympathetic ear with the other crybabies over kdedevelopers.org

Yawn. I'm afraid that doesn't justify your arguments (what were they again?) nor are they relevant to the article.

Wrong morty. The reason is very simple and logical. The qt license discriminates unlike gtk+ and LSB has taken a position that they're not going to discriminate against closed-source companies and that any library that has string attached like qt will not be in the LSB.

And you should think before you type because the GPL is all politics. Go read the FAQ.

Wrong morty. The reason is very simple and logical. The qt license discriminates unlike gtk+ and LSB has taken a position that they're not going to discriminate against closed-source companies and that any library that has string attached like qt will not be in the LSB.

Exactly. Open standards in the free and open source software world so far are *NOT* based on RAND ("reasonable and non-discriminatory") terms - remember, this is one of the things we keep harping on Microsoft about, trying to push RAND standards through standards groups like the IETF. The Open Group / LSB isn't going to accept RAND, they're going for completely royalty-free no-strings-attached -- which means they can't throw Qt in there. Period.

That's what this discussion is about. But everytime it comes up, some KDE advocates who clearly don't understand the issues turn it into a huge war and trollfest. (Not to pick on KDE, there are plenty of Gnome advocates who troll on other stupid topics.) Folks, it is what it is! Use whatever toolkit you want, under whatever terms you like. That's your choice. But please, don't bitch and moan and whine about a Gnome conspiracy everytime the licensing terms of Qt causes somebody a problem. Just because LSB has a problem, doesn't mean you have to have a problem - nor does it mean that LSB is wrong (I happen to think they are 100% correct, and any other position would be hypocritical and represent a huge break in open standards goals). Use Qt in your GPL or commercial development to your heart's content, nobody is stopping you!

People bitch and moan because they still believe this is a winner-take-all proposition. It isn't. Let standards groups bless an LGPL toolkit. Let desktop projects choose whichever toolkit they wish, LGPL or GPL or otherwise. Let application authors choose what they wish. What we need are baseline technologies and integration so that it just doesn't matter to the end user what toolkit you use, because frankly they don't give a damn anyway. GTK+ apps should be first-class apps on a KDE desktop, and KDE or Qt apps should be first-class apps on a Gnome desktop. Put the politics and whining aside, use what you like, and let's move forward with real technical solutions to technical problems.

The Open Group / LSB isn't going to accept RAND, they're going for completely royalty-free no-strings-attached -- which means they can't throw Qt in there. Period.

When you've actually read about how Qt is actually licensed come back and give us a call, OK sonny? Regurgitating totally inaccurate and luaghably imature stuff from the LSB web site doesn't qualify.

Quite what Qt has got to do with RAND is anybody's guess.

Quite what Qt has got to do with RAND is anybody's guess.

It's really sad to see somebody with so much venom who has absolutely no idea what they're talking about. Here's what Qt has to do with RAND: it is offered under RAND terms! Whereas the rest of the LSB is offered under royalty-free, no-strings-attached terms. Once again, this doesn't mean there is anything wrong with Qt, but it absolutely means that any standard it is a part of must be a RAND standard. LSB doesn't want to be RAND. Can it be any clearer? Please save your venom and indignation for topics you actually understand.

It's really sad to see somebody with so much venom who has absolutely no idea what they're talking about.

Ha, ha, ha! Venom. *sarcasm mode* I really appreciate you being the bigger person here */sarcasm mode*.

Here's what Qt has to do with RAND: it is offered under RAND terms!

Where?

I suggest you go back and read how Qt is licensed. How Qt is licensed is in no way an impediment to Qt being in the LSB, nor is it an impediment to third-party developers in the way the LSB talks about.

The fact is the LSB wants the goalposts positioned so that Qt doesn't get in, and quite frankly, it doesn't matter.

but it absolutely means that any standard it is a part of must be a RAND standard.

No it doesn't because it isn't. Try explaining this in plain English.

LSB doesn't want to be RAND. Can it be any clearer? Please save your venom and indignation for topics you actually understand.

When you learn that the rear orifice is not for talking with, I might.

The fact is the LSB wants the goalposts positioned so that Qt doesn't get in, and quite frankly, it doesn't matter.


You better explain that statement, unless you want people thinking that you have paranoid, conspiracy theories.

You better explain that statement, unless you want people thinking that you have paranoid, conspiracy theories.

I'd better had I? Ooooh. No, I don't think I will actually because you can get all the info you need from the LSB's libQt page and the mailing list postings they link to ;-).

Put politely, from what is supposed to be a professional body it's inaccurate crap. I wouldn't expect it from a professional engineering, or other industrial, bodies who formulate standards for their respective industries and I don't expect it from software - open source or otherwise. Notice the word professional.

It doesn't matter because people have been trying since the dawn of time to get their pet stuff accepted as standards. Standards only work when politics doesn't get in the way. It happened in the Unix world, and look where it got them. I doubt whether Microsoft or anyone else is bothered that their software isn't accredited by a standards body.

I suggest you go back and read how Qt is licensed. How Qt is licensed is in no way an impediment to Qt being in the LSB, nor is it an impediment to third-party developers in the way the LSB talks about.

Your argument isn't with me, it's with the dictionary. If you refuse to understand what RAND means, there is nothing I can do about that. LSB is not using some magical definition of RAND here. They're using the same definition as everybody else, and Qt meets it. I don't think anybody from Trolltech would even argue this issue, it's really not an opinion but a fact. And it has nothing to do with whether Qt is any good or not, or whether it's open source, or any of that.

No it doesn't because it isn't. Try explaining this in plain English.

Is this your way, 100 posts into the thread and after post after post of name-calling and spewing venom, of admitting that you don't understand what RAND means?

Here it is, in plain english: If you want to use Qt in your proprietary application, you have to pay Trolltech. Nothing wrong with that, but that is a "string attached" and therefore Qt can't be included in a royalty free, no strings attached standard. It instead has to move up the level of RAND, reasonable and non-discriminatory terms - Trolltech does have a string attached for some uses (proprietary development), but it's the same string attached for all comers, so it meets the RAND-level for standards. Many standards are RAND, but LSB is not, so Qt can't go in - neither can MySQL, neither can BerkeleyDB, and so on. Doesn't mean these won't be de facto standards, but they can't be part of a non-RAND formal standard. Not just LSB, but any non-RAND standard made by any standards organization following the same understanding of RAND that has been in use for decades around the world.

The fact is the LSB wants the goalposts positioned so that Qt doesn't get in, and quite frankly, it doesn't matter.

Unlike the definition of RAND, your conspiracy theory about the LSB is most certainly not a fact.

Since you're unable to argue coherently - instead of arguing about things that are arguable, you're disputing facts, and doing so with anger and name-calling to boot - I'm going to do you a big favor and take the devil's advocate position. How about an argument that goes something like this?

<devil's advocate>

"Yes, of course Qt is RAND, only a fool would dispute a simple and obvious fact such as that. I might as well argue with the dictionary! Ha ha. But why does LSB have to be non-RAND? Why can't they make an exception for Qt? Qt is already a de facto standard, included as a standard library or available for every distro, and Linux users and developers around the world already depend upon it. If somebody really must have a non-RAND toolkit, they can use GTK or something else. But LSB should still include Qt, perhaps with a statement something like: 'although Qt is RAND, we are making an exception and including it in the LSB because it is a pre-existing de facto standard. For those who require a non-RAND library for the same purpose, equivalent non-RAND libraries are included in the LSB. Note that Qt is completely royalty free for usage in GPL or compatible applications.' How about that? And if it can't be in the LSB proper, maybe as an appendix that recognizes the reality out there - that Qt is already a de facto standard in the Linux world, and free software should be able to count on its inclusion? Would that solve our problem?"

</devil's advocate>

Now, if you made a coherent argument like that, we might have something of substance to argue about, rather than over the accepted definition of terms used by standards groups around the world. You might be right, you might be wrong, but at least you'd have a coherent argument that made sense instead of spewing hate and banging your head against the wall, convinced that the whole world is against you for no good reason.

The well-known kernel hacker Theodore Ts'o has already commented on give Qt an exception.

http://freestandards.org/pipermail/lsb-futures/2002-November/000668...

Your argument isn't with me, it's with the dictionary.

RAND isn't in the dictionary.

If you refuse to understand what RAND means, there is nothing I can do about that.

Where's the RAND clauses in Qt? Qt does not need to be released under RAND terms, and it isn't. You're off into the trees here, as well as the LSB:

http://en.wikipedia.org/wiki/Reasonable_and_Non_Discriminatory_Lice...

It has absolutely bugger all to do with Qt. Zilch.

Now, if you made a coherent argument like that, we might have something of substance to argue about, rather than over the accepted definition of terms used by standards groups around the world.

Because what you're argument and your facts are total tosh - crystal clear.

Is this your way, 100 posts into the thread and after post after post of name-calling and spewing venom, of admitting that you don't understand what RAND means?

*sarcasm mode* Once again, I appreciate you coming out and being the bigger person here */sarcasm mode*. You're still so wrong it beggers belief though.

Here it is, in plain english: If you want to use Qt in your proprietary application, you have to pay Trolltech. Nothing wrong with that, but that is a "string attached" and therefore Qt can't be included in a royalty free

Qt is royalty free, always has been, aways will be. This word royalty crops up on every single posting on LSB's mailing list. It is totally inaccurate in every possible - OK?

Until this royalty word disappears your arguments, whatever they are, are null and void. And with unbelievably ludicrous comments like this flying around:

http://freestandards.org/pipermail/lsb-futures/2005-March/001489.ht...

The libqt case is an interesting one in that non-GPL developers are allowed to deploy applications that use the dual licensed Qt Commercial License/GPL runtime libraries without restriction and the restriction is actually at development time, if you want to develop non-GPL applications then you need to buy a development license. I don't know how this license works, if it's restricting access to headers or development tools or what. Maybe the Trolltech people can explain.

The first sentence in there actually qualifies Qt. You can simply forget having any kind of watertight argument if that is the kind of wishy-washy understanding they have. It leaks like a seive. And that comment above was in March of this year.

Then there is paragraph below that:

Given that the restriction is a development time, is the existance of the LSB header files and stub libraries enough to fulfil motivation #2 above? These headers would at least need to be under a license that meets the LSB license criteria in order to do so. Someone on the call pointed out that since this is a c++ library we can't yet fully generate headers because parts of the headers contain inline code......

Which is simply a reason not to do it. There are no license restrictions on simply scanning a bunch of source files.

Since you're unable to argue coherently - instead of arguing about things that are arguable, you're disputing facts, and doing so with anger and name-calling to boot - I'm going to do you a big favor and take the devil's advocate position. How about an argument that goes something like this?

Once again, I appreciate you being the bigger person here and I think everyone can see that ;-).

But since Qt in fact have a no-strings-attached license everything you say are just nonsens,

When people that write closed-source apps can use the Qt license without paying a per developer, per OS license then Qt will have no strings attached. Until then, it has strings attached.


Just lying about the issue won't help your cause. Even most KDE developers/fanboys would admit that there are strings attached to the Qt license.

But since Qt in fact have a no-strings-attached license everything you say are just nonsens, making all your arguments void.

Saying it doesn't make it true. Make a proprietary app on top of Qt and you have to pay Trolltech, as you know. THERE IS NOTHING WRONG WITH THIS (I hate to shout, but you seem to have trouble hearing). That's a great business model for them; similar dual-licensing strategies work well for MySQL and others... but it's a "string attached." That isn't nonsense, my argument isn't void - it's a fact. This is a problem for standards organizations and wishing it away won't change that, but there should be no reason why this is a problem for you, for open source developers, for commercial developers who like Qt, or for KDE. Keep using what you like, who is stopping you?

Including Qt in the LSB does not make the LSB RAND.

Yes it does, by definition. If you disagree then your disagreement is with the definition of RAND, not with me. Same with with your buddy seg. You are making a very silly argument. Argue that it shouldn't matter, not that black is white and white is black. (I can't believe that the level of discourse on OSNews has actually fallen this low.)

Since Qt can't make the LSB RAND your argument are void.

See above. It would.

Including it will actually make the LSB relevant for the desktop, with a no cost libraries(GTK+ and GPL Qt) and support for the majority of Linux desktops.

Ah, now there's a reasonable argument. I don't necessarily agree, but at least you're making sense now.

Elsewhere, did you even read the article?

The guy that wrote the article was taking the FSF position regarding the GPL. So basically, he has to change his position if Trolltech ever gets bought out and the license is liberalized.

I wasn't really responding to the article, just all the posts stating that nobody should or will use qt because of the price, or comparing it in dollar terms to windows / visual studio (?) etc. Just pointing out that price is less important that cost in most situations and businesses (ie. commercial software vendors) often use different and varied criteria for making their decisions.

The rest was just a personal rant about why this discussion keeps coming up as if people are being forced to make a concrete choice one way or the other.

" A desktop that is like windows reduces training overhead."

I seem to remember a test awhile back were this supposition was examined. If memory serves, they concluded that the similarities were a hinderence for the Windows users because they were expecting one thing, and getting something "slightly" different. While the differences that Gnome presented didn't throw the group as much because it didn't create a particular expectation that couldn't be met.

I like your thinking, but do not underestimate the work it would take to move KDE from Qt to anything else.

As the core KDE people are also Trolltech people, it would make a great movie if a fork of KDE to something else took place. Talk about reality TV drama for geeks!

Ultimately I also believe a third option will emerge that is not Qt and not GTK as it exists today. It maybe based on some of the higher level UI stuff that is in development now.

How about a third Linux desktop that will be essentially a KDE fork but based on wxWidgets/GTK rather than QT as the C++ framework.

No, because it would be an unbelievable amount of work to do that (and totally unrealistic), and KDE based on Qt would simply still motor off into the distance.

Plus, wxWidgets, to be quite frank, is shite. It's great for general development, but on any sort of large project (desktop environment definitely included and anything seriously commercial) I wouldn't even want to contemplate it. It offers not even a fraction of the productivity benefits of Qt, because Qt is of course not just a GUI tookit. And I don't want to spend all of my time overriding virtual methods, and of course, there's no decent IDE tools to handle all of that complexity.

Boss: You know what, nobody uses Linux on the desktop anyway, let's just write our software for Windows and MacOSX...

Unfortunately for Linux the boss is right. Not exactly as stated above, but still the boss is right.

Native tools are much better than Qt and it is probably cheaper to build two native versions, one for Windows and one for Mac, vs. a cross-platform version using Qt.

By using native tools, the applications will have 100% of the look and feel of a native app and integrate with other apps and the OS better.

You have a chance to make a great Mac app and a great Windows app. This is not something that can be done with Qt.

The boss also knows that it is very hard to get people to pay for Linux software. And the costs of testing and supporting Linux software are very high.

So the boss puts the company in position to make a profit if you are a software company and not a services company. Namely, building software for Mac and Windows.

Somehow this is not a surprise.

By using native tools, the applications will have 100% of the look and feel of a native app and integrate with other apps and the OS better.

Most tier 1 commercial off the shelf apps don't integrate deeply with OS or desktop environments they run on. Photoshop, Adobe Premier, Quark, Dreamweaver, Quicken (especially Quicken), etc, etc... are all largely islands unto themselves. These are the type of proprietary applications which Linux most needs, not the "shell enhancement" stuff which integrates deeply with the environment.

The other category of proprietary software Linux really, really needs far more of is the vertical apps. If I were a betting man, I'd wager that in the medium-to-longterm Gtk# on mono/.net/portable.net becomes the most popular choice for vertical vendors looking to target multiple platforms.

Most tier 1 commercial off the shelf apps don't integrate deeply with OS or desktop environments they run on. Photoshop, Adobe Premier, Quark, Dreamweaver, Quicken (especially Quicken), etc, etc... are all largely islands unto themselves. These are the type of proprietary applications which Linux most needs, not the "shell enhancement" stuff which integrates deeply with the environment.

I beg to differ. Most of the apps you mention have deep OS-level awareness of the file system, for example. They use OS-specific mechanisms to control application instancing. They use a lot of code that is particular to the OS -- the details of web, ftp, urls, etc. They integrate with the Windows shell. They support Windows drag and drop. The list goes on and on. All "Tier 1" Windows apps are close to the OS. The *data* that these apps work with may be islands. The way the app works with this data *within itself* may be particular to the app. Of course that makes sense. But the app itself is written to Windows.

Yes, Adobe has some pieces of cross-platform code but the big cross-platform engines they used to love have been slimmed down a lot. It just didn't work.

Another example -- look at many popular Windows apps and you will find all sorts of COM interfaces. That is deep Windows integration.

The other category of proprietary software Linux really, really needs far more of is the vertical apps. If I were a betting man, I'd wager that in the medium-to-longterm Gtk# on mono/.net/portable.net becomes the most popular choice for vertical vendors looking to target multiple platforms.

I wouldn't bet against you here. Mono is very close to being a full development stack and if it grows up well will become a force in the app development world. Lots of great development tools, lots of components, and flexible licensing. Sounds like a winner as long as Microsoft's lawyers don't launch the missiles.

Lots of great development tools, lots of components, and flexible licensing.

Lots of great development tools and components for what? I wasn't aware Mono had a great IDE. Be aware that Mono is not .Net, and that will become even more apparent in the not to distant future.

Lots of great development tools and components for what? I wasn't aware Mono had a great IDE. Be aware that Mono is not .Net, and that will become even more apparent in the not to distant future.

On Windows, you can use almost any .NET development tool with Mono. And there is the Mono version of SharpDevelop. There are many editors/IDE's that have C# support.

I moved over a .NET C# console app with very little effort to Mono. I have to say that I was impressed.

For components, a lot of .NET code that doesn't require WinForms works with Mono.

The .NET design provides for mostly language-neutral API bindings. This is a big advantage over any other existing system. I see no reason why Mono cannot support multiple application-level UI systems. It will give apps developers a lot of flexibility while maintaining compatibility with all their .NET architecture code written in all the .NET/Mono compatible languages.

On the cost side, without the kick-you-in-the-balls Qt commercial license entry fee, Mono will enable development efforts to grow from small seeds.

All it will take is a robust implementation of something like WinForms on Mono and then the landscape will be changed. That one development will enable lots of components to be moved to and built for Linux.

It will enable a components market. And the components market will enable a higher level of apps which are made from those components. It will be the first components market on Linux. That may be a huge differentiator vs. Qt which has an extremely small and sparse third-party marketplace.

As long as the missiles don't get launched, Mono has a lot of room to grow.

Mono/CLR is a much stronger architecture than a proprietary C++ preprocessor and the complexities and interface issues of C++. As long as the Microsoft stigma can be overcome, there is a lot of promise.

On Windows, you can use almost any .NET development tool with Mono.

.Net is not Mono, and that assumes there will be a 1:1 mapping between Mono and .Net now and in the future. Not going to happen, and it isn't right now.

And there is the Mono version of SharpDevelop.

It's crap. SharpDevelop itself is well ahead, and there isn't likely to be any code sharing or reuse in the future.

On the cost side, without the kick-you-in-the-balls Qt commercial license entry fee

Well I'm going to have to pay for Visual Studio to develop for Mono....

And the components market will enable a higher level of apps which are made from those components. All it will take is a robust implementation of something like WinForms on Mono and then the landscape will be changed.

That assumes that .Net will be 1:1 with Mono now and in the future. It isn't and it won't, and it also depends on Microsoft's good will to do that

There is already a components market for Linux. It's called Java, but all of the people using it are not arguing on forums.

Mono/CLR is a much stronger architecture than a proprietary C++ preprocessor

Qt isn't proprietary.

and the complexities and interface issues of C++.

With a good toolkit, those issues disappear.

.Net is not Mono, and that assumes there will be a 1:1 mapping between Mono and .Net now and in the future. Not going to happen, and it isn't right now.

It is not perfect portability between the two. But it is at least as good as moving between systems using Qt.

And there is the Mono version of SharpDevelop.

It's crap. SharpDevelop itself is well ahead, and there isn't likely to be any code sharing or reuse in the future.

Give it time. It's coming along pretty well given how long Mono has been around.

On the cost side, without the kick-you-in-the-balls Qt commercial license entry fee

Well I'm going to have to pay for Visual Studio to develop for Mono....

Say $100 for Visual Studio C#. That gives you the ability to write commercial apps for a tiny fraction of the Qt license fee.

No matter how you slice it, Windows development tools offer much higher value for your money and all have lower price points than Qt.

And the components market will enable a higher level of apps which are made from those components. All it will take is a robust implementation of something like WinForms on Mono and then the landscape will be changed.

That assumes that .Net will be 1:1 with Mono now and in the future. It isn't and it won't, and it also depends on Microsoft's good will to do that

A component market could develop even if there was only MonoForms.

There is already a components market for Linux. It's called Java, but all of the people using it are not arguing on forums.

That is a good point. Maybe because out of the server room, there is insignificant Java usage?

Mono/CLR is a much stronger architecture than a proprietary C++ preprocessor

Qt isn't proprietary.

MOC is Trolltech's IP. It is used by no other company. I believe that is proprietary.

and the complexities and interface issues of C++.

With a good toolkit, those issues disappear.

There has never been such a "good toolkit" in the history of C++. The language itself is too complex. You will not win too many arguments saying C++ is simple.

Boss: We usually pay for our development tools and IDEs anyway. It's a bonus that it's all free, but we need to get some work done. Is there no nice IDE and development tools that we can buy to cut out some of the unecessary steps?
Programmer: No.

No joke. I've worked with a small company of three people (the type of company who everybody thinks develops for nothing) who was looking to get started on .Net development (their choice). They didn't have a product or any real revenue from .Net development to speak of, so I suggested they use something like SharpDevelop to get started, get up to speed and get some real income and then they could buy Visual Studio and possibly MSDN subscriptions. You know what? They bought MSDN subscriptions anyway.

It's an absolute no brainer for a company, even when it's totally unecessary to spend lots of money on development tools they do anyway. This develop for nothing philosophy people have is total crap. Yes, having LGPL'd etc. tools that allows you to do lots of additional development and give you flexibility that can be vital in some cases is important (and there are many great tools and bits of software around), but no one can develop everything for nothing.

So the future for Linux is two GNOME desktops? The one build on Mono and gtk# from Novell. And the other one based on Java and gtk/Java from RedHat/Sun? That is certainly perfect for ISV/IHVs...

I don't know what the future is for the Linux desktop itself. The functionality and form questions that should drive the desktop are larger than what language/tools are used to implement the desktop.

For application development, I think Mono has a promising future, perhaps the most promising future of anything on Linux. With the usual Microsoft IP caveats.

And if Mono is so great, why doesn't RedHat touch it with a ten foot pole?

Probably due to those missiles I mentioned. At any time, Microsoft can launch massive WMD on whomever they want. WMD = Weapons of Mono Destruction. As Red Hat doesn't do much in the apps space (who does for Linux? almost no one), Red Hat doesn't feel the need to take the risk.

No, "royalty" is quite appropriate:
http://en.wikipedia.org/wiki/Royalties

Hell, you're citing wikipedia and that's even a stub.

Let's see what merriam-webster.com has to say about royalties:
5 a : a share of the product or profit reserved by the grantor especially of an oil or mining lease b : a payment to an author or composer for each copy of a work sold or to an inventor for each item sold under a patent

thefreedictionary.com:
8.
a. A share paid to a writer or composer out of the proceeds resulting from the sale or performance of his or her work.
b. A share in the proceeds paid to an inventor or a proprietor for the right to use his or her invention or services.

askoxford.com:
3 a sum paid for the use of a patent or to an author or composer for each copy of a work sold or for each public performance.

Note that according to all these definitions the defining point of royalties is that you pay for each copy sold. Qt is royalty-free. It's not free as in beer but the developer licenses of Qt are not royalties. Period.

Ooops, forgot cambridge.org:
royalty [Show phonetics]
noun [C usually plural]
a payment made to writers, people who have invented things, owners of property, etc. every time their books, devices, land, etc. are bought or used by others

It's pretty clear what he means by that. Imagine the situation if you had to pay for Qt, xorg, the kernel, kdelibs, etc.

In a cold hard and objective way, that would really depend on whether the software was actually good enough. Is GCC good enough? Probably. Is xorg good enough? Probably. Even those bits of low-level software need continued investment and more resources. They don't just run themselves. Is GTK, or any of the other development tools around it, good enough for Turbotax, Quicken etc.? No it most certainly isn't, and those companies are going to totally reject desktop Linux on the basis of the very tools the LSB wants them to use. You're simply going to get laughed out of town.

I think the LSB should go out and ask these companies what they want first, as opposed to just making assumptions about what they're going to use. I don't see anyone actually talking to these companies and asking them even though they make such a song and dance about them developing mythical, non-existant software for Linux. Making things a standard isn't going to help them.

If none of that software was actually good enough then the LSB would have to organise some sort of payments collection system to make it easy for people or try to make people use standard software they're never going to use, so they'll use Windows instead. That happened with Unix in the 80s and 90s and it's repeating itself.

That's why the LSB has its "no strings attached" policy.

Depends how 'no strings attached' is defined.

The point was to troll. Despite that the overwhelming majority of the software available on the Linux desktop is not from Adobe/Macromedia, their choices are of course indicative of the future of the nascent Linux desktop. There's all of that proprietary software available using SWT to think of, after all. Or is Java dead on the desktop? Well I guess that depends on what mood the usual parties are in today.

What people are missing here is that commercial usage (or closed source usage) of QT is held hostage by Trolltech.

There is nothing stopping them from increasing the price or demanding royalties or indeed making any unreasonable demands whatsoever. In other words they have the power to screw you and your business up and you are powerless to stop them.

What if Trolltech was bought out by SCO or Micrososft - you would have to pay whatever price the Trolls demand. Thats why its essential to have the libs as LGPL or BSD or equivalent. If KDE is serious about widescale adoption it must address this