AI assistants can write a working program from a paragraph of English. That is genuinely useful, and it is also a quiet legal problem that most people shipping “vibe-coded” projects have not thought through. If no human wrote the code, no human owns the copyright, and the entire open source licensing model depends on copyright being attached to a person.
I want to walk through why this matters, what the actual legal ground looks like as of mid-2026, and what a small team should do today if it is shipping AI-written code under a copyleft license. I am not a lawyer, and this is not legal advice. It is a reading of the public record and a list of decisions I would make if I were the one shipping the repo.
What the copyright question actually looks like
Open source licenses (the family of licenses that let you copy, modify, and redistribute code under specific conditions) only work because copyright exists. The MIT License (a permissive license that lets you do almost anything as long as you keep the copyright notice) says the software is “Copyright (c) [year] [name].” The GPL says “you must give any other recipients of the program a copy of the source code.” Both phrases assume a person or company holds the copyright in the first place.
Copyright in the United States (and under the Berne Convention in most other jurisdictions) attaches to works “created by a human being.” That phrase is short, but it is doing an enormous amount of work. The U.S. Copyright Office has been clear, in multiple review board decisions over the last few years, that it will not register a work that was generated by a machine with no meaningful human creative input. The application form now asks the applicant to identify the human author and to describe what that human contributed. A pure prompt-and-paste workflow with no edits does not satisfy that requirement.
That does not mean AI-written code is “unowned” in some romantic sense. It means the copyright is unattributable. The code is in the public domain by default (a default that means anyone can use it without permission or obligation) unless a human can claim a meaningful creative contribution to the specific output. The distinction matters because the public domain default is incompatible with the entire copyleft premise.
Why copyleft breaks without an author
Copyleft licenses are reciprocal. The GPL (GNU General Public License, the most widely used copyleft license) says: you can use, modify, and redistribute this code under the condition that any derivative work is also GPL. That reciprocal obligation is enforceable because the original copyright holder can sue for infringement. Without a copyright holder, the only thing the license grants is permission. Permission is weaker than copyright because permission can be granted by anyone, including people who do not own what they are granting.
If a vibe-coded project ships with a GPL header, three things are simultaneously true:
- The header implies a copyright holder who may not legally exist.
- The reciprocal obligation that makes GPL enforceable is not attached to a person who can sue.
- Any downstream user can argue, in bad faith or otherwise, that they took the permission and ignored the obligation because there was no underlying copyright to enforce against them.
This is not a hypothetical. It is the structural problem copyleft was specifically designed to avoid, and it returns the moment the author disappears from the workflow.
What permissive licenses do instead
MIT, BSD, and Apache 2.0 (the three permissive licenses that dominate modern open source) do not depend on reciprocity. They grant broad permission in exchange for keeping a copyright notice. If the copyright notice is unattributable, the license still grants permission. The downstream user can do almost anything with the code, including make a proprietary fork. The only thing they cannot do is remove the copyright notice, and if there is no valid copyright holder, that requirement also weakens.
For a vibe-coded project, a permissive license is the only one that does not create a structural mismatch between what the license promises and what the workflow produces. That is not a value judgment. It is a description of how the licenses were drafted.
What the courts and the Copyright Office have actually said
The case law and the Copyright Office guidance both point in the same direction. The Copyright Office has refused registration for AI-generated outputs where the human contribution was limited to prompting. The most-cited example in the U.S. is the Théâtre D’opéra Spatial case, where the artist used Midjourney to generate an image and applied for copyright registration. The Copyright Office’s final decision in 2023 found that the artist’s “sole contribution” was the text prompt and that the office “has found previously that copyright law is meant to protect human authors, not machines.” The decision also referenced earlier cases the office had rejected, including a work “purportedly authored by non-human spiritual beings” and the question of whether a monkey’s selfie could be copyrighted.
In 2023, the U.S. District Court for the District of Columbia became the first federal court to specifically address the copyrightability of AI-generated outputs, in a case challenging the Copyright Office’s refusal to register the same image. The court agreed with the office. The office has since published a 52-page report on Copyright and Artificial Intelligence, with Part 2 on Copyrightability being the part most readers will want to start with. Many of the pages are footnotes, so the effective reading load is closer to 25 or 30 pages.
The same direction is visible in the broader copyright policy discussion in the U.S., UK, EU, and Australia. Major IP offices in each of those jurisdictions have published guidance that excludes purely AI-generated works from copyright protection absent a human author. The Berne Convention baseline (the international treaty that establishes baseline copyright protection across most of the world) leans toward human authorship, even where specific national patent offices have taken more permissive positions on AI-generated inventions.
If you are shipping in 2026, the assumption that “the code I just generated is mine to license” is not safe.
What I would actually do today
For a small team that has been using AI assistants heavily and is shipping a copyleft project, three concrete steps are worth taking:
- Document the human edits. Keep a commit history that shows which lines came from a prompt and which were typed by a person. A reviewer who can point at the human-touched lines has a much stronger authorship claim than one who pasted a final block.
- Pick the right license for the workflow. Permissive licenses survive an unattributable author better than copyleft. If the project genuinely needs GPL, get a human-authored core and use AI to extend it, not the other way around.
- Read the AI provider’s terms. OpenAI, Anthropic, Google, and Meta each have output ownership clauses that assign rights to the user under specific conditions. The conditions are not identical, and they do not solve the copyright-attach-to-human problem on their own, but they do affect what you can claim about outputs.
- Keep a paper trail outside the repo. A short note in the project README saying “human-authored by [name], AI-assisted for X percent of lines” is not a legal shield, but it gives a downstream reviewer (or a future court) a starting point. Silence on the question is the worst position to be in if a dispute ever arises.
The legal answer is not “vibe coding is illegal.” It is that the licenses most open source projects rely on were designed for a world where a person wrote the code. The newer world requires either different licenses, different workflows, or different assumptions about who owns what.
Trade-offs
There is a real cost to the cautious path. Documenting human edits adds friction to a workflow that exists specifically because it removes friction. Picking permissive over copyleft weakens the reciprocal guarantee that many projects rely on to stay open in the first place. Reading four sets of provider terms is a small task, but it is not zero, and most teams will not do it.
The alternative is to keep the frictionless workflow and accept that the resulting license header may not mean what people think it means. For an internal tool, that is probably fine. For a public library that downstream users will fork and ship under their own brands, it is not fine. The trade-off is between shipping speed and license integrity, and the answer depends on who is going to be downstream of the code you are putting out today.
If your project is a personal script or a tool you will never redistribute, the legal question is mostly theoretical. If your project is an open source library that hundreds of other projects will pull in, the question is the entire premise of the license you are publishing under.
Bottom line
The legal ground under “AI wrote this code” is still shifting, but it is shifting in one direction. The U.S. Copyright Office, the major IP offices abroad, and the handful of cases on record all agree that pure AI output does not get a copyright. Open source licenses depend on copyright, and copyleft depends on it twice. If you are vibe-coding under a copyleft header, you are publishing a license that is structurally weaker than the one you think you are publishing. The fix is not to stop using AI assistants. It is to be honest about who did the writing, choose a license that survives that answer, and keep the human edits in the commit log so a future dispute has something to point at.