The court and representation for each side talk and negotiate deadlines for particular stages of the trial. I imagine that there are common standards for each stage. The judge and Red Hat have interests in seeing Red Hat's case executed in a timely manner, so it would be somewhat difficult for SCO to extend the deadlines greatly.
It is possible to file motions or amended actions later to delay or reset the clock. If the judge believes they have merit, it will go through[1]. If a party to a lawsuit submits many such motions and they are largely frivolous or unwarranted, it may count as vexatious litigation. If a judge considers something vexatious litigation, he or she will generally sanction the offending party. Sanctions can many forms[2].
IANAL, etc.
[1]- For example, SCO recently got a delay in its trial versus IBM so that it could perform due diligence and research in their counter-defense. [2]- Monetary fines are common, but others are possible. The US prosecutors in the Zacarias Moussaoui were barred from seeking the death penalty or introducing broad classes of evidence when the government refused to comply with a court order to give him direct access to certain terrorist suspect-detainees.
Bandwidth and routing functions are not problems -- the radio function is the problem. Traditionally, decoding the modulated signal (finding the carrier and recovering likely bits) was done in dedicated hardware. Sometimes, Viterbi or other maximum-likelihood decoding is also done in hardware. WIth current PCs -- especially with SIMD instructions like the SSE family -- the demodulation function can be implemented mostly in software.
The practical effect is that instead of having a (hardware) platform that works only with certain encoding and modulation standards, you have a (software) platform that works with many. It is easier to produce software than hardware at the scales needed, and it allows for an easier upgrade path.
My bet is they have a legal DDOS already planned to sue every single one of IBM's customers. By IBM providing indeminification, they would be swamped responding to the individual claims.
I believe IBM could trivially combine such complaints, since the subject matter and parties would be identical; IBM might even get to pick the jurisdiction out of all those where complaints were filed. That kind of stunt would be counter-productive, except to increase the amount of damages that SCO could claim -- and we all know how unlikely it is that SCO will be awarded any damages.
As Otter pointed out in a separate post, broadcast television stations are granted monopolies by government.
Cable providers (and telephone service providers) are also granted monopolies, and individual users also pay for those services. Barriers to entry are so high that you have to be significantly invested in that commercial exchange before you can compete for those licenses.
In comparison, you can choose an independently operated school much more easily than you can choose an independently operated TV or even print news source.
To switch tracks a bit, think back to Popeye eating spinach and becoming amazingly strong. Imagine instead he chugged a can of some corn syrupy brand-name beverage aimed at kids. Why should the show's producers be able to take secret kickbacks from SyrupCo for that? The request is not to forbid that kind of exchange, but to require disclosure.
Next I suppose you'll be saying that parents should not complain when their children's schools are filled with advertisements for and machines selling unhealthy foods with big brand names -- after all, we have to pay for schools somehow. It would be inappropriate for parents to complain to the school board, since that kind of decision might be made at the school level rather than the district level. Complain to the principal, who is already probably overworked and trying to balance too many things at once!
Why should the government impose any limits at all on advertising? If enough people die from taking drugs for a condition where the drug hurts rather than helps, people will stop buying that drug, right?
Government intervention may be appropriate here because product placement is a form of commercial speech, and courts have recognized that the government has legitimate interest in limiting some forms of commercial speech. The steps you hypothesize for the market to limit the product are naive: How many old TV shows or movies stopped using cigarettes because they caused lung cancer?
Maybe you appreciated Microsoft doing that. I thought Microsoft dumping OS/2 was a cheap and dirty stunt, and indicative of Microsoft's growing monopoly -- and Microsoft's tendency to abuse that monopoly. Microsoft had a contract to develop OS/2 with IBM, semi-secretly developed NT behind the scenes, and chose to shaft IBM just to consolidate their control over the OS market.
I certainly didn't like Windows then, and Windows NT 3.1 was vastly inferior to the OS/2 of its time (despite its chintzy "OS/2 1.x support" personality). If Microsoft had focused its "innovation" in the direction of OS/2 instead of NT, I suspect the world today would be much better for end users.
I told my officemate (born in Russia, lived there most of his life) about IBM's "new" counterclaim and the claim by the same spokesman that SCO owns C++. He said that in Soviet Russia, there was a slogan to demonstrate that everything originally came from their country: "Russia is the motherland of the elephant." I think Darl McBride & Co. need a similar slogan: "SCO is the inventor of the elephant."
I hope you're joking. If you ever filed a patent application, you would know otherwise. The claims -- which is all that most/.'ers ever see from a patent -- are by definition concepts with little in the way of implementation details. However, the bulk of a patent application's information content is the exemplar that accompanies the claims.
In the old days, you had to send in an actual working device. Nowadays, you have to document the device, its construction and its operation in sufficient detail to let another practitioner (re-)create the device. This involves a detailed written description, anywhere from a few pages to a few hundred pages.
Reportedly, his access to the NYT systems was by using publically accessible proxy servers. Saying he needs prior authorization to do that is naive -- do you need prior authorization to access arbitrary mail or web servers on the Internet? Leaving the systems open is prima facie authorization. There would have to be some indication that only NYT employees (or whomever) were authorized to use the system.
You are amused that he uses the same tactics to access many poorly secured networks. Does it not worry you that so many networks are poorly secured in identical ways? I believe that is a much more significant issue.
You are further amused that he does it not for money, but for publicity. HELLO MCFLY. There are an unknown number of other systems just waiting for someone to break into them. If Mr. Lamo publicizes the existence gaping security problems (especially after working to help close the specific examples he finds), it encourages other businesses to close their holes. Without him, many of them would rather than sit fat and lazy and hope whoever penetrates them gets caught.
That publicity also brings business to the security professions who you think consider him a joke. Talk about biting the hand that feeds you.
That kind of concern is why each side can (and will) bring expert witnesses to the stand -- to support or rebut the claims of infringement.
At least in other cases, each side must present its expert witness testimony in advance and give the other side a chance to rebut it. If SCO finds an expert witness who is unaware of certain code's provenance, and uses him, IBM can shoot down that witness by asking "Are you aware that XYZ submitted this code to Linus on June 32 of 199-, with the comment that drunken monkeys in his basement wrote it from scratch? Do you have any first-hand knowledge that the code has other provenance?" Either the expert witness will admit the truth or it will be the last time that expert witness ever testifies in court.
For all the silly choices the American legal system makes, it is not as easily manipulated as some people seem to think -- especially when both sides have considerable money to throw at the problem.
Except that downloading ISOs from an FTP site is technically copying it. So anyone who doesn't order copies on a CD is technically copying their (?) code.
I assume you have specific example from case law that supports this? It seems to me that the FTP server is making the copy, and the responsibility would tend to lie with the administrator of that machine.
Not to mention that if someone buys a "pirated" movie copy, they do not get to keep it when they are found out, even if they believed the transaction was legitamate.
Could you provide an example of when a court ordered this?
SCO tends to complain about "intellectual property" without identifying the particular genus of IP that they believe is infringed. There are roughly four classes of IP claims: copyright, trade secret, trademark and patent infringement.
End users cannot infringe on a copyright unless they make unauthorized copies of the work -- users at home tend not to do this, but corporate users make enough copies that SCO could (if you assume they have a valid claim to copyright in the first place) claim that the corporate users infringe.
A person is only liable under trade secret or breach of contract laws if he is party to a contract or has reasonable knowledge that the information is protected. Someone who simply uses the Linux kernel would be safe from such a claim, as would a majority of developers.
SCO has no apparent basis to assert a trademark infringement complaint, so end users are safe there too.
SCO has not mentioned ownership rights in any patents -- in fact, most of the relevant patents seem to be assigned to companies they might sue. Here again, Linux users appear safe.
(ObDisclaimer: I am not a lawyer. If you want legal advice, retain counsel and ask for opinions specific to your situation.)
The response is directed more at the plaintiff and his lawyer than at the judge. It enumerates some reasons that we contest the complaint's claims, but it does not give the details. Until we go through the discovery process, it is not useful to be specific in why we mention those defenses.
James has acted in concert with the rest of the board from the time we transferred the domain to the current time. Among other things, he played a significant role in helping us locate the attorney we retained for our defense.
A rather more important flaw is that if there is even a minor change -- something like renaming a variable, adapting to use a native interface, or inserting a comment -- the MD5 will no longer match. Such changes could be made either before or after the code is added to one source tree, and could be done intentionally to hide similarities or as part of normal maintenance or development.
A number of computer science professors and instructors use software to find similarities between submitted code, in an effort to catch cheaters. This varies in complexity, but a live OS kernel being developed by dozens or hundreds of people is likely to have even more change than that kind of software will pick up.
On the other hand, the idea of "convergent evolution" from biology also applies to software -- especially when you implement a strongly structured standard interface like POSIX or SuS. The semantics of certain system calls dictate parts of their structure.
Re:what ?
on
Linus on DRM
·
· Score: 3, Interesting
Saying "external keys are fine" is debatable -- the GPL limits what you can do with derivative works of GPLed software, not what you can do with software's executable form. A signature permitting execution of a kernel binary is not useful in any connection other than trying to use the kernel. It is reasonable to say that this makes the signature a derivative work, and therefore subject to the GPL's "preferred format for modification" clause.
This is a good basis for distinguishing between the "good" and "bad" uses of software: If the signature is a way of identifying and asserting your trust in the software to other humans, it is a form of speech rather than a derivative work. If the signature is a way of telling a device how to operate, it is not speech -- merely a derivative work.
Seeing as it is possible to to illicit a DoS or due to poor program design actualy crash applications with a simple port scanning then you have to question if its even a gray area, ie if you do damage its bad, if not your ok.
That is really a crock. If a program crashes because of data it receives from the network, it is buggy, and should be fixed. Unless the sender sends data with the intention to interfere with the scanned machine's operation, it is silly to blame the sender for damage. This is a common criteria for laws: certain actions are forbidden only if there are "bad" intentions, as can be demonstrated in a court.
Yes.. obviously, being able to talk to millions upon millions of people (at least potentially) is a deficiency in the Internet. The lack of strong cryptographic authentication in a 20 year old protocol is a deficiency in the late Jon Postel's design abilities. Finally, the not-so-commonness of common courtesy is a deficiency in the human species.
SMTP and email format are both essentially 20 year old protocols. There are two reasons they are still used. First, it is expensive to replace that much software (and sometimes hardware). Second, it basically works. Can you imagine how much less productive the world would be without email being so ubiquitous?
If you want a level playing field, apply the common rules of postal service to email: The sender must accurately identify themselves. The origin must be labelled (you know, the postmark). Sending huge volumes of mail to harass someone is against the law. Sending huge volumes of mail costs the sender considerably more than the receivers.
Do not claim that email is exempt from being legislated in ways specific to its new capabilities. It is different than what came before, and deserves to be treated as such.
That would vastly reduce the amount of USEFUL EMAIL as well. You would not believe what a large fraction of the Internet is configured to fail that kind of test -- or else you would not seriously contemplate that solution. Sometimes there are good reasons to configure a mail server that way.
DNS is not a terribly useful authentication mechanism for this kind of thing. Much more useful is origin-authenticated SMTP: the originator (either user or mail server) calculates a signed hash of the message, and attaches that when sending it. The receiver can verify that the signature is valid for the person (or mail server) that claimed to originate the message.
Obviously things lose in the transition period before every sender does that. You also get a huge fight over which algorithms to use, how to distribute and verify the public keys, and so forth. Welcome to Internet politics.
One could argue that reentry dynamics and airflow could make for a bumpy ride, thus the designers need to be aware of the journey this vessel's going to go on.
That actually occurred to me while I was writing my post, and I considered it to be an instance where my second paragraph bears true: if the ride will be bumpy, or flown upside down, or whatever, then those cases should be documented (or at least known) to the designers of the cockpit widgets.
Yes, you need to avoid both over- and under-design. Yes, you need to know things beyond your piece of the work. But no, you do not need to consider the whole system and all parts of it when you do implementation or even some of the design.
A good designer knows how far away the interaction horizon should be, and can analyze the effects of everything within that horizon. If the collective effects are too many to analyze, it is a sign that the design needs to be refined or reworked.
That's not entirely true. Right brained people can, thing is..
Being right-brained does not magically grant someone the ability to keep ten thousand things in their head at once. At best, it allows one the ability to easily defocus on things that are not important for what they do want to focus on -- in other words, to think abstractly.:)
The hard part of being a really good programmer is not learning how to do job X, Y or Z. The hard part is learning where to draw the interfaces, where you should use existing abstractions, and where you need to extend them or create new abstractions. This is true at most layers of design -- like Dr. Manhattan said, you can find abstraction layers and idealized interfaces at many different places in a complex (especially a computerized) system.
Keeping the "big picture" in mind is a good thing for managers and designers. For people implementing the finer details, though, it can be a distraction and a poor use of their time. Someone implementing or verifying flow control in a ground-to-space network link does not need to know much about the format of data carried over the link. Someone doing circuit layout or design for a cockpit control widget does not need to worry about reentry dynamics and airflow. Similar examples can be found in any large system design.
It is the responsibility of the higher level designers and managers to encapsulate the big picture into digestible, approachable chunks. To the extent possible, they should be aware of and codify the assumptions and requirements that cross multiple domains -- when those are documented, it is easier to test the system for correctness or robustness, as well as to diagnose problems.
When everyone on the project tries to orient their work to what they each perceive as the big picture, you end up with enough different perceptions that people work against each other. Breaking down the system into smaller, more defined, chunks combats that tendency.
Which is of course also nonsense - that people agree to it - but evidently the courts do care (or understand) how it really works. (I read your other links)
The question is not whether people really agree to it. Unless you sit them down and make them read and sign the EULA, you enter new ground in contract law. It becomes a question of what action(s), in the eye of the law, should bind a customer to the license.
You can argue what should indicate acceptance of the license, but courts may not (in general) enumerate what is allowed; they may only say whether some specific thing is or is not allowed, and then only when it is pertinent to a case in their jurisdiction. Until federal or state governments create laws (such as UCITA) on shrink-wrap or click-wrap licensing, it will be a legal gray area.
Since it is a gray area, and since (again in general) courts would rather err on the side of caution, end users can not expect much relief from court cases dealing with the legitimacy of EULAs.
How many cases do you want? One?Two?Three? A Google search for "shrink-wrap license court case" turns up these and others; judging from that, more shrink-wrap licenses have been upheld than overturned.
You might argue that some or all of those cases gave "no extra rights" to the licensee. Since you did not specify "extra rights" beyond anything in particular, I assume you wanted wiggle room to squirm out of concrete examples.
Slashdot Mirror
The court and representation for each side talk and negotiate deadlines for particular stages of the trial. I imagine that there are common standards for each stage. The judge and Red Hat have interests in seeing Red Hat's case executed in a timely manner, so it would be somewhat difficult for SCO to extend the deadlines greatly.
It is possible to file motions or amended actions later to delay or reset the clock. If the judge believes they have merit, it will go through[1]. If a party to a lawsuit submits many such motions and they are largely frivolous or unwarranted, it may count as vexatious litigation. If a judge considers something vexatious litigation, he or she will generally sanction the offending party. Sanctions can many forms[2].
IANAL, etc.
[1]- For example, SCO recently got a delay in its trial versus IBM so that it could perform due diligence and research in their counter-defense.
[2]- Monetary fines are common, but others are possible. The US prosecutors in the Zacarias Moussaoui were barred from seeking the death penalty or introducing broad classes of evidence when the government refused to comply with a court order to give him direct access to certain terrorist suspect-detainees.
Bandwidth and routing functions are not problems -- the radio function is the problem. Traditionally, decoding the modulated signal (finding the carrier and recovering likely bits) was done in dedicated hardware. Sometimes, Viterbi or other maximum-likelihood decoding is also done in hardware. WIth current PCs -- especially with SIMD instructions like the SSE family -- the demodulation function can be implemented mostly in software.
The practical effect is that instead of having a (hardware) platform that works only with certain encoding and modulation standards, you have a (software) platform that works with many. It is easier to produce software than hardware at the scales needed, and it allows for an easier upgrade path.
As Otter pointed out in a separate post, broadcast television stations are granted monopolies by government.
Cable providers (and telephone service providers) are also granted monopolies, and individual users also pay for those services. Barriers to entry are so high that you have to be significantly invested in that commercial exchange before you can compete for those licenses.
In comparison, you can choose an independently operated school much more easily than you can choose an independently operated TV or even print news source.
To switch tracks a bit, think back to Popeye eating spinach and becoming amazingly strong. Imagine instead he chugged a can of some corn syrupy brand-name beverage aimed at kids. Why should the show's producers be able to take secret kickbacks from SyrupCo for that? The request is not to forbid that kind of exchange, but to require disclosure.
Next I suppose you'll be saying that parents should not complain when their children's schools are filled with advertisements for and machines selling unhealthy foods with big brand names -- after all, we have to pay for schools somehow. It would be inappropriate for parents to complain to the school board, since that kind of decision might be made at the school level rather than the district level. Complain to the principal, who is already probably overworked and trying to balance too many things at once!
Why should the government impose any limits at all on advertising? If enough people die from taking drugs for a condition where the drug hurts rather than helps, people will stop buying that drug, right?
Government intervention may be appropriate here because product placement is a form of commercial speech, and courts have recognized that the government has legitimate interest in limiting some forms of commercial speech. The steps you hypothesize for the market to limit the product are naive: How many old TV shows or movies stopped using cigarettes because they caused lung cancer?
Maybe you appreciated Microsoft doing that. I thought Microsoft dumping OS/2 was a cheap and dirty stunt, and indicative of Microsoft's growing monopoly -- and Microsoft's tendency to abuse that monopoly. Microsoft had a contract to develop OS/2 with IBM, semi-secretly developed NT behind the scenes, and chose to shaft IBM just to consolidate their control over the OS market.
I certainly didn't like Windows then, and Windows NT 3.1 was vastly inferior to the OS/2 of its time (despite its chintzy "OS/2 1.x support" personality). If Microsoft had focused its "innovation" in the direction of OS/2 instead of NT, I suspect the world today would be much better for end users.
I told my officemate (born in Russia, lived there most of his life) about IBM's "new" counterclaim and the claim by the same spokesman that SCO owns C++. He said that in Soviet Russia, there was a slogan to demonstrate that everything originally came from their country: "Russia is the motherland of the elephant." I think Darl McBride & Co. need a similar slogan: "SCO is the inventor of the elephant."
I hope you're joking. If you ever filed a patent application, you would know otherwise. The claims -- which is all that most /.'ers ever see from a patent -- are by definition concepts with little in the way of implementation details. However, the bulk of a patent application's information content is the exemplar that accompanies the claims.
In the old days, you had to send in an actual working device. Nowadays, you have to document the device, its construction and its operation in sufficient detail to let another practitioner (re-)create the device. This involves a detailed written description, anywhere from a few pages to a few hundred pages.
Your argument falls flat on a number of points.
Reportedly, his access to the NYT systems was by using publically accessible proxy servers. Saying he needs prior authorization to do that is naive -- do you need prior authorization to access arbitrary mail or web servers on the Internet? Leaving the systems open is prima facie authorization. There would have to be some indication that only NYT employees (or whomever) were authorized to use the system.
You are amused that he uses the same tactics to access many poorly secured networks. Does it not worry you that so many networks are poorly secured in identical ways? I believe that is a much more significant issue.
You are further amused that he does it not for money, but for publicity. HELLO MCFLY. There are an unknown number of other systems just waiting for someone to break into them. If Mr. Lamo publicizes the existence gaping security problems (especially after working to help close the specific examples he finds), it encourages other businesses to close their holes. Without him, many of them would rather than sit fat and lazy and hope whoever penetrates them gets caught.
That publicity also brings business to the security professions who you think consider him a joke. Talk about biting the hand that feeds you.
That kind of concern is why each side can (and will) bring expert witnesses to the stand -- to support or rebut the claims of infringement.
At least in other cases, each side must present its expert witness testimony in advance and give the other side a chance to rebut it. If SCO finds an expert witness who is unaware of certain code's provenance, and uses him, IBM can shoot down that witness by asking "Are you aware that XYZ submitted this code to Linus on June 32 of 199-, with the comment that drunken monkeys in his basement wrote it from scratch? Do you have any first-hand knowledge that the code has other provenance?" Either the expert witness will admit the truth or it will be the last time that expert witness ever testifies in court.
For all the silly choices the American legal system makes, it is not as easily manipulated as some people seem to think -- especially when both sides have considerable money to throw at the problem.
I assume you have specific example from case law that supports this? It seems to me that the FTP server is making the copy, and the responsibility would tend to lie with the administrator of that machine.
Could you provide an example of when a court ordered this?
SCO tends to complain about "intellectual property" without identifying the particular genus of IP that they believe is infringed. There are roughly four classes of IP claims: copyright, trade secret, trademark and patent infringement.
End users cannot infringe on a copyright unless they make unauthorized copies of the work -- users at home tend not to do this, but corporate users make enough copies that SCO could (if you assume they have a valid claim to copyright in the first place) claim that the corporate users infringe.
A person is only liable under trade secret or breach of contract laws if he is party to a contract or has reasonable knowledge that the information is protected. Someone who simply uses the Linux kernel would be safe from such a claim, as would a majority of developers.
SCO has no apparent basis to assert a trademark infringement complaint, so end users are safe there too.
SCO has not mentioned ownership rights in any patents -- in fact, most of the relevant patents seem to be assigned to companies they might sue. Here again, Linux users appear safe.
(ObDisclaimer: I am not a lawyer. If you want legal advice, retain counsel and ask for opinions specific to your situation.)
The response is directed more at the plaintiff and his lawyer than at the judge. It enumerates some reasons that we contest the complaint's claims, but it does not give the details. Until we go through the discovery process, it is not useful to be specific in why we mention those defenses.
James has acted in concert with the rest of the board from the time we transferred the domain to the current time. Among other things, he played a significant role in helping us locate the attorney we retained for our defense.
A rather more important flaw is that if there is even a minor change -- something like renaming a variable, adapting to use a native interface, or inserting a comment -- the MD5 will no longer match. Such changes could be made either before or after the code is added to one source tree, and could be done intentionally to hide similarities or as part of normal maintenance or development.
A number of computer science professors and instructors use software to find similarities between submitted code, in an effort to catch cheaters. This varies in complexity, but a live OS kernel being developed by dozens or hundreds of people is likely to have even more change than that kind of software will pick up.
On the other hand, the idea of "convergent evolution" from biology also applies to software -- especially when you implement a strongly structured standard interface like POSIX or SuS. The semantics of certain system calls dictate parts of their structure.
This is a good basis for distinguishing between the "good" and "bad" uses of software: If the signature is a way of identifying and asserting your trust in the software to other humans, it is a form of speech rather than a derivative work. If the signature is a way of telling a device how to operate, it is not speech -- merely a derivative work.
That is really a crock. If a program crashes because of data it receives from the network, it is buggy, and should be fixed. Unless the sender sends data with the intention to interfere with the scanned machine's operation, it is silly to blame the sender for damage. This is a common criteria for laws: certain actions are forbidden only if there are "bad" intentions, as can be demonstrated in a court.
Yes .. obviously, being able to talk to millions upon millions of people (at least potentially) is a deficiency in the Internet. The lack of strong cryptographic authentication in a 20 year old protocol is a deficiency in the late Jon Postel's design abilities. Finally, the not-so-commonness of common courtesy is a deficiency in the human species.
SMTP and email format are both essentially 20 year old protocols. There are two reasons they are still used. First, it is expensive to replace that much software (and sometimes hardware). Second, it basically works. Can you imagine how much less productive the world would be without email being so ubiquitous?
If you want a level playing field, apply the common rules of postal service to email: The sender must accurately identify themselves. The origin must be labelled (you know, the postmark). Sending huge volumes of mail to harass someone is against the law. Sending huge volumes of mail costs the sender considerably more than the receivers.
Do not claim that email is exempt from being legislated in ways specific to its new capabilities. It is different than what came before, and deserves to be treated as such.
That would vastly reduce the amount of USEFUL EMAIL as well. You would not believe what a large fraction of the Internet is configured to fail that kind of test -- or else you would not seriously contemplate that solution. Sometimes there are good reasons to configure a mail server that way.
DNS is not a terribly useful authentication mechanism for this kind of thing. Much more useful is origin-authenticated SMTP: the originator (either user or mail server) calculates a signed hash of the message, and attaches that when sending it. The receiver can verify that the signature is valid for the person (or mail server) that claimed to originate the message.
Obviously things lose in the transition period before every sender does that. You also get a huge fight over which algorithms to use, how to distribute and verify the public keys, and so forth. Welcome to Internet politics.
One could argue that reentry dynamics and airflow could make for a bumpy ride, thus the designers need to be aware of the journey this vessel's going to go on.
That actually occurred to me while I was writing my post, and I considered it to be an instance where my second paragraph bears true: if the ride will be bumpy, or flown upside down, or whatever, then those cases should be documented (or at least known) to the designers of the cockpit widgets.
Yes, you need to avoid both over- and under-design. Yes, you need to know things beyond your piece of the work. But no, you do not need to consider the whole system and all parts of it when you do implementation or even some of the design.
A good designer knows how far away the interaction horizon should be, and can analyze the effects of everything within that horizon. If the collective effects are too many to analyze, it is a sign that the design needs to be refined or reworked.
That's not entirely true. Right brained people can, thing is..
Being right-brained does not magically grant someone the ability to keep ten thousand things in their head at once. At best, it allows one the ability to easily defocus on things that are not important for what they do want to focus on -- in other words, to think abstractly. :)
The hard part of being a really good programmer is not learning how to do job X, Y or Z. The hard part is learning where to draw the interfaces, where you should use existing abstractions, and where you need to extend them or create new abstractions. This is true at most layers of design -- like Dr. Manhattan said, you can find abstraction layers and idealized interfaces at many different places in a complex (especially a computerized) system.
Keeping the "big picture" in mind is a good thing for managers and designers. For people implementing the finer details, though, it can be a distraction and a poor use of their time. Someone implementing or verifying flow control in a ground-to-space network link does not need to know much about the format of data carried over the link. Someone doing circuit layout or design for a cockpit control widget does not need to worry about reentry dynamics and airflow. Similar examples can be found in any large system design.
It is the responsibility of the higher level designers and managers to encapsulate the big picture into digestible, approachable chunks. To the extent possible, they should be aware of and codify the assumptions and requirements that cross multiple domains -- when those are documented, it is easier to test the system for correctness or robustness, as well as to diagnose problems.
When everyone on the project tries to orient their work to what they each perceive as the big picture, you end up with enough different perceptions that people work against each other. Breaking down the system into smaller, more defined, chunks combats that tendency.
The question is not whether people really agree to it. Unless you sit them down and make them read and sign the EULA, you enter new ground in contract law. It becomes a question of what action(s), in the eye of the law, should bind a customer to the license.
You can argue what should indicate acceptance of the license, but courts may not (in general) enumerate what is allowed; they may only say whether some specific thing is or is not allowed, and then only when it is pertinent to a case in their jurisdiction. Until federal or state governments create laws (such as UCITA) on shrink-wrap or click-wrap licensing, it will be a legal gray area.
Since it is a gray area, and since (again in general) courts would rather err on the side of caution, end users can not expect much relief from court cases dealing with the legitimacy of EULAs.
How many cases do you want? One? Two? Three? A Google search for "shrink-wrap license court case" turns up these and others; judging from that, more shrink-wrap licenses have been upheld than overturned.
You might argue that some or all of those cases gave "no extra rights" to the licensee. Since you did not specify "extra rights" beyond anything in particular, I assume you wanted wiggle room to squirm out of concrete examples.