How can something that’s free and openly available cause so much unintended harm to your business? The availability of open source software has contributed as much to lowering the cost of starting a software company as cloud hosting services. So much so that it’s not unusual to find software companies with 40% or more of their code attributable to open source software. But too many startups learn later as they’re in the middle of due diligence from a big acquirer that their practices for using open source software created significant problems – including reducing the acquisition price or, worse, killing the deal.
I previously described a specific example of this, which I was personally involved in. You can read it here: A Tale of Two Acquisitions – Part 1. Let’s dissect the issues a little further so that you can decide what the right uses and processes should be related to open source software at your company.
Background
When most startups think about open source software (OSS) they think about its two key benefits: free and time saving. These are HUGE benefits for startups that are missing two key things: money and time. But the thing that is often ignored are the licensing and related requirements for using OSS.
A 2016 lecture I listened to by representatives from BlackDuck reported there were approximately 2 million open source components in existence. Additionally, 35% of the average application is made up of open source code based on number of files (1/3 of apps tested were comprised of 50% or more open source).
Big companies with mature development practices and large legal departments REALLY care about this because their violation of OSS licensing can lead to huge financial damages or other highly undesirable judgments. Big companies are already a target for lawsuits because of their size and financial coffers. As a result, if a big company approaches yours for acquisition, I can all but guarantee that your use of open source software is on the top 5 list of things they most want to investigate during due diligence.
Disclaimer: I am not a licensed attorney nor an expert in the field of open source software law. The lack of case law and related precedents heightens the confusion and paranoia over what’s appropriate and what’s not. But that will change over time. Also, laws and their interpretation surely vary around the world. You should consult with your trusted attorney for anything related to your use of open source software.
The Open Source Initiative defines open source software as “software that can be freely used, changed, and shared (in modified or unmodified form) by anyone. Open source software is made by many people, and distributed under licenses that comply with the Open Source Definition”. As it relates to potentially screwing up your acquisition exit, the most important words from the definition are “Licenses” and “Open Source Definition”. After finishing this article, come back and click those links to digest them further. I’ll only provide highlights here.
Licenses
Not all open source software licenses are equal in terms of perceived risk and restriction by acquirers. In fact, big software companies will surely have the most knowledge and likely be the most picky about everything described in this article as they conduct acquisitions.
The GNU General Public License (GPL) and its cousin the Lesser GPL (LGPL) are generally regarded as the most restrictive, but especially related to any linking that’s involved (see Embedding section below for more on this). And there’s even a big difference between GPL-v1 and -v3 (v1 is generally regarded as deprecated and should never be used). In fact, a Vice President in the M&A department of a Fortune 100 tech company told me they literally remove all instances of GPL-licensed code after the acquisition, even for SaaS-delivered offerings.
At the other end of the spectrum are the MIT, BSD and Apache Software License, which generally aren’t considered as restrictive. In between these two extremes are moderately restrictive licenses like the Eclipse Public License and Mozilla Public License. Educate yourself and know the nuances of each license type you use, including the difference between the following license categories:
- “Full Copyleft” (reciprocal) – The best example is GPL. Derivatives must be licensed according to the original and source code enhancements must be shared.
- “Limited Copyleft” (hybrid) – Examples include LGPL and Mozilla. Same as full copyleft but the definition of “derivative” is different (such as static versus dynamic linking).
- “Permissive” (attribution) – Examples include MIT, BSD and Apache. Must give proper credit.
In case you’re interested, at the time of this writing, the top market share license types (in order) are supposedly MIT, GPL v2.0 and Apache. Together, they comprise more than 60% of the total open source market.
Modifications
Did you use the OSS code exactly as published or did you need to modify in any way? Functional enhancements are usually considered modifications but what about “tweaks” or modifications that only enable incorporation into your code? The general term used for modifications is “derivative work”. Also realize it might not be easy to determine exactly where your functional enhancement “resides”. In other words, is it a standalone feature that simply interacts with the OSS or is it a direct enhancement of the OSS. Read the license language carefully and get an expert opinion, if needed.
Distribution
Do you distribute your software? Does hosting and delivering your software as a service (SaaS) constitute “distribution”. Possibly not, but the legal distinction between things like source code, binary files, executable form and scripting is important to understand. For example, the popular GPLv3 license includes words like “convey” and “propagate”. What do these mean? You need to know.
An IP attorney recently told me the Affero GPL license states that if object code is available to the public (ie – SaaS delivered), then the source code must also be made available. Yikes.
Also realize that using OSS in the code you sell is typically evaluated differently (more strictly) than using it in internal development and testing tools, at least from an acquirer’s point of view.
Embedding
The way the OSS is incorporated into your source code is pretty important. For example, there are regular debates about things like static versus dynamic linking and which are allowed under particular OSS licenses (helpful article here). Certain types of linking (ie – dynamic) can cause two pieces of OSS that are licensed differently to both take on the least protected attributes of the licenses used. In other words, you can “taint” one piece of OSS by linking it with others.
Documenting
Documenting your code is good and standard software development practice. But as it pertains to documenting use of open source software, many developers either get really lazy or don’t understand how important it is. They should document each instance of OSS, most importantly the name of the open source software used, how it is licensed (be specific) and any info about modifications. As you can tell, the benefit of such in-code documentation is less for the developer’s future reference and more to help with future due diligence requests from an acquirer. Imagine trying to research this required information years later for hundreds of instances of OSS. Nearly impossible!
Company Policy
You should document and explain the company policy for using OSS to your developers. Each new developer you hire should be given the document and should sign that they understand it. Same for development 
contractors. This is mostly to make sure they both adhere to your intended practices but partly to protect yourself in the event of a future lawsuit. Do a search on “open source software policy template” and you’ll find plenty of starting points or click on the graphic to the right to download a basic version I produced (scroll down to the Legal Resources section of the page).
Code Scans
If you’ve been working on your software code for years and are just now realizing the importance of understanding your use of open source software, you might consider doing a code scan to get a fresh baseline. All software companies should consider doing a code scan every year to potentially identify OSS instances that weren’t properly documented. You’ll have a chance to fix issues before it’s too late and it will also give you an opportunity to coach the involved developer(s).
Do a search for “open source code scanning tools” to identify various options. One thing is for sure, the big software company acquirers will certainly commission a code scan as part of acquisition due diligence, and some of them even have their own code scanning utilities. If you report having 35 instances of OSS but their code scan reveals 135, you will be showing the acquirer how poorly you’ve been managing and documenting your use of OSS. Big strike #1.
Tip: Check out an open source project started by Hewlett Packard called Fossology. It includes code scanning and other utilities that could be helpful in this regard. You can also find a GitHub page on Fossology with helpful info.
Remediation
If you ever hear this word in the late stages of an acquisition, you’re going to learn to hate it. As it pertains to OSS, what it means is the acquirer is going to give you a list of code-related issues that need to be resolved. Some items on the list might need to be remediated as a closing condition, which means your acquisition won’t legally close until the issues are sufficiently resolved. Other items might be allowed to remediate post-close. But don’t celebrate too soon because your acquirer will probably not sell/ship your product until these remaining items are remediated. If your acquisition price tag includes what’s called an “earn-out”, then any delay in sales could literally take money out of your pocket and your investors’ pockets.
Acquirer Due Diligence
What might an acquirer ask of you or expect from you during the due diligence phase of an acquisition? Well, if it’s a large and sophisticated acquirer, they will dig deep as mentioned already. To help you prepare now for such an activity, below are some questions provided by BlackDuck as part of their promotional material:
- Can you provide an accurate, real-time inventory of the open source components in use?
- What are the company policies for open source use and processes for selecting, approving and tracking it?
- How do you ensure compliance with open source license obligations, including those associated with code acquired from third parties?
- What processes do you use to identify and remediate known open source security vulnerabilities and to monitor for new vulnerabilities?
- How do you train your developers on the importance of managing open source and your company’s specific policy and processes?
Hopefully this list adds credence to the topics discussed previously in this article.
Summary
I realize this is a lot to absorb but you may as well educate yourself as early as possible because doing so after being approached for acquisition can literally be a disaster. I also don’t want to discourage the use of open source software in any way. In fact, in this era and beyond, that would be virtually impossible and certainly impractical. I hope you’ve been enlightened and I have a feeling your next email is going to be to your attorney.
You also need to know that this particular issue is only one of multiple that could harm, or kill, your future acquisition exit. To better understand the other common issues, read my article titled “Accumulated By-the-Book Debt Will Eventually Come Due“.
Related Reading