The biggest advantage of a 64 bit processor is the increased memory space. Intel makes processors, not memory. The last thing that they want is a computer where Dell spends more on memory than processor.
Ease of use is only one small part of the picture. That is why Microsoft outsold the Macintosh even before Windows came out. No one in their right mind would tell you that DOS + Wordperfect + Lotus 1 2 3 was easier to use than the comparable Macintosh software, but this wacky combination of OS and applications outsold Apple's best by an order of magnitude. The Apples were easy to use, but the DOS-based solution was good enough at a far lower price.
When push comes to shove it is all about being good enough at the lowest price. Currently, for most folks anyway, part of being "good enough" is being able to share software and documents with the large Windows using crowd. This requirement puts Linux at a serious disadvantage. However, marketshare is a pretty flimsy protection (ask Novell, Lotus, and the original makers of WordPerfect).
The secret is that it is not the idea (or the API in this case) but rather the implementation that gets copyrighted. You copyright the source code and the binary is a derivative work (lots of precedence here). The API can either be reverse engineered, or in the case of readline it isn't even protected.
So you create your own library libedit. The source might be similar to readline, but similar is fine in this case. Just like there are lots of books that are similar to Lord of the Rings. Your binary is a derivative of your library (not of readline), it just happens to do the same thing. You are free and clear.
On the other hand, you build an application that links with readline. The binaries you create are clearly a derivative of readline (for the same reason that your binaries compiled against libedit were derivatives of libedit). If you distribute this binary then you are distributing a derivative of someone else's work. Now, you could distribute the source for your work and have the end user build it himself, that's a much harder reach as a derivative (there are precedents, however). On the other hand, if you are going to distribute source you might as well license your software under the GPL.
You see, that's the real trick. People distributing closed software want to distribute binaries.
If the program is designed to share a memory space with the library, and does not run without it then the binaries that you compile that dynamically link to the library are clearly a derivative work (according the definition the FSF and the rest of the software industry uses). You can't distribute these binaries that are a derivative work without the permission of the original copyright holder. The end user's actions have nothing do with it.
Now if you wrote a proxy for the library that would be a different matter. However, you had probably better remove the bits where it links the library anyhow. After all, the fact that a proxy exists might not be enough of a buffer. It's like the rules that accountants use for deciding whether a tax deduction is legal. The rule of thumb is that if you believe you have a one in three chance of winning in court then you can take the deduction. The question is whether or not you believe that you can make your point in court, with the ownership of your proprietary code and all the revenues you have made from it (plus damages) hanging in the balance. Not to mention the fact that the very fine lawyers at the FSF will be on the other side of the bench. Will you be able to afford someone who has argued in front of the Supreme Court? The FSF might even get help from the major software producers (and possibly Hollywood) who want to guarantee that no bad copyright precedents are set.
Feeling lucky, punk?
Now, if you want to argue about how copyrights, should be, that's another story. I am simply telling you how they are.
Believe what you want, when Eben Moglen calls you'll either hand over the source or you'll write your proxy application and you'll be glad that the FSF doesn't make examples of companies that change their ways.
The Kylix Open Edition ships with CLX(TM) libraries under the GPL license.
As such, any applications that are built with a CLX library must make their sources freely available and distribute them under the terms of the GPL license as well. For example, any application built with the Kylix Open Edition must link to the BaseCLX(TM) library and will therefore be bound to the GPL. Furthermore, the Open Edition IDE End User License Agreement (EULA) also requires that any software developed with Kylix Open Edition must be released to the general public under the terms of the GPL. Any other use of Kylix Open Edition IDE would be in legal violation of the license agreement.
A little searching will undoubtedly produce others. Basically if the FSF is imagining the bounds of copyright then it is a consensual hallucination with a lot of participants.
Once again, read the licenses of the libraries that you are linking against. You will probably be surprised. The fact of the matter is that the software industry has worked like this forever. You simply haven't paid any attention to software licenses before.
The fact of the matter is that if you base your work on a commercial license you are invariably putting yourself at risk. The company could disappear, they could change their licensing terms, etc. The fact that your program is a derivative work (legal, in this case that you paid for your library) doesn't really change the equation. When you use someone else's proprietary license you are literally at their mercy.
If they share the same memory space then your program is a derivative work. If they communicate in some other way then you are fine. That's "mere aggregation."
There are plenty of folks that thought that their product wasn't a derivative work if they simply pointed people to the download of the GPL library. In the end all of them either released their source or wrote a small GPL wrapper around the library that communicated with their program via some other method than a shared address space (and even that may not be a protection in some cases according to the FSF).
The point that you are missing is that it doesn't matter who downloads what when. If your program doesn't work without the GPL library linked in then it is a derivative work, at least according to the FSF.
Yes, something like that. Read the licenses on some of the commercial libraries you use. If you think that the GPL is shocking, you should see what Microsoft, Borland, and some of the rest have to say.
I don't know of a precedent for this sort of a interpretation, but I am not Eben Moglen either. Not that it matters. Since there is little to gain and a lot to lose by testing these legal waters it isn't likely that we will get someone stupid enough to actually set a legal precedent. That is why people comply when Eben Moglen calls them on the phone. The only reasonable way to act is as if a legal precedent had been set. After all, you don't want to become the precedent.
That's why I always laugh at GPL detractors who point out what they consider to be legal problems with the GPL. The detractors might be right, but no one is likely to take their word for it.
Personally I agree that if they can fingerprint copyrighted material on their network they should do something about it. I do not agree that there are no legal uses for the bandwidth that colleges provide. If there are no legal uses for the bandwidth that colleges provide then they should just shut the network down and be done with it.
I actually have read Title 17, and I am afraid that I will have to agree with the legal folks at the FSF (and every major software company). Not that it matters what I think. As you have pointed out only a fool would go to court against the FSF on this issue. If the FSF is right about what constitues a derivative work in software then the offending company's software would essentially become property of the FSF and they would have to release the source code to this software to all of their customers (plus any monetary penalties). In short, it would be instant death. Even releasing the source code to your crown jewels is probably a better alternative.
Big Corp A would be crazy to base their proprietary software on GPLed code because anytime between now and whenever the copyright wears out on said code the FSF can come and wreck their party. And the FSF can even wait until after it has found an easier target to be the legal precedent.
So you can pretend that the GPL is on shaky ground when it comes to linking, but you can bet that your legal department isn't likely to advise you to press the issue. If Mr Moglen called your company you would cave, just as everyone else has. So think what you want, for all practical purposes the FSF is right as rain on this issue.
Your "so-called" imposition on third parties, on the other hand, is just pure hogwash. It doesn't matter where I get the copyrighted work, if I try and distribute it I have to get the permission of the copyright holder. Without that permission I can't distribute the work. There is no third party. The only way to get permission to distribute GPLed code is to make source code available.
Which brings us to your last point, where you talk about the GPL restricting the "use" of software. I am perfectly free to download a GPLed library and link my own personal programs against it, as long as I don't distribute my derivative work to someone else. In short, I am free to "use" the software how I wish (including linking), I just can't distribute the GPLed software, or its derivative works, without the permission of the copyright holder. As long as you don't distribute the software the GPL has absolutely no hold you.
The folks at the FSF explain it much better than I could here. Long story short you don't link against "Windows" it is a separate program.
Let's imagine that you took one of Steven King's novels and wrote an alternative ending. Could you legally distribute that and tell your customers to go and purchase Steven King's book if you want to read the first part of the story. Of course not. Creating a program that requires an external library is a similar type deal.
Now if your program communicates with a separate GPLed program via pipes (or other methods) that's a totally different story. Read the FAQ, it should clear things up.
I write an application called FooEdit, which dynamically links to a GPLed library called libfoo. I distribute FooEdit under some closed license, requiring my users to get their own copy of libfoo. Have I done wrong? If I understand your post correctly, then you believe that the FSF does not really have a case against me.
If you write an application that links (dynamically or statically it doesn't matter) with a GPLed library then you must distribute your application under the GPL (assuming you distribute your application). This doesn't "lock" the interface or the API because you are perfectly free to create your own replacement for libfoo (called libbar, of course). Example: libedit is a replacement for readline.
What I get from this interview is that the FSF does think it has such a case. The question I'd like to see answered is how it would go about enforcing it. In distributing FooEdit, I haven't agreed to the terms of the GPL, so they would have no choice but to go after me for copyright infringement. In order to gain any traction they would have to argue that my use of libfoo's API constitutes copyright infringement.
If your application doesn't work without libfoo then it is clearly a derivative work of libfoo. You are infringing on the copyright not because you used the libfoo API, but because you created and distributed a derivative work without the permission of the copyright holder.
Is the FSF willing to argue that point in a court of law? Or are they just blowing hot air and hoping to scare people into licensing their applications under the GPL?
Here's a little secret. The reason that the GPL has never been tried in court is not because the GPL is on shaky ground, but rather because it is on such firm ground that only an idiot would want to get up in front of a judge and become a precedent. First of all, all of the major software houses rely on copyright to protect their own intellectual property.
Take the large software development firms, for example. The last thing that IBM or Microsoft would want is a legal precedent that weakened copyright. So count out the large software houses as potential GPL litigators. This explains why there is not a single major software company that hasn't responded, and responded quickly, to perceived GPL violations. Even Microsoft distributes GPLed software, strange as that may seem.
So that leaves the small-time developers. Now imagine your local software consulting firm paying for the lawyer fees that would arise from butting heads with the likes of Moglen or Lessig. The FSF has access to excellent lawyers, and in a copyright case the FSF could even push for the reward of heavy damages. So not only would the small consulting firm be faced with large legal bills, but they would also be faced with the possibility of losing their own copyrighted works (since they would be a derivative of the FSF's works), and paying a hefty fine.
It's no wonder that a case hasn't gone to court. Especially since the FSF is happy to forgive you if you simply make the source code available to your customers (note, you don't have to make the source available to the whole world).
And the FSF almost certainly would win the court case anyhow. You see, they were very careful to make sure that the GPL relied on the "distribution" of the software as the key to their license. Under normal copyright terms the end user is denied the right to distribute copyright material without permission of the copyright holder. The GPL simply points out the terms under which the original copyright holder is willing to allow you to distribute their work. Either the end user accepts the GPL, or they don't have permission to distribute the software (or its derivatives). The end user can still use the software, but that's it.
Another example of a GPLed library is QT. This allows developers to use QT if they are willing to let their software fall under the GPL. If you want to use QT in a commercial product you must pay money for a commercial (non-GPL) license.
As for your belief that GPLing a library is an attempt to lock the *interface*, that's blatantly false. As proof of this take a look at libedit. It's goal is to be 100% API compatible with readline, but with a BSD-style license.
The FSF argues that there is little reason to GPL a library that is a reimplementation of a commercial library (ie glibc), because if you did that no one would use the GPLed library. However, if your library has new and interesting features that aren't found in a commercial library then the GPL makes sense. People will want to use the library in their own programs (because of the features), but they will need to release their software under the GPL to be able to use it. There are several examples (ncftp using readline being the prime example) where this has actually been the case.
Are you kidding? I already have a desktop for firebreathing horsepower stuff. A wireless card in this bad boy would give me a portable X terminal for use all around my house, and I could still take the thing with me and fire up Emacs when I am on the road. I think this laptop sounds very cool.
Heck, when it comes to laptops the only app that I am really worried about being able to use is Emacs. I am actually glad when I see the manufacturer skimping on the video card.
Yes, software that links with a GPLed library needs to be released under the GPL. However, most of the libraries on a typical GNU/Linux box are LGPLed, and not GPLed. Readline is the prime example of a widely used GNU library that is released under the GPL.
Microsoft loses quite a bit of money on every XBox sold. Microsoft's only reason for creating the XBox is to sell XBox games. The last thing Microsoft wants to do is make it possible for Sony to make money selling PSX games to XBox owners.
And how is this different from real life? My goodness, a game where money, prestige, status and experience expand the opportunities for advancement. That's practically revolutionary! The funny thing about being at the top, is that you have nowhere to go but down (and lots of folks gunning for your position). In fact, that's basically politics in a nutshell.
And how do you get people and businesses to move? Simple, tax them like crazy. In short, this is a perfect way to encourage businesses to migrate away from the more congested areas.
What does this example have to do with anything? In all of your examples overtime is simply a method where the slow, unproductive, and troubled get paid extra to do the same amount of work (as long as they stick around the office while they are being slow, unproductive, and troubled).
On the flip side, let's say that my wife is sick and I would like to go home early to give her a hand with the kids. As a salaried worker I can leave early without losing money. As long as I get my job done to my employer's satisfaction I can be far more flexible with my time. If my employer is unhappy with my performance he can hire one of the "100 guys standing in line to get a job." Likewise, if I am unhappy with the hours that my employer is asking me work I am free to try and find another job.
Quite frankly, unless you happen to have a job as a security guard or something where the primary component of your pay is your physical presence then it simply doesn't make sense to get paid simply by the amount of hours that you spend in the office. My employer doesn't really care where I get my job done, as long as it gets done. Yes, sometimes that means that I have long days, but sometimes it means that I get to go home early.
Actually, now that there are two implementation of Python (CPython and Jython), I think that I would have to disagree with you about the single implementation problem. Besides, from where I am sitting standardization has been the death knell for every language that has ever gone through the process. Standardization certainly didn't help Lisp, and standardization has actually delayed adoption of important parts of C++ (as folks waited for them to become standard).
As long as the language in question has a good (and portable) Free Software implementation why should I care about what some wacky standards body says?
Yes, you are probably right. I probably was a little harsh. However, the whole point of the article was that, in the name of progress, geeks keep messing up perfectly good systems. If you have spent a great deal of time and effort learning an interface, even a poor one, the last thing that you need is some dumb shmuck making a totally new interface.
As a concrete example take vi. Vi is still widely popular despite the fact that it's interface is so non-intuitive that the first time I used it I had to turn off my Linux box to get it to go away. The reason that vi is popular despite it's horrifically non-intuitive interface is that once you learn vi's interface you can get your job done a heck of a lot faster than someone who has to take their hands off the keyboard to use the mouse. I have a buddy that can hack faster drunk than any two other coders because he literally thinks in vi macros. You give my buddy any other IDE, no matter how intuitive, and you will almost certainly hurt his ability to get things done.
The problem isn't that these journalists are too stupid to learn the new systems. The problem is that they don't want to have to learn another system. They want to hang onto their old interface, the one they already know how to use.
Slashdot Mirror
The biggest advantage of a 64 bit processor is the increased memory space. Intel makes processors, not memory. The last thing that they want is a computer where Dell spends more on memory than processor.
Ease of use is only one small part of the picture. That is why Microsoft outsold the Macintosh even before Windows came out. No one in their right mind would tell you that DOS + Wordperfect + Lotus 1 2 3 was easier to use than the comparable Macintosh software, but this wacky combination of OS and applications outsold Apple's best by an order of magnitude. The Apples were easy to use, but the DOS-based solution was good enough at a far lower price.
When push comes to shove it is all about being good enough at the lowest price. Currently, for most folks anyway, part of being "good enough" is being able to share software and documents with the large Windows using crowd. This requirement puts Linux at a serious disadvantage. However, marketshare is a pretty flimsy protection (ask Novell, Lotus, and the original makers of WordPerfect).
The secret is that it is not the idea (or the API in this case) but rather the implementation that gets copyrighted. You copyright the source code and the binary is a derivative work (lots of precedence here). The API can either be reverse engineered, or in the case of readline it isn't even protected.
So you create your own library libedit. The source might be similar to readline, but similar is fine in this case. Just like there are lots of books that are similar to Lord of the Rings. Your binary is a derivative of your library (not of readline), it just happens to do the same thing. You are free and clear.
On the other hand, you build an application that links with readline. The binaries you create are clearly a derivative of readline (for the same reason that your binaries compiled against libedit were derivatives of libedit). If you distribute this binary then you are distributing a derivative of someone else's work. Now, you could distribute the source for your work and have the end user build it himself, that's a much harder reach as a derivative (there are precedents, however). On the other hand, if you are going to distribute source you might as well license your software under the GPL.
You see, that's the real trick. People distributing closed software want to distribute binaries.
If the program is designed to share a memory space with the library, and does not run without it then the binaries that you compile that dynamically link to the library are clearly a derivative work (according the definition the FSF and the rest of the software industry uses). You can't distribute these binaries that are a derivative work without the permission of the original copyright holder. The end user's actions have nothing do with it.
Now if you wrote a proxy for the library that would be a different matter. However, you had probably better remove the bits where it links the library anyhow. After all, the fact that a proxy exists might not be enough of a buffer. It's like the rules that accountants use for deciding whether a tax deduction is legal. The rule of thumb is that if you believe you have a one in three chance of winning in court then you can take the deduction. The question is whether or not you believe that you can make your point in court, with the ownership of your proprietary code and all the revenues you have made from it (plus damages) hanging in the balance. Not to mention the fact that the very fine lawyers at the FSF will be on the other side of the bench. Will you be able to afford someone who has argued in front of the Supreme Court? The FSF might even get help from the major software producers (and possibly Hollywood) who want to guarantee that no bad copyright precedents are set.
Feeling lucky, punk?
Now, if you want to argue about how copyrights, should be, that's another story. I am simply telling you how they are.
Believe what you want, when Eben Moglen calls you'll either hand over the source or you'll write your proxy application and you'll be glad that the FSF doesn't make examples of companies that change their ways.
Here's what Borland has to say:
Here's a link. Unforutnately it is a Word document
A little searching will undoubtedly produce others. Basically if the FSF is imagining the bounds of copyright then it is a consensual hallucination with a lot of participants.
Once again, read the licenses of the libraries that you are linking against. You will probably be surprised. The fact of the matter is that the software industry has worked like this forever. You simply haven't paid any attention to software licenses before.
The fact of the matter is that if you base your work on a commercial license you are invariably putting yourself at risk. The company could disappear, they could change their licensing terms, etc. The fact that your program is a derivative work (legal, in this case that you paid for your library) doesn't really change the equation. When you use someone else's proprietary license you are literally at their mercy.
If they share the same memory space then your program is a derivative work. If they communicate in some other way then you are fine. That's "mere aggregation."
There are plenty of folks that thought that their product wasn't a derivative work if they simply pointed people to the download of the GPL library. In the end all of them either released their source or wrote a small GPL wrapper around the library that communicated with their program via some other method than a shared address space (and even that may not be a protection in some cases according to the FSF).
The point that you are missing is that it doesn't matter who downloads what when. If your program doesn't work without the GPL library linked in then it is a derivative work, at least according to the FSF.
Yes, something like that. Read the licenses on some of the commercial libraries you use. If you think that the GPL is shocking, you should see what Microsoft, Borland, and some of the rest have to say.
I don't know of a precedent for this sort of a interpretation, but I am not Eben Moglen either. Not that it matters. Since there is little to gain and a lot to lose by testing these legal waters it isn't likely that we will get someone stupid enough to actually set a legal precedent. That is why people comply when Eben Moglen calls them on the phone. The only reasonable way to act is as if a legal precedent had been set. After all, you don't want to become the precedent.
That's why I always laugh at GPL detractors who point out what they consider to be legal problems with the GPL. The detractors might be right, but no one is likely to take their word for it.
Personally I agree that if they can fingerprint copyrighted material on their network they should do something about it. I do not agree that there are no legal uses for the bandwidth that colleges provide. If there are no legal uses for the bandwidth that colleges provide then they should just shut the network down and be done with it.
I actually have read Title 17, and I am afraid that I will have to agree with the legal folks at the FSF (and every major software company). Not that it matters what I think. As you have pointed out only a fool would go to court against the FSF on this issue. If the FSF is right about what constitues a derivative work in software then the offending company's software would essentially become property of the FSF and they would have to release the source code to this software to all of their customers (plus any monetary penalties). In short, it would be instant death. Even releasing the source code to your crown jewels is probably a better alternative.
Big Corp A would be crazy to base their proprietary software on GPLed code because anytime between now and whenever the copyright wears out on said code the FSF can come and wreck their party. And the FSF can even wait until after it has found an easier target to be the legal precedent.
So you can pretend that the GPL is on shaky ground when it comes to linking, but you can bet that your legal department isn't likely to advise you to press the issue. If Mr Moglen called your company you would cave, just as everyone else has. So think what you want, for all practical purposes the FSF is right as rain on this issue.
Your "so-called" imposition on third parties, on the other hand, is just pure hogwash. It doesn't matter where I get the copyrighted work, if I try and distribute it I have to get the permission of the copyright holder. Without that permission I can't distribute the work. There is no third party. The only way to get permission to distribute GPLed code is to make source code available.
Which brings us to your last point, where you talk about the GPL restricting the "use" of software. I am perfectly free to download a GPLed library and link my own personal programs against it, as long as I don't distribute my derivative work to someone else. In short, I am free to "use" the software how I wish (including linking), I just can't distribute the GPLed software, or its derivative works, without the permission of the copyright holder. As long as you don't distribute the software the GPL has absolutely no hold you.
Let's imagine that you took one of Steven King's novels and wrote an alternative ending. Could you legally distribute that and tell your customers to go and purchase Steven King's book if you want to read the first part of the story. Of course not. Creating a program that requires an external library is a similar type deal.
Now if your program communicates with a separate GPLed program via pipes (or other methods) that's a totally different story. Read the FAQ, it should clear things up.
If you write an application that links (dynamically or statically it doesn't matter) with a GPLed library then you must distribute your application under the GPL (assuming you distribute your application). This doesn't "lock" the interface or the API because you are perfectly free to create your own replacement for libfoo (called libbar, of course). Example: libedit is a replacement for readline.
If your application doesn't work without libfoo then it is clearly a derivative work of libfoo. You are infringing on the copyright not because you used the libfoo API, but because you created and distributed a derivative work without the permission of the copyright holder.
Here's a little secret. The reason that the GPL has never been tried in court is not because the GPL is on shaky ground, but rather because it is on such firm ground that only an idiot would want to get up in front of a judge and become a precedent. First of all, all of the major software houses rely on copyright to protect their own intellectual property.
Take the large software development firms, for example. The last thing that IBM or Microsoft would want is a legal precedent that weakened copyright. So count out the large software houses as potential GPL litigators. This explains why there is not a single major software company that hasn't responded, and responded quickly, to perceived GPL violations. Even Microsoft distributes GPLed software, strange as that may seem.
So that leaves the small-time developers. Now imagine your local software consulting firm paying for the lawyer fees that would arise from butting heads with the likes of Moglen or Lessig. The FSF has access to excellent lawyers, and in a copyright case the FSF could even push for the reward of heavy damages. So not only would the small consulting firm be faced with large legal bills, but they would also be faced with the possibility of losing their own copyrighted works (since they would be a derivative of the FSF's works), and paying a hefty fine. It's no wonder that a case hasn't gone to court. Especially since the FSF is happy to forgive you if you simply make the source code available to your customers (note, you don't have to make the source available to the whole world). And the FSF almost certainly would win the court case anyhow. You see, they were very careful to make sure that the GPL relied on the "distribution" of the software as the key to their license. Under normal copyright terms the end user is denied the right to distribute copyright material without permission of the copyright holder. The GPL simply points out the terms under which the original copyright holder is willing to allow you to distribute their work. Either the end user accepts the GPL, or they don't have permission to distribute the software (or its derivatives). The end user can still use the software, but that's it.
Another example of a GPLed library is QT. This allows developers to use QT if they are willing to let their software fall under the GPL. If you want to use QT in a commercial product you must pay money for a commercial (non-GPL) license.
As for your belief that GPLing a library is an attempt to lock the *interface*, that's blatantly false. As proof of this take a look at libedit. It's goal is to be 100% API compatible with readline, but with a BSD-style license.
The FSF argues that there is little reason to GPL a library that is a reimplementation of a commercial library (ie glibc), because if you did that no one would use the GPLed library. However, if your library has new and interesting features that aren't found in a commercial library then the GPL makes sense. People will want to use the library in their own programs (because of the features), but they will need to release their software under the GPL to be able to use it. There are several examples (ncftp using readline being the prime example) where this has actually been the case.
Are you kidding? I already have a desktop for firebreathing horsepower stuff. A wireless card in this bad boy would give me a portable X terminal for use all around my house, and I could still take the thing with me and fire up Emacs when I am on the road. I think this laptop sounds very cool.
Heck, when it comes to laptops the only app that I am really worried about being able to use is Emacs. I am actually glad when I see the manufacturer skimping on the video card.
Yes, software that links with a GPLed library needs to be released under the GPL. However, most of the libraries on a typical GNU/Linux box are LGPLed, and not GPLed. Readline is the prime example of a widely used GNU library that is released under the GPL.
Microsoft loses quite a bit of money on every XBox sold. Microsoft's only reason for creating the XBox is to sell XBox games. The last thing Microsoft wants to do is make it possible for Sony to make money selling PSX games to XBox owners.
On the other hand 486s also make good X terminals :).
A word to the wise. A felony assault is not a good idea.
And how is this different from real life? My goodness, a game where money, prestige, status and experience expand the opportunities for advancement. That's practically revolutionary! The funny thing about being at the top, is that you have nowhere to go but down (and lots of folks gunning for your position). In fact, that's basically politics in a nutshell.
Are you telling me that the destruction of Arthur Dent's home was some sort of anomaly?
And how do you get people and businesses to move? Simple, tax them like crazy. In short, this is a perfect way to encourage businesses to migrate away from the more congested areas.
What does this example have to do with anything? In all of your examples overtime is simply a method where the slow, unproductive, and troubled get paid extra to do the same amount of work (as long as they stick around the office while they are being slow, unproductive, and troubled).
On the flip side, let's say that my wife is sick and I would like to go home early to give her a hand with the kids. As a salaried worker I can leave early without losing money. As long as I get my job done to my employer's satisfaction I can be far more flexible with my time. If my employer is unhappy with my performance he can hire one of the "100 guys standing in line to get a job." Likewise, if I am unhappy with the hours that my employer is asking me work I am free to try and find another job.
Quite frankly, unless you happen to have a job as a security guard or something where the primary component of your pay is your physical presence then it simply doesn't make sense to get paid simply by the amount of hours that you spend in the office. My employer doesn't really care where I get my job done, as long as it gets done. Yes, sometimes that means that I have long days, but sometimes it means that I get to go home early.
Actually, now that there are two implementation of Python (CPython and Jython), I think that I would have to disagree with you about the single implementation problem. Besides, from where I am sitting standardization has been the death knell for every language that has ever gone through the process. Standardization certainly didn't help Lisp, and standardization has actually delayed adoption of important parts of C++ (as folks waited for them to become standard).
As long as the language in question has a good (and portable) Free Software implementation why should I care about what some wacky standards body says?
Yes, you are probably right. I probably was a little harsh. However, the whole point of the article was that, in the name of progress, geeks keep messing up perfectly good systems. If you have spent a great deal of time and effort learning an interface, even a poor one, the last thing that you need is some dumb shmuck making a totally new interface.
As a concrete example take vi. Vi is still widely popular despite the fact that it's interface is so non-intuitive that the first time I used it I had to turn off my Linux box to get it to go away. The reason that vi is popular despite it's horrifically non-intuitive interface is that once you learn vi's interface you can get your job done a heck of a lot faster than someone who has to take their hands off the keyboard to use the mouse. I have a buddy that can hack faster drunk than any two other coders because he literally thinks in vi macros. You give my buddy any other IDE, no matter how intuitive, and you will almost certainly hurt his ability to get things done.
The problem isn't that these journalists are too stupid to learn the new systems. The problem is that they don't want to have to learn another system. They want to hang onto their old interface, the one they already know how to use.