AI can rewrite open source code—but can it rewrite the license, too?

2026-03-10 · Source: AI - Ars Technica · Field: Technology & Digital — Artificial Intelligence & Machine Learning, Software Development & Engineering, AI Ethics & Legal Frameworks · Depth: Intermediate, short

Summary

The release of chardet version 7.0, a popular open-source Python library for character encoding detection, has ignited a debate over AI-assisted code licensing and derivative works. Maintainer Dan Blanchard rewrote the library in approximately five days using Claude Code, achieving a 48x performance boost and relicensing it from LGPL to a more permissive MIT license. This rewrite, which Blanchard claims is "structurally independent" and shows only 1.29 percent similarity to previous versions via JPlag statistics, involved starting with an empty repository and instructing Claude not to use LGPL/GPL code. However, the original author, Mark Pilgrim, argues it is an illegitimate relicensing because Blanchard had extensive exposure to the original LGPL-licensed code, and Claude's training data likely included prior chardet versions, raising questions about whether the new code is truly non-derivative.

Key takeaway

For CTOs and VPs of Engineering evaluating AI code generation tools, you must carefully consider the legal implications of AI-assisted rewrites, especially concerning open-source licenses. Your teams should establish clear protocols for "AI clean room" development, including strict separation from existing codebases and explicit instructions to the AI, to mitigate risks of unintended license violations and derivative work claims.

Key insights

AI-assisted code rewrites challenge traditional "clean room" reverse engineering and open-source licensing principles.

Principles

• Structural independence is key for non-derivative works.
• AI training data ingestion complicates derivative work claims.

Method

To achieve an "AI clean room" rewrite, specify architecture and requirements, start with an empty repository, and explicitly instruct the AI not to base code on prior licensed versions.

In practice

• Use JPlag or similar tools to assess code structural similarity.
• Document AI prompts and architectural specifications carefully.

Topics

• AI Code Generation
• Software Licensing
• Open-Source Software
• Derivative Works
• Legal Implications of AI

Code references

• chardet/chardet
• jplag/JPlag

Best for: CTO, VP of Engineering/Data, Director of AI/ML, Software Engineer, AI Engineer, Legal Professional

Related on AIssential

• Can coding agents relicense open source through a “clean room” implementation of code? — AI-assisted code rewrites challenge traditional "clean room" definitions and open-source licensing compliance.
• The Guardian view on changes to copyright laws: authors should be protected over big tech | Editorial — Authors are demanding robust copyright legislation to protect their work and livelihoods from unlicensed AI use.
• Researchers propose 'copyleft' rules for generative AI — Generative AI challenges FOSS transparency, leading researchers to propose "copyleft" rules for reciprocal openness.
• GitHub joins coalition advocating for fixes to California AI Transparency Act to protect open source — The California AI Transparency Act's license revocation clauses threaten open source's perpetual nature, requiring amendments for compatibility.
• AI And The Ship of Theseus — Cheap code generation and AI challenge traditional software licensing and copyright, enabling re-implementations from test suites.
• South Korea: If the AI product competes directly with the original market (or acts like a drop-in replacement), fair use becomes much harder to defend. — Fair use in AI training hinges on transformative use and legitimate data acquisition, not market substitution.

Open in AIssential →

Editorial summary, takeaway, and curation by AIssential. Original article published by AI - Ars Technica.