Common use of Introduction Clause in Contracts

Introduction. A contract is a binding agreement stipulated between two or more parties, which dictates their rights and their duties, and the penalties each party has to pay in case the contract is not honoured. In the current practice of information technology, contracts are not that different from those legal agreements traditionally enforced in courts of law. Both software and services commit themselves to re- spect some (typically weak, if not “without any expressed or implied warranty”) service level agreement. In the case this is not honoured, the only thing the user can do is to take legal steps against the software vendor or service provider. Since legal disputes may require a lot of time, as well as relevant expenses, such kinds of contracts serve more as an instrument to discourage users, rather than making easier for users to demand their rights. Recent research has then addressed the problem of devising new kinds of contracts, to be exploited for specifying and automatically regulating the interaction among users and service providers. See e.g. [6, 8, 11, 13, 20], to cite a few. A contract subordinates the behaviour promised by a client (e.g. “I will pay for a service X”) to the behaviour promised by a service (e.g. “I will provide you with a service Y”), and vice versa. The crucial problems are then how to formalise the concept of contract, how to understand when a set of contracts gives rise to an agreement among the stipulating parties, and how to actually enforce this agreement in an open, and possibly unreliable, environment. In the Concurrent Constraint Programming (CCP) paradigm [23, 24], concurrent processes commu- nicate through a global constraint store. A process can add a constraint c to the store through the tell c primitive. Dually, the primitive ask c makes a process block until the constraint c is entailed by the store. Very roughly, such primitives may be used to model two basic operations on contracts: a tell c is for publishing the contract c, and an ask c′ is for waiting until one has to fulfill some duty c′. While this may suggest CCP as a good candidate for modelling contract-based interactions, some important features seem to be missing. Consider e.g. a set of parties, each offering her own contract. When some of the contracts at hand give rise to an agreement, all the involved parties accept the contract, and start interacting to accomplish it. A third party (possibly, an “electronic” court of law) may later on join these parties, so to provide the stipulated remedies in the case an infringement to the contract is found. To model this typical contract-based dynamics, we need the ability of making all the parties ▇▇▇▇▇▇▇, ▇▇▇▇▇, ▇▇▇▇▇▇▇▇, ▇▇▇▇▇ (Eds.): Third Interaction and Concurrency Experience (ICE 2010) EPTCS 38, 2010, pp. 67–82, doi:10.4204/EPTCS.38.8 ⃝c ▇. ▇▇▇▇▇▇▇▇▇▇ & ▇. ▇▇▇▇▇▇ This work is licensed under the Creative Commons Attribution License. In this paper we study a variant of [2], an extension of CCP which allows for modelling such kinds of scenarios. Our calculus features two primitives, called fuse and join: the first fuses all the processes agreeing on a given contract, while the second joins a process with those already participating to a contract. Technically, the prefix fusex c probes the constraint store to find whether it entails c; when this happens, the variable x is bound to a fresh session identifier, shared among the parties involved in the contract. Such parties are chosen according to a local minimal fusion policy. The prefix joinx c is similar, yet it looks for an already existing session identifier, rather than creating a fresh one. While our calculus is undogmatic about the underlying constraint system, in the contract-based scenarios presented here we commit ourselves to using PCL formulae [2] as constraints.

Introduction. A contract is a binding agreement stipulated between two or more parties, which dictates their rights and their duties, and the penalties each party has to pay in case the contract is not honoured. In the current practice of information technology, contracts are not that different from those legal agreements traditionally enforced in courts of law. Both software and services commit themselves to re- spect some (typically weak, if not “without any expressed or implied warranty”) service level agreement. In the case this is not honoured, the only thing the user can do is to take legal steps against the software vendor or service provider. Since legal disputes may require a lot of time, as well as relevant expenses, such kinds of contracts serve more as an instrument to discourage users, rather than making easier for users to demand their rights. Recent research has then addressed the problem of devising new kinds of contracts, to be exploited for specifying and automatically regulating the interaction among users and service providers. See e.g. [6, 8, 11, 13, 20], to cite a few. A contract subordinates the behaviour promised by a client (e.g. “I will pay for a service X”) to the behaviour promised by a service (e.g. “I will provide you with a service Y”), and vice versa. The crucial problems are then how to formalise the concept of contract, how to understand when a set of contracts gives rise to an agreement among the stipulating parties, and how to actually enforce this agreement in an open, and possibly unreliable, environment. In the Concurrent Constraint Programming (CCP) paradigm [23, 24], concurrent processes commu- nicate through a global constraint store. A process can add a constraint c to the store through the tell c primitive. Dually, the primitive ask c makes a process block until the constraint c is entailed by the store. Very roughly, such primitives may be used to model two basic operations on contracts: a tell c is for publishing the contract c, and an ask c′ is for waiting until one has to fulfill some duty c′. While this may suggest CCP as a good candidate for modelling contract-based interactions, some important features seem to be missing. Consider e.g. a set of parties, each offering her own contract. When some of the contracts at hand give rise to an agreement, all the involved parties accept the contract, and start interacting to accomplish it. A third party (possibly, an “electronic” court of law) may later on join these parties, so to provide the stipulated remedies in the case an infringement to the contract is found. To model this typical contract-based dynamics, we need the ability of making all the parties ▇▇▇▇▇▇▇ICE 2010 EPTCS ??, ▇▇▇▇▇, ▇▇▇▇▇▇▇▇, ▇▇▇▇▇ (Eds.): Third Interaction and Concurrency Experience (ICE 2010) EPTCS 38, 201020??, pp. 67–821–16, doi:10.4204/EPTCS.38.8 ⃝c ▇. ▇▇▇▇▇▇▇▇▇▇ & ▇. ▇▇▇▇▇▇ This work is licensed under the Creative Commons Attribution License. EPTCS.??.?? In this paper we study a variant of [21], an extension of CCP which allows for modelling such kinds of scenarios. Our calculus features two primitives, called fuse and join: the first fuses all the processes agreeing on a given contract, while the second joins a process with those already participating to a contract. Technically, the prefix fusex c probes the constraint store to find whether it entails c; when this happens, the variable x is bound to a fresh session identifier, shared among the parties involved in the contract. Such parties are chosen according to a local minimal fusion policy. The prefix joinx c is similar, yet it looks for an already existing session identifier, rather than creating a fresh one. While our calculus is undogmatic about the underlying constraint system, in the contract-based scenarios presented here we commit ourselves to using PCL formulae [21] as constraints.