By Mario Peshev, DevriX
If you are in confirmatory diligence on a software or software-enabled target and the seller’s tech deck says nothing about the third-party code inside the product, you have a gap that will show up later as either a remediation cost or a legal exposure. Open source software composition due diligence is the work that finds that gap before you sign, and it informs a decision a deal partner owns directly: whether the code you are buying can be shipped, resold, and integrated on the terms your thesis assumes. Most sellers cannot answer the license question in a room. That silence is itself evidence, and it belongs in your risk register long before the first 100 days.
I run these reviews inside technology due diligence engagements for buyers, and the pattern is consistent. The engineering team knows the product works. Nobody has a defensible inventory of what it is built on. That is the problem this article is about, and the reason it matters more in software deals now than it did five years ago.
Why the composition of the code is a commercial question, not a technical one
Roughly 70 to 90 percent of a modern application is code the target did not write. It came from open source libraries, package registries, and copied snippets. That is normal, and it is not a red flag by itself. Bain’s annual private equity report has tracked how software has become the largest single sector for buyout activity, and Bain & Company’s Global Private Equity Report makes the point that value now sits in the durability of the asset and in whether the buyer can keep selling the product without a license dispute forcing a rewrite.
The commercial question is narrow and answerable. Can the target ship and monetize this product on the licenses attached to the components it depends on. If a copyleft license like GPL or AGPL sits inside a proprietary product that the target distributes or offers as a hosted service, the obligation attached to that license may require source disclosure or may simply be incompatible with the commercial model. The license terms the target accepted by using the component carry revenue consequences you are underwriting.
I treat this the same way I treat a customer concentration finding. It changes the number, not the narrative. A deal partner does not need to read the code. A deal partner needs to know the size of the obligation, who owns fixing it, and what it costs against plan.
The four things composition diligence actually decides
When I scope this work for a buyer, I am not producing a compliance report to file away. I am answering four decisions that sit on the deal partner’s desk.
Whether the license terms are compatible with the business model
This is the first cut and the most consequential. A component licensed under a permissive license (MIT, Apache 2.0, BSD) carries almost no commercial constraint. A component under a strong copyleft license, embedded and distributed the wrong way, can require the target to release proprietary source or restructure how the product is delivered. The question is not “is there GPL in here.” The question is “is there GPL in here in a way that triggers an obligation given how this product actually reaches customers.”
Whether the components carry known, unpatched vulnerabilities
Old dependencies accumulate published vulnerabilities. A component three major versions behind is not just technical debt. It is a documented, exploitable weakness that a security-conscious enterprise buyer will find in their own vendor review, which affects renewal risk in the customer base you are buying.
Whether the target can maintain what it depends on
Some open source projects are actively maintained by well-resourced communities. Others are one unpaid maintainer who stopped answering issues in 2023. A dependency on an abandoned project is a future rewrite with no external help arriving. That is a forecast cost, and it belongs in the value creation plan with an owner attached.
Whether the target even knows what it is running
The absence of a software bill of materials tells you how the target manages engineering risk generally. A team that cannot produce an inventory of its own dependencies is usually a team that cannot answer other diligence questions cleanly either. I read the missing SBOM as a signal about management maturity, and I price it that way.
What “clean” and “not clean” look like in the data room
Buyers ask me what good looks like, so here is the practical version. A clean answer is a target that hands you a current software bill of materials, a license report generated by a tool rather than by memory, and a short written note on any copyleft components and why they are used in a compliant way. It does not have to be perfect. It has to exist and be traceable to the actual build.
A not-clean answer is a founder telling you “we only use open source, so there is nothing to worry about.” That sentence contains a misunderstanding that costs money. Open source is not license-free. It is licensed under terms that carry obligations, and “we use a lot of it” is the opposite of reassurance when nobody has read the terms.
The gap between those two states is where the fee for this work pays for itself. On a pre-LOI screen I am looking for whether the not-clean state is present at all. In confirmatory diligence I am sizing it.
How I price a composition finding into the deal
A finding that stays in a technical appendix does not change anything. The discipline is translating each finding into one of a few plain outcomes a deal partner can act on. I score findings against the same categories I use across any tech diligence engagement where the point is to price risk in EBITDA rather than to describe engineering activity.
- Remediation cost. Replacing an incompatible or abandoned component has an engineering price. I put a range and a timeline on it, and I name who does the work.
- Legal exposure. Where a copyleft obligation may have been triggered, I flag it for counsel. I do not give the legal opinion. I give the technical facts counsel needs to form one, which is the part sellers usually cannot assemble.
- Deal condition. Some findings become a condition to close or a specific rep and warranty. The deal team controls whether a finding becomes a lever, and the decision sits with them rather than with the engineering team conducting the review.
- Post-close workstream. Findings that do not move price become line items in the first 100 days plan, with an owner and a date, so they do not resurface at the first board meeting as a surprise.
The reason to force each finding into one of these buckets is that a deal partner cannot act on “the codebase has some GPL.” A deal partner can act on “there is one AGPL component in the hosted product, replacing it is roughly six engineer-weeks, and until it is done we hold it as a disclosed condition.” That sentence is the deliverable.
Where this fits against the rest of technical due diligence
Composition review is one workstream inside a broader technical assessment, and it should not be sold or bought as a standalone unless the deal is small. It connects directly to architecture, to security posture, and to the integration plan. A component you must replace is also a component that touches the roadmap you were counting on, which is why I keep it in the same view as what a deal partner actually decides in integration planning.
It also connects to how you judge the AI story a target is telling. Models and pipelines are assembled from open source frameworks and pretrained weights that carry their own licenses and provenance questions, which is a growing part of what AI readiness actually tells you in a deal. A target claiming proprietary AI while running entirely on permissively licensed open models is telling you something about the moat you are paying for.
McKinsey’s private capital research has documented how operational value creation, not multiple expansion, is where returns increasingly come from, and McKinsey’s work on private markets reinforces that the diligence which finds fixable operational cost is diligence that pays. Composition findings are almost always fixable. The failure is not finding them until an enterprise customer’s security team does.
The trigger points where this work earns its fee
Timing decides whether this review changes a decision or just documents one. There are a few moments where it matters, and they are specific.
At the pre-LOI stage, a light-touch screen tells you whether the composition risk is large enough to affect price or structure before you commit. This is a screening question, not a full inventory, and it should cost accordingly. The output I aim for here is binary with a size estimate: is there a material license or maintainability problem, and roughly how big.
In confirmatory diligence, the full review produces the inventory, the license map, and the priced findings. This is where the deal team needs the copyleft question answered with facts counsel can use, and where remediation ranges go into the model.
At the first board meeting after close, the composition findings should already be workstreams with owners. If a copyleft exposure surfaces at the first board meeting, diligence missed it, and the conversation shifts from execution to identifying who should have caught it. My work surfaces these findings early enough that the first board meeting focuses on progress against a known plan.
There is a fourth trigger that buyers underweight. During an add-on, you are merging two codebases, and the combined product may create license obligations neither company had on its own. Distributing a merged product can activate a copyleft term that was dormant when the component sat in an internal tool. This is the same category of surprise that shows up in the revenue decisions deal partners get wrong after an add-on, and it deserves the same attention before you combine anything.
What a good provider hands you, and what a weak one does
Since the search that brought you here is commercial, here is how to judge the provider. A weak provider runs a scanning tool, exports the raw output, and hands you a 200-page PDF of every dependency with its license. The document contains data but no interpretation: the deal partner receives a list they cannot act on, and the team that must decide what it means does not have time to analyze 200 pages during diligence.
A useful provider does the interpretation. They separate the components that matter from the noise, map each material license to how the target’s product actually reaches customers, size the remediation, and hand the deal team the four outcomes I described above. The test is simple: can the deal partner read the summary and know what changes about price, structure, or the 100-day plan. If the answer requires an engineer to translate, the provider did half the job.
This is the same standard I apply to judging any value creation partner before you sign and to judging M&A consulting firms when you are the one underwriting the deal. The provider’s job is to price risk in terms the person underwriting the deal already uses. Everything else is activity.
The disclosure environment is moving in one direction
Software bill of materials expectations are hardening across regulated buyers and government procurement, and enterprise security reviews increasingly ask vendors for one. That matters for a portfolio company’s renewal and new-logo motion, because an SBOM the target cannot produce becomes friction in its own sales cycle. Reporting from S&P Global Market Intelligence and analysis in the Harvard Law School Forum on Corporate Governance both track how software supply chain scrutiny is becoming a standard part of both procurement and governance.
The practical read for a buyer: composition maturity is turning into a revenue-adjacent capability, alongside its compliance function. A target that already produces a clean SBOM has a lower-friction enterprise sales motion. A target that cannot will hit a wall in the deals your growth plan depends on. This creates a value creation angle inside a diligence workstream, and the finding is worth surfacing to the deal partner as upside and as risk.
The operator takeaway
Open source software composition due diligence answers one question a deal partner owns: can you sell and integrate the code you are buying on the terms your thesis assumes. Everything else in the review supports that question. Do not accept a scanner dump, do not accept “it’s all open source so it’s fine,” and do not let a copyleft finding sit in a technical appendix where it will not change a decision. Force every finding into a price effect, a deal condition, a legal flag, or a dated 100-day workstream with an owner.
The work is not expensive relative to what it protects. A single missed copyleft obligation in a distributed product can turn into a rewrite that was never in the model, and a missing SBOM can slow the enterprise sales motion your growth case rests on. Scope it to the deal stage, screen at pre-LOI and size it at confirmatory, and keep it inside the same technical view as architecture, security, and integration rather than treating it as a separate checkbox. This is the same discipline I apply to the technology remediation decision a deal partner actually owns, and to what a deal partner actually buys when they buy post-merger integration.
If you are approaching LOI or already in confirmatory diligence on a software target, the composition review should be scoped now rather than after close. Our private equity technology diligence practice runs this as a focused pre-LOI screen or inside a full five-day technical assessment, priced to the stage you are at. Bring us the target and the timeline, and we will tell you what the code you are buying actually obligates you to.
