ABA Section of Litigation Intellectual Property Litigation Committee Roundtable Discussion Outline

Transcription

1 ABA Section of Litigation Intellectual Property Litigation Committee Roundtable Discussion Outline Litigating IP and IT Contracts -- And Drafting Tips for Avoiding Litigation By Paul R. Gupta Mayer, Brown, Rowe & Maw LLP 1675 Broadway New York, New York I. Introduction We have had significant litigation experience with three generations of technology contracts (which are somewhat related to generations of technology). Each generation s contracts have been more comprehensive and detailed than the prior generation s. Three areas are of the most practical significance in litigating technology contracts: warranties, regulatory requirements and bankruptcy issues. This appears to be true whether the contract is a simple license, a development contact, an outsourcing agreement or any other form of technology transfer. I have included a checklist of some of the other key terms for technology contracts as a sidebar to this article. II. Warranties Software Functionality A technology transfer agreement should describe in detail the functionality of the software. Functional specifications should outline the business operations that are to be performed. If these specifications are determined prior to the signing of the final contract, they should be included as part of the contract. Otherwise, the agreement typically should establish milestones for development goals. The agreement should also call for delivery of documentation. User documentation provides essential operating instructions and identifies the functions of the computer system, while systems documentation provides a computer programmer with the information necessary to modify the computer software (assuming that the user can negotiate modification rights). Documentation is often a neglected step in software development as the developer strives to meet its schedule and stay within its budget. While there is no industry standard for the quality of computer documentation, the technology transfer agreement should explicitly specify the minimum documentation required. Service Level Agreements Service level agreements are critical to a technology transfer relationship because they provide accountability and serve as the basis for measuring the vendor s performance. The NYDB

2 closer the application is to the core of an institution s business processes, the more important the service level agreement becomes. Such agreements should detail the specific quality, availability, performance levels and support services a customer can expect from its service provider. In addition, the agreements should address the factors that directly affect the customer s business, such as expected response times for computer applications, system capacity and interface compatibility. Response time metrics are often developed in contract negotiations. Response time, for example, is the time from when the transaction is entered into the computer to the time when the computer system s response appears on the screen or when the system is ready to accept the next transaction. The minimum threshold in negotiating performance expectations in the service level agreement may be the existing service levels the customer is receiving from its prior technology. In addition, particularly where the vendor is developing new technology, the user should consider involving user groups for establishing metrics. Vendors are typically hesitant to provide warranties regarding response times, because of the effect of external factors such as hardware, software and telecommunications. For these reasons, and to help maintain adequate capacity, the contract should adequately define the equipment to be used by the customer. The contract should specify a system s hardware and software, as well as the number and quality of the telephone lines. Once the equipment is clearly identified, the vendor may commit to certain performance levels based upon use of the specified equipment. The vendor also may be willing to give a terminal response time warranty if the hardware and software configurations are stated with specificity. Customers may seek financial penalties for failure to meet established minimum requirements, or offer bonuses based on performance. Response time terms also protect a user from the effects of a successful vendor s inevitable difficulties in handling growing business. Similar issues arise for the other SLA terms, such as any permitted downtime periods or help desk performance. System Configuration Compatibility between the customer s existing system and the products selected by the vendor is essential to the efficacy of any technology transfer relationship. The agreement should specify the compatibility requirements of the vendor s system with the user s existing system. For example, in an outsourcing deal, the vendor may transfer the customer s existing software and hardware operations to its more powerful operating system, which is used in common by a number of the vendor s clients. The contract should allocate the responsibilities to ensure a proper flow of operations. Another important element that must be included in an agreement is a specification of the system s capacity. A system should have room to grow as the user s needs expand, without having to replace the system or otherwise spend unreasonable amounts of money and time. Software Development Specifications governing the development and creation of new software are often the most critical part of any technology transfer agreement. There are many factors to be addressed NYDB

3 in contracting for software development, including software functionality, implementation schedules, acceptance testing, trial periods and payment schedules. At the outset, the customer s specific needs and requirements, such as data analysis, data processing and output must be specified to ensure both parties clearly understand their duties. Anti-Vaporware Protection Vaporware can be defined as software or another computer product that is promised but never delivered. To protect against losing money or time because of vaporware, the parties should identify where products stand in the development cycle: designed, coded, built out, alpha tested, beta tested or in production. In addition, the agreement should set forth contingency plans if the products are never developed or if they fail to satisfy the stated specifications. Intellectual Property A critical component of any technology transfer agreement is providing for the ownership of intellectual property rights. Often, intellectual property provisions are poorly drafted and, as a result, disputes over intellectual property are highly litigated. The vendor may legitimately need to protect its core intellectual property. However, each party may have rights to cooperatively created intellectual property. The agreement should delineate how the rights to these properties are to be divided. Failure to address these issues in the agreement can lead to unforeseen results, particularly in the work-for-hire area. A technology transfer agreement should address the rights of each party to the intellectual property, as well as whether either party can license jointly created property. The customer will likely want to prohibit or limit the access of its competitors to the intellectual property. In that regard, expertise in IP, IT and anti-trust should be utilized in the drafting of appropriate language. Remedies While the foregoing issues are often tied to warranties, such warranties are typically limited by vendor clauses that limit direct damages and eliminate consequential damages. Most customers at least well-advised customers are more interested in obtaining performance rather than recovering money. Therefore, the remedies should provide incentives for performance, for example, by deferring payments until milestones are met. III. Regulatory Issues Regulatory issues also give rise to litigation issues. A technology acquisition agreement must not only fulfill the needs identified by business users, but also help the customer stay in compliance with ever-changing regulations. If requested, most vendors will agree to provisions that require them to maintain, for example, application software in compliance with at least federal requirements. The customer s request should be informed by a knowledge of the applicable regulations, as well as future regulatory changes. NYDB

