Revisiting Key Provisions in Software and Outsourcing Agreements

Key provisions in software license and outsourcing agreements should be revisited and updated in light of the events of 9/11 and changes in privacy laws, intellectual property practices, and the business purposes of information technology projects. Central to this is the use of technology to implement business transformation, that is, the use of software and outsourcing to improve, or transform, a company's business operations.

An example of business transformation could be taken from the use of a manual system to order custom products in the retail industry. Let us assume that the use of manual orders causes in salesmen to miscode forms and that the volume of handwritten paperwork causes manufacturing mistakes at the factory. If the manual system were replaced by software and the software prevented miscoding and its automated order placement prevented factory mistakes, then the number of products that would have to be discarded or returned would be greatly reduced. In this case, the improvement in business operations, at both the retail store and the factory, is included in the software. The business transformation is embodied in the adoption of the new technology.

The topics covered by this article are also important even if business transformation is not the primary purpose of the IT transaction. For such cases, this article provides updated licensing techniques. Among other topics, this article covers: (1) the changes required in confidentiality agreements to accommodate the privacy of personal information; (2) rethinking the purpose of force majeure provisions in light of 9/11; (3) the potential problems of using joint ownership as a solution for intellectual property rights; (4) the impact of statements of work on litigated disputes; (5) having master agreements control over subsequent transactions documents; (6) the advantages of placing confidentiality obligations in a separate agreement; (7) framing a motion for an injunction to require the vendor to provide maintenance during a dispute as a motion to maintain the status quo rather than as a request for an extraordinary affirmative remedy; (8) converting source code escrow to technology escrow (including placing the names of the programmers in escrow); and (9) requiring employee background checks as protection against software sabotage. The article concludes with a discussion of the core factors necessary for successful outsourcing or software licensing agreement.

MODIFYING CONFIDENTIALITY AGREEMENTS TO PROTECT PERSONAL INFORMATION

New privacy law regimes and the business need for a software or outsourcing customer to protect the personally identifiable information (PII) in its possession require changes in standard confidentiality agreements. The PII can belong to the customer's customers, its employees, business partners, and others. In the United States, the new privacy laws include Graham-Leach-Bliley for financial information, the Children's Online Privacy Protection Act for online sales to children, and the Health Insurance Portability Protection Act for personal health information. Elsewhere, new privacy legislation includes the European Directive on the Protection of Individuals with regard to the Processing of Personal Data and on the Free Movement of such Data in EU member states, the Canadian Personal Information Protection and Electronic Documents Act, and Australian Federal Privacy Act.

Standard confidentiality agreements were generally written to protect trade secrets and other proprietary business information and to exclude publicly available information from nondisclosure obligations. These confidentiality agreements need to be revisited because they were not written to cover PII entrusted to a party. A company that is a customer in a software license or outsourcing transaction will want the vendor to keep PII confidential. It will argue that, because it has an obligation to do so, so does the vendor that acts as its agent. The vendor, however, may argue that it has no confidentiality obligation because the PII fits within the exception for public information. This is because personal information such as home addresses is technically available to the public in the county clerk's office and other similar sources. To protect its business interests and to avoid possible liability under privacy regulations, the customer will insist on an exception to the exception to prevent the disclosure of PII.

In some cases, a vendor may have already received the same PII in its possession, and it may have received the consent of the owner, as is available under privacy laws, to disclose that information. This can occur, for example, when the vendor is a large institution that licenses software to this particular customer but provides data processing or outsourcing services to other customers and has the right to disclose the PII for those purposes. As a result, the vendor will require the right to disclose PII that it has independently received, even if the same PII is the incidental possession of the customer, in order to preserve the rights it previously obtained for that information.

COMBINING FORCE MAJEURE AND BUSINESS CONTINUITY PLANS

An issue highlighted by 9/11 is the need to rethink the purpose of force majeure provisions. I suggest that force majeure provisions be combined and coordinated with disaster recovery and business continuation provisions. Disaster recovery and business continuation plans are meant to operate when certain force majeure events occur. The force majeure provision should not operate to relieve the vendor of the obligation to perform. While force majeure events might reduce the obligations of the vendor, they should not eliminate them. Instead, the contract should identify certain foreseeable events and delineate what the vendor's obligations should be (even if reduced) when those events occur. Put another way, the contact should require the vendor do be part of the disaster recovery and business continuation process. In essence, the contract should specify the acts the vendor is to take in the event of particular force majeure events instead of simply excusing vendor performance.

POTENTIAL PROBLEM WITH JOINT OWNERSHIP OF PATENT RIGHTS

