Open source software (“OSS”) is now ubiquitous, providing community-vetted solutions to common requirements in the software industry. The widespread use of OSS is especially common with start-ups who are driven by the need to develop a minimum viable product as fast as possible in order to quickly enter the market and acquire market feedback.
Risks of unmonitored use of OSS
While most start-ups are quick to use OSS, many are less motivated to establish OSS best practices in acquiring, monitoring and updating the OSS.
The risks associated with such inaction tend to reveal themselves during M&A or capital raising activities. Potential acquirers or investors routinely require code scans to identify OSS present in a code base, and take great interest in a company’s OSS procedures. Red flags immediately arise if OSS code has not been identified prior to the code scan, raising concerns that could potentially result in a lowered valuation or the need for remediation actions to bring the code base into compliance. In a worst-case scenario, unidentified OSS can halt the sale of the company or prevent a funding round. Problems arising from undisclosed OSS have become a familiar scenario encountered by those working on the sale and funding of start-ups.
Why exactly are investors and acquirers concerned with undisclosed OSS? Typically, the risks they want to avoid are related to the following:
- Cyberattacks. If OSS is not properly managed, patched, and/or updated, a company is left vulnerable to cyberattacks and data breaches. Unlike the automatic updates that typically accompany proprietary code, most OSS requires manual updating. The dark web is constantly scanning to find obsolete OSS that may provide access to a seemingly secure system. A good example in this area is the Heartbleed virus that was inadvertently installed in an OpenSSL in 2012, and then sat undiscovered until 2014, when the virus was activated. Although a secure patch was quickly made available to the OpenSSL community, the dark web continues to assemble and sell lists of websites containing obsolete versions of OpenSSL containing the Heartbleed virus.
- The viral effect. OSS licenses, such as the GNU General Public Licenses, can contain provisions requiring any code “derived from” OSS and then “distributed” to be made available to users down the line in source code format under the same license as the original OSS. Many notables in the OSS community have taken the position that, if proprietary code is compiled with the OSS under such a license, then the proprietary source code must also be made available in source code format.
- Copyright infringement suits. If you do not follow the requirements of an OSS license, then arguably, you are working with unlicensed code. The failure to follow OSS license terms has opened the door to lawsuits by those looking to benefit from a potential violation of the OSS license, including so-called OSS copyright trolls.
Start-ups can minimize risks associated with OSS use by adhering to the following common best practices:
- Know your OSS Code
You should always be up to date on your code base, including all OSS. Extra care must be taken when downloading OSS to avoid the inadvertent downloading of compromised code. Unfortunately, there are unscrupulous individuals within the cyber community who will download legitimate OSS code, insert a virus, and then make their code available through a website designed to look like a legitimate site (often referred to as a “mirror site”). Communicate these dangers to your technology team and emphasize the company’s commitment to using only trusted OSS repositories. A best practice is to have each download site approved by the technical group responsible for maintaining the code base.
- Adopt practical OSS policies and procedures
Going a step further, consider adopting a set of policies and procedures to guide the software development team’s use of OSS. For example, create an approval process for the use of all OSS, including a monitoring system to ensure that (a) OSS is properly monitored, patched, and updated to protect against security vulnerabilities; (b) all OSS licenses have been approved by legal; and (c) all compliance obligations (notice, attribution, and the posting of modified code (if required), etc.,) of the OSS license are met. Also, consider adopting a policy that prohibits the modification of OSS since the OSS community will not maintain what will then be considered “orphaned” or “branched” code.
- Scan your code periodically for OSS
Even if you have strict internal rules, OSS has a way of integrating itself into code bases. Do not assume you are the exception. Make it a practice to scan your code base periodically, or at minimum, prior to the proposed sale of the company or a funding round.
- Know you OSS Resources
Identify internal and external technical, business, and legal resources who are able to answer OSS related questions quickly and within the context of the company’s business objectives. Having these resources lined up can prove valuable during due diligence. Potential acquirers and investors are put at ease when they observe that a strong OSS program is in place.
There are many benefits to using OSS, most notably quick access to vetted solutions that can shorten a start-up’s time to market. Knowing the potential risks associated with OSS can help a start-up develop best practices to minimize such risks and establish confidence with potential acquirers and investors.
Frank Fletcher is a Partner with Outside GC LLC’s California-based team. He has over 20 years of in-house experience in software, digital media, outsourcing, SaaS software, open source, on-line privacy, and litigation management, as well as extensive experience in Asia and Europe. His LinkedIn profile is available at: www.linkedin.com/in/frankfletcherprofile. Frank can be reached at firstname.lastname@example.org.