AI-generated code and open-source licenses: managing the IP risk

Most conversations about AI coding tools and risk focus on security or data privacy. The one that gets less attention, and is harder to unwind later, is intellectual property: who owns the code an AI tool helped write, and whether any of it carries an open-source license your business never agreed to.

This is not hypothetical. AI coding models are trained on large amounts of public code, including code under restrictive licenses. Most of the time a suggestion is novel enough to be fine. Occasionally it is a near-verbatim reproduction of training data, and if that data was licensed under GPL or another copyleft license, accepting the suggestion can pull obligations into your codebase that nobody evaluated.

We help engineering teams manage this without turning it into a legal project that stops delivery. The risk is real but bounded, and the controls are practical. Here is how to think about it.

This is a practical engineering view, not legal advice. The law here is unsettled and varies by jurisdiction; your legal counsel owns the final position for your organisation.

The two distinct risks

"IP risk from AI code" bundles two different problems that need different answers.

The first is about obligations you might unknowingly take on. The second is about whether the code is cleanly yours to begin with. Both matter, and they are easy to conflate.

Inbound: when a suggestion carries a license

The contamination risk is concentrated, not uniform. It is highest when a model reproduces a recognisable chunk of training data: most likely for well-known algorithms, distinctive utility functions, or large blocks generated from a thin prompt.

The danger is that copyleft licenses such as the GPL are "viral": if their code is incorporated into your product and distributed, the license can require you to release your own source under the same terms. For a proprietary codebase, that is a serious problem, and it is invisible at the moment of acceptance because the suggestion arrives with no provenance attached. The engineer sees code that works. They do not see where it came from.

The mitigations are concrete:

• Use the vendor's duplication or filtering feature. Several enterprise AI coding tools can detect when a suggestion closely matches public code and either block it or flag it with the source. Turn this on. It is the single highest-leverage control.
• Prefer tools that offer IP indemnification. Some enterprise vendors contractually indemnify customers against third-party IP claims arising from their tool's suggestions, on qualifying plans with the duplication filter enabled. This shifts a meaningful part of the risk and is worth weighing in tool selection.
• Run license scanning in CI. Software composition analysis and license scanners catch known problematic patterns and flag license headers, whether the code came from a human or a model.
• Be most careful with verbatim large blocks. A whole function generated wholesale deserves more scrutiny than a line-by-line completion the author shaped.

Outbound: do you actually own the output

The second question is whether AI-generated code is cleanly yours. Two issues sit underneath it.

First, copyright in purely AI-generated work is unsettled. Some jurisdictions, including current US Copyright Office guidance, hold that material generated without sufficient human authorship may not be copyrightable. In practice, code with meaningful human direction, editing, and integration is on far safer ground than code accepted wholesale and untouched. That is another reason the author should understand and shape every change, not just accept it.

Second, check the tool's own terms. Reputable coding-tool vendors assign output ownership to the user and do not claim rights over generated code, but this is a term to verify per tool and plan, not assume. If you later sell the company or sign a customer contract with IP warranties, this is exactly what diligence will examine.

Provenance is the thing AI removed

Step back and the root issue is clear. Traditional development has provenance built in: every dependency is declared, every license is in a manifest, every commit has an author. You know where your code came from.

AI-suggested code arrives with none of that. The provenance, the chain of where a piece of logic originated and under what terms, is exactly what the model strips away. Managing IP risk is, at its core, adding that provenance discipline back.

• Declare AI assistance in your process so it is visible which work was AI-heavy and may warrant more provenance scrutiny.
• Keep dependency hygiene strict. Models sometimes suggest adding a package; that package has its own license and supply-chain risk, evaluated the same as any other dependency.
• Maintain your license inventory. Know which licenses are acceptable in your codebase and which are not, so scanning has a policy to enforce against.

Write it into policy and tooling, not memory

None of this works as a thing engineers are supposed to remember mid-task. It works when it is built into the path.

• Approved tools have the duplication filter on, set at the organisation level so it cannot be silently disabled.
• License scanning runs in CI, blocking merges that introduce a disallowed license.
• The [AI usage policy](/blog/how-to-write-an-ai-usage-policy) states the rule: which licenses are acceptable, that large verbatim blocks get extra review, and that AI assistance is declared.

That turns a fuzzy legal worry into a few enforced defaults, which is the only form of this control that survives contact with a deadline.

Our view

The open-source license risk from AI coding tools is real but manageable, and it is overwhelmingly addressable through tooling rather than vigilance. The contamination risk concentrates in verbatim reproduction of training data, and enterprise duplication filters plus CI license scanning catch most of it. The ownership question is genuinely unsettled, which is itself the reason to keep meaningful human authorship in the loop and to verify your vendor's terms.

The deeper point is that AI removed provenance from your codebase, quietly. The teams that handle IP risk well are the ones that add it back deliberately, through filters, scanners, and a written policy, so that "where did this code come from" has an answer before anyone has to ask it in a deposition.

• US Copyright Office, Copyright and Artificial Intelligence guidance on human authorship, accessed 2026-06-10
• Free Software Foundation, GNU General Public License and copyleft obligations, accessed 2026-06-10
• OWASP, OWASP Top 10 for Large Language Model Applications, on insecure output and provenance, accessed 2026-06-10
• Linux Foundation / SPDX, software license identification and SBOM practice, accessed 2026-06-10