7.1. Contracts and their role in software business modes

This study specified and introduced three different generic contracting networks for COTS, tailored, and MOTS business modes of software developing companies. It was established in Chapter 6 that these three business modes have similarities as well as dissimilarities applying the software contracting processes. These divergences are further discussed and analysed subsequently. Summing up the findings: the COTS business relied firmly on multiform licensing practices, whereas the tailored business saw the framework contract as the main contractual tool and interestingly the MOTS business employed combinations of these two previous forms, i.e. both licensing and framework contracts.

The software company can be seen as a nexus of contracts, i.e. the firm is actually formed and defined by a set of several distinct contracts forming a network of contracts. It can be presented in short by the equation where the Firm is a function of all of its valid contracts:

Firm = f (contracts).

Reve (1990) has further refined and depicted the firm with the following “equation”:

Firm = f (internal contracts, external contracts).

Where internal contracts stand for internal (hierarchical) governance, while bilateral governance between companies is defined by the external contracts where the firm forms the centre of contracts. The separation between internal and external contracts is necessary to indicate the different governance modes that require different skills and incentives (ibid). From the present study the different business modes could be defined as follows:

1. The COTS business contracts of sale resemble the Williamson type of market transactions as briefly described in Chapter 2 and also found in Section 6.4.4. This holds up especially with the pure COTS business, though the situation is again different when business is exercised through channels with the reseller or systems integrator partnership.

2. The tailored and MOTS business again is relationship bounded as in both cases, exist or at least there is an aspiration to establish, a relationship as the joint cooperative software development process requires this in alternating density, see Sections 6.4.5 and 6.4.6.

3. The channel and other joint efforts, i.e. alliances, always require a working relationship to be viable in supplying software to the end-users. Even in some cases the MOTS type of business can be pure channel operations compared to the COTS business as the level of the tailoring and customisation part of the software may vary extensively between the applications and even between the end-user’s needs and requirements. Thus many times the line between COTS and MOTS business is fine and vague, as found in the analysis of data.

Inserting the above discussion in the “equation” gives:

Firm = f (internal contracts, transactional contracts, relationship contracts),

where the internal contracts depict the contractual agreements made between the firm and its employees or business units. The external contracts are divided into two, in order to distinguish between the short-lived transactional contracts and the relationship contracts that emphasize the long-standing nature of the firms’ cooperation. In Table 10 the central contractual and contract affecting elements of the three observed and studied central software business modes are arranged. The items can be seen as augmenting the Conceptual software contracting process model with the depicted issues. These items have been unfolding from the case data.

The contracts in the COTS business are meant to be watertight as the sphere of the customers is or at least is aimed to be large. The software supplier does not usually know the customer and vice versa. No longstanding relationship between the supplier and the customer develops in a relationship sense. On the other hand in the tailored software business the customer and the supplier are close to each other and they also strive for a long-standing relationship.

In this mode of business relationship it is more important to have a close working relationship and the contracts need not to be so tight as the partners (have to) depend on each other. However, this type of business is not the moneymaker compared to the possibilities of the COTS business as well as MOTS business, Table 10.

The middle ground between these two business modes is the MOTS business that tries to combine both advantages of the COTS and tailored businesses. Less contracts than in the COTS business, though more contracts than in the tailored business. Customers are better known than in the COTS business, however not so well as in the tailored business.

The interviews brought up the following elements that were found to be important to be understood for a successful contracting process:

1. The line of business must be well understood.

2. The specific subject of the focal contract must be known.

3. Definition of the proprietary technology to be transferred must be done well.

4. Rights of use given to the customer or partner, including the definitions of where to use and how to use, as well as the possible rights to transfer the object of contract must be done clearly.

Other central issues are to understand what the supplier company is transferring, with what price, what are the liabilities (on both side’s), what if there are delays in payments, what happens if the other party is sold, goes bankrupt or some other unexpected and undesirable events occur.

The managers had the opinion that usually it is better to use their own contract templates and try to negotiate from these onward than to take a contract template made by some other party and try to make changes to it. Though from a contracting perspective the party who writes the contract is usually in a worse position if the contract is taken under closer examination e.g. in the case of a dispute. Normally the party who drafts the text is legally supposed to control the formulation given to that text. Therefore that party bears the risk of unclarities and innocent misunderstandings, which the formulation chosen gives rise to.

Next some contracts from the interviewed companies are scrutinized. The analysis is quite short as the focal aim of this paper is to study the contracting process, i.e. how the contracts are negotiated and what their implications for the software development and governance process are, not the contract law with deep and extensive analysis of the contracts and contract texts, i.e. the wording, ref. Chapter 2. The typically observed contractual structure included contracts:

1. to relieve and enable trusty information exchange institutions with the non-disclosure-agreements type of contracts,

2. to lay the foundation for future lasting and viable relationship building and securing with the framework type of contracts,

