Even a clause that says they are not liable does not exclude them from liability.
Here's an article on software liability clauses and theories on lawsuits regarding software liability. The key to success in a lawsuit is as follows:
Negligence: The company has a duty to take reasonable measures to make the product safe (no personal injuries or property damage), or no more unsafe than a reasonable customer would expect (skis are unsafe, but skiers understand the risk and want to buy skis anyway.) Under the right circumstances, a company can non-negligently leave a product in a dangerous condition.
The users of the software would assume that this software would be free from viruses. This company, by both not securing its networked systems from known viruses, and by not verifying that it's software was not virus-infected prior to release, acted negligently.
Now the question is -- would the reward of attempting lengthy litigation over a relatively small loss be worthwhile? Unfortunately, it's not all too often as such. To my knowledge, as of yet, data loss due to negligence (not resulting in death, destruction of people or property, etc) has not provided for large damages. I'm sure as judges and congress members become more technically savvy, we will see more resonable laws and judgements relating to software liability. Until then, good luck.
Depending upon the state, this law may vary, however, this text as follows comes from section 23 of this article:
As Mangren Research, 87 F.3d at 944 quotes from In res Innovation Constr. Sys., Inc., 793 F.2d 875, 887 (7th Cir. 1986): "The user of another's trade secret is liable if he uses it with modifications or improvements upon it effected by his own efforts, so long as the substance of the process is derived from the other's secret." Indeed, Motorola might face liability for misappropriation under the ITSA even if it used Nilssen's trade secrets "
only to demonstrate what pitfalls to avoid" (Affiliated Home Products, 57 Ill. App. 3d at 807).
In this case, prior experience, even if only used to avoid pitfalls in execution, would violate this specific law (Illinois Trade Secret Act) -- even without an implicit NDA preventing the use of that information. Keep in mind that people use their experience in this way all the time. This specific application of the law related to a person who thought out an electronic ballast business, brought it to Motorola, and got thrown out of the deal which Motorola later began business in.
The storage of this information, as with simple things such as fingerprints, leads to the question of what information is really to be gleaned from it.
Years ago, we knew that DNA was the building material for humans, but had no idea why or how. Now, we've mapped the human genome, at least in part, and can provide some insight into life expectancy, diseases, and many other facets of life. Given that everyone's retina is unique -- as much so as DNA -- I wonder whether we will find out in a few years that fingerprints and retina scans provide as much insight into our lives as those grocery store mini-books having been trying to tell us for years.
From the spscicomp.org PDF, on the 14th page, it was noted that this chip could boot with Linux, AIX, and OS/400 and worked with SMP. Is this simply due to IBM's willingness to work with Linux, or do other mainframe CPUs work with Linux using SMP?
On the side --- I'd love to see the kernel compile on that beast!
There is a solution. Write your software with a simple CRC check on startup. Validate the versions and CRCs the libraries that your software uses. If the libraries that your software uses are changed often, statically link your software. If that's not good enough, then write a few of your own libraries.
It's really very simple to keep software from passing back invalid data due to physical corruption of its storage media. A few thousand clock cycles every time your software starts up can save you hours of useless troubleshooting due to simple physical failures -- not to mention that it will let your client know when their hardware is failing. Checking libraries is something that is so rarely done as well in the Windows world. I'm surprised so many in the software development community have ignored the simple solutions that can be used to solve potential problems due to plausible and even common situations today -- virus infections, hardware failure, and library incompatibility. Ten years ago, it was common to see a CRC check on a piece of software -- what happened?
There is a lot that can be said for a company that spends the time to check their code and make certain their software responds appropriately to all possible input. However, there are so many other possible conflicts -- video, RAM, CPU, motherboard, kernel, libraries -- that without proper verification of hardware and software compatibility, you and I, software developers, will never be able to win. With so many ways to protect our software -- and so few that are used -- I can see why software consumers are so frustrated at this point of those from our trade who choose not to protect their software in such simple ways.
Having a look at a distant galaxy and determining the type of life it can sustain simply by peering at the color of the light that we see seems a bit far fetched. My scepticism is only compounded by the fact that we've as of yet not found another planet that can sustain life (as we know it). Therefore, I would tend to think that the majority of this "space discovery" information is rather flawed and scientifically unsubstantiated. Does anyone have information for a scientifically proven method of determining composition of a star, even if we've never explored anywhere remotely close to them? It seems that the scientific community, as it relates to space, is developing the chicken without ever having an egg.
The issue with biometric data storage is not necessarily its use for identifying people as they move about country. If they wanted to track you, they could do it well before they started developing useful facial recognition software.
The problem is truely with the storage medium, and the auditing and security placed on this data. If this data were stored on chips on the ID cards, possessed only by the actual card owner, we would have few problems. Sure, there would be theft potentially, but people steal Social Security Cards still. A central database designed for access by any DMV or law enforcement personel leaves many potential holes. It has been proven many times over that it is only a matter of money that can drive an employee like that to corruption -- especially in jobs which are so seriously underpaid.
In the US, there is a man creating masks for people who have been disfigured in fires. These masks are created to nearly mirror the original face. The face is designed based on a collection of pictures of the disfigured person. As facial pictures get better, these new digital images of us could potentially become someone's new face. As facial recognition software does not readily detect well-constructed masks, it would be impossible to differentiate the two based simply based on a picture.
Retina and fingerprint scanners have a similar issue, although Retina scanners are significantly more complicated to defeat. As many of these scanners rely on few points of verification, it only takes a minimal amount of work to falsify an image. Even fingerprints have in many cases been falsified. Consider that there are likely a few hundred to a few thousand programmers whom have designed some of these biometric identification software from companies which have since shutdown. These people have been involved in testing many thousands of false fingers and faces. Who's to say that these programmers may not be the next generation of criminal -- one who leaves an exact representation of other people's fingerprints, in perfect digital format, to commit crimes -- ditch the connection to themselves -- and have the ability to target this attack to anyone whom they wish. This applies simply to faces too -- given a sufficient digital image, one could construct a mask that could easily fool current facial-recognition software.
This is my true fear of this consolidation of information. When this was stored in 285,000,000 5"x7" cards in a huge warehouse protected by armed guards and requiring security clearance to enter, I was not concerned. Now, there is nothing complicated involved in pulling up any information they wish.
gov1#
Download complete. 100% of 542 megabytes. Elapsed Time: 00:40s allstates.tgz
gov1#
Slashdot Mirror
Here's an article on software liability clauses and theories on lawsuits regarding software liability. The key to success in a lawsuit is as follows: The users of the software would assume that this software would be free from viruses. This company, by both not securing its networked systems from known viruses, and by not verifying that it's software was not virus-infected prior to release, acted negligently.
Now the question is -- would the reward of attempting lengthy litigation over a relatively small loss be worthwhile? Unfortunately, it's not all too often as such. To my knowledge, as of yet, data loss due to negligence (not resulting in death, destruction of people or property, etc) has not provided for large damages. I'm sure as judges and congress members become more technically savvy, we will see more resonable laws and judgements relating to software liability. Until then, good luck.
In this case, prior experience, even if only used to avoid pitfalls in execution, would violate this specific law (Illinois Trade Secret Act) -- even without an implicit NDA preventing the use of that information. Keep in mind that people use their experience in this way all the time. This specific application of the law related to a person who thought out an electronic ballast business, brought it to Motorola, and got thrown out of the deal which Motorola later began business in.
The storage of this information, as with simple things such as fingerprints, leads to the question of what information is really to be gleaned from it.
Years ago, we knew that DNA was the building material for humans, but had no idea why or how. Now, we've mapped the human genome, at least in part, and can provide some insight into life expectancy, diseases, and many other facets of life. Given that everyone's retina is unique -- as much so as DNA -- I wonder whether we will find out in a few years that fingerprints and retina scans provide as much insight into our lives as those grocery store mini-books having been trying to tell us for years.
From the spscicomp.org PDF, on the 14th page, it was noted that this chip could boot with Linux, AIX, and OS/400 and worked with SMP. Is this simply due to IBM's willingness to work with Linux, or do other mainframe CPUs work with Linux using SMP?
On the side --- I'd love to see the kernel compile on that beast!
There is a solution. Write your software with a simple CRC check on startup. Validate the versions and CRCs the libraries that your software uses. If the libraries that your software uses are changed often, statically link your software. If that's not good enough, then write a few of your own libraries.
It's really very simple to keep software from passing back invalid data due to physical corruption of its storage media. A few thousand clock cycles every time your software starts up can save you hours of useless troubleshooting due to simple physical failures -- not to mention that it will let your client know when their hardware is failing. Checking libraries is something that is so rarely done as well in the Windows world. I'm surprised so many in the software development community have ignored the simple solutions that can be used to solve potential problems due to plausible and even common situations today -- virus infections, hardware failure, and library incompatibility. Ten years ago, it was common to see a CRC check on a piece of software -- what happened?
There is a lot that can be said for a company that spends the time to check their code and make certain their software responds appropriately to all possible input. However, there are so many other possible conflicts -- video, RAM, CPU, motherboard, kernel, libraries -- that without proper verification of hardware and software compatibility, you and I, software developers, will never be able to win. With so many ways to protect our software -- and so few that are used -- I can see why software consumers are so frustrated at this point of those from our trade who choose not to protect their software in such simple ways.
Having a look at a distant galaxy and determining the type of life it can sustain simply by peering at the color of the light that we see seems a bit far fetched. My scepticism is only compounded by the fact that we've as of yet not found another planet that can sustain life (as we know it). Therefore, I would tend to think that the majority of this "space discovery" information is rather flawed and scientifically unsubstantiated. Does anyone have information for a scientifically proven method of determining composition of a star, even if we've never explored anywhere remotely close to them? It seems that the scientific community, as it relates to space, is developing the chicken without ever having an egg.
The issue with biometric data storage is not necessarily its use for identifying people as they move about country. If they wanted to track you, they could do it well before they started developing useful facial recognition software. The problem is truely with the storage medium, and the auditing and security placed on this data. If this data were stored on chips on the ID cards, possessed only by the actual card owner, we would have few problems. Sure, there would be theft potentially, but people steal Social Security Cards still. A central database designed for access by any DMV or law enforcement personel leaves many potential holes. It has been proven many times over that it is only a matter of money that can drive an employee like that to corruption -- especially in jobs which are so seriously underpaid. In the US, there is a man creating masks for people who have been disfigured in fires. These masks are created to nearly mirror the original face. The face is designed based on a collection of pictures of the disfigured person. As facial pictures get better, these new digital images of us could potentially become someone's new face. As facial recognition software does not readily detect well-constructed masks, it would be impossible to differentiate the two based simply based on a picture. Retina and fingerprint scanners have a similar issue, although Retina scanners are significantly more complicated to defeat. As many of these scanners rely on few points of verification, it only takes a minimal amount of work to falsify an image. Even fingerprints have in many cases been falsified. Consider that there are likely a few hundred to a few thousand programmers whom have designed some of these biometric identification software from companies which have since shutdown. These people have been involved in testing many thousands of false fingers and faces. Who's to say that these programmers may not be the next generation of criminal -- one who leaves an exact representation of other people's fingerprints, in perfect digital format, to commit crimes -- ditch the connection to themselves -- and have the ability to target this attack to anyone whom they wish. This applies simply to faces too -- given a sufficient digital image, one could construct a mask that could easily fool current facial-recognition software. This is my true fear of this consolidation of information. When this was stored in 285,000,000 5"x7" cards in a huge warehouse protected by armed guards and requiring security clearance to enter, I was not concerned. Now, there is nothing complicated involved in pulling up any information they wish. gov1# Download complete. 100% of 542 megabytes. Elapsed Time: 00:40s allstates.tgz gov1#