Tag Archives: software copyright

Can AI-Written Code Be Truly Clean?

Clean-room development, open-source licences and the law

John Britto Kurusumuthu

In March 2026, the maintainers of chardet, a widely used Python library for detecting text encodings, released version 7.0 as a ground-up rewrite. Much of the new code was produced with an AI coding assistant, and it arrived under a new licence: the permissive MIT licence in place of the LGPL that had governed the project for years.

The library’s original author objected publicly. A complete rewrite, he argued, changes nothing when its authors had ample exposure to the original code; in his view, this was no clean room. The maintainer has defended the release, saying he designed and reviewed every part of the rewrite and that the MIT licence applies to it legitimately. The dispute remains unresolved, and the debate it set off is still running through the open-source world.

Whatever one concludes about chardet, the episode exposes a common misunderstanding. We tend to think of clean-room development as a way of writing code. It is better understood as a way of proving a negative: that the people who wrote the new program never drew on the protected expression of the old one. The code is the product; the record is the defence.

AI coding assistants have made the first part cheaper than ever. A capable model can rewrite a library in days. They have also made the second part harder, because no one can say with certainty what a model has absorbed. That tension is the subject of this post.

1. What clean-room development is, and what it is not

Clean-room development separates the people who study an existing program from the people who build its replacement. The method entered industry practice in the early 1980s, when makers of IBM-compatible personal computers, Compaq and Phoenix Technologies among them, used separated teams to write their own BIOS firmware. It runs in five steps:

  1. The analysis team studies the original through lawful means: documentation, observable behaviour, published specifications, interfaces and, where the law permits, technical inspection.
  2. That team writes a functional specification. It records what the software must do, its interfaces, inputs, outputs and test cases, but not how the original authors expressed it in code.
  3. A reviewer screens the specification before hand-off and strips out anything carrying protected implementation detail.
  4. The implementation team, which has never seen the original code, writes the new program from the approved specification alone.
  5. The finished code is tested for compatibility and examined for provenance, third-party components and licence obligations before release.

The central distinction is between what a program does and how its authors chose to express that in code. Software functionality and ideas are generally treated differently from protected expression, although other legal rights and restrictions may apply.

2. Why the wall matters: four layers of legal risk

A clean room is a risk-management technique, not a legal exemption. It answers one layer of risk well and leaves the others untouched.

  1. Copyright. Copyright protects original expression, not ideas, methods of operation or functionality as such. A separated process makes it far easier to show that a new program does not reproduce protected source code, structure or other expression. It does not guarantee that the result is lawful.
  2. Interfaces and interoperability. A compatible product may need to reproduce APIs, command syntax, file formats or observable behaviour. Some of these elements are functional or dictated by compatibility; others may carry protectable expression. The answer varies by jurisdiction and by interface.
  3. Patents and trade secrets. Independent creation is no defence to patent infringement: freshly written code can still practise a valid claim. Nor does a clean room cure information obtained by improper means or in breach of confidence.
  4. Contracts and licences. Lawful access to code may come with conditions restricting its use, disclosure or reverse engineering. Whether such conditions bind depends heavily on where you are, as the next section shows.

3. What the courts and legislatures have said

The legal footing differs markedly across the three systems most relevant to readers here: case-by-case fair use in the United States, a statutory code in the European Union, and narrow, specific exceptions in India.

United States: fair use, case by case. In Sega v. Accolade (1992), the Ninth Circuit held that disassembling Sega’s game code to learn the console’s compatibility requirements was fair use. The decisive factors were a legitimate purpose and the absence of any other way to reach the unprotected functional elements. Accolade then worked from a manual of functional descriptions containing none of Sega’s code, a clean room in all but name.

In Google LLC v. Oracle America (2021), the Supreme Court held, six votes to two, that Google’s copying of roughly 11,500 lines of declaring code from the Java SE API was fair use as a matter of law. The Court assumed, without deciding, that the code was copyrightable. Two cautions follow: fair use turns on its facts, and American courts have in some cases enforced licence terms that forbid reverse engineering.

European Union: a statutory code. Directive 2009/24/EC sets the rules out directly.

  1. Article 5(3) lets a person entitled to use a program observe, study or test its functioning, to determine the ideas and principles underlying it, while loading, displaying, running, transmitting or storing it.
  2. Article 6 permits decompilation without the rightholder’s consent where it is indispensable for interoperability with an independently created program. The person must be entitled to use the program, the information must not already be readily available, and the acts must be confined to the parts needed. The information may not be used for other purposes, passed on unnecessarily, or used to build a program substantially similar in its expression.
  3. Article 8 makes any contract term contrary to Article 6, or to Article 5(2) and (3), null and void.

