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.

The manufacturing group's board had approved the acquisition in principle on the strength of the product demonstration and the target's customer list, without any board member other than Zainab having a background that would let them meaningfully question the technical underpinnings of what they were buying. That gap is a common one in strategic acquisitions of software companies by buyers whose core business is not software, and it is precisely the gap that intellectual property due diligence is meant to close before the money moves rather than after.

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.

We also checked the company's underlying intellectual property ownership more broadly, beyond the open-source question. The platform's core code had been written entirely by employees under standard invention-assignment clauses in their employment agreements, which meant the company, not any individual developer, owned it outright — a detail worth confirming rather than assuming, since gaps in assignment paperwork are a common and separate source of ownership disputes in founder-led software companies. On that front the target's records were clean, which meant the open-source licensing issue was the one genuine finding in an otherwise well-documented codebase.

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. This let the acquisition committee focus its limited time on the handful of components that actually mattered rather than wading through dozens of low-risk entries.
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. Getting this technical detail right mattered because the legal consequence turns entirely on how the code is combined, not merely on which license appears in a dependency list.
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 — so the acquirer had a concrete, costed plan rather than an open-ended promise that the issue would eventually be handled.
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. This kept the transaction on schedule while giving the acquirer real financial leverage to make sure the fix actually happened.
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. If a further undisclosed licensing problem surfaced after closing, the acquirer would have a clear contractual remedy against the seller rather than having to argue the point from general principles alone, which meant the risk did not simply end when the holdback was eventually released.
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, walking through what could go wrong, how likely it was, and what the holdback did to protect against it, so the committee's approval was informed rather than a formality signed on trust.

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.

For Zainab, the experience changed how she approached her role on the acquisition committee going forward. She later asked that any future technology acquisition include the same kind of plain-language technical briefing as a standing requirement before a vote, rather than something that happened to occur on this particular deal because Tharshini had insisted on it. That small governance change — building the explanation step into the process itself — was arguably as valuable to the manufacturing group as the $650,000 holdback, since it meant the next deal team would not be relying on one board member's instinct for thoroughness to catch what a purely commercial review would miss.

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