Between "closed source software" and "open source software" there is "internal software". That software may become open source eventually, or it may just disappear quietly.
Internal software is a crucial part of open source software, because much of it will eventually become open source. My company has released probably a dozen software packages as open source that started out as internal software (some of it very widely used).
But if you try to force internal software to be open from the start by placing a QPL-style license on your platform's libraries, many people will simply use a different platform.
Maybe you are too young to remember, but we had roughly that situation with Motif and Solaris. People would write lots of software for those platforms, in particular at universities, where they were essentially free, but anybody else needed to pay Sun and OSF a lot of money to use them.
In any case, I don't suggest that there are "license problems": I think it's pretty clear what Troll Tech's intent is, and I don't want them to change it. What I'm suggesting is that if QPL'ed software becomes the basis for a standard Linux desktop, that will be a problem for Linux, and that's why people should develop for something else.
What this does is allow you to write the software under the GPL and use it internally. However if you write it as such and someone in your organization wishes to distribute it, they can. Just like if you use GPL-derived software, regardless of what point 11 says. The trolls themselves have said that this is true. So what is the problem?
You can place your own software under the GPL, but the QPL terms still apply, in addition to whatever terms you put in it yourself.
It is plain wrong to claim that internally written GPL'ed software is subject to such requirements. This is a direct consequence of the QPL. Troll Tech's claims to the contrary are wrong and misleading.
Re:"standard desktop"--you missed the point
on
Happy Birthday, KDE
·
· Score: 2
Well, in my posting, I suggested people develop for a different toolkit, not that they don't use KDE.
Still, I have mixed feelings about even using KDE. Yes, you are right that you can use KDE and develop using another toolkit. But non-KDE/Qt applications won't integrate as well with KDE as KDE/Qt applications will, so the more people use KDE, the more pressure there will be to develop for it. And the more people use KDE, the more bug reports and suggestions for improvement get submitted to Troll Tech, quality control that other toolkits miss out on.
Besides, installing multiple desktop and toolkit systems increases support and training costs and uses up more resources (disk space, memory, etc.).
I would buy the "use KDE and develop for something else" argument more if KDE was committed to a seamless integration with GTK and other toolkits. But recent statements suggest that they aren't, at least in the short term.
$1500 is peanuts for any company doing internal development in C++.
Well, both in my work as an independent consultant and in the corporate world, wherever I have worked, $1500 for a library has always been a lot of money. But I will admit that there are companies for which money is no object (defense contractors in the past,.com startups these days, I suppose).
But even if $1500 is a problem, what makes you think that commercial or non-commercial alternative toolkits can't compete with QT? It's not that they own some interface or other standard (like Microsoft).
Nothing makes me think that "they can't compete" technically. In fact, I think there are better toolkits than Qt. But the fact is that lots of people develop for KDE/Qt, and that's why I think it's worth pointing out to people who do that there are problems with the Qt license and that that is one of the many reasons they should look at other toolkits.
11.Using the Free Edition, can I write software for internal use in my company/organization?
The Qt Free Edition is not intended for such use; it is our policy that when you are using Qt for free, you should in return contribute to the free software community. If you cannot do that, you must get Professional Edition licenses instead.
The QPL is far closer to the intent of the GPL than the LGPL, which is what I'm assuming you are advocating. All free software library authors should be concerned with is allowing people to write free software.
I'm concerned with not being forced to release software that I develop internally. That is clearly the intent of Troll Tech, and it clearly goes against the goals of the GPL and the LGPL. Here is a recent quote from RMS on the Plan 9 license:
[Plan 9 License:] You agree to provide the Original Contributor, at its request, with a copy of the complete Source Code version, Object Code version and related documentation for Modifications created or contributed to by You if used for any purpose.
[Stallman:] This prohibits modifications for private use, denying the users a basic right
As for "advocating" or "disguising", I'm doing neither. I'm merely stating my opinion that if Qt becomes the basis for the predominant Linux desktop, that will be very disadvantageous for the adoption of Linux as a whole, contrary to the stated goals of the KDE project.
KDE is as close to a standard desktop as exists in the Linux world.
I agree, and I think that should be reason for concern. Why? Because it means that any development for Linux for this "standard desktop" inside a corporation, even just for internal use, requires and expensive, commercial Qt license.
If people inside corporations had had to pay $1500/developer to get Linux in the door for trying it out on internal development efforts on it, it would have never caught on as a server platform.
And because the GUI toolkit and desktop is the most important part of a client, desktop OS, having that kind of fee structure for the "standard" GUI toolkit would harm Linux as a client platform.
So far, there are still viable alternatives to KDE/Qt. But every time a free software developer decides to develop a new piece of software for KDE/Qt rather than Gnome or some other free toolkit, KDE/Qt gets the bug fixes, functionality, and increase in user community. There is a high opportunity cost with choosing KDE/Qt for the other toolkits. Those are the network effects that got MS Windows where it is today.
Let's not make the same mistake with Linux that the industry made with Windows. Develop for free platforms, even if the alternatives seem more expedient to you in the short term.
We have come a long way since the Xerox GUI Concept.
Xerox didn't just have "concepts", they delivered a series of fully functional, easy to use office machines, as well as a series of languages and environments for building GUI applications.
I find that even the best GUI libraries of today are much harder to program and and arguably harder to use than what Xerox delivered 20 years ago.
So, do you care to elaborate in what way you think we have "come a long way"?
Yes, Kylix will bring lots of Windows programmers and Windows programs to Linux. Many of the programs will be proprietary, some will be free. So, why exactly is this good?
Most mainstream, Windows programs are written in VC++, so it's not like that this will bring the few crucial apps to Linux that Linux needs for mainstream acceptance (mostly Office).
OTOH, it will keep Windows programmers from learning how Linux development and programming works. They'll develop in the same style that they developed on Windows, and they'll produce the same kind of software that they produce on Windows. That kind of software is one of the main reasons I don't use Windows, and one of the main reasons other people have fled Windows as well.
I did read the KDE Free Qt Foundation documents, and I think nothing that I said contradicts anything you said. And I don't find the document reassuring.
In any case, this discussion has gone off track. I responded to a posting by someone who claimed that (I'm paraphrasing) "Troll Tech could take back Qt at any time, so we shouldn't annoy them". I don't see how anybody who has that kind of belief can advocate building a large free software infrastructure on such software.
We can argue whether that belief is justified. I think it is partially justified, given the license and the loopholes. You may disagree. That's life.
Printing is actually a surprisingly difficult problem: it involves something that amounts to executable content, authentication, accounting, downloading of drivers, envelopes/covers, transferring large amounts of data, collating, device configuration, content negotiation, security, DoS attacks, and other issues.
The UNIX lpr protocol avoided dealing with most of those issues and assumes the whole world is PostScript or ASCII and having minimal security. And Windows now has a proprietary solution for installing drivers and other issues.
I hope IPP won't go overboard. Many of the issues I mentioned, I think, are best left unaddressed, because if the printing protocol makes it too easy to create a proliferation of configurations and printer drivers, people will do just that. But something a bit more featureful based on HTTP I think would definitely be a step forward.
From the press release, it's hard to tell what you pay the $2000 for. Is it for support? Or is there some proprietary component? If the latter is the case, why does the press release talk about "open source momentum"?
I think we need more information to see whether this signals a lessening of RedHat's commitment to an open source corporate strategy, or whether they are executing the "traditional" open source strategy of selling support and configuration, or whether this is something yet different. It's definitely something to be looked at carefully, but I wouldn't get overly concerned until more facts are in.
Look at the composition of the "KDE Free Qt Foundation": two Troll Tech employees and "two members of the KDE project". Even if the "two members of the KDE project" were completely independent, that would at best produce a tie. And there is no guarantee that they aren't also Troll Tech employees or consultants, or that they have the interests of open source in mind.
Furthermore, destroying Qt is easy without ever triggering the "KDE Free Qt Project": stop the commercial support, and do half-hearted development. Then, KDE/Qt would be a toolkit with one of the most restrictive "open source" licenses in existence, completely unsuitable even for commercial users that have the money to pay. Hundreds of commercial developers would be left stranded and would have to port their code to other GUI toolkits.
I think it's completely naive to believe that the QPL and "KDE Free Qt Foundation" protect anything. And I cannot help but think that Troll Tech is disingenuous rather then incompetent when they put together this string of legally flawed licenses and agreements.
Notions of "more free" or "less free" don't matter much to me. I don't object to Troll Tech's license on philosophical grounds. I think Troll Tech can license their software whatever way they want. Neither to I take what RMS says as gospel truth. Nor did I even suggest Gnome as an alternative AFAIK.
The "standard" GUI toolkit for an open source OS is of fundamental importance; it is unlike almost any other library. If the GUI toolkit license isn't acceptable to a lot of potential users and supporters, the platform isn't acceptable to a lot of potential users and supporters.
And what it comes down to is that, IMO, the LGPL is fine for an open source GUI toolkit. The GPL is marginal (it at least allows internal use), and the QPL is not.
As for Gnome/GTK specifically, as far as I can tell, the GTK is fully under LGPL. That's good. Gnome is partially under GPL. That's not so good. If parts that are essential for writing good GUI apps and/or interoperating are under GPL (rather than LGPL), I think Gnome is also unsuitable to fill the role of predominant GUI platform on Linux (although I think a GPL'ed toolkit is still preferable to Qt Free Edition).
But, more generally, I question whether there should be a predominant GUI platform on Linux, rather than an interoperable diversity. "KDE and Qt everywhere" is just as harmful to me as "Windows everywhere". The whole "KDE vs. Gnome" thing is like "Windows vs. MacOS". If people work more on interoperability instead of pushing a particular platform, then all these issues about one toolkit vs. another become much less important. And, who knows, with interoperability standards, the Linux desktop might even progress beyond being a Windows/MacOS clone, as people who have new ideas can incrementally move towards a new paradigm.
11.
Using the Free Edition, can I write software for internal use in my company/organization?
The Qt Free Edition is not intended for such use; it is our policy that when you are using Qt for free, you should in return contribute to the free software community. If you cannot do that, you must get Professional Edition licenses instead.
In my experience, most uses of free software start off as "internal" development, with some of the projects eventually becoming free, some turning into products, and some just disappearing. Because that's how development and open sourcing works at large "companies/organizations", they need to buy the commercial license basically for every developer.
Note that most university students are probably covered by intellectual property agreements with their universities and funding organizations that also prohibit them from legally developing software with Qt Free Edition as part of their research.
MORONS! IT'S NOT SMART TO PISS PEOPLE OFF WHO WERE NICE ENOUGH TO GIVE YOU SOMETHING, BUT CAN STILL TAKE IT BACK!!!
Woah--you are saying that Troll Tech can "take back" Qt for Linux whenever they please? And you are suggesting that we build a large open source infrastructure on that kind of basis? Something that can be rendered useless at the whim of a small private company or whoever acquires them?
If we based the predominant Linux desktop on that kind of foundation, someone like Microsoft could come in, buy Troll Tech for a miniscule few $100 million, and put a quick end to any client aspirations of Linux. Microsoft kills technology that threatens their position regularly by buying out the competing companies.
If there weren't any other reasons, that alone should be enough of a reason not to touch Qt with the proverbial 10 foot pole.
If more and more people start developing apps with Qt, other toolkits for Linux will fall into disuse. In the end, we might be left with only one high quality toolkit: Qt. And that would be bad, because Qt's license and pricing are not acceptable to many developers. If it comes to that, it would harm Linux as a whole.
I agree that calls for Qt to be placed under some different license are not justified: Troll Tech can license their software whatever way they want.
But users of Qt and KDE should realize that the Troll Tech QPL license is bad for open source and for Linux. If Linux had been licensed like Qt, it would have never caught on. And if KDE succeeds at displacing other Linux desktops, it will largely spell the end of Linux as a competitive, open source client desktop operating system: if you have to pay Troll Tech under the conditions they require you to pay, as a developer, you might as well go with BeOS or Windows, pay less money, get more development tools, and (in the case of Windows) cover a much bigger market segment.
However, I disagree with your statement that "Troll Tech has been very nice to the Linux community". Troll Tech was merely business savvy and opportunistic. Adoption of Qt by KDE was one sweet deal for the company: they made software available to people who otherwise wouldn't pay for it anyway, they got a huge user community, lots of naive university students started hacking free software in it, and they got lots of feedback, bugfixes, and improvements, and adoption by several big companies in return. Without the exposure from KDE, Qt would have remained just one of many mediocre, tool-poor cross platform toolkits with a tiny user community. Troll Tech's "donation" paid handsomely for them. The open source community has nothing to excuse for or be thankful for.
Altogether, I agree: don't ask Troll Tech to free Qt, or KDE to change their license. Instead, just don't use those systems. Develop and support truly free desktop software instead.
Whenever the question of MySQL vs. PostgreSQL comes up, someone is sure to dust off the old "bank account transfer" example and pound the table about how important transactions are to guarantee consistency and prevent data loss.
Nonsense. Many applications (including banking applications) that theoretically would be well served by transactions still run largely non-transactioned and use proven real-life approaches instead (transaction limits, nightly reconciliation) because trying to handle everything with transactions would create a huge bottleneck. As for data loss, that is more of an issue with database logging and replication, which you can have without having transactions.
Both MySQL and PostgreSQL have their strong points and their weak points. I think I have a slight preference for MySQL, not in spite of, but because of, its limited feature set; it keeps people from blindly using performance killing features that most applications just don't need; full SQL just makes it too easy to write something that will bring the whole database to a grinding halt.
Ultimately, the argument between MySQL and PostgreSQL is missing the point. The current crop of SQL-based databases (this includes Oracle and DB2) are just awful for modern applications: their APIs and data models are a poor match to what we really need (SQL was originally designed to allow managers to generate reports easily). The widespread use of "stored procedures" and various "object" features is a clear indication of that. Some alternatives are on the horizon. For now, we'll have to make do with what we have, I guess.
It's not ideologically wrong for musicians to make money, and I don't think the original message claimed that.
The question is what happens when technology makes it infeasible to make money off music (or any other field of endeavor). The legal means by which profitability could be retained also fundamentally affect our rights to communicate and share non-copyrighted information with each other.
So, should our society put draconian restrictions on the rights of people to exchange information so that musicians (actually, mostly the major record labels) get a guaranteed return? Or should we accept that certain occupations simply become obsolete because of technology?
We don't force people to ride horses (to give blacksmiths and horsefarms work) or run around in handwoven, coarse cloth (to allow the weavers to support themselves). Why should we force people to listen to music on outdated, copy-restricted media? Technological progress causes lots of people to lose jobs, but it also creates lots of new jobs. That's the road we have chosen as a society.
Even if there were no limitation on music copying, many people would still continue to go to live performances, and the Internet would be a great way to promote that. It would also get rid of many people who were in it only for the money and who produce merely formulaic stuff designed to appeal. Getting rid of retail distribution with its star system, marketing, and limited access may well turn out to be overall good for music.
I completely agree that encryption should be use widely.
Unfortunately, our existing software infrastructure still makes this difficult. Keeping cryptography out of standard software (as opposed to out of terrorist hands) was likely the primary reason for all the shenanigans that the administration and intelligence community engaged in.
For example, I tried using an encrypted file system on my Linux laptop, and it took several hours (and I'm fairly familiar with recompiling the kernel, even modifying it). The stuff gets distributed in too many different pieces, the documentation is somewhat confusing, etc.
So, ask your favorite software authors and distributors to support and include cryptography in their distributions, including standard Linux distributions and the kernel. Note that a single "secure" distribution of Linux isn't sufficient, because it's an obvious place for Trojan horses.
I like it when game developers write their game under the assumption that there is no hard disk.
If they can assume a disk, they'll want to "install" all sorts of stuff there, including patches, upgrades, and media that need fast access. Disks run out of space and need cleanup. And when you upgrade the console, the built-in disk with all your saved games, patches, upgrades, and media goes away. Putting a disk into the console gives us the same mess as Windows machines. I might as well buy a PC.
Keeping the disk optional means that a lot of software will be written that doesn't require a disk. It means that software developers will have an incentive to provide DVDs with bug fixes, rather than just throwing a few megabytes of bug fixes up on a web site. They may even be more careful with their releases because they can't just put up a patch. And the memory cards are still good enough for saving games.
The original implementations of GUIs and desktops in languages like Smalltalk and Cedar/Mesa made exploration and experimentation quite easy.
Then came Apple. They cut corners to squeeze something that looked like the Xerox PARC GUIs into completely underpowered machines. First, they tried the Lisa, which was marginally acceptable, if already quite stripped down. Then came the 128k Mac and its toolbox. It was a great engineering achievement and a great hack. Microsoft then just copied Apple's strategy, coming out with a mediocre clone of a good hack. Apple's strategy worked beautifully in the market.
But squeezing all that stuff into these underpowered machines meant that customizability, ease of programming, and extensibility went out the window. X and UNIX contributed their part. The overall result has been 20 years of living within a straightjacket of limiting APIs, poor tools, and lousy languages. Since the consumer didn't have to deal with the programming side and since the results looked nice, the consumer was happy. But, IMO, Apple is probably the single most responsible company for impeding progress in the area of GUIs and HCI.
People will make progress in fields when they have good tools that allow them to explore new ideas easily. We are only now beginning to get back to the state of the art of the early 1980's. Languages like Java and Python make experimentation easier, and systems like OpenGL present a good standard for advanced graphics. Maybe soon, we'll see some genuine progress in human/computer interaction again.
Several people responded to my post about the "PSX2 booting Linux" with the question "why?".
The answer is simple: the hardware is mass produced and gives you excellent bang for the buck. And it has all the bits and pieces you need for building a supercomputer: the FireWire provides very fast networking and access to disks (perhaps based on object storage disks), and the PSX2 (*) has two vector processing units that can be useful for scientific computations. That's why people have started looking into building Beowulf-like clusters out of them.
The Xbox may or may not be interesting for the same reasons. Its hardware is more traditional (Intel processor, Ethernet, local disk) and that would make it easier to put together a Beowulf cluster out of them. On the other hand, I remain unconvinced that the Xbox can actually be produced at a price that makes it interesting to use for supercomputing. And what makes it particularly uninteresting is that it isn't going to ship in the near future.
Ethernet is slower than Firewire, and it doesn't function as an expansion bus or interface to multimedia devices. Firewire is the right choice for adding external disks, as well as hooking up to camcorders, frame grabbers, cameras, networks, and all sorts of other devices.
The PS2 design, having no disk in the box but a standard interface for adding an external one, is the right choice for a consumer product, IMO. It means that people can upgrade the main box without losing their data, and it lowers the cost of the main box. It also means that consumers can buy a lot of other useful external devices and keep using them when they upgrade.
The Xbox design with the disk in the Xbox and some sort of "expansion slot" and Ethernet is altogether much inferior. With Xbox, Microsoft is thinking "in the box".
As for Sony's strategy and corporate citizenship, they are a consumer products company and they make hardware. Sure, they are a big corporation, they do proprietary stuff, and sometimes even plain stupid things (e.g., memory stick). They also push proprietary standards from time to time. But so far, I don't see them trying to take over the world by attempting to put tentacles into every protocol and infrastructure known to man (we can criticize them if they ever get there). And I note that the PS2 already boots Linux and has some gcc support. I don't know where all that came from, but I suspect it involved at least some cooperation from Sony.
Consoles are really easy to upgrade. For less than $250, you can upgrade your processor, graphics card, and memory all at once and without opening the box--by buying a new one. On the PS2, the stuff you want to keep, your network connection and disk, are hooked up to the FireWire port, so you get to hang on to them (the Xbox, OTOH, has the same design flaw as PCs by putting the disk into the main box).
Slashdot Mirror
Internal software is a crucial part of open source software, because much of it will eventually become open source. My company has released probably a dozen software packages as open source that started out as internal software (some of it very widely used).
But if you try to force internal software to be open from the start by placing a QPL-style license on your platform's libraries, many people will simply use a different platform.
Maybe you are too young to remember, but we had roughly that situation with Motif and Solaris. People would write lots of software for those platforms, in particular at universities, where they were essentially free, but anybody else needed to pay Sun and OSF a lot of money to use them.
In any case, I don't suggest that there are "license problems": I think it's pretty clear what Troll Tech's intent is, and I don't want them to change it. What I'm suggesting is that if QPL'ed software becomes the basis for a standard Linux desktop, that will be a problem for Linux, and that's why people should develop for something else.
You can place your own software under the GPL, but the QPL terms still apply, in addition to whatever terms you put in it yourself.
It is plain wrong to claim that internally written GPL'ed software is subject to such requirements. This is a direct consequence of the QPL. Troll Tech's claims to the contrary are wrong and misleading.
Still, I have mixed feelings about even using KDE. Yes, you are right that you can use KDE and develop using another toolkit. But non-KDE/Qt applications won't integrate as well with KDE as KDE/Qt applications will, so the more people use KDE, the more pressure there will be to develop for it. And the more people use KDE, the more bug reports and suggestions for improvement get submitted to Troll Tech, quality control that other toolkits miss out on.
Besides, installing multiple desktop and toolkit systems increases support and training costs and uses up more resources (disk space, memory, etc.).
I would buy the "use KDE and develop for something else" argument more if KDE was committed to a seamless integration with GTK and other toolkits. But recent statements suggest that they aren't, at least in the short term.
Well, both in my work as an independent consultant and in the corporate world, wherever I have worked, $1500 for a library has always been a lot of money. But I will admit that there are companies for which money is no object (defense contractors in the past, .com startups these days, I suppose).
But even if $1500 is a problem, what makes you think that commercial or non-commercial alternative toolkits can't compete with QT? It's not that they own some interface or other standard (like Microsoft).
Nothing makes me think that "they can't compete" technically. In fact, I think there are better toolkits than Qt. But the fact is that lots of people develop for KDE/Qt, and that's why I think it's worth pointing out to people who do that there are problems with the Qt license and that that is one of the many reasons they should look at other toolkits.
The QPL is at best ambiguous; Troll Tech's FAQ is not:
The QPL is far closer to the intent of the GPL than the LGPL, which is what I'm assuming you are advocating. All free software library authors should be concerned with is allowing people to write free software.
I'm concerned with not being forced to release software that I develop internally. That is clearly the intent of Troll Tech, and it clearly goes against the goals of the GPL and the LGPL. Here is a recent quote from RMS on the Plan 9 license:
As for "advocating" or "disguising", I'm doing neither. I'm merely stating my opinion that if Qt becomes the basis for the predominant Linux desktop, that will be very disadvantageous for the adoption of Linux as a whole, contrary to the stated goals of the KDE project.
I agree, and I think that should be reason for concern. Why? Because it means that any development for Linux for this "standard desktop" inside a corporation, even just for internal use, requires and expensive, commercial Qt license.
If people inside corporations had had to pay $1500/developer to get Linux in the door for trying it out on internal development efforts on it, it would have never caught on as a server platform.
And because the GUI toolkit and desktop is the most important part of a client, desktop OS, having that kind of fee structure for the "standard" GUI toolkit would harm Linux as a client platform.
So far, there are still viable alternatives to KDE/Qt. But every time a free software developer decides to develop a new piece of software for KDE/Qt rather than Gnome or some other free toolkit, KDE/Qt gets the bug fixes, functionality, and increase in user community. There is a high opportunity cost with choosing KDE/Qt for the other toolkits. Those are the network effects that got MS Windows where it is today.
Let's not make the same mistake with Linux that the industry made with Windows. Develop for free platforms, even if the alternatives seem more expedient to you in the short term.
Xerox didn't just have "concepts", they delivered a series of fully functional, easy to use office machines, as well as a series of languages and environments for building GUI applications.
I find that even the best GUI libraries of today are much harder to program and and arguably harder to use than what Xerox delivered 20 years ago.
So, do you care to elaborate in what way you think we have "come a long way"?
Most mainstream, Windows programs are written in VC++, so it's not like that this will bring the few crucial apps to Linux that Linux needs for mainstream acceptance (mostly Office).
OTOH, it will keep Windows programmers from learning how Linux development and programming works. They'll develop in the same style that they developed on Windows, and they'll produce the same kind of software that they produce on Windows. That kind of software is one of the main reasons I don't use Windows, and one of the main reasons other people have fled Windows as well.
In any case, this discussion has gone off track. I responded to a posting by someone who claimed that (I'm paraphrasing) "Troll Tech could take back Qt at any time, so we shouldn't annoy them". I don't see how anybody who has that kind of belief can advocate building a large free software infrastructure on such software.
We can argue whether that belief is justified. I think it is partially justified, given the license and the loopholes. You may disagree. That's life.
The UNIX lpr protocol avoided dealing with most of those issues and assumes the whole world is PostScript or ASCII and having minimal security. And Windows now has a proprietary solution for installing drivers and other issues.
I hope IPP won't go overboard. Many of the issues I mentioned, I think, are best left unaddressed, because if the printing protocol makes it too easy to create a proliferation of configurations and printer drivers, people will do just that. But something a bit more featureful based on HTTP I think would definitely be a step forward.
I think we need more information to see whether this signals a lessening of RedHat's commitment to an open source corporate strategy, or whether they are executing the "traditional" open source strategy of selling support and configuration, or whether this is something yet different. It's definitely something to be looked at carefully, but I wouldn't get overly concerned until more facts are in.
Furthermore, destroying Qt is easy without ever triggering the "KDE Free Qt Project": stop the commercial support, and do half-hearted development. Then, KDE/Qt would be a toolkit with one of the most restrictive "open source" licenses in existence, completely unsuitable even for commercial users that have the money to pay. Hundreds of commercial developers would be left stranded and would have to port their code to other GUI toolkits.
I think it's completely naive to believe that the QPL and "KDE Free Qt Foundation" protect anything. And I cannot help but think that Troll Tech is disingenuous rather then incompetent when they put together this string of legally flawed licenses and agreements.
The "standard" GUI toolkit for an open source OS is of fundamental importance; it is unlike almost any other library. If the GUI toolkit license isn't acceptable to a lot of potential users and supporters, the platform isn't acceptable to a lot of potential users and supporters.
And what it comes down to is that, IMO, the LGPL is fine for an open source GUI toolkit. The GPL is marginal (it at least allows internal use), and the QPL is not.
As for Gnome/GTK specifically, as far as I can tell, the GTK is fully under LGPL. That's good. Gnome is partially under GPL. That's not so good. If parts that are essential for writing good GUI apps and/or interoperating are under GPL (rather than LGPL), I think Gnome is also unsuitable to fill the role of predominant GUI platform on Linux (although I think a GPL'ed toolkit is still preferable to Qt Free Edition).
But, more generally, I question whether there should be a predominant GUI platform on Linux, rather than an interoperable diversity. "KDE and Qt everywhere" is just as harmful to me as "Windows everywhere". The whole "KDE vs. Gnome" thing is like "Windows vs. MacOS". If people work more on interoperability instead of pushing a particular platform, then all these issues about one toolkit vs. another become much less important. And, who knows, with interoperability standards, the Linux desktop might even progress beyond being a Windows/MacOS clone, as people who have new ideas can incrementally move towards a new paradigm.
In my experience, most uses of free software start off as "internal" development, with some of the projects eventually becoming free, some turning into products, and some just disappearing. Because that's how development and open sourcing works at large "companies/organizations", they need to buy the commercial license basically for every developer.
Note that most university students are probably covered by intellectual property agreements with their universities and funding organizations that also prohibit them from legally developing software with Qt Free Edition as part of their research.
Woah--you are saying that Troll Tech can "take back" Qt for Linux whenever they please? And you are suggesting that we build a large open source infrastructure on that kind of basis? Something that can be rendered useless at the whim of a small private company or whoever acquires them?
If we based the predominant Linux desktop on that kind of foundation, someone like Microsoft could come in, buy Troll Tech for a miniscule few $100 million, and put a quick end to any client aspirations of Linux. Microsoft kills technology that threatens their position regularly by buying out the competing companies.
If there weren't any other reasons, that alone should be enough of a reason not to touch Qt with the proverbial 10 foot pole.
If more and more people start developing apps with Qt, other toolkits for Linux will fall into disuse. In the end, we might be left with only one high quality toolkit: Qt. And that would be bad, because Qt's license and pricing are not acceptable to many developers. If it comes to that, it would harm Linux as a whole.
But users of Qt and KDE should realize that the Troll Tech QPL license is bad for open source and for Linux. If Linux had been licensed like Qt, it would have never caught on. And if KDE succeeds at displacing other Linux desktops, it will largely spell the end of Linux as a competitive, open source client desktop operating system: if you have to pay Troll Tech under the conditions they require you to pay, as a developer, you might as well go with BeOS or Windows, pay less money, get more development tools, and (in the case of Windows) cover a much bigger market segment.
However, I disagree with your statement that "Troll Tech has been very nice to the Linux community". Troll Tech was merely business savvy and opportunistic. Adoption of Qt by KDE was one sweet deal for the company: they made software available to people who otherwise wouldn't pay for it anyway, they got a huge user community, lots of naive university students started hacking free software in it, and they got lots of feedback, bugfixes, and improvements, and adoption by several big companies in return. Without the exposure from KDE, Qt would have remained just one of many mediocre, tool-poor cross platform toolkits with a tiny user community. Troll Tech's "donation" paid handsomely for them. The open source community has nothing to excuse for or be thankful for.
Altogether, I agree: don't ask Troll Tech to free Qt, or KDE to change their license. Instead, just don't use those systems. Develop and support truly free desktop software instead.
Nonsense. Many applications (including banking applications) that theoretically would be well served by transactions still run largely non-transactioned and use proven real-life approaches instead (transaction limits, nightly reconciliation) because trying to handle everything with transactions would create a huge bottleneck. As for data loss, that is more of an issue with database logging and replication, which you can have without having transactions.
Both MySQL and PostgreSQL have their strong points and their weak points. I think I have a slight preference for MySQL, not in spite of, but because of, its limited feature set; it keeps people from blindly using performance killing features that most applications just don't need; full SQL just makes it too easy to write something that will bring the whole database to a grinding halt.
Ultimately, the argument between MySQL and PostgreSQL is missing the point. The current crop of SQL-based databases (this includes Oracle and DB2) are just awful for modern applications: their APIs and data models are a poor match to what we really need (SQL was originally designed to allow managers to generate reports easily). The widespread use of "stored procedures" and various "object" features is a clear indication of that. Some alternatives are on the horizon. For now, we'll have to make do with what we have, I guess.
The question is what happens when technology makes it infeasible to make money off music (or any other field of endeavor). The legal means by which profitability could be retained also fundamentally affect our rights to communicate and share non-copyrighted information with each other.
So, should our society put draconian restrictions on the rights of people to exchange information so that musicians (actually, mostly the major record labels) get a guaranteed return? Or should we accept that certain occupations simply become obsolete because of technology?
We don't force people to ride horses (to give blacksmiths and horsefarms work) or run around in handwoven, coarse cloth (to allow the weavers to support themselves). Why should we force people to listen to music on outdated, copy-restricted media? Technological progress causes lots of people to lose jobs, but it also creates lots of new jobs. That's the road we have chosen as a society.
Even if there were no limitation on music copying, many people would still continue to go to live performances, and the Internet would be a great way to promote that. It would also get rid of many people who were in it only for the money and who produce merely formulaic stuff designed to appeal. Getting rid of retail distribution with its star system, marketing, and limited access may well turn out to be overall good for music.
Unfortunately, our existing software infrastructure still makes this difficult. Keeping cryptography out of standard software (as opposed to out of terrorist hands) was likely the primary reason for all the shenanigans that the administration and intelligence community engaged in.
For example, I tried using an encrypted file system on my Linux laptop, and it took several hours (and I'm fairly familiar with recompiling the kernel, even modifying it). The stuff gets distributed in too many different pieces, the documentation is somewhat confusing, etc.
So, ask your favorite software authors and distributors to support and include cryptography in their distributions, including standard Linux distributions and the kernel. Note that a single "secure" distribution of Linux isn't sufficient, because it's an obvious place for Trojan horses.
If they can assume a disk, they'll want to "install" all sorts of stuff there, including patches, upgrades, and media that need fast access. Disks run out of space and need cleanup. And when you upgrade the console, the built-in disk with all your saved games, patches, upgrades, and media goes away. Putting a disk into the console gives us the same mess as Windows machines. I might as well buy a PC.
Keeping the disk optional means that a lot of software will be written that doesn't require a disk. It means that software developers will have an incentive to provide DVDs with bug fixes, rather than just throwing a few megabytes of bug fixes up on a web site. They may even be more careful with their releases because they can't just put up a patch. And the memory cards are still good enough for saving games.
Then came Apple. They cut corners to squeeze something that looked like the Xerox PARC GUIs into completely underpowered machines. First, they tried the Lisa, which was marginally acceptable, if already quite stripped down. Then came the 128k Mac and its toolbox. It was a great engineering achievement and a great hack. Microsoft then just copied Apple's strategy, coming out with a mediocre clone of a good hack. Apple's strategy worked beautifully in the market.
But squeezing all that stuff into these underpowered machines meant that customizability, ease of programming, and extensibility went out the window. X and UNIX contributed their part. The overall result has been 20 years of living within a straightjacket of limiting APIs, poor tools, and lousy languages. Since the consumer didn't have to deal with the programming side and since the results looked nice, the consumer was happy. But, IMO, Apple is probably the single most responsible company for impeding progress in the area of GUIs and HCI.
People will make progress in fields when they have good tools that allow them to explore new ideas easily. We are only now beginning to get back to the state of the art of the early 1980's. Languages like Java and Python make experimentation easier, and systems like OpenGL present a good standard for advanced graphics. Maybe soon, we'll see some genuine progress in human/computer interaction again.
The answer is simple: the hardware is mass produced and gives you excellent bang for the buck. And it has all the bits and pieces you need for building a supercomputer: the FireWire provides very fast networking and access to disks (perhaps based on object storage disks), and the PSX2 (*) has two vector processing units that can be useful for scientific computations. That's why people have started looking into building Beowulf-like clusters out of them.
The Xbox may or may not be interesting for the same reasons. Its hardware is more traditional (Intel processor, Ethernet, local disk) and that would make it easier to put together a Beowulf cluster out of them. On the other hand, I remain unconvinced that the Xbox can actually be produced at a price that makes it interesting to use for supercomputing. And what makes it particularly uninteresting is that it isn't going to ship in the near future.
(*) Where did that "X" in "PSX2" come from?
The PS2 design, having no disk in the box but a standard interface for adding an external one, is the right choice for a consumer product, IMO. It means that people can upgrade the main box without losing their data, and it lowers the cost of the main box. It also means that consumers can buy a lot of other useful external devices and keep using them when they upgrade.
The Xbox design with the disk in the Xbox and some sort of "expansion slot" and Ethernet is altogether much inferior. With Xbox, Microsoft is thinking "in the box".
As for Sony's strategy and corporate citizenship, they are a consumer products company and they make hardware. Sure, they are a big corporation, they do proprietary stuff, and sometimes even plain stupid things (e.g., memory stick). They also push proprietary standards from time to time. But so far, I don't see them trying to take over the world by attempting to put tentacles into every protocol and infrastructure known to man (we can criticize them if they ever get there). And I note that the PS2 already boots Linux and has some gcc support. I don't know where all that came from, but I suspect it involved at least some cooperation from Sony.
Consoles are really easy to upgrade. For less than $250, you can upgrade your processor, graphics card, and memory all at once and without opening the box--by buying a new one. On the PS2, the stuff you want to keep, your network connection and disk, are hooked up to the FireWire port, so you get to hang on to them (the Xbox, OTOH, has the same design flaw as PCs by putting the disk into the main box).