AI coding tools are already changing how companies develop software. But alongside the speed, efficiency and convenience they offer, they also raise fundamental questions about copyright, ownership, infringement and licensing – questions that are no longer theoretical, but commercial, contractual and highly practical.
AI coding tools have quickly become an integral part of the modern software development environment. They assist with drafting functions, completing code, refactoring, debugging, documentation and, at times, even generating entire code segments. Operationally, the value is clear: faster development, time savings and improved productivity. Legally, however, the picture is more complex. As companies rely more heavily on AI in the development process, three core questions come into sharper focus: is the resulting code protected by copyright, who may be regarded as owning the rights in it, and could its use expose the company to infringement or licensing risk?
As in many other areas of GenAI, there is no single answer that fits every scenario. The legal analysis depends heavily on how the tool is used, the degree of human involvement and the nature of the resulting code. Code created with the assistance of AI should not be treated as a single category, but rather as a spectrum of different situations, each of which may lead to a different legal outcome. The January 2025 U.S. Copyright Office report, together with recent European sources, starts from a broadly similar premise: the use of AI systems does not automatically rule out protection, but whether copyright will arise depends on whether the final output reflects sufficient human creative contribution.
From both a legal and practical perspective, it is important to distinguish between three different scenarios.
This distinction matters because it may determine not only who owns the rights in the code, but also a more basic threshold question: whether copyright subsists in it at all. In other words, before asking “who owns the code?”, it is often necessary to ask “does this code create a protectable IP asset in the first place?”
One of the key insights emerging from the recent literature is that, in many cases, ownership is not the starting point. Protection is. The U.S. approach, as reflected in the U.S. Copyright Office report, is that copyright protects expression that originates in sufficient human creative contribution. The use of AI does not, in itself, disqualify a work from protection. However, where the system generates the concrete expressive output and the human provides mainly general instructions or prompts, the basis for recognising sufficient human creative contribution becomes materially weaker. The report further makes clear that prompts alone will not, as a general rule, be enough to establish sufficient human creative contribution.
A similar underlying principle appears in the European materials. Copyright protection is grounded in human intellectual creation, and output generated without sufficient human creative involvement is therefore unlikely, as such, to qualify for protection. By contrast, where a person meaningfully selects, edits, integrates, arranges or rewrites AI-generated material, protection may arise at least in relation to the human elements embodied in the final output.
This is not merely a theoretical issue. If code generated largely by AI is not protected by copyright, the company for which it was developed may not enjoy the same proprietary exclusivity it would ordinarily expect in code written by employees or contractors. Even if the AI provider’s terms of use grant the user certain contractual rights in the output, that does not necessarily create copyright where substantive law would not otherwise recognise it. In that sense, contractual allocation of rights and the existence of copyright protection are not the same question.
Where sufficient human contribution exists, the ownership analysis largely returns to familiar principles: the employee, the employer, the contractor, the commissioning party and the terms of the relevant agreements. In the context of AI-assisted coding, however, the practical application becomes more complicated. The more significant the tool’s role in the creative process, the harder it may be to identify the human element that can properly be attributed to an author or rights holder.
For commercial companies, the most important question is not always whether the code “belongs” to the company, but whether it may create exposure to others. Even where one assumes that the user or the company has certain rights in the output, a separate question remains: does the model-generated code reflect, reproduce or too closely resemble pre-existing third-party code? At that point, the issue shifts from ownership to infringement.
Technical and empirical studies in recent years have found that models may generate code with striking similarity to existing implementations, and that in many cases they do not provide accurate licensing information for those outputs. The issue is particularly acute in relation to copyleft open-source licences, where non-compliance with licence terms may create meaningful commercial and legal exposure.
In software, licensing questions can be just as important as questions of ownership. Many models have been trained, at least in part, on public code repositories, including open-source code. From a practical standpoint, the question companies should be asking when developing code is not only whether the training itself was permissible, but whether code incorporated into a commercial product may carry with it attribution requirements, disclosure obligations, code-sharing duties or other restrictions arising from a third-party licence.
One of the clearest practical concerns highlighted in the literature is the lack of sufficient transparency regarding the source of a model’s suggestion. When a development team integrates AI-generated output without knowing whether it is based on pre-existing code, without understanding its licensing context and without carrying out appropriate review, the company may discover too late that the real risk lies not in the quality of the code, but in the chain of rights behind it.
Despite the remaining uncertainty, several points are already beginning to emerge with some clarity:
At the same time, several important questions remain open: how much human contribution is required to support protection; how much weight should be given to sophisticated prompting; when editing, selection or integration amount to protectable expression; and where the practical line will ultimately be drawn between using AI as a tool and relying on AI as the dominant creator of code.
The practical message for companies is not necessarily to avoid AI-assisted coding, but to use it in a managed, deliberate and risk-calibrated way. At present, a company that does not distinguish between different types of AI use, does not document human contribution and does not implement licensing and compliance controls may find, in hindsight, that its code was faster to produce – but weaker as a proprietary asset and more exposed from a legal perspective.
Companies should therefore already be considering the following steps:
This is not only a technology issue and not only a legal issue. It requires a genuine working interface between the relevant functions within the organisation.
In an era in which code can be produced faster than ever, competitive advantage will depend not only on what AI can generate, but also on a company’s ability to understand what exactly was created, who—if anyone—has rights in it, and what legal baggage may come with it.
