Open-Source Software in Tech Due Diligence: What You Actually Need to Know

Open-source software sits inside almost every modern product - and for good reason. It's fast, flexible, well-tested and saves teams from reinventing the wheel. But during technology due diligence, it's also one of the areas that catches companies off guard.

Most teams assume "open-source = free to use." Unfortunately, that's not how it works.

Every piece of open-source software comes with a licence, and those licences come with rules. In an M&A process, buyers want to know whether those rules affect your product, your codebase, or, in some cases, your valuation.

This is the bit most people aren't aware of.

Why Open-Source Licences Matter (Even if It Feels Legal)

If your product uses open-source software, there will be a licence attached to it. Different licences allow different things. Some are relaxed. Some are… not. And some can require you to open-source parts of your own product if you're not careful.

This is why investors ask questions about it. They want to know whether anything in your codebase could create obligations later.

Two Types of Licences You Need to Know About

Open-source licensing is expansive, but we mostly care about two broad categories: permissive and copyleft.

Permissive Licences

This is the easy group. MIT, Apache 2.0, BSD - these are generally fine. They allow commercial use and modification with very few restrictions. From a tech DD perspective, these rarely cause concern, although you should still know where they are in your stack.

Copyleft Licences

This is where the risk tends to sit. Copyleft licences require that derivative works remain open-source. Two specific licences matter most:

GPL - a strong copyleft licence. Depending on how you use it, you may be required to release your own code under GPL.

AGPL - similar, but even stricter. It closes the SaaS loophole in GPL and can apply even if you never 'distribute' software to customers.

Neither is bad, but they need to be used intentionally. Accidentally introducing GPL/AGPL into a core part of your product can create legal, commercial, and technical headaches.

Why This Comes Up in M&A

Open-source licensing often feels like a legal footnote, but the impact is very much technical. If the wrong licence sits in the wrong part of your codebase, you might need to refactor or restructure. That costs time, and during a transaction, time isn't something you usually have.

Buyers typically want to know what they're walking into. A clean open-source footprint gives them confidence. A messy one creates questions.

How to Get Ahead of It

You don't need a compliance department to sort this out. A few practical steps go a long way.

Start by scanning your codebase using tools like Syft, Snyk, Mend, FOSSA or GitHub's built-in dependency analysis. These will show you exactly what licences you're using. Once you have the list, pay close attention to anything under GPL or AGPL, especially in the core product.

Research the license in more detail - this blog post is just an introduction.

If you find something problematic, fix it before running a process. Removing or replacing a dependency at your own pace is far easier than doing it midway through diligence.

It also helps to keep a simple SBOM (Software Bill of Materials). This doesn't need to be fancy — a spreadsheet is fine.

And finally, add a quick approval step for new dependencies. One person checking a licence before a library enters your codebase saves a lot of pain later.

Further Reading

If you want a clear explanation of the most common open-source licences, this guide is excellent: https://www.mend.io/blog/top-open-source-licenses-explained/

Final Thoughts

Open-source is brilliant - it speeds up development and supports entire engineering teams. But it still requires a little awareness, especially if you're heading into a transaction.

You're not expected to avoid open-source or memorise every licence. You're simply expected to know what you're using and whether any of it could cause an issue.

A bit of preparation goes a long way, and it makes the whole diligence experience far smoother for everyone involved.