Prepare and Prevent Common Due Diligence Issues in Health IT Transactions: Intellectual Property Considerations (Part 5 of 6)March 28, 2018
Over the next few months, HGP is publishing a 6-part research series covering a range of due diligence issues that are common to Health IT and Services transactions. The 6 sections cover: Accounting and Tax, Legal, Human Resources, Operations, Intellectual Property, and Technology. In today’s edition, we are covering the Intellectual Property topics.
Software is a core intellectual property asset to most companies operating in the health IT and services market. Therefore, clear and unambiguous title to this asset is an absolute necessity. A company must ensure that any individual or entity that touches the code enters into an invention assignment agreement that gives clear title to that work to the company (employer) and not the individual (employee or contractor). The same dynamic is true for technology that is licensed from another entity or licensed from research or academic institutions. In our experience, patents are not a requirement to secure value in a software asset, however, software companies must ensure that they have freedom to operate and are not infringing on other intellectual property. Because the secret sauce of most companies in the health IT market is their go-to-market strategy, we find that patents tend to protect value as much as they create it. “Knowledge qualifiers,” survival, and indemnity caps are often hotly contested points in the IP provisions of a purchase agreement.
In any transaction, a buyer will closely assess the use of open source code to ensure that the underlying license agreement provides the company with the flexibility to redistribute that code as part of their software application without violating the open source license. The General Public License (GPL) open source license is well understood, however, copyleft standards generally must be followed when dealing with open source software. According to GNU (the entity that governs GPL), “anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it.” This policy is in direct conflict with a copyright, the common standard for software intellectual property protection. When undergoing a transaction, a buyer is likely to perform a deep assessment of the use of open source, potentially using a third-party firm, such as Black Duck.
The use of third-party intellectual property within a proprietary software platform is common, either through white label or third-party licensing agreements. When pursuing a transaction, sellers must clearly articulate proprietary versus non-proprietary licensed intellectual property. From a legal perspective, licensing third-party IP can present issues if the licensing agreement does not clearly delineate who owns what IP when they are co-mingled. Finally, licensing third-party IP may create a dependence on a third party that the licensee cannot control. If the licensor is acquired by or partners with a competitor to the licensee, how might that kind of scenario change the relationship dynamics and competitive landscape? It is encouraged to vet these relationships from all legal and business angles.
Out-licensing, giving another party permission to use your IP, is the inverse of the relationship described above. Excluding customer contracts, white label agreements are the most typical form of out-licensing. While these agreements may be a tremendous revenue opportunity, they may also present challenges. Vendors should be very careful about re-seller and white label relationships that include exclusivity restrictions. A second issue in these agreements often involves a lack of clarity to title of jointly-developed code improvements and modifications. From a business perspective, a white label agreement may mean that a vendor loses the relationship with the end-user, and a diversified base of hundreds of customers may turn into a single, concentrated customer relationship.
Regardless if a company files for its own patents, it should still complete a freedom to operate analysis to ensure that it is not infringing on the intellectual property rights of others.
Client rights involve specific software license agreements with customers that involve joint-intellectual property or product guarantees that are not part of the standard form customer contract. Customization is the simplest form of specific license agreements. When customizing software, a vendor must ensure that any customizations are owned by the company and may be re-used with other customers. Future development guarantees may also present an issue, because to the extent these guarantees are not met, the vendor may be in violation of the customer contract. In some situations, a customer may require a source code escrow. While this sounds reasonable, source code escrows are often impractical.
While software businesses tend to be asset-light, often intellectual property is the #1 asset of the business. To protect this value, companies should comply with all registrations and documentation related to IP, including patents and patent applications, trademarks, trade secrets, contracts, domain names, escrows, and even social media. Ensure that this documentation is held in the company name rather than the individual.
Given the importance and sensitivity around intellectual property related to software businesses, sellers should very closely scrutinize the representations and warranties that they sign up for in the purchase agreement. To prevent indemnity and litigation issues down the line sellers should also make sure that the related disclosures are accurate and complete.