In short the answer is yes. SCOs lawsuit is slowing the deployment of Linux and other OSS in at least my enterprise
The longer answer is below:
I've read a bunch of these SCO Bad vs. Linux Good threads on/. for the last few months. I haven't really seen anyone point out the challenge that OSS puts into the corporate world in terms of how using software, particular mission critical software, is different now with OSS model then in the old traditional enterprise license model. The biggest area of concern as noted before is the IP infringement and that is what the SCO case fundamentally is about regardless of its particular merits (or lack there of).
When a large enterprise goes down the road of building a critical business application (read as revenue producing) many times there is a contract negotiation that has an Indemnity clause to protect the company licensing the software from claims against intellectual property asserted by another party. The greatest risk for the mission critical application is that there could be an attempt at an injunctive action against the infringing parties (Not common, but it does happen anyone remember Amazon's one click and bn.com???). This then could mean the company licensing the software that infringes might have to shutdown their application. Not such a big deal if now I can't load those spiffy web applets in my browser to download MP3s or have to make two clicks to buy a book, but a real bummer if Im a bank and I cannot run my funds transfer system.
In the case that a traditional software application infringes on the IP of another the indemnity clause gives the end user some protection. [Of course an indemnity clause from Joe & Bob development, Inc. doesnt really mean that much to Mucho-Huge-Bank-Corp, Inc., but one from Mega-PC-Soft, Inc. might.) In either case it also places a burden, because of the indemnity clause, on the original software developer to do a search of intellectual property to see if the is an infringement and seek to license from the IP owner that intellectual property or re-build the infringing model. If I am a software development shop and know my industry my legal consul can perform that task, as I know the internal mechanisms of the software applications I developed. You see this happen all the time in standards bodies when new specifications are being developed its called "identification of necessary claims" by the parties to the standard.
The trick is this is very hard to do for an enterprise that is the end customer of an application. As such, all new software that use OSS either in the app layer or as the base OS is still being viewed with a hairy eye-ball and needs to have a "how do I move to something else" plan developed before it is deployed in my shop. This is manageable for something like Apache where I can replace it with another web server with a modest amount of trauma, but a whole different story when I need to rebuild from the ground up because I have to toss the operating system.
This was seen as activity on the net last night by some of the MSS firms. It seems post-patching of the Cicso boxes results in higher CPU utilization for a godd while. Not sure why yet, but maybe due to all that bad traffic...
How about the other 13k Acess Points in NYC???
on
The Wireless City
·
· Score: 2, Informative
Any of you seen the site PublicInternetProject.org They catalog over 13,000 access point in New York City. Including half a dozen in central park.
From thier site:
Research Specifics, Overall Statistics:
1) 13,707 unique nodes within manhattan 2) 4,038 (29.46%) WEP enabled
Trooper: I got an email alert from TiVo alerting me that you've been taping the Fast & the Furious, Fast Lane, Gone in 60 seconds, and other shows that match a repeat speeders profile.
Motorist: ummm. I think that was my son...
Trooper: No, sir it correlates with your EzPass acitivity as well. Please step out of the car...
One other thing is there was a major backup site location for one of the 'offsite' storage companies at WTC. Some folks who went through the trouble of sending data offiste had it destroyed as well.
Don't forget the 6.5 mile away suggestion from one of the other posts.
Offsite needs to be away from probable inclusions. In some places I've lived that might include a snow flake...
Also the revovery mostly worked, but the markets were closed a for several days. IMHO because to many firms were in disarray with both technology and human resources.
Nobody's DR scenarios prior to 9-11 anticipated losing mulitple facilities, communcations, transportation hubs, and personnel at the same time.
Operational Recovery: Gee I deleted this file, broke the hard drive, etc. aka Recovery from flukes and stupidity
Disaster Recovery: Gee my office turned into a dust pile, I should have that file. aka Recover from bad karma
Archive: Umm gee Mr. Aircraft Manufacturer did you test that engine mount when you built the plane? aka Recover from lawsuits.
Since the storage times and recovery times are different you may well need different solutions.
Operational recovery is short term 99% of the time. I need this back now so I want it close at hand. DR is a little longer term to recover. I get data sent to my backup site or a new machine and restore. Archive is much longer storage duration and higer latency for retrvial. I need this before I get to court next week.
I'd argue that long term storage of data should not be in raw format. How the heck am I going to recover a database file 17 years from now? (say for a patent dispute)
Be careful with your 'glass' based storage archive. I ran into this problem a few years ago. We were storing Ingres database files from VMS systems to RV-20 magento-optical platters. What would I do if we had to recover that data now???
Our solution to the above was lo-tech, but it works. We output the data in column format to microfiche.
IMHO the full suite requires a 3 pronged strategy
Local storage operational recovery
offsite media - DR
offsite & onsite - image ready copy or technology refresh regiment. (Maybe HTML may live long enough)
-M
BTW: I live 4 blocks from a 16 acre testament to DR planning...
Slashdot Mirror
In short the answer is yes. SCOs lawsuit is slowing the deployment of Linux and other OSS in at least my enterprise
/. for the last few months. I haven't really seen anyone point out the challenge that OSS puts into the corporate world in terms of how using software, particular mission critical software, is different now with OSS model then in the old traditional enterprise license model. The biggest area of concern as noted before is the IP infringement and that is what the SCO case fundamentally is about regardless of its particular merits (or lack there of).
The longer answer is below:
I've read a bunch of these SCO Bad vs. Linux Good threads on
When a large enterprise goes down the road of building a critical business application (read as revenue producing) many times there is a contract negotiation that has an Indemnity clause to protect the company licensing the software from claims against intellectual property asserted by another party. The greatest risk for the mission critical application is that there could be an attempt at an injunctive action against the infringing parties (Not common, but it does happen anyone remember Amazon's one click and bn.com???). This then could mean the company licensing the software that infringes might have to shutdown their application. Not such a big deal if now I can't load those spiffy web applets in my browser to download MP3s or have to make two clicks to buy a book, but a real bummer if Im a bank and I cannot run my funds transfer system.
In the case that a traditional software application infringes on the IP of another the indemnity clause gives the end user some protection. [Of course an indemnity clause from Joe & Bob development, Inc. doesnt really mean that much to Mucho-Huge-Bank-Corp, Inc., but one from Mega-PC-Soft, Inc. might.) In either case it also places a burden, because of the indemnity clause, on the original software developer to do a search of intellectual property to see if the is an infringement and seek to license from the IP owner that intellectual property or re-build the infringing model. If I am a software development shop and know my industry my legal consul can perform that task, as I know the internal mechanisms of the software applications I developed. You see this happen all the time in standards bodies when new specifications are being developed its called "identification of necessary claims" by the parties to the standard.
The trick is this is very hard to do for an enterprise that is the end customer of an application. As such, all new software that use OSS either in the app layer or as the base OS is still being viewed with a hairy eye-ball and needs to have a "how do I move to something else" plan developed before it is deployed in my shop. This is manageable for something like Apache where I can replace it with another web server with a modest amount of trauma, but a whole different story when I need to rebuild from the ground up because I have to toss the operating system.
My $0.02
This was seen as activity on the net last night by some of the MSS firms. It seems post-patching of the Cicso boxes results in higher CPU utilization for a godd while. Not sure why yet, but maybe due to all that bad traffic...
From thier site:
That is a little better than just Bryant Park.
Motorist: Umm, no
Trooper: I got an email alert from TiVo alerting me that you've been taping the Fast & the Furious, Fast Lane, Gone in 60 seconds, and other shows that match a repeat speeders profile.
Motorist: ummm. I think that was my son...
Trooper: No, sir it correlates with your EzPass acitivity as well. Please step out of the car...
Don't forget the 6.5 mile away suggestion from one of the other posts.
Offsite needs to be away from probable inclusions. In some places I've lived that might include a snow flake...
Also the revovery mostly worked, but the markets were closed a for several days. IMHO because to many firms were in disarray with both technology and human resources. Nobody's DR scenarios prior to 9-11 anticipated losing mulitple facilities, communcations, transportation hubs, and personnel at the same time.
They should now...
Operational Recovery: Gee I deleted this file, broke the hard drive, etc. aka Recovery from flukes and stupidity
Disaster Recovery: Gee my office turned into a dust pile, I should have that file. aka Recover from bad karma
Archive: Umm gee Mr. Aircraft Manufacturer did you test that engine mount when you built the plane? aka Recover from lawsuits.
Since the storage times and recovery times are different you may well need different solutions. Operational recovery is short term 99% of the time. I need this back now so I want it close at hand. DR is a little longer term to recover. I get data sent to my backup site or a new machine and restore. Archive is much longer storage duration and higer latency for retrvial. I need this before I get to court next week.
I'd argue that long term storage of data should not be in raw format. How the heck am I going to recover a database file 17 years from now? (say for a patent dispute)
Be careful with your 'glass' based storage archive. I ran into this problem a few years ago. We were storing Ingres database files from VMS systems to RV-20 magento-optical platters. What would I do if we had to recover that data now???
Ingres=CA=Dead, RV-20=Digital Equipment Corp=Dead, VMS=OpenVMS=DEC/COMPAQ/HP=still alive.
1 out of 3 doesn't get my data back.
Our solution to the above was lo-tech, but it works. We output the data in column format to microfiche.
IMHO the full suite requires a 3 pronged strategy
Local storage operational recovery offsite media - DR offsite & onsite - image ready copy or technology refresh regiment. (Maybe HTML may live long enough)
-M
BTW: I live 4 blocks from a 16 acre testament to DR planning...