One difference between driving and the Internet is that they don't put student drivers in cars out on the highways. At least not right off. First, you sit in a classroom and learn, from lectures and reading, the theory of the basics. Then they give you a test to make sure you've actually absorbed the basics. Then they put you in a simulator. Then, if you pass the simulator, they put you in a car in a closed lot with no other cars around and see if you can put all that theory into practice without being too dangerous. Then, only after you've passed all that, do they let you out on the highway, and even then only with an experienced driver along for the first few months.
Imagine the howls if we imposed the same rules for Internet access...
Because AOL gave millions of people who had no clue about the Internet access to the Internet. This is much akin to taking several million people who have no clue how to drive, giving them shiny new high-performance cars and dumping them on the freeways.
Queueing and local delivery. On my system the mailserver is local-service-only. It queues mail from the clients (Pine and Mozilla) for delivery, and handles local delivery of mail retrieved via fetchmail. The first improves reliability, since mail is safely queued if there's any transient problems (most clients have inadequate provisions for saving mail if it can't be sent immediately), and the second gives me the ability to do processing via procmail easily (not to mention the ability to use e-mail locally for notifications and reporting).
Note that it's physically impossible for my mailserver to relay spam. First, it's configured to refuse to relay. Second, even if it would relay it's configured not to listen on the external interface. Third, even if it were listening the firewall would prevent the outside world from connecting to port 25.
Then you may have a problem, because most non-Linux vendors won't offer you that indemnity either. As MS customers are finding out with the SQL Server lawsuits, for example. At least with RedHat you have the ability to produce the source to prove it's not the suing party's software.
What the patent describes is the use of a public-key cryptosystem to sign a document. That was well-known a decade before the patent was applied for. His patent fails both on obviousness and originality.
That's only an issue if you don't know the ISP's policies. If they publish their policies and you sign up knowing them, then presumably you don't disagree with them too much. If you want an ISP that allows everything through, you wouldn't sign up with one with a draconian filtering policy.
For myself, I'm happy my ISP applies some fairly extensive filtering to remove spam, applies more that flags messages in the headers so I can drop it myself if I want, and has a setup where I can do my own filtering on top of that. I'd be rather annoyed if someone tried to tell me my chosen ISP couldn't do the things that convinced me to go with them in the first place.
Of course Intuit's not showing a hit on profits yet. Most of the people who are complaining already bought the software before they found out about the problems (from someone else if they were lucky, the hard way if they weren't). What Intuit needs to question is what effect this will have on next year's profits, when the people who complained this year buy some other tax software package instead of TurboTax. Of course, by that time nobody will make the connection between declining sales and the screw-up 12 months before
The parts about Google's cookies may or may not be worth worrying about, but then Google works just fine if you block cookies from it so it's not hard to prevent any potential problems. The rest is paranoid handwaving amounting to "Google lets anyone in the world find out exactly what I said even if I don't want them to!". I fail to see the problem in that.
I'm sorry, but Verisign should have their status as both registrar and root nameserver operator revoked after this. We depend on being able to tell when a DNS name doesn't exist. The master nameservers for two of the biggest TLDs should never, I repeat never, lie to us about that by returning a record when no such record exists for the name queried.
What Verisign's doing is the equivalent of the phone company responding to a 411 request for a name that isn't in the phone listings not with "I'm sorry, we don't have a listing for that name." but with "The number is.".
Just remember that Lindows is not, according to the GPL, required to provide source code to the world. They're required to provide source code to anyone who they distribute a product based upon GPL'd software to. Since their product is only available via purchase, they're allowed to restrict access to the source code to only those who've purchased their product.
They're not, of course, allowed to prohibit you from redistributing the GPL-software-derived parts of their distribution, and the accompanying source code, after you've purchased it. They can only put that restriction on the parts that they created that aren't touched by the GPL.
It depends, but generally yes I would be held liable. I probably wouldn't face criminal charges if the modifications were such that they wouldn't be immediately apparent, but I'd still have to pay for damages and injuries and such (or my insurance would). I would, however, likely be able to hold you liable for the modifications, and be able to sue you to recover what I'd had to pay out. I'd possibly also be able to sue the manufacturer for making a faulty product.
As far as expectations about computers go, they're irrelevant. Computers running lots of software are inherently complex, in the same way and for the same reasons that a 747 is complex to operate. You can make it easier, but you can't make it less complex without making it incapable of doing it's job. Either you adapt your expectations to reality, or reality will continue to smack you.
And when did people get stupid? I can remember when secretaries were expected to be able to write fairly sophisticated macro programs for Lotus 1-2-3 or WordPerfect. And they did it well, often better than professional programmers could. When did it become acceptable to not know how to use a tool you need to use to do your job?
However, the manufacturers of most computer software have NOT made efforts to make the software trivially easy to secure. Even for those with grea expertise, it requires significant effort (many settings, checks tests, etc.). Thus, holding a normal user responsible for the actions of a hijacked computer is unreasonable.
Invalid argument. In any other area, if you operate something that you know you aren't qualified to operate and damage property with it, you won't be held not responsible because you couldn't have been expected to operate it properly. Quite the opposite, you'll very likely face even more severe penalties.
Yes, we should hold vendors liable, just like we hold manufacturers liable if they make a faulty product. But we should also hold users liable for either knowing how to use their systems or getting advice and aid from someone who does. "I didn't know how to drive." doesn't cut it, "I don't know how to use a computer properly." shouldn't either.
First, you don't need to be licensed to be an auto mechanic. Those certifications the mechanic has up are there to show off. Whether they mean anything depends on the certificate and who issued it, but none of them are required to work on cars. Of course people do make decisions based on them (eg. not taking their new car to a mechanic who doesn't have a certification from the car's maker).
Second, the certificates for hairdressers and such have nothing do to with how well they do their jobs. The certifications are about making sure the certified isn't a hazard to the public (the customers). The certificate says your hairdresser knows and follows the rules about cleanliness of the tools and such, but whether they can cut your hair without butchering it is outside the scope of the certification.
Given those two things, there's not much parallel in the parallels the article's author is drawing. Myself, I think certification would be good, but only if it concentrated on practical tests (ie. no questions to answer, your test is to be given a bench and a broken PC and you have to fix it while an instructor grades you on whether you followed anti-static and other safety procedures, whether the work was done right and (most importantly) whether the PC actually worked when you were done).
It looks like the server is sending an HTTP 1.0 version in the response, though, which makes the relevant RFC 1945, not 2616. IE should be checking the HTTP response version to determine whether it's in fact HTTP 1.1, or it should be checking the readability of the socket before writing (to detect an HTTP 1.0 server closing the connection after the response).
You failed to read all of RFC793. When the server sends a FIN to the client, the client is required to ACK it, but the client is not required to send a FIN to the server at that point. If the client doesn't close it's half of the connection (triggering the send of it's FIN packet), it's allowed to continue to write. That's why the shutdown() socket call takes an argument indicating whether to close the read half, the write half or both halves of the connection. Of course, if the server has completely closed and disposed of the socket on it's end, incoming packets will fail to match a connected socket on the server and an RST will be generated.
It was thought more likely to work the other way, with the browser sending a FIN packet to the server immediately after sending it's request, closing the browser-to-server half of the connection, and the server would then send the response back down the server-to-browser half of the connection before sending it's FIN packet to the browser to complete closing the connection. As it turns out, things took a different route and the opposite happens.
It is being set up properly. What happens is that the browser hasn't closed it's half of the connection. When the next request happens it tries a TCP write, but since the server side has closed the connection the write fails. That's what's confusing the blog author, they're not familiar with the TCP protocol. A TCP connection has two halves and it's entirely legal to close one half but not the other, leaving a socket that can be read from but not written to (or vice versa). IE doesn't check for the server-side close like it should, treats the socket as if it's writable (which it is) and writes to it. Since the server's closed the socket on it's end, that attempted write generates an RST (which is TCPly correct), the browser gets a write error and finally notices that it's connection has been closed by the remote end, closes everything down like it should have much earlier and builds a completely new socket.
You can get this same behavior between two Linux systems. The server side goes:
socket(...)
listen(...)
accept(...)
read(...)
write(...)
shutdown( SHUT_RDWR )
close()
The client side goes:
socket(...)
connect(...)
write(...)
read(...)
write(...)
Note error
close(...)
socket(...)
connect(...)
In IE, steps 3 and 4 in the client handle one request. Step 5 is an attempt to handle the next request assuming that the server handles persistent connections. Step 6 is where IE notices that the server doesn't do persistent connections.
The right thing to do would be to notice the HTTP version and lack of a Connection: header indicating support for persistent connections in the response and close the connection upon receipt of the response. IE is stupid in not handling non-persistent-connection servers as it should, but it's not violating or even bending the TCP protocol spec in any way. It's just stupid coding.
No, what's described is a plain vanilla half-close of a standard TCP connection. The server called shutdown(), sends a FIN, the client stack ACKs it. The browser doesn't call shutdown(), hence it doesn't generate any FIN packet for it's half of the connection. It's entirely acceptable from a TCP-protocol standpoint, although highly annoying.
If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it. If the server doesn't support persistent connections, it's free to close it's end of the connection. The browser is supposed to see this, close it's end and open a new connection for the next request, but it's possible IE is simply assuming persistent connections and only doing the close-and-reopen when it sees an error sending the additional requests. My guess is that they combined error-recovery ("the connection died, close it, open a new one and retry the request") with handling servers that don't support persistent connections ("server closed the connection, close our half and open a new one for this request").
Unless they've taken it into account, eg. the way the FSF does with their GPL'd software. And note that you can use the results, it's just the code itself that would be GPL'd. Eg. if a company wanted to use a GPL'd protocol stack without negotiating a different license, they could simply taken the protocol definition and do a clean-room implementation of it.
(You may need to review the GPL if you don't get this -- the point of the GPL is to make it so that derivative works CAN'T be relicensed, yet you say that MS should just get the IP relicensed... Anybody else see the problem here?)
No problem. Remember that the original author of the code isn't bound by the GPL. If I wrote the code and released it under the GPL you can't relicense it, but I can release it under any other licenses I want.
Why is it a different story? The taxpayers paid for it, precisely why should a business be allowed to profit from it without paying royalties back in one form or another? What MS is asking is to be allowed to reap the profits while letting the taxpayers foot the bill. Sorry, that's not kosher in my book. And yes, we did lose something when MS used software developed by the DoD and NASA without paying: we lost the funds that went into developing it and that aren't being recouped.
And it still comes back to, if the stuff was put out under the GPL, the company can go back to the agency that did the work and negotiate a license other than the GPL.
Personally I think something along the lines of the LGPL, or a modified BSD license which requires that the software being used and any modifications/enhancements to it be made available under the terms the original software was gotten under, would be more appropriate than the GPL. It still boils down to, a private company should not be able to take taxpayer-funded property and use it to make a profit without some of that profit going back to the taxpayers in some way.
Actually the GPL doesn't prevent companies from using the covered IP in their products. What it does do is force them to negotiate a suitable license from the original author of the covered IP (if they don't want to give away their own IP, that is). The big advantage to companies of the BSD license is that they can use the covered IP without negotiating with the original author and probably having to pay for the IP they use. That's the heart of MS's position: they want to be able to use everybody else's IP for free while still forcing everyone else to pay to use MS IP.
We already know the massive evil the BSA is trying to push. They want people to "borrow" copies of software until they've used it enough to come to depend on it. Then they can shake down the businesses (and the occasional individual) for the money with that dependence as leverage ("Isn't it cheaper to pay us danegeld than to have to completely change your entire company's software systems out?").
That's why they don't want working DRM: it cuts off that all-important first step. We all know the licensing fees are getting expensive. Right now companies get off cheaply by fudging the licensing until they're dependent on the software. With working DRM applied to software companies would wind up facing that huge licensing bill immediately, and the beancounters balk and say "Well, we haven't built anything yet, can't we find a cheaper alternative to start with?".
I take the exact, unchanged text of a book and include it in it's entirety in a book of my own, making references to that included text in my own, analyzing it and otherwise using it without modifying it.
I publish a similar book but do not include the original book's text, merely sell a copy of it in a package with mine.
Which of those uses would be a derivative work? The first corresponds, IMO, to static linking, the second to linking a shared-object library. I'd guess the courts would consider the first to definitely be a derivative work, the second not. Note that in the article's quote from copyright law, it explicitly says that annotations and elaborations are derivative works and those can be done without modifying the original.
Even if it isn't a derivative work, the same line winds up being drawn. If it's not a derivative work, then the license for the original library (the GPL) still applies to it. Since term 2 grants the right to modify the copy the recipient received, you could argue that if the recipient cannot modify (by modifying the code, recompiling and relinking) the copy in your program you're not complying with term 2 of the GPL when you distributed the library as part of your program. I'm sure the lawyers would love to argue that in court, it'd provide endless billable hours.
Slashdot Mirror
One difference between driving and the Internet is that they don't put student drivers in cars out on the highways. At least not right off. First, you sit in a classroom and learn, from lectures and reading, the theory of the basics. Then they give you a test to make sure you've actually absorbed the basics. Then they put you in a simulator. Then, if you pass the simulator, they put you in a car in a closed lot with no other cars around and see if you can put all that theory into practice without being too dangerous. Then, only after you've passed all that, do they let you out on the highway, and even then only with an experienced driver along for the first few months.
Imagine the howls if we imposed the same rules for Internet access...
Because AOL gave millions of people who had no clue about the Internet access to the Internet. This is much akin to taking several million people who have no clue how to drive, giving them shiny new high-performance cars and dumping them on the freeways.
Queueing and local delivery. On my system the mailserver is local-service-only. It queues mail from the clients (Pine and Mozilla) for delivery, and handles local delivery of mail retrieved via fetchmail. The first improves reliability, since mail is safely queued if there's any transient problems (most clients have inadequate provisions for saving mail if it can't be sent immediately), and the second gives me the ability to do processing via procmail easily (not to mention the ability to use e-mail locally for notifications and reporting).
Note that it's physically impossible for my mailserver to relay spam. First, it's configured to refuse to relay. Second, even if it would relay it's configured not to listen on the external interface. Third, even if it were listening the firewall would prevent the outside world from connecting to port 25.
Then you may have a problem, because most non-Linux vendors won't offer you that indemnity either. As MS customers are finding out with the SQL Server lawsuits, for example. At least with RedHat you have the ability to produce the source to prove it's not the suing party's software.
What the patent describes is the use of a public-key cryptosystem to sign a document. That was well-known a decade before the patent was applied for. His patent fails both on obviousness and originality.
That's only an issue if you don't know the ISP's policies. If they publish their policies and you sign up knowing them, then presumably you don't disagree with them too much. If you want an ISP that allows everything through, you wouldn't sign up with one with a draconian filtering policy.
For myself, I'm happy my ISP applies some fairly extensive filtering to remove spam, applies more that flags messages in the headers so I can drop it myself if I want, and has a setup where I can do my own filtering on top of that. I'd be rather annoyed if someone tried to tell me my chosen ISP couldn't do the things that convinced me to go with them in the first place.
Of course Intuit's not showing a hit on profits yet. Most of the people who are complaining already bought the software before they found out about the problems (from someone else if they were lucky, the hard way if they weren't). What Intuit needs to question is what effect this will have on next year's profits, when the people who complained this year buy some other tax software package instead of TurboTax. Of course, by that time nobody will make the connection between declining sales and the screw-up 12 months before
The parts about Google's cookies may or may not be worth worrying about, but then Google works just fine if you block cookies from it so it's not hard to prevent any potential problems. The rest is paranoid handwaving amounting to "Google lets anyone in the world find out exactly what I said even if I don't want them to!". I fail to see the problem in that.
I'm sorry, but Verisign should have their status as both registrar and root nameserver operator revoked after this. We depend on being able to tell when a DNS name doesn't exist. The master nameservers for two of the biggest TLDs should never, I repeat never, lie to us about that by returning a record when no such record exists for the name queried.
What Verisign's doing is the equivalent of the phone company responding to a 411 request for a name that isn't in the phone listings not with "I'm sorry, we don't have a listing for that name." but with "The number is .".
Just remember that Lindows is not, according to the GPL, required to provide source code to the world. They're required to provide source code to anyone who they distribute a product based upon GPL'd software to. Since their product is only available via purchase, they're allowed to restrict access to the source code to only those who've purchased their product.
They're not, of course, allowed to prohibit you from redistributing the GPL-software-derived parts of their distribution, and the accompanying source code, after you've purchased it. They can only put that restriction on the parts that they created that aren't touched by the GPL.
It depends, but generally yes I would be held liable. I probably wouldn't face criminal charges if the modifications were such that they wouldn't be immediately apparent, but I'd still have to pay for damages and injuries and such (or my insurance would). I would, however, likely be able to hold you liable for the modifications, and be able to sue you to recover what I'd had to pay out. I'd possibly also be able to sue the manufacturer for making a faulty product.
As far as expectations about computers go, they're irrelevant. Computers running lots of software are inherently complex, in the same way and for the same reasons that a 747 is complex to operate. You can make it easier, but you can't make it less complex without making it incapable of doing it's job. Either you adapt your expectations to reality, or reality will continue to smack you.
And when did people get stupid? I can remember when secretaries were expected to be able to write fairly sophisticated macro programs for Lotus 1-2-3 or WordPerfect. And they did it well, often better than professional programmers could. When did it become acceptable to not know how to use a tool you need to use to do your job?
However, the manufacturers of most computer software have NOT made efforts to make the software trivially easy to secure. Even for those with grea expertise, it requires significant effort (many settings, checks tests, etc.). Thus, holding a normal user responsible for the actions of a hijacked computer is unreasonable.
Invalid argument. In any other area, if you operate something that you know you aren't qualified to operate and damage property with it, you won't be held not responsible because you couldn't have been expected to operate it properly. Quite the opposite, you'll very likely face even more severe penalties.
Yes, we should hold vendors liable, just like we hold manufacturers liable if they make a faulty product. But we should also hold users liable for either knowing how to use their systems or getting advice and aid from someone who does. "I didn't know how to drive." doesn't cut it, "I don't know how to use a computer properly." shouldn't either.
First, you don't need to be licensed to be an auto mechanic. Those certifications the mechanic has up are there to show off. Whether they mean anything depends on the certificate and who issued it, but none of them are required to work on cars. Of course people do make decisions based on them (eg. not taking their new car to a mechanic who doesn't have a certification from the car's maker).
Second, the certificates for hairdressers and such have nothing do to with how well they do their jobs. The certifications are about making sure the certified isn't a hazard to the public (the customers). The certificate says your hairdresser knows and follows the rules about cleanliness of the tools and such, but whether they can cut your hair without butchering it is outside the scope of the certification.
Given those two things, there's not much parallel in the parallels the article's author is drawing. Myself, I think certification would be good, but only if it concentrated on practical tests (ie. no questions to answer, your test is to be given a bench and a broken PC and you have to fix it while an instructor grades you on whether you followed anti-static and other safety procedures, whether the work was done right and (most importantly) whether the PC actually worked when you were done).
It looks like the server is sending an HTTP 1.0 version in the response, though, which makes the relevant RFC 1945, not 2616. IE should be checking the HTTP response version to determine whether it's in fact HTTP 1.1, or it should be checking the readability of the socket before writing (to detect an HTTP 1.0 server closing the connection after the response).
You failed to read all of RFC793. When the server sends a FIN to the client, the client is required to ACK it, but the client is not required to send a FIN to the server at that point. If the client doesn't close it's half of the connection (triggering the send of it's FIN packet), it's allowed to continue to write. That's why the shutdown() socket call takes an argument indicating whether to close the read half, the write half or both halves of the connection. Of course, if the server has completely closed and disposed of the socket on it's end, incoming packets will fail to match a connected socket on the server and an RST will be generated.
It was thought more likely to work the other way, with the browser sending a FIN packet to the server immediately after sending it's request, closing the browser-to-server half of the connection, and the server would then send the response back down the server-to-browser half of the connection before sending it's FIN packet to the browser to complete closing the connection. As it turns out, things took a different route and the opposite happens.
It is being set up properly. What happens is that the browser hasn't closed it's half of the connection. When the next request happens it tries a TCP write, but since the server side has closed the connection the write fails. That's what's confusing the blog author, they're not familiar with the TCP protocol. A TCP connection has two halves and it's entirely legal to close one half but not the other, leaving a socket that can be read from but not written to (or vice versa). IE doesn't check for the server-side close like it should, treats the socket as if it's writable (which it is) and writes to it. Since the server's closed the socket on it's end, that attempted write generates an RST (which is TCPly correct), the browser gets a write error and finally notices that it's connection has been closed by the remote end, closes everything down like it should have much earlier and builds a completely new socket.
You can get this same behavior between two Linux systems. The server side goes:
- socket(...)
- listen(...)
- accept(...)
- read(...)
- write(...)
- shutdown( SHUT_RDWR )
- close()
The client side goes:- socket(...)
- connect(...)
- write(...)
- read(...)
- write(...)
- Note error
- close(...)
- socket(...)
- connect(...)
In IE, steps 3 and 4 in the client handle one request. Step 5 is an attempt to handle the next request assuming that the server handles persistent connections. Step 6 is where IE notices that the server doesn't do persistent connections.The right thing to do would be to notice the HTTP version and lack of a Connection: header indicating support for persistent connections in the response and close the connection upon receipt of the response. IE is stupid in not handling non-persistent-connection servers as it should, but it's not violating or even bending the TCP protocol spec in any way. It's just stupid coding.
No, what's described is a plain vanilla half-close of a standard TCP connection. The server called shutdown(), sends a FIN, the client stack ACKs it. The browser doesn't call shutdown(), hence it doesn't generate any FIN packet for it's half of the connection. It's entirely acceptable from a TCP-protocol standpoint, although highly annoying.
If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it. If the server doesn't support persistent connections, it's free to close it's end of the connection. The browser is supposed to see this, close it's end and open a new connection for the next request, but it's possible IE is simply assuming persistent connections and only doing the close-and-reopen when it sees an error sending the additional requests. My guess is that they combined error-recovery ("the connection died, close it, open a new one and retry the request") with handling servers that don't support persistent connections ("server closed the connection, close our half and open a new one for this request").
Unless they've taken it into account, eg. the way the FSF does with their GPL'd software. And note that you can use the results, it's just the code itself that would be GPL'd. Eg. if a company wanted to use a GPL'd protocol stack without negotiating a different license, they could simply taken the protocol definition and do a clean-room implementation of it.
(You may need to review the GPL if you don't get this -- the point of the GPL is to make it so that derivative works CAN'T be relicensed, yet you say that MS should just get the IP relicensed... Anybody else see the problem here?)
No problem. Remember that the original author of the code isn't bound by the GPL. If I wrote the code and released it under the GPL you can't relicense it, but I can release it under any other licenses I want.
Yes you can. This was settled in court back in the IBM vs. Phoenix case.
Why is it a different story? The taxpayers paid for it, precisely why should a business be allowed to profit from it without paying royalties back in one form or another? What MS is asking is to be allowed to reap the profits while letting the taxpayers foot the bill. Sorry, that's not kosher in my book. And yes, we did lose something when MS used software developed by the DoD and NASA without paying: we lost the funds that went into developing it and that aren't being recouped.
And it still comes back to, if the stuff was put out under the GPL, the company can go back to the agency that did the work and negotiate a license other than the GPL.
Personally I think something along the lines of the LGPL, or a modified BSD license which requires that the software being used and any modifications/enhancements to it be made available under the terms the original software was gotten under, would be more appropriate than the GPL. It still boils down to, a private company should not be able to take taxpayer-funded property and use it to make a profit without some of that profit going back to the taxpayers in some way.
Actually the GPL doesn't prevent companies from using the covered IP in their products. What it does do is force them to negotiate a suitable license from the original author of the covered IP (if they don't want to give away their own IP, that is). The big advantage to companies of the BSD license is that they can use the covered IP without negotiating with the original author and probably having to pay for the IP they use. That's the heart of MS's position: they want to be able to use everybody else's IP for free while still forcing everyone else to pay to use MS IP.
We already know the massive evil the BSA is trying to push. They want people to "borrow" copies of software until they've used it enough to come to depend on it. Then they can shake down the businesses (and the occasional individual) for the money with that dependence as leverage ("Isn't it cheaper to pay us danegeld than to have to completely change your entire company's software systems out?").
That's why they don't want working DRM: it cuts off that all-important first step. We all know the licensing fees are getting expensive. Right now companies get off cheaply by fudging the licensing until they're dependent on the software. With working DRM applied to software companies would wind up facing that huge licensing bill immediately, and the beancounters balk and say "Well, we haven't built anything yet, can't we find a cheaper alternative to start with?".
Take two scenarios in books:
Which of those uses would be a derivative work? The first corresponds, IMO, to static linking, the second to linking a shared-object library. I'd guess the courts would consider the first to definitely be a derivative work, the second not. Note that in the article's quote from copyright law, it explicitly says that annotations and elaborations are derivative works and those can be done without modifying the original.
Even if it isn't a derivative work, the same line winds up being drawn. If it's not a derivative work, then the license for the original library (the GPL) still applies to it. Since term 2 grants the right to modify the copy the recipient received, you could argue that if the recipient cannot modify (by modifying the code, recompiling and relinking) the copy in your program you're not complying with term 2 of the GPL when you distributed the library as part of your program. I'm sure the lawyers would love to argue that in court, it'd provide endless billable hours.