Open-source software is an increasingly popular software development and distribution model that may spread further in the face of financial constraints in our current economy. With publicly available source code generally offered without charge, it is tempting to look to open source for potentially significant cost savings in this time of need.
But not so fast. While proponents of open source proclaim the benefits of “free code,” it might better be compared to the free puppy offered to a good home. The “puppy” may come at no initial cost, but the ongoing maintenance and undisclosed hidden dangers may create unforeseen hassles in your corporate home. Open source has complex legal restrictions that can create copyright and patent compliance issues and corporate transaction challenges for companies that rely heavily on customized software or that distribute software to partners or customers.
In 2004, the Federal Reserve, FDIC and other federal financial regulatory agencies outlined various strategic and legal risks of using open-source software in the jointly issued guidance notice “Risk Management of Free and Open Source Software.” Public company disclosure statements also demonstrate open-source issues. In their annual reports, many public companies note their use of open source as a risk factor to their businesses, while others go as far as to highlight their lack of open source as a positive factor. Private companies seeking to be acquired have seen their valuation drop, or have seen acquisitions fail altogether, as a result of open-source software discovered during the due diligence process.
To read more on this topic, see: Wall Street Software Scandal: When Does Open Source Become Proprietary Code
and Open Source – Dirty Code, Licenses and Open Source.
Any doubts about the enforceability of open-source software licensing restrictions in practice have been put to rest by recent court decisions. At the same time, the use of open-source software is expanding rapidly, and even commercial software companies often provide open-source licensing options and opportunities.
Open-Source Licenses Are Complex
The Open Source Initiative standards group has approved nearly 70 open-source licenses, each with different terms. These licenses typically fall into one of two categories. The first is described as an attribution-type license, and it generally imposes few obligations beyond requiring that an acknowledgement of the authorship of the software be included in some manner, such as in source code comments and help files.
The second, more common and more demanding type of open-source license is the reciprocal-type license, also known as a “viral” or “copyleft” license. Reciprocal-type open-source license terms can be complex and ambiguous. Generally, any company that uses open source and either modifies or distributes it will need to have a thorough program in place to ensure compliance with the applicable licensing requirements.
Typical features of reciprocal-type licenses include requirements to make source code generally available, prohibitions on using the software for commercial purposes, and?? implied or express patent license grants. These licenses may also lack authorization for the rights to transfer or assign the software.
One example of a reciprocal-type license is the GNU General Public License (GPL). When a company includes GPL-licensed software in its own software, that company must then allow its software to be made available and licensed to all third parties under the same GPL terms. That means competitors can examine–and in some circumstances copy, distribute and develop derivative works of–what could otherwise be proprietary source code.
Know the Risks
Failing to comply with open-source license terms is not merely a breach of contract. Noncompliant use of open-source software also can result in copyright infringement, with increased possibilities for injunctive relief that may force product recalls or expensive alternative software development. It can also lead to enhanced damages and a fixed penalty of up to $150,000 per work infringed, as well as liability for the other party’s attorneys’ fees.
This is not a hypothetical threat. In 2008, the Federal Circuit Court of Appeals issued a decision that upheld the enforceability of open-source licenses. The court ruled that as a result of the defendant’s failure to comply with the notice and attribution requirements in the open-source license for software it had used, the defendant did not have a license and potentially was subject to a preliminary injunction to stop his alleged copyright infringement as well as liability for copyright damages.
Another risk that arises from using open source is that its pedigree often is unknown and always is uncertified. Using open-source software may expose a company to claims that it has infringed the intellectual property rights of others. Open-source licenses provide no warranties or other guarantees that contributors to the source code did not copy the protected work of others, nor do these licenses provide any indemnification to protect against third-party claims for such infringement. No one stands behind the software. Again, the threat is not hypothetical; open-source distributors have been sued for patent infringement, and end users can be liable as well. For example, in October, Red Bend Software sued Google for patent infringement with respect to functionality included in Google’s Chrome browser.
Manage Your Exposure
Companies preparing to be acquired should know the risks of open source upfront, since most buyers will conduct a sophisticated and rigorous evaluation of open-source software use. The representations and warranties in an acquisition agreement generally will require disclosure of open-source use and distribution. Additionally, an acquiring company will want a general understanding of the origin of all of the software used and distributed by the target company. Part of that exercise involves understanding open-source use and which license requirements apply.
Target companies that use “not for commercial use” open-source software for commercial purposes will need to obtain a different and generally more costly commercial license, if such a license is even available. Depending upon the structure of the acquisition, third-party consent for assignment may be needed for continued use of the software. Additionally, if company employees have contributed software in any collaborative open-source projects, their participation may require corollary contribution of company intellectual property or a promise not to assert intellectual property rights to the code or software developed in the project.
Many acquirers require target companies to undergo an expert technical assessment to determine the use and applicable license terms of open-source software, with the commitment to proceed with the acquisition contingent on satisfactory results. Software licensed under a reciprocal-type license may need to be replaced with newly written software, commercially licensed software or perhaps open-source software licensed under an attribution-type license. This replacement or remediation effort can be substantial and may delay closing or, in the worst-case scenario, terminate the transaction.
The Sarbanes-Oxley Act (SOX) requires executives of a public company to certify that the company has procedures in place to provide accurate financial statements and has the related internal controls necessary to produce those statements. Such controls include being able to verify ownership of material assets. Failing to establish procedures to ensure compliance with open-source licenses may indicate a lack of procedures necessary to verify ownership and use of intellectual property.
At a minimum, risk factors associated with compliance with reciprocal-type licenses–which may require that a company make its intellectual property assets publicly available without charge–may need to be disclosed. Penalties for falsely certifying a SOX-required statement are severe, including substantial fines and possible imprisonment.
If you know open source has been used by your IT staff or external developers, get the details on use, modifications and compliance. Your organization should have policies for oversight and control of all software acquisition by employees. If your open-source use is extensive, you also may want to check with a consultant that specializes in open-source compliance.
Finally, once you have a clear understanding of your company’s open-source use and the corresponding licensing requirements, get a jump-start on remediation by thinking through your options with your financial and legal advisers. This is especially important if you are attempting to go public or are involved in merger, acquisition or other investment discussions, so that these matters can be addressed early in the process.
Mark H. Wittow and Jessica C. Pearlman are partners in the Seattle office of the law firm K&L Gates. Wittow focuses on intellectual property and technology transactions and litigation. Pearlman focuses on corporate securities, and mergers and acquisitions.