3. to secure the transfer of the intellectual property rights as well as other rights for the application and related material, i.e. to explicitly agree on the ownership of the software, with the license type of contracts,

4. to define the work on specific software assignment in detail with work-orders, project contracts and assignment contracts and lastly

5. especially in tailored and MOTS business the software companies were disposed to sign maintenance or congruent contracts to bind the customer and to secure constant and predictable future cash-flow.

In the early stages of the relationship the most common and also the central forms of contracts are the NDA contracts which are used in order to free the partners to disclose confidential material during the negotiations and subsequent cooperation, Fig. 34. Typically these contracts are just one or two pages long with few headings. Indicating, first the scope of confidential information that the contract covers, second, financial and other remedies to be paid if the contract is breeched, third, duration of the contract, typically quite short from six months though it could even be to five years or more, the law under which the agreement shall be construed and interpreted in case of difficulties. For the NDA agreements quite standard contract templates are used.

The key elements of the framework contracts have already been discussed in Chapter 6. In this analysis the framework contracts were found to belong to a two stage building process where during the preliminary phase the partners negotiate and agree on the general business terms (main terms, cf. Section 2.1.2) of the future cooperation by drafting and signing the framework contract. After the business terms are agreed and achieved the partners are freer and conscious of proceeding to lighter and more efficient form of cooperation using the project specific contracts, work orders and assignment contracts to describe the software to be developed in specific documentation. The role of the framework contract is equally important in the COTS, tailored and MOTS software business to lay down the base for future cooperation and to ease out future contracting procedures.

The framework contract has two kinds uses and manifestations depending on the business where it is exploited, again the tailored business on the one hand and the COTS and MOTS businesses on the other hand. For the tailored business the framework contract was the primary issue for the software companies to be drafted and signed. To this framework contract different kinds of smaller and task specific agreements were later attached, thus it formed an element where to anchor the future contracts. In the COTS and MOTS business the role of the framework contract was to establish a working relationship between the software producer and the channel operator. In some cases the framework contract was separate from the subsequent license agreement or they were drafted jointly to be included in the same contract form. In some cases these two contract forms were even synonymously used in speech. In Table 11 the character X indicates all the different contract forms found and represented in the analysed transcriptions according to the three business categories.

From Table 11 it can again be seen how the MOTS software business resembles both COTS and tailored modes of operations and how the management of MOTS business has to understand several forms of contracting applicable to that business.

One of the framework contract templates examined was six pages long and it was used in different kinds of software development projects that could later cover software coding, planning and development projects. Project specific descriptions and definitions about the object of the contract are written in an attachment document named as special terms. This general framework contract had 18 basic headings including, among others, the Order. Which further defines the project specific documents to include quality issues, the purpose of the use of the application, its content, scope, used material, time table and environment. Further there are the paragraphs describing the condition of Delivery and acceptance of produced software, Customer"s and supplier"s liabilities and obligations during the development process, Property rights and limitations, i.e. who owns the source code, Time schedule for payments, Warranties that usually are three months starting from the delivery date. Paragraph explicitly stating that Maintenance and support is not included in the contract if not otherwise agreed, and Confidentiality issues are the same as in the NDA contract, but in a shorter text. All the changes must be made in a written format to all of the documents. At the end there is also a paragraph concerning the indemnification issues. The compensation figures are in concordance with the usual percentages as used in the IT2000 contract templates.

The framework contract is followed in the COTS and MOTS business with a license agreement. This contract type is used when one party receives a license from another party to market a product. The agreement requires the party receiving the license to market the product in a specified region and to purchase a minimum quantity of the product, see also (Chernofsky & deNoyelles 1998). The managers represented the opinion that the OEM deal was one of the most demanding contract forms, as the software provider must agree on a broad set of intertwining issues:

• Licensing of the software and technology,

• Support and service arrangements for the future,

• Maintenance arrangements for the delivered software,

• Possible development agreement in order to enhance and update the software with future customer needs,

• Prepare a solid pricing chart. This is especially important where there is a possibility to enlarge the user volume in the customer’s organization and

• A specific content of the agreed product.

For example the channel licensing contract reflects and has an influence on many other internal business processes of the supplier company as well as in the customer’s organization, too. Resources must be dedicated to correspond to the agreed level of support in each contractual case. Agreeing and implementing in practice the support level is demanding, as it has to be the same across the whole chain from the software company to the end-user. The main problem is how to define it in order for it to be adequate in every stage of the chain, e.g. if a two day repair time is required, what the moderate sanctions are, how many resources are required and what are the costs to keep the agreed level. The same holds with the maintenance operations, what is the response time and level of expertise required from the customer and at what price? Usually the software delivered needs before or later some upgrading to keep pace with organization’s or environment’s changing needs. The software may also require more extensive development work. The supplier must be prepared for this kind work too. From the customer’s point of view the partners should agree on these issues during the contract negotiations in order not be locked in with the supplier’s proprietary software in the later stages. On the other hand to agree on these elements is important and advantageous also for the supplier as the supplier is then able to plan their future resource needs more accurate and also the situation is financially clearer.

