Blog

May 30, 2019 -

Don’t Let Your Open Source Software Issues Kill Your M&A Deal

Does your company offer software-based products or services? If so, then you are probably using open source software – whether you know it or not.

Every software business owner should understand that the “free” software they’ve been using comes with strings attached. The licenses it’s under arrive with conditions and potentially serious consequences. If you don’t take stock of what you’re using or take action to meet your obligations under these licenses, it could lead to trouble, such as:

  • Being accused by the owner of the software that you are infringing on their license. These situations happen. They rarely lead to lawsuits in the real world, but you may need to hire a lawyer to help you navigate the encounter through to a workable resolution.
  • Loss of bargaining power in a mergers and acquisitions transaction. If you’re hoping to sell your company someday, it’s imperative that you get your house in order concerning your use of open source software before you go to market. Even if you know you’re using it, you may not have stopped to consider the level of scrutiny this use may receive from a buyer in an acquisition scenario. You can either discover and fix compliance issues on your own beforehand, or you can wait to discover them alongside of your buyer during the due diligence process. I’ll leave it to your imagination to decide which is going to be less stressful (and costly) overall.

Below are four proactive steps you can take to help prevent your open source software license non-compliance issue from becoming a bigger headache down the line.

STEP 1: Take Inventory

Sort through your code base and make a list of all of the open source components you find, along with what licenses they are covered under. If your code base is sufficiently limited in size, you or one of your developers may be able to do this manually, utilizing an Excel spreadsheet or the like to record the results. Some suggested column headings can include:

Screen Shot 2019-05-30 at 12.11.37 PM

  • When to get help: To analyze a larger code base, a manual process may take too long for it to be practical. In this case, you may wish to use one of the various free or commercially available scanning tools to get the job done more quickly. The cost of these tools varies anywhere from free (e.g., FOSSology), to pricey commercial tools offered by reputable vendors with a great deal of experience in open source software compliance matters.

STEP 2: Analyze the Impact

There is no such thing as a “good” or “bad” open source license. However, some fit more comfortably with the needs of your business. The goal during this step should be to ensure that you are not using software under licenses that are inimical to your — and your customers’ and desired business partners’ — commercial objectives and needs.

  • Permissive License Impact. Permissive open source licenses, such as the MIT and BSD license, are relatively easy to comply with and are rarely found to be hostile to the needs of a business and its customers.

•  When to get help: “Easy” compliance obligations can grow unmanageable when you discover that you are using hundreds — if not thousands — of software components licensed under permissive licenses.

  • Copyleft License Impact. Closer scrutiny is warranted if your code base contains software licensed under the GNU General Public License (“GPL”) and similar so-called “copyleft” licenses. A concerning consequence under copyleft licenses (depending on your company’s business objectives) is the way it requires software combined with it to be distributed to others only under the same open source license. In this instance, you would be required to share the entire combined work in source code form with each person who receives a copy of your software, and each recipient must be given the freedom to use, modify, or hand out copies of your code to anyone else. Even to your closest competitors. If you would rather avoid that result, you may be in better shape if you’re providing your software product via a SaaS or PaaS delivery model and you’re certain that your customers/users are not technically receiving a copy of any copyleft-licensed code in the process. But watch for code licensed under the Affero General Public License and similar licenses, which would trigger the obligations under copyleft, even if you only make your software’s functionality available over a network.

•  When to get help: I suggest consulting a lawyer if you discover any copyleft software in your code base and this is your first time dealing with copyleft software license compliance.

STEP 3: Clean up your Game

Take all necessary measures to comply with any affirmative obligations you may have under the licenses that apply to the software you’re using. The two broad categories of obligations most often found under open source licenses include: (1) providing certain (text-based) notices; and (2) providing (or offering to provide) a copy of the software in source code form.

  • When to get help: Each open source license describes your compliance obligations under the license. The language used to describe these obligations is at times vague, confusing, or ambiguous. Call a lawyer if you are having trouble understanding your obligations based on the language in the licenses that you found in your code base. The information you captured during Step 1 will help your lawyer arrive at recommendations. I also suggest calling a lawyer if you’ve been using code covered under the GPL and you have not been complying with your obligations under the license.

STEP 4: Create a Process

Create a written process to manage the onboarding of additional open source components that your developers may desire to add to your code base in the future. A simple yet perfectly adequate program in a small company can be implemented with relative ease. Key elements of your program should include appointing a person or committee to oversee the open source software compliance process in your company; requiring your developers to carefully document each new open source component they add to your code base (seeking pre-approval in certain, but not necessarily all, cases, depending on the license); and providing for the periodic training of all developers and other involved company stakeholders on the process.

  • When to get help: If you’re not sure where to start, a lawyer familiar with open source software licenses should be able to help you design a compliance program.

I’ll end by noting that there is much more to open source software licensing than can be contained in a brief article. However, if you’ve been using open source software and are looking for directions back to the road to compliance, I hope this article helps to get you moving in the right direction.