The card's theory is that by moving a lot of the network stack into hardware you can decrease the latency due to OS driver/stack processing. It's a nice theory, pity that part of the latency's only 1-2% of the total latency. But then, buying magic solutions to basic problems isn't new. Think of the audiophools who spend $20/foot on deoxygenated, magnetically-aligned, high-copper-alloy low-resistance speaker cables with special xenon-impregnated insulation and amorphous-bonded iridium-plated connectors because the salesman claims it'll magically improve the sound from their stereo system.
Well, you could've if he hadn't've died not too long ago. But anyone at Baen Books could tell you, since that's exactly what they're doing. They publish books in electronic form, with no DRM or other technical restrictions on them. HTML is one of the formats. Some of the e-books they give away, others they sell in both electronic and dead-tree format. And you know the odd thing? The books they give away actually sell more copies. Just look at what Eric Flint has to say on the front page of the Baen Free Library. People not only buy the e-book form of the very books they can get for free, they buy the dead-tree form too. And they buy other books by the authors who have their work up in the BFL. Enough so that those authors have actually seen their back-list sales increasing. That never happens, or at least never until the BFL appeared.
You want to know how to make money with freely-available content? Go ask the people who're doing it today.
I think you miss the intended markets for those cards: hard-core gamers and high-performance streaming-media systems. Gamers in particular will pay inordinate sums to shave another millisecond off their game's ping time or get that extra FPS or two, and they don't really care how bad an idea is overall if it gets them what they want.
Exactly. You want to protect the consumer's ability to identify the source of goods and services, specifically yours. When that consumer sees something with your trademark on it, you want it to be your item and not somebody else's using your name.
Interesting. Do you mean function calls? So if I use a toolkit that has something like RenderSquare(blah blah) in it, and I call that function from my code, then is that a physical appearance?
Yep. The function declaration from the header file produces a small amount of literally-copied code in your executable that comes from the library. Same thing with constant definitions and macros and such. It's minimal, but it's there. It's also fairly critical, your program won't work without it without a lot of reworking. This is why the major GUI toolkits are all under either the LGPL, a BSD-style license or are dual-licensed under both the GPL and a commercial license. I don't think the whole matter needs addressed in the license because it's already clearly addressed in copyright statute and case law. A license need address only those things that aren't addressed by law or that the creator wants to have handled differently than the law's default.
Whether a library's usable under the GPL or LGPL isn't, I'm afraid, up to you. It's up to the library's creator. You'll have to do what you do with any software, free, open-source or commercial: compare what's allowed by the license against what you want to do and decide whether the software's valuable enough to justify accomodating it's license terms. For most users of open-source software it's not an issue because all the software's open-source and there's no license conflicts. Different software uses different versions of libraries, but there's not usually major problems having 3-4 different libraries co-exist and the worst-case condition still leaves 80+% of the drive free.
Actually all your questions are answered by the basic question you need to ask of copyrighted works: does any GPL'd code physically appear in the work you distribute? If the answer's yes, then the GPL applies to that work and you need to release your code. If the answer's no, then it doesn't and you don't. Note that in most cases if you link to a library some of the library's code will appear in the resulting program. This is why the LGPL was created, to allow the minimal code needed to use a library to be included (as in dynamic linking) without triggering the GPL conditions unless the body of the library itself is also physically included (as would happen with static linking). Whether you modify the toolkit or not doesn't matter, only whether it's copyrighted code appears in the work you're distributing. Remember, if you can distribute the toolkit's code in violation of it's license simply because you didn't modify it, then anybody else can distribute your code in violation of your license as long as they don't modify it. That would sort of kill your ability to make a profit, wouldn't it?
As for Office on Linux, that wouldn't need to include any code that's under the GPL so there'd be no reason to open-source it. If you want to see an analysis of what's changed between GPL v2 and v3, visit the FSF's Web site and read their annotations of the changes.
You're entirely free to do whatever you want with software you have written. What the GPL, versions 2 and 3, are about is what you can and cannot do with software someone else wrote. You want the right to determine terms for your software? You have to respect the right of someone else to determine terms for their software.
I think BW underestimates the relevance of the FSF. Yes, Linux uses GPLv2 only. Yes Mozilla uses their own license. But if you look at the basic toolchain that Linux, Mozilla and the like use, the majority of that infrastructure's copyright rests with... the Free Software Foundation. Use GCC to compile? Depend on Bash, flex, bison? They'll be moving to GPLv3. Even something as basic as grep, chances are if you're on a Linux system you use the FSF's version of it.
It's also going to depend on developers, not companies (unless those companies are also the developers and copyright holders on the programs). I'd note that one of the tipping points for the GPL was when people started to find GPL'd software in commercial products which the code owners themselves were locked out of by lack of source code. I think the same pattern will repeat, with the GPLv3 being RMS-only for a bit and then it'll pick up steam when a few high-profile developers want to modify a neat device and find they're locked out of modifying their own code by DRM.
That said, it's unlikely the Linux kernel will ever move to GPLv3 regardless of what Linus thinks simply because of the infeasability of contacting every copyright holder. It's been mentioned as a protection: there's so many copyright holders no company (say, Microsoft) could get authorization from all of them to put their release of the Linux kernel under a more restrictive license. The same thing applies to any contemplated change to GPLv3.
CR isn't identifying new exploits. All they're doing is the old virus-writer trick of tweaking a virus by shuffling the order of routines around or changing strings (banners or other displayed text) to change the virus enough to make existing signatures not match anymore. In short, CR's testing the ability of AV software to actually detect viruses, not just do a simple grep for a known byte sequence and return a yes/no based on whether it was found or not.
We won't get into stealthed polymorphic viruses that do nasty things like hook the OS read routines so the file has different contents depending on whether it's being read as data or loaded as an executable program...
Except that financial calculations don't count units of currency. Think about interest calculations, for example, that do care about fractions of a cent (at least in the ledger, although the numbers may be rounded to the nearest cent for display/printing purposes).
Assuming the marketing literature is right about the detection rates, that alone renders the device useless. Consider this: for every terrorist there are at least a thousand legitimate travellers in any given airport. At an 8% false-positive rate, you'll incorrectly tag 80 innocent travellers during screening. Assume you tag the terrorist as well. You've now got a group of 81 people, 80 of whom are innocent. What's the public reaction going to be when, after the delays and the hassles to all those people, it turns out that 98.77% of the time your "detector" is wrong? And this is conservative, assuming a low number of travellers and a high percentage of terrorists. It wouldn't suprise me if a major airport like Heathrow handled several tens of thousands of travellers every day and only saw any terrorists at all on one day a month if that often.
The problem isn't really that some numbers can't be represented exactly, it's that base-2 has different numbers that can't be represented exactly than base-10. People aren't suprised when 3-for-a-dollar results in oddities (33 cents each, but 3x33 isn't 1 dollar), but get suprised when 10-for-a-dollar behaves the same way on a computer.
Not quite. Go look up the history of the word "xerox" for an example. Xerox lost the trademark on their own name over this exact issue. No company wants that.
I think it's simpler: financial calculations require a certain number of decimal places of precision, while scientific calculations tend to require a certain number of significant digits of precision. Floating-point numbers provide a known number of significant digits of precision, but depending on the exponent that may not provide the 2 decimal places of precision needed to represent a financial amount (in US currency at least, other countries may have different requirements).
Well, the other problem is the difference between decimal places vs. significant digits when it comes to precision. Most people are used to a fixed number of decimal places, and when you have to go to significant digits people get confused too. In practice, though, I run into decimal-vs-binary confusion far more often.
We have the same problem in everyday numbers. Try representing 1/3 in any finite number of digits. You can't. The big thing about floating-point numbers that trips people up is that we're used to thinking in base 10. Floating-point numbers in computers typically aren't in base 10, they're in base 2. The rounding problem he describes is simply us getting confused and wondering why a fraction with an exact representation in base 10 doesn't have an exact representation in base 2. The obvious solution is the one he alludes to at the end: don't use base 2. Computers have had base-10 arithmetic in them for decades, in fact the x86 family has base-10 arithmetic instructions built in (the packed-BCD instructions). COBOL has used packed-BCD since it's beginning, which is why you don't find this sort of calculation error in ancient COBOL financial packages running on mainframes.
Because it puts the DRM keys in the hands of the user, not the vendor. The vendor (the one who makes the hardware and software) doesn't need to insure that there's no tampering. The user generates their own signing key, loads it into the hardware (or possibly has the vendor do it, if the chip with the verification key's tamperproof and can't be changed or written to after installation), certifies the software and signs the binaries so only the binary they certified can run. Nobody else can run binaries on that hardware, not even the vendor, but that's OK since the user isn't going to distribute the firmware in that state to anyone else, they'll only use it themselves. They can similarly sign the data file containing the ballots for each election, letting them create and use their own ballots without being dependent on the vendor. Any further distribution of the firmware would of course be without a burned-in key, so again the end user can supply their own key for their own hardware and binaries.
This means, of course, that the vendor can't install software updates without going through the end user (election commission) to get the new binaries signed (and presumably certified first), but that's OK since that's what we want. And of course the election commission itself could tamper with the software, but we already have methods from physical ballots to prevent that (think multiple independent observers who can supply and verify additional signatures, if the election officials modified the binaries they'd invalidate those additional signatures).
Problem is, it doesn't identify the zombies or stop the spam. The only thing it does is block the legitimate e-mail. Oh, and it gives the spammers an incentive to increase the number of bots they've got, to increase access to tokens.
Now, if the tokens were tied to and usable by only one person, that'd identify the spam sources. But then the tokens couldn't be used by the recipient as proposed. That would also throttle the spam down because of the limited number of tokens. But as long as new tokens are available from incoming spam, the outgoing spam can continue. It'll only stop when the user makes the connection between his inability to send e-mail and the malware on his PC sending out spam, but if the lusers could manage that we wouldn't have these massive botnets in the first place.
Basic problem: most spam is sent by zombie PCs. The spam software will just use the tokens belonging to the PC's owner, leaving him with none. And since the owner's receiving spam too, with attached tokens, there won't be a shortage.
My bet is the city thought they had a simple transaction: they were buying a robotic parking garage and contracting with the company that made it to operate it. No software in there at all, any more than the software in the engine computer of your car's involved when you buy a car and a maintenance contract. If you don't renew the maintenance contract, you don't expect the car's ECU software to suddenly stop working. If this is the case, though, there's no excuse. The city's lawyers should've screamed bloody murder when the contract the city was supposed to sign didn't match what the city thought it was agreeing to. Or if they did scream and the vendor brushed it off with some "Don't worry about that, it's just standard language." they should've responded "Well, if it's not a problem you won't mind having that standard language replaced with the correct version and you and us both signing the change, right?".
I think the whole escapade's a good object lesson for people buying things that contain software: make sure you know exactly what the contract says and make sure you can live with the interpretation least favorable to you in all circumstances. If you don't or you can't, and the vendor won't agree to acceptable terms, walk away and find another vendor. And if the salesman does appear to agree to change the terms, don't trust any verbal agreements and don't trust the salesman's signature alone. Make it go back to the vendor's legal department for review to the vendor can't repudiate the alterations later with "We didn't authorize our salesman to make those changes.".
Well, some parts really are more complex. That's usually because there's more things to tweak. Setting up Samba, for example, is a bit harder than enabling file sharing on Windows, but then you can excercise more control over how Samba does things while Windows gives you the choice of doing it it's way or not doing it. More control = more controls.
On the other hand, a common lament about the "complexity" of Linux from the Windows side is "But on RedHat startup scripts go in/etc/rc.d/init.d but on Debian they're in/etc/init.d! How am I going to figure out which it is?!" (to which I usually respond "Well, if you can't check which one exists and just use that, you really need to go back to Shell Scripting 101.").
Agreed on the first. As to the second, especially the harm part, you're making the assumption that it's a human being at a browser looking at the page. What happens when it's an automated system (say Windows Update) using HTTP to access a Web service? It can probably handle a "server not found" error if the hostname in the URL becomes invalid, but how's it going to handle a success that isn't a success? We won't even discuss things like a typo in the form-submit URL on a bank sending that holding/advert server every account number and password used by everyone using that bank's on-line service (or trying to, anyway). Claiming that a hostname exists when it doesn't has a lot of subtle effects, bad ones.
Well, yes, but then your example is of an open-source program that can freely use open-sourced libraries (for the most part). If you're writing your own app it starts out using no libraries. You then get to decide as you find a need for libraries which ones you'll use. Yes, you'll not be able to use a lot of common libraries and stay closed-source because those libraries are open-source. Similarly, open-source software can't use a lot of commercial libraries and stay open-source. It's a simple matter of deciding whether using the library's valuable enough to justify any license changes required.
Of course, if you use third-party commercial libraries you've got the additional problem of getting them to provide a Linux version you can use. Many vendors won't do that and without those libraries your app may not work. If you've got customers who want to pay you for a Linux version, ponder the lost revenue and consider that you're experiencing exactly why a lot of Linux users don't like closed-source software. As a software developer I find myself saying this a lot: "If I've got the source code I can fix the problem. If I don't, we're SOL.".
Slashdot Mirror
The card's theory is that by moving a lot of the network stack into hardware you can decrease the latency due to OS driver/stack processing. It's a nice theory, pity that part of the latency's only 1-2% of the total latency. But then, buying magic solutions to basic problems isn't new. Think of the audiophools who spend $20/foot on deoxygenated, magnetically-aligned, high-copper-alloy low-resistance speaker cables with special xenon-impregnated insulation and amorphous-bonded iridium-plated connectors because the salesman claims it'll magically improve the sound from their stereo system.
Well, you could've if he hadn't've died not too long ago. But anyone at Baen Books could tell you, since that's exactly what they're doing. They publish books in electronic form, with no DRM or other technical restrictions on them. HTML is one of the formats. Some of the e-books they give away, others they sell in both electronic and dead-tree format. And you know the odd thing? The books they give away actually sell more copies. Just look at what Eric Flint has to say on the front page of the Baen Free Library. People not only buy the e-book form of the very books they can get for free, they buy the dead-tree form too. And they buy other books by the authors who have their work up in the BFL. Enough so that those authors have actually seen their back-list sales increasing. That never happens, or at least never until the BFL appeared.
You want to know how to make money with freely-available content? Go ask the people who're doing it today.
I think you miss the intended markets for those cards: hard-core gamers and high-performance streaming-media systems. Gamers in particular will pay inordinate sums to shave another millisecond off their game's ping time or get that extra FPS or two, and they don't really care how bad an idea is overall if it gets them what they want.
Exactly. You want to protect the consumer's ability to identify the source of goods and services, specifically yours. When that consumer sees something with your trademark on it, you want it to be your item and not somebody else's using your name.
Interesting. Do you mean function calls? So if I use a toolkit that has something like RenderSquare(blah blah) in it, and I call that function from my code, then is that a physical appearance?
Yep. The function declaration from the header file produces a small amount of literally-copied code in your executable that comes from the library. Same thing with constant definitions and macros and such. It's minimal, but it's there. It's also fairly critical, your program won't work without it without a lot of reworking. This is why the major GUI toolkits are all under either the LGPL, a BSD-style license or are dual-licensed under both the GPL and a commercial license. I don't think the whole matter needs addressed in the license because it's already clearly addressed in copyright statute and case law. A license need address only those things that aren't addressed by law or that the creator wants to have handled differently than the law's default.
Whether a library's usable under the GPL or LGPL isn't, I'm afraid, up to you. It's up to the library's creator. You'll have to do what you do with any software, free, open-source or commercial: compare what's allowed by the license against what you want to do and decide whether the software's valuable enough to justify accomodating it's license terms. For most users of open-source software it's not an issue because all the software's open-source and there's no license conflicts. Different software uses different versions of libraries, but there's not usually major problems having 3-4 different libraries co-exist and the worst-case condition still leaves 80+% of the drive free.
Actually all your questions are answered by the basic question you need to ask of copyrighted works: does any GPL'd code physically appear in the work you distribute? If the answer's yes, then the GPL applies to that work and you need to release your code. If the answer's no, then it doesn't and you don't. Note that in most cases if you link to a library some of the library's code will appear in the resulting program. This is why the LGPL was created, to allow the minimal code needed to use a library to be included (as in dynamic linking) without triggering the GPL conditions unless the body of the library itself is also physically included (as would happen with static linking). Whether you modify the toolkit or not doesn't matter, only whether it's copyrighted code appears in the work you're distributing. Remember, if you can distribute the toolkit's code in violation of it's license simply because you didn't modify it, then anybody else can distribute your code in violation of your license as long as they don't modify it. That would sort of kill your ability to make a profit, wouldn't it?
As for Office on Linux, that wouldn't need to include any code that's under the GPL so there'd be no reason to open-source it. If you want to see an analysis of what's changed between GPL v2 and v3, visit the FSF's Web site and read their annotations of the changes.
You're entirely free to do whatever you want with software you have written. What the GPL, versions 2 and 3, are about is what you can and cannot do with software someone else wrote. You want the right to determine terms for your software? You have to respect the right of someone else to determine terms for their software.
I think BW underestimates the relevance of the FSF. Yes, Linux uses GPLv2 only. Yes Mozilla uses their own license. But if you look at the basic toolchain that Linux, Mozilla and the like use, the majority of that infrastructure's copyright rests with... the Free Software Foundation. Use GCC to compile? Depend on Bash, flex, bison? They'll be moving to GPLv3. Even something as basic as grep, chances are if you're on a Linux system you use the FSF's version of it.
It's also going to depend on developers, not companies (unless those companies are also the developers and copyright holders on the programs). I'd note that one of the tipping points for the GPL was when people started to find GPL'd software in commercial products which the code owners themselves were locked out of by lack of source code. I think the same pattern will repeat, with the GPLv3 being RMS-only for a bit and then it'll pick up steam when a few high-profile developers want to modify a neat device and find they're locked out of modifying their own code by DRM.
That said, it's unlikely the Linux kernel will ever move to GPLv3 regardless of what Linus thinks simply because of the infeasability of contacting every copyright holder. It's been mentioned as a protection: there's so many copyright holders no company (say, Microsoft) could get authorization from all of them to put their release of the Linux kernel under a more restrictive license. The same thing applies to any contemplated change to GPLv3.
CR isn't identifying new exploits. All they're doing is the old virus-writer trick of tweaking a virus by shuffling the order of routines around or changing strings (banners or other displayed text) to change the virus enough to make existing signatures not match anymore. In short, CR's testing the ability of AV software to actually detect viruses, not just do a simple grep for a known byte sequence and return a yes/no based on whether it was found or not.
We won't get into stealthed polymorphic viruses that do nasty things like hook the OS read routines so the file has different contents depending on whether it's being read as data or loaded as an executable program...
Except that financial calculations don't count units of currency. Think about interest calculations, for example, that do care about fractions of a cent (at least in the ledger, although the numbers may be rounded to the nearest cent for display/printing purposes).
Assuming the marketing literature is right about the detection rates, that alone renders the device useless. Consider this: for every terrorist there are at least a thousand legitimate travellers in any given airport. At an 8% false-positive rate, you'll incorrectly tag 80 innocent travellers during screening. Assume you tag the terrorist as well. You've now got a group of 81 people, 80 of whom are innocent. What's the public reaction going to be when, after the delays and the hassles to all those people, it turns out that 98.77% of the time your "detector" is wrong? And this is conservative, assuming a low number of travellers and a high percentage of terrorists. It wouldn't suprise me if a major airport like Heathrow handled several tens of thousands of travellers every day and only saw any terrorists at all on one day a month if that often.
The problem isn't really that some numbers can't be represented exactly, it's that base-2 has different numbers that can't be represented exactly than base-10. People aren't suprised when 3-for-a-dollar results in oddities (33 cents each, but 3x33 isn't 1 dollar), but get suprised when 10-for-a-dollar behaves the same way on a computer.
Not quite. Go look up the history of the word "xerox" for an example. Xerox lost the trademark on their own name over this exact issue. No company wants that.
I think it's simpler: financial calculations require a certain number of decimal places of precision, while scientific calculations tend to require a certain number of significant digits of precision. Floating-point numbers provide a known number of significant digits of precision, but depending on the exponent that may not provide the 2 decimal places of precision needed to represent a financial amount (in US currency at least, other countries may have different requirements).
Well, the other problem is the difference between decimal places vs. significant digits when it comes to precision. Most people are used to a fixed number of decimal places, and when you have to go to significant digits people get confused too. In practice, though, I run into decimal-vs-binary confusion far more often.
We have the same problem in everyday numbers. Try representing 1/3 in any finite number of digits. You can't. The big thing about floating-point numbers that trips people up is that we're used to thinking in base 10. Floating-point numbers in computers typically aren't in base 10, they're in base 2. The rounding problem he describes is simply us getting confused and wondering why a fraction with an exact representation in base 10 doesn't have an exact representation in base 2. The obvious solution is the one he alludes to at the end: don't use base 2. Computers have had base-10 arithmetic in them for decades, in fact the x86 family has base-10 arithmetic instructions built in (the packed-BCD instructions). COBOL has used packed-BCD since it's beginning, which is why you don't find this sort of calculation error in ancient COBOL financial packages running on mainframes.
Because it puts the DRM keys in the hands of the user, not the vendor. The vendor (the one who makes the hardware and software) doesn't need to insure that there's no tampering. The user generates their own signing key, loads it into the hardware (or possibly has the vendor do it, if the chip with the verification key's tamperproof and can't be changed or written to after installation), certifies the software and signs the binaries so only the binary they certified can run. Nobody else can run binaries on that hardware, not even the vendor, but that's OK since the user isn't going to distribute the firmware in that state to anyone else, they'll only use it themselves. They can similarly sign the data file containing the ballots for each election, letting them create and use their own ballots without being dependent on the vendor. Any further distribution of the firmware would of course be without a burned-in key, so again the end user can supply their own key for their own hardware and binaries.
This means, of course, that the vendor can't install software updates without going through the end user (election commission) to get the new binaries signed (and presumably certified first), but that's OK since that's what we want. And of course the election commission itself could tamper with the software, but we already have methods from physical ballots to prevent that (think multiple independent observers who can supply and verify additional signatures, if the election officials modified the binaries they'd invalidate those additional signatures).
If it was released with the "or any future version" language in the GPL it used, there's no problem.
Problem is, it doesn't identify the zombies or stop the spam. The only thing it does is block the legitimate e-mail. Oh, and it gives the spammers an incentive to increase the number of bots they've got, to increase access to tokens.
Now, if the tokens were tied to and usable by only one person, that'd identify the spam sources. But then the tokens couldn't be used by the recipient as proposed. That would also throttle the spam down because of the limited number of tokens. But as long as new tokens are available from incoming spam, the outgoing spam can continue. It'll only stop when the user makes the connection between his inability to send e-mail and the malware on his PC sending out spam, but if the lusers could manage that we wouldn't have these massive botnets in the first place.
Basic problem: most spam is sent by zombie PCs. The spam software will just use the tokens belonging to the PC's owner, leaving him with none. And since the owner's receiving spam too, with attached tokens, there won't be a shortage.
My bet is the city thought they had a simple transaction: they were buying a robotic parking garage and contracting with the company that made it to operate it. No software in there at all, any more than the software in the engine computer of your car's involved when you buy a car and a maintenance contract. If you don't renew the maintenance contract, you don't expect the car's ECU software to suddenly stop working. If this is the case, though, there's no excuse. The city's lawyers should've screamed bloody murder when the contract the city was supposed to sign didn't match what the city thought it was agreeing to. Or if they did scream and the vendor brushed it off with some "Don't worry about that, it's just standard language." they should've responded "Well, if it's not a problem you won't mind having that standard language replaced with the correct version and you and us both signing the change, right?".
I think the whole escapade's a good object lesson for people buying things that contain software: make sure you know exactly what the contract says and make sure you can live with the interpretation least favorable to you in all circumstances. If you don't or you can't, and the vendor won't agree to acceptable terms, walk away and find another vendor. And if the salesman does appear to agree to change the terms, don't trust any verbal agreements and don't trust the salesman's signature alone. Make it go back to the vendor's legal department for review to the vendor can't repudiate the alterations later with "We didn't authorize our salesman to make those changes.".
Well, some parts really are more complex. That's usually because there's more things to tweak. Setting up Samba, for example, is a bit harder than enabling file sharing on Windows, but then you can excercise more control over how Samba does things while Windows gives you the choice of doing it it's way or not doing it. More control = more controls.
On the other hand, a common lament about the "complexity" of Linux from the Windows side is "But on RedHat startup scripts go in /etc/rc.d/init.d but on Debian they're in /etc/init.d! How am I going to figure out which it is?!" (to which I usually respond "Well, if you can't check which one exists and just use that, you really need to go back to Shell Scripting 101.").
Agreed on the first. As to the second, especially the harm part, you're making the assumption that it's a human being at a browser looking at the page. What happens when it's an automated system (say Windows Update) using HTTP to access a Web service? It can probably handle a "server not found" error if the hostname in the URL becomes invalid, but how's it going to handle a success that isn't a success? We won't even discuss things like a typo in the form-submit URL on a bank sending that holding/advert server every account number and password used by everyone using that bank's on-line service (or trying to, anyway). Claiming that a hostname exists when it doesn't has a lot of subtle effects, bad ones.
Well, yes, but then your example is of an open-source program that can freely use open-sourced libraries (for the most part). If you're writing your own app it starts out using no libraries. You then get to decide as you find a need for libraries which ones you'll use. Yes, you'll not be able to use a lot of common libraries and stay closed-source because those libraries are open-source. Similarly, open-source software can't use a lot of commercial libraries and stay open-source. It's a simple matter of deciding whether using the library's valuable enough to justify any license changes required.
Of course, if you use third-party commercial libraries you've got the additional problem of getting them to provide a Linux version you can use. Many vendors won't do that and without those libraries your app may not work. If you've got customers who want to pay you for a Linux version, ponder the lost revenue and consider that you're experiencing exactly why a lot of Linux users don't like closed-source software. As a software developer I find myself saying this a lot: "If I've got the source code I can fix the problem. If I don't, we're SOL.".
Yes. Term 3 of the LGPL. And yes, once a copy's been converted to GPL it's permanently under the GPL, it can't be reverted back to the LGPL.