The license agreement also serves as a planning tool for business operations. For the supplier it is essential to know how committed the channel is to selling the products and services. Usually this component is linked to a common sales and marketing plan that is included in the framework part of the contract. This contract element is e.g. checked more than once a year. Typically once a year a more extensive round and two – three times a year smaller examinations.

In Table 12 some general factors that characterize three end-user license agreements is presented, the company codes are indicated in brackets. From the numbers it can be clearly seen the size differences between the contracts in Finland and the USA.

The above short and exiguous statistics indicate clearly that the contracts in the USA are more extensive in their length than in Finland, also they cover in more detail diverse warranty and liability issues. The US contracts had their own peculiarities, e.g. the restricted rights of the U.S. Government with the reference to the Federal Acquisition Regulations[1] (FAR). Also one of the US contracts exempted itself from high-risk activities as well as from export restrictions from the USA. Otherwise the three license agreements had quite similar general clauses concerning the grants and limitations, intellectual property rights, payments and delivery, support services offered, term and terminations and issues concerning confidentiality. In the case of litigation or other dispute resolutions between the parties, then they were either to be settled in the USA (State of California, US 1), both in the USA and in Finland, depending on the place of operation of the licensee (State of California, US 2), or in Finland (Fin 1). No one offered the possibility to settle disputes using the court of arbitration. See more about this in (Saunders 2001). The report by Jacobsen et al. (2001) has a rich practical description of other practical consultant aspects that must be kept in mind when entering the US software markets. However, the above statistics is only indicative of its nature, as the sample size is only three items. This would be an interesting issue for further research from strict legal perspective to analyse the differences in licence contracts.

The sales channel also affects the terms of the contract as indicated by the managers. The software companies offer quite inexpensive products through the Internet compared to other sales modes used. In this web-case the limitations of liability part of the text is important so that they are limited to the price of the software in all circumstances. In this sense one of the CEOs thought that this type of a license contract is from a juridical point of view a delicate paper. For example in MOTS business the following work order contracts are easier to formulate as the business is based on discussions between partners that usually meet each others face to face, trust has emerged between the partners. However, this COTS type of license contract is different. The companies can be afraid of possible indemnifications from the customers in the USA if they have not appropriately limited their liabilities in the license contracts as otherwise they may face huge claims.

After these basic contracts are drafted and signed there is a set of different types of contract forms to be used for more or less specific needs. For example these contracts include: the work order (project order, delivery contract), assignment, support (service) and distribution contracts.

From the empirical material it was derived that typically the different contractual terms are formed and given solely by the interviewed managers as used in their companies, thus the contents and usage may be quite the same regardless of their differing names. The names of the contracts used were usually inherited from the previous companies where the management has been working in the past or from other sources. The names may also depict the commonplace naming of the contracts whereas the formal written names are fewer. This brought some problems in accurately identifying the designated contractual forms.

The work order is bound to the framework contract as it is usually an attachment for this or in the work order there is an indication of the framework contract in question. In the framework contract the general conditions are stated and with the delivery contract the supplier delimits the order to a specific work. In this document the partners describe the application to be produced and its preliminary specifications are attached to it. Also the obligations of both parties are included in it and are agreed the timetables, resource estimations and contents of partial deliveries. How the work order is bound to the framework with the specifications depends more on the customer’s bureaucracy and their procurement customs. The preliminary supplier’s offer is usually handled and inspected by the customer’s IT-department, but the final order comes from the purchase department that have different and perhaps more strict purchasing rules. In some cases the work-order contract is even drafted by the customer.

The delivery contract specifies exactly the definition phase workload and the supplier will give a broad estimate of the planning and production work. After the specification project is done, then the supplier comes back to inspect and compare these previous estimates and gives new and more accurate estimates concerning the timetable and resource usage. Then starts the actual planning for software development work. The whole development cycle is divided up into smaller phases.

With the support (service) contract the supplier commits to having professionals available to render agreed services with the required level of quality. If the service’s and physical product’s contracts are compared, i.e. in this context the services are exemplified by training, help-desks, small software maintenance works, trouble shooting activities etc. and the actual software application stands for physical product. Based on the National Association of Purchasing Manager’s study Anderson and Narus (1999) indicate that managers find the service contracts more problematic to draft, as they are more ambiguous in their nature. This further reflected the availability of these services as well the assessment of the rendered services where difficult. Another problem was that for the customer it is difficult to predict when they actually need the service. These were, at the same time also the supplier’s problems, how to deliver a proper service within the agreed level and how to have the resources required available.