Without government setting up a detailed web of laws, rules, balances, and without government enforcement of those laws, rules, and balances, there would be no invisible hand or free market in which economic players, open source or otherwise could compete.
Government doesn't always get the rules and regulations right. Government is influenced by special interest lobbying, by bogus economic theories, and often, they just get it wrong. But a laissez-faire approach is throwing out the baby with the bathwater. In order to live in a prosperous, free market society, we need to get government to work properly.
Raymond could be correct in arguing that in the Microsoft case in particular, government action is not needed anymore, that other forces have already worked to reduce Microsoft's importance and influence. But it's false to base that argument on "the invisible hand"--for a market like the one Microsoft operates in, a monopoly is a very plausible outcome. If open source can, by itself, compete with Microsoft, it's because Microsoft has missed opportunity after opportunity, and it's because the goverment investigation has already restrained their behavior greatly (without it, PC companies would likely continue to be contractually prohibited from preloading anything other than Windows). But, in addition about ensuring a free market in PC software in the future, the law suit is as much about punishing past misbehavior (and discouraging others from engaging in it) as it is about addressing current failures of the market.
I should say, incidentally, that I don't view Microsoft as all evil. But they have done some things that no large company should be allowed to do in a free market, and it appears to me that they have, at least for the time being, a natural monopoly, something that requires some government supervision to ensure that the consumer isn't harmed, just like electricity and telephone.
Americans seem to love to hate law and government. A healthy distrust of government is probably always a good idea, but ultimately, there is no democracy or free market without the rule of law and a government to enforce it. A free market and "the invisible hand" work only under a specific set of social and economic parameters and government needs to create and maintain those parameters.
It's valuable to debate individual policies on their specific merits and effects, but general arguments that with less government regulation, the "invisible hand" will take care of things are not based in economic reality.
While the case was about as specific instance, I think it's indicative of a number of generally unacceptable business practices. Not all of them are related to bundling or tying.
It could probably be argued that this case should not form the basis for more general remedies, and legally that may be true. But I still believe that in order to be effective, some remedy other than breaking up the company needs to be used.
As for the effects of breaking the company up, since bundling has worked spectacularly so far, I see no reason why the Microsoft/OS and Microsoft/Office companies wouldn't collude to continue their current behavior: while the profits would get split up, their market dominance would remain. Sure, that's illegal, too, but it buys them another 5-10 years of litigation, and then probably some similarly ineffective remedy will be used. That kind of behavior can go on forever, with little financial consequence to the Microsoft companies and little change in their behavior. That's why I think something different is needed.
But actually I doubt that much of anything is going to happen: both political parties are very-corporate friendly these days, and while Microsoft's competitors don't like Microsoft's business practices, they like the thought that they might be next to be hauled into court for their anticompetitive practices even less. And there are plenty of other examples of anticompetitive practices.
Being broken up would probably be one of the better things to happen to Microsoft: the individual companies could work more independently, their "top management" could focus on just one market, their stock prices would soar, and they would still end up dominating each market and cooperating.
Something similar goes for the other often-discussed remedy, open sourcing Windows (without making it freely redistributable). That would simply entrench Microsoft software further.
Good remedies I can think of would be:
Supervise Microsoft's business and accounting practices and get them to agree explicitly not to make "precompetitive announcements". This worked for IBM (IBM is very cautious about product announcements even today because of past justice department investigations), and it ought to work for Microsoft.
Limit Microsoft's ability to manipulate earnings through creative accounting.
Prevent Microsoft from buying or investing in any other companies for the next five years. Microsoft has been buying up lots of companies that threatened to compete with them, limiting consumer choice and limiting the availability of technologies for other platforms.
Impose a stiff fine for their past misconduct, both to reimburse society for the financial losses and lack of innovationresulting from Microsoft's past misconduct and as a penalty; something of the order of Microsoft's cash reserves ($18b) would seem appropriate and would further limit their ability to engage in creative accounting and buy out competitors to extend their monopoly.
Microsoft has been squashing the competition not through better technologies but through misleading marketing and announcements, forcing unfavorable terms on others, and buying out competitors, a direct result of their market position. That conduct has denied consumers better technology and choice, and that conduct needs to be addressed directly.
About 80% of my mail is spam. And it is a problem, because with some regularity I miss messages that are important among the junk. And if you use automatic mail filters, you also risk losing messages.
If it is this bad already despite the obvious disapproval, imagine how bad it would get if this were approved of by everybody.
The problem with E-mail advertising is that the recipient pays almost all the cost: you pay for the ISP and if ISPs have to expand because of spam, that cost needs to be passed on to you. That provides an almost unlimited economic incentive for spam.
The commercial spam baffles me, though: companies just don't seem to get it. The more junk mail a company like CD-NOW sends me, the less likely I am ever going to buy from them again.
Most printed documentation I get with commercial software is useless: it's way too verbose, tries to document every feature, yet is remarkably useless for actually learning anything. Often, the reference manual seems derived automatically from the source code, and the user manual seems like it was written by technical writers with minimal understanding of the product for people with no understanding of computers. If you are going to produce anything like that--don't bother and save some trees.
Good examples of what I find useful are the O'Reilly "In A Nutshell" books, the O'Reilly main series, the "For Dummies", and the Waite Group's "How-To" books. Those generally present a lot of information, but in a logical, useful way. They do leave out less important detail. The on-line documentation should then document every last bit.
Well, there is a lot of snake oil that can be sold, but building a computer input device should really separate the wheat from the chaff: if it doesn't control the mouse or the airplane, people won't use it.
I think PEAR's claims are shaky and unlikely to be true. What "observation" means in QM is still an open question, but it seems unlikely that it is anything tied particularly to human perception (although early physicists seemed to think so). If IBM's funding will contribute to resolving this question, all the better.
I have used quite a number of digicams, including the Olympus D600L, Olympus C2000Z, the Nikon 950, several of the Fujis (MX2700 most recently), the Sony DSC-F505, and some of the older Kodaks.
I like SmartMedia much better than either CompactFlash or the Sony memory sticks. CF uses pins (which can bend easily) and is bulky. SmartMedia actually gives you more storage density, even if the individual chips hold a little less data. Sony's MemoryStick is not widely supported by third party manufacturers; what Sony gives you in terms of accessories is it, and if it doesn't work right (like their PCMCIA interface), you are stuck. Sony also can't decide on a form factor: there are three MemoryStick variants coming out, not all compatible.
I like the Olympus and Fuji cameras a lot. The Fujis are high quality, robust, and work very reliable. The Olympus cameras are somewhat quirkier but usually have more features. Both the Olympus C2000Z and the Nikon 950 (and later models apparently too) have some (to me) objectionable color artifacts. The Fuji MX2700 doesn't, but it doesn't have zoom. I don't particularly like the Kodaks: they are a bit bulky IMO. The Sony DSC-F505 has great quality, a great and versatile lens, and an nice form factor, but the LCD becomes unusable outdoors (and it uses the MemoryStick).
Watch out for fake resolution statements. Just like scanners, several manufacturers now overstate resolution because they perform software interpolation. The most notable offenders are Agfa (almost none of their cameras have the resolution they claim), and Fuji's latest MX4700 (which is a 2.2Mpixel camera, not a 4.7Mpixel camera).
Incidentally, a 2 megapixel camera really has only 2 million sensors, not 6 million, as you might think since it takes RGB pictures; the color information is interpolated. So, all the resolution claims are somewhat overblown, but they are comparably overblown. And the color interpolation is actually fairly harmless because of the way human color vision works--the greyscale resolution is pretty close to what they claim, it's just that the color information is a bit spread out (but you won't notice). And at least this is consistent among all cameras.
Altogether, I end up using the Fuji MX2700 most. It is small enough to carry everywhere, it's not too expensive, and it produces great pictures. It also has good battery lifetime (also very important).
Properly exposed, good 35mm film may have a resolution of 1000 lines per inch, but that's not the same as 2000 pixels: each pixels has an 8 or a 10 bit value; you need a lot of lines to get that kind of gradation in film. That's why a lot of people do medium format photography: even though MF probably doesn't have a lot more resolution than 35mm, the gradations of MF pictures are so much better. It's also why regular PhotoCD doesn't really bother to scan much more than that.
From a practical point of view, current cameras with 1600x1200 resolution are pretty close to what most people get out of 35mm; there are differences, but they are a toss-up--digital does actually do some things better. Once the resolution doubles or triples, there is little reason to go with 35mm.
Microsoft would like to demonstrate that their SQL server really can deal with large amounts of data. Never mind that serving up map data or astronomical images is not exactly what people who need high performance, high availability databases do. This will appeal more to the non-technical decision makers high up in the management chain ("see, they can serve big databases, let's put our customer database on MS SQL").
Maybe this is also going to be useful for the astronomy community. I would put more stake into a publically funded project that's supervised and implemented by astronomers and without any kind of commercial angle. Even today, though, I suspect that anybody who is interested in getting data can easily get it over the Internet, in the worst case by sending E-mail.
For static linking, yes, it's pretty simple what "using GPL components in your programs" means and how not to do it.
For dynamic linking, it isn't clear at all. I have understood RMS to have claimed in the past that if I distribute a program that is dynamically linked against a GPL'ed library, it falls under the GPL. (Once a binary compatible BSD-style library exists, then it doesn't, according to him.)
How is that related to API copyrights? It isn't quite the same as an API copyright, but it is pretty close, because it basically says that I must put code under the GPL merely because it uses an API that falls under the GPL; the fact that I don't actually distribute binaries derived from GPL'ed code doesn't exempt me.
"Don't use it" is, of course, the practical answer, but that's not the point. The point is that that the GPL seems to claim to be able to determine licensing for code that is connected to the GPL'ed software only through using its API; there is no copying or distribution of any GPL'ed code involved. And that's a dangerous precedent, I think.
Of course, RMS may simply be wrong on the dynamic linking issue. But the question isn't as simple as you make it.
Seems like no big deal: you get ads that are relevant to your interests, and programs you like go up in the ratings and stay on TV. What's wrong with that?
Well, several things. First of all, the goal of targetted advertising and television ratings is to sell you stuff. It isn't to challenge, educate, broaden horizons, or install a sense of community or civic duty. If someone is white supremacist survivalist, they are going to get a steady diet of gun commercials and right wing commentators, reinforcing their beliefs rather than educating them about alternative views. This subverts the medium of television even further than it already has been subverted.
But there are other concerns, too. In communist countries and Nazi Germany, people would get picked up and thrown in jail based on inferences about their ideology, derived from the flimsiest pieces of evidence: books they read, newspaper clippings they kept, remarks they made to friends.
Of course, something as blatant and crude as that doesn't seem like it's in the cards in the short term for the US (well, unless the religious right wins).
Things are likely to be much more subtle in the US. Data mining programs will make inferences from your viewing habits, possibly combined with your shopping habits, about lots of aspects of your life. Are you a home gardener or are you growing pot? How sexually active are you? What's your likelihood of developing heart disease? Are you a dangerous driver? Are you financially responsible?
This kind of data could be used to determine your insurance rates, credit worthiness, school admissions, job eligibility, propensity to engage in drug use or other criminal behavior, etc. To the insurance company, police, employer, or school, it's only statistical averages that matter: if you move to the top of their list, they'll make your life difficult. And for the individual, it will be difficult to prove that anything unusual has happened; in fact, this kind of analysis isn't illegal as long as it isn't used as a proxy for race.
There are massive personal data collections going on, and with good statistical techniques, anybody with the money to purchase the data will be able to get statistically excellent information on you. You can bet that this data won't just be used for targetted advertising: the economic incentives to use it for credit ratings, insurance, law enforcement/profiling, and employment are simply too strong. And you can also bet that if your are a bit unusual or excentric (and who on Slashdot isn't?), you'll pop out of those statistical models, either as a bad risk to be avoided, or as a likely suspect to be examined, even if your excentricities are completely harmless.
Allowing this kind of data collection to proceed is setting a dangerous precedent. I think the Europeans are right in essentially prohibiting any on-line data collection that isn't associated directly with a business transaction and requiring all data to be erased when the business transaction is over (airlines aren't even permitted to keep your meal preferences in their databases). Will the US have to learn the hard way to be careful when it comes to privacy?
The author can always license GPL'ed code under other licenses if he so chooses. In fact, some GPL'ed packages are also licensed commercially under a completely separate license. The author of some GPL'ed software can also decide to license later versions of his software only commercially, something which has also happened. The versions distributed under GPL, of course, continue to be redistributable under GPL.
The GPL indeed wants to claim rights to code that merely links with GPL'ed software. While I understand the desire to do so, I think this sets a dangerous precedent because, in essence, it creates a notion of "API copyrights".
If the GPL can claim this, Sun could claim that any code that "references" or "links with" their Java APIs should fall under their license, or Apple could claim that any code that "references" their OpenStep APIs should fall under their license. The POSIX organization might claim the same for the POSIX APIs, and Microsoft might claim it for Win32 (so much for Wine). There is also no reason why a license would stop at claiming "linking": if the "linking" reasoning applies, the expect or Perl script you write that is based on some licensed software might fall under its license merely for "using" the software if the license author writes that into their license.
So far, thankfully, companies generally seem to have been unable to successfully claim rights over APIs. Let's hope that GPL'ed software won't set a dangerous precedent in this area. If the GPL claims are valid, I think they call into question the foundation of much of free software, since much of it relies on using APIs that are non-free and could have onerous API license terms applied to it if the vendor so chooses and if this part of the GPL is found valid.
I'm not making an argument, I'm merely stating the way things are: historically, the.COM domain started out as a US domain, and right now it is administered under US jurisdiction, and US companies have no alternative. You may not like that and call it "crap", but that's the way it is.
Creating more TLDs within the current environment is not the solution. The solution is to make our DNS client software flexible enough so that users can pick which name resolution services they like, and to start creating more alternative name resolution services. In fact, that's already beginning to happen with the naming services incorporated into Netscape and IE, and more of that is likely going to happen at the DNS level.
There is no reason to wait for ICANN or any kind of government to get their act together on naming: naming is entirely by convention and up to whatever software you happen to run on your machine and what services you provide on the web.
The US may be culturally arrogant in many ways, but in this case you just got your history and facts wrong.
The US taxpayer paid for the development and initial deployment of the Internet (if.COM actually were a perk rather than a nuisance, that in itself would be ample justification)..COM and friends were US domains because there were no non-US domains at all. Today, US companies still don't have a choice:.COM is their top level domain; the.US domain serves different purposes.
It would have been nice if US companies could have moved to.CO.US or something like that when the Internet became more international, but that simply wasn't practical; after more than a decade of US.COM names, changing this would have made the lives of lots of people miserable. Besides, nobody could have foreseen the domain name craze of today, so it simply didn't seem to matter all that much.
Rather than complaining I'd suggest actually exercising some restraint: before you, wherever you may be, try to stake out your place in.COM land, keep in mind that you are really a guest in the US name space, and that by registering your domain in.COM, you may be causing problems for US folks who really don't have any other place to go.
Yes, the differences between Objective-C's object model and Java's are subtle but important. Until Java 1.1, Java was more limited. But with Java's reflection APIs, you can get pretty much the same behavior and generality you get in Objective-C.
Granted, it isn't quite as straightforward as Objective-C, since you are forced to define interfaces. I, too, would have preferred these features to be as straightforward in Java as in Objective-C. But you lose some and you win some: on balance, Java has runtime safety and Java's reflection API is more complete and better specified; on balance, I think that's not a bad tradeoff.
Incidentally, there are more dynamic distributed object systems for Java, including Sun's own JavaSpaces, as well as some of the XMLRPC implementations.
Incidentally, both JPython and Bistro give you a very Smalltalk/Objective-C like object model on top of the Java runtime. Bistro just uses reflection, which has significant overhead. JPython actually does a lot of analysis to make some method invocatinos faster. I believe it's possible to do even better and essentially support Smalltalk/Objective-C object semantics completely and portably in Java.
The other thing to keep in mind is that Sun, unlike Apple/NeXT, has publically stated that independent reimplementations of their software and APIs are fine with them (their battle with Microsoft is over trademarks and licensing terms, not the right to clone Java).
Why does this surprise anybody? Apple/NeXT had some of the first software patents, they sued other companies over "look and feel", and they never understood that they could have owned the personal computer industry if they actually had made their software more open and cross platform.
Rather than get involved with a company that clearly doesn't get it, why not help make the closest thing to OpenStep work better? A lot of the Java libraries are designed in the spirit of OpenStep and the Java imaging model is essentially PostScript. What Java needs is more efficient compilers; technically, if Java is compiled natively, there is no reason it should be any slower than Objective-C. Cygnus has made a great start on a native code Java compiler. It needs more help and more free libraries.
(Incidentally, the licensing paragraph in the OpenStep docs has been there for years, and I'm surprised nobody on the GNUstep project bothered to clear this with Apple/NeXT before they got started.)
Note that the free Qt license (QPL) only applies to the Linux version, not the Windows version, and only if you develop free software.
If you want to use Qt, be sure to read the license and the Troll Tech FAQ carefully.
As I interpret these, there are two important restrictions:
You must pay for licenses to the commercial version of Qt even if you only distribute your application internally inside your company.
You must pay for licenses to the commercial version of Qt before you start your project; if you start developing under the QPL, your software is automatically free software when distributed. (This is perhaps hard for Troll Tech to enforce, but then so are per-developer licenses.)
There are several other, good cross-platform C++ libraries out there, many of the cheaper than Qt, some free (see my other post). I recommend giving them serious consideration before investing much time and money in Qt.
I looked into this recently, and here are a bunch of suggestions/evaluations:
Java 1.2. Technically, I think this is by far the best choice: easy to program, robust, extensive built-in APIs, etc. But you need to somehow get a Java 1.2 runtime onto your clients machines, and it still isn't efficient enough for number crunching (if that's part of your application).
FLTK Small, cross-platform (Linux, Windows,...), straightforward C++ GUI toolkit. You can link your applications statically and they are still small enough to distribute. It includes a GUI builder. Good OpenGL support. Has its on look-and-feel. Versions 1.x still lack drag-and-drop and dynamic widget layout support.
wxWindows Very complete C++ GUI toolkit, cross platform between Linux, Windows, MacOS. Lots of widgets. Drag-and-drop support and dynamic layout. Uses platform look-and-feel. Very MFC-like, including the use of event tables for event routing. Steeper learning curve. GUI builder doesn't seem to be quite ready yet.
Qt Commercial toolkit. Pretty good quality. But you need an expensive, per-developer license unless you do open source. I don't think it's worth the money or hassle compared to wxWindows.
Willows Supoprts genuine Windows programming on Linux, in an open source environment. (I haven't looked much into how complete it is because I don't actually like genuine Windows programming:-)
GTK There is a Windows port as well as C++ bindings. I don't think the Windows port is far enough along yet for deployment, though.
Tcl/Tk The Tk toolkit comes with a scripting language you may not want, and, out of the box, it has a fairly limited widget set by modern standards. No drag-and-drop support. Multiple GUI builders. Great canvas class. Exceptionally easy to get started with, great for prototyping.
Fox Toolkit In may ways like FLTK. Has drag-and-drop support, but cross platform is still a promise.
Altogether, if you can deploy Java 1.2 and it's efficient enough for your needs (for most applications, it is), I'd go with that. If you need something in C++, I'd stick with wxWindows, FLTK, or Tcl/Tk, depending on your specific needs and preferences. I think you may also want to reconsider whether you really want an IDE and GUI builder; I find writing GUIs by hand in toolkits that are set up for it is ultimately faster and easier.
Protecting one's copyright may not be censorship, but banning software that could be used for protecting one's copyright is censorship.
Gnutella may be primarily used for copyright infringement, but where do you draw the line? IRC isn't all that different from Gnutella and it also makes it easy to exchange copyrighted data. What about FTP and web servers? Web browsers?
Another problem with your argument is that it leads to limitations on fair use. It is perfectly legitimate for me to convert my CDs into MP3s, carry them on my laptop or with a portable player. But the new legislation along the lines you propose already in place have restricted the utility of devices and stifled innovation. For example, many MP3 players would make nifty portable, USB-attached drives. But because of recently enacted laws, thsoe devices need to be hobbled so that they can only play back MP3s and not be used for data storage.
Software and software-based devices are very malleable. I think if you start banning software that, right now, looks like it might be used primarily for infringement, you end up infringing on the rights of legitimate licensees and you severly restrict innovation. And that is a David-vs.-Goliath issue, because the big, established companies dislike the new technologies, not because of copyright infringement, but because they break their long-standing business models. And that should be of concern to everybody.
I don't see any benefit in breaking up Microsoft or opening up their source code. Both of those would only send the Microsoft stock price up further and lead to an even wider dissemination of their software.
The problem with Microsoft is their predatory release and licensing practices. They seem to release software too early, with incomplete specifications, and keep a bunch of APIs for their own internal uses. This is what gives them an edge over their competitors in terms of time to market and apparent functionality, and it also accounts for the low quality of their software.
This is no different from a manufacturer of physical devices cutting corners in product design and safety features. This allows them to cut costs and get to market faster, but at the expense of the consumer. Taken to its extreme, the savings accrued from such poor practices may well allow a manufacturer to dominate the market.
The solution I see is fairly simple, and quite analogous in both cases: the government needs to require specifications of software and create liabilities if the software doesn't comply. This is simply realizing that an order transaction in any form requires contractual agreements and the possibility of enforcement when there are violations, and in the case of software, contractual agreements are "specifications".
It's no coincidence that Microsoft has steadfastly resisted efforts to standardize or document their APIs. And their argument is correct: it would "slow down innovation" (i.e., their release cycle). But the point is that we don't want Microsoft (or any other company) to release software as fast as possible without any other considerations.
This solution, of course, is wholly unpalatable to software companies. You mean that we ought to be required to specify in advance what our software does and be held liable if it doesn't comply? How dare the government get involved in innovation and software practice in that way?
But this seems like a logical next step to me. The government (foremost, Republicans) has not at all been squeamish about imposing regulations on all sorts of formerly free-wheeling aspects of the computer industry and cyberspace: the enormous expansion of copyright law and fields of patentability, the criminalization of previously innocuous behavior on the Internet, content filtering, etc. Those kinds of regulations will have very uncertain consequences for innovation. In comparison, imposing some simple product safety and contractual requirements on the software industry seems like a small and logical step.
I think requiring companies to provide specifications of their software and make them contractually enforceable is generally a good idea for the software industry as a whole. Sun should be held to similar standards for Java, IBM for their software, etc.
But, right now, ideas along these lines would even be sufficient as remedies in the Microsoft case. For example, Microsoft could be required to create standards-quality specifications of the Win32, COM, and ActiveX APIs, as well as the VisualBasic programming language and the IE browser, and to be liable for compliance with their specifications. That, rather than opening the source code, would benefit the industry, level the playing field, and benefit Windows users. Yes, it would result in delays and lots of additional expenses to Microsoft, but that's, after all, the point: cutting corners in these areas is what has allowed Microsoft to dominate the market in the first place.
When Microsoft and the government talk about "open source", they most likely don't mean that people can recompile it and redistribute modified versions.
What they mean is that users and developers can obtain the code to discover hidden APIs. It could possibly also mean that competitors could license and re-sell modified versions of Windows under "fair" conditions, meaning with some revenue for Microsoft.
No matter what it means, as a rememdy, I think any opening of the Windows source code would be bad. The problem with Windows is not that the source code is closed, it is that Windows is unreliable, poorly specified, and uses non-standard APIs that some hackers at Microsoft dreamed up one night. Opening its source code would simply entrench it further and cause software vendors to start relying on even more obscure behaviors inside it.
Sure you can run Word and Solitaire in web pages in numerous ways. But my point is that you should rewrite applications to take advantage of the new open, non-proprietary, multi-vendor web technologies. I know: it's an expensive short term proposition, but it's the economically rational thing to do in the long term.
Sure I read his comment. My point (perhaps subtle) is that Wyse has lots of ways of building thin clients, many of which have nothing to do with RDP/ICA. If they have problems with Linux for their purposes, it's not because they have problems building "thin clients" out of Linux, it's because they have problems building RDP/ICA clients based on Linux.
That appears to be not a technical shortcoming of Linux but a shortcoming of the various licensing schemes involved in the proprietary protocols and the limitations of the ICA clients. The difference matters because open source can fix technical shortcomings, but we can't fix licensing problems of some proprietary windowing protocol, not even by implementing something better.
Slashdot Mirror
Government doesn't always get the rules and regulations right. Government is influenced by special interest lobbying, by bogus economic theories, and often, they just get it wrong. But a laissez-faire approach is throwing out the baby with the bathwater. In order to live in a prosperous, free market society, we need to get government to work properly.
Raymond could be correct in arguing that in the Microsoft case in particular, government action is not needed anymore, that other forces have already worked to reduce Microsoft's importance and influence. But it's false to base that argument on "the invisible hand"--for a market like the one Microsoft operates in, a monopoly is a very plausible outcome. If open source can, by itself, compete with Microsoft, it's because Microsoft has missed opportunity after opportunity, and it's because the goverment investigation has already restrained their behavior greatly (without it, PC companies would likely continue to be contractually prohibited from preloading anything other than Windows). But, in addition about ensuring a free market in PC software in the future, the law suit is as much about punishing past misbehavior (and discouraging others from engaging in it) as it is about addressing current failures of the market.
I should say, incidentally, that I don't view Microsoft as all evil. But they have done some things that no large company should be allowed to do in a free market, and it appears to me that they have, at least for the time being, a natural monopoly, something that requires some government supervision to ensure that the consumer isn't harmed, just like electricity and telephone.
Americans seem to love to hate law and government. A healthy distrust of government is probably always a good idea, but ultimately, there is no democracy or free market without the rule of law and a government to enforce it. A free market and "the invisible hand" work only under a specific set of social and economic parameters and government needs to create and maintain those parameters.
It's valuable to debate individual policies on their specific merits and effects, but general arguments that with less government regulation, the "invisible hand" will take care of things are not based in economic reality.
It could probably be argued that this case should not form the basis for more general remedies, and legally that may be true. But I still believe that in order to be effective, some remedy other than breaking up the company needs to be used.
As for the effects of breaking the company up, since bundling has worked spectacularly so far, I see no reason why the Microsoft/OS and Microsoft/Office companies wouldn't collude to continue their current behavior: while the profits would get split up, their market dominance would remain. Sure, that's illegal, too, but it buys them another 5-10 years of litigation, and then probably some similarly ineffective remedy will be used. That kind of behavior can go on forever, with little financial consequence to the Microsoft companies and little change in their behavior. That's why I think something different is needed.
But actually I doubt that much of anything is going to happen: both political parties are very-corporate friendly these days, and while Microsoft's competitors don't like Microsoft's business practices, they like the thought that they might be next to be hauled into court for their anticompetitive practices even less. And there are plenty of other examples of anticompetitive practices.
Something similar goes for the other often-discussed remedy, open sourcing Windows (without making it freely redistributable). That would simply entrench Microsoft software further.
Good remedies I can think of would be:
Microsoft has been squashing the competition not through better technologies but through misleading marketing and announcements, forcing unfavorable terms on others, and buying out competitors, a direct result of their market position. That conduct has denied consumers better technology and choice, and that conduct needs to be addressed directly.
If it is this bad already despite the obvious disapproval, imagine how bad it would get if this were approved of by everybody.
The problem with E-mail advertising is that the recipient pays almost all the cost: you pay for the ISP and if ISPs have to expand because of spam, that cost needs to be passed on to you. That provides an almost unlimited economic incentive for spam.
The commercial spam baffles me, though: companies just don't seem to get it. The more junk mail a company like CD-NOW sends me, the less likely I am ever going to buy from them again.
Good examples of what I find useful are the O'Reilly "In A Nutshell" books, the O'Reilly main series, the "For Dummies", and the Waite Group's "How-To" books. Those generally present a lot of information, but in a logical, useful way. They do leave out less important detail. The on-line documentation should then document every last bit.
I think PEAR's claims are shaky and unlikely to be true. What "observation" means in QM is still an open question, but it seems unlikely that it is anything tied particularly to human perception (although early physicists seemed to think so). If IBM's funding will contribute to resolving this question, all the better.
I like SmartMedia much better than either CompactFlash or the Sony memory sticks. CF uses pins (which can bend easily) and is bulky. SmartMedia actually gives you more storage density, even if the individual chips hold a little less data. Sony's MemoryStick is not widely supported by third party manufacturers; what Sony gives you in terms of accessories is it, and if it doesn't work right (like their PCMCIA interface), you are stuck. Sony also can't decide on a form factor: there are three MemoryStick variants coming out, not all compatible.
I like the Olympus and Fuji cameras a lot. The Fujis are high quality, robust, and work very reliable. The Olympus cameras are somewhat quirkier but usually have more features. Both the Olympus C2000Z and the Nikon 950 (and later models apparently too) have some (to me) objectionable color artifacts. The Fuji MX2700 doesn't, but it doesn't have zoom. I don't particularly like the Kodaks: they are a bit bulky IMO. The Sony DSC-F505 has great quality, a great and versatile lens, and an nice form factor, but the LCD becomes unusable outdoors (and it uses the MemoryStick).
Watch out for fake resolution statements. Just like scanners, several manufacturers now overstate resolution because they perform software interpolation. The most notable offenders are Agfa (almost none of their cameras have the resolution they claim), and Fuji's latest MX4700 (which is a 2.2Mpixel camera, not a 4.7Mpixel camera).
Incidentally, a 2 megapixel camera really has only 2 million sensors, not 6 million, as you might think since it takes RGB pictures; the color information is interpolated. So, all the resolution claims are somewhat overblown, but they are comparably overblown. And the color interpolation is actually fairly harmless because of the way human color vision works--the greyscale resolution is pretty close to what they claim, it's just that the color information is a bit spread out (but you won't notice). And at least this is consistent among all cameras.
Altogether, I end up using the Fuji MX2700 most. It is small enough to carry everywhere, it's not too expensive, and it produces great pictures. It also has good battery lifetime (also very important).
From a practical point of view, current cameras with 1600x1200 resolution are pretty close to what most people get out of 35mm; there are differences, but they are a toss-up--digital does actually do some things better. Once the resolution doubles or triples, there is little reason to go with 35mm.
Maybe this is also going to be useful for the astronomy community. I would put more stake into a publically funded project that's supervised and implemented by astronomers and without any kind of commercial angle. Even today, though, I suspect that anybody who is interested in getting data can easily get it over the Internet, in the worst case by sending E-mail.
For dynamic linking, it isn't clear at all. I have understood RMS to have claimed in the past that if I distribute a program that is dynamically linked against a GPL'ed library, it falls under the GPL. (Once a binary compatible BSD-style library exists, then it doesn't, according to him.)
How is that related to API copyrights? It isn't quite the same as an API copyright, but it is pretty close, because it basically says that I must put code under the GPL merely because it uses an API that falls under the GPL; the fact that I don't actually distribute binaries derived from GPL'ed code doesn't exempt me.
"Don't use it" is, of course, the practical answer, but that's not the point. The point is that that the GPL seems to claim to be able to determine licensing for code that is connected to the GPL'ed software only through using its API; there is no copying or distribution of any GPL'ed code involved. And that's a dangerous precedent, I think.
Of course, RMS may simply be wrong on the dynamic linking issue. But the question isn't as simple as you make it.
Well, several things. First of all, the goal of targetted advertising and television ratings is to sell you stuff. It isn't to challenge, educate, broaden horizons, or install a sense of community or civic duty. If someone is white supremacist survivalist, they are going to get a steady diet of gun commercials and right wing commentators, reinforcing their beliefs rather than educating them about alternative views. This subverts the medium of television even further than it already has been subverted.
But there are other concerns, too. In communist countries and Nazi Germany, people would get picked up and thrown in jail based on inferences about their ideology, derived from the flimsiest pieces of evidence: books they read, newspaper clippings they kept, remarks they made to friends.
Of course, something as blatant and crude as that doesn't seem like it's in the cards in the short term for the US (well, unless the religious right wins).
Things are likely to be much more subtle in the US. Data mining programs will make inferences from your viewing habits, possibly combined with your shopping habits, about lots of aspects of your life. Are you a home gardener or are you growing pot? How sexually active are you? What's your likelihood of developing heart disease? Are you a dangerous driver? Are you financially responsible?
This kind of data could be used to determine your insurance rates, credit worthiness, school admissions, job eligibility, propensity to engage in drug use or other criminal behavior, etc. To the insurance company, police, employer, or school, it's only statistical averages that matter: if you move to the top of their list, they'll make your life difficult. And for the individual, it will be difficult to prove that anything unusual has happened; in fact, this kind of analysis isn't illegal as long as it isn't used as a proxy for race.
There are massive personal data collections going on, and with good statistical techniques, anybody with the money to purchase the data will be able to get statistically excellent information on you. You can bet that this data won't just be used for targetted advertising: the economic incentives to use it for credit ratings, insurance, law enforcement/profiling, and employment are simply too strong. And you can also bet that if your are a bit unusual or excentric (and who on Slashdot isn't?), you'll pop out of those statistical models, either as a bad risk to be avoided, or as a likely suspect to be examined, even if your excentricities are completely harmless.
Allowing this kind of data collection to proceed is setting a dangerous precedent. I think the Europeans are right in essentially prohibiting any on-line data collection that isn't associated directly with a business transaction and requiring all data to be erased when the business transaction is over (airlines aren't even permitted to keep your meal preferences in their databases). Will the US have to learn the hard way to be careful when it comes to privacy?
The author can always license GPL'ed code under other licenses if he so chooses. In fact, some GPL'ed packages are also licensed commercially under a completely separate license. The author of some GPL'ed software can also decide to license later versions of his software only commercially, something which has also happened. The versions distributed under GPL, of course, continue to be redistributable under GPL.
If the GPL can claim this, Sun could claim that any code that "references" or "links with" their Java APIs should fall under their license, or Apple could claim that any code that "references" their OpenStep APIs should fall under their license. The POSIX organization might claim the same for the POSIX APIs, and Microsoft might claim it for Win32 (so much for Wine). There is also no reason why a license would stop at claiming "linking": if the "linking" reasoning applies, the expect or Perl script you write that is based on some licensed software might fall under its license merely for "using" the software if the license author writes that into their license.
So far, thankfully, companies generally seem to have been unable to successfully claim rights over APIs. Let's hope that GPL'ed software won't set a dangerous precedent in this area. If the GPL claims are valid, I think they call into question the foundation of much of free software, since much of it relies on using APIs that are non-free and could have onerous API license terms applied to it if the vendor so chooses and if this part of the GPL is found valid.
Isn't it ironic that in an attempt at insulting another software company, MS engineers demonstrate how unprofessional they themselves are?
Creating more TLDs within the current environment is not the solution. The solution is to make our DNS client software flexible enough so that users can pick which name resolution services they like, and to start creating more alternative name resolution services. In fact, that's already beginning to happen with the naming services incorporated into Netscape and IE, and more of that is likely going to happen at the DNS level.
There is no reason to wait for ICANN or any kind of government to get their act together on naming: naming is entirely by convention and up to whatever software you happen to run on your machine and what services you provide on the web.
The US taxpayer paid for the development and initial deployment of the Internet (if .COM actually were a perk rather than a nuisance, that in itself would be ample justification). .COM and friends were US domains because there were no non-US domains at all. Today, US companies still don't have a choice: .COM is their top level domain; the .US domain serves different purposes.
It would have been nice if US companies could have moved to .CO.US or something like that when the Internet became more international, but that simply wasn't practical; after more than a decade of US .COM names, changing this would have made the lives of lots of people miserable. Besides, nobody could have foreseen the domain name craze of today, so it simply didn't seem to matter all that much.
Rather than complaining I'd suggest actually exercising some restraint: before you, wherever you may be, try to stake out your place in .COM land, keep in mind that you are really a guest in the US name space, and that by registering your domain in .COM, you may be causing problems for US folks who really don't have any other place to go.
Granted, it isn't quite as straightforward as Objective-C, since you are forced to define interfaces. I, too, would have preferred these features to be as straightforward in Java as in Objective-C. But you lose some and you win some: on balance, Java has runtime safety and Java's reflection API is more complete and better specified; on balance, I think that's not a bad tradeoff.
Incidentally, there are more dynamic distributed object systems for Java, including Sun's own JavaSpaces, as well as some of the XMLRPC implementations.
Incidentally, both JPython and Bistro give you a very Smalltalk/Objective-C like object model on top of the Java runtime. Bistro just uses reflection, which has significant overhead. JPython actually does a lot of analysis to make some method invocatinos faster. I believe it's possible to do even better and essentially support Smalltalk/Objective-C object semantics completely and portably in Java.
The other thing to keep in mind is that Sun, unlike Apple/NeXT, has publically stated that independent reimplementations of their software and APIs are fine with them (their battle with Microsoft is over trademarks and licensing terms, not the right to clone Java).
Rather than get involved with a company that clearly doesn't get it, why not help make the closest thing to OpenStep work better? A lot of the Java libraries are designed in the spirit of OpenStep and the Java imaging model is essentially PostScript. What Java needs is more efficient compilers; technically, if Java is compiled natively, there is no reason it should be any slower than Objective-C. Cygnus has made a great start on a native code Java compiler. It needs more help and more free libraries.
(Incidentally, the licensing paragraph in the OpenStep docs has been there for years, and I'm surprised nobody on the GNUstep project bothered to clear this with Apple/NeXT before they got started.)
If you want to use Qt, be sure to read the license and the Troll Tech FAQ carefully.
As I interpret these, there are two important restrictions:
There are several other, good cross-platform C++ libraries out there, many of the cheaper than Qt, some free (see my other post). I recommend giving them serious consideration before investing much time and money in Qt.
Altogether, if you can deploy Java 1.2 and it's efficient enough for your needs (for most applications, it is), I'd go with that. If you need something in C++, I'd stick with wxWindows, FLTK, or Tcl/Tk, depending on your specific needs and preferences. I think you may also want to reconsider whether you really want an IDE and GUI builder; I find writing GUIs by hand in toolkits that are set up for it is ultimately faster and easier.
Gnutella may be primarily used for copyright infringement, but where do you draw the line? IRC isn't all that different from Gnutella and it also makes it easy to exchange copyrighted data. What about FTP and web servers? Web browsers?
Another problem with your argument is that it leads to limitations on fair use. It is perfectly legitimate for me to convert my CDs into MP3s, carry them on my laptop or with a portable player. But the new legislation along the lines you propose already in place have restricted the utility of devices and stifled innovation. For example, many MP3 players would make nifty portable, USB-attached drives. But because of recently enacted laws, thsoe devices need to be hobbled so that they can only play back MP3s and not be used for data storage.
Software and software-based devices are very malleable. I think if you start banning software that, right now, looks like it might be used primarily for infringement, you end up infringing on the rights of legitimate licensees and you severly restrict innovation. And that is a David-vs.-Goliath issue, because the big, established companies dislike the new technologies, not because of copyright infringement, but because they break their long-standing business models. And that should be of concern to everybody.
The problem with Microsoft is their predatory release and licensing practices. They seem to release software too early, with incomplete specifications, and keep a bunch of APIs for their own internal uses. This is what gives them an edge over their competitors in terms of time to market and apparent functionality, and it also accounts for the low quality of their software.
This is no different from a manufacturer of physical devices cutting corners in product design and safety features. This allows them to cut costs and get to market faster, but at the expense of the consumer. Taken to its extreme, the savings accrued from such poor practices may well allow a manufacturer to dominate the market.
The solution I see is fairly simple, and quite analogous in both cases: the government needs to require specifications of software and create liabilities if the software doesn't comply. This is simply realizing that an order transaction in any form requires contractual agreements and the possibility of enforcement when there are violations, and in the case of software, contractual agreements are "specifications".
It's no coincidence that Microsoft has steadfastly resisted efforts to standardize or document their APIs. And their argument is correct: it would "slow down innovation" (i.e., their release cycle). But the point is that we don't want Microsoft (or any other company) to release software as fast as possible without any other considerations.
This solution, of course, is wholly unpalatable to software companies. You mean that we ought to be required to specify in advance what our software does and be held liable if it doesn't comply? How dare the government get involved in innovation and software practice in that way?
But this seems like a logical next step to me. The government (foremost, Republicans) has not at all been squeamish about imposing regulations on all sorts of formerly free-wheeling aspects of the computer industry and cyberspace: the enormous expansion of copyright law and fields of patentability, the criminalization of previously innocuous behavior on the Internet, content filtering, etc. Those kinds of regulations will have very uncertain consequences for innovation. In comparison, imposing some simple product safety and contractual requirements on the software industry seems like a small and logical step.
I think requiring companies to provide specifications of their software and make them contractually enforceable is generally a good idea for the software industry as a whole. Sun should be held to similar standards for Java, IBM for their software, etc.
But, right now, ideas along these lines would even be sufficient as remedies in the Microsoft case. For example, Microsoft could be required to create standards-quality specifications of the Win32, COM, and ActiveX APIs, as well as the VisualBasic programming language and the IE browser, and to be liable for compliance with their specifications. That, rather than opening the source code, would benefit the industry, level the playing field, and benefit Windows users. Yes, it would result in delays and lots of additional expenses to Microsoft, but that's, after all, the point: cutting corners in these areas is what has allowed Microsoft to dominate the market in the first place.
What they mean is that users and developers can obtain the code to discover hidden APIs. It could possibly also mean that competitors could license and re-sell modified versions of Windows under "fair" conditions, meaning with some revenue for Microsoft.
No matter what it means, as a rememdy, I think any opening of the Windows source code would be bad. The problem with Windows is not that the source code is closed, it is that Windows is unreliable, poorly specified, and uses non-standard APIs that some hackers at Microsoft dreamed up one night. Opening its source code would simply entrench it further and cause software vendors to start relying on even more obscure behaviors inside it.
Sure you can run Word and Solitaire in web pages in numerous ways. But my point is that you should rewrite applications to take advantage of the new open, non-proprietary, multi-vendor web technologies. I know: it's an expensive short term proposition, but it's the economically rational thing to do in the long term.
That appears to be not a technical shortcoming of Linux but a shortcoming of the various licensing schemes involved in the proprietary protocols and the limitations of the ICA clients. The difference matters because open source can fix technical shortcomings, but we can't fix licensing problems of some proprietary windowing protocol, not even by implementing something better.