It is because software is supposed to bend to the will of the user, not the other way around.
But guess what! 99% of the target customers out there do or will want to do business differently!
If you just give people the software, it is too hard for the user to bend it to their will, because it has 100 times the bulk that the user is ready to manage. This is why you have to sell people software prebent to their wills. And if you're charging 6 figures for the software, you'd better do the work of figuring out what the user's will is, and bending the software for them.
The right idea is to add the support to the core routines, but sell separately the bit that enables it. That way people who have no need for the feature don't get it (and those who do need it pay extra...). Ideally, business software vendors have professional services teams, who will sell you a product that does what you want and nothing else (by modifying the build to turn on only those things you want).
We're talking about a platform implementation, not the standard. The standard will surely remain Sun's property. The "Java" trademark will also remain Sun's, and Sun will retain the right to dictate how it is used.
The Sun v. MicroSoft case was based on MS shipping a "Java" environment which did not follow the standard to Sun's satisfaction. The copyright on the environment was never in question: it belonged to MicroSoft.
If there's a GPL Java environment, you can only call it "Java(tm)" if it has not been changed such that it fails to follow the standard. This would most likely mean that extensions remain internal to a given project, or are reference implementations or research for proposed modifications to the standard, etc.; on the other hand, you're perfectly free to port it to a different platform, change implementation details, add your new optimization, and so forth. You could also change things that the standard leaves to the implementation to decide (like command-line options to the tools).
Ah, that's different from the soundtracks I tend to see, which is what I assumed you meant. But the ones I tend to see (at least, the good ones) are "unified, cohesive works"; it's just that the arrangement wasn't done by the people who wrote or played the songs (My favorite examples are The Crow and Pi, each of which is mostly songs not written for the movie, but each of which was assembled artfully).
All you can really expect is to have the software yourself. Hopefully, that's worth it. If you're lucky, the software will reflect more work than you put into it, and you'll have the satisfaction of using a tool you are primarily responsible for that's better than what you could have done alone.
Things you swallow aren't as dangerous as things you inject, because your digestive tract helps somewhat to avoid overdosing, both by failing to absorb excessive amounts of a particular substance and by inducing vomitting in extreme cases.
That paper suggests that the lethal dose of heroin is actually high enough that you can't buy it accidentally, and that "overdose" deaths are largely caused by mixing with other drugs, either impurities in the substance or taken separately (like alcohol).
The thing with tolerance is that if you do a drug frequently, it gets less effective, because your body adjusts to expect and counteract the effects. So you need a higher dose to get the same effect. The conventional wisdom is that the margin between the effective dose and the lethal dose of heroin will get small enough that a slight error will push you over. The paper says that's not true, and that the window remains large, and the actual overdose effects are rarely seen in "overdose" victems.
Is the paper accurate? I'd be inclined to believe it; things that nearly kill you are rarely enjoyable. It's much more likely that something similar to something enjoyable will kill you or some combination of things which are fun by themselves are bad together.
The chain of causation goes back not to the substance but to the form. Snorting anything makes it hit very quickly and very hard. If you were to drink a beverage containing cocaine, it wouldn't affect you for a little while, since it would have to be absorbed from your stomach, put in your bloodstream, and brought to your brain. If you were to snort powdered caffeine, it would hit in two heartbeats and extremely hard, because it enters your bloodstream in your brain through mucous membranes.
Caffeine and cocaine are similarly addictive (actually, caffeine is probably the substance to which most Americans are addicted); snorting stimulants is more addictive, because you get a higher dose faster, and more dangerous, because it is not mediated by your digestive tract.
People don't snort lines of caffeine because it's much easier to get in drinks and safer that way. People don't make coca-leaf tea in America because it's not cost-effective, given the legal risks. On the other hand, mate de coca is considered a nice breakfast drink in the Andes, great for altitude sickness and much less likely than coffee to make you a nervous wreck.
It's all a matter of legality, marketting, and fashion.
Soundtracks shouldn't count because they're compilations of individual songs. If anything, soundtracks demonstrate that artists don't do a good job of arranging their own work (aside from the occasional soundtrack by a single artist). If the people who arrange soundtracks can do so much better at it than the artists that half of your collection is that way, the results are probably much better if people get individual songs and compile them into playlists themselves.
Cocaine is actually pretty similar in danger to caffeine, except that it is usually found in the US in a purified form. If you got caffeine in a similar form, it would probably kill you. Most cultures use one stimulant and prohibit others; it's pretty random that ours picks caffeine as good and cocaine as bad.
MDMA is quite safe: the main danger is that it encourages activity and suppresses thirst. If you take it at an all-night party without a lot of non-diuretic drinks, you can easily cause severe dehydration. It also causes a temporary burnout if you don't take an SSRI with it. If you try to take it frequently, it has no effect, and taking more than the appropriate dose doesn't matter.
Cannabis makes you think unclearly. If you spend too much time thinking unclearly, you can learn to do so all the time. It is therefore about as bad for you as listening to presidential addresses.
I'm not familiar with what is necessary for safe use of heroine. Most likely, a trained anaesthesiologist.
Things on fire cause cancer and burns; snorting and injecting things makes it easy to surpass the safe dosage (which is much harder to do by ingesting things).
Most controlled substances don't really require more responsibility than legal ones. Of course, street drugs are more dangerous than packaged ones, due to concentration and impurity, and street drug administration methods are more dangerous than using your stomach. Some controlled substances will impair driving, but plenty of OTC drugs do, too, and in worse ways.
Frequently, if a bug never got reported in an old version, it didn't get fixed, and it's still present in the new version (unless the project has taken to rewriting the whole thing frequently). If a bug has been reported in the old version and fixed in the latest version, you can frequently determine this, because you have access to the bug reports and mailing list archives. So you know if upgrading will fix your problem.
It's also possible that you get can and apply a patch that solves your problem. I've done this when I was having a problem with the latest (at the time) release of JBoss that had a fix proposed. I got the source to the version I was using before, patched it with the patch from the mailing list, built it, and it worked fine. Try doing that with a closed-source product.
If IBM thought the case had any merit, they'd buy SCO on the off chance that the contract SCO recently signed with MicroSoft will allow SCO (or whoever ends up with their assets) to revoke MicroSoft's right to sell software, like SCO seems to think their contract with IBM allows. Personally, I'm glad I'm not a customer of any company with a contract with SCO.
I never thought I'd see Forbes calling a company that's been #8 or better on the Forbes 500 as far back as Forbes has it online a bunch of crunchies.
Sure, they're the biggest and most experienced computer company around today, but what do they know? They'll lose a contract/IP case to a totally insignificant company, because that company managed to win an anti-trust case against MicroSoft (like everybody else has).
What is the world coming to, when Forbes actually expects someone with less money to get somewhere?
SCO's approach doesn't seem at all particular to Linux. They say that Linus could not determine whether the code he was importing was, in fact, SCO's property. But MicroSoft's product managers can't determine whether the code they import is SCO's property, and SCO's product managers can't determine whether the code they import is my property. Their scare tactics apply somewhat to Linux, but just as much to any other copyrightable work. There's no way for the RIAA or the MPAA to determine whether their products violate my copyrights, for the simple reason that copyrighted works don't have to be registered with anyone.
Of course, SCO hasn't in any official way claimed that Linux violates copyrights they hold, or tried to hold Linus or anyone else on the receiving end responsible; if they did, they'd be opening themselves up to a class action lawsuit by any interested copyright holder on the same legal principle. It wouldn't stand up in court on either side, but SCO's pockets are far less deep than the whole rest of the world.
I don't see any particular reason that mathematical truths shouldn't be patentable, except that they wouldn't make particularly useful patents, since there isn't exactly any way to "use" them in the right sense for the restriction. Unless, of course, they are algorithms. Sure, they're discovered, but so is everything else. The functionality of a steam engine was no less true in 1776 than it is now, but nobody knew to do that then, just like RSA would have worked in 1776 if anyone had tried it. There is no real fundamental difference between algorithms and devices, as has become clear in these days when mechanical devices are being replaced first with digital circuits and then with software for an embedded computer.
There are plenty of problems with the patent system (largely concerning the vast quantity of patent applications and awarded patents overwhelming patent offices and inventors; the intent of the system is that every inventor read every patent applicable to the field, but this is impossible, and the patents aren't even available for a long time), but this isn't really one of them (except that people getting software patents tend to be sleazier than the average).
If SCO wins, free software doesn't lose credibility as a development model. Software loses credibility as a business. Remember that they're also claiming that users of AIX are in violation of their copyright now. If they win, all use of software may be considered risky. What's to stop Windows from turning out to be a derivative of some unfriendly copyright holder, who then goes on to destroy the business world, which relies on it, entirely?
If they win, it will be on the basis of a more substantial sort of derivation than they've shown, and only against IBM, who knew as much as SCO about the ownership of the code.
If they lose, it won't be on the basis of copyright in general being invalid, which is what the GPL depends on. It will be based on limits on what constitutes a derivative work, which will potentially limit the reach of the GPL, but only in ways that everyone except RMS thinks is reasonable (RMS claims that code which can use a GPL library, even if it doesn't include any of the library, and even if the library could be legally reimplemented (and, perhaps, has been), is a derivative work; everyone else thinks he's nuts, because the library isn't actually necessary to produce the work, just to use it).
Construction projects are largely limited by budgets, not by work to do. The 13 people who don't get paid to repair this bridge will get paid to repair 6 other bridges instead (except for one whose salary goes to buying these things).
I'm oversimplifying, of course; some of the people switch to pouring new concrete, because it would be a really bad idea to demolish roadways 7 times faster then you repave them. But new technology doesn't eliminate jobs; it just changes them. Not that people aren't right to be unhappy with it, since the new jobs often require retraining. On the other hand, the new jobs also frequently are more skilled and pay more.
If you can't get bought by IBM, at least you can forfeit all your assets to them. That's sort of similar, isn't it?
Of course, this greatly reduces the chance that MicroSoft would buy out SCO's assets and liabilities.
Personally, I think SCO's executives are just trying to keep getting paid as long as possible. The real question is whether they've done anything that they're personally liable for so far, which would matter a whole lot more.
This would actually be a good feature of online publications. There is already often support for feedback. It would be worthwhile to add support for verified responses from the entities discussed (possibly leading off-site, so that if MS complains about you, and someone complains about MS, it's MS's responsibility to handle the second complaint).
If you think about it, "reply" is what most publications actually most frequently want, and the offended party is generally not forthcoming. You always see "(Company) was not available for comment", and whenever you hear about a GPL violation, people eagerly await the violator's response. For all of these SCO stories, my first thought is "What does SCO have to say about that?"
The hard part, of course, is accurately identifying the party with the right to reply, since it would be bad to accept somebody else's comments instead of the actual party involved.
Considering that you're doing this on a relatively sophisticated firewall, have it hit different connections at different times, depending on when you don't expect those sorts of connections.
For that matter, losing a connection is generally not that big a deal, and tends to happen anyway. If something is actually attended, the person will notice and restart it without losing much.
It's also worth pointing out that it doesn't matter all that much whether your movie is rendered in real time or not, since it takes so long to build the models and all that. Additional processor power is actually much more useful for supporting the artists working on the movie, not for producing the finished result.
By your calculation, this cluster could render 2 hours of CGI in a weekend, which makes the final render not an issue; you can start it Friday evening and have it ready when people get back on Monday. The real issue is getting all of the models designed and tweaked to look just right, and all of the rendering necessary to let the animators see what they're doing.
It's ironic. If you drive to Cape Cod, the first thing you see when you cross the Sagamore Bridge is: a huge windmill. If anything, you'd think these people would *want* to have some more windmills around.
On the other hand, the picture doesn't look like some windmills; it looks like a huge graveyard. I can understand not wanting a wind farm that looks like that. But it should be a small technical and artistic feat to build a wind farm that doesn't look out-of-place, given that you're in an area with a great tradition in wind power. If they stuck hulls on the bottoms of those, people would look out at the faux clipper-ships on the horizon and be perfectly happy. After all, one thing that the pilgrims did see when they landed was a sailing ship.
When dealing with nimbyism, a bit of art can go a long way.
Note that Red Hat currently has a number of "Enterprise" versions, of which one is "AS", but all of which seem to be Oracle-approved. In fact, Oracle recommends "WS" as the cost-effective "Advanced Server" for developers, and it's quite reasonably priced (as far as software for businesses goes).
What PNG does best is screenshots. There's no point in using Flash, because it's a static image, the color depth is 24-bit, so you can't use GIF, and the image isn't photographic, and you care about noise, so you don't want JPEG. This leaves PNG. If you want a screenshot of a powerpoint slide (with an even, non-dithered background gradient and more than 256 colors total), PNG is the only way to make it look good.
OSS doesn't stop paid software development. It both enables and requires paid software development to be more advanced. Provided that the business recognizes the significance of free software and arranges to take advantage of it in the ways its licenses permit, the existance of a free program means that developers of other programs can skip to the next problem. Even where a free program isn't used by a company, it competes on features with commercial programs and prompts more commercial development to stay viable, which leads to more programmers working on the commercial program.
It's not like there's some amount of software functionality that is the what the market wants, and free software, as it reaches toward that goal, diminishes the space of software which people are willing to pay for. There is, rather, some amount of money people are willing to pay, and they want to get the most out of that they can. The free portion is the baseline, and people will pay for functionality beyond that.
Slashdot Mirror
It is because software is supposed to bend to the will of the user, not the other way around.
But guess what! 99% of the target customers out there do or will want to do business differently!
If you just give people the software, it is too hard for the user to bend it to their will, because it has 100 times the bulk that the user is ready to manage. This is why you have to sell people software prebent to their wills. And if you're charging 6 figures for the software, you'd better do the work of figuring out what the user's will is, and bending the software for them.
The right idea is to add the support to the core routines, but sell separately the bit that enables it. That way people who have no need for the feature don't get it (and those who do need it pay extra...). Ideally, business software vendors have professional services teams, who will sell you a product that does what you want and nothing else (by modifying the build to turn on only those things you want).
We're talking about a platform implementation, not the standard. The standard will surely remain Sun's property. The "Java" trademark will also remain Sun's, and Sun will retain the right to dictate how it is used.
The Sun v. MicroSoft case was based on MS shipping a "Java" environment which did not follow the standard to Sun's satisfaction. The copyright on the environment was never in question: it belonged to MicroSoft.
If there's a GPL Java environment, you can only call it "Java(tm)" if it has not been changed such that it fails to follow the standard. This would most likely mean that extensions remain internal to a given project, or are reference implementations or research for proposed modifications to the standard, etc.; on the other hand, you're perfectly free to port it to a different platform, change implementation details, add your new optimization, and so forth. You could also change things that the standard leaves to the implementation to decide (like command-line options to the tools).
Ah, that's different from the soundtracks I tend to see, which is what I assumed you meant. But the ones I tend to see (at least, the good ones) are "unified, cohesive works"; it's just that the arrangement wasn't done by the people who wrote or played the songs (My favorite examples are The Crow and Pi, each of which is mostly songs not written for the movie, but each of which was assembled artfully).
All you can really expect is to have the software yourself. Hopefully, that's worth it. If you're lucky, the software will reflect more work than you put into it, and you'll have the satisfaction of using a tool you are primarily responsible for that's better than what you could have done alone.
Just surround your house with toxic waste. That'll take care of them pretty quickly.
Things you swallow aren't as dangerous as things you inject, because your digestive tract helps somewhat to avoid overdosing, both by failing to absorb excessive amounts of a particular substance and by inducing vomitting in extreme cases.
That paper suggests that the lethal dose of heroin is actually high enough that you can't buy it accidentally, and that "overdose" deaths are largely caused by mixing with other drugs, either impurities in the substance or taken separately (like alcohol).
The thing with tolerance is that if you do a drug frequently, it gets less effective, because your body adjusts to expect and counteract the effects. So you need a higher dose to get the same effect. The conventional wisdom is that the margin between the effective dose and the lethal dose of heroin will get small enough that a slight error will push you over. The paper says that's not true, and that the window remains large, and the actual overdose effects are rarely seen in "overdose" victems.
Is the paper accurate? I'd be inclined to believe it; things that nearly kill you are rarely enjoyable. It's much more likely that something similar to something enjoyable will kill you or some combination of things which are fun by themselves are bad together.
The chain of causation goes back not to the substance but to the form. Snorting anything makes it hit very quickly and very hard. If you were to drink a beverage containing cocaine, it wouldn't affect you for a little while, since it would have to be absorbed from your stomach, put in your bloodstream, and brought to your brain. If you were to snort powdered caffeine, it would hit in two heartbeats and extremely hard, because it enters your bloodstream in your brain through mucous membranes.
Caffeine and cocaine are similarly addictive (actually, caffeine is probably the substance to which most Americans are addicted); snorting stimulants is more addictive, because you get a higher dose faster, and more dangerous, because it is not mediated by your digestive tract.
People don't snort lines of caffeine because it's much easier to get in drinks and safer that way. People don't make coca-leaf tea in America because it's not cost-effective, given the legal risks. On the other hand, mate de coca is considered a nice breakfast drink in the Andes, great for altitude sickness and much less likely than coffee to make you a nervous wreck.
It's all a matter of legality, marketting, and fashion.
Soundtracks shouldn't count because they're compilations of individual songs. If anything, soundtracks demonstrate that artists don't do a good job of arranging their own work (aside from the occasional soundtrack by a single artist). If the people who arrange soundtracks can do so much better at it than the artists that half of your collection is that way, the results are probably much better if people get individual songs and compile them into playlists themselves.
Cocaine is actually pretty similar in danger to caffeine, except that it is usually found in the US in a purified form. If you got caffeine in a similar form, it would probably kill you. Most cultures use one stimulant and prohibit others; it's pretty random that ours picks caffeine as good and cocaine as bad.
MDMA is quite safe: the main danger is that it encourages activity and suppresses thirst. If you take it at an all-night party without a lot of non-diuretic drinks, you can easily cause severe dehydration. It also causes a temporary burnout if you don't take an SSRI with it. If you try to take it frequently, it has no effect, and taking more than the appropriate dose doesn't matter.
Cannabis makes you think unclearly. If you spend too much time thinking unclearly, you can learn to do so all the time. It is therefore about as bad for you as listening to presidential addresses.
I'm not familiar with what is necessary for safe use of heroine. Most likely, a trained anaesthesiologist.
Things on fire cause cancer and burns; snorting and injecting things makes it easy to surpass the safe dosage (which is much harder to do by ingesting things).
Most controlled substances don't really require more responsibility than legal ones. Of course, street drugs are more dangerous than packaged ones, due to concentration and impurity, and street drug administration methods are more dangerous than using your stomach. Some controlled substances will impair driving, but plenty of OTC drugs do, too, and in worse ways.
Frequently, if a bug never got reported in an old version, it didn't get fixed, and it's still present in the new version (unless the project has taken to rewriting the whole thing frequently). If a bug has been reported in the old version and fixed in the latest version, you can frequently determine this, because you have access to the bug reports and mailing list archives. So you know if upgrading will fix your problem.
It's also possible that you get can and apply a patch that solves your problem. I've done this when I was having a problem with the latest (at the time) release of JBoss that had a fix proposed. I got the source to the version I was using before, patched it with the patch from the mailing list, built it, and it worked fine. Try doing that with a closed-source product.
If IBM thought the case had any merit, they'd buy SCO on the off chance that the contract SCO recently signed with MicroSoft will allow SCO (or whoever ends up with their assets) to revoke MicroSoft's right to sell software, like SCO seems to think their contract with IBM allows. Personally, I'm glad I'm not a customer of any company with a contract with SCO.
I never thought I'd see Forbes calling a company that's been #8 or better on the Forbes 500 as far back as Forbes has it online a bunch of crunchies.
Sure, they're the biggest and most experienced computer company around today, but what do they know? They'll lose a contract/IP case to a totally insignificant company, because that company managed to win an anti-trust case against MicroSoft (like everybody else has).
What is the world coming to, when Forbes actually expects someone with less money to get somewhere?
SCO's approach doesn't seem at all particular to Linux. They say that Linus could not determine whether the code he was importing was, in fact, SCO's property. But MicroSoft's product managers can't determine whether the code they import is SCO's property, and SCO's product managers can't determine whether the code they import is my property. Their scare tactics apply somewhat to Linux, but just as much to any other copyrightable work. There's no way for the RIAA or the MPAA to determine whether their products violate my copyrights, for the simple reason that copyrighted works don't have to be registered with anyone.
Of course, SCO hasn't in any official way claimed that Linux violates copyrights they hold, or tried to hold Linus or anyone else on the receiving end responsible; if they did, they'd be opening themselves up to a class action lawsuit by any interested copyright holder on the same legal principle. It wouldn't stand up in court on either side, but SCO's pockets are far less deep than the whole rest of the world.
I don't see any particular reason that mathematical truths shouldn't be patentable, except that they wouldn't make particularly useful patents, since there isn't exactly any way to "use" them in the right sense for the restriction. Unless, of course, they are algorithms. Sure, they're discovered, but so is everything else. The functionality of a steam engine was no less true in 1776 than it is now, but nobody knew to do that then, just like RSA would have worked in 1776 if anyone had tried it. There is no real fundamental difference between algorithms and devices, as has become clear in these days when mechanical devices are being replaced first with digital circuits and then with software for an embedded computer.
There are plenty of problems with the patent system (largely concerning the vast quantity of patent applications and awarded patents overwhelming patent offices and inventors; the intent of the system is that every inventor read every patent applicable to the field, but this is impossible, and the patents aren't even available for a long time), but this isn't really one of them (except that people getting software patents tend to be sleazier than the average).
If SCO wins, free software doesn't lose credibility as a development model. Software loses credibility as a business. Remember that they're also claiming that users of AIX are in violation of their copyright now. If they win, all use of software may be considered risky. What's to stop Windows from turning out to be a derivative of some unfriendly copyright holder, who then goes on to destroy the business world, which relies on it, entirely?
If they win, it will be on the basis of a more substantial sort of derivation than they've shown, and only against IBM, who knew as much as SCO about the ownership of the code.
If they lose, it won't be on the basis of copyright in general being invalid, which is what the GPL depends on. It will be based on limits on what constitutes a derivative work, which will potentially limit the reach of the GPL, but only in ways that everyone except RMS thinks is reasonable (RMS claims that code which can use a GPL library, even if it doesn't include any of the library, and even if the library could be legally reimplemented (and, perhaps, has been), is a derivative work; everyone else thinks he's nuts, because the library isn't actually necessary to produce the work, just to use it).
Construction projects are largely limited by budgets, not by work to do. The 13 people who don't get paid to repair this bridge will get paid to repair 6 other bridges instead (except for one whose salary goes to buying these things).
I'm oversimplifying, of course; some of the people switch to pouring new concrete, because it would be a really bad idea to demolish roadways 7 times faster then you repave them. But new technology doesn't eliminate jobs; it just changes them. Not that people aren't right to be unhappy with it, since the new jobs often require retraining. On the other hand, the new jobs also frequently are more skilled and pay more.
If you can't get bought by IBM, at least you can forfeit all your assets to them. That's sort of similar, isn't it?
Of course, this greatly reduces the chance that MicroSoft would buy out SCO's assets and liabilities.
Personally, I think SCO's executives are just trying to keep getting paid as long as possible. The real question is whether they've done anything that they're personally liable for so far, which would matter a whole lot more.
This would actually be a good feature of online publications. There is already often support for feedback. It would be worthwhile to add support for verified responses from the entities discussed (possibly leading off-site, so that if MS complains about you, and someone complains about MS, it's MS's responsibility to handle the second complaint).
If you think about it, "reply" is what most publications actually most frequently want, and the offended party is generally not forthcoming. You always see "(Company) was not available for comment", and whenever you hear about a GPL violation, people eagerly await the violator's response. For all of these SCO stories, my first thought is "What does SCO have to say about that?"
The hard part, of course, is accurately identifying the party with the right to reply, since it would be bad to accept somebody else's comments instead of the actual party involved.
Considering that you're doing this on a relatively sophisticated firewall, have it hit different connections at different times, depending on when you don't expect those sorts of connections.
For that matter, losing a connection is generally not that big a deal, and tends to happen anyway. If something is actually attended, the person will notice and restart it without losing much.
It's also worth pointing out that it doesn't matter all that much whether your movie is rendered in real time or not, since it takes so long to build the models and all that. Additional processor power is actually much more useful for supporting the artists working on the movie, not for producing the finished result.
By your calculation, this cluster could render 2 hours of CGI in a weekend, which makes the final render not an issue; you can start it Friday evening and have it ready when people get back on Monday. The real issue is getting all of the models designed and tweaked to look just right, and all of the rendering necessary to let the animators see what they're doing.
It's ironic. If you drive to Cape Cod, the first thing you see when you cross the Sagamore Bridge is: a huge windmill. If anything, you'd think these people would *want* to have some more windmills around.
On the other hand, the picture doesn't look like some windmills; it looks like a huge graveyard. I can understand not wanting a wind farm that looks like that. But it should be a small technical and artistic feat to build a wind farm that doesn't look out-of-place, given that you're in an area with a great tradition in wind power. If they stuck hulls on the bottoms of those, people would look out at the faux clipper-ships on the horizon and be perfectly happy. After all, one thing that the pilgrims did see when they landed was a sailing ship.
When dealing with nimbyism, a bit of art can go a long way.
Note that Red Hat currently has a number of "Enterprise" versions, of which one is "AS", but all of which seem to be Oracle-approved. In fact, Oracle recommends "WS" as the cost-effective "Advanced Server" for developers, and it's quite reasonably priced (as far as software for businesses goes).
What PNG does best is screenshots. There's no point in using Flash, because it's a static image, the color depth is 24-bit, so you can't use GIF, and the image isn't photographic, and you care about noise, so you don't want JPEG. This leaves PNG. If you want a screenshot of a powerpoint slide (with an even, non-dithered background gradient and more than 256 colors total), PNG is the only way to make it look good.
OSS doesn't stop paid software development. It both enables and requires paid software development to be more advanced. Provided that the business recognizes the significance of free software and arranges to take advantage of it in the ways its licenses permit, the existance of a free program means that developers of other programs can skip to the next problem. Even where a free program isn't used by a company, it competes on features with commercial programs and prompts more commercial development to stay viable, which leads to more programmers working on the commercial program.
It's not like there's some amount of software functionality that is the what the market wants, and free software, as it reaches toward that goal, diminishes the space of software which people are willing to pay for. There is, rather, some amount of money people are willing to pay, and they want to get the most out of that they can. The free portion is the baseline, and people will pay for functionality beyond that.