The situation
Soo-jin ran a dental practice. Min-ji owned several locations of a franchise. Neither was in the software business, but both had put a meaningful share of their personal capital into a private equity-backed buyer group that had spent the better part of a year assembling an acquisition. The target was a Scarborough company that built workflow-automation software for mid-sized logistics operators, and the deal on the table was valued at roughly $65 million.
The fund leading the acquisition had brought in outside counsel for the deal's financial and corporate structure, but the investor group wanted its own independent set of eyes on one piece of the file: the target's intellectual property. Soo-jin and Min-ji had sat on enough advisory calls to understand the basic shape of the deal, but what they were actually paying for, in a software company, was the code. If the code came with strings attached that nobody had priced in, the whole valuation was built on a number that did not hold up.
Treadstone Law was retained to conduct intellectual property due diligence on the target as part of the broader transaction. That work runs in parallel with financial and corporate due diligence, but it asks a narrower question: does the company actually own, cleanly and without encumbrance, the technology the buyer thinks it is paying for.
What the review found
The target's core product had been built over nearly a decade by a small internal engineering team, supplemented at various points by contractors. Like almost every modern software company, it also relied on open-source components: pre-written code libraries, freely available online, that developers use rather than writing the same functionality from scratch. This is completely standard practice. The problem is never that open-source code was used. The problem is what license governs each piece of it, and whether the company using it has honoured that license's terms.
Open-source licenses fall into two broad families. Permissive licenses generally let a company use the code in a commercial product with few conditions beyond attribution. Copyleft licenses are different: some require that if you distribute software built on the licensed code, you make your own source code available on the same terms, or that you grant broad rights to anyone who receives the software. For a company whose entire value is proprietary, uncopied source code, a copyleft obligation buried in the product is not a technicality. It can mean the company does not fully own what it is selling.
A code composition review, run against the target's repositories, flagged a routing and scheduling module, used inside the product's core automation engine, that incorporated a component under a restrictive copyleft license. Nirosha, the target's founder, was candid when asked about it directly: the component had been added years earlier by a contractor who was no longer with the company, nobody had run a formal license audit since, and the company had no record of ever reviewing the obligation. It was not concealment in any deliberate sense. It was the kind of gap that accumulates in a growing codebase when nobody is specifically tasked with tracking it.
The practical exposure was real, though. If the licensing terms applied the way they appeared to on their face, a rights holder could later argue the buyer was obligated to make portions of a proprietary, revenue-generating product available on open terms, or could seek damages for the unlicensed use. Either outcome would undercut the core asset the $65 million purchase price was paying for.
What we did
- Ran a full code composition scan before relying on the target's own disclosures. Sellers rarely misrepresent intellectual property intentionally, but they also rarely have a complete internal audit trail. An independent scan of the actual codebase, rather than a questionnaire answered from memory, is what surfaced the copyleft component in the first place.
- Traced the specific license terms and their actual legal effect on the module in question. Not every copyleft license triggers the same obligations, and the effect depends on how the code is incorporated into the larger product. Our review confirmed the component was linked closely enough into the core engine that the more restrictive reading of the license had a credible basis, which meant the risk had to be treated as real rather than theoretical.
- Went back to the target's founder for a full accounting rather than treating the finding as a closing condition to negotiate around later. Nirosha's team pulled the original commit history and confirmed the scope of the module's use, which let both sides work from the same facts instead of dueling assumptions.
- Scoped a remediation path with the target's engineering team. The module could be rewritten using a permissively licensed alternative, or built in-house, without disrupting the product's function. The work was estimated at a few weeks of engineering time.
- Restructured the purchase agreement around the finding before it went to closing. Rather than closing on the original terms and hoping the remediation happened afterward, the agreement was revised to make completion of the rewrite, and independent confirmation that the resulting code was free of the restrictive component, a condition of closing. A portion of the purchase price, in the low six figures, was held back in escrow until that confirmation was delivered.
- Added specific intellectual property representations and warranties addressing open-source use. Beyond the immediate fix, the agreement was amended to include the target's affirmative promise that its codebase, as delivered at closing, was free of undisclosed copyleft obligations, with a defined process for addressing any that surfaced later.
The outcome
The deal closed roughly a month later than the buyer group had originally targeted. The target's engineering team completed the rewrite of the affected module, an independent scan confirmed the copyleft component was gone, and the escrowed funds were released on schedule once that confirmation was in hand. The purchase price itself was not reduced. The buyer group instead absorbed a short delay and paid for a level of certainty the original timeline had not accounted for.
What the deal avoided is the more important part of the story. Had the acquisition closed on the original schedule without the finding, the buyer group would have owned a company whose flagship product carried an unresolved licensing defect discovered only after the fact, likely during a later financing round, a subsequent sale, or a dispute with a rights holder. At that point, the same fix would have had to happen anyway, but without leverage, without escrow protection, and with the buyer's own capital already fully committed and the seller no longer at the table.
Soo-jin and Min-ji had gone into the transaction assuming intellectual property review was a formality attached to a much larger financial deal. What the review actually did was confirm, before their money moved, that the asset they were buying was the asset they thought they were buying. Nothing about the deal blew up. Nothing had to be renegotiated from scratch. The problem was caught with enough runway to fix it properly, which is the version of this story that rarely makes headlines because nothing dramatic happens after it.
What you can learn from this
- Open-source components in a target company's software are normal and not, by themselves, a red flag. The license governing each component is what determines the risk.
- A code composition scan run independently by the buyer's advisors will often find things a seller's own disclosures miss, not because of dishonesty but because internal audit trails are frequently incomplete.
- Copyleft licenses can create obligations to share proprietary source code or grant broad usage rights, which directly affects the value of a software company's core asset.
- When intellectual property issues surface during diligence, tying remediation and independent verification to a closing condition protects the buyer far better than relying on a promise to fix it after the money changes hands.
- An escrow holdback tied to a specific, defined deliverable gives both sides a workable path forward without forcing a full renegotiation of the purchase price.
This is a mergers & acquisitions problem we handle
Start a file online — flat, published fees, reviewed by a licensed lawyer before a dollar is owed.