One difficult intellectual property issue that arises in software development and outsourcing agreements concerns the ownership of improvements and new inventions, especially those created as a result of joint or collaborative effort of the vendor and customer. A common contractual provision provides that the parties will jointly own the patents that result from jointly developed inventions. The practicalities of patent prosecution can confound the parties' expectations, however. By way of background, recall that a patent has several sections, including the claims. When a patent is enforced or infringed, it is the claims that are enforced or infringed. Utility patent applications are filed with an initial set of claims (as distinguished from provisional applications, which need not include claims), but the claims can be completely changed during the course of the prosecution (provided that the new claims are supported by the specification section of the patent application). In fact, during prosecution, the Patent and Trademark Office (PTO) generally will reject or require changes to the claims as originally filed in order to allow the application to mature to an issued patent. In addition, the party prosecuting the application may introduce new subsets of claims during the two or three years that it typically takes a software or business process patent to issue.

If one party (either the vendor or the customer) controls the prosecution, it is possible for that party, intentionally or not, to over time change the claims in a way that favors it and disfavors the other party. In addition, it is conceivable that the party controlling prosecution could draft the claims more narrowly in a jointly owned application than it would if it were to be the sole owner of the patent precisely because the patent will be jointly owned with another party.

Accordingly, a party interested in preserving benefits of joint patent ownership must take the long view and stay involved during the full period of patent prosecution. This is often a challenge as the two-year, or three-year, or even longer prosecution process may outlast the software development project. This party and its own patent counsel will need to have the right to approve claim changes and other filings with the PTO. Obtaining mutual agreement on all prosecution filings can prove difficult, especially as each party pursues its own agenda. An agreement to joint decision making during the course of prosecution does not mean that the resulting patent will be equally beneficial to each party. Therefore, once a decision to jointly own the patent is made, the parties need to carefully manage the patent process. It needs to be made an important part of long-term contract administration handled by qualified lawyers who must monitor prosecution developments.

LIMITING LICENSE RIGHTS FOR JOINTLY OWNED INTELLECTUAL PROPERTY

A related issue concerns the parties' respective rights to license a jointly owned patent. A party that is the sole owner of a patent probably would not license it to its competitor. However, if the same patent is jointly owned, the other owner might license it to the first party's competitor. This is because the scope of license rights was not addressed when the parties agreed to joint ownership in the contract and because the licensing could not occur until the patent issued several years after the contract was signed, and this is probably several years after the software development project ended. Thus, in addition to ownership, each party needs to focus on, and perhaps limit, the scope of license rights that the other party will have. These license restrictions need to be determined at the beginning of the development agreement even though such license rights will not be exercised until years later.

Joint owners of a copyright also have the right to independently grant non-exclusive licenses. Jointly owned copyright in important software presents the same licensing issues and also should be addressed when the contract is being drafted. It is important to note that copyright authorship is different from patent inventorship; it is possible that an invention relating to the software can be jointly owned, while the copyright in the software will not, or vice versa. As a result, the agreement must treat patents and copyrights separately.

LAWYERS SHOULD DRAFT TECHNICAL SCHEDULES

In complex software licensing and software development projects, as well as outsourcing arrangements, the transaction documents initially will consist of a master agreement and a series of schedules, project plans, and other documents. Later, the parties will enter into various statements of works and amendments to govern new work. Litigations arising from these agreements are often factintensive and involve the definition of the parties' obligations, software functionality, the exact scope of outsource services, and whether performance justified payment and at what price. These issues are governed in many cases by service level schedules, statements of works, and other technical documents. Because of the litigation impact of these documents, there is a danger in having them drafted solely by technical personnel. For this reason, it is important that lawyers draft these documents even though they cover technical subject matter and that the lawyers understand this subject matter or work closely with experts who do.

PROPER RELATIONSHIP BETWEEN MASTER AGREEMENT AND STATEMENTS OF WORK
The transaction documents for complex software and outsourcing agreements typically consist of a master agreement; a set of specialized schedules or sub-agreements, such as service level agreements; price documents; maintenance and support agreements; security schedules; and so forth. Later on, the parties will enter into various statements of work and project plans to implement the next phases of the project. The lawyers for the vendor and customer will have carefully negotiated the master agreement. The real-world danger is that the subsequent documents will undue the balance of rights that were so carefully negotiated there.

