Nobody reads the licence of a package they install in four minutes. It becomes interesting at exactly one moment — when an investor, an acquirer or an enterprise customer asks for a list, and something on it obliges you to hand over source you consider yours.
This is a commercial risk that behaves unlike a security risk. A vulnerability is urgent and then fixed. A licence obligation is dormant for years and then decides a deal. It also cannot be patched: by the time it surfaces, the code is in your product and has been shipped.
What follows is an engineer's map, not legal advice. The line between "this licence applies to us" and "it does not" turns on facts about how you distribute your software, and that is a question for a lawyer. What you can do without one is know what you have.
The three families
Permissive — MIT, BSD, Apache 2.0, ISC
Do what you like, including using it in closed commercial software. The obligations are small: keep the copyright notice and licence text with the distribution. Apache 2.0 adds an explicit patent grant, which is why legal teams tend to prefer it over MIT. It also asks you to mark any file you changed, and to pass on the NOTICE file if the project ships one.
This is the great majority of what you depend on, and it is why the topic feels theoretical most of the time.
Weak copyleft — LGPL, MPL 2.0, EPL
The obligation attaches to the component, not to your product. Modify the library and you publish those modifications; your own code around it stays yours. MPL draws the line at the file: any file containing MPL code stays under MPL — including one of yours, if you pasted it in there. Files you wrote from scratch are untouched.
The practical trap is LGPL and static linking. Dynamic linking is the case the licence was written for and is generally comfortable: the user can swap the library out for themselves. Static linking is permitted too, but on a condition most teams never notice — you have to give recipients enough, either object files or your source, to relink your binary against a modified version of the library. On a product you ship as one opaque binary that is a real obligation, which is why this matters far more for desktop, mobile and Go than for a server you never hand to anyone.
Strong copyleft — GPL, AGPL
This is the family that can reach your own code. If your product is a derivative work of GPL code and you distribute it, you must offer the complete corresponding source of the whole under the same terms. For a proprietary product that is not an option, which makes it a removal job rather than a compliance job.
AGPL deserves its own paragraph, because it is the one that catches modern companies. GPL obligations trigger on distribution, and running software on your own server for users to access over a network was long held not to be distribution — the so-called ASP loophole. AGPL closes it: if users interact with your modified version over a network, you must offer them the source. For a SaaS business that is precisely the scenario, so an AGPL dependency deep in a web application is materially different from a GPL one.
Note that this is why projects such as Grafana and Nextcloud chose AGPL. It is not an accident or an oversight on their part; it is the point.
Two qualifications are worth carrying out of that paragraph. The network clause bites on a modified version, so running an unmodified AGPL service is a narrower case than it is usually described as. And whether calling an AGPL library from your own application makes your application a modified version is precisely the derivative-work question a lawyer has to answer against your architecture — it is not settled by reading the licence. Most companies do not litigate it. They write "no AGPL in the product" into the policy and move on, which is a defensible way to spend the risk budget rather than a statement about what the licence means.
Why it surfaces during due diligence, and not before
Nobody audits licences on a normal Tuesday. The trigger is always a transaction.
An acquirer's technical due diligence runs a scan over your repositories, because they are buying the code and inheriting whatever obligations come with it. An enterprise customer's procurement process asks for a bill of materials with licences, because their own compliance depends on yours. An investor asks because their lawyers told them to.
At that point the finding is not "you have a problem to fix". It is "you have a problem, and it is now in a data room, and the clock is running". Remediation at that stage means finding a replacement library, rewriting the integration and re-testing, under time pressure you did not choose. Six months earlier it would have been a fifteen-minute decision to pick a different package.
The parts that are genuinely hard
Transitive licences. You chose forty packages and vetted their licences, if you were diligent. The six hundred those pulled in have licences too, and nobody looked. In practice this is where the surprises live.
Unclear declarations. A meaningful minority of packages state their licence badly or not at all: an empty metadata field, free text no parser recognises, or a LICENSE file that disagrees with the manifest. A tool has two options and only one is honest: record it as undetermined, or guess. A guess does not stay a guess — it is ingested, reported, and eventually relied on in a decision about whether you may ship. This is what NOASSERTION exists for in SPDX, and a tool that never emits it is not more capable, only less careful.
Dual licensing and exceptions. Some projects offer a choice of licences, or a copyleft licence with a linking exception attached. The exception is frequently the whole reason the package is usable commercially, and a scanner that reports only the base licence will alarm you about something that is fine.
Relicensing. A package can change licence between versions. An upgrade you approved for a security fix can quietly change your obligations. This is not hypothetical — Elastic, MongoDB, HashiCorp and Redis have all moved to source-available terms in recent years — and the important detail is that those licences are not open source at all, so a policy written in terms of "permissive or copyleft" has no answer for them.
What to actually do
Decide your policy once, in advance. Most companies land on: permissive is fine, weak copyleft needs a look at how it is linked, strong copyleft needs approval, AGPL is a no for anything in the product. Writing that down converts a judgement call into a lookup.
Check when the dependency is added, not when the deal is signed. This is the entire difference in cost. A licence flagged in a pull request is a different package. The same licence flagged in a data room is a rewrite.
Keep the inventory generated, not maintained. A spreadsheet of licences is wrong within a month. It has to come from the same resolution that produces your actual dependency tree.
Treat unknown as a finding. An undetermined licence is not a pass. It is the item most likely to be a real problem, because nobody has looked at it.
Which open source licences are risky for a commercial product?
The strong copyleft family — GPL and AGPL — is the one that can reach your own code, because a derivative work you distribute must be offered under the same terms with complete corresponding source. Weak copyleft such as LGPL and MPL attaches obligations to the component rather than your product and is usually manageable, though statically linking LGPL code into a binary you ship needs care. Permissive licences such as MIT, BSD, ISC and Apache 2.0 impose little beyond keeping the notice.
What is the difference between GPL and AGPL?
GPL obligations are triggered by distribution, and running modified software on your own server for users to reach over a network has long been held not to count as distributing it. AGPL closes exactly that gap: if users interact with your modified version over a network, you must offer them the source. For a SaaS business this is the normal operating model, so an AGPL dependency in a web application is materially more serious than a GPL one.
Why do licence problems surface during due diligence?
Licence problems surface during due diligence because a transaction is the only routine event that causes anyone to audit licences. An acquirer scans your repositories since they are inheriting the obligations, and an enterprise customer's procurement asks for a bill of materials with licences because their compliance depends on yours. By then the finding is not a task but a problem in a data room with a clock on it — the same issue caught when the dependency was added would have been a fifteen-minute decision to choose a different package.
What should a tool do when a package's licence cannot be determined?
A tool should record an undeterminable licence as undetermined rather than guess at it. A meaningful minority of packages declare their licence badly or not at all, and a guessed licence does not stay a guess: it is ingested, reported and eventually relied on in a decision about whether you may ship. SPDX provides NOASSERTION for exactly this, and a tool that never emits it is not more capable than one that does, only less careful. An unknown licence is also the item most likely to be a real problem, because nobody has looked at it.
Where CodeControl fits
CodeControl resolves the licence of every package in your tree, including the transitive ones nobody chose, and raises a finding where a licence can legally reach your own product. An unrecognised licence is reported as undetermined rather than guessed, and exported as NOASSERTION in the SPDX bill of materials — which is the document the due-diligence request will ask for by name. Because it runs on every push, the check happens when the package is added rather than when the deal is signed.