I think such restrictions are often counterproductive. Within certain limits, the more operating systems like Windows, MacOS, Solaris, and AIX rely on free software, the more commercial programmers will get used to free software and open APIs. Once they are in the fold, they'll quickly realize that it is usually cheaper to participate in the open source project than to try and maintain a separate proprietary branch in parallel. Having free software available on proprietary platforms also reduces the risk that commercial players take over the market through advertising, PR, FUD, and patents.
I understand the urge to be as restrictive as possible with free or open source software, but in the end, I think liberal licenses are a better idea in most cases. Restrictive licenses may make sense on a case-by-case basis.
The GPL is not about gaining some consideration for use, but denying a certain use to a certain group.
Of course, the GPL is about gaining consideration: it's your potential contributions for your ability to use the software. That's an equitable trade, and it isn't denying you anything. If you don't like it, don't enter into the contract.
They have no willingness to negotiate, and despite offering it to proprietary software developers, they deliberately prohibit the use it's wanted for.
It's not offered to "proprietary software developers". And, as you should have learned as a child, not all your wants are met by the world. Other people have wants, too.
By traditional contract standards, this is not at all reasonable.
By your reasoning, I should be able to copy Microsoft Windows freely and widely. After all, their EULA is keeping me from doing what I want with it, and Microsoft won't negotiate their EULA with me.
Re:Things RMS didn't forsee in 1984
on
GPL FAQ
·
· Score: 2
It won't matter. These things are all governed by whether the work is or is not a derivative work in the copyright sense, and it does not matter in the slightest what the GPL or RMS' lawyers say about it. [...] Recall, the GPL does not extend copyrights by engaging the user in a contract before use, as would be the case in an EULA.
I don't see what makes you say that the GPL is "not a contract". It's not just a "waiver of rights" on the part of the author, it's a list of rights and obligations for both the author and the user of the GPL'ed software.
As far as I can tell, the GPL is a contract, no different from the MS EULA, shrink-wrap, or click-through agreements. Recent legislation has, in fact, strengthened these kinds of contracts. And as a contract, it can require you to do certain things unrelated to "derived software", like place some of your software under the GPL. Many other software licenses, in fact, make claims on something you have that's definitely not a derivative work: your money.
TiVo managed to come up with an innovative product that plenty of people (especially here) have found to be extremely useful and worth the price. As such, they deserve to have their advances in technology formally protected, and they have.
TiVo's success wasn't about a great idea. Lots of people had the same idea. Cheap digital video compression technology and harddisks just made it feasible to turn that idea into a consumer product at a certain point in time. TiVo's success was about timing, about lining up investment and going to market at roughly the right point. And a lot of their patents sound to me like stuff any reasonable engineer would come up with as a natural part of designing a PVR, without any significant thought.
See - the patent system isn't all bad:)
We would have TiVo-like devices with or without TiVo: the idea is pretty obvious. Without TiVo or some other company pushing consumer hardware early on, this would probably have started a couple of years later, first as software and hardware add-ons to PCs, Macs, and Linux machines.
Perhaps they can even get some money out of Microsoft for ripping them off with their Ultimate TV.
I don't see any rip-off. And they will be after you when you try to do similar kinds of things with your GPL'ed video recording software on Linux.
By granting these kinds of patents, the PTO risks that for the next 20 years, it could be mainly TiVo that controls this market, without being forced to innovate further. Soon, it will be cheaper to build TiVo-like devices than to build VCRs, yet if TiVo's patents turn out to be broad enough, they can keep the prices and profit margins high.
I think this is actually a good example for why patent life times should be shortened. TiVo should manage to make a tidy profit on their patents in five years. It makes little sense to grant them an artificial monopoly beyond that, no matter whether their patents are sensible or not, and doing so deprives the public of further innovation, in contradiction to the foundations of the patent system.
Of course, since there is so little that is worth recording on TV, it's probably pointless to get very upset about this.
For plain Tk, you have to write new widgets in C. I'd say, that's a little easier than for Motif, and a little harder than for Gtk+. It's significantly harder than for Qt. And it's a lot harder than writing new widgets for FLTK, wxWindows, or Swing. Another problem, though, was distribution. The Tcl/Tk team never seemed very eager to incorporate outside code, and a lot of widgets that got created languished for a few releases on some external web site and then eventually stopped being maintained. Finally, I think Tcl/Tk was ultimately limited by the large number of people who felt that Tk was contaminated by its close association with Tcl.
I think Tcl/Tk could have been so much more than it is if it had had a somewhat less screwy scripting language and a more open development process. Even as it is, it's still very widely used and extremely portable: you can pretty much use it on any UNIX or Windows system.
They chose the former, making the GPL nearly meaningless, rather than choosing the latter, and scaring off everybody even thinking of touching GPL'd software. Now it's just a matter of who gets better lawyers and the quirks of the judge.
If that is the intent, it would represent both bad faith and bad judgement. If two parties enter into a contract in good faith, they should aim to clarify each other's rights and obligations. And except perhaps for some clueless companies, anybody with legal counsel will get the advice that if it isn't clearly permitted by the license, they should not do it. That is, in my opinion, also the ethically correct position.
I hope that you are wrong and that the FSF merely hasn't gotten around to incorporating these clarifications into the next version of the GPL. Being deliberately vague would, I think, undermine their ethical position and be quite harmful to the GNU project.
Why isn't the GPL more specific?
on
GPL FAQ
·
· Score: 2
I don't understand why the GPL itself can't be more specific. The FAQ already lists some concrete cases where the GPL applies and doesn't apply to a program that uses GPL'ed code. Why can't a number of those explicit cases be defined in the GPL itself? For concreteness, the cases could be defined in terms of GNU/Linux software terminology with the additional clause "or analogous mechanisms on other operating systems or platforms". Static linking, dynamic linking, dynamic loading, invocation as a standalone program, and invocation through a system like CORBA could all be clarified that way.
I can only think that the FSF likes to be a bit vague about what can and cannot be done with GPL'ed software. But I think that makes the GPL less useful than it could be: authors placing their software under the GPL deserve the clearest license possible.
I think putting ReiserFS into may not be a good engineering tradeoff. What are the tradeoffs? We gain the following:
ReiserFS allows very fine-grained access control, on a "per field" (per file) basis. But is that really needed for the kinds of databases it is intended for? The main applications listed for it, databases, file servers, and desktop applications, either have a front-end application that performs its own security checks, or they run on behalf of a single user. Furthermore, even if fine-grained access control is needed, the set of user ids known to the kernel often does not correspond anymore to the set of users authorized to access the data.
Being in the kernel, all applications use it automatically. But if we put a database into libc and hooked it into the file system calls, we'd get almost the same benefits.
What are the disadvantages of putting it into kernel space?
Performance. Currently, it takes several system calls to access a data item in ReiserFS. That's a lot of overhead.
Slow evolution. ReiserFS could benefit greatly from additional API calls, but adding those is a big hassle because they need to become ioctls or new system calls.
Maybe ReiserFS is the best we are going to get and the only way in which people are going to migrate to something less impoverished than the current UNIX file system data model. But I still think it's not a good engineering tradeoff overall.
Tk, unfortunatly, has a very limited set of widgets. They are good enough for probably 90% of the applications people write, but what are they going to do for the rest? In part, I think these limitations are a consequence of the fact that Tcl is a pretty limited language and isn't sufficient to extend Tk (MegaWidgets and [incr Tcl] were too little too late and still aren't even part of the default distribution).
Having said that, I think Tcl/Tk is still proof of how powerful the combination of an interpreted language and a widget set can be. And the Tk binding to Tcl is a lot easier to use (in particular, for "non-specialists") than any of the Gtk+ or Qt bindings to Python or other languages.
I think you are going to see a system like Tcl/Tk appear again, but based on a better language and with more of the widget code written in the scripting language.
I know what you mean: the text components in Swing are complex. But what's the alternative? At least, with Swing you could get there without starting from scratch. And while we both may be cursing the complex and general APIs that do so much more than we want, and all the thinking we have to do to figure them out, it's still a lot better than starting from scratch.
The text widgets in Tcl/Tk, Gtk+, wxWindows, and Win32 are easier to use, but I think they are too limited to implement a full HTML editor (or do a lot of the other oddball things I have managed to do with Swing). OTOH, if you start with the Mozilla editor or Frontpage as a component, someone has already done all the hard work, but you probably can't customize them in the way you want without hacking their sources, and in the end, they will probably still retain functionality that's inappropriate and confusing to users (not to mention their size and potential licensing problems).
I found what helps a lot with complex APIs like Swing's text widget is to get a "cookbook" type manual. That way, I can get whole code snippets and assemble them into what I want.
IBM had a big team working on that and they never succeeded either. The reason is that the Win32 API doesn't have a spec and you don't know all the hidden features "clever" programmers are taking advantage of.
Of course, even if it did have a spec, reimplementing something obscure and complex to a spec is a lot harder than creating something and the later writing an obscure and complex spec for it.
Fountain has some points. First, Motif uses X11 more efficiently than Gtk+ or Qt. I think much of the reputation X11 has among new programmers for inefficiency is because Gtk+, Qt, Mozilla, and other recent toolkits take such a brute force approach to using the X11 APIs. Gtk+ and Qt's redraw logic also don't work as well with the X11 protocol. Of course with 1GHz machines and 1Mbit Internet hookups, that matters less and less. Also, neither Gtk+ nor Qt have anything that is a nice and flexible as the toolkit intrinsics when it comes to GUI configuration, options, and GUI building.
However, to me, all that is water under the bridge. In practice, Motif was a messy and buggy toolkit that it took forever to get anything done in. Most corporate and defense projects I have seen dumped Motif as soon as they had an alternative, mostly for Tcl/Tk and web interfaces (but if you prefer to believe that the lack of press Motif is getting is some corporate conspiracy to keep the good stuff from you, I have some Internet stocks for you to invest in).
OTOH, I don't think Gtk+ or Qt will have the life span of Motif, for a variety of reasons. The only existing toolkit that seems to me like it's going to survive another two decades is probably Swing, which is pretty powerful, easy to extend, and still simple enough to develop for.
Re:What has TT done for KDE?
on
Qt for Mac
·
· Score: 2
Honest question: like what ? The only other I know is wxWindows, which is based on GTK+(or Motif) for Unices. In particular, which one were around, ready for use, when KDE started (like you said in your other post)?
For a C++-based system, I think Interviews would have been a good choice. Garnet might have been as well. More generally, however, I have my doubts that KDE should have been based on C/C++ in the first place. Contributing to the GNUStep project might have been a better approach, as might have been developing a new toolkit.
We should not complain about all these failing open-source companies , and then complain about the fews that, playing fair, manage to succeed.
In my opinion, TrollTech hasn't been playing fair: I think they have misled people and taken advantage of the open source community for their own financial gain. Thanks, but I'd rather do entirely without that kind of commercial involvement in open source.
I think the current Linux desktop efforts suffer from two serious problems.
First, they don't address the needs of the traditional UNIX/Linux user community. Those users want tools that they can use to put together applications quickly from the command line after looking at a couple of concise manual pages. For desktops, Gnome and KDE fail to support that kind of usage. Gnome and KDE are complex C/C++ systems that require a lot of time to get started with and a lot of effort to build applications for. If UNIX/Linux users wanted that, why wouldn't they just switch to the "free" copy of Windows that shipped with their PC?
The second problem is that Gnome and KDE (plus all its applications) are oriented towards the past. Putting together desktop apps by laboriously writing widget creation code and laying out widgets in some "visual designer" is so 1990's. That's what Microsoft used to do. And building huge, complex, do-everything applications harks from an era where vendors needed to cram whatever functionality they could onto a single CD-ROM because they only got one shot at reaching the end user; with the Internet, we don't need that anymore.
So, where should the Linux desktop really go? Here are some ideas:
Use something higher level, safer, and simpler to program than C/C++. Python or Java are good choices. In languages like that, programmers will have a lot more time left worrying about efficiency, and their applications will likely end up being smaller and faster than the C/C++ applications currently being written. And compute-intensive loops can still be written in C/C++. (A significant number of Gnome applications seem to be written in Python--that's a good start.)
Approach GUI design more like HTML/XML authoring and less like programming/visual layout. The former is something a lot more people are capable of. It helps design applications more quickly, it makes them work better on a variety of devices and screens, and allows non-specialists to change significant aspects of UIs.
Pick better graphics abstractions. The Tcl/Tk canvas and MacOSX's object graphics are good abstractions, the bit-by-bit drawing found in Windows and most current Linux toolkits are not. Unlike MacOSX, you don't have to throw out X11 (which is basically a reasonable window system), you can build such libraries on top of it.
Write small, targetted applications. Don't write a do-all word-processor, write a word processor toolkits (that knows about XML, menubars, rendering, previewing and printing) and let people build word processors for specific applications themselves (letters, business forms, papers, etc.).
Don't use CORBA, RMI, or similar systems: they are unnecessarily complex and are too strict about what can talk to what and when they can talk. Systems like Linda and JavaSpaces are simpler and more forgiving.
The Linux desktop needs to do more than just be a better implementation of dated Windows/Macintosh ideas in order to succeed.
Re:Possibly for somethings, not all though.
on
Qt for Mac
·
· Score: 2
I don't recall the old days of Motif, but was the situation really exactly like this?
No, I think the Motif situation was actually somewhat better. As I recall, at least the people who made the UNIX workstations were part of the consortium that owned Motif. With Qt, you would be asking commercial backers of Linux to engage in marketing and support for the benefit of a company, Troll Tech, that they have no commercial interest in.
Really, the only problem anyone could have with Qt is that you have to pay for it if you do commercial development. This has never made it "unnattractive" however.
How would one be able to quantify that? $2000-$3000/year is more than many companies spend on hardware and software per developer. For many people, the evaluation probably stops right there. In the three corporate jobs I have had, that kind of per-developer license would have required enormous red tape to justify.
Think also of all the missed opportunities. Assuming for the sake of argument that Qt is actually a nice library, wouldn't it be great if lots of Windows developers used it even if they don't need cross-platform development? Then their software would run right away on Linux. Well, they won't do that at these prices.
And, assuming for the moment that KDE would win the Linux desktop, all of a sudden the cost for a commercial software developer on Linux goes from $0 to $2000+/year, all sent to a little company in Norway. Of course, the idea is so absurd that it is pretty clear that KDE cannot take over the Linux desktop as long as it is based on Qt: it will always be at most one of at least two major players, until Linux itself goes away.
[In any case, technically, I don't think Qt is where Linux GUIs should be going anyway.] Where should they be going? Do you not like KDE? Are there any Linux toolkits/GUIs that are going where you think they should?
I think KDE itself is a very good software engineering effort within the requirements it set for itself. It's what Windows NT and Windows 98 should have been.
But where are things going? I think more and more interfaces are built around documents, foremost HTML, XML, and DOM. That's true even for UI "screens" that are never transported through HTTP. It's both a look and an approach to programming. Foremost, it means that UIs aren't designed anymore by programmatically or visually placing widgets in particular locations. Instead, UIs are authored.
Re:What has TT done for KDE?
on
Qt for Mac
·
· Score: 2
Sure, Troll Tech has invested money and time in KDE. I don't think that's altruism: the existence of KDE probably works out the equivalent of millions of dollars a year in advertising, testing, debugging, and product-related research for Troll Tech. Without KDE, I don't think Troll Tech would even be on the map. On the other hand, I think KDE would be just fine without Troll Tech/Qt: you can argue whether Gtk+ is better or worse than Qt, but they are pretty close, and there are several other reasonable C++ toolkits. Qt may have been a good initial catalyst and motivator for KDE, but I think the value of KDE greatly overshadows the value of Qt by now.
Re:Possibly for somethings, not all though.
on
Qt for Mac
·
· Score: 2
What contributions are those? I don't recall any examples of KDE code (which would be GPL) getting back into the early Qt (which were not GPL).
If not anything else, initially, KDE made contributions in lots of bug reports and feature requests; those are enormously valuable, in particular for a company with a new product and little resources for testing. Later, people in the KDE project also started donating code back to TrollTech, although I don't know whether that was before the GPL release or after (not that it matters).
It seems AT&T, NASA, Ford, IBM, and Intel, among others, disagree with you.
I have worked at three of those companies listed as references, and I have never heard of any products developed with Qt there. Often, we'd get listed by vendors if anybody ordered a copy to play around with. I think in that kind of list, even Tcl/Tk would win hands down in terms of customers and commercial products released.
[10 years ago, a C++ cross platform GUI library may have been a big deal, these days, they are a dime a dozen.] Please, complete the following, with toolkits that are as featureful and mature as Qt:
For cross platform development, depending on your requirements, wxWindows, FLTK, MFC/Win32 (with compatibility libraries on some platforms), Interviews, Gtk, Motif (with compatibility libraries on some platforms), Tcl/Tk, Swing, and Fox are all reasonable choices. If you want to argue that Qt is "more featureful" or "more mature", forget it. Each of those toolkits has advantages and disadvantages compared to other toolkits, and Qt isn't a clear winner.
[I also think it was a poor choice for the KDE project] Is there an argument behind this, or just the claim? Can this argument even be defended? Do you know if the requirements of the KDE project could be met by anyone else?
As the "I think" indicates, it's my opinion. Since I had more than a decade of GUI development under my belt around the time the KDE project started, I think I had a pretty good idea of what was out there at the time. I think the KDE developers didn't look hard enough and got snookered by a company with an agenda. Your opinion may be different, of course.
(I'm sorry if the flamethrower was on full-blast, but one thing I can't stand is groundless, unsubstantiated claims by zealots.)
You're as much a babe in the woods when it comes to flaming as when it comes to trusting software vendors. But let's get to substantiation: maybe you can get TrollTech to remove their false and misleading information about the GPL from their site.
Re:Possibly for somethings, not all though.
on
Qt for Mac
·
· Score: 2
They released their flagship product as GPL. Really, what more can they do?
Well, for one thing, they could stop misleading people about the meaning of the GPL. It is, in fact, perfectly fine to develop commercial/closed source software with a GPL'ed library under a number of circumstances, yet TrollTech keeps claiming otherwise.
I'd say the community has gained more than Trolltech has gained, however it's silly to argue about who had the greater benefit. In this case, everyone has won.
I think if a GUI library takes hold on Linux that requires payment to some vendor for any kind of commercial software development, as TrollTech claims for Qt, then Linux becomes a pretty unattractive platform for commercial developers. It also becomes an unattractive platform for people like IBM and Sun to support. Altogether, I think that would be a big loss for Linux: that situation would be worse than the situation we had with Motif on UNIX.
In any case, technically, I don't think Qt is where Linux GUIs should be going anyway. Qt is merely redoing in a slightly cleaner way where Microsoft was 5 years ago, and that style of GUI programming was outdated and cumbersome even back then.
Re:Possibly for somethings, not all though.
on
Qt for Mac
·
· Score: 2
To some the prices might seem "high", but having worked with cross-platform products from other companies ($10,000.00, plus runtime license fees), I can tell you that Trolltech's prices are very reasonable.
An 1 year MSDN subscription is cheaper than a Qt developer license, and you get a lot more for your money in terms of tools, documentation, libraries, compilers, etc. What TrollTech is charging is more than many places spend on all their software and hardware combined per year.
Commercial cross-platform toolkits I have used in the past cost about as much as Qt, but they sure came with a lot more tools. In fact, as far as I am concerned, the only reason Qt is as nice as it is is because of the enormous contributions of the KDE project: without KDE, Qt would have been quickly forgotten.
Besides, the fact that some companies seem bent on charging a captive audience outrageous prices while floundering in the market doesn't mean that any cross-platform GUI library is worth that kind of money these days. 10 years ago, a C++ cross platform GUI library may have been a big deal, these days, they are a dime a dozen.
Nothing on Trolltech's pricing page indicates that you are limited to using the copy for one year. Rather, each copy is limited to one developer
Realistically, for commercial products, you need to get the annual maintenance: Microsoft and Apple keep rolling out new versions of their OS, and as a developer, you need to keep up.
If roughly $3000.00 USD for both *nix and WinXX is "too much" for your product's UI, I really have to question the business plan behind the product.
That's a lame argument. Commercial projects usually involve many developers, not just a single person. And if we are talking about small developers or consultants working on single projects, $2000-$4000/year is a lot of money.
Altogether, I don't think Qt is a good value for commercial projects. I also think it was a poor choice for the KDE project, and TrollTech has gotten a lot more out of KDE than they have given.
I suppose for the time being, the iMac wil still come with a CRT? That may be good enough for their low-end offerings. An iMac with a low-cost LCD would be kind of nice, though.
IR is at least reasonably secure against eavesdropping. With the "wonderful" security of Bluetooth and other current wireless RF protocols, you will be broadcasting your passwords all over your neighborhood. And current COTS RF keyboards don't even bother with the minimal encryption of the wireless protocols.
The IBM stuff probably failed because it was overpriced. There are other IR keyboards still on sale in many places.
There have been mice with integrated keypads for quite some time for use in CAD applications, but they never seem to have caught on much.
In my book, for efficiency and compactness, the IBM Trackpoint is still the best way to go. It takes a while to become good at using it and feel comfortable with it (and many users give up before then), but once you are used to it, it's great. Note that the Trackpoint is different from the pointing sticks found on Toshiba machines and some other imitators; those are really awful.
I certainly don't want all that amateur code in embedded, possibly life-critical systems.
On the one hand, we have graduate students from various universities, industrial and academic researchers, and industrial software developers.
On the other hand, we have some nebulous people deep inside the bowels of some defense, medical, and aerospace contractors that have been writing "life-critical systems" for decades. The kind of people who managed to blow up the Osprey and the Ariane in software and punch holes into patients with radiation machines. They use and create low-volume, proprietary software with little or no peer review. A review of the kinds of blunders these professionals make shows that there are quite a few bad apples in the bunch and just leaves people scratching their heads. So, no, it isn't obvious to me that the "amateur" open source code is any worse in principle than the professional code.
Off-the-shelf Linux itself is probably not a good choice for "life-critical systems" because it wasn't developed with that goal in mind. I'd still trust it more than some of the supposedly "reliable" proprietary systems being sold. If you wanted to make Linux truly reliable, you would probably start by throwing out 90% of the drivers and other extensions and carry out a lot more additional code review and testing. In userland, you'd also limit yourself to a small set of very strictly tested tools.
More generally, however, given the same goals and the same resources for testing and development, I'd trust the open source community considerably more to develop reliable and safety critical systems than a bunch of proprietary professionals: I think the open source community has better people in it, and the open source process brings more resources to bear on code review and bug fixing.
Many people have often pointed out that MS rarely gets anything right on the first try. But by the 3rd iteration or so, the competetion is in trouble. Look at Office, DirectX, and Windows itself.
The competition is in trouble by the 3rd iteration not because Microsoft gets it right, but because Microsoft has manipulated the market so that there isn't any other realistic commercial choice anymore. Office, DirectX, and Windows may look pretty good to you now because there is simply little or no commercial competition anymore.
As for WinCE, maybe people will be swayed by the powerful and nifty hardware that Microsoft specified. The OS itself and its UI are still lousy. Given how bulky and heavy the WinCE machines are still, I still don't see them succeeding.
The Palm platform has lots of shortcomings and limitations: poor resolution, slow processor, limited OS. But it still does the basics better than the commercial alternatives. Palm can still catch up. Judging by their track record, Microsoft will never figure it out; if they win this market, it will only be because all the competitors with better products self-destruct.
no wonder: no reason to upgrade
on
Palm In Trouble?
·
· Score: 2
People have little reason to upgrade to the latest Palm computers: they don't do a lot more than the originals or a low-end $130 M10x or low-end Visor. I find it kind of insulting, actually, that they charge around $400 for the M50x and Visor Edge, hardware that does little more than a Sharp PDA.
Until Palm comes out with new models that have compelling additional features over their current models, they will continue to have financial problems. What would be compelling?
Higher resolution color screen.
Somewhat faster processor, to be able to deal with audio, MP3, and images.
32bit OS (easier to program/port).
Built-in audio I/O, modem, wireless modem, phone, VGA output, and/or digital camera, etc. (not expansion slots), in an M50x/Edge form factor.
Built-in working bluetooth or 802.11 interfaces.
In fact, I think their release of the M50x series and PalmOS 4 was a big mistake: it cost them lots of development time, they are in competition with the VisorEdge, and they are not compelling upgrades. They should have skipped that and instead pushed ahead forcefully on their new ARM platform and 32bit OS.
Slashdot Mirror
I understand the urge to be as restrictive as possible with free or open source software, but in the end, I think liberal licenses are a better idea in most cases. Restrictive licenses may make sense on a case-by-case basis.
Of course, the GPL is about gaining consideration: it's your potential contributions for your ability to use the software. That's an equitable trade, and it isn't denying you anything. If you don't like it, don't enter into the contract.
They have no willingness to negotiate, and despite offering it to proprietary software developers, they deliberately prohibit the use it's wanted for.
It's not offered to "proprietary software developers". And, as you should have learned as a child, not all your wants are met by the world. Other people have wants, too.
By traditional contract standards, this is not at all reasonable.
By your reasoning, I should be able to copy Microsoft Windows freely and widely. After all, their EULA is keeping me from doing what I want with it, and Microsoft won't negotiate their EULA with me.
I don't see what makes you say that the GPL is "not a contract". It's not just a "waiver of rights" on the part of the author, it's a list of rights and obligations for both the author and the user of the GPL'ed software.
As far as I can tell, the GPL is a contract, no different from the MS EULA, shrink-wrap, or click-through agreements. Recent legislation has, in fact, strengthened these kinds of contracts. And as a contract, it can require you to do certain things unrelated to "derived software", like place some of your software under the GPL. Many other software licenses, in fact, make claims on something you have that's definitely not a derivative work: your money.
TiVo's success wasn't about a great idea. Lots of people had the same idea. Cheap digital video compression technology and harddisks just made it feasible to turn that idea into a consumer product at a certain point in time. TiVo's success was about timing, about lining up investment and going to market at roughly the right point. And a lot of their patents sound to me like stuff any reasonable engineer would come up with as a natural part of designing a PVR, without any significant thought.
See - the patent system isn't all bad :)
We would have TiVo-like devices with or without TiVo: the idea is pretty obvious. Without TiVo or some other company pushing consumer hardware early on, this would probably have started a couple of years later, first as software and hardware add-ons to PCs, Macs, and Linux machines.
Perhaps they can even get some money out of Microsoft for ripping them off with their Ultimate TV.
I don't see any rip-off. And they will be after you when you try to do similar kinds of things with your GPL'ed video recording software on Linux.
By granting these kinds of patents, the PTO risks that for the next 20 years, it could be mainly TiVo that controls this market, without being forced to innovate further. Soon, it will be cheaper to build TiVo-like devices than to build VCRs, yet if TiVo's patents turn out to be broad enough, they can keep the prices and profit margins high.
I think this is actually a good example for why patent life times should be shortened. TiVo should manage to make a tidy profit on their patents in five years. It makes little sense to grant them an artificial monopoly beyond that, no matter whether their patents are sensible or not, and doing so deprives the public of further innovation, in contradiction to the foundations of the patent system.
Of course, since there is so little that is worth recording on TV, it's probably pointless to get very upset about this.
I think Tcl/Tk could have been so much more than it is if it had had a somewhat less screwy scripting language and a more open development process. Even as it is, it's still very widely used and extremely portable: you can pretty much use it on any UNIX or Windows system.
If that is the intent, it would represent both bad faith and bad judgement. If two parties enter into a contract in good faith, they should aim to clarify each other's rights and obligations. And except perhaps for some clueless companies, anybody with legal counsel will get the advice that if it isn't clearly permitted by the license, they should not do it. That is, in my opinion, also the ethically correct position.
I hope that you are wrong and that the FSF merely hasn't gotten around to incorporating these clarifications into the next version of the GPL. Being deliberately vague would, I think, undermine their ethical position and be quite harmful to the GNU project.
I can only think that the FSF likes to be a bit vague about what can and cannot be done with GPL'ed software. But I think that makes the GPL less useful than it could be: authors placing their software under the GPL deserve the clearest license possible.
What are the disadvantages of putting it into kernel space?
Maybe ReiserFS is the best we are going to get and the only way in which people are going to migrate to something less impoverished than the current UNIX file system data model. But I still think it's not a good engineering tradeoff overall.
Having said that, I think Tcl/Tk is still proof of how powerful the combination of an interpreted language and a widget set can be. And the Tk binding to Tcl is a lot easier to use (in particular, for "non-specialists") than any of the Gtk+ or Qt bindings to Python or other languages.
I think you are going to see a system like Tcl/Tk appear again, but based on a better language and with more of the widget code written in the scripting language.
The text widgets in Tcl/Tk, Gtk+, wxWindows, and Win32 are easier to use, but I think they are too limited to implement a full HTML editor (or do a lot of the other oddball things I have managed to do with Swing). OTOH, if you start with the Mozilla editor or Frontpage as a component, someone has already done all the hard work, but you probably can't customize them in the way you want without hacking their sources, and in the end, they will probably still retain functionality that's inappropriate and confusing to users (not to mention their size and potential licensing problems).
I found what helps a lot with complex APIs like Swing's text widget is to get a "cookbook" type manual. That way, I can get whole code snippets and assemble them into what I want.
Of course, even if it did have a spec, reimplementing something obscure and complex to a spec is a lot harder than creating something and the later writing an obscure and complex spec for it.
However, to me, all that is water under the bridge. In practice, Motif was a messy and buggy toolkit that it took forever to get anything done in. Most corporate and defense projects I have seen dumped Motif as soon as they had an alternative, mostly for Tcl/Tk and web interfaces (but if you prefer to believe that the lack of press Motif is getting is some corporate conspiracy to keep the good stuff from you, I have some Internet stocks for you to invest in).
OTOH, I don't think Gtk+ or Qt will have the life span of Motif, for a variety of reasons. The only existing toolkit that seems to me like it's going to survive another two decades is probably Swing, which is pretty powerful, easy to extend, and still simple enough to develop for.
For a C++-based system, I think Interviews would have been a good choice. Garnet might have been as well. More generally, however, I have my doubts that KDE should have been based on C/C++ in the first place. Contributing to the GNUStep project might have been a better approach, as might have been developing a new toolkit.
We should not complain about all these failing open-source companies , and then complain about the fews that, playing fair, manage to succeed.
In my opinion, TrollTech hasn't been playing fair: I think they have misled people and taken advantage of the open source community for their own financial gain. Thanks, but I'd rather do entirely without that kind of commercial involvement in open source.
First, they don't address the needs of the traditional UNIX/Linux user community. Those users want tools that they can use to put together applications quickly from the command line after looking at a couple of concise manual pages. For desktops, Gnome and KDE fail to support that kind of usage. Gnome and KDE are complex C/C++ systems that require a lot of time to get started with and a lot of effort to build applications for. If UNIX/Linux users wanted that, why wouldn't they just switch to the "free" copy of Windows that shipped with their PC?
The second problem is that Gnome and KDE (plus all its applications) are oriented towards the past. Putting together desktop apps by laboriously writing widget creation code and laying out widgets in some "visual designer" is so 1990's. That's what Microsoft used to do. And building huge, complex, do-everything applications harks from an era where vendors needed to cram whatever functionality they could onto a single CD-ROM because they only got one shot at reaching the end user; with the Internet, we don't need that anymore.
So, where should the Linux desktop really go? Here are some ideas:
The Linux desktop needs to do more than just be a better implementation of dated Windows/Macintosh ideas in order to succeed.
No, I think the Motif situation was actually somewhat better. As I recall, at least the people who made the UNIX workstations were part of the consortium that owned Motif. With Qt, you would be asking commercial backers of Linux to engage in marketing and support for the benefit of a company, Troll Tech, that they have no commercial interest in.
Really, the only problem anyone could have with Qt is that you have to pay for it if you do commercial development. This has never made it "unnattractive" however.
How would one be able to quantify that? $2000-$3000/year is more than many companies spend on hardware and software per developer. For many people, the evaluation probably stops right there. In the three corporate jobs I have had, that kind of per-developer license would have required enormous red tape to justify.
Think also of all the missed opportunities. Assuming for the sake of argument that Qt is actually a nice library, wouldn't it be great if lots of Windows developers used it even if they don't need cross-platform development? Then their software would run right away on Linux. Well, they won't do that at these prices.
And, assuming for the moment that KDE would win the Linux desktop, all of a sudden the cost for a commercial software developer on Linux goes from $0 to $2000+/year, all sent to a little company in Norway. Of course, the idea is so absurd that it is pretty clear that KDE cannot take over the Linux desktop as long as it is based on Qt: it will always be at most one of at least two major players, until Linux itself goes away.
[In any case, technically, I don't think Qt is where Linux GUIs should be going anyway.] Where should they be going? Do you not like KDE? Are there any Linux toolkits/GUIs that are going where you think they should?
I think KDE itself is a very good software engineering effort within the requirements it set for itself. It's what Windows NT and Windows 98 should have been.
But where are things going? I think more and more interfaces are built around documents, foremost HTML, XML, and DOM. That's true even for UI "screens" that are never transported through HTTP. It's both a look and an approach to programming. Foremost, it means that UIs aren't designed anymore by programmatically or visually placing widgets in particular locations. Instead, UIs are authored.
Sure, Troll Tech has invested money and time in KDE. I don't think that's altruism: the existence of KDE probably works out the equivalent of millions of dollars a year in advertising, testing, debugging, and product-related research for Troll Tech. Without KDE, I don't think Troll Tech would even be on the map. On the other hand, I think KDE would be just fine without Troll Tech/Qt: you can argue whether Gtk+ is better or worse than Qt, but they are pretty close, and there are several other reasonable C++ toolkits. Qt may have been a good initial catalyst and motivator for KDE, but I think the value of KDE greatly overshadows the value of Qt by now.
If not anything else, initially, KDE made contributions in lots of bug reports and feature requests; those are enormously valuable, in particular for a company with a new product and little resources for testing. Later, people in the KDE project also started donating code back to TrollTech, although I don't know whether that was before the GPL release or after (not that it matters).
It seems AT&T, NASA, Ford, IBM, and Intel, among others, disagree with you.
I have worked at three of those companies listed as references, and I have never heard of any products developed with Qt there. Often, we'd get listed by vendors if anybody ordered a copy to play around with. I think in that kind of list, even Tcl/Tk would win hands down in terms of customers and commercial products released.
[10 years ago, a C++ cross platform GUI library may have been a big deal, these days, they are a dime a dozen.] Please, complete the following, with toolkits that are as featureful and mature as Qt:
For cross platform development, depending on your requirements, wxWindows, FLTK, MFC/Win32 (with compatibility libraries on some platforms), Interviews, Gtk, Motif (with compatibility libraries on some platforms), Tcl/Tk, Swing, and Fox are all reasonable choices. If you want to argue that Qt is "more featureful" or "more mature", forget it. Each of those toolkits has advantages and disadvantages compared to other toolkits, and Qt isn't a clear winner.
[I also think it was a poor choice for the KDE project] Is there an argument behind this, or just the claim? Can this argument even be defended? Do you know if the requirements of the KDE project could be met by anyone else?
As the "I think" indicates, it's my opinion. Since I had more than a decade of GUI development under my belt around the time the KDE project started, I think I had a pretty good idea of what was out there at the time. I think the KDE developers didn't look hard enough and got snookered by a company with an agenda. Your opinion may be different, of course.
(I'm sorry if the flamethrower was on full-blast, but one thing I can't stand is groundless, unsubstantiated claims by zealots.)
You're as much a babe in the woods when it comes to flaming as when it comes to trusting software vendors. But let's get to substantiation: maybe you can get TrollTech to remove their false and misleading information about the GPL from their site.
Well, for one thing, they could stop misleading people about the meaning of the GPL. It is, in fact, perfectly fine to develop commercial/closed source software with a GPL'ed library under a number of circumstances, yet TrollTech keeps claiming otherwise.
I'd say the community has gained more than Trolltech has gained, however it's silly to argue about who had the greater benefit. In this case, everyone has won.
I think if a GUI library takes hold on Linux that requires payment to some vendor for any kind of commercial software development, as TrollTech claims for Qt, then Linux becomes a pretty unattractive platform for commercial developers. It also becomes an unattractive platform for people like IBM and Sun to support. Altogether, I think that would be a big loss for Linux: that situation would be worse than the situation we had with Motif on UNIX.
In any case, technically, I don't think Qt is where Linux GUIs should be going anyway. Qt is merely redoing in a slightly cleaner way where Microsoft was 5 years ago, and that style of GUI programming was outdated and cumbersome even back then.
An 1 year MSDN subscription is cheaper than a Qt developer license, and you get a lot more for your money in terms of tools, documentation, libraries, compilers, etc. What TrollTech is charging is more than many places spend on all their software and hardware combined per year.
Commercial cross-platform toolkits I have used in the past cost about as much as Qt, but they sure came with a lot more tools. In fact, as far as I am concerned, the only reason Qt is as nice as it is is because of the enormous contributions of the KDE project: without KDE, Qt would have been quickly forgotten.
Besides, the fact that some companies seem bent on charging a captive audience outrageous prices while floundering in the market doesn't mean that any cross-platform GUI library is worth that kind of money these days. 10 years ago, a C++ cross platform GUI library may have been a big deal, these days, they are a dime a dozen.
Nothing on Trolltech's pricing page indicates that you are limited to using the copy for one year. Rather, each copy is limited to one developer
Realistically, for commercial products, you need to get the annual maintenance: Microsoft and Apple keep rolling out new versions of their OS, and as a developer, you need to keep up.
If roughly $3000.00 USD for both *nix and WinXX is "too much" for your product's UI, I really have to question the business plan behind the product.
That's a lame argument. Commercial projects usually involve many developers, not just a single person. And if we are talking about small developers or consultants working on single projects, $2000-$4000/year is a lot of money.
Altogether, I don't think Qt is a good value for commercial projects. I also think it was a poor choice for the KDE project, and TrollTech has gotten a lot more out of KDE than they have given.
I suppose for the time being, the iMac wil still come with a CRT? That may be good enough for their low-end offerings. An iMac with a low-cost LCD would be kind of nice, though.
The IBM stuff probably failed because it was overpriced. There are other IR keyboards still on sale in many places.
In my book, for efficiency and compactness, the IBM Trackpoint is still the best way to go. It takes a while to become good at using it and feel comfortable with it (and many users give up before then), but once you are used to it, it's great. Note that the Trackpoint is different from the pointing sticks found on Toshiba machines and some other imitators; those are really awful.
On the one hand, we have graduate students from various universities, industrial and academic researchers, and industrial software developers. On the other hand, we have some nebulous people deep inside the bowels of some defense, medical, and aerospace contractors that have been writing "life-critical systems" for decades. The kind of people who managed to blow up the Osprey and the Ariane in software and punch holes into patients with radiation machines. They use and create low-volume, proprietary software with little or no peer review. A review of the kinds of blunders these professionals make shows that there are quite a few bad apples in the bunch and just leaves people scratching their heads. So, no, it isn't obvious to me that the "amateur" open source code is any worse in principle than the professional code.
Off-the-shelf Linux itself is probably not a good choice for "life-critical systems" because it wasn't developed with that goal in mind. I'd still trust it more than some of the supposedly "reliable" proprietary systems being sold. If you wanted to make Linux truly reliable, you would probably start by throwing out 90% of the drivers and other extensions and carry out a lot more additional code review and testing. In userland, you'd also limit yourself to a small set of very strictly tested tools.
More generally, however, given the same goals and the same resources for testing and development, I'd trust the open source community considerably more to develop reliable and safety critical systems than a bunch of proprietary professionals: I think the open source community has better people in it, and the open source process brings more resources to bear on code review and bug fixing.
The competition is in trouble by the 3rd iteration not because Microsoft gets it right, but because Microsoft has manipulated the market so that there isn't any other realistic commercial choice anymore. Office, DirectX, and Windows may look pretty good to you now because there is simply little or no commercial competition anymore.
As for WinCE, maybe people will be swayed by the powerful and nifty hardware that Microsoft specified. The OS itself and its UI are still lousy. Given how bulky and heavy the WinCE machines are still, I still don't see them succeeding.
The Palm platform has lots of shortcomings and limitations: poor resolution, slow processor, limited OS. But it still does the basics better than the commercial alternatives. Palm can still catch up. Judging by their track record, Microsoft will never figure it out; if they win this market, it will only be because all the competitors with better products self-destruct.
Until Palm comes out with new models that have compelling additional features over their current models, they will continue to have financial problems. What would be compelling?
In fact, I think their release of the M50x series and PalmOS 4 was a big mistake: it cost them lots of development time, they are in competition with the VisorEdge, and they are not compelling upgrades. They should have skipped that and instead pushed ahead forcefully on their new ARM platform and 32bit OS.