Daniel C. Glazer
Arianne de Govia
In today’s technology-rich environment, in-house corporate counsel must necessarily handle a range of agreements that implicate intellectual property issues. Here are five key IP considerations to be aware of when retaining a contractor to develop software for your company.
1. Get Ownership Right
Companies can benefit from owning the IP rights in developed software; IP owners can use, commercialize, and modify the software free of the scope restrictions and termination risks often associated with license agreements. However, developers may have legitimate reasons to retain IP ownership; for example, they have invested knowledge capital in the project and may be able to reuse code or build on it for other client projects. Before insisting that IP ownership is a “must,” consider whether the software will be competitively sensitive (i.e., will it matter if the developer creates something similar for others?) and whether your company is likely to license it to others or otherwise commercialize it. If not, factors such as vendor bargaining power, cost savings, or even earning developer goodwill may be sufficient reason to allow a developer to retain IP ownership and grant a broad perpetual license to your company.
Beware of joint ownership: Jointly owning software IP with the developer can seem like an efficient way to sidestep difficult negotiations. Unfortunately, parties rarely consider the full implications of this choice. Joint ownership rules vary, not only by type of IP (e.g., patents, copyrights, or trade secrets), but by country. For example, under U.S. law each joint copyright owner may commercialize a copyrighted work without the other joint owners’ consent, but must account for licensing royalties received and may not destroy the value of the work. This is different from English copyright law (under which joint copyright owners cannot exploit their rights without the other joint owners’ consent), as well as U.S. patent law (under which joint owners have no duty to account to each other for licensing royalties). Parties can modify these default rules by contract, but when the agreement states only that the parties are “joint owners,” these restrictions and obligations may be unexpected.
Clarify the handling of residuals: If your developer requires the ability to reuse knowledge acquired while handling your project, it may insist the agreement include a “residuals” clause permitting the developer to freely use ideas, know-how, and techniques that its personnel retain in their unaided memory. These clauses present two important questions: should the developer’s rights in residuals be an exception to the agreement’s confidentiality restrictions, and should these rights constitute a de facto license under your company’s IP rights? There are no “right” answers, but to avoid unintended consequences the parties should ensure they address the topic with specificity.
2. Get Specific on Potential Transfers of Rights
Divested entity provisions mean smoother transitions: If your company is obtaining an enterprise-wide license covering its affiliates, including a “divested entity” provision in the agreement will save time and increase value if an affiliate is later sold to an acquirer. These provisions grant licensees the right to use the developed software on behalf of divested affiliates, or allow those former affiliates to continue using the software after the divestiture. Licensees often also insist that the developer be obligated to enter negotiations for a new license agreement with any divested affiliate.
Do not remain silent on sublicensing, transferability, or exclusivity: If a software license agreement is silent on the licensee’s ability to grant sublicenses or transfer its rights, a non-exclusive licensee generally may not engage in either activity without the licensor’s consent. Some courts have extended these rules to exclusive technology licenses. In contrast, a technology licensor typically may transfer its rights without the licensee’s consent. Further, a license agreement that does not state whether it is exclusive or non-exclusive likely will be found to be non-exclusive. Of course, the best practice is to ensure the agreement addresses all these topics in a manner reflecting the parties’ specific intent.
Watch for unexpected restrictions on transfer: A merger transaction in which the target company does not survive the transaction may constitute a breach of non-assignment provisions in the target’s agreements for in-licensed IP and software. In part to avoid these restrictions, divestitures often are structured as reverse triangular mergers (RTMs), whereby the target company survives the merger as the buyer’s subsidiary. However, a recent court decision has made it less certain that an RTM will not breach non-assignment provisions in the target’s commercial contracts. In Meso Scale v. Roche (2011), the Delaware Chancery Court left open the possibility that Roche Holding Ltd.’s RTM acquisition of BioVeris Corp. breached a non-assignment clause in one of BioVeris’s agreements. To avoid uncertainty, the prudent approach is to clarify with greater specificity in the development agreement what transactions are and are not permissible.
3. Address Bankruptcy
Acknowledge bankruptcy risk: Section 365(n) of the U.S. Bankruptcy Code protects licensees of patents, copyrights, and trade secrets (but not trademarks) from unilateral termination by bankrupt licensors. Software licensees typically can retain their rights as long as they continue to pay license fees when due and otherwise comply with the agreement. Including an express acknowledgement in a software license that Section 365(n) applies helps avoid disputes if a bankruptcy occurs. If the developer is a significant bankruptcy risk it may be appropriate to insist on a perpetual, irrevocable license to the software.
Get a present license to escrowed source code: Bankruptcy can trigger the release of escrowed source code to a licensee. However, bankruptcy courts may characterize a license contingent on a licensor’s bankruptcy as an unenforceable transfer of assets from the bankruptcy estate. Drafting the source code license as a present grant of rights (i.e., “hereby grants”) helps ensure its effectiveness. The developer-licensor may object that it is not allowing your company to presently use the software, but of course the licensee receives no benefit from the license until the escrow agent releases the code.
Bankruptcy complications can be avoided altogether by expanding the scope of escrow release events to include “pre-bankruptcy” warning signs of financial distress, such as licensor’s failure to timely pay bills, or concerns expressed by independent financial auditors. Further, a prudent licensee will consider making bankruptcy (and other release events) an exception to any restriction on hiring the licensor’s programmers. If a release event occurs, your company may find it difficult to use the source code without assistance from the programmers who know it best.
Subscribe to Corporate Counsel
