You typed the brief. The AI wrote the HTML. Your client signed off the content. Now someone in procurement is asking who actually owns the course, and you are realising you never thought about it.
Welcome to the IP question that the vibe coding community has been quietly avoiding.
What the tools tell you
If you have built HTML learning content in Lovable, v0, Cursor, or Claude, you will have noticed that the terms of service are reassuringly simple. Lovable says you own the output, no royalties, no attribution required. Cursor says it will not use your content to train its models without permission. The message across the board is: it is your code, do what you like with it.
That is what the vendors say. Copyright law says something different.
What copyright law actually says
The US Copyright Office set out its position in January 2025: prompts alone do not give you sufficient human authorship over AI output to make it copyrightable. The reasoning is that when you type a prompt, you are giving an instruction, and instructions convey ideas, and ideas are not copyrightable. The resulting code is the AI's expression of your idea, not yours.
This is not a fringe position. Courts have rejected AI authorship at every level, and as of early 2026 no jurisdiction recognises AI as capable of holding copyright. The UK, EU, and Australia are all working from variations of the same principle: copyright requires a human author.
So the gap is this. The vendor says you own the output. Copyright law says the output may not be ownable by anyone. You are sitting in the middle with a course you built, a client who paid for it, and protection that may be thinner than you assumed.
Does this actually matter for eLearning?
It depends on what you are worried about.
If you are worried about someone copying your course wholesale and selling it, the weak copyright position is a real problem. You would struggle to enforce a claim based on AI-generated HTML, particularly the structural and visual elements that the AI produced. The written content, scenarios, and assessment questions are a different matter if you wrote those yourself, but the scaffold the AI built around them is harder to protect.
If you are worried about your client owning what you made, the answer is mostly: they probably do not own the code any more than you do, unless your contract says they do. But that is not reassuring, it is just a different kind of uncertainty.
If you are worried about using elements across client projects, reusing AI-generated structural code you wrote once and have been adapting ever since, the weak copyright position actually works in your favour. Nobody owns it, so nobody can stop you using it.
What you can do about it
The most practical protection for vibe coded content is to document your human contributions. That means keeping records of your prompt strategy, your structural decisions, the content you wrote yourself, the edits you made to the AI output. The Copyright Office position is that human creative contribution earns protection. The more clearly you can show what you contributed, the stronger your position.
For client contracts, the honest move is to address IP explicitly before you start. Something like: the HTML structure is AI-generated and sits in a legal grey area. The course content, scripts, assessments, and any bespoke assets I create are owned by you on delivery. The underlying code scaffold may not be ownable by either party. Clients who have thought about this at all will respect the clarity. Clients who have not will appreciate knowing before there is a dispute.
Trade secrets are worth understanding too. If your value is not in the code itself but in your workflow, your prompting approach, your quality process, that can be protected as a trade secret without needing copyright to attach. It just has to stay confidential.
The training data question
One more thing that comes up. If the AI was trained on copyrighted code, does that taint the output?
The short answer as of mid-2026 is: probably not, for most practical purposes. The landmark cases in 2025 gave AI companies their first major wins on training data fair use, and the courts have generally treated AI output as sufficiently transformed from its training data to stand separately. This is still being litigated and the picture will keep shifting, but for HTML learning content built on mainstream tools, training data contamination is not the most pressing concern.
The ownership gap is.
What to do next
Three things worth doing this week.
Read your vendor's terms of service properly, not the summary. Understand what they claim and what they waive. Most are reasonable, but the details matter.
Look at your current client contracts and check whether IP ownership is addressed at all. If it is not, add a clause. If it is, check whether it contemplates AI-generated elements or was written in an era when that was not a question.
Start documenting your contributions. Not for a lawsuit you might never have, but because the habit of being clear about what you created is a good one regardless of the legal landscape.
The law will catch up. Until it does, the people who have thought about this in advance will be in a better position than the people who have not.
Written by Michael at Digital Technology Training. If you are building HTML learning content that needs to reach an LMS, the AI Learning Packager wraps it as SCORM without touching an authoring tool.