By now the headline is familiar: pure AI output has no human author, so under U.S. law nobody owns it. I've made that case in the overview, watched a federal appeals court confirm it, and watched the Supreme Court leave that rule standing. The law is the same for everyone. What is not the same is what that law costs you. A hobbyist giving code away and a startup vibe-coding an MVP to sell both produce unownable code, and for one of them it's a non-event while for the other it's the whole valuation. Your exposure depends on who you are and what you do with the code.
Two kinds of risk, not one
It helps to split the danger into the two directions code flows through you. Inbound risk is about what the model ingested to produce your code: training data of unknown provenance, scraped repositories, and the chance that infringing or copyleft fragments came out the other side and into your build. Outbound risk is about what you ship: whether you can actually own, license, warrant, and sell the result. Most teams only worry about one of these, but they're independent axes. The company with the scariest inbound problem (the one training the model) often has almost no outbound problem, and the company with catastrophic outbound exposure (the one signing a title warranty it can't honor) barely ingested anything itself. The table below plots eighteen common patterns on both axes, roughly ordered by how often you see them in the U.S. Hover or tap any risk bar to see why it lands where it does.
| # | Persona | The pattern | Example | How they use AI | Inbound risk | Outbound risk |
|---|---|---|---|---|---|---|
| 1 | The "Internal Tooler" | Builds it, runs it, never sells it | Large enterprise IT | AI-assisted scripts and utilities for internal use | Low | Low |
| 2 | The "Onshorer" | Hires a US shop that may quietly use AI | US systems integrator | Contractor leans on AI, client never asks | Low | High |
| 3 | The "Offshorer" | Hires an offshore shop that's hard to audit | Offshore dev firm | Offshore team vibe-codes with low oversight | Low | High |
| 4 | The "Host" | Pure SaaS, never distributes code | Cloud SaaS provider | AI-assisted code that only ever runs on their servers | Low | Moderate |
| 5 | The "Bootstrapper" | Paid app, no investors, not for sale | Solo app developer | Builds a paid product with AI and runs it for recurring revenue | Moderate | High |
| 6 | The "Hired Gun" | Dev shop on the hook for the warranty it signs | Boutique software agency | Builds client deliverables with AI assistance | Low | Critical |
| 7 | The "Renter" | Builds on a platform that indemnifies them | Enterprise on a major AI platform | AI coding on a vendor that stands behind the output | Moderate | Moderate |
| 8 | The "Giver" | Gives it away, never monetizes | Open-source hobbyist | AI-generated code released freely | Low | None |
| 9 | The "Licensor" | Ships licensed software, keeps the company | Commercial software vendor | AI-assisted product code shipped to customers | Moderate | Critical |
| 10 | The "Regulated" | Pharma, finance, or health under audit | Health or finance software firm | AI in the build triggers traceability duties | Moderate | Critical |
| 11 | The "Exiter" | Vibe-codes an MVP to raise money and sell | Early-stage AI startup | Founders generate most of the codebase with AI | Moderate | Critical |
| 12 | The "Acquirer" | Buys companies, asks who owns the code | Strategic acquirer | Uses AI-detection in diligence, not to build | Low | Moderate |
| 13 | The "Civic Coder" | Government writes it; open, unownable by law | Federal agency (e.g. NASA) | Federal devs use AI on public-domain code | Moderate | None |
| 14 | The "Fed Supplier" | Delivers to the government under statute | Defense or gov contractor | AI in the build must survive federal title and accuracy rules | Moderate | Critical |
| 15 | The "Inheritor" | Bought a codebase, gap shows up later | Post-acquisition operator | Inherited AI-built code, often undisclosed | Low | High |
| 16 | The "Walled Garden" | Trains its own model on its own data | Large enterprise with internal LLM | Internal LLM trained only on owned code | Low | Low |
| 17 | The "Two-Tier" | Open-source core plus a paid layer | Open-core software company | AI mixed across free and proprietary tiers | Moderate | Critical |
| 18 | The "Model Maker" | Ships the AI itself | Foundation-model company | Trains and sells the model others build on | Critical | Low |
Low Moderate High Critical
The patterns worth staring at
Read the two columns against each other and the story writes itself. Exactly one persona carries critical inbound risk, and it's the Model Maker, the company scraping the world to train a model while the fair-use question sits unresolved in court. Everyone else's inbound risk is a downstream echo of that one. The critical outbound risks cluster somewhere else entirely: the Hired Gun, the Licensor, the Exiter, the Fed Supplier, the Regulated firm, the Two-Tier vendor. What they share isn't heavy AI use, it's a promise. Each one signs or implies a warranty of title, to a customer, an acquirer, or the federal government, and unowned AI code makes that warranty a lie waiting to be discovered. At the calm end sit the Giver and the Civic Coder, whose outbound risk is genuinely zero because they never intended to own or sell anything. The Walled Garden earns low-low by training on its own data and keeping the output inside. The lesson isn't that AI is safe or dangerous in the abstract. It's that the same unownable code is a rounding error for one persona and an existential defect for another, and the deciding factor is what you promised about it.
Find yourself on the list
Most organizations are more than one of these at once, and that's the useful part. A commercial vendor with a government contract and a regulated customer is stacking three critical-outbound patterns on the same codebase. A startup that plans to raise, then sell, is an Exiter today and an Inheritor's problem tomorrow. The point of the table isn't the taxonomy for its own sake; it's a prompt to ask which rows describe you, because that dictates how much governance the moment actually demands. If your worst exposure is a shrug (Internal Tooler, Giver), a light-touch policy is proportionate. If you're anywhere in the critical-outbound cluster, the ownership question isn't a someday problem, it's a term in a contract you've already signed.
The advice still doesn't change
Wherever you land, the response is the same one I've given since the first post, just weighted by your risk. Keep a human doing the expressive, creative work on anything you intend to own. Keep the record of who did what, in your prompts and your commits, because that's the evidence the day authorship is questioned. Don't apply an open-source license to code you don't own, and don't mistake revenue or a shipped product for a defensible asset. What the table adds is triage: the higher your outbound column, the sooner that discipline stops being good hygiene and starts being the thing standing between you and a broken warranty. I'm a developer, not your attorney, so none of this is legal advice. But you can find your row, and you can see what it's going to cost you to keep pretending the question doesn't apply.
Want to know exactly where your organization stands? Visit whoownsthecode.com and take the assessment today.