“AI introduces an awkward question: how clean is the room?”
AI tools can help developers recreate the functions of established software. But there is an important difference between building an alternative and copying someone else’s work.
A developer’s recent claim to have attracted 20,000 users to a “vibe-coded” alternative to Photoshop raises an interesting question. If AI can help someone build a competing product, does the original software owner have grounds to complain?
The instinctive answer might be that recreating an established product must infringe its copyright. After all, the original developer may have invested years in developing it. However, copyright does not give a software business a monopoly over what its product does. The distinction between copying functionality and copying the expression of that functionality has been tested in the courts long before AI coding tools arrived.
Same result, different software
Consider a photo editor. A developer might want users to crop images, adjust colours and work with layers. Those requirements describe functions. The code written to deliver them is something different.
That distinction is central to software copyright. Source code and object code can be protected, but the ideas and principles underlying a program are not protected as such. Consequently, a competing program does not necessarily infringe merely because it accepts the same inputs or produces the same results.
The English courts addressed this in Navitaire v easyJet [2004] EWHC 1725 (Ch). A replacement airline reservation system was deliberately developed to operate much like the existing system, without access to its source code. The court rejected the principal claim that reproducing its functional behaviour infringed copyright. Importantly, however, some claims concerning graphical screens and icons succeeded. The functionality and the artwork required different answers.
For anyone developing a software alternative, that is a useful starting point: recreating what a product does is not the same as having permission to reproduce everything the user sees.
What makes a clean-room implementation different?
A clean-room process is designed to keep those distinctions clear. Typically, one team studies the existing software and prepares a specification describing its functional behaviour. A separate team, which has not seen the original code, writes a new implementation from that specification. Records of the process help demonstrate independent development.
This is not a way of making the original copyright disappear. Nor is “clean room” a legal label that guarantees a favourable result. Its value lies in showing that the new product reproduces unprotected functionality rather than protected expression.
AI introduces an awkward question: how clean is the room?
Starting with an empty repository does not necessarily answer this question. The material supplied to the coding tool matters, as does any source material it retrieves. There may also be questions about whether the model encountered relevant code during training. Those questions do not establish infringement, but they make a simple assertion that “the AI wrote it from scratch” less reassuring than it might first appear.
Developers should therefore distinguish between asking AI to implement a functional specification and asking it to rewrite an existing codebase. The two exercises should not be treated as interchangeable.
European law
One of the most relevant decisions is SAS Institute v World Programming, C‑406/10. The competing software was intended to run programs written in the same language as the original system and produce the same outputs. Its developer studied the original product, but there was no suggestion that it had accessed or copied the original source code.
In C-406/10, the Court of Justice of the European Union held that a program’s functionality, programming language and relevant data-file formats were not forms of expression protected by copyright in the computer program under the Software Directive. The distinction preserved the ability to develop compatible software without giving the first developer exclusive control over the underlying ideas.
In the subsequent English appeal, SAS Institute v World Programming [2013] EWCA Civ 1482, upheld the outcome in favour of functional reimplementation. However, limited findings of infringement relating to copying between manuals remained. Understanding a product from its documentation is one thing; reproducing protected expression from that documentation is another.
For a photo editor, this provides a useful analogy. Writing independent code to support an existing file format is not automatically the same as copying the original program. It does not follow, however, that code, documentation or other protected material associated with that format can simply be taken.
Didn’t Google win the argument about APIs?
The long-running dispute between Google and Oracle in the US courst is often recalled as establishing that application programming interfaces, or APIs, cannot be protected by copyright. That is not where the US Supreme Court ultimately landed.
An API allows programmers to call on functions without writing the underlying implementation themselves. In developing Android, Google wrote its own implementing code but copied approximately 11,500 lines of declaring code and the associated organisational structure from the Java platform, allowing programmers to use familiar commands.
After conflicting outcomes in the lower courts, the Supreme Court ruled in Google v Oracle in April 2021 that the copying was fair use (summarised here). Crucially, it assumed copyright protection existed for the purpose of deciding the case, rather than resolving whether the material was copyrightable.
The decision therefore does not establish that APIs are universally free to copy. Nor should its US fair-use reasoning be confused with the European approach in SAS Institute v World Programming, which concerned the scope of software copyright and permitted study of a program. The cases offer support for compatibility and reimplementation, but through different legal routes.
New code does not settle the question
A developer might avoid copying the original code yet reproduce its interface very closely. That raises a separate issue.
In Bezpečnostní softwarová asociace, C‑393/09, the European court held that a graphical user interface was not protected as the expression of a computer program under the Software Directive. Nevertheless, an interface could qualify for copyright protection in its own right if it was its author’s own intellectual creation. Components dictated only by technical function would not meet that originality requirement.
Applied to an AI-coded photo editor, the distinction is between providing familiar editing functions and reproducing original graphics or other protected interface expression. Asking a coding tool to recreate a screen from an image should not be assumed safe simply because the resulting code is new. That is the practical implication of treating the interface separately from the program implementing it.
What should developers and software businesses do?
For developers, our recommendation is to define the functionality needed before generating the implementation. Keep records of the specifications, prompts and source materials used, and review the resulting code and visual assets separately. A documented development process is more useful than relying on a description such as “AI-generated” or “written from scratch”.
For established software businesses, the cases also highlight the limits of relying on copyright alone. Copyright can protect valuable code, graphics and documentation, but it does not necessarily prevent a competitor from independently implementing the same functions. Other rights and obligations, including patents, trade secrets and contractual restrictions, need separate consideration.
Recent advancements in vibe-coding should be a prompt for that discussion.
The central question remains a familiar one: has the developer created another way of doing the same thing, or reproduced someone else’s protected work? AI may change how the software is built, but “the AI wrote it” is not a substitute for answering that question.
If you are developing a competing or compatible software product, or are concerned about a product reproducing your own, contact your usual Barker Brettell attorney to discuss the IP issues.
