In a Trethowans analysis published by technology lawyer Laura Trapnell, companies are warned that engineers using AI coding tools such as GitHub Copilot, Cursor, and ChatGPT may be creating internal software with untracked open-source licence obligations. The uncomfortable point is not that AI-assisted development is inherently unlawful. It is that many organisations have quietly expanded who can create software without expanding the governance that normally follows software creation. The result is a new class of “shadow code” that looks productive on a dashboard and radioactive in due diligence.
The phrase vibe coding has become a shorthand for describing software by intent and letting an AI assistant fill in the implementation. For startups and internal automation teams, it can feel like magic: a calibration engineer writes a script, a finance analyst builds a dashboard, a mechanical engineer produces an optimisation tool, and nobody waits three months for a central IT backlog to move. But the legal and operational problem is that code does not become clean just because it arrived through a chat box.
Trapnell’s argument lands because it reframes AI coding as a supply-chain issue rather than a novelty issue. The risk is not merely that the generated code might be buggy, insecure, or badly architected, though it may be all three. The deeper risk is that organisations are losing track of what they have incorporated, what licences govern it, and what obligations may have attached before anyone with authority has even seen the repository.
Shadow IT used to mean a rogue SaaS subscription, a spreadsheet that became business-critical, or a database running under somebody’s desk. The AI era changes the medium but not the pattern. Employees still reach for tools that let them move faster than official systems allow; only now the output is software, and software carries copyright, security, maintenance, and compliance consequences.
That is why this problem matters beyond legal departments. WindowsForum readers will recognise the pattern from every previous technology wave: macros, Access databases, PowerShell scripts, low-code workflows, unmanaged cloud accounts, and container images pulled from nowhere at 2 a.m. The organisation gets the productivity first and the inventory later, if at all.
AI coding tools accelerate the cycle because they lower the psychological barrier to writing software. A non-developer no longer has to know how to structure a package, handle an API, or write a parser from memory. They can ask for “a Python script that reads this CSV and generates a forecast,” then iterate until something appears to work.
That is not inherently bad. Many of the best internal tools are born close to the work, not in architecture review boards. A test engineer who understands a manufacturing line may specify a better utility than a professional developer who has never seen the line run. But the moment that utility is stored in Git, shared with a colleague, connected to production data, or handed to a customer, it has crossed from personal productivity into software governance.
The tension is familiar: the people closest to the problem can now build the solution, but they are often the least likely to know the rules that attach to building software. Licence compliance is one of those rules. It is invisible when everything works and suddenly central when a merger, customer audit, procurement questionnaire, or open-source enforcement letter arrives.
AI assistants add a new problem on top of the old one. They do not merely install dependencies; they generate code that may resemble, reconstruct, or be influenced by patterns from public repositories. GitHub’s own Copilot documentation acknowledges the possibility of suggestions matching public code and describes organisation-level controls for blocking or referencing matching suggestions. That feature exists because the issue is not imaginary.
The legal boundary remains unsettled in important ways. There is a live debate over whether training on public code creates copyright or licence obligations, and courts have not produced a simple universal rule that companies can paste into a policy. But enterprise compliance does not wait for perfect case law. Sensible companies manage plausible risk long before a judge writes the sentence that confirms it.
This is where Trapnell’s warning is useful but needs careful handling. It is too blunt to say every AI-generated function that resembles GPL code automatically forces an entire proprietary application open. Licence obligations depend on facts: what was copied, how much was copied, whether it is protectable expression, how it was incorporated, whether the software was conveyed, how components interact, and which licence applies. Yet it is equally reckless to conclude that uncertainty means safety.
The professional answer is not panic; it is traceability. If an organisation cannot say where code came from, what packages are included, what licences govern them, and who approved the exceptions, it does not have a licence strategy. It has hope dressed up as velocity.
That design is not a trap. It is the point. The Free Software Foundation’s philosophy was always that software freedom should propagate rather than be absorbed into proprietary products without returning rights to users. Whether one likes that philosophy or not, it is expressed through enforceable licence terms that companies ignore at their peril.
Permissive licences such as MIT, BSD, and Apache 2.0 are comparatively easy for commercial users to live with. They usually require attribution, preservation of notices, and sometimes patent-related conditions, but they do not generally demand that the larger proprietary program be released under the same licence. That is why many corporate policies treat permissive licences as low-friction.
Strong copyleft licences such as GPL and AGPL are different. GPL obligations are commonly triggered by distribution of covered software. The AGPL goes further by addressing network interaction, requiring modified versions that users interact with remotely to offer corresponding source code. The Open Source Initiative’s text of the AGPL reflects that network-service concern directly.
The practical danger in vibe coding is not that a lawyer will parachute into every script and declare catastrophe. The danger is that engineers and domain specialists may paste, generate, or import code without recognising that these categories exist at all. Once code spreads through an organisation, gets refactored into shared tooling, or becomes part of a customer-facing platform, disentangling it becomes much harder than preventing the problem at pull request time.
But “internal only” is one of the least durable labels in enterprise technology. Internal tools become client demos. Client demos become hosted portals. Hosted portals become products. Products become assets in acquisitions. The compliance state that looked harmless during a skunkworks sprint can become material when the code is used as evidence of technical capability.
There is also a cultural hazard. Once staff learn that internal software is exempt from normal review, they will build more of it, connect it to more systems, and share it more widely. By the time legal or security teams discover the estate, “internal” may describe the origin story rather than the current risk.
AGPL complicates the comfort further because its network clause was designed to address software delivered as a service. Whether a specific internal or externally accessed deployment triggers obligations depends on the facts, but the licence category itself should set off a review. Any organisation that treats AGPL as “just another open-source licence” is not paying attention.
The right approach is to distinguish private experimentation from operational software. A one-off script on a personal machine is not the same as a tool in a shared repository that processes customer data, runs in CI, or supports a contractual deliverable. Governance should scale with impact, but it cannot be absent until the day before a deal closes.
This is where traditional software teams already struggle, and non-developer builders are even more exposed. They may understand the domain problem deeply but not the implications of importing a package that imports another package that depends on something abandoned, mislicensed, or restricted. The fact that a package manager resolves the dependency graph does not mean the organisation has accepted the legal graph.
The modern JavaScript ecosystem is the canonical example because npm packages are famously granular, but the issue is not limited to Node. Python, Rust, Go, Java, .NET, container images, and even PowerShell modules all have their own forms of dependency sprawl. The convenience of reuse is also the mechanism by which obligations and vulnerabilities arrive.
For Windows-heavy shops, the risk may hide in automation rather than products. A PowerShell script that calls a Python utility, which depends on a package generated from a Copilot suggestion, which is then bundled into an installer for a customer engagement, is not science fiction. It is a normal week in a busy IT department.
This is why SBOMs matter even when nobody is selling software. An SBOM is not a magic compliance shield, but it gives the organisation a record of components, versions, suppliers, relationships, and timestamps. Without that inventory, every audit begins as archaeology.
Employment contracts can answer who owns code written by employees in the course of their work. They cannot grant rights to third-party code the company did not own in the first place. A proprietary licence file in the root of a repository does not override an MIT notice buried in a dependency, an Apache patent clause, or a GPL component copied into the codebase.
This distinction sounds obvious when stated plainly, yet it is frequently missed because companies conflate authorship, ownership, and permission. A company may own the glue code written by an employee while still being bound by the licence of a library that glue code incorporates. It may own an AI-assisted script while still needing to preserve notices for copied components. It may own a product while being unable to distribute it under the intended commercial terms until a copyleft issue is resolved.
The due-diligence consequences can be disproportionate. Acquirers and enterprise customers do not need to prove a lawsuit is imminent to care about licence contamination. They need only identify uncertainty significant enough to demand remediation, escrow, indemnity, price adjustment, or exclusion of an asset from the deal.
In that sense, licence compliance is not just about avoiding courtroom drama. It is about preserving optionality. Clean software can be sold, shared, hosted, audited, insured, and integrated more easily than software whose origins nobody can explain.
GitHub’s matching-public-code controls are a useful example of where vendors are heading. Copilot can be configured to block or reference suggestions that match public code, and GitHub has described code referencing features that show repositories and licences when matches occur. Those are not substitutes for legal judgement, but they are signals that provenance belongs inside developer workflow rather than in a quarterly training deck.
The Linux kernel community’s recent posture, as reported by technology outlets, points in the same direction: AI assistance may be acceptable, but humans remain accountable for what they submit. That principle should be uncontroversial. A compiler does not take responsibility for a binary, and an AI assistant does not take responsibility for a licence breach.
The same logic applies in corporate environments. If a developer, engineer, or analyst accepts AI-generated code, the organisation needs a way to know that AI was involved, what checks were run, and who reviewed the result. The point is not to stigmatise AI-written code. The point is to stop pretending it has no provenance problem because it arrived fluently.
The mature control is disclosure without drama. A pull request can state that AI assistance was used. A scanner can check for licence and code similarity issues. A reviewer can decide whether the implementation is acceptable. A policy can define which licences require escalation. None of this requires banning AI; it requires treating it like any other powerful tool that can produce unsafe output quickly.
The answer is to move licence guidance into the development workflow. Engineers do not need a jurisprudential seminar on the GPL before writing a helper script. They need clear classifications, automated checks, and a known escalation path when a component falls into a risky category.
A traffic-light model is not perfect, but it is useful. Permissive licences can be green with attribution requirements. Weak copyleft licences such as LGPL and MPL can be amber, requiring architectural care and approval. Strong copyleft and network copyleft licences can be red for proprietary use unless legal review approves a specific plan.
The details matter. Apache 2.0 has patent provisions that may matter in some businesses. LGPL obligations differ depending on linking and modification. MPL is file-scoped and may be manageable in ways GPL is not. SSPL is not approved by the Open Source Initiative as open source and is treated warily by many enterprises. But the existence of nuance is not an argument against simple first-line controls; it is the reason escalation exists.
The better organisations will make the safe path the easy path. A GitHub workflow that runs licence scanning on pull requests is more effective than a policy PDF. A template that asks whether AI was used is more useful than a stern reminder at annual training. A curated internal package registry is safer than telling every domain expert to search the internet and hope.
AI-generated code can contain security flaws, outdated patterns, missing error handling, unsafe deserialisation, weak authentication assumptions, or hard-coded secrets. Public research on AI coding assistants has repeatedly raised concerns about insecure suggestions, and developer forums are full of examples where generated code looks plausible but fails under scrutiny. Licence risk is one face of a broader provenance and review problem.
The overlap becomes obvious when dependencies enter the picture. The same inventory that tells you a package’s licence can also tell you whether the version is vulnerable, abandoned, or pulled from a questionable source. The same pull-request gate that flags GPL can flag known CVEs. The same SBOM that supports customer assurance can support incident response.
This is why the governance should not be owned by legal alone. Legal, security, engineering, procurement, and enterprise architecture all have a stake. If the process is framed only as licence policing, it will be resented. If it is framed as software supply-chain hygiene, it becomes part of the same operational discipline that already governs patching, secrets management, and build integrity.
For Windows administrators, the analogy is patch management. Nobody serious argues that patching is optional because most machines probably will not be exploited tomorrow. The practice exists because unmanaged exposure compounds over time. Licence exposure works similarly, except the exploit may be a customer audit rather than a network scan.
A company accumulates dozens or hundreds of internal repositories. Some were written by software engineers, some by analysts, some by project staff, some by contractors, and some with AI assistance nobody recorded. They include dependencies nobody reviewed, copied snippets nobody remembers, and licences nobody classified. Then a customer, acquirer, insurer, or regulator asks for evidence.
At that moment, the question is no longer “Are we definitely infringing?” It is “Can we prove we are not carrying unacceptable risk?” That is a harder question, and it is expensive to answer after the fact. Retrospective audits are always messier than controls built into creation.
The no-blame audit Trapnell recommends is therefore the right posture. If employees believe an audit is a hunt for culprits, they will hide the very repositories the organisation needs to inspect. If the audit is framed as inventory and remediation, teams are more likely to cooperate.
Most issues will be boring and fixable. A dependency can be replaced. A notice can be restored. A component can be isolated. A risky library can be removed before a tool leaves the company. The earlier the organisation finds the issue, the less dramatic the fix.
That changes the language of governance. Telling a calibration specialist to evaluate derivative-work risk is pointless. Telling them that red-licence code cannot be merged without review is actionable. Telling a data analyst to produce a full legal assessment of transitive dependencies is unrealistic. Giving them a repository template with automated scanning is reasonable.
Education still matters, but it must be practical. A 30-page policy will be ignored by the people most in need of it. A short guide explaining that open source is not “free of conditions,” that AI output must be reviewed, and that certain licences require escalation will do more good.
The same applies to managers. Many business leaders hear “AI coding” and see only reduced backlog. They need to understand that productivity gains are real but not free. If an internal tool starts influencing customer deliverables, safety decisions, financial reporting, or regulated workflows, it deserves software governance even if it began as a prompt.
The best policy is proportionate. A throwaway local script should not face the same process as a customer-facing service. But once code is shared, stored, scheduled, integrated, or relied upon, it enters the governed estate. That line should be clear enough that non-developers can recognise when they have crossed it.
A sensible baseline starts with repository hygiene. Code that matters should live in managed source control, not personal folders, chat histories, or random zip files. Pull requests should be required for shared projects. Automated licence and vulnerability scans should run before merge. AI use should be disclosed in a lightweight way. Dependencies should be pinned, reviewed, and inventoried.
Tooling choices vary. Snyk, FOSSA, Mend, Black Duck, Trivy, ORT, license-checker, GitHub Advanced Security, and other tools can play roles depending on stack and budget. The specific product matters less than the existence of a repeatable workflow that produces evidence.
SBOM generation should become normal for anything that might be shipped, hosted for external users, or included in a contractual deliverable. SPDX and CycloneDX are widely used formats, and the NTIA’s minimum-element work has helped standardise expectations around component identity, versioning, dependency relationships, authorship, and timestamps. An SBOM will not tell a company whether every use is legally safe, but it gives reviewers the map they need.
Finally, there must be an exception process. If engineers know that red means “never,” they may hide exceptions. If red means “stop and get review,” the process can distinguish between unacceptable incorporation, acceptable isolation, commercial licensing, replacement, or redesign. Governance works best when it can say yes safely, not only no loudly.
The phrase vibe coding has become a shorthand for describing software by intent and letting an AI assistant fill in the implementation. For startups and internal automation teams, it can feel like magic: a calibration engineer writes a script, a finance analyst builds a dashboard, a mechanical engineer produces an optimisation tool, and nobody waits three months for a central IT backlog to move. But the legal and operational problem is that code does not become clean just because it arrived through a chat box.
Trapnell’s argument lands because it reframes AI coding as a supply-chain issue rather than a novelty issue. The risk is not merely that the generated code might be buggy, insecure, or badly architected, though it may be all three. The deeper risk is that organisations are losing track of what they have incorporated, what licences govern it, and what obligations may have attached before anyone with authority has even seen the repository.
The New Shadow IT Writes Python Now
Shadow IT used to mean a rogue SaaS subscription, a spreadsheet that became business-critical, or a database running under somebody’s desk. The AI era changes the medium but not the pattern. Employees still reach for tools that let them move faster than official systems allow; only now the output is software, and software carries copyright, security, maintenance, and compliance consequences.That is why this problem matters beyond legal departments. WindowsForum readers will recognise the pattern from every previous technology wave: macros, Access databases, PowerShell scripts, low-code workflows, unmanaged cloud accounts, and container images pulled from nowhere at 2 a.m. The organisation gets the productivity first and the inventory later, if at all.
AI coding tools accelerate the cycle because they lower the psychological barrier to writing software. A non-developer no longer has to know how to structure a package, handle an API, or write a parser from memory. They can ask for “a Python script that reads this CSV and generates a forecast,” then iterate until something appears to work.
That is not inherently bad. Many of the best internal tools are born close to the work, not in architecture review boards. A test engineer who understands a manufacturing line may specify a better utility than a professional developer who has never seen the line run. But the moment that utility is stored in Git, shared with a colleague, connected to production data, or handed to a customer, it has crossed from personal productivity into software governance.
The tension is familiar: the people closest to the problem can now build the solution, but they are often the least likely to know the rules that attach to building software. Licence compliance is one of those rules. It is invisible when everything works and suddenly central when a merger, customer audit, procurement questionnaire, or open-source enforcement letter arrives.
AI Did Not Invent Licence Risk; It Removed the Friction That Kept It Contained
Open-source compliance was already hard before generative AI. Modern applications are mosaics of packages, transitive dependencies, code snippets, container layers, build tools, and test frameworks. The National Telecommunications and Information Administration popularised the idea of a Software Bill of Materials as a nested inventory of components precisely because software supply chains had become too complex to reason about informally.AI assistants add a new problem on top of the old one. They do not merely install dependencies; they generate code that may resemble, reconstruct, or be influenced by patterns from public repositories. GitHub’s own Copilot documentation acknowledges the possibility of suggestions matching public code and describes organisation-level controls for blocking or referencing matching suggestions. That feature exists because the issue is not imaginary.
The legal boundary remains unsettled in important ways. There is a live debate over whether training on public code creates copyright or licence obligations, and courts have not produced a simple universal rule that companies can paste into a policy. But enterprise compliance does not wait for perfect case law. Sensible companies manage plausible risk long before a judge writes the sentence that confirms it.
This is where Trapnell’s warning is useful but needs careful handling. It is too blunt to say every AI-generated function that resembles GPL code automatically forces an entire proprietary application open. Licence obligations depend on facts: what was copied, how much was copied, whether it is protectable expression, how it was incorporated, whether the software was conveyed, how components interact, and which licence applies. Yet it is equally reckless to conclude that uncertainty means safety.
The professional answer is not panic; it is traceability. If an organisation cannot say where code came from, what packages are included, what licences govern them, and who approved the exceptions, it does not have a licence strategy. It has hope dressed up as velocity.
Copyleft Is Not a Virus, but It Is Designed to Travel
Developers often describe the GPL as “viral,” and lawyers often wince at the metaphor. The better description is reciprocal. Copyleft licences use copyright permission as a lever: you may copy, modify, and redistribute the software, but if you distribute covered derivative works, you must preserve the same freedoms for downstream users.That design is not a trap. It is the point. The Free Software Foundation’s philosophy was always that software freedom should propagate rather than be absorbed into proprietary products without returning rights to users. Whether one likes that philosophy or not, it is expressed through enforceable licence terms that companies ignore at their peril.
Permissive licences such as MIT, BSD, and Apache 2.0 are comparatively easy for commercial users to live with. They usually require attribution, preservation of notices, and sometimes patent-related conditions, but they do not generally demand that the larger proprietary program be released under the same licence. That is why many corporate policies treat permissive licences as low-friction.
Strong copyleft licences such as GPL and AGPL are different. GPL obligations are commonly triggered by distribution of covered software. The AGPL goes further by addressing network interaction, requiring modified versions that users interact with remotely to offer corresponding source code. The Open Source Initiative’s text of the AGPL reflects that network-service concern directly.
The practical danger in vibe coding is not that a lawyer will parachute into every script and declare catastrophe. The danger is that engineers and domain specialists may paste, generate, or import code without recognising that these categories exist at all. Once code spreads through an organisation, gets refactored into shared tooling, or becomes part of a customer-facing platform, disentangling it becomes much harder than preventing the problem at pull request time.
“Internal Only” Is a Comfort Blanket, Not a Compliance Model
The standard defence is that internal tools do not matter because GPL source obligations generally arise on distribution. There is truth there. If a company modifies GPL software and uses it only privately, without conveying it outside the organisation, the risk profile is different from shipping that software to customers.But “internal only” is one of the least durable labels in enterprise technology. Internal tools become client demos. Client demos become hosted portals. Hosted portals become products. Products become assets in acquisitions. The compliance state that looked harmless during a skunkworks sprint can become material when the code is used as evidence of technical capability.
There is also a cultural hazard. Once staff learn that internal software is exempt from normal review, they will build more of it, connect it to more systems, and share it more widely. By the time legal or security teams discover the estate, “internal” may describe the origin story rather than the current risk.
AGPL complicates the comfort further because its network clause was designed to address software delivered as a service. Whether a specific internal or externally accessed deployment triggers obligations depends on the facts, but the licence category itself should set off a review. Any organisation that treats AGPL as “just another open-source licence” is not paying attention.
The right approach is to distinguish private experimentation from operational software. A one-off script on a personal machine is not the same as a tool in a shared repository that processes customer data, runs in CI, or supports a contractual deliverable. Governance should scale with impact, but it cannot be absent until the day before a deal closes.
Dependency Trees Are Where Good Intentions Go to Multiply
The article’s most understated point may be the dependency problem. Engineers do not need AI to create licence exposure; they can do it with one package install. A single npm or Python dependency may pull in dozens of transitive packages, each with its own maintainer, version history, vulnerability profile, and licence.This is where traditional software teams already struggle, and non-developer builders are even more exposed. They may understand the domain problem deeply but not the implications of importing a package that imports another package that depends on something abandoned, mislicensed, or restricted. The fact that a package manager resolves the dependency graph does not mean the organisation has accepted the legal graph.
The modern JavaScript ecosystem is the canonical example because npm packages are famously granular, but the issue is not limited to Node. Python, Rust, Go, Java, .NET, container images, and even PowerShell modules all have their own forms of dependency sprawl. The convenience of reuse is also the mechanism by which obligations and vulnerabilities arrive.
For Windows-heavy shops, the risk may hide in automation rather than products. A PowerShell script that calls a Python utility, which depends on a package generated from a Copilot suggestion, which is then bundled into an installer for a customer engagement, is not science fiction. It is a normal week in a busy IT department.
This is why SBOMs matter even when nobody is selling software. An SBOM is not a magic compliance shield, but it gives the organisation a record of components, versions, suppliers, relationships, and timestamps. Without that inventory, every audit begins as archaeology.
Ownership Paperwork Cannot Launder Third-Party Rights
Trapnell is especially sharp on a common corporate mistake: assuming that an internal IP assignment or repository licence file solves the problem. Companies often state that all employee-created code belongs to the company, then treat that statement as though it cleanses everything inside the repository. It does not.Employment contracts can answer who owns code written by employees in the course of their work. They cannot grant rights to third-party code the company did not own in the first place. A proprietary licence file in the root of a repository does not override an MIT notice buried in a dependency, an Apache patent clause, or a GPL component copied into the codebase.
This distinction sounds obvious when stated plainly, yet it is frequently missed because companies conflate authorship, ownership, and permission. A company may own the glue code written by an employee while still being bound by the licence of a library that glue code incorporates. It may own an AI-assisted script while still needing to preserve notices for copied components. It may own a product while being unable to distribute it under the intended commercial terms until a copyleft issue is resolved.
The due-diligence consequences can be disproportionate. Acquirers and enterprise customers do not need to prove a lawsuit is imminent to care about licence contamination. They need only identify uncertainty significant enough to demand remediation, escrow, indemnity, price adjustment, or exclusion of an asset from the deal.
In that sense, licence compliance is not just about avoiding courtroom drama. It is about preserving optionality. Clean software can be sold, shared, hosted, audited, insured, and integrated more easily than software whose origins nobody can explain.
The AI Assistant Is Now Part of the Build Chain
The industry still talks about AI coding tools as if they sit outside the development process: a clever autocomplete, a pair programmer, a chat window. That framing is outdated. If generated code is accepted into production, the assistant has become part of the build chain in the only sense that matters.GitHub’s matching-public-code controls are a useful example of where vendors are heading. Copilot can be configured to block or reference suggestions that match public code, and GitHub has described code referencing features that show repositories and licences when matches occur. Those are not substitutes for legal judgement, but they are signals that provenance belongs inside developer workflow rather than in a quarterly training deck.
The Linux kernel community’s recent posture, as reported by technology outlets, points in the same direction: AI assistance may be acceptable, but humans remain accountable for what they submit. That principle should be uncontroversial. A compiler does not take responsibility for a binary, and an AI assistant does not take responsibility for a licence breach.
The same logic applies in corporate environments. If a developer, engineer, or analyst accepts AI-generated code, the organisation needs a way to know that AI was involved, what checks were run, and who reviewed the result. The point is not to stigmatise AI-written code. The point is to stop pretending it has no provenance problem because it arrived fluently.
The mature control is disclosure without drama. A pull request can state that AI assistance was used. A scanner can check for licence and code similarity issues. A reviewer can decide whether the implementation is acceptable. A policy can define which licences require escalation. None of this requires banning AI; it requires treating it like any other powerful tool that can produce unsafe output quickly.
Legal Review Must Move Left or It Will Be Ignored
Traditional legal review is too slow for the world Trapnell describes. If every AI-assisted script must wait for a lawyer, employees will route around the process or stop asking. If legal review appears only after a tool is useful, the organisation will face pressure to approve what already exists.The answer is to move licence guidance into the development workflow. Engineers do not need a jurisprudential seminar on the GPL before writing a helper script. They need clear classifications, automated checks, and a known escalation path when a component falls into a risky category.
A traffic-light model is not perfect, but it is useful. Permissive licences can be green with attribution requirements. Weak copyleft licences such as LGPL and MPL can be amber, requiring architectural care and approval. Strong copyleft and network copyleft licences can be red for proprietary use unless legal review approves a specific plan.
The details matter. Apache 2.0 has patent provisions that may matter in some businesses. LGPL obligations differ depending on linking and modification. MPL is file-scoped and may be manageable in ways GPL is not. SSPL is not approved by the Open Source Initiative as open source and is treated warily by many enterprises. But the existence of nuance is not an argument against simple first-line controls; it is the reason escalation exists.
The better organisations will make the safe path the easy path. A GitHub workflow that runs licence scanning on pull requests is more effective than a policy PDF. A template that asks whether AI was used is more useful than a stern reminder at annual training. A curated internal package registry is safer than telling every domain expert to search the internet and hope.
Security and Licensing Are Different Problems With the Same Root Cause
It is tempting to file this issue under legal and leave security teams out of it. That would be a mistake. Licence compliance and software security are separate disciplines, but vibe coding stresses both for the same reason: unknown inputs are entering operational code without normal review.AI-generated code can contain security flaws, outdated patterns, missing error handling, unsafe deserialisation, weak authentication assumptions, or hard-coded secrets. Public research on AI coding assistants has repeatedly raised concerns about insecure suggestions, and developer forums are full of examples where generated code looks plausible but fails under scrutiny. Licence risk is one face of a broader provenance and review problem.
The overlap becomes obvious when dependencies enter the picture. The same inventory that tells you a package’s licence can also tell you whether the version is vulnerable, abandoned, or pulled from a questionable source. The same pull-request gate that flags GPL can flag known CVEs. The same SBOM that supports customer assurance can support incident response.
This is why the governance should not be owned by legal alone. Legal, security, engineering, procurement, and enterprise architecture all have a stake. If the process is framed only as licence policing, it will be resented. If it is framed as software supply-chain hygiene, it becomes part of the same operational discipline that already governs patching, secrets management, and build integrity.
For Windows administrators, the analogy is patch management. Nobody serious argues that patching is optional because most machines probably will not be exploited tomorrow. The practice exists because unmanaged exposure compounds over time. Licence exposure works similarly, except the exploit may be a customer audit rather than a network scan.
The Real Risk Is Not One Bad Snippet; It Is a Portfolio Nobody Can Explain
The nightmare scenario in these discussions is usually a dramatic one: Copilot emits a GPL function verbatim, the company ships it, and an enforcement action forces disclosure of proprietary source code. That can happen in theory, but it is not the most common enterprise failure mode. The more likely failure is cumulative uncertainty.A company accumulates dozens or hundreds of internal repositories. Some were written by software engineers, some by analysts, some by project staff, some by contractors, and some with AI assistance nobody recorded. They include dependencies nobody reviewed, copied snippets nobody remembers, and licences nobody classified. Then a customer, acquirer, insurer, or regulator asks for evidence.
At that moment, the question is no longer “Are we definitely infringing?” It is “Can we prove we are not carrying unacceptable risk?” That is a harder question, and it is expensive to answer after the fact. Retrospective audits are always messier than controls built into creation.
The no-blame audit Trapnell recommends is therefore the right posture. If employees believe an audit is a hunt for culprits, they will hide the very repositories the organisation needs to inspect. If the audit is framed as inventory and remediation, teams are more likely to cooperate.
Most issues will be boring and fixable. A dependency can be replaced. A notice can be restored. A component can be isolated. A risky library can be removed before a tool leaves the company. The earlier the organisation finds the issue, the less dramatic the fix.
The Governance Model Has to Fit the People Now Writing Code
The old compliance model assumed that software was written by software teams. That assumption is increasingly false. AI coding means organisations must design controls for people who may not identify as developers at all.That changes the language of governance. Telling a calibration specialist to evaluate derivative-work risk is pointless. Telling them that red-licence code cannot be merged without review is actionable. Telling a data analyst to produce a full legal assessment of transitive dependencies is unrealistic. Giving them a repository template with automated scanning is reasonable.
Education still matters, but it must be practical. A 30-page policy will be ignored by the people most in need of it. A short guide explaining that open source is not “free of conditions,” that AI output must be reviewed, and that certain licences require escalation will do more good.
The same applies to managers. Many business leaders hear “AI coding” and see only reduced backlog. They need to understand that productivity gains are real but not free. If an internal tool starts influencing customer deliverables, safety decisions, financial reporting, or regulated workflows, it deserves software governance even if it began as a prompt.
The best policy is proportionate. A throwaway local script should not face the same process as a customer-facing service. But once code is shared, stored, scheduled, integrated, or relied upon, it enters the governed estate. That line should be clear enough that non-developers can recognise when they have crossed it.
The Practical Fix Is Smaller Than the Problem Sounds
The good news is that organisations do not need to build a legal observatory to manage this risk. Most of the required controls are already familiar to competent engineering teams. The work is extending them to AI-assisted and citizen-developed code.A sensible baseline starts with repository hygiene. Code that matters should live in managed source control, not personal folders, chat histories, or random zip files. Pull requests should be required for shared projects. Automated licence and vulnerability scans should run before merge. AI use should be disclosed in a lightweight way. Dependencies should be pinned, reviewed, and inventoried.
Tooling choices vary. Snyk, FOSSA, Mend, Black Duck, Trivy, ORT, license-checker, GitHub Advanced Security, and other tools can play roles depending on stack and budget. The specific product matters less than the existence of a repeatable workflow that produces evidence.
SBOM generation should become normal for anything that might be shipped, hosted for external users, or included in a contractual deliverable. SPDX and CycloneDX are widely used formats, and the NTIA’s minimum-element work has helped standardise expectations around component identity, versioning, dependency relationships, authorship, and timestamps. An SBOM will not tell a company whether every use is legally safe, but it gives reviewers the map they need.
Finally, there must be an exception process. If engineers know that red means “never,” they may hide exceptions. If red means “stop and get review,” the process can distinguish between unacceptable incorporation, acceptable isolation, commercial licensing, replacement, or redesign. Governance works best when it can say yes safely, not only no loudly.
Vibe Coding Needs Guardrails Before It Becomes Product Code
The lesson from Trapnell’s piece is not that AI coding should be banned. It is that code created through AI belongs inside the same governance perimeter as code created by hand, and often needs more explicit provenance checks because its author may not understand the supply chain they have entered.- Companies should assume that AI-assisted internal tools are part of the software estate once they are shared, integrated, scheduled, or used for business decisions.
- Licence classification should be simple enough for non-lawyers to apply, with permissive licences treated differently from weak copyleft, strong copyleft, and network copyleft licences.
- Automated scanning should run in pull requests and CI pipelines, because policy that depends on memory will fail under delivery pressure.
- SBOMs should be generated for software that may be shipped, hosted, sold, audited, or relied upon in customer work.
- AI-generated code should be reviewed by accountable humans, not accepted as provenance-free output from a machine.
- Retrospective audits should be no-blame exercises focused on inventory, replacement, isolation, and documented remediation.
References
- Primary source: Trethowans
Published: 2026-07-06T08:50:18.816809
Your engineers are vibe coding which means your licence compliance is probably broken - Trethowans
AI-assisted development is transforming how internal tools get built but most companies haven't thought about what's hiding in the code. There's a quiet
www.trethowans.com
- Related coverage: github.blog
Introducing code referencing for GitHub Copilot - The GitHub Blog
Today, we’re announcing a private beta of GitHub Copilot with code referencing that includes a filter to detect code suggestions matching public code on GitHub.github.blog
- Official source: docs.github.com
Managing GitHub Copilot policies as an individual subscriber - GitHub Docs
Find out how to change your personal settings on GitHub to configure GitHub Copilot's behavior.
docs.github.com
- Related coverage: systemshardening.com
AI-Generated Code and Open Source License Compliance: The Copilot Copyright Problem
GitHub Copilot, Cursor, and Claude Code generate code trained on GPL, LGPL, and AGPL repositories. The legal risk of shipping AI-generated code in commercial products is unresolved. Separately, AI-generated code creates SBOM gaps: when an LLM inlines functionality previously provided by a...www.systemshardening.com - Related coverage: crashoverride.com
- Related coverage: sbomify.com
NTIA Minimum Elements for SBOM (2021) | Sbomify
Complete guide to the NTIA Minimum Elements for a Software Bill of Materials, the foundational US baseline for SBOM data fields.sbomify.com