Reliable Software and the Year 2000
Alistair Kelman
LSE Computer Security Research Centre
[email protected]
1. Introduction
To say that the Year 2000 problem looks like being a gift for us litigation lawyers is stating the obvious. But winning stupendous damages in court - or defeating justifiable claims - requires sophisticated planning and tactics. Everyone is gearing up for the forthcoming fight.
Let us look at this from both sides. If a software company suspects that the software it has sold will fail after the Year 2000 it has a problem. If it goes to the expense and trouble of discovering that the software will fail then it has created for itself a duty to inform all its customers so that they can take precautions. If it fails in that duty then, if and when litigation commences, it will have to supply the other side with the documents which showed that it knew about the fault and did nothing since these documents will have been created in the normal course of the business and were not created in contemplation of litigation under legal professional privilege. Bingo for triple damages awards of punitive damages by a Californian jury against the software company. However if it does inform its customers of the fault it is inviting litigation - particularly if it informs them of the fault when a reasonable man would find that it was too late for the customer to adequately protect itself from coming to harm. Alternatively if the software company does not investigate its software and it fails because of the Year 2000 problem its customers may at the time suffer so many other problems that no litigation begins. Many companies are now so dependant upon their computers that they cannot survive more than a few days denial of service. Like Victorian surgeons the software company with the latent Year 2000 problem may be able to bury its mistakes - particularly if there is general chaos (power outages, accidents, telecommunications failures etc) immediately after the Year 2000.
For the customer there is a different problem. Undoubtedly with all the publicity there is now a duty upon computer users who handle personal data belonging to third parties to investigate and determine whether their computing environment is Year 2000 compliant. They could be liable under data protection law for denial of service to the third parties and for loss or damage to the personal data which causes actual loss to the third parties. Shareholder actions against companies which do not act and suffer losses are also a possibility. Consequently computer users need to factor the Year 2000 problem into their corporate disaster recover plans - which in any event need to be kept under regular review.
But, as professional litigators, in considering the Year 2000 situation we must also be aware that during the 1990s one of the greatest dogmas of computer science has been overturned. Until recently it was safe to say that because you could never prove that a particular piece of software was error free it was impossible to create a system which was completely reliable unless you adopted military style code review procedures. The growth of the Open Source Software movement and the development of Linux has proved this to be wrong: reliable software can come into being through an entirely different route. And the consequences for the established software industry are serious.
Many lay people will find the explanation of Open Source Software development and its implications difficult concepts to grasp at first. So to introduce the consequences I have composed a Millennium Fable:
2. A Millennium Fable
Once upon a time there was a man who built a Magic System. It wasn't really a Magic System but it did wonderful things and to the ordinary people the things it could do appeared to be Magical. The man never allowed anyone to see inside the System but kept its contents secret. He also charged people a lot of money for use of his Magic System.
Over several years the man sold the use of his System to many many people and made lots and lots of money. The people started using his Magic System for lots and lots of things and built their lives around it. The Magic System ran their homes, their offices, their hospitals, their schools, their nuclear power plants. Society and modern civilisation came to depend upon the Magic System and its availability.
The man knew all this. And the man knew that his Magic System was not perfect and that it could fail and cause damage in unexpected ways. So he protected himself by making a statement on his Magic System 'Hear Ye, Hear Ye - If you choose to use my Magic System for anything all risks in it failing belong to you and not to me.' The man believed that if damage occurred the courts would say that his statement was reasonable and would absolve him from liability because the Magic System was very complicated and the man, rich though he was, could never test his Magic System to such an extent that all the possible faults in it were eliminated since such an activity would take several human lifetimes. The benefits of the Magic System were such that society at large would have to bear the costs of failure of the Magic System. Or so the man thought.
Then one day another man built a different system, a Living System. This Living System was even more complicated than the Magic System. But the man, proud of what he had done, showed anyone and everyone how his Living System worked and did not charge them lots of money to use his Living System. Within a short time millions of people had looked inside his Living System. And some of them saw faults and errors. But in gratitude to the man who had given them the Living System they told him about the faults and errors and provided repairs and corrections free of charge. The Living System got stronger and stronger and more reliable. More and more people started using it instead of the Magic System.
At long last there came the Day of Reckoning when both the Living System and the Magic System were tested to destruction. On the Day of Reckoning many people with Magic Systems found that they did not work properly. The man who licensed the Magic System was inundated with requests for help and support. The people could not help themselves regarding the operation of the Magic System since the man had kept everything in it secret. And weeks and months went by as the man sought to supply solutions to people who had depended upon the failing Magic System. Many people died, businesses which depended upon the Magic System went bankrupt. And those that had been hurt but survived decided to sue the man who owned the Magic System.
On the Day of Reckoning the Living System was also tested to destruction. But here the fact that everybody knew what was inside the Living System meant that everyone was able to help each other. Failings were quickly spotted and fixed by the army of helpers who worked on the Living System, supporting and helping each other. The Living System survived and was made stronger and better.
Some time later the man who produced the Magic System found himself in the courtroom facing thousands of injured people. He told the judge 'It is not my fault all these people got hurt. Even if I had worked night and day to test and fix all the errors and faults in the Magic System there would still have been faults in it. It is reasonable for me to relay upon my 'Hear Ye' statement as absolving me from liability. Society has benefited by having my Magic System, faults and all, and I demand the protection of the court.' But the judge said 'Ah, but you did not do everything. You kept the contents of your Magic System secret so that people could not look inside it and fix your errors. Although you and your friends alone could not have fixed all the faults in your Magic System had you opened your Magic System out to everyone they would have come in, seen how it worked and would have fixed all your faults as they did with the Living System. So you did not act reasonably and you are not entitled to rely upon your 'Hear Ye' statement. You must compensate each and every person who has been harmed by your Magic System.
And the man who had the Magic System wailed and gnashed but was ordered to hand over all his money to the damaged people.
Moral: When comparing Possessions and Knowledge remember - you have to look after Possessions; Knowledge looks after you
3. Open Source Software
[Note - in this section I have drawn extensively and with permission, upon the writings of Mr Eric Raymond, the author of the seminal paper ' The Cathedral and the Bazaar ']
Open Source Software (OSS) is software in which both source and binaries are distributed or accessible for a given product, usually for free. OSS is often mistaken for 'shareware' or 'freeware' but there are significant differences between these licensing models and the process around each product.
The basic idea behind open source is very simple. When programmers on the Internet can read, redistribute, and modify the source for a piece of software, it evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.
But the most interesting feature of the Open Source Software development process, for us Year 2000 litigators, is that the rapid evolutionary process produces better software than the traditional closed model, in which only a very few programmers can see source code and everybody else must blindly use an opaque block of bits. In Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services from the Computer Science Department of the University of Wisconsin - Madison the researchers reliability conclusions were:
-
'The failure rate of utilities on the commercial versions of UNIX that we tested...ranged from 15-43%.'
-
'The failure rate of the utilities on the freely-distributed Linux version of UNIX [an Open Source Software product] was second-lowest, at 9%.'
-
'The failure rate of the public GNU utilities [another Open Source Software product] was the lowest in our study, at only 7%.'
The reasons why Open Source Software works and produces reliable code were analysed initially by Eric Raymond in ' The Cathedral and the Bazaar '.
In 'The Cathedral and the Bazaar' Raymond anatomised a successful open-source project, fetchmail, that was run as a deliberate test of some of his surprising theories about software engineering which had been suggested by the history of the development of the Linux operating system. In doing so he derived a series of rules-of-thumb which could be exploited by other Open Source Software projects in the future:
This summarises one of the core motivations of developers in the Open Source Software process: solving an immediate problem at hand faced by an individual developer without constant 'assistance' and feedback from marketing and focus groups. The developers are in control of their projects and are keen to make them work.
Because all developers in an Open Source environment always have access to entire source all the time they are more likely to reuse code than in a more traditional development. Widely available open source reduces search costs for finding a particular code snippet. Human beings in Open Source Projects work smarter by reusing code rather than writing it afresh. This leads to leaner, more elegant and more reliable software. If many people are using the same code for a variety of different purposes it is likely that in the course of their development work any bugs in the code will manifest themselves.
Remember that if a computer program contain twenty decision points there are more than a million logical paths through it - and a program with twenty decision points is likely to be quite a small program. Full testing of this program would require a developer to test everyone of those logical paths to ensure that none of them gave rise to bugs. It is clearly better to write a program by assembling existing modules that have already undergone some testing by a variety of users than to start afresh every time.
Quoting Fred Brooks, 'The Mythical Man-Month', Chapter 11. (ISBN: 0201835959) Open Source Development is characterised by several initial prototypes followed by the selection and refinement of a single design under a Darwin-like system of 'survival of the fittest'.
If users are properly acknowledged as being contributors to the development process and are rewarded by the sight of constant improvement in their work, the co-operative effort will improve quality of the code. Code documentation is an area which commercial developers typically neglect. The same thing happening would be a fatal mistake in Open Source Software. Fortunately by harnessing users as co-developers in Open Source Software development projects the documentation gets written as part of the ongoing development process.
Open Source Software developments are characterised by having two releases constantly on the go. The first is a stable software release which is fully reliable but may not have all the up-to-the-minute features wanted by some of the users. The stable software release cycle is about once every six months. In parallel with the stable software release is a development release which is less reliable since it contains new code which is still under development. These second development releases happen very frequently - sometimes on a daily basis. The user can thus choose between stability and functionality. If he signs up to become part of the development release cycle he expects that the code may fail from time to time. But in return he gets all the latest features and is able to actively contribute to the development process himself.
The rapid software development release system leads to a huge variety of scenarios actually being played out on computer systems around the world. And thus when a hidden bug manifests itself in the stable release there is a huge 'biodiversity' pool of alternative code from the parallel development release system to call upon to cure the bug. In the Linux community, for example, when the TearDrop IP attack was first posted to the web, less than 24 hours passed before the Linux community had a working fix available for download.
Raymond paraphrases this rule as 'debugging is parallelizable'. Open Source Software projects, such as Linux, utilise multiple small teams of individuals independently solving particular problems. Because the developers are typically hobbyists, the ability to `fund' multiple, competing efforts is not an issue and the Open Source Software process benefits from the ability to pick the best potential implementation out of the many produced.
In developing countries and within universities Open Source Software development is growing faster than the growth of the Internet. In an Internal Memos (which leaked) Microsoft stated:
'Open Source Software poses a direct, short-term revenue and platform threat to Microsoft, particularly in server space. Additionally, the intrinsic parallelism and free idea exchange in Open Source Software has benefits that are not replicable with our current licensing model and therefore present a long term developer mindshare threat.'
The Microsoft strategy of 'Embrace, Extend, Encircle and Extinguish' is not reconcilable to the Open Source Software development model (see http://indiaserver.com/itserver/viewpoint/viewpoint.html ).
4. Earning Money from Open Source Software Projects
At first glance it appears that Open Source Software development cannot make money in the commercial world. But this conclusion is wrong. Within the software marketplace there are companies which are making good money in selling Open Source software. They do so by packaging the binaries and source codes in an attractive and usable fashion and then, in some cases, providing a warranty regarding the reliability of the software which they are supplying. So if the Open Source Software goes wrong and the user loses there is someone who can be sued.
It is a common fallacy that software piracy (i.e. the availability of source code and binaries) destroys all software businesses - it can actually help some. In the early 1980s in the software industry the companies which developed database software actually wanted their works pirated and replicated. They got the bulk of their revenue not from the sale of software licences but from the sale of support to users. To sell support the software company had to have a substantial user base and to gain this it was economically desirable for the database software to be pirated. With the growth of Open Source Software this business model is becoming the norm.
With a pool of Open Source Software available individual computer programmers and software companies make a living by producing bespoke solutions to customers problems using Open Source Software components. The customer gets a software product which exactly suits him and the programmer and software company gets the revenue and job satisfaction which comes from doing a good job.
What is eliminated from this environment is monopoly value - the value a software company gains from being the sole source of binaries and support for its software. It can regain some of this revenue by providing warranties and help desk support to users. But the software company's standing within the marketplace depends on its reputation as a service company and the clear visible quality of the source code its programmers have contributed to the Open Source Software distribution.
5. Conclusion
Now that Open Source Software has proved itself as being reliable I find it unlikely to believe that a court would accept any limitation of liability in a software contract unless the source code of the software had been made readily available to a user community.
In the next issue of JILT I hope to be able to introduce an analysis of the various licensing agreements which are being used within the Open Source Software community. The analysis is being performed by a small team of Postgraduate students studying Information Systems at the London School of Economics under my supervision.
6. Further Reading:
'Open Source: the Future is Here' - http://www.opensource.org/
'Introduction to Open Source' - http://www.opensource.org/intro.html
'The Cathedral and the Bazaar', by Eric S Raymond - http://tuxedo.org/~esr/writings/cathedral-bazaar/
This is a Commentary published on 26 February 1999.
Citation: Kelman A, 'Reliable Software and the Year 2000', Commentary 1999 (1) The Journal of Information, Law and Technology (JILT). <http://elj.warwick.ac.uk/jilt/99-1/kelman.html>. New citation as at 1/1/04: <http://www2.warwick.ac.uk/fac/soc/law/elj/jilt/1999_1/kelman/>
|
