Section: New Results

Liability issues in software engineering

Participants : Daniel Le Métayer, Manuel Maarek, Eduardo Mazza.

Software contracts usually include strong liability limitations or even exemptions of the providers for damages caused by their products. This situation does not favour the development of high quality software because software editors don't have sufficient economical incentives to apply stringent development and verification methods. Indeed, experience shows that products tend to be of higher quality and more secure when the actors in position to influence their development are also the actors bearing the liability for their defects. The usual argument to justify this lack of liability is the fact that software products are too complex and versatile objects whose expected features (and potential defects) cannot be characterised precisely, and which thus cannot be treated as traditional (tangible) goods. Taking up this challenge is precisely the objective of the Lise project: the project studies liability issues both from the legal and the technical points of view with the aim to put forward a formal framework to (1) define liability in a precise and unambiguous way and (2) establish such liability in case of incident.

Obviously, specifying all liabilities in a formal framework is neither possible nor desirable. Usually, the parties wish to express as precisely as possible certain aspects which are of prime importance for them and prefer to state other aspects less precisely (either because it is impossible to foresee at contracting time all the events that may occur or because they do not want to be bound by too precise commitments). Taking this requirement into account, the Lise architecture provides different levels of services which can be used by the parties depending on the economic stakes and the timing constraints for the drafting of the contract:

1. The first level is a systematic (but informal) definition of liabilities.

2. The second level is the formal definition of liabilities. This formal definition itself can be more or less detailed and encompasses only a part of the liability rules defined informally. In addition, it does not require a complete specification of the software but only the properties relevant for the targeted liability rules.

3. The third level is the implementation of a log infrastructure or the enhancement of existing logging facilities to ensure that all the information required to establish liabilities will be available if a claim is raised.

4. The fourth level is the implementation of a log analyser to assist human experts in the otherwise tedious and error-prone log inspection task.

5. A fifth level is the verification of the correctness of the log analyser with respect to the formal definition of liabilities (considering the correspondence between log files and abstract traces).

Each level contributes to reducing further the uncertainties with respect to liabilities and the parties can decide to choose the level commensurate with the risks involved with potential failures of the system. The overall approach followed in Lise has been applied to a representative case study: an electronic signature application on a mobile phone [16] , [12] .