In SAS Institute v World Programming (Case C-406/10, 2012), the Court of Justice added that neither a program’s functionality, nor its programming language, nor the format of its data files is a form of expression protected by copyright.

India: narrow, specific exceptions. The Copyright Act, 1957 treats software differently from other works. Its general fair-dealing exception in section 52(1)(a) applies only to a work “not being a computer programme”. Software has its own cluster of exceptions instead, added by amendments in the 1990s:

  1. Section 52(1)(aa): the lawful possessor of a copy may make copies or adaptations to use the program for the purpose for which it was supplied, and back-up copies as temporary protection against loss or damage.
  2. Section 52(1)(ab): a lawful possessor may do any act necessary to obtain information essential for the interoperability of an independently created program with other programs, provided that information is not otherwise readily available. This is the clause most directly relevant to clean-room work.
  3. Section 52(1)(ac): a program’s functioning may be observed, studied or tested to determine the ideas and principles underlying any of its elements, while performing acts necessary for the functions for which it was supplied.
  4. Section 52(1)(ad): copies or adaptations may be made from a personally, legally obtained copy for non-commercial personal use.

Two cautions apply. Section 52 has no counterpart to Article 8 of the EU Directive, so whether a licence term can narrow these exceptions remains an open question in Indian law. And the clauses have seen little judicial interpretation: how far “any act necessary” in clause (ab) extends to decompilation, for instance, is yet to be tested. A cross-border project may engage all three regimes at once.

4. Open-source licences: independence is not compliance

Open-source software is copyrighted software released under a licence that grants stated permissions on stated conditions. It is not free of legal restriction. A clean room can help when building an independent alternative to an open-source product, but it is not always needed, and it never discharges obligations attached to material that is actually reused.

  1. Reimplementing documented functionality without copying protected code: independent implementation may be lawful, subject to patents, contracts and other rights.
  2. Copying MIT- or BSD-licensed code: keep the copyright notice and licence text, and meet any attribution conditions.
  3. Modifying or distributing GPL-licensed code: where your work is a covered derivative, the GPL’s conditions on source availability and licensing apply.
  4. Using an AGPL component: a modified version offered to users over a network may oblige you to make its corresponding source available.
  5. Reimplementing an API or file format: assess copyright, interoperability rules, patents, contract terms and any expressive material.
  6. Reusing code with no identifiable licence: public availability is not permission.

Licence versions matter, and so does architecture: how components are linked, combined and distributed can change the analysis. An independently written database driver does not take on the licence of an MIT-licensed utility library merely because both sit in one project, though the library itself must still travel with its notices.

Likewise, reimplementing functionality associated with a GPL program does not make the new program GPL-licensed, provided the new work genuinely avoids copying protected expression. That proviso is exactly what the chardet dispute is about.

5. What AI changes

AI assistance does not by itself defeat a clean-room process. It complicates two things: the evidence of independence and the assessment of licence obligations. Three risks stand out.

  1. Similar output. A model may produce code resembling existing source code. If the output reproduces protected expression, the fact that a machine produced it is no answer. Short, commonplace or functionally dictated code calls for a different analysis from substantial reproduction of distinctive code.
  2. Unknown provenance. A suggestion may resemble code released under terms that require attribution, preserved notices or reciprocal licensing. If you cannot identify the source, you cannot know which steps compliance demands.
  3. Contamination of the clean side. A conventional clean room controls what the implementation team sees. An assistant can quietly breach that wall if it is fed the original source, repository context, internal notes or prompts drawn from material the team was meant to avoid. The chardet controversy raises a version of this question: whether a rewrite led by a long-time maintainer of the old code can count as independent. The original author says it cannot, the maintainer says it can, and at least one prominent licensing expert has observed that no one has yet identified copied expression from earlier versions in the new code. The question remains open.

Tools help, but none of them settles the question. GitHub’s code-referencing feature for Copilot compares a suggestion, with about 150 characters of surrounding code, against an index of public code on GitHub. Where it finds a match, it shows the repositories and their licences. GitHub reports that matches occur in under one per cent of suggestions, but the check covers only accepted completions; code you write yourself, and suggestions you modify or dismiss, are not checked. The absence of a flag is not proof of independent authorship.

