Open-Source Code Risk Found Before a $38M Acquisition Closed

The situation

A mid-size manufacturing group was preparing to acquire a software company based in Owen Sound that built analytics tools for industrial equipment. The deal was valued at roughly $38 million, most of it tied to the target's proprietary software platform rather than its physical assets. The acquirer's deal team was small: Tharshini, the group's accountant and de facto head of corporate development, and Zainab, an independent board member who sat on the acquisition committee and worked full-time as an air traffic controller. Neither had run a software acquisition before, and both were candid about that from the first call.

The target's founder, Bilal, had built the platform over roughly a decade. The product itself was strong — the acquirer's operating team had already validated the technology and the customer contracts. What remained was due diligence: confirming that the acquirer would actually own, cleanly, what it was paying for. For a software-heavy target, that meant intellectual property due diligence — a structured review of how the company's code, patents, trademarks and data rights were documented, licensed and protected, done before the purchase agreement was signed.

Tharshini's instruction on the first call was specific. She did not want a review that simply produced a clean opinion to make the deal easier to approve. She wanted an honest one, even if it slowed things down or affected the price. That instruction shaped how the engagement was scoped from the outset.

What the review found

Our team began with a software composition analysis — a scan of the target's codebase that identifies every third-party and open-source component embedded in it, along with the license each one carries. Almost every modern software product is built partly on open-source code: free, publicly available components that save development time. The legal question is never whether open-source code was used. It almost always is. The question is which licenses govern it, because open-source licenses are not interchangeable.

Some open-source licenses are permissive — they allow the code to be used, modified and distributed inside a proprietary product with few obligations beyond attribution. Others are copyleft licenses, most notably licenses in the GPL family, which carry a very different consequence: if a company distributes software that incorporates GPL-licensed code in certain ways, it can be required to release the source code of the surrounding proprietary software under that same open license. Lawyers sometimes describe this as the license being viral — it can attach to code written around it, not just the component itself.

The scan on the target's platform found several dozen open-source components in active use. Most were permissively licensed and posed no real risk. But three components, all involved in a data-processing module added roughly two years earlier by a contractor no longer with the company, carried GPL-family licenses. The way they were integrated created a genuine argument that the surrounding proprietary code could be subject to the same disclosure obligation if the product were distributed in its current form.

This was not a reason to walk away from the deal, and our team said so plainly. The exposure was real but bounded: it touched one module, not the core platform, and it was fixable. The mistake would have been either ignoring it to keep the deal moving, or overstating it to the point of scaring the acquirer off a fundamentally sound business. Tharshini's instruction to be honest, not alarmist, was the right one — the review's job was to size the risk accurately, not to editorialize it.

What we did

1. Mapped every open-source component against its license. The scan results were organized into a plain-language risk table — permissive, weak copyleft, and strong copyleft — so Tharshini and Zainab could see at a glance which components needed attention and which did not, without needing to read license text themselves.
2. Engaged directly with the target's engineering lead. With Bilal's cooperation, we confirmed how the flagged components were actually integrated into the product, and whether the target's own code was linked to them in a way that would trigger disclosure obligations under the GPL-family licenses, or whether the integration was more separable than it first appeared.
3. Scoped a remediation plan before closing. The three components could be replaced with permissively licensed alternatives or removed outright with a modest engineering effort. We worked with both sides' technical leads to price that work and put a timeline on it — a matter of weeks, not months.
4. Negotiated a holdback tied to completion. Rather than delaying the deal until remediation was finished, or ignoring the issue in the purchase price, we negotiated a holdback of roughly $650,000 out of the total purchase price, released to the seller once the remediation was verified complete and an independent code review confirmed the flagged components were gone.
5. Strengthened the IP representations and warranties. The purchase agreement was amended to include specific warranties that the seller had disclosed all material open-source components and their licenses, with the holdback serving as the practical backstop if anything material had been missed.
6. Briefed the acquisition committee directly. Because Zainab sat on the committee approving the deal and had no technical background in software licensing, we prepared a short written summary in plain language explaining what copyleft licensing risk actually meant in practice, so the committee's approval was informed rather than a formality.

The outcome

The deal closed at the agreed price of roughly $38 million, with the $650,000 holdback structured as planned. The remediation work took about five weeks — the three GPL-licensed components were replaced with permissively licensed equivalents, and an independent review confirmed no other copyleft-licensed code remained embedded in a way that created disclosure risk. The holdback was released to the seller in full once that confirmation came through, on the timeline both sides had agreed to.

Bilal's team stayed on through the transition, and the acquirer's operating group later told Tharshini that dealing with the open-source issue before closing, rather than discovering it afterward as a buyer, had made the whole process considerably less stressful than it could have been. Because the issue was caught, quantified and fixed on a known schedule, it never became a source of dispute or a reason to revisit the price after the fact.

The broader lesson for the acquirer's deal team was about what due diligence is actually for. It is not a formality on the way to a deal that was always going to happen. Done properly, it either confirms that a deal is safe to do at the agreed price, or it identifies a specific, priceable problem early enough to solve it — before it becomes the acquirer's problem alone.

What you can learn from this