This could actually work. "Accept" the job while refusing to sign the NCA. Keep a copy of your letter stating that you accept the offer in case your unemployment benefits are challenged, should it be the case they decline to employ you.
I've actually done that once on an indepdent contract. They wanted an NCA preventing me from working for any hosting company for a year. At the time, hosting companies were just starting on the scene, and that looked like a good field to work in. I simply explained that agreeing to that effectively agreed to be unemployed for a year for someone whose expertise was well focused on internet technology, and most ISPs were becoming hosting companies. I offered to agree not to take any customers with me to any new company (as if I could... I don't work in sales).
What if you are on unemployment, and you get only one job offer, and that offer includes a clause that requires you to agree not to read Slashdot. And because it is an offer, if you turn it down, you could lose your unemployment benefits. Would you take it or turn it down? Substitute just about anything else in the offer. Of course the benefits policies do include some limitations that do allow you to turn down certain offers. But I'm sure they have not thought about all the things that employers could screw you over with by merely making the offer.
Do not stoop to the low levels of SCO. Of course geeks could do DDoS attacks. Of course lawyers can file frivolous and/or harrassment lawsuits. Just because both have tools doesn't make either of them right.
Once it is known what line(s) of code are involved, then it's a matter of tracing back to who wrote it or contributed it. Testimony by the author may help. Proof of release dates may help. There are ways once the specifics are known. SCO is trying to prevent anyone from having time to research this by hiding facts until they actually have to show them during the legal proceedings.
And if in fact it turns out to be genuine SCO code that got in there, somehow, it should be possible to figure out the path it came from. The code would be removed and the kernel developers could cite where it came from. Maybe someone would get in trouble, depending. But until specifics are known, no serious action can be taken. If it's userland code, then it's a matter of that project author or team to work with.
If it's SysV init script code, at least my servers are safe because I already got rid of that:-)
OTOH, there are cheaper solutions. Alternatives include "dedicated server" (you get root/Administrator access and administer it yourself) or "dedicated managed server" (the hosting provider retains root/Administrator, administers it for you, but you still have a whole machine dedicated to you). A dedicated server can actually be fairly cheap because it can use cheaper IDE drives. If you can handle some downtime when a drive fails, most dedicated hosters can have you back up soon on a whole new machine. IMHO, that beats colocation where your access to replacement hardware is whatever you put there, and may have to do it yourself. Just be sure you have a specific time commitment from your hosting ISP with regard to time to replace failing hardware, and have a backup plan. Double the price and you can have a 2nd server hot online with replica data, ready to go, or even serve load balanced. Some hosters may even provide a "backup spare" server at less than full price.
If you intend to transmit any email from your server, you might want to reconsider and look elsewhere. There are spammers in the midst, and that means that at least some of the address space is blocked by who knows how many blacklists and/or networks. And they have never responded to my reports that one of their spammers was sending spam to me at a rate of 25 to 30 an hour continuously for a 3 week period (I had to access-list deny them at the router).
I challenge you: Where are the good C coders that write working code, without critical bugs, in any reasonable amount of time?
Define "reasonable amount of time". There are tradeoffs in time, cost, and quality. When you want the time to be shorter, the others are greater (you can still balance between them).
The C language is like "portable assembly". It isn't intended to do everything. What it does well is what needs to be close to what the CPU literally does, whether for direct access reasons, or for performance reasons. It is a "sharp tool" in the sense that it does give you that direct access, and the dangers associated with it. I tend to recommand that programmers who want to do C first learn an assembly language, so they learn the impact of making mistakes, and the details involved. Those will be the good C programmers. C doesn't even try to the abstract concepts you can do in Lisp. If an application needs those, then it's more appropriate to do in Lisp than in C. And it's more appropriate for you to do it than for me to do it (because I could never understand Lisp, but I do very well in assembly and C... difference in how brains are wired, I presume).
C supports rational numbers. The issue is how you define "support". In C, "support" for things like that means "you can code it". C99 does have complex numbers, and I think that's a mistake. Applications that need a complex number type I cannot imagine being appropriate for C (maybe Fortran or Java or Lisp... I'm sure Lisp has that, too). But any high level language that has something like complex numbers or rational numbers had to have that capability designed in some way. Some might do it in C, and some might do it in their own language (shouldn't be hard to do). But asking for rational numbers in C is like asking for rational numbers in assembly. Does the CPU have a rational numbers instruction?
Just take a look at what language most of those "advanced" systems are written in. I assume you are one of those kinds of programmers that needs someone to protect your from yourself with type-safety features. Of course you can find bad programmers anywhere, in any language. But the bad programmers don't mean the language is bad any more than drunk driving can be blamed on the car.
Keeping your indexes inside the bounds of an array is like coloring a picture and keeping inside the lines or driving a car and keeping it on the road. There's nothing to stop you from coloring outside the lines (you won't die because of this) or driving off the edge of a cliff (you will die because of this). Yet we aren't calling for "bounds checkers" for steering wheels. Programming in a language like C/C++ or even assembly gives you all the power you need just like a car, along with the responsibility to stay on the road and not drive drunk.
C/C++ gives you the power to create better code. And C/C++ gives you the power to create worse code. Which is done is up to the programmer. Some programmers shouldn't be given sharp tools. Some programmers need to be kept in padded cells to avoid hurting themselves or others.
Don't allow bad programmers to use sharp tools with which they may be able to hurt themselves or someone else. C and C++ are sharp tools. Perl and Python are blunt instruments.
And also pass the information on to your elected Congressional representative and Senators explaining to them that an "out of control" USPTO which issues frivilous and obvious patents is doing harm to the economy by causing businesses to waste resources arguing and litigating over such things. This is yet another example of a patent that would never have been issued had the USPTO been mandated by law to only issue patents to genuinely new and unique ideas.
How does anyone really know for sure that some urban legend really did not happen? Take the dog drying case. It's certainly plausible, as urban legends do stick around when that is the case. But a microwave oven is actually a lousy way to dry a dog (or anything for that matter). This legend, though, might have been derived from a case in the late 1960's when a woman in Ohio did (try to) dry (and did kill) her dog in a conventional oven.
If you really want to dry your dog safely, you need to get one of these.
The marijuana example is inapplicable. The laws don't focus on the rights to use the seeds; they focus on the fact that marijuana is a controlled substance and all aspects of it are affected by the law.
As for the farmer, he sure has a right to save his seeds and replant them. The fact that some are glyphosate resistant might be otherwise depriving him of the opportunity to save enough seed at all to have a full crop next year. To the extent that Monsanto's license is required, his rights have been taken away.
I don't think it should matter whether the farmer grows patented crops knowingly or not. What should matter is if he came by having these improperly, such as by stealing a sack of seed. If the genetics came to him on their own, then I think it is no different than Monsanto having come along and given him free seeds and a perpetual regrowing license. If a neighbor bought the seeds and let them leak, that's the neighbor's fault. I'm not against patents on genetically engineered plants. But I am against improperly enforcing such patents where care is not properly taken to protect the patent, and such "intrusion" by the patent affects the farmer (e.g. it reduced his yield of unpatented plants, and hence his yield of unpatented seeds).
I don't know if Canada ever considers traditional rights or not. But if something is a common, traditional, historical practice for years, decades, and even centuries (farming falls under this), then the right exists. The right might not be recognized by the law, but that doesn't change the existance of the right. A change in law should not be to grant such a right, but rather, to recognize that it exists (and always has). And courts (at least in that country south of Canada) can recognize such rights, too.
It's common practice in farming to retain seed from each crop to plant in the next year. What Monsanto is effectively doing is denying the farmer the right to carry on a traditional practice. The only thing the farmer is doing purposefully, apparently, is growing from the seed harvested on his own land. That traditional practice needs to be fully protected in law.
And Monsanto is showing absolute and utter ignorance when it claims there is no way for their seed to have escaped in any way. While I can't say whether this farmer "expedited" any cross pollination or cross seeding, I do know from knowing people who have worked on farms in the rural area I grew up in, that such a thing was common. It varied depending on the type of crop. Some crop types could spread their genetics far more easily than others. I do know corn was one of those that was a problem in that area. But it wasn't a big problem in the sense that anyone might get sued because their field got infested from a neighbor's crop. They were more worried that their field might have a mix of different kinds of corn.
Most likely they are afraid that the pieces of code, once specifically pointed out, will be copied into other software. Of course open source projects would be jumping to get that code removed and track back how it got in there in the first place. But what about a commercial OS? Would someone actually want to more likely grab that code once it's identified as being from SCO? If they wouldn't worry about theft, I'd think they also wouldn't worry about GPL implications, and just use whatever they like out of Linux. They can state that the reason to not identify what particular code is their trade secret property in order to preserve the secrecy, but in this case I don't think it will really matter because I doubt anyone will want to touch it (besides making sure it is removed from other OSes). But another reason is that they can use it to extort money from unknowing users who would rather pay them than upgrade to a version with SCO code removed.
There are investors who will react to a perceived value in intellectual property being pursued. It very well could be a tactic intended to raise the escape price and let the current investors dump a worthless company on another set who don't yet realize what is going on. I hope the SEC is taking a peek at this.
I don't claim to be a legal expert, either, but it does seem reasonable if SCO is claiming that I as a user could be using code protected under their intellectual property rights, that they could identify specifically what is, and what is not, part of their rights. I believe it is unreasonable for them to simply say, in an ambiguous way, that some of the computer code I am using is theirs. I have the source code to the Linux kernel, so it is not an unbreakable piece that I have to choose either to use or not use. Each character of the source code is a separate piece I can choose or not choose to use. I have in fact exercised that choice already, both in the form of configuring the kernel to select and unselect features, as well as having applied patches of my own to modify (delete some code and/or add some code). In much the same way they cannot deprive me from using my other computers by saying one of them happens to be running code of their property (e.g. they would have to know which one is, and would have to tell me which one)... they cannot deprive me of using those parts of Linux which are not their property.
And then there's the issue of disputing it. What if I believe that none of the code I am using is their property? They can't just assert that some is and expect that will be believed. What if they piece of code they claim is theirs is something I happened to write (since I've never seen SCO source code, I cannot possibly have copied it, although in the case of obvious algorithms I might have come up with something nearly identical... and that isn't protected by copyright law although patent law might have). I should have the right to specifically dispute it. And if the matter is settled in a way that I decide to withdraw my code from public, I also have to be able to tell the public exactly which piece of code to remove; I cannot just insist everyone stop using the entire program that my code might happen to just be a few pieces of.
And of course there is the issue that perhaps SCO (maybe even inadvertently) copied some of Linux code into their source. Maybe their programmers looked at Linux to get ideas and the code just looks similar (and perhaps won't even be affected by GPL).
This whole secrecy thing just doesn't fly when they are talking about code that's already in publically available source files. Suppose IBM really did leak the code in violation of the NDA and trade secret laws. The damage is already done in the sense that public eyes can see it. And sure, they'd have certain rights to recover those damages from IBM if IBM caused it to happen. But as to whether they want others to stop using it, they really must identify that which is theirs so that it can be stopped.
Perhaps this will have to open up new case law in the issues of trade secret law. Usually in cases of trade secret, the party that illegally acquired the trade secrets simply used them rather than give them away to everyone. If some of their code really is in Linux, then either someone did leak it, or it's a huge coincidence.
So, let's assume SCO is right, and their code really is in the Linux kernel, and they even know the trail of how it got there. They would have certain rights for past infringement (and it's not nearly as much compared to cases where the infringers are aware). Let's assume the past infringement is settled and IBM pays them a certain amount to settle that. What about future infringement. Since SCO is widening the case and not limiting it to IBM, then clearly they are not expecting IBM to compensate them for all the infringement. Had they simply blamed IBM for leaking it to the public and demanded IBM pay for all the value leaked, then the code could stay and no one would have to worry once the matter is settled with IBM. But instead, it can be implied that they want the code to be removed, yet are refusing to allow that to be done.
If they had merely pursued a case against IBM to recover their losses and the value
Chris Sontag, senior vice president and general manager of The SCO Group's SCOsource licensing operation, said in an interview that he will show independent experts, under a non-disclosure agreement, the evidence behind SCO's allegations that the Linux kernel source contains code copied from SCO UnixWare illegally and without credit.
And will they even keep secret the names of these so-called experts? Of course I would never trust anyone who signs a non-disclosure agreement that prevents them from revealing the full truth about what they are examining. I probably would never trust those people about anything ever again. I know I would never sign such an agreement (but I don't have the political clout to be called an expert, so I'll let my 24 years of operating systems work (including source code internals), 19 years of C programming, 15 years of Unix experience, and 9 years of working on Linux, continue to do what it should be doing... which doesn't include helping low-life underpaid executives recover their worthless stock options).
UnitedLinux should eject SCO. Our boycott (permanent for SCO) should eventually extend to UnitedLinux if they continue to retain SCO as a partner. That would mean Connectiva, SuSE, and TurboLinux would be at risk of boycott just for being associated. If UnitedLinux won't do the right thing, these 3 companies should leave and start a new thing together, without SCO being involved at all.
Or better yet, ask UnitedLinux why they are still keeping SCO are a partner. Whereas before I was merely boycotting SCO, it has now gotten to the point where I will never ever have anything to do with SCO ever again, no matter what they do now, and will be extending the boycott to Connectiva, SuSE, and TurboLinux... if they don't soon eject SCO from the UnitedLinux partnership.
SCO proprietary code -> IBM -> Linux kernel -> SCO -> release under the GPL.
This would narrow down the scope of the claimed infringement to that code which IBM has contributed to Linux. That is what they are claiming in the complaint against IBM. So any code not contributed by IBM or its employees who had access to the SCO IP, isn't part of this complaint. That's probably rather narrow. The significance of Linux is surely not dependent on that code, so while Linux certainly has cut SCO sales, I don't think it can be argued that reduction of sales is the result of that code being there.
Maybe it's something in IBM's Journaling File System?
But I think SCO's attitude about not revealing the specific allegations is part of the problem. I don't think the court is going to like it when IBM simply tells the court that SCO refused to tell them what was infringing so they could put a stop to any further damages. Also, IBM can't be prepared when they come to court (and any judge will understand this) because of the refusal to reveal this. What I wonder about right now is why IBM isn't (or maybe they are doing this) going through a discovery process to find out the facts of the case.
Personally, I'd live to see a group of Linux vendors "gang up" and file a suit against SCO for false statements and fraud... just to further force the discovery process. I doubt that would happen, but if it did, I'd do a little dance.
In my view, SCO is now a doomed company. It cannot be recovered. They have gone so far with this now there is no backing and and recovering any good will from the Linux community. Hell, I won't even have anything to do with United Linux until those guys eject SCO from their group.
So if some ISP is hosting someone who is eating up your bandwidth with ping packets, and never stops, you're going to consider that to be just like the phone company and not try to get them to stop it... or if you do ask them to and they ignore you, you're not going to blame them for hosting someone who attacks other networks?
I don't know of any cases where the existance of music trading, or kiddie porn, has denied me of the resources and services I have paid for on the internet. Those may or may not be bad things depending on your point of view, but they are not something that has come along and actually stolen something from you or me. I can certainly see that some people will have the view that some of those things do steal from them, and so I can understand them wanting to do something about it. And I can understand if something is illegal, that law enforcement is expected to pursue it. Someone who tries to crack into your computer is different. If they do a denial of service attack, I think you clearly have cause against an ISP that does nothing about it.
And yes, if you repeatedly dial up the same person or business over and over, the phone company can, and may, disconnect your service. Or they can also just block you from calling that number (if they bought the switch feature option that allows them to do that).
A great many spammers are actually conducting a denial of service attack. I won't say that of someone who tries sending one spam once to each address in a mailing list they bought. But there are lots of spammers who are incessantly conducting spamming over and over to mail servers of mine that are refusing that mail. Yes, I blocked the spammers, but they keep on trying. It uses bandwidth. It uses processes on the server. It uses up RAM and swap space. It costs me money. And the ISPs take money from those spammers that cost me money. It's like they are allowing this just so they can get rich. This is why I have blocked the entirety of places like Rackspace and Rackshack (also known as Everyone's Internet). They host spammers and they profit off those denial of service attacks. So they are as much slime as spammers are.
Just use one MX record. Period. There is no need for any additional MX records. And certainly don't use any mail server you don't have total policy control over as a secondary MX. Be sure all your users are configured on that server. Never make any rejection decisions after the SMTP session has accepted the mail. If you are going to refuse/reject any mail, do so only during the SMTP session. Any decisions made after the SMTP session should only put mail in special boxes or folders, such as the spam folder.
If you let your mail server do bounces, in addition to having that extra workload, you also run the risk of being blocked. If a spammer thinks you have a lot of users or otherwise tries a dictionary attack on your mail server, and if you queue bounces from such an attack, and if the attacker forged email addresses at some place like aol.com, then your mail server would end up attempting a massive delivery of bounce messages to them. They would detect that as spam due to the sudden volume spike, and block you.
Slashdot Mirror
This could actually work. "Accept" the job while refusing to sign the NCA. Keep a copy of your letter stating that you accept the offer in case your unemployment benefits are challenged, should it be the case they decline to employ you.
I've actually done that once on an indepdent contract. They wanted an NCA preventing me from working for any hosting company for a year. At the time, hosting companies were just starting on the scene, and that looked like a good field to work in. I simply explained that agreeing to that effectively agreed to be unemployed for a year for someone whose expertise was well focused on internet technology, and most ISPs were becoming hosting companies. I offered to agree not to take any customers with me to any new company (as if I could ... I don't work in sales).
What if you are on unemployment, and you get only one job offer, and that offer includes a clause that requires you to agree not to read Slashdot. And because it is an offer, if you turn it down, you could lose your unemployment benefits. Would you take it or turn it down? Substitute just about anything else in the offer. Of course the benefits policies do include some limitations that do allow you to turn down certain offers. But I'm sure they have not thought about all the things that employers could screw you over with by merely making the offer.
Do not stoop to the low levels of SCO. Of course geeks could do DDoS attacks. Of course lawyers can file frivolous and/or harrassment lawsuits. Just because both have tools doesn't make either of them right.
Once it is known what line(s) of code are involved, then it's a matter of tracing back to who wrote it or contributed it. Testimony by the author may help. Proof of release dates may help. There are ways once the specifics are known. SCO is trying to prevent anyone from having time to research this by hiding facts until they actually have to show them during the legal proceedings.
And if in fact it turns out to be genuine SCO code that got in there, somehow, it should be possible to figure out the path it came from. The code would be removed and the kernel developers could cite where it came from. Maybe someone would get in trouble, depending. But until specifics are known, no serious action can be taken. If it's userland code, then it's a matter of that project author or team to work with.
If it's SysV init script code, at least my servers are safe because I already got rid of that :-)
What? No referral program for their customers? And I was hoping I could help pay for a dedicated server that way.
OTOH, there are cheaper solutions. Alternatives include "dedicated server" (you get root/Administrator access and administer it yourself) or "dedicated managed server" (the hosting provider retains root/Administrator, administers it for you, but you still have a whole machine dedicated to you). A dedicated server can actually be fairly cheap because it can use cheaper IDE drives. If you can handle some downtime when a drive fails, most dedicated hosters can have you back up soon on a whole new machine. IMHO, that beats colocation where your access to replacement hardware is whatever you put there, and may have to do it yourself. Just be sure you have a specific time commitment from your hosting ISP with regard to time to replace failing hardware, and have a backup plan. Double the price and you can have a 2nd server hot online with replica data, ready to go, or even serve load balanced. Some hosters may even provide a "backup spare" server at less than full price.
If you intend to transmit any email from your server, you might want to reconsider and look elsewhere. There are spammers in the midst, and that means that at least some of the address space is blocked by who knows how many blacklists and/or networks. And they have never responded to my reports that one of their spammers was sending spam to me at a rate of 25 to 30 an hour continuously for a 3 week period (I had to access-list deny them at the router).
Define "reasonable amount of time". There are tradeoffs in time, cost, and quality. When you want the time to be shorter, the others are greater (you can still balance between them).
The C language is like "portable assembly". It isn't intended to do everything. What it does well is what needs to be close to what the CPU literally does, whether for direct access reasons, or for performance reasons. It is a "sharp tool" in the sense that it does give you that direct access, and the dangers associated with it. I tend to recommand that programmers who want to do C first learn an assembly language, so they learn the impact of making mistakes, and the details involved. Those will be the good C programmers. C doesn't even try to the abstract concepts you can do in Lisp. If an application needs those, then it's more appropriate to do in Lisp than in C. And it's more appropriate for you to do it than for me to do it (because I could never understand Lisp, but I do very well in assembly and C ... difference in how brains are wired, I presume).
C supports rational numbers. The issue is how you define "support". In C, "support" for things like that means "you can code it". C99 does have complex numbers, and I think that's a mistake. Applications that need a complex number type I cannot imagine being appropriate for C (maybe Fortran or Java or Lisp ... I'm sure Lisp has that, too). But any high level language that has something like complex numbers or rational numbers had to have that capability designed in some way. Some might do it in C, and some might do it in their own language (shouldn't be hard to do). But asking for rational numbers in C is like asking for rational numbers in assembly. Does the CPU have a rational numbers instruction?
Just take a look at what language most of those "advanced" systems are written in. I assume you are one of those kinds of programmers that needs someone to protect your from yourself with type-safety features. Of course you can find bad programmers anywhere, in any language. But the bad programmers don't mean the language is bad any more than drunk driving can be blamed on the car.
Keeping your indexes inside the bounds of an array is like coloring a picture and keeping inside the lines or driving a car and keeping it on the road. There's nothing to stop you from coloring outside the lines (you won't die because of this) or driving off the edge of a cliff (you will die because of this). Yet we aren't calling for "bounds checkers" for steering wheels. Programming in a language like C/C++ or even assembly gives you all the power you need just like a car, along with the responsibility to stay on the road and not drive drunk.
C/C++ gives you the power to create better code. And C/C++ gives you the power to create worse code. Which is done is up to the programmer. Some programmers shouldn't be given sharp tools. Some programmers need to be kept in padded cells to avoid hurting themselves or others.
Don't allow bad programmers to use sharp tools with which they may be able to hurt themselves or someone else. C and C++ are sharp tools. Perl and Python are blunt instruments.
And also pass the information on to your elected Congressional representative and Senators explaining to them that an "out of control" USPTO which issues frivilous and obvious patents is doing harm to the economy by causing businesses to waste resources arguing and litigating over such things. This is yet another example of a patent that would never have been issued had the USPTO been mandated by law to only issue patents to genuinely new and unique ideas.
How does anyone really know for sure that some urban legend really did not happen? Take the dog drying case. It's certainly plausible, as urban legends do stick around when that is the case. But a microwave oven is actually a lousy way to dry a dog (or anything for that matter). This legend, though, might have been derived from a case in the late 1960's when a woman in Ohio did (try to) dry (and did kill) her dog in a conventional oven.
If you really want to dry your dog safely, you need to get one of these.
The marijuana example is inapplicable. The laws don't focus on the rights to use the seeds; they focus on the fact that marijuana is a controlled substance and all aspects of it are affected by the law.
As for the farmer, he sure has a right to save his seeds and replant them. The fact that some are glyphosate resistant might be otherwise depriving him of the opportunity to save enough seed at all to have a full crop next year. To the extent that Monsanto's license is required, his rights have been taken away.
I don't think it should matter whether the farmer grows patented crops knowingly or not. What should matter is if he came by having these improperly, such as by stealing a sack of seed. If the genetics came to him on their own, then I think it is no different than Monsanto having come along and given him free seeds and a perpetual regrowing license. If a neighbor bought the seeds and let them leak, that's the neighbor's fault. I'm not against patents on genetically engineered plants. But I am against improperly enforcing such patents where care is not properly taken to protect the patent, and such "intrusion" by the patent affects the farmer (e.g. it reduced his yield of unpatented plants, and hence his yield of unpatented seeds).
I don't know if Canada ever considers traditional rights or not. But if something is a common, traditional, historical practice for years, decades, and even centuries (farming falls under this), then the right exists. The right might not be recognized by the law, but that doesn't change the existance of the right. A change in law should not be to grant such a right, but rather, to recognize that it exists (and always has). And courts (at least in that country south of Canada) can recognize such rights, too.
It's common practice in farming to retain seed from each crop to plant in the next year. What Monsanto is effectively doing is denying the farmer the right to carry on a traditional practice. The only thing the farmer is doing purposefully, apparently, is growing from the seed harvested on his own land. That traditional practice needs to be fully protected in law.
And Monsanto is showing absolute and utter ignorance when it claims there is no way for their seed to have escaped in any way. While I can't say whether this farmer "expedited" any cross pollination or cross seeding, I do know from knowing people who have worked on farms in the rural area I grew up in, that such a thing was common. It varied depending on the type of crop. Some crop types could spread their genetics far more easily than others. I do know corn was one of those that was a problem in that area. But it wasn't a big problem in the sense that anyone might get sued because their field got infested from a neighbor's crop. They were more worried that their field might have a mix of different kinds of corn.
Most likely they are afraid that the pieces of code, once specifically pointed out, will be copied into other software. Of course open source projects would be jumping to get that code removed and track back how it got in there in the first place. But what about a commercial OS? Would someone actually want to more likely grab that code once it's identified as being from SCO? If they wouldn't worry about theft, I'd think they also wouldn't worry about GPL implications, and just use whatever they like out of Linux. They can state that the reason to not identify what particular code is their trade secret property in order to preserve the secrecy, but in this case I don't think it will really matter because I doubt anyone will want to touch it (besides making sure it is removed from other OSes). But another reason is that they can use it to extort money from unknowing users who would rather pay them than upgrade to a version with SCO code removed.
There are investors who will react to a perceived value in intellectual property being pursued. It very well could be a tactic intended to raise the escape price and let the current investors dump a worthless company on another set who don't yet realize what is going on. I hope the SEC is taking a peek at this.
I don't claim to be a legal expert, either, but it does seem reasonable if SCO is claiming that I as a user could be using code protected under their intellectual property rights, that they could identify specifically what is, and what is not, part of their rights. I believe it is unreasonable for them to simply say, in an ambiguous way, that some of the computer code I am using is theirs. I have the source code to the Linux kernel, so it is not an unbreakable piece that I have to choose either to use or not use. Each character of the source code is a separate piece I can choose or not choose to use. I have in fact exercised that choice already, both in the form of configuring the kernel to select and unselect features, as well as having applied patches of my own to modify (delete some code and/or add some code). In much the same way they cannot deprive me from using my other computers by saying one of them happens to be running code of their property (e.g. they would have to know which one is, and would have to tell me which one) ... they cannot deprive me of using those parts of Linux which are not their property.
And then there's the issue of disputing it. What if I believe that none of the code I am using is their property? They can't just assert that some is and expect that will be believed. What if they piece of code they claim is theirs is something I happened to write (since I've never seen SCO source code, I cannot possibly have copied it, although in the case of obvious algorithms I might have come up with something nearly identical ... and that isn't protected by copyright law although patent law might have). I should have the right to specifically dispute it. And if the matter is settled in a way that I decide to withdraw my code from public, I also have to be able to tell the public exactly which piece of code to remove; I cannot just insist everyone stop using the entire program that my code might happen to just be a few pieces of.
And of course there is the issue that perhaps SCO (maybe even inadvertently) copied some of Linux code into their source. Maybe their programmers looked at Linux to get ideas and the code just looks similar (and perhaps won't even be affected by GPL).
This whole secrecy thing just doesn't fly when they are talking about code that's already in publically available source files. Suppose IBM really did leak the code in violation of the NDA and trade secret laws. The damage is already done in the sense that public eyes can see it. And sure, they'd have certain rights to recover those damages from IBM if IBM caused it to happen. But as to whether they want others to stop using it, they really must identify that which is theirs so that it can be stopped.
Perhaps this will have to open up new case law in the issues of trade secret law. Usually in cases of trade secret, the party that illegally acquired the trade secrets simply used them rather than give them away to everyone. If some of their code really is in Linux, then either someone did leak it, or it's a huge coincidence.
So, let's assume SCO is right, and their code really is in the Linux kernel, and they even know the trail of how it got there. They would have certain rights for past infringement (and it's not nearly as much compared to cases where the infringers are aware). Let's assume the past infringement is settled and IBM pays them a certain amount to settle that. What about future infringement. Since SCO is widening the case and not limiting it to IBM, then clearly they are not expecting IBM to compensate them for all the infringement. Had they simply blamed IBM for leaking it to the public and demanded IBM pay for all the value leaked, then the code could stay and no one would have to worry once the matter is settled with IBM. But instead, it can be implied that they want the code to be removed, yet are refusing to allow that to be done.
If they had merely pursued a case against IBM to recover their losses and the value
And will they even keep secret the names of these so-called experts? Of course I would never trust anyone who signs a non-disclosure agreement that prevents them from revealing the full truth about what they are examining. I probably would never trust those people about anything ever again. I know I would never sign such an agreement (but I don't have the political clout to be called an expert, so I'll let my 24 years of operating systems work (including source code internals), 19 years of C programming, 15 years of Unix experience, and 9 years of working on Linux, continue to do what it should be doing ... which doesn't include helping low-life underpaid executives recover their worthless stock options).
UnitedLinux should eject SCO. Our boycott (permanent for SCO) should eventually extend to UnitedLinux if they continue to retain SCO as a partner. That would mean Connectiva, SuSE, and TurboLinux would be at risk of boycott just for being associated. If UnitedLinux won't do the right thing, these 3 companies should leave and start a new thing together, without SCO being involved at all.
Or better yet, ask UnitedLinux why they are still keeping SCO are a partner. Whereas before I was merely boycotting SCO, it has now gotten to the point where I will never ever have anything to do with SCO ever again, no matter what they do now, and will be extending the boycott to Connectiva, SuSE, and TurboLinux ... if they don't soon eject SCO from the UnitedLinux partnership.
This would narrow down the scope of the claimed infringement to that code which IBM has contributed to Linux. That is what they are claiming in the complaint against IBM. So any code not contributed by IBM or its employees who had access to the SCO IP, isn't part of this complaint. That's probably rather narrow. The significance of Linux is surely not dependent on that code, so while Linux certainly has cut SCO sales, I don't think it can be argued that reduction of sales is the result of that code being there.
Maybe it's something in IBM's Journaling File System?
But I think SCO's attitude about not revealing the specific allegations is part of the problem. I don't think the court is going to like it when IBM simply tells the court that SCO refused to tell them what was infringing so they could put a stop to any further damages. Also, IBM can't be prepared when they come to court (and any judge will understand this) because of the refusal to reveal this. What I wonder about right now is why IBM isn't (or maybe they are doing this) going through a discovery process to find out the facts of the case.
Personally, I'd live to see a group of Linux vendors "gang up" and file a suit against SCO for false statements and fraud ... just to further force the discovery process. I doubt that would happen, but if it did, I'd do a little dance.
In my view, SCO is now a doomed company. It cannot be recovered. They have gone so far with this now there is no backing and and recovering any good will from the Linux community. Hell, I won't even have anything to do with United Linux until those guys eject SCO from their group.
So if some ISP is hosting someone who is eating up your bandwidth with ping packets, and never stops, you're going to consider that to be just like the phone company and not try to get them to stop it ... or if you do ask them to and they ignore you, you're not going to blame them for hosting someone who attacks other networks?
I don't know of any cases where the existance of music trading, or kiddie porn, has denied me of the resources and services I have paid for on the internet. Those may or may not be bad things depending on your point of view, but they are not something that has come along and actually stolen something from you or me. I can certainly see that some people will have the view that some of those things do steal from them, and so I can understand them wanting to do something about it. And I can understand if something is illegal, that law enforcement is expected to pursue it. Someone who tries to crack into your computer is different. If they do a denial of service attack, I think you clearly have cause against an ISP that does nothing about it.
And yes, if you repeatedly dial up the same person or business over and over, the phone company can, and may, disconnect your service. Or they can also just block you from calling that number (if they bought the switch feature option that allows them to do that).
A great many spammers are actually conducting a denial of service attack. I won't say that of someone who tries sending one spam once to each address in a mailing list they bought. But there are lots of spammers who are incessantly conducting spamming over and over to mail servers of mine that are refusing that mail. Yes, I blocked the spammers, but they keep on trying. It uses bandwidth. It uses processes on the server. It uses up RAM and swap space. It costs me money. And the ISPs take money from those spammers that cost me money. It's like they are allowing this just so they can get rich. This is why I have blocked the entirety of places like Rackspace and Rackshack (also known as Everyone's Internet). They host spammers and they profit off those denial of service attacks. So they are as much slime as spammers are.
Just use one MX record. Period. There is no need for any additional MX records. And certainly don't use any mail server you don't have total policy control over as a secondary MX. Be sure all your users are configured on that server. Never make any rejection decisions after the SMTP session has accepted the mail. If you are going to refuse/reject any mail, do so only during the SMTP session. Any decisions made after the SMTP session should only put mail in special boxes or folders, such as the spam folder.
If you let your mail server do bounces, in addition to having that extra workload, you also run the risk of being blocked. If a spammer thinks you have a lot of users or otherwise tries a dictionary attack on your mail server, and if you queue bounces from such an attack, and if the attacker forged email addresses at some place like aol.com, then your mail server would end up attempting a massive delivery of bounce messages to them. They would detect that as spam due to the sudden volume spike, and block you.