Does AI-generated code inherit an open-source licence because the model learned from open-source repositories? Not automatically. The real questions are whether a given output reproduces protected material, which licence governs that material, and what the AI provider’s own terms say about the output. The Linux Foundation’s guidance on generative AI asks contributors to check that last point: the tool’s terms must not restrict use of its output in ways inconsistent with the project’s licence.

Can an assistant take part in a clean-room project at all? Yes, if its role is drawn as carefully as a human team member’s. It may generate implementation code from an approved functional specification; it must never receive the original source or analysis notes containing protected detail.

The Linux kernel offers a working model of accountability. Its rules for AI coding assistants, added during the Linux 7.0 cycle, bar AI agents from adding a Signed-off-by tag, because only a human can certify the Developer Certificate of Origin. The human submitter must review the generated code, ensure licence compliance and take full responsibility, and the patch should carry an Assisted-by tag naming the tool.

6. A clean-room protocol for AI-assisted work

For a commercial project, I would recommend seven controls.

  1. Define the legal scope: the target software, the jurisdictions involved, the intended compatibility and any contractual restrictions.
  2. Draw the information boundary: what the analysis team may inspect, and what may cross to the implementation team.
  3. Approve the specification: functional requirements, interfaces, input and output behaviour and test cases, without unnecessary implementation detail.
  4. Configure the AI tools: use an approved assistant whose repository access is limited to the clean side, with no excluded source, confidential material or restricted analysis notes in its context.
  5. Keep the record: specification versions, commits, prompts where appropriate, AI-generated patches, review notes and third-party notices.
  6. Check provenance and licences: similarity scanning, dependency inventories and software composition analysis, with every significant match investigated.
  7. Review before release: obtain legal review of material risks, confirm licence compatibility and document the basis for the clean-room conclusion.

Treat the assistant as part of the process, never as a source of legal assurance. A similarity scanner, a provider’s statement or the absence of a visible match is each a useful signal; none of them, alone, establishes that the program is free from infringement.

7. Who answers when the machine writes the code?

Responsibility turns on four questions that are related but not interchangeable.

  1. Copyright: does the output reproduce someone else’s protected expression?
  2. Licence compliance: does any incorporated third-party material carry obligations?
  3. Ownership: who, if anyone, owns the resulting code?
  4. Accountability: who reviewed, approved and authorised it for distribution?

Ownership is where jurisdictions now diverge most visibly. In the United States, the Supreme Court on 2 March 2026 declined to review Thaler v. Perlmutter, leaving in place the D.C. Circuit’s 2025 ruling that copyright requires a human author. A refusal to hear a case is not a ruling on its merits, and the appellate court did not decide how much human involvement an AI-assisted work needs.

India’s Act took a different line long before generative AI arrived. Section 2(d)(vi), added in 1994, makes the author of a computer-generated literary, dramatic, musical or artistic work “the person who causes the work to be created”. Because section 2(o) counts computer programmes as literary works, the clause reaches code as well.

On 31 August 2026, the Registrar of Copyrights rejected an application by Stephen Thaler that named his AI system, DABUS, as the author of an artwork, the same work at issue in the American case. DABUS, the Registrar held, is neither a natural nor a juristic person and cannot be entered as author. The Registrar also found that Thaler, on his own account, was the person who caused the work to be created; but he declined an opportunity to amend the application to name himself as author, and it was rejected as filed. The order is expressly confined to the facts of that application.

Neither approach settles the separate question of infringement. A company may own code, or hold contractual rights to use it, and still find that it copies someone else’s work. For anything meant for distribution, document your rights in AI output and your process for detecting and resolving third-party matches.

The room was always a ledger

Clean-room development remains the most credible way to show that software was independently written. Open-source licensing does not displace copyright compliance, and AI-generated code is neither automatically independent nor automatically unrestricted. The most defensible approach combines a separated process, a clear functional specification, lawful information-gathering, controlled AI access, provenance and licence checks, and documented human review.

The age of AI has not abolished the clean room; it has moved its centre of gravity. When anyone can generate a thousand lines in an afternoon, lines are cheap. What stays scarce, and what a court will ask to see, is the record of how they came to be written. The clean room, in the end, was never really a room. It was always a ledger.

This is a general legal and technical discussion, not a legal opinion. A project involving commercial release, disputed access to source code or significant licence exposure should be reviewed by a lawyer experienced in software intellectual property.

Further reading

John Britto Kurusumuthu

Rise & Inspire  ·  riseandinspire.co.in

Explore more at the Rise & Inspire archive |   Law 

© 2026 Rise & Inspire. All Rights Reserved.

Website: Home  |  Blog  |  About Us  |  Contact  |  Resources