4 Cyber-Security Some of the most significant regulatory developments in the IT area involve cybersecurity. It would be prudent to vendors and customers in currently negotiated contracts to allocate responsibilities for cyber-security. Protection of critical infrastructure has received increased attention in Washington, D.C. (and state capitals) since the September 11 terrorist attacks. On October 16, 2002, President Bush issued Executive Order 1331, Critical Infrastructure Protection in the Information Age (the Executive Order). This Executive Order is aimed at protecting critical information infrastructures related to essential systems such as financial services, energy, telecommunications and health care by creating a public-private partnership. Specifically, the Executive Order establishes the President s Critical Infrastructure Protection Board (PCIPB). The establishment of the PCIPB potentially sets the stage for subsequent mandatory compliance rules. In addition, Senator Bennett, a member of the Republican HighTech Task Force, has expressed his desire to require public companies to regularly disclose the extent of their cybersecurity preparedness. While such legislation has not yet been formally proposed, it is expected in the near term. IT lawyers should closely monitor such developments. GLB and HIPAA There are, of course, other complex regulatory issues that should also be considered by insurance companies, banks and other financial institutions. Notably, the Gramm-Leach-Bliley Act (GLB) requires financial institutions to protect the confidentiality of nonpublic personal information. This year, the focus is on complying with new regulations requiring those institutions to demonstrate that they have put procedures and systems in place that allow them to meet the relevant privacy goals. At the same time, many insurance and health care entities are now attempting to come to grips with new federal requirements governing the privacy and security of health information under the Health Insurance Portability and Accountability Act of 1996 (HIPAA). These new rules will be enforced by the Department of Health and Human Services (and in some cases, the Justice Department). There are various compliance deadlines, some as early as this fall. Entities that are subject to the rules will have difficulty achieving compliance by the deadlines unless they have compliance plans in place and are on their way toward achieving compliance. These regulatory issues should be considered when drafting technology contracts, particularly where the vendor should be expected to help the customer obtain or maintain regulatory compliance. The IT requirements for GLB and HIPAA compliance have been estimated to substantially exceed the costs for Y2K compliance. State Statutes and Regulations In addition to the federal government, many states have imposed requirements on financial institutions, including insurance companies and banks, which should be considered in connection with technology contracts. Some vendors will provide technology solutions or support to help financial institutions meet state requirements. Other vendors, if asked, will at least cooperate with customers in working with third parties for purposes of compliance with NYDB

5 state regulations (including giving third parties access to relevant portions of vendor s specifications and source code, so that state-specific supplemental programs can be created and updated). IV. Bankruptcy Finally, given the current economic facts of life, the agreement should be drafted in anticipation of the risk of licensor insolvency or bankruptcy, particularly for mission-critical software. Proper drafting will enable the licensee to take fullest advantage of specific provisions of the United States Bankruptcy Code designed to protect the rights of intellectual property licensees in the event of a licensor s bankruptcy. Section 365(n) of the Bankruptcy Code The Bankruptcy Code gives a debtor (here, the licensor) the right to exercise its business judgment to determine which of its contracts it will assume (or continue to perform), and which it will reject (or breach with the bankruptcy rules), provided that the contracts are deemed executory. A contract is commonly considered executory if the obligations of both the debtor and the non-debtor party to the contract are so far unperformed that the failure of either to complete the performance would constitute a material breach excusing the performance of the other. A nonexclusive license typically imposes sufficient out-going obligations on each party to be deemed to fit within this definition of executoriness. Section 365(n) of the Bankruptcy Code, which deals with the treatment of intellectual property in the event of a licensor bankruptcy, was enacted in 1988 in response to a decision by the Fourth Circuit Court of Appeals, Lubrizol Enters., Inc. v. Richmond Metal Finishers, Inc. (In re Lubrizol Enters., Inc.), 756 F.2d 1043 (4th Cir. 1985), cert. denied, 475 U.S (1986). In the Lubrizol case, the court ruled that then-current bankruptcy law permitted the debtor/licensor to reject an executory software license, thereby stripping the licensee of its right to use the licensed software and leaving it with nothing but a claim for damages against the debtor (which may have been worth only pennies on the dollar). In response to Lubrizol, Congress enacted Section 365(n), which allows the non-debtor licensee to retain most of its contract rights before and even after the debtor has rejected the license. Thus, prior to assumption or rejection, Section 365(n) allows the licensee to elect, by notice to the debtor, whether it wishes to have the debtor continue to perform its executory obligations or to deliver possession of the intellectual property to the licensee. In addition, Section 365(n) prohibits the debtor from interfering with the licensee s rights as provided in the contract. Upon rejection, the licensee may elect either to (i) treat the license as terminated and file a claim for rejection damages against the debtor s estate or (ii) retain its right to use the intellectual property in exchange for payment of all royalties due over the duration of the license and a waiver of all rights of setoff it may have against the debtor. Section 365(n) also protects the licensee s rights under an agreement supplementary to the license, such as third-party technology escrow agreement. NYDB

