/. doesn't do subtlety - so that one-word "who?" which should be modded up to a +5 is probably destined to languish unappreciated - but at least it happened in a discussion of great almosts.
Re:NFS - history ignored
on
HyperSCSI Examined
·
· Score: 5, Interesting
That's a good point, and needs a bit more modding up.
It's worth adding, however, that the hyperSCSI folks are trying to make a distinction between wider-area networks (which they call SWANs for Storage WAN) and local single-segment (since they aren't routing) networks, and arguing that iSCSI is right for the former and hyperSCSI, because it's faster/cheaper, for the latter.
This view has parallels in the history of NFS over TCP versus NFS over UDP, because NFS/UDP is still hanging on in one niche: short-haul, high-speed, low-latency, few-hops, negligible-loss environments.
It also has parallels with the bad old days when direct-attached storage interconnects were much faster than LANs, so one set of protocols (FCP, SCSI, ESDI, IDE, SIMD...)evolved on the short fat pipes used to connect computers to peripherals, and a completely different set of protocols (ethernet, TCP/IP, SDLP,...) evolved for the long thin pipes used to connect computers to one another. Similarly, hyperSCSI is an argument that the two domains are different enough to justify different protocols. That seems to be arguing against a historical trend tht says that the short/fat and long/thin differences are vanishing; compare gigE and fibrechannel as _wires_ today.
All of this just reinforces Bourne's general point about ignoring the history. It's pretty clear that NFS over TCP is where the world is going, and the only reason that there's an NFS over UDP hanging around is that's how all NFS used to be, so some still is. When we compare hyperSCSI to iSCSI over TCP, I can't find any reason not to just deploy iSCSI everywhere and be done with it.
First, Ethernet can't be routed, so hyperSCSI isn't going to be nearly as flexible as iSCSI. This is the reason that just about everything that might want to be routed is usually carried over IP (and TCP and UDP and other stuff on top of IP). Straight ethernet is for stuff like ARP that really doesn't want to leave a network segment.
Of course, one could reasonably do something hyperSCSI-like across IP, and still save the TCP overhead. (Consider that in a low-loss short-hop environment, NFS over UDP generally outperforms NFS over TCP). The problem here is that SCSI was never ever intended to run well over a lossy transport, and it doesn't. That seems a serious objection to running SCSI over both non-routable and non-reliable ethernet and routable but still non-reliable IP.
C'mon, there's a reason why people use TCP.... And why iSCSI chose TCP as the transport....
Thus, the "license breaker" could not be
forced to release their own source code.
This is quite true, and not in the least bit controversial. No (legally clueful) person has ever seriously argued that the GPL could be used to force someone to release their source code, and indeed the next-to-last paragraph of section 2 of the GPL says that that's not the intent.
It's really all simpler than it looks: If it's copyrighted, the default, no-license, no-GPL, simple ordinary, I wrote it so it's mine to decide what to do with it, rule, which applies to great novels as well as great software, is that you can't distribute it without the author's permission. The GPL is the author's permission. You don't have to accept the GPL, but if you don't, you don't have permission to redistribute the GPL'd work; you're back in the default no-permission case.
And if you distribute something without permission? A court can make you stop. A court can make you pay the copyright holder monetary damages (unlikely in a GPL case, since it's unlikely that the copyright holder suffered any monetary damage, but possible). But make you distribute your own work? No way. It's your work, and your infringement of someone else's copyright doesn't change that.
Of course, once you consider the implications of the court's ruling, you may choose to release your modification along with the GPL'd code you started with. That's what RMS would like you to do, and since the alternative is not distributing at all, it may be the easiest answer. But it's not mandatory.
Think about it. What permissions are implicitly offered by the author, without reference to the GPL? I think that there are a great many circumstances in which a judge can find that GPL'd software has effectively been released into the public domain. There are two basic misunderstandings here.
First, this notion of "public domain".... There is only one way that a copyrighted work enters the public domain, and that is when the copyright expires. That's (one reason) why Apache is distributed under a license that says that you may do anything you please with the code: the license is the only way of giving that permission. When the copyright on the code expires, decades hence, then it will enter the public domin and the Apache license will be redundant. But until then, the code is copyrighted, and only the Apache license gives you the right to do anything with it.
Second, there is no such thing as "implicitly offered" permissions in this context. Copyright law says that you have no permissions to copy a copyrighted work, except as allowed by a license from the copyright holder or under the copyright law notion of "fair use". It's fair use that allows book reviewers to quote snippets of the reviewed work, students to use properly footnoted quotations, and that allows people to freely quote newsgroup postings in their replies, and generally allows all the other things that are "obviously" OK.
Since legally a company is an individual, these cases aren't "gray" at all. The first two are not distribution (provided that the modified program is only used in the operations of the company; if an employee takes it home for personal use, that's a distribution to that employee). The third is distribution.
Nonetheless, with a little work, you will be able to construct a hypothetical case that really is "gray". This has nothing to do with the GPL; it's just the way law works. No matter how sharp and clear a line is, it will show up as a broad gray area if viewed at sufficently high resolution. When court decisions and legislative action draw a new and sharper line through this gray area, all we have to do is crank up the magnification again to turn the new line into a gray area. (If you aren't already, you should be thinking "fractal decomposition").
This recurrence of "gray areas" doesn't matter, because the law is not a machine preprogrammed with answers for all legal questions. It's a machine for resolving disputes, and any given dispute will be resolvable at some level in the fractal decomposition.
Correct me if I'm wrong, but I don't recall that IIS is installed by default in Win2000. Is it in NT (I don't remember)?
It is installed by default with W2K Server but not W2K Professional. It is part of the NT 4.0 Option Pack for NT Server, but not for NT4 Workstation (that gets PWS instead).
This actually raises a somewhat interesting question: What fraction of the infected servers are running each flavor?
You may be underestimating just how much the XML folks learned from the catastrophe that HTML became. Of the four advantages you cite for a non-human-readable form:
"Syntax could be strict": XML syntax is quite strict. Your example is particularly badly chosen, since XML explicitly disallows size=123. It's size="123" or it's an XML parse error.
"Checked prior to publication": XML is checked prior to publication. That's what XML parsers are for.
"waste of bandwidth": XML was designed to compress well, and it does. The idea was that the compressed form would be used where bandwidth mattered, and the inflated form where it didn't. Considering how fast compression algorithms are nowadays, this is a lot closer to the best of both worlds than a defect.
"Proprietary extensions": People who make proprietary extensions don't have to give you their parser (because what XML has really standardized is the behavior of the parsers), but they do have to give you their DTD. Any XML parser, plus a DTD, is a parser and generator/compiler for the particular XML vocabulary described by that DTD.
It's worth noting that HTML was born as an SGML dialect, and SGML, although it is complex and horrible in many ways, is also quite free of the ambiguities and defects of HTML that you cite. However, early in its history, HTML got caught in no-man's land between Netscape and Microsoft during the browser wars, and both sides inflicted massive non-standard modifications on it. This is why the web is the way it is, and that's good, but it's also why HTML and browsers are the way they are, and that's bad.
Check out XHTML sometime - that's an XML dialect designed to do what HTML does. There are reasons why people of good will choose not to like XHTML, but it most assuredly is free of the defects you list.
The more I think about it, the more it seems like a permissible act of self defense.
I sympthize a lot with the soreness of your temptation, but I also think you misspelled "less" somewhere in the quoted sentence:-) Self-defense only applies when you are defending yourself and have no alternative. If a crazed axe murderer is pounding at your door with the avowed intent of hacking you into bloody bits, it's self-defense if you shoot him when he bursts through the door. It's self-defense if you shoot him after it's obvious that he will succeed him breaking down the door. But you are not allowed to shoot him if your door is protecting you - that's what the door and the 911 dispatcher is there for.
You wouldn't be posting here if you actually had any measurable vulnerability to CRII, so there's no question of self-defense. You're already defended. Both legally and ethically the right thing to do is to notify the owner of the offending machine, or their ISP (who does have the right to shut off their internet access) and let them deal with it.
http:// {infected ip here }/scripts/root.exe?/c%20del%20/Q%20/F%20/S%20c:\*.*
It's not if as many/.ers need to be told about the existence of the DEL command, and the intellectual leap required to recognize that the ability to execute an arbitrary command implies the ability to execute a particular command seems rather modest to me.
But before we mod this down as an insult to the intelligence of the/. readership, there is a more interesting issue: This particular inspiration is going to occur to a fair number of vandals, kiddies, and assorted undersocialized individuls. Many of them will do something more destructive with it than posting it to slashdot. More generally, the level of sophistication needed to attack a CRII-compromised machine is low, much lower than even script-kiddie level, low enough that any moderately determined wolfcub with a bent hairpin and a telnet client can do tremendous damage.
Thus, CRII has suddenly created and widely advertised a pool of very vulnerable machines. It would not be surprising to find that the worst damage is done by vandals following along behind CRII, just as looters follow behind natural disasters.
None of the above. The two historical precedents that come to mind are:
The Grand Canyon midair collision on 30 June 1956
The sinking of the Titanic
In both cases, technologies failed in ways that (in hindsight) were predictable and even inevitable consequences of growth beyond the their roots. In both cases, the response was moderate, incremental, and designed to preserve existing investments in these technologies. The lesson is that the "breaking point" for a widespread infrastructural technology is very hard to reach. And, like it or not, Windows is one of these technologies.
Instead, what we'll see happen is more attention to security, taken in small steps. More people will subscribe to alert services, and they'll be willing to pay more for them. Bosses will start asking sysadmins what they've done for security today, and be more willing to sign purchase orders for security-related work. ISPs will pay a bit more attention to open ports on their home users, and some will scan their networks for known security vulnerabilities. OEMs configuring systems for naive users will discover that people will pay for a "safe out of the box" configuration, so they'll start to offer one. And so on, and so on....
The normal state for an economically useful thing is to be stressed, but not stressed to the breaking point. This should be pretty obvious: if it's not stressed, it was uneconomically overbuilt. We are very far from the breaking point for Windows.
And, also anecdotally: If the default index page for the compromised IP address is the standard IIS "under construction" page, the trojan will be active at "scripts/root.exe". These are machines with a stone stock untouched OOTB IIS installation.
The "too busy" reply happens for any HTTP request, as one would expect, but suggests that something beyond hosting the trojan is happening to the compromised machines. Either they're getting a lot of HTTP requests from somewhere, or something is happening on them.
FWIW: A fair number of the compromised machines respond with the standard IIS "server too busy" HTML error page instead.
At least one compromised machine launched root.exe the first time it was touched this way, but then started responding with the error page.
Is this collateral damage as the ravening script-kiddies of the internet discover a new and vulnerable target? Or is it an attribute of the compromise itself?
Remember the exact same problem exists for Microsoft. If any of their kernel programmers become "contaminated" by GPL code (ie Linux) then they have serious problems in the CE or NT code base
No. This entire notion of "contamination" comes from trade-secret law, not copyright law. The GPL is a copyright license, controlling how GPL'd code may be copied and redistributed. It says absolutely nothing about ideas derived from reading GPL'd code.
The reason that Microsoft is so careful about the GPL is that they know perfectly well that they are everyone's favorite target. Can you imagine Ballmer playing Valjean to RMS's Javert?
Where did this twisted notion come from that one should not benefit from reading copyrighted or patented work? The whole point of copyright and patent law is to encourage people to share their creations so that other people can learn from them.
Copyright and patent are altogether different things.
The whole point of patent law is to encourage people to bring their inventions to market without fear that they'll be ripped off. Thus, patent law allows people to patent their inventions, and once patented, no one else can use the idea behind the invention.
The whole point of copyright law is to protect people from having their actual work copied. There's no notion of "idea" in copyright law.
Is the possibility of being sued after having looked at someone else's code real, or is this just/. paranoia?
The possibility is real, if you violate some agreement you have with the owner of the code, or if you shouldn't have been looking at the code in the first place. In the former case, you're violating an agreement, and you're always at risk for doing that. In the latter case, "shouldn't" is the operative word. If you have trouble with this "shouldn't" concept, apply a simple test: what would the owner of the code think if they knew you were looking at it? Calling the lawyers down on your head is their way of saying no.
If this were true, whats to stop Linus from suing Microsoft when he sees microsoft.com in kernel.org's transfer logs?
Two answers.
First, the general but unhelpful one... Nothing. Anyone can sue anyone for anything, anytime. The law isn't about whether you can sue someone, it's about whether whether you'll recover anything if you do.
Second, the helpful but ungeneral one....Easy. Linux is distributed under the GPL. As long as Microsoft doesn't violate the GPL they can download the code to their hearts' content.
What is the fallout of loooking at the source code for a product and then writing your own from scratch.
It depends on how you got to look at the source code, and what the legal status of the source code is.
Did you have to sign an NDA? If so, the words in the NDA contain the answer to your question. Of course, there may be some dispute about what these words mean - see below.
Is the source code copyrighted? Then you can do pretty much whatever you want with ideas you get by reading it, but there are only two ways that you can copy it:
- Under fair use law, which basically allows you to talk about it. That's how book reviewers get to quote snippets of prose from the reviewed book, and why you're allowed to quote other peoples' Usenet posts. Of course, there may be some dispute about exactly what is fair use - see below.
- As allowed by some license that the copyright holder has granted you. That's how it is with GPL'd code and stuff under the BSD or Apache licenses - the only difference is what the license allows you to do. Of course, there may be some dispute about whether the license really allowed you to do what you did with the code - see below.
Is it patented? Then you cannot use the idea behind the patent without a license from the patent holder. Not even if you came up with the same idea independently (although if you did, and the timing is right, the patent may be invalid - see below).
Is it a trade secret? Then you cannot do anything with it. Of course, if you do do something with it, they still have to catch you and show that you used the trade secret - see below.
First of all, what does it take to actually establish guilt if the company that allowed you to see the source thought you had done wrong with it?
This leads into the point behind all the see-belows above: What you're really asking is how the legal system determines facts. You say you didn't violate someone's copyright. They say you did. Or you say that you didn't steal their trade secrets. They say that you did. Or you say that their patent is invalid because you used their idea first. They say you didn't and it's not. Or you say that your use of the code is covered by "fair use" and they say it's not.
In theory, the legal system answers these questions by passing them on to a jury. In practice, because jury trials are very expensive, the lawyers on both sides will settle the case based on what they think a jury would decide. Since lawyers are pretty good at predicting what a jury will decide, these generally come down to the same thing. A corollary is that a clever and/or internally consistent sophistry ("I only read Playboy for the articles", "BackOrifice is a remote administration tool") won't work. If you giggle when you hear it, so will a jury of your peers.
Also in practice, and more cynically, a large company can throw enough lawyers at a dispute to drive the cost of fighting them so high that no one is willing to take a chance on the case unless it is really clear-cut (One of the charms of contingency fees is that if you are really no-shit, unambiguously, no-dummy-could-miss-it right, you will be able to find first-rate lawyers to take your case and win it).
Despite the popular belief, it is possible to write software that is completely free of bugs (just look at the space shuttle launching code). It is a lot more difficult to do that, sure, but nevertheless quite doable.
Indeed it is. In 1967(!) Boeing executives were lecturing IBM executives about failure rates; a 707 or 727 is no less complex than a mainframe of that era, and was many orders of magnitude more reliable - because the failures killed people.
The key point is that "a lot more difficult" is generally equivalent to "a lot more expensive". When the cost of reducing the defect rate exceeds the cost of living with the defect rate, it becomes rational to stop working on further reduction of the defect rate and to start working on adding new functionality, improving performance, or otherwise adding value on some other axis.
That crossover point is reached at one point with MS Office ("damn - there goes a few minutes of work"), another point with an enterprise ERP system ("damn - three minutes of downtime at $3E6/minute"), and yet another (near-extreme) point with the space shuttle launching code ("damn - six people dead, $3E9 up in smoke, one irreplaceable shuttle gone").
We should not expect people to be willing to pay more for less buggy software (if they did, it would be prima facie evidence that the vendor has underestimated the value of the software to the user). What may happen is that, as happened with automobiles during the 1980's and 1990's, some vendors will figure out how to improve quality while holding costs constant; these vendors will raise the quality bar across the board. They won't succeed by mainstreaming the techniques used in designing mission-critical software, any more than Honda or Toyota succeeded by mainstreaming techniques used by Rolls-Royce - they'll succeed by driving the craftsmanship out of the engineering and replacing it with a soulless but repeatable development process.
It's irresponsible to release software that has at least one known Severity 1 or Severity 2 bug.
That's a bit of an oversimplification (unless you are making the tautological argument that a Sev1 bug is one that makes the software unreleasable - a reasonable position but not much help in deciding when the software is releasable).
The essential question is: is the software, with the bug, still more valuable than no software at all? If so, it's better to release it than not. I can deliver software with zero defects in infinite time and at infinite cost. Most users are willing to accept some non-zero defect rate in exchange for non-infinite cost and delivery sooner rather than later - and this is a value tradeoff that the user must make.
Among the factors to consider:
What is the value of the non-broken parts of the application to the user? I'd consider "optimization causes incorrect code generation" to be a Sev2 or worse in a compiler, but there have been many times in my life when I've been happier with a compiler that didn't optimize and the promise of an optimizer next release than I would have been with no compiler at all.
Are the defects clearly documented so that the user can make an informed time/cost/quality tradeoff? It's one thing to ship a compiler with -O3 broken; it's another thing not to tell people about it.
Is there a committment to getting the defects fixed on a credible schedule?
Will more customer feedback sooner make it possible to further improve the product?
Bottom line: Listen to your customers, not engineering religion.
> It sure beats the current fad of shooting your classmates.
> (Lovecraftian emphasis added)
Gah.... That's not a "Lovecraftian" emphasis. Howard Philip Lovecraft never did that cheesy italics-at-the-end thing. You're thinking of August Derleth, who finished a few of Lovecraft's stories after Lovecraft's death, and wrote a bunch more in what he wistfully hoped was Lovecraft's style. Sadly, Derleth didn't have Lovecraft's talent for foreshadowing and structured his endings so ineptly that he had to resort to italics to make readers notice that the last sentence or so of the story was important.
One anecdotal data point....
Three years ago I watched the CTO of a well-known e-commerce vendor describe this particular vulnerability: prices in hidden fields.
His company's shopping cart product didn't have this vulnerability. It was a big selling point for them. Really big. The salespeople would trot it out to create an Oh-shit-we-gotta-pay-these-pros-big-bucks moment in a prospect's mind. It worked. Well enough to close 6-figure sales.
Sometimes - but not all sites offer the same price to all customers. This is especially true in the B2B world, where pricing and service terms are provided on the basis of previously negotiated contracts.
Yes, providing a customer id as well helps you figure it out internally. But remember, online business processes tend to mirror preexisting offline ones. If the preexisting process is based on a paper quote, it may take non-zero work to avoid embedding any quotation information in the quotation into browser session state (cookies/URL fields/whatever). And there's always a way in which someone will forget to do any non-zero amount of work.
The real problem here is pitiably naive^h^h^h^h^h^h^h^h^h^h^h^h^h^h insufficiently careful programming, and, sadly, that's not a scarce commodity.
Why must the courts and legislatures of our world continue to think of computers as things foreign to traditional law? Why must they continue to make computer laws and decisions that would be considered unreasonable when applied to the real world
But in this case what the Telegraph is describing is precisely the application of traditional law. It is giving email the exact same treatment that paper mail gets under current copyright law, and has gotten for a very long time without kicking up any particular controversy.
You write something, you own the copyright. Others may copy only by fair use or if you give them permission. That's how it is with paper.
And use the same logic to make the opposite point: How is accessing my web page page any different than coming through my unlocked door and photocopying documents left out on my desk? On the internet you can't necessarily assume the intent of the person using the resource is theivery, nor can you assume that a shared resource is some kind of misconfiguration or user error.
Yes, and outside of the internet you can't assume that the person entering through your unlocked door wasn't actually trying to track down and exterminate a mouse infected with a mutant hantavirus strain, or didn't have some other altogether legitimate purpose that exceeds even the fertile imagination of/ers.
This technique of making internally consistent but bogus arguments (bogus because the arguer doesn't really believe them himself, but has labored long to ensure their internal consistency) works just as well outside the internet as inside.
So I still don't see why the problem is fundamentally different on the net. Off the net, it's more or less illegal to mess with your neighbor's property in ways that he wouldn't like. Off the net, it's possible to construct all sorts of interesting and logical arguments for why it was OK for you to mess with neighbor's property. Off the net, if a jury of your peers would giggle at these arguments, so will a court of law.
What's different if you use the internet to mess with your neighbor's property? Well, it's likely that it's harder to assemble a jury of your peers, but that's just an implementation difficulty, it's not a fundamental difference. And if we did assemble such a jury, how do we think they would react to an argument that you believed, really believed that Joe Clueless meant to share his C: drive? ROTFLMAO.
Slashdot Mirror
/. doesn't do subtlety - so that one-word "who?" which should be modded up to a +5 is probably destined to languish unappreciated - but at least it happened in a discussion of great almosts.
That's a good point, and needs a bit more modding up.
...) evolved for the long thin pipes used to connect computers to one another.
It's worth adding, however, that the hyperSCSI folks are trying to make a distinction between wider-area networks (which they call SWANs for Storage WAN) and local single-segment (since they aren't routing) networks, and arguing that iSCSI is right for the former and hyperSCSI, because it's faster/cheaper, for the latter.
This view has parallels in the history of NFS over TCP versus NFS over UDP, because NFS/UDP is still hanging on in one niche: short-haul, high-speed, low-latency, few-hops, negligible-loss environments.
It also has parallels with the bad old days when direct-attached storage interconnects were much faster than LANs, so one set of protocols (FCP, SCSI, ESDI, IDE, SIMD...)evolved on the short fat pipes used to connect computers to peripherals, and a completely different set of protocols (ethernet, TCP/IP, SDLP,
Similarly, hyperSCSI is an argument that the two domains are different enough to justify different protocols. That seems to be arguing against a historical trend tht says that the short/fat and long/thin differences are vanishing; compare gigE and fibrechannel as _wires_ today.
All of this just reinforces Bourne's general point about ignoring the history. It's pretty clear that NFS over TCP is where the world is going, and the only reason that there's an NFS over UDP hanging around is that's how all NFS used to be, so some still is. When we compare hyperSCSI to iSCSI over TCP, I can't find any reason not to just deploy iSCSI everywhere and be done with it.
Two big disadvantages:
First, Ethernet can't be routed, so hyperSCSI isn't going to be nearly as flexible as iSCSI. This is the reason that just about everything that might want to be routed is usually carried over IP (and TCP and UDP and other stuff on top of IP). Straight ethernet is for stuff like ARP that really doesn't want to leave a network segment.
Of course, one could reasonably do something hyperSCSI-like across IP, and still save the TCP overhead. (Consider that in a low-loss short-hop environment, NFS over UDP generally outperforms NFS over TCP). The problem here is that SCSI was never ever intended to run well over a lossy transport, and it doesn't. That seems a serious objection to running SCSI over both non-routable and non-reliable ethernet and routable but still non-reliable IP.
C'mon, there's a reason why people use TCP....
And why iSCSI chose TCP as the transport....
forced to release their own source code.
This is quite true, and not in the least bit controversial. No (legally clueful) person has ever seriously argued that the GPL could be used to force someone to release their source code, and indeed the next-to-last paragraph of section 2 of the GPL says that that's not the intent.
It's really all simpler than it looks: If it's copyrighted, the default, no-license, no-GPL, simple ordinary, I wrote it so it's mine to decide what to do with it, rule, which applies to great novels as well as great software, is that you can't distribute it without the author's permission. The GPL is the author's permission. You don't have to accept the GPL, but if you don't, you don't have permission to redistribute the GPL'd work; you're back in the default no-permission case.
And if you distribute something without permission? A court can make you stop. A court can make you pay the copyright holder monetary damages (unlikely in a GPL case, since it's unlikely that the copyright holder suffered any monetary damage, but possible). But make you distribute your own work? No way. It's your work, and your infringement of someone else's copyright doesn't change that.
Of course, once you consider the implications of the court's ruling, you may choose to release your modification along with the GPL'd code you started with. That's what RMS would like you to do, and since the alternative is not distributing at all, it may be the easiest answer. But it's not mandatory.
There are two basic misunderstandings here.
First, this notion of "public domain".... There is only one way that a copyrighted work enters the public domain, and that is when the copyright expires. That's (one reason) why Apache is distributed under a license that says that you may do anything you please with the code: the license is the only way of giving that permission. When the copyright on the code expires, decades hence, then it will enter the public domin and the Apache license will be redundant. But until then, the code is copyrighted, and only the Apache license gives you the right to do anything with it.
Second, there is no such thing as "implicitly offered" permissions in this context. Copyright law says that you have no permissions to copy a copyrighted work, except as allowed by a license from the copyright holder or under the copyright law notion of "fair use". It's fair use that allows book reviewers to quote snippets of the reviewed work, students to use properly footnoted quotations, and that allows people to freely quote newsgroup postings in their replies, and generally allows all the other things that are "obviously" OK.
Since legally a company is an individual, these cases aren't "gray" at all. The first two are not distribution (provided that the modified program is only used in the operations of the company; if an employee takes it home for personal use, that's a distribution to that employee). The third is distribution.
Nonetheless, with a little work, you will be able to construct a hypothetical case that really is "gray". This has nothing to do with the GPL; it's just the way law works. No matter how sharp and clear a line is, it will show up as a broad gray area if viewed at sufficently high resolution. When court decisions and legislative action draw a new and sharper line through this gray area, all we have to do is crank up the magnification again to turn the new line into a gray area. (If you aren't already, you should be thinking "fractal decomposition").
This recurrence of "gray areas" doesn't matter, because the law is not a machine preprogrammed with answers for all legal questions. It's a machine for resolving disputes, and any given dispute will be resolvable at some level in the fractal decomposition.
It is installed by default with W2K Server but not W2K Professional. It is part of the NT 4.0 Option Pack for NT Server, but not for NT4 Workstation (that gets PWS instead).
This actually raises a somewhat interesting question: What fraction of the infected servers are running each flavor?
It's worth noting that HTML was born as an SGML dialect, and SGML, although it is complex and horrible in many ways, is also quite free of the ambiguities and defects of HTML that you cite. However, early in its history, HTML got caught in no-man's land between Netscape and Microsoft during the browser wars, and both sides inflicted massive non-standard modifications on it. This is why the web is the way it is, and that's good, but it's also why HTML and browsers are the way they are, and that's bad.
Check out XHTML sometime - that's an XML dialect designed to do what HTML does. There are reasons why people of good will choose not to like XHTML, but it most assuredly is free of the defects you list.
I sympthize a lot with the soreness of your temptation, but I also think you misspelled "less" somewhere in the quoted sentence :-)
Self-defense only applies when you are defending yourself and have no alternative. If a crazed axe murderer is pounding at your door with the avowed intent of hacking you into bloody bits, it's self-defense if you shoot him when he bursts through the door. It's self-defense if you shoot him after it's obvious that he will succeed him breaking down the door. But you are not allowed to shoot him if your door is protecting you - that's what the door and the 911 dispatcher is there for.
You wouldn't be posting here if you actually had any measurable vulnerability to CRII, so there's no question of self-defense. You're already defended. Both legally and ethically the right thing to do is to notify the owner of the offending machine, or their ISP (who does have the right to shut off their internet access) and let them deal with it.
But I still feel the temptation....
It's not if as many /.ers need to be told about the existence of the DEL command, and the intellectual leap required to recognize that the ability to execute an arbitrary command implies the ability to execute a particular command seems rather modest to me.
But before we mod this down as an insult to the intelligence of the /. readership, there is a more interesting issue: This particular inspiration is going to occur to a fair number of vandals, kiddies, and assorted undersocialized individuls. Many of them will do something more destructive with it than posting it to slashdot. More generally, the level of sophistication needed to attack a CRII-compromised machine is low, much lower than even script-kiddie level, low enough that any moderately determined wolfcub with a bent hairpin and a telnet client can do tremendous damage.
Thus, CRII has suddenly created and widely advertised a pool of very vulnerable machines. It would not be surprising to find that the worst damage is done by vandals following along behind CRII, just as looters follow behind natural disasters.
None of the above.
The two historical precedents that come to mind are:
- The Grand Canyon midair collision on 30 June 1956
- The sinking of the Titanic
In both cases, technologies failed in ways that (in hindsight) were predictable and even inevitable consequences of growth beyond the their roots. In both cases, the response was moderate, incremental, and designed to preserve existing investments in these technologies. The lesson is that the "breaking point" for a widespread infrastructural technology is very hard to reach. And, like it or not, Windows is one of these technologies.Instead, what we'll see happen is more attention to security, taken in small steps. More people will subscribe to alert services, and they'll be willing to pay more for them. Bosses will start asking sysadmins what they've done for security today, and be more willing to sign purchase orders for security-related work. ISPs will pay a bit more attention to open ports on their home users, and some will scan their networks for known security vulnerabilities. OEMs configuring systems for naive users will discover that people will pay for a "safe out of the box" configuration, so they'll start to offer one. And so on, and so on....
The normal state for an economically useful thing is to be stressed, but not stressed to the breaking point. This should be pretty obvious: if it's not stressed, it was uneconomically overbuilt. We are very far from the breaking point for Windows.
The "too busy" reply happens for any HTTP request, as one would expect, but suggests that something beyond hosting the trojan is happening to the compromised machines. Either they're getting a lot of HTTP requests from somewhere, or something is happening on them.
At least one compromised machine launched root.exe the first time it was touched this way, but then started responding with the error page.
Is this collateral damage as the ravening script-kiddies of the internet discover a new and vulnerable target? Or is it an attribute of the compromise itself?
No. This entire notion of "contamination" comes from trade-secret law, not copyright law. The GPL is a copyright license, controlling how GPL'd code may be copied and redistributed. It says absolutely nothing about ideas derived from reading GPL'd code.
The reason that Microsoft is so careful about the GPL is that they know perfectly well that they are everyone's favorite target.
Can you imagine Ballmer playing Valjean to RMS's Javert?
Copyright and patent are altogether different things.
The whole point of patent law is to encourage people to bring their inventions to market without fear that they'll be ripped off. Thus, patent law allows people to patent their inventions, and once patented, no one else can use the idea behind the invention.
The whole point of copyright law is to protect people from having their actual work copied. There's no notion of "idea" in copyright law.
The possibility is real, if you violate some agreement you have with the owner of the code, or if you shouldn't have been looking at the code in the first place. In the former case, you're violating an agreement, and you're always at risk for doing that. In the latter case, "shouldn't" is the operative word. If you have trouble with this "shouldn't" concept, apply a simple test: what would the owner of the code think if they knew you were looking at it? Calling the lawyers down on your head is their way of saying no.
If this were true, whats to stop Linus from suing Microsoft when he sees microsoft.com in kernel.org's transfer logs?
Two answers.
First, the general but unhelpful one... Nothing. Anyone can sue anyone for anything, anytime. The law isn't about whether you can sue someone, it's about whether whether you'll recover anything if you do.
Second, the helpful but ungeneral one....Easy. Linux is distributed under the GPL. As long as Microsoft doesn't violate the GPL they can download the code to their hearts' content.
It depends on how you got to look at the source code, and what the legal status of the source code is.
Did you have to sign an NDA? If so, the words in the NDA contain the answer to your question. Of course, there may be some dispute about what these words mean - see below.
Is the source code copyrighted? Then you can do pretty much whatever you want with ideas you get by reading it, but there are only two ways that you can copy it:
Is it patented? Then you cannot use the idea behind the patent without a license from the patent holder. Not even if you came up with the same idea independently (although if you did, and the timing is right, the patent may be invalid - see below).
Is it a trade secret? Then you cannot do anything with it. Of course, if you do do something with it, they still have to catch you and show that you used the trade secret - see below.
First of all, what does it take to actually establish guilt if the company that allowed you to see the source thought you had done wrong with it?
This leads into the point behind all the see-belows above:
What you're really asking is how the legal system determines facts. You say you didn't violate someone's copyright. They say you did. Or you say that you didn't steal their trade secrets. They say that you did. Or you say that their patent is invalid because you used their idea first. They say you didn't and it's not. Or you say that your use of the code is covered by "fair use" and they say it's not.
In theory, the legal system answers these questions by passing them on to a jury. In practice, because jury trials are very expensive, the lawyers on both sides will settle the case based on what they think a jury would decide. Since lawyers are pretty good at predicting what a jury will decide, these generally come down to the same thing. A corollary is that a clever and/or internally consistent sophistry ("I only read Playboy for the articles", "BackOrifice is a remote administration tool") won't work. If you giggle when you hear it, so will a jury of your peers.
Also in practice, and more cynically, a large company can throw enough lawyers at a dispute to drive the cost of fighting them so high that no one is willing to take a chance on the case unless it is really clear-cut (One of the charms of contingency fees is that if you are really no-shit, unambiguously, no-dummy-could-miss-it right, you will be able to find first-rate lawyers to take your case and win it).
Please please please mod this down.
1) We've all seen it.... a lot
2) It would have been better to post a link rather than pasting in all this text.
Indeed it is. In 1967(!) Boeing executives were lecturing IBM executives about failure rates; a 707 or 727 is no less complex than a mainframe of that era, and was many orders of magnitude more reliable - because the failures killed people.
The key point is that "a lot more difficult" is generally equivalent to "a lot more expensive". When the cost of reducing the defect rate exceeds the cost of living with the defect rate, it becomes rational to stop working on further reduction of the defect rate and to start working on adding new functionality, improving performance, or otherwise adding value on some other axis.
That crossover point is reached at one point with MS Office ("damn - there goes a few minutes of work"), another point with an enterprise ERP system ("damn - three minutes of downtime at $3E6/minute"), and yet another (near-extreme) point with the space shuttle launching code ("damn - six people dead, $3E9 up in smoke, one irreplaceable shuttle gone").
We should not expect people to be willing to pay more for less buggy software (if they did, it would be prima facie evidence that the vendor has underestimated the value of the software to the user). What may happen is that, as happened with automobiles during the 1980's and 1990's, some vendors will figure out how to improve quality while holding costs constant; these vendors will raise the quality bar across the board. They won't succeed by mainstreaming the techniques used in designing mission-critical software, any more than Honda or Toyota succeeded by mainstreaming techniques used by Rolls-Royce - they'll succeed by driving the craftsmanship out of the engineering and replacing it with a soulless but repeatable development process.
That's a bit of an oversimplification (unless you are making the tautological argument that a Sev1 bug is one that makes the software unreleasable - a reasonable position but not much help in deciding when the software is releasable).
The essential question is: is the software, with the bug, still more valuable than no software at all? If so, it's better to release it than not. I can deliver software with zero defects in infinite time and at infinite cost. Most users are willing to accept some non-zero defect rate in exchange for non-infinite cost and delivery sooner rather than later - and this is a value tradeoff that the user must make.
Among the factors to consider:
Bottom line: Listen to your customers, not engineering religion.
> (Lovecraftian emphasis added)
Gah.... That's not a "Lovecraftian" emphasis. Howard Philip Lovecraft never did that cheesy italics-at-the-end thing. You're thinking of August Derleth, who finished a few of Lovecraft's stories after Lovecraft's death, and wrote a bunch more in what he wistfully hoped was Lovecraft's style. Sadly, Derleth didn't have Lovecraft's talent for foreshadowing and structured his endings so ineptly that he had to resort to italics to make readers notice that the last sentence or so of the story was important.
Three years ago I watched the CTO of a well-known e-commerce vendor describe this particular vulnerability: prices in hidden fields.
His company's shopping cart product didn't have this vulnerability. It was a big selling point for them. Really big. The salespeople would trot it out to create an Oh-shit-we-gotta-pay-these-pros-big-bucks moment in a prospect's mind. It worked. Well enough to close 6-figure sales.
Yes, providing a customer id as well helps you figure it out internally. But remember, online business processes tend to mirror preexisting offline ones. If the preexisting process is based on a paper quote, it may take non-zero work to avoid embedding any quotation information in the quotation into browser session state (cookies/URL fields/whatever). And there's always a way in which someone will forget to do any non-zero amount of work.
The real problem here is pitiably naive^h^h^h^h^h^h^h^h^h^h^h^h^h^h insufficiently careful programming, and, sadly, that's not a scarce commodity.
But in this case what the Telegraph is describing is precisely the application of traditional law. It is giving email the exact same treatment that paper mail gets under current copyright law, and has gotten for a very long time without kicking up any particular controversy.
You write something, you own the copyright. Others may copy only by fair use or if you give them permission. That's how it is with paper.
On the internet you can't necessarily assume the intent of the person using the resource is theivery, nor can you assume that a shared resource is some kind of misconfiguration or user error.
Yes, and outside of the internet you can't assume that the person entering through your unlocked door wasn't actually trying to track down and exterminate a mouse infected with a mutant hantavirus strain, or didn't have some other altogether legitimate purpose that exceeds even the fertile imagination of /ers.
This technique of making internally consistent but bogus arguments (bogus because the arguer doesn't really believe them himself, but has labored long to ensure their internal consistency) works just as well outside the internet as inside.
So I still don't see why the problem is fundamentally different on the net. Off the net, it's more or less illegal to mess with your neighbor's property in ways that he wouldn't like. Off the net, it's possible to construct all sorts of interesting and logical arguments for why it was OK for you to mess with neighbor's property. Off the net, if a jury of your peers would giggle at these arguments, so will a court of law.
What's different if you use the internet to mess with your neighbor's property? Well, it's likely that it's harder to assemble a jury of your peers, but that's just an implementation difficulty, it's not a fundamental difference. And if we did assemble such a jury, how do we think they would react to an argument that you believed, really believed that Joe Clueless meant to share his C: drive? ROTFLMAO.