Who owns the code an AI tool writes for you?

Ask a supplier whether you own what their tool builds and you will get a confident yes. It is a fair answer to an unfair question, because “own” is doing three jobs at once: who holds the copyright, can you read and change the thing, and can you run it somewhere else. A vendor can be entirely truthful about the first and leave you stuck on the third.

The three questions

• Legal ownership. Who holds the rights to the output, and what do the terms you signed say about it?
• Transparency. Can you see the code, read it, review it, and have your own developers change it — or is it behind an editor and a format that only the vendor’s software understands?
• Portability. If the relationship ends, does what you built keep running? On whose infrastructure, with whose database, and how much work is the move?

They come apart in ways that matter. You can hold every right to a system you cannot read. You can be able to read code you cannot run anywhere but there. Only the combination is worth anything.

The legal part, honestly

Copyright in machine-generated output is unsettled, and it is unsettled differently in different countries. The general direction in the United States has been that copyright protects human authorship, and that material produced by a machine without meaningful human creative input is not registrable — while work where a person contributed the creative expression, and used a tool along the way, is treated normally. Other jurisdictions weigh it differently, and the position keeps moving.

The practical consequence is smaller than it sounds. For most internal systems and most products, the question that decides your position is not whether a copyright registration would survive a challenge. It is what your agreement with the vendor grants you, and whether the thing runs without them. Those are contractual and technical questions, and both have clear answers today.

What to read in the terms

Whatever tool you are evaluating, these are the clauses that decide what you actually walk away with. They are usually short and rarely hidden — but they are also rarely volunteered.

• What is granted on the output. Does the agreement assign the output to you, or license it to you? A licence can be revoked or made conditional on staying a customer; assignment cannot.
• What happens on termination. Do your rights to what was built survive the contract ending? If the answer is only implied, it is not an answer.
• What they may do with your code and data. Is any of it used to train models, or to improve the service in a way that involves keeping it? A plain statement either way is fine; silence is not.
• What you get on the way out, and when. Data export, database structure, and the application source — in a standard format, on demand, without a support ticket and a wait.
• Whether anything in it only runs there. Proprietary components, a runtime only they operate, or a build step you cannot reproduce. This one is technical, but it belongs on the same list, because it is what turns a good contract into a bad position.

The exit test

One question settles most of this, and you can ask it in a sales call: if we left next Tuesday, what exactly would we take, and what would it take to run it? Vendors who have thought about it answer in specifics. Ones who have not answer in reassurance.

A good answer has four parts, and you should ask to see each one rather than be told about it.

• The source, in a normal shape. An ordinary project in a mainstream framework that a developer who has never met the vendor can open and understand. Ask to look at a real one before you buy.
• The data, in a format something else reads. Not a proprietary archive that only imports back into the same product.
• The database structure, not just the rows. Data without its schema is a large puzzle. Plain SQL for the structure is the thing to ask for.
• A path to somewhere else. What it takes to host the result elsewhere — and whether anything in it is a service only that vendor runs.

It is worth noticing what this test is not about. It is not a plan to leave. Most people asking it stay. It is a way of finding out whether staying will be a choice or a consequence — which is also, incidentally, the strongest thing a supplier can offer you.

Where we stand

Our answers, since it would be strange to publish this and be coy: the application code is yours and it is ordinary code in ordinary frameworks — React, Next.js, Vue, Flutter — that your own developers can read and change. Your data and your database structure export in full, on demand, including as SQL scripts an ordinary database can read. The questions and answers page states all of this in the specific, and Softeria Studio is the product it applies to.

We would rather compete on being worth staying with. That is a commercial position, not a moral one — but it is the one that lets us publish this guide without editing the awkward parts out of it.