The offer must be valid for any third party who has the offer
However, if the person who received the offer passes on the offer to the rest of the world, the rest of the world can then request the source code under the terms of that offer. This has to be the intent, otherwise the 3rd alternative (to pass along the information you received when you make a non-commercial binary-only distribution that you originally got with a written offer) wouldn't accomplish anything. Yes, if none of the people you distribute to pass along the offer, you are probably exempt from having to provide it to anyone else, but you can't prohibit them from passing it along. Once they do, you're potentially on the hook to anyone (though, of course, you can recover costs).
Don't even need to do that. Just return an NS record, named the same as the query, with supplementary data pointing at the Verisign site, which has a DNS running which returns itself as the A and NS records for any query.
E.g. query on does_not_exist.com returns:
does_not_exist.com. 900 IN NS does_not_exist.com.
does_not_exist.com. 900 IN A 64.94.110.11 (as additonal information)
Then the nameserver at 64.94.110.11 has the same thing (returns both A and NS records).
Then someone will patch BIND to check for an SOA record at the authoritative NS; then Verisign will generate an SOA record as well in the next round.
No, it doesn't. It's done entirely in the nameserver, unless you do a zone transfer (normally used for secondary servers, and often not allowed for public access).
No, this does nothing to block wildcards (which wouldn't help anyway unless they could somehow force Verisign to block them). When you request a record from a nameserver, you don't get any indication that the records you get back were generated from a wildcard entry. The wildcard exists only in THEIR file. All this blocks is anything but NS records (with the supplemental addresses of those nameservers, of course). What this doesn't help, as has been pointed out by others, is them simply changing the A record returned to an NS record instead, pointing to their server, which then returns the appropriate A and NS records for *.
The only way I can think of to automatically block this kind of thing is to have name servers check randomly generated host names, and if they all return the same IP address, block any response that specifies that IP address, whether returned as an A or NS record. Once found, use one of those random names each time as a crosscheck. This would also block the diverter site even when using the actual assigned name.
An advantage of this is that, with thousands of machines checking for bogus host names on a regular basis, any attempt to record and take advantage of queries for the purpose of finding unregistered but popular names might be made more difficult.
A flat income tax can also have a reimbursement feature. Reimbursement doesn't mean you have to "struggle" until you get reimbursed - you're getting reimbursed every year (or your parents, while they're supporting you). What does it matter if it's last year's check or this year's that you just received? Also, note that the Cato NST paper suggests reimbursing through paycheck throughout the year. Only people with no regular payroll income throughout the year would need an annual check, which saves the government a substantial amount of money in check writing and distribution costs.
The problem I have with a NST is the record keeping burden. The rules in the Cato paper, for example, are complex for re-sale of a car or home. Tax it once, put all of the record keeping and reporting burden on business (which already has to keep track), and eliminate all of the complexity for almost everyone else.
Re:And both generics and templates are kiddy toys.
on
Does C# Measure Up?
·
· Score: 1
Really? It is certainly possible to add a proof from the compiler that a particular cast is unnecessary, with the verifier checking that and then short-circuiting the cast. Article in Dr. Dobbs described it quite well a couple years ago. Even was backward compatible with old VM.
The right in question is the right to not have the government come along and say you can't connect to said privately owned network, or create your own private network and allow anyone you please to connect to it.
Freedom of the press doesn't mean that you have a right to a free printing press, or that you have a right to use someone eles's printing press (or copier, or printer, or fax machine...). It doesn't mean you have a right to have your letter to the editor published. It does mean that the government doesn't have the right to tell an editor not to publish your letter because you don't have a license to write.
For anything which you don't meet the requirements, if you can show that the H1B that got the job also doesn't meet them (and you are the same or closer to meeting them), I think you'd still have a case.
So find out which companies are (ab)using H1-B a lot, and send them your resume, including the skills they're claiming they need. Then sue over the next H1-B they hire that matches the skills you told them you had.
If you have a trojan that can get root privileges, why would you bother using any of the code given in the article? Just do it directly in the trojan
All this article shows is how to write buffer overflow payloads, if you find a buffer overflow in a root process.
Something else you can see from reading the (original) article are a few simple ways to make it harder to use such a payload - e.g. processing a system call could check that the sc operation was specified correctly. However, there are so many ways to get around things like that (in this case, self-modifying code) that it wouldn't help much. A much better defense is to make stack/data non-executable.
Re:Java's not exactly pining for the fields just n
on
Java vs .NET
·
· Score: 1
I still don't see any reason why you'd need to use in-line assembly in a pcode program, except to write a device driver (direct access to memory, I/O instructions, interrupt processing), call call some OS routine not otherwise supported, or possibly to implement something like shared memory that isn't supported by the VM. Note that if the pcode doesn't support any way to specify in-line assembly/native machine code, but you think you need to use it, then that doesn't make the VM non-portable, it makes it inadequate for your needs.
Writing a device driver is inherently non-portable, but to the extent that it could be portable, and it was desirable to use something like pcode (e.g. Open Firmware Forth boot code), extend the language to support it.
Accessing an OS routine shouldn't be necessary. If it is, the language is missing a feature, so add it. Shared memory, if desirable, can be added. Providing access to a facility that may or may not be present can be done in a way that preserves portability (with either a feature check facility or a clean failure with "feature not present" error return or exception). A portable language/VM does not mean you can't write non-portable programs in it, but a non-portable program should be able to figure out when it can't run and cleanly fail or degrade. Depending on your definition, all programs are non-portable. Even "Hello, World!" assumes you have a character output device. Other reasonable requirements (memory, persistent storage, communications (to users, other processes, other machines), display, audio/video I/O, sensors and manipulators, CPU speed, randomness) can all be missing unless you define the virtual platform as having them - but then you limit the ability to properly implement the platform.
For a language/VM where you deliberately want to provide clean access to non-portable features, you can provide them, e.g. JNI. Anything that needs to be done in such a way should be considered a candidate for inclusion in the virtual platform.
A pcode-type system does not need to be slow. With current processor speeds, a 10,000 user time shared system written in assembly code can be emulated with each user having more CPU time available than they had on the 500 user system of 20 years ago. Emulating a good pcode system is faster than emulating machine code for a processor that wasn't designed with emulation in mind.
Re:Java's not exactly pining for the fields just n
on
Java vs .NET
·
· Score: 1
Why would I want to put in Intel assembly code into my Pascal program? I never had a need to drop in 68000, PDP-11, or Cyber assembly language, why would an 8080 be any different?
It would make more sense to slightly extend Pascal to allow direct access to memory, ROM routines and the like, and add in interrupt handling capability (i.e. save/restore registers, manipulate interrupt level/interrupt mask) than to allow in-line assembly code, if that even makes sense in a pcode environment, which it doesn't. See, for example, the variant of Pascal that Apple used in the Lisa and MacOS (though I don't think it directly supported interrupt routines). Of course, the ROM routines had to use Pascal calling conventions, and it wasn't a pcode environment.
Re:Java's not exactly pining for the fields just n
on
Java vs .NET
·
· Score: 2, Insightful
A portable VM for Pascal... maybe you could call the machine language for that "pcode"...? Wow, I wonder why no one ever thought of doing something like that.
The only legitimate reason for faking a From: address is so that replies go back to the correct mailbox while submitting them through a different mail server. It seems to me that the first step has to be to pressure all mail client and mail server programs to support using the MSA protocol/port. Sendmail has this enabled by default, I believe, and many mail clients can use it as well. If it was made pretty much universal and supported, the necessity of submitting to a local SMTP only (or using hideous kludges like SMTP-after-POP) would be eliminated.
Use all the different e-mail addresses you want, as long as you send them via a mail server that is authorized by the domain specified in the "From:" (or at least "Sender:") field. AMTP or something like it could be used to validate that. People who want to run their own mail servers can still do so. If something like AMTP becomes the standard, and you don't want to get your own certificate, you could still make arrangements with your ISP to deliver mail through their server, authenticating your server using their own certificates, knowledge of your IP address, or whatever.
If I give you detailed directions on how to buy a copy of a (copyrighted) picture, and how to modify that picture in order to achieve some amusing effect (say, putting devil horns on Bill Gates), are my directions to you a derivative work of that photograph? I don't think so, but the FSF's reasoning would say it is. Do you have reason to think that a court would rule one way or the other?
If you gave away the program but, in violation of the GPL, didn't give away the source, the figuring of actual damages would be challenging!
Damages might be the fair market value of the source code not released, which leads to an interesting situation. Since, by definition, a fair market value would be a price that the defendant would agree to sell it for (as one half of the equation), a fair solution would be for the court to require the defendant to name a price, and the plaintiff to be able to choose to take the money or the source code (and then release or keep as desired). Sort of like having one person cut the cake, and the other person choose which half to take.
Then Apple should have raised the license fee for the clones, not killed them. From what I observed during the period, all of a sudden companies that would never touch a Mac were buying clones, internally supporting MacOS and Mac products, and people were getting excited about the increases in performance the clones were promising. Then Apple shut it all down, many companies switched back to being Windows only, and Apple continued to be lackluster. Certainly, Jobs did some things right - he eventually managed to get some excitement going, starting with the iMac. Apple has also been steering the right way recently, particularly with Mac OSX, the iApps, and online music, and they have a very good chance of doing very well with the 64-bit PPC machines. But I will always wonder if things could have been much better if they had just continued the clones, perhaps somewhat better managed (I'm typing this on my APS M*Power 200 MHz clone - damn, Mozilla is slow and bloated!).
Tru64 (nee Digital Unix nee OSF/1) is also pretty good, if you ignore that it is now owned by a company that bought the company that bought the company that made it, and that the Alpha it runs on is going to be killed by that company in favor of Intel, many years late in moving to 64 bits. It's painful to see such nice hardware and software be dumped by a company that can't or won't recognize its value.
Of course, a stock Tru64 system is painful to use if you're used to GNU utilities. However, there were some shortcomings in Linux 2.2, many corrected in 2.4, and I haven't been following changes in 2.5 recently. I'm mostly comparing kernel features (and related libraries), not the rest of "the system".
To get back more on topic, there's no assurance that SCO won't sue both Sun and Compaq, attempting to turn all existing installations of their systems into infringing revenue sources. I don't see how Linux is more of a liability to end users, and may be much less - wouldn't one possible outcome of a trial be a finding that Linux being Open Source is an affirmative defense against infringement, as anyone being infringed upon can easily find out, and that what SCO should have done is notify Linux, or one of the distributors, that they were infringing and to remove the code (and, SCO actually being a developer/distributor of Linux makes them even more responsible for checking for infringement in the Linux code base).
The NDA's are obviously necessary to SCO. If their claim to trade secret is to hold up, they simply can not, in any way, release that information in a way that would compromise that trade secret. Doing so would instantly invalidate their claim.
I've seen several comments complaining about the definition of confidential information in the NDA. It seems to me (NAL) that some of the fears are baseless - e.g. if they show you some public information (e.g. some lines of code from Linux or the LKML), that doesn't mean you can't ever use that information in the future, you simply can't reveal that such public information was part of what they gave you to look at. There is the potential issue of "contamination", but only if you write code that is accepted, and that code is fairly closely structured to code that you've been given access to. "Clean room engineering" is sufficient, but not necessary, to avoid copyright infringement. It seems to me that having seen the code, you could avoid even the appearance of infringement by making sure that the code you write is different. Just because I've read Stephen King novels doesn't mean I can't write my own horror fiction. Contrast with not being contaminated at all, but accidentally writing something very similar - it's going to be hard to prove you didn't have access. After all, according to SCO, anyone who's looked Linux kernel code should be considered contaminated already. Again, IANAL, but I don't think that NDA is quite as bad as some of the other NALs think.
I also think a lot of the bashing on Laura Didio has been uncalled for. Taking a few quotes out of context can make her sound bad, but overall she qualified most of her statements appropriately. Mostly what she's done is make the point that SCO needs to be taken seriously, but that they haven't proven anything yet. She did sort of mangle the implications of the GPL pretty badly, but then so do a lot of people on/.
You missed the bit about "in sufficient detail to qualify for public disclosure". However, all of those items have been described in enough detail that no one can get a patent on "time machine" or "anti-gravity device" in general - only on a specific way of building one.
You no longer have to implement an idea in order to patent it. For example, you could quite likely patent a particular use of a time machine, as long as it hasn't already been described by someone else, even though you have no idea of how to actually build a time machine. However, if someone else invents a practical time machine, your patent will cover that particular use of that time machine. Your only obstacle might be convincing that patent office that time machines were possible (otherwise your idea has no utility, thus is unpatentable).
Under current patent rules, you probably could have patented "recording a movie on a small plastic disk", and thus been able to get royalties on every DVD made until your patent ran out - unless someone could show where some science fiction story or a story of future predictions ("What Will Life Be Like in Fifty Years") included enough detail. Then, of course, you'd simply have had to make your patent a little more detailed (using a laser, using polycarbonate with a metal film, encrypting and error-correcting, whatever wasn't mentioned in the published record). Include enough possible ways of doing it, and you might be lucky enough to stumble upon the way someone will actually try to do it.
There are many examples of this actually being done. Look at any of the so-called submarine patents that have been reported on, including the "microprocessor patent".
Simple solution: to be eligible for copyright protection (including DMCA protection), they have to follow restrictions. If they want to add additional protection beyond what something like this legislation would do, then they lose copyright protection and are ONLY protected by their technological methods - which means it would be legal to hack it by reverse engineering players, modifying players, analog hole, brute force cracking of keys, whatever you wanted.
You can't describe what you haven't invented. The very act of describing it in sufficient detail to qualify for public disclosure means you've already invented it. That doesn't mean you can't make further improvements, including actually getting something to work (which isn't necessary to patent it).
Say I describe A + B + C, and publish that; I've just invented it, THEN published it. If my patent application later describes A + B + C + D (where D is all the other details needed to use A + B + C effectively), that's no problem, that's a new invention. If I didn't claim just A + B + C in my patent, then anyone else is free to use that subset of my patent, and no one else can patent that particular combination either (unless they can show they invented it before it was published). However, I still have a year from that publication date in which to file a patent for just A + B + C (unless someone else knew/used/published it before I invented it).
The definition of "obvious" in patent law is patently unobvious. For instance, it probably fits the definition of "novel, non-obvious and useful" for me to patent the idea of having a stored user preference that controls the scroll rate of a list of products that a nano-manufacturing box can produce - and if I'm lucky enough that nano-manufacturing boxes (suitably described in the patent as a "device that can produce a plurality of products"), or something close enough to them, are available before my patent expires, I can prevent someone, including the holder of this particular patent, from using such an obvious idea. Unless, of course, I don't patent it in the next year (since I've now just published it).
The Amiga Toaster allows vertical scrolls for credits and such - each such page has a little dial icon that you can use to control the scroll rate. I'm pretty sure that program was in use well before 1995. Teleprompters also scroll at variable rates vertically. Even if you could find, say, a program that presented lists of options on a vertical scroll with a user-settable non-volatile preference setting for rate, it would still be "non-obvious" to extend that to a device where those options are lists of available content on a video device (or however the patent claims read). In other words, "non-obvious" and "novel" have such a limited meaning as to be almost useless except in a very literal sense.
BTW, you don't need to be an expert in the field in order to determine obviousness, merely "skilled" - and that is, apparently, defined as a moron with an encylopedic knowledge of everything that's been published on the subject who also is a patent lawyer.
Slashdot Mirror
You can only pass along the offer of source code (as opposed to making the offer yourself) when making a non-commercial distribution.
However, if the person who received the offer passes on the offer to the rest of the world, the rest of the world can then request the source code under the terms of that offer. This has to be the intent, otherwise the 3rd alternative (to pass along the information you received when you make a non-commercial binary-only distribution that you originally got with a written offer) wouldn't accomplish anything. Yes, if none of the people you distribute to pass along the offer, you are probably exempt from having to provide it to anyone else, but you can't prohibit them from passing it along. Once they do, you're potentially on the hook to anyone (though, of course, you can recover costs).
Don't even need to do that. Just return an NS record, named the same as the query, with supplementary data pointing at the Verisign site, which has a DNS running which returns itself as the A and NS records for any query.
E.g. query on does_not_exist.com returns:
does_not_exist.com. 900 IN NS does_not_exist.com.
does_not_exist.com. 900 IN A 64.94.110.11 (as additonal information)
Then the nameserver at 64.94.110.11 has the same thing (returns both A and NS records).
Then someone will patch BIND to check for an SOA record at the authoritative NS; then Verisign will generate an SOA record as well in the next round.
No, it doesn't. It's done entirely in the nameserver, unless you do a zone transfer (normally used for secondary servers, and often not allowed for public access).
No, this does nothing to block wildcards (which wouldn't help anyway unless they could somehow force Verisign to block them). When you request a record from a nameserver, you don't get any indication that the records you get back were generated from a wildcard entry. The wildcard exists only in THEIR file. All this blocks is anything but NS records (with the supplemental addresses of those nameservers, of course). What this doesn't help, as has been pointed out by others, is them simply changing the A record returned to an NS record instead, pointing to their server, which then returns the appropriate A and NS records for *.
The only way I can think of to automatically block this kind of thing is to have name servers check randomly generated host names, and if they all return the same IP address, block any response that specifies that IP address, whether returned as an A or NS record. Once found, use one of those random names each time as a crosscheck. This would also block the diverter site even when using the actual assigned name.
An advantage of this is that, with thousands of machines checking for bogus host names on a regular basis, any attempt to record and take advantage of queries for the purpose of finding unregistered but popular names might be made more difficult.
A flat income tax can also have a reimbursement feature. Reimbursement doesn't mean you have to "struggle" until you get reimbursed - you're getting reimbursed every year (or your parents, while they're supporting you). What does it matter if it's last year's check or this year's that you just received? Also, note that the Cato NST paper suggests reimbursing through paycheck throughout the year. Only people with no regular payroll income throughout the year would need an annual check, which saves the government a substantial amount of money in check writing and distribution costs.
The problem I have with a NST is the record keeping burden. The rules in the Cato paper, for example, are complex for re-sale of a car or home. Tax it once, put all of the record keeping and reporting burden on business (which already has to keep track), and eliminate all of the complexity for almost everyone else.
Really? It is certainly possible to add a proof from the compiler that a particular cast is unnecessary, with the verifier checking that and then short-circuiting the cast. Article in Dr. Dobbs described it quite well a couple years ago. Even was backward compatible with old VM.
The right in question is the right to not have the government come along and say you can't connect to said privately owned network, or create your own private network and allow anyone you please to connect to it.
Freedom of the press doesn't mean that you have a right to a free printing press, or that you have a right to use someone eles's printing press (or copier, or printer, or fax machine ...). It doesn't mean you have a right to have your letter to the editor published. It does mean that the government doesn't have the right to tell an editor not to publish your letter because you don't have a license to write.
For anything which you don't meet the requirements, if you can show that the H1B that got the job also doesn't meet them (and you are the same or closer to meeting them), I think you'd still have a case.
So find out which companies are (ab)using H1-B a lot, and send them your resume, including the skills they're claiming they need. Then sue over the next H1-B they hire that matches the skills you told them you had.
If you have a trojan that can get root privileges, why would you bother using any of the code given in the article? Just do it directly in the trojan
All this article shows is how to write buffer overflow payloads, if you find a buffer overflow in a root process.
Something else you can see from reading the (original) article are a few simple ways to make it harder to use such a payload - e.g. processing a system call could check that the sc operation was specified correctly. However, there are so many ways to get around things like that (in this case, self-modifying code) that it wouldn't help much. A much better defense is to make stack/data non-executable.
I still don't see any reason why you'd need to use in-line assembly in a pcode program, except to write a device driver (direct access to memory, I/O instructions, interrupt processing), call call some OS routine not otherwise supported, or possibly to implement something like shared memory that isn't supported by the VM. Note that if the pcode doesn't support any way to specify in-line assembly/native machine code, but you think you need to use it, then that doesn't make the VM non-portable, it makes it inadequate for your needs.
Writing a device driver is inherently non-portable, but to the extent that it could be portable, and it was desirable to use something like pcode (e.g. Open Firmware Forth boot code), extend the language to support it.
Accessing an OS routine shouldn't be necessary. If it is, the language is missing a feature, so add it. Shared memory, if desirable, can be added. Providing access to a facility that may or may not be present can be done in a way that preserves portability (with either a feature check facility or a clean failure with "feature not present" error return or exception). A portable language/VM does not mean you can't write non-portable programs in it, but a non-portable program should be able to figure out when it can't run and cleanly fail or degrade. Depending on your definition, all programs are non-portable. Even "Hello, World!" assumes you have a character output device. Other reasonable requirements (memory, persistent storage, communications (to users, other processes, other machines), display, audio/video I/O, sensors and manipulators, CPU speed, randomness) can all be missing unless you define the virtual platform as having them - but then you limit the ability to properly implement the platform.
For a language/VM where you deliberately want to provide clean access to non-portable features, you can provide them, e.g. JNI. Anything that needs to be done in such a way should be considered a candidate for inclusion in the virtual platform.
A pcode-type system does not need to be slow. With current processor speeds, a 10,000 user time shared system written in assembly code can be emulated with each user having more CPU time available than they had on the 500 user system of 20 years ago. Emulating a good pcode system is faster than emulating machine code for a processor that wasn't designed with emulation in mind.
Why would I want to put in Intel assembly code into my Pascal program? I never had a need to drop in 68000, PDP-11, or Cyber assembly language, why would an 8080 be any different?
It would make more sense to slightly extend Pascal to allow direct access to memory, ROM routines and the like, and add in interrupt handling capability (i.e. save/restore registers, manipulate interrupt level/interrupt mask) than to allow in-line assembly code, if that even makes sense in a pcode environment, which it doesn't. See, for example, the variant of Pascal that Apple used in the Lisa and MacOS (though I don't think it directly supported interrupt routines). Of course, the ROM routines had to use Pascal calling conventions, and it wasn't a pcode environment.
A portable VM for Pascal ... maybe you could call the machine language for that "pcode"...? Wow, I wonder why no one ever thought of doing something like that.
The only legitimate reason for faking a From: address is so that replies go back to the correct mailbox while submitting them through a different mail server. It seems to me that the first step has to be to pressure all mail client and mail server programs to support using the MSA protocol/port. Sendmail has this enabled by default, I believe, and many mail clients can use it as well. If it was made pretty much universal and supported, the necessity of submitting to a local SMTP only (or using hideous kludges like SMTP-after-POP) would be eliminated.
Use all the different e-mail addresses you want, as long as you send them via a mail server that is authorized by the domain specified in the "From:" (or at least "Sender:") field. AMTP or something like it could be used to validate that. People who want to run their own mail servers can still do so. If something like AMTP becomes the standard, and you don't want to get your own certificate, you could still make arrangements with your ISP to deliver mail through their server, authenticating your server using their own certificates, knowledge of your IP address, or whatever.
Among three CD drives I have (one a DVD drive), only the CD burner consistently reads the same audio data every time.
If I give you detailed directions on how to buy a copy of a (copyrighted) picture, and how to modify that picture in order to achieve some amusing effect (say, putting devil horns on Bill Gates), are my directions to you a derivative work of that photograph? I don't think so, but the FSF's reasoning would say it is. Do you have reason to think that a court would rule one way or the other?
Damages might be the fair market value of the source code not released, which leads to an interesting situation. Since, by definition, a fair market value would be a price that the defendant would agree to sell it for (as one half of the equation), a fair solution would be for the court to require the defendant to name a price, and the plaintiff to be able to choose to take the money or the source code (and then release or keep as desired). Sort of like having one person cut the cake, and the other person choose which half to take.
Then Apple should have raised the license fee for the clones, not killed them. From what I observed during the period, all of a sudden companies that would never touch a Mac were buying clones, internally supporting MacOS and Mac products, and people were getting excited about the increases in performance the clones were promising. Then Apple shut it all down, many companies switched back to being Windows only, and Apple continued to be lackluster. Certainly, Jobs did some things right - he eventually managed to get some excitement going, starting with the iMac. Apple has also been steering the right way recently, particularly with Mac OSX, the iApps, and online music, and they have a very good chance of doing very well with the 64-bit PPC machines. But I will always wonder if things could have been much better if they had just continued the clones, perhaps somewhat better managed (I'm typing this on my APS M*Power 200 MHz clone - damn, Mozilla is slow and bloated!).
Tru64 (nee Digital Unix nee OSF/1) is also pretty good, if you ignore that it is now owned by a company that bought the company that bought the company that made it, and that the Alpha it runs on is going to be killed by that company in favor of Intel, many years late in moving to 64 bits. It's painful to see such nice hardware and software be dumped by a company that can't or won't recognize its value.
Of course, a stock Tru64 system is painful to use if you're used to GNU utilities. However, there were some shortcomings in Linux 2.2, many corrected in 2.4, and I haven't been following changes in 2.5 recently. I'm mostly comparing kernel features (and related libraries), not the rest of "the system".
To get back more on topic, there's no assurance that SCO won't sue both Sun and Compaq, attempting to turn all existing installations of their systems into infringing revenue sources. I don't see how Linux is more of a liability to end users, and may be much less - wouldn't one possible outcome of a trial be a finding that Linux being Open Source is an affirmative defense against infringement, as anyone being infringed upon can easily find out, and that what SCO should have done is notify Linux, or one of the distributors, that they were infringing and to remove the code (and, SCO actually being a developer/distributor of Linux makes them even more responsible for checking for infringement in the Linux code base).
The NDA's are obviously necessary to SCO. If their claim to trade secret is to hold up, they simply can not, in any way, release that information in a way that would compromise that trade secret. Doing so would instantly invalidate their claim.
I've seen several comments complaining about the definition of confidential information in the NDA. It seems to me (NAL) that some of the fears are baseless - e.g. if they show you some public information (e.g. some lines of code from Linux or the LKML), that doesn't mean you can't ever use that information in the future, you simply can't reveal that such public information was part of what they gave you to look at. There is the potential issue of "contamination", but only if you write code that is accepted, and that code is fairly closely structured to code that you've been given access to. "Clean room engineering" is sufficient, but not necessary, to avoid copyright infringement. It seems to me that having seen the code, you could avoid even the appearance of infringement by making sure that the code you write is different. Just because I've read Stephen King novels doesn't mean I can't write my own horror fiction. Contrast with not being contaminated at all, but accidentally writing something very similar - it's going to be hard to prove you didn't have access. After all, according to SCO, anyone who's looked Linux kernel code should be considered contaminated already. Again, IANAL, but I don't think that NDA is quite as bad as some of the other NALs think.
I also think a lot of the bashing on Laura Didio has been uncalled for. Taking a few quotes out of context can make her sound bad, but overall she qualified most of her statements appropriately. Mostly what she's done is make the point that SCO needs to be taken seriously, but that they haven't proven anything yet. She did sort of mangle the implications of the GPL pretty badly, but then so do a lot of people on /.
Do a google search for "Software Defined Radio".
You missed the bit about "in sufficient detail to qualify for public disclosure". However, all of those items have been described in enough detail that no one can get a patent on "time machine" or "anti-gravity device" in general - only on a specific way of building one.
You no longer have to implement an idea in order to patent it. For example, you could quite likely patent a particular use of a time machine, as long as it hasn't already been described by someone else, even though you have no idea of how to actually build a time machine. However, if someone else invents a practical time machine, your patent will cover that particular use of that time machine. Your only obstacle might be convincing that patent office that time machines were possible (otherwise your idea has no utility, thus is unpatentable).
Under current patent rules, you probably could have patented "recording a movie on a small plastic disk", and thus been able to get royalties on every DVD made until your patent ran out - unless someone could show where some science fiction story or a story of future predictions ("What Will Life Be Like in Fifty Years") included enough detail. Then, of course, you'd simply have had to make your patent a little more detailed (using a laser, using polycarbonate with a metal film, encrypting and error-correcting, whatever wasn't mentioned in the published record). Include enough possible ways of doing it, and you might be lucky enough to stumble upon the way someone will actually try to do it.
There are many examples of this actually being done. Look at any of the so-called submarine patents that have been reported on, including the "microprocessor patent".
Simple solution: to be eligible for copyright protection (including DMCA protection), they have to follow restrictions. If they want to add additional protection beyond what something like this legislation would do, then they lose copyright protection and are ONLY protected by their technological methods - which means it would be legal to hack it by reverse engineering players, modifying players, analog hole, brute force cracking of keys, whatever you wanted.
You can't describe what you haven't invented. The very act of describing it in sufficient detail to qualify for public disclosure means you've already invented it. That doesn't mean you can't make further improvements, including actually getting something to work (which isn't necessary to patent it).
Say I describe A + B + C, and publish that; I've just invented it, THEN published it. If my patent application later describes A + B + C + D (where D is all the other details needed to use A + B + C effectively), that's no problem, that's a new invention. If I didn't claim just A + B + C in my patent, then anyone else is free to use that subset of my patent, and no one else can patent that particular combination either (unless they can show they invented it before it was published). However, I still have a year from that publication date in which to file a patent for just A + B + C (unless someone else knew/used/published it before I invented it).
The definition of "obvious" in patent law is patently unobvious. For instance, it probably fits the definition of "novel, non-obvious and useful" for me to patent the idea of having a stored user preference that controls the scroll rate of a list of products that a nano-manufacturing box can produce - and if I'm lucky enough that nano-manufacturing boxes (suitably described in the patent as a "device that can produce a plurality of products"), or something close enough to them, are available before my patent expires, I can prevent someone, including the holder of this particular patent, from using such an obvious idea. Unless, of course, I don't patent it in the next year (since I've now just published it).
The Amiga Toaster allows vertical scrolls for credits and such - each such page has a little dial icon that you can use to control the scroll rate. I'm pretty sure that program was in use well before 1995. Teleprompters also scroll at variable rates vertically. Even if you could find, say, a program that presented lists of options on a vertical scroll with a user-settable non-volatile preference setting for rate, it would still be "non-obvious" to extend that to a device where those options are lists of available content on a video device (or however the patent claims read). In other words, "non-obvious" and "novel" have such a limited meaning as to be almost useless except in a very literal sense.
BTW, you don't need to be an expert in the field in order to determine obviousness, merely "skilled" - and that is, apparently, defined as a moron with an encylopedic knowledge of everything that's been published on the subject who also is a patent lawyer.