This often happens because the vendor tenders its standard form statement of work forms to the customer's technical (as opposed to legal) staff, the technical staff signs the form because it focuses on technical matters, and ignores the legal provisions. The result is that the new form undoes the concessions that the customer's lawyer was able to skillfully negotiate in the master agreement. (Note that it is not always the vendor's form that causes this. Large users also have their own standard forms, and use of these can cause the same result in reverse.)

The way to protect against this is somewhat counterintuitive: The first document, not the last document, should govern. Thus, the master agreement should provide that, in the event of a conflict with subsequent transaction document, the master agreement should control. This is especially important with respect to "master" provisions, such as representations and warranties, indemnities, intellectual property ownership, limitation of liability, and the like. Exceptions may be appropriate for changes in price or adjustments in service levels, but the basic principle is to protect the careful balance of negotiated rights from being undone when lawyers are not involved.

SEPARATE CONFIDENTIALITY AGREEMENTS

Entering into a separate confidentiality agreement instead of including confidentiality and non-disclosure provisions in a master agreement can provide several advantages. First, it can make it easier for the aggrieved party to obtain a judicial remedy for a breach of a confidentiality obligation. A separate agreement can put a simple, focused dispute before the court and reduce the opportunity for the defendant to cloud the wrongful-disclosure issues by introducing potentially irrelevant counterclaims going to an alleged breach of the main agreement that would be more readily introduced if the confidentiality provisions were part of a single contract.

Second, it can take a long time for parties to negotiate the master agreements. In the mean time, they will be exchanging confidential information (as part of the RFP process, for example). The vendor will disclose proprietary technology and the customer will disclose its business plans, including possible deficiencies in its current operations. In many cases, the customer will be negotiating with several potential vendors, in which case it will be necessary to protect the confidentiality of the information disclosed to the semifinalists who are not ultimately selected. Thus, a comprehensive confidentiality agreement entered into before the master agreement is executed can protect the pre-contract disclosures, the disclosures made during the initial phase of the contract beginning after execution, and disclosures made under agreements other than the master agreement, such as project plans and statements of work entered into in future phases of the project. As with the master agreement, the confidentiality agreement should be drafted to prevail over any inconsistent provisions in future statements of work and so forth to preserve the careful balance of rights negotiated by the attorneys at the beginning of the relationship. (This should include the proper treatment of personally identifiable information).

Third, in the RFP process when multiple vendors are bidding for the contract, each vendor runs the risk that the proprietary information disclosed to the customer will be disclosed to its competitors during the selection process. Having this information covered by the confidentiality agreement can protect the vendor. Confidentiality agreements with potential or actual subcontractors also may be needed.

Finally, the customer should have the confidentiality agreement cover evaluations and reports made by the vendor of the customer's operations. As noted, the customer may be entering into the agreement to transform its business operations. It will not want its customers and competitors to know of any weaknesses in its technology or business practices. A customer also may want to keep improvements confidential because the new technology offers a competitive advantage. Improvements in intellectual property should be protected for the same reason. Similarly, a vendor may wish to have reports kept confidential that indicate deficiencies in its technology or outsourcing operations.

PUBLISHED IP AND CONFIDENTIALITY
A related issue regarding confidentiality concerns published intellectual property. Commonly used confidentiality agreements generally cover intellectual property. However, the recipient of another party's intellectual property may take the position that issued patents and other publicly available IP of the disclosing party are either subject to the standard confidentiality exceptions or should be excluded by contract from confidentiality obligations. Foreign patent applications (including foreign counterparts of US applications), and under a relatively recent change to US patent laws, US patent applications (subject to certain exceptions) will be published 18 months after the first filing date. Even though the applications are published in official government patent publications, it can be argued that they are not readily available to the public. Because of this, the party owning the application may wish to require by contract that the recipient not disclose the application or the subject matter thereof. Moreover, in a multiyear contract, both parties may wish to maintain the confidentiality of applications published during the term, especially if the patent rights are jointly owned.

MAINTENANCE DISPUTES

A risk that a customer runs is that the vendor will cut off maintenance and support during the pendency of a payment or other dispute. This can place undue leverage in the hands of the vendor when the payment was withheld because of its failure to meet required performance levels. Courts are often reluctant to grant injunctions when affirmative relief is sought. A solution to this is to have the customer frame the relief sought not as a request for an extraordinary affirmative remedy but as a request that the status quo be maintained while the dispute is being resolved. The customer should anticipate this eventuality and draft the contract, including the maintenance and support obligations, to support this position. The customer can further support this by showing that members of the public at large, who happen to be its customers, will be the ones injured if maintenance is allowed to be suspended. For example, a bank could argue that the public interest would be harmed if ATMs were temporarily withdrawn from service when service withdrawal avoidable. Courts are also reluctant to order parties to work together when human anguish will result. A sizable vendor will be providing support and maintenance services to a number of customers on a one-to-many basis. The customer can argue that no human anguish will result if the vendor is required to provide it with support because little additional work is required to provide remote services to the customer as well as to the vendor's other licensees.

TECHNOLOGY ESCROW

Traditional source code escrow arrangements should be converted to full-bodied technology escrow arrangements. The party seeking the protection of the escrow should take the long view and carefully consider what materials it will need to support the technology that it is acquiring. In addition to placing source code (in fully commented form, or course) in escrow, the escrow should include design documents, protocols, test programs, certain software tools, diagnostics, maintenance and support tools, and similar materials. The customer also may want to use any knowledge base developed to maintain the software placed in escrow. This knowledge base (as well as other deliverables) should be in a technology-neutral format so that it can be used without the vendor's proprietary software.

A problem with source code released from escrow is that it often consists of hundreds of feet of magnetic tape or hundreds of pages of program listings. This can make the protection afforded by escrow somewhat illusory (even assuming that the escrow has been updated with new versions of the code as they are released). As a practical matter, it will be difficult for a party who obtains the source code from escrow to locate the actual lines of code that contain the programming problem that the escrow is meant to address.

A solution to this problem is to go one step beyond the source code and place the names and addresses of the programmers themselves in escrow. The programmers who are best able to fix the code are the ones who wrote it, and they can be made available. Any restriction in the agreement against hiring the programmers must be modified to permit such hiring by the customer in a bankruptcy or similar situation that triggers the release of the source code from escrow. The party obtaining the release from escrow also will need an intellectual property license to make derivative works of the code.

EMPLOYEE BACKGROUND CHECKS

The events of 9/11 also highlight the risk that programmers can sabotage code and introduce errors into the customer's system that cause potentially significant malfunctions. This risk may be increased in outsource agreements when software is written in foreign countries. Similarly, code can be written that allows unauthorized access to a customer's confidential information, and this can include the credit card numbers and other sensitive data belonging to the customer's customers. One way to address this risk is to conduct background checks on the programmers before they are hired or assigned to the customer's project. In addition, the software can be verified by a third party or checked by the customer before it is implemented in a live environment.

TEN KEY FACTORS FOR SUCCESSFUL SOFTWARE AND OUTSOURCING AGREEMENTS
In addition to the updating the contractual provisions discussed above, the following core factors are necessary for successful information technology agreements in today's business environments.


Clear Description of Software's Functionality. A customer needs the scope and description of the functionality of the software and services to be clear, complete, and unambiguous.


Meaningful Acceptance Criteria. Acceptance criteria should be objective, rigorous, and tailored to the needs of the customer. It should be possible to fail the test, quantify the failure, and determine what changes are required to pass the retest.


Meaningful Service Levels. A service level is the level of service that the software will provide. Service levels are often expressed in percentage terms. For example, a contract may require a service level of 100 transactions per second 95 percent of the time. A common mistake is to ignore the other 5 percent of the time. The contract should impose a service level on that remaining percentage; otherwise, the exception could provide a large whole for in performance obligations.


Accurate Metrics. Metrics are the standards and other criteria used to measure the performance of the software and related services. Continuing with the example in number three, the metric would be the criteria used to determine whether the software processes 100 transactions 95 percent of the time.


Meaningful Service-Level Credits. These credits are payments, offsets, or other forms of compensation that a vendor is obligated to pay the customer when it the software fails to meet service levels. These payments are what put teeth in service-level obligations.


Maintenance and Support Levels and Response Times. The safest assumption for the customer to make is that software or outsource services will not work completely. To compensate, the customer must receive complete and timely maintenance and support services with proper escalation provisions to be sure that the appropriately skilled vendor employees resolve the problems.


Avoid Too Much Shared Responsibility. To the extent possible, functions should be the responsibility of either one party or the other. If functions must be shared (for example, first-level support provided by the customer and higher levels of support provided by the vendor), then the demarcation lines should be drawn cleanly. When no one party is responsible, the task often will not get done properly.


Avoid Uncoordinated Amendments. A danger in complex information technology licensing transactions is that, over time, the collection of statements of work, work orders, amendments, and the like introduce inconsistent provisions with the result in extreme cases that it is not clear what the contract requires.


Avoid Paying Too Much Money Upfront. Paying most of the fees at the beginning of the contract reduces the customer's leverage, and in some cases, the key vendor employees will be assigned to other customers.


Termination Rights and Transition Services. A customer will want the right to terminate the agreement both for cause and for convenience. Termination for convenience is an important remedy when the customer downsizes or reduces the scope of the project. A customer will want the right to transition the software or services in house or to another vendor. The vendor will want to be paid for these services. The customer may consider paying a premium for transition services in order to obtain the benefit of an orderly transition.

Sitemap
Ecommerce
Financial
B2B
Free Evaluation

Source:http://articles.corporate.findlaw.com