6 Drafting Issues From the viewpoint of the licensee, the license agreement should be drafted for the purpose of taking full advantage of the provisions of Section 365(n), with an eye to litigation, as follows: Recite that, for purposes of Section 365(n) of the Bankruptcy Code, all rights and licenses granted under the license are deemed to be intellectual property as defined under Section 101(35A) of the Bankruptcy Code, and that the licensee shall retain and may fully exercise its rights under Section 365(n) in the event of the bankruptcy of licensor. The licensee should have a present right to use and repair the intellectual property and to make derivative works as of the effective date of the license, even if the licensee is not presently in possession of the source code. The Bankruptcy Code will not give effect to any provision in the license granting new rights to a licensee upon the bankruptcy or insolvency of the licensor (a so called ipso facto clause). Include in the agreement sufficient ongoing duties on the part of licensor and licensee that the license will be deemed executory in the event of a bankruptcy filing. Examples of obligations that may render a contract executory as to a licensor include a duty to notify the licensee of patent infringement suits and to defend the licensee against infringement claims; as well as indemnities and warranties. Examples of obligations that may render a contract executory as to a licensee include the duty to account for and pay royalties; to maintain books and records; and to keep information and technology confidential. If feasible, create separate agreements for: (i) trademarks and tradenames, which do not fall within the Bankruptcy code definition of intellectual property ; and (ii) affirmative obligations imposed upon the licensor, such as maintenance and support services, to which Section 365(n) does not authorize the licensee to retain rights. If such services are included in the agreement, separately itemize that portion of the fees payable by the licensee that correspond to these obligations and stipulate that such fees will be reduced or elinated if the licensor ceases to perform the services. Include provisions granting the licensee a security interest in intellectual property, and file a Uniform Commercial Code Financing Statement to perfect a security interest in the intellectual property. Include a statement that failure by the licensee to assert its rights to benefits provided by Section 365(n) will not be deemed a termination of the agreement in the event that it is rejected by the licensor. Create a separate technology escrow agreement (cross-referenced to the license agreement) by which the licensor must provide source code for all intellectual property, including upgrades and modifications, to a third-party escrow agent. In addition to audit provisions and customary requirements concerning storage and maintenance of the software, the escrow agreement should recite that it is an agreement supplementary to the license as provided in Section 365(n) of the Bankruptcy Code, and specify trigger conditions for automatic NYDB

7 release of the source code to the licensee, such as the cessation of business operations or failure to support the licensed property. V. Conclusion We can expect to see more, not less, litigation regarding IP and IT licenses. Careful drafting can avoid some litigation, or at least provide a significant advantage in the event of a dispute. NYDB

8 Software Functionality Written representations Documentation Service Level Agreements Response Time Capacity Interface compatibility System Configuration Compatibility Capacity New Software Upgrade Path Will it Work? Anti-Virus Protection Upon delivery In use Anti-Vaporware Protection Does the product exist? If not, when? Intellectual Property Ownership Upon delivery In use In bankruptcy Regulatory Compliance Federal State Change of Date Warranty New Year Other significant dates Limitation of Liability Penalties Caps IP/IT Agreement Checklist Indemnifications of Service Provider Negligence Willful acts Scope of Use Number of sites Number of users Customers Third parties Conversion Initial phase Exit strategy Modifications Upon customer s request Upon regulator s request Acceptance Testing Standards Payment Access to Data Customer owns data Backing up data Security Customer services Related Networks Estimates and Fees Most favored nation Caps on increases Confidentiality Post-termination Confidentiality agreements Employees Hiring and exit procedures Account managers Priority SLAs Timelines Rights to Software Escrow Modifications Assignment To affiliates To merged entities Disaster Recovery Procedures Scope Periodic testing State of readiness Replacements and upgrades Maintenance Agreements Updates, modifications and new versions Separate contracts Bankruptcy Create present rights Escrow Agreements Termination At customer s option At vendor s option Upon bankruptcy NYDB