Companies are transforming legacy systems, implementing automation and artificial intelligence tools, embedding digital capabilities into their products, shifting to cloud solutions and leveraging technology to better connect to their customers, personnel, and third parties, all at an unprecedented pace. The focus on businesses to get to market faster, reach a broader audience and provide real-time interaction has in turn put pressure on legal and sourcing documents to keep up. The complexity and volume of the numbers of projects (and contracts) can be daunting — especially for companies that have not yet elevated the importance of the technology law function within their organizations.
While “legal” does not want to hold up getting the deal done, it is important for the deal team to take a moment to address the key components of a transformative transaction — with a critical consideration being short- and long-term intellectual property (IP) implications. While the short-term vision may less complex, considering long-term strategies and potential uses requires some ingenuity that could bring new perspectives to the overall commercial arrangement. Wouldn’t it be a relief to be able to say in a few years, “We got the broader right to use that embedded tool or code so that we can use that platform for XYZ commercial use,” or, “Yes, that company that just acquired us can use our platform”? As members of the team that performs a lot of diligence on deals, we (and the deal team) often wish that the IP considerations had garnered a bit more attention in the initial negotiations of some of the key technology contracts.
In our recent webcast, Digital Disruption: Considerations When Implementing Major Technology Transformations, Michael Pillion discussed the importance of focusing on IP rights in technology transformation projects. Set out below are some of the key points to consider:
1. Pre-Existing and Independently Developed IP (Background IP)
- Customer Background IP: Consider what legacy company proprietary IP might be used in the existing system(s) and embedded in the new solution. Is there potential interest in commercializing or selling the new technology in the future, and, if so, has diligence been done (or can it be done) on the legacy IP to assess ownership and commercialization rights?
- Vendor Background IP: Taxonomize which parts of the new solution will embed the vendor’s proprietary IP. Are those parts critical for performance or for the customer’s business?
2. Customer’s License Rights to Vendor Background IP
- A customer’s license to use a vendor’s Background IP typically includes permitted licensees other than the customer, such as its affiliates. Consider if any divested or acquiring entities and any third parties (such as advisors and consultants) should be permitted licensees.
- For highly customized, business-critical systems, consider whether a perpetual and irrevocable license to use the vendor’s embedded Background IP is appropriate. A vendor might suggest that a term-limited license may be more appropriate if use is tied to payment of fees, or if the solution is not bespoke.
- To protect its competitive interests, a vendor may try to restrict license rights for its Background IP to a particular field of use. As noted above, customers should consider potential future uses of the technology, including if any acquirer entity were to operate in a different market. Broader usage rights in the future, especially if competitive, may form part of commercial discussions.
- For new systems, customers may initially anticipate only non-commercial uses and additional uses become visible as the project develops. Consider if the customer, or any pre-defined third parties, should have a right (or option) to commercialize the technology and embedded Background IP or whether, instead, certain pre-defined circumstances should be carved out from certain usage restrictions. These considerations can change the shape of a deal very quickly.
- As to object code, should the customer’s license to the vendor’s Background IP be limited to use of the object code? Will customer modifications to the object code be permitted?
- As to source code, consider whether using escrow arrangements is necessary and, if so, the triggers and parameters for release of the source code, including whether any knowledge transfer by the vendor’s personnel to the customer would be required.
3. Rights to Enhancements and Derivative Works to Background IP
- For customized systems, the parties may need to modify and enhance each other’s Background IP as part of the transformation. If so, ownership and licensing rights should expressly capture such modifications rather than risk such rights arguably being implied (and uncertain) following a customer’s request or a vendor’s approval.
- If Background IP is licensed from third parties, do those usage rights enable the creation of enhancements and derivative works? Is there any know-how to such Background IP or legacy platforms that may need to be sought from third parties?
4. Newly Developed IP
- Both parties will almost certainly create new IP during the project. The vendor’s newly developed IP could include upgrades and enhancements to their solution delivered through implementation or maintenance and support. The customer’s newly developed IP might include customizations of its legacy platform or upgrades and enhancements following release of source code.
- It will be critical to any project to allocate ownership and use rights for short- and long-term use cases.
- Consider the parameters of the vendor’s usage rights to any newly developed IP, and whether any specific uses should be licensed under different terms—e.g., is the vendor obliged to provide ongoing maintenance and support following transformation?
5. Essential Third-Party IP and Other Assets
- As part of planning transformation, consider what third-party IP rights are required to use and operationalize the systems as well as further develop the new solution. Certain terms sought by the customer may need to be flowed down to third-party providers, or obtained upstream from third-party licensors, such as usage in particular fields.
- Other points to consider: Is any advance notice of intended use or customization of the third party’s IP required? Who has the obligation to obtain and pay for required license rights or additional terms? Are the license rights consistent with the customer’s other license rights for components of the solution?
6. Use of Open Source
- Consider if any open-source software is permitted in the solution.
- The potential impact of open use, third-party use, or disclosure may be significant. The parties will want to ensure when appropriate that the code underlying the system’s IP does not become subject to an open-source license that would require (1) disclosure or allow others the right to use, access and/or modify it; or (2) the licensee to grant back any license rights to the licensor or to the public.
7. Other IP Considerations
- Feedback: Customers typically provide feedback to refine and add functionality to the new solution, and the parties should consider whether the vendor will be permitted to use such feedback only to improve that specific solution or to improve its wider offering.
- Documentation and Issues Logs: Consider what proprietary IP is contained in documentation (training manuals, corporate presentations) and issue logs compiled during the project, and ensure that the parties have the appropriate rights to use the information contained in them, including if the project is terminated prior to completion.
- Patent Rights: Consider registering necessary patents and documenting protections of knowledge and outputs from the transformation project. For a business-critical, strategic system, the customer might seek contractual restrictions on the vendor’s ability to build the solution for the customer’s competitors, which would almost certainly affect the price.
- Branding: If the transformation project coincides with any new branding, which is often the case, ensure that appropriate trademark registrations are made with respect to such branding. The vendor may seek a license to use such branding in marketing materials on the transformation project.
8. Rights to Operational and Testing Data
- Data generated by the vendor from the operation of the solution (such as metadata), is often the subject of much discussion. It could be used to the customer’s disadvantage if enhancing services for the customer’s competitors or if the vendor itself becomes a competitor. This data is most relevant in cloud-based solutions and software-as-a-service.
- While a customer could consider restrictions on the vendor’s rights to use operational and testing data, the significant benefit that the vendor gains from wider use could be considered as part of the overall commercial arrangement.
Not all technology transformations require the same level of attention to IP, but many do. Providing the guidance and foresight to work with the business to protect valuable company assets for use today and into the future is a growing—and incredibly important—role of the technology lawyer.