White-Label WordPress Code Ownership: Who Owns the Code, and How to Avoid Lock-In

Who legally owns the code in a white-label WordPress solution?

Start with the default, because the default is where most agencies actually are.

Copyright belongs to the author. Paying for the work does not move it. In the US, an independent contractor remains the author and owner of software they wrote unless there is a written assignment. UK law arrives at the same place by a different route: the author is first owner, and a transfer needs an express written agreement signed by the owner.

Two jurisdictions, one conclusion. The invoice is not the transfer.

One note before the rest. None of this is legal advice and none of it is tailored to where you work. Rules on commissioned work vary by country, moral rights vary more, and the GPL section further down touches ground that is genuinely argued rather than settled. Use this to know what to ask a lawyer, not instead of asking one.

Why a “work made for hire” clause usually does not transfer your code

This is the one that catches people. The phrase sounds like it does the job.

US copyright law covers two situations with that phrase. Work created by an employee inside their job, which is straightforward. And commissioned work, which qualifies only when it falls into one of nine listed categories and both sides sign a written agreement saying so before the work starts.

Software is not among the nine. It is treated as a literary work, and literary works did not make the list.

Which means a clause reading “all work shall be considered a work made for hire” can be signed, countersigned and filed, and still leave copyright sitting with the developer. The fix is to stop leaning on the doctrine and add an assignment: a present-tense transfer that works whether or not work for hire applies.

If your template says work for hire and nothing else, that is a paragraph to change this week. It is a cheap fix and it only gets more expensive to make later.

What does an IP assignment clause need to say?

Four things.

A present-tense assignment. “Developer hereby assigns” rather than “shall assign.” A promise to assign later is a promise. An assignment is a transfer.

Everything in scope, named. Code, design files, configuration, documentation, and anything else created under the agreement, rather than a gesture at “deliverables.”

A carve-out for pre-existing work, with a licence back. Any serious partner will insist on keeping their own boilerplate, and they are right to. What matters here is the shape of the licence you get in return. Perpetual, so it does not expire with the relationship. Transferable, so it survives you handing the site to somebody else. And scoped to the sites those components are already in, so nobody has to renegotiate per project.

Moral rights handled where they exist. In some jurisdictions these cannot be assigned at all and get waived instead. Ask rather than assume.

Which document the clause belongs in is a separate question, and the NDA, the MSA and the assignment each do a different job.

How do you make sure your client owns the code you promised them?

You sit in the middle of a chain. Your partner builds, you deliver, your client signs with you. Each link transfers something, and you can only pass on what you actually hold.

General advice on code ownership skips this, because it is written for whoever sits at one end. Agencies are the only party in the middle.

So a proposal promising your client full ownership of all deliverables becomes a problem the moment your own partner agreement gives you a licence instead of an assignment. You have committed to something you do not have. Nobody notices for years, and then the client sells the business, or a lawyer reads the file during due diligence, or they ask for everything on their way to a new agency.

Fix the upstream side first, then match the language downstream. If your partner agreement carves out their boilerplate under a licence, your client contract has to describe the same carve-out in the same shape. Otherwise you have quietly promised more than you received, in writing, to the person least likely to forgive it.

What if you have already signed contracts that say work for hire?

Most agencies read something like this with years of signed paperwork behind them and no appetite for reopening any of it. You do not have to reopen all of it.

Sort the backlog by who could actually turn this into a problem. Clients likely to be acquired come first, because due diligence is where unassigned code surfaces and where it gets expensive. Then clients with in-house counsel, who read contracts for sport. Then any partner relationship you can feel cooling, since a retrospective assignment is easy to get while things are friendly and awkward to ask for afterwards.

Everything else can wait for the next renewal, where the clause gets replaced as a matter of course rather than as a negotiation.

The instrument you want is short. An assignment covering all work performed under the relationship, including work completed before the date of signature, because signing one today does not reach backwards on its own. Partners who intended to behave well sign it without comment. The ones who want to discuss it have told you something useful about the next two years.

Why owning the code does not stop vendor lock-in

Settle every clause above and you have won the argument agencies spend their energy on. You have not made yourself able to leave.

Ownership is a question about rights. Lock-in is a question about architecture. They live in different places, and a contract only reaches one of them.

A site you own outright can still be unmovable, because the thing holding you is not the copyright. It is the format the content is stored in, the licence the theme depends on, and a handful of build decisions that make the site legible to exactly one team.

How can I avoid vendor lock-in when using white-label WordPress products?

The real version of this question is narrower than it sounds. You cannot eliminate lock-in. Every tool choice is a commitment, and the useful work is knowing which ones you have made and what each costs to reverse.

How do WordPress page builders lock your content into one format?

Page builders are the biggest one. Almost nobody prices them in.

Page builders do not share a storage format. Each one invents its own. Divi writes shortcodes into `post_content`. Elementor keeps JSON in `postmeta`. Beaver Builder uses serialized PHP arrays. The block editor uses HTML comments inside the post body.

None of them reads another’s output. So switching builders does not migrate your content, it abandons it. The old layout stays in a format the new tool ignores, and somebody rebuilds every page by hand.

Deactivating a builder without replacing it is worse. What remains in the editor is raw shortcode text or an empty post body, depending on which one you used, on a site whose content you own completely.

You can check your position this afternoon. Open a page in the plain text editor and read what is actually stored. If it looks like content, you are portable. If it looks like machine output, the layout belongs to the plugin rather than to you.

That is not an argument against page builders. They earn their place on plenty of projects. It is an argument for knowing the exit cost before a client has two hundred pages.

Which theme and plugin licences stop working when a partner leaves?

Licences bind to accounts, and accounts belong to people.

Three patterns worth checking. A theme framework or premium plugin licensed to your partner’s account, where updates stop when the relationship does. Plugins bundled inside a commercial theme, which usually cannot be licensed separately and expire with the parent. And anything on annual renewal paid by a card you do not control.

None of that is ownership, and none of it is fixed by an assignment. You can own every line of custom code on a site and still be running a theme whose security updates depend on somebody else’s subscription. Put the licences on your own account at the start, or at least know exactly which ones are not.

Does your hosting or multisite setup make a site hard to extract?

Multisite is the common one. A single client site inside a multisite network is not something you copy. Extracting it means separating database tables, reworking upload paths and untangling shared plugin configuration. That is a project, not a migration, and it is rarely in anyone’s budget.

Then the content nobody counts as content. Custom post types and field structures, where the data sits in the database correctly and renders only through one theme’s templates. Move the theme and the content is still there, intact and invisible. That is a quieter version of the page builder problem, and it catches agencies who avoided page builders precisely to stay portable.

Then the quieter dependencies. Host-specific functions called from the theme. A caching layer the code assumes exists. An object cache or search service with no local equivalent. Each one is fine right up until the site has to run somewhere else.

How does GPL licensing affect white-label WordPress code ownership?

Separate what is settled from what is argued. This is where confident writing on the subject usually goes wrong.

Settled: WordPress is GPL-licensed, and the GPL’s obligations are triggered by distribution rather than by use. A plugin built for one client site and never passed to anyone else carries no obligation to publish anything.

WordPress.org’s stated position is that themes and plugins are derivative works of WordPress and inherit the GPL, and the plugin directory is run on that basis.

Argued: whether every theme and plugin is legally a derivative work. There is acknowledged grey area here, and some vendors act on it. Split licensing is the practical result, where the PHP is released under the GPL while CSS, JavaScript and images sit under something more restrictive. Envato built a marketplace on that model and it was contested inside the WordPress community for years.

What this means for an agency is narrower and more useful than the debate itself. Where code carries GPL terms, owning it does not let you stop the person you gave it to from using, changing or passing it on. You hold copyright. You do not hold a veto. If your commercial plan depends on exclusivity over something built on WordPress, settle that before the build rather than after.

The related question of what an NDA can keep confidential once GPL terms apply is answered separately.

How do you get full rights to access and customise white-label WordPress code?

Ownership on paper, access in practice, and permission to act. Three different things, and agreements routinely cover only the first.

Ask for source rather than build output. A compiled stylesheet is not the code. It is what the code produced.

Ask for unobfuscated, unencoded files. Some commercial products ship encoded PHP. That is legal, and it also means you cannot read or change what you are running.

Then ask for the right to modify the work and to hand it to a third party. That is the clause partners quietly leave out, and it is the one that bites when you want a different developer to touch the site. A licence to use is not a licence to change, and a licence to change is not a licence to let somebody else change it.

Can you transfer code ownership when switching white-label WordPress providers?

For what you own outright, yes. Rights you hold under an assignment can be passed on, provided your own agreement permits it, which is why transferability belongs in the clause rather than being left to assumption.

For everything else, no, and the detail matters. Third-party licences move according to the vendor’s rules rather than yours. Components your previous partner licensed to you under a carve-out stay governed by those terms, so read what they say about a successor. And GPL-licensed code does not transfer in the usual sense at all, because the rights it grants were never exclusive to start with.

Getting the files, accounts and credentials to actually move is a separate operational job.

Which white-label WordPress providers give you clear code ownership?

Structural, rather than a list of names. The answer shows up in how a partner already works, not in what they say on a call.

Three questions do most of the work. What is your default, assignment or licence? Do you build on a proprietary framework of your own, and what happens to it if we stop working together? Which licences will sit on our account rather than yours?

A partner who reuses their own libraries is not a problem. Everybody does, and anyone claiming to write every project from scratch is either inexperienced or not being straight with you. What matters is whether the reuse is named, licensed in writing, and survives the relationship.

A good answer sounds boring and arrives immediately, because it was decided years ago and has been given before. A vague answer is a forecast.

Frequently asked questions

What are standard intellectual property clauses in web development agreements?

The usual set is an assignment of the work produced, a carve-out licensing any pre-existing components the developer brought with them, a warranty that the work does not infringe anyone else’s rights, and an indemnity if it turns out to. Standard does not mean suitable, and the carve-out is where the real negotiation happens, because its wording decides what you can do with the site later.

Do I need a lawyer for this, or is a template enough?

A template gets you a sound starting structure, and having a lawyer review it against your actual delivery model costs far less than having one draft from nothing. Spend the money where the money is: the assignment and the pre-existing work carve-out. Both should be checked by someone qualified in your jurisdiction, because that is where the wording varies most.

Who owns the design files, as opposed to the code?

Separate question with a separate answer, and agencies routinely assign the code while forgetting the rest. The editable design source, the logo variations and any stock photography or font licence each have their own terms, and stock and font licences in particular are often non-transferable regardless of what your contract says. List design assets explicitly in the assignment rather than assuming “deliverables” covers them.

Does owning the code mean I can resell it as a product?

Owning the copyright is necessary and not always sufficient. Where the code carries GPL terms, you can sell it, and you cannot stop a buyer passing it on, which changes the business model rather than blocking it. Check too whether any third-party component in the build carries a single-site or non-redistribution licence, since one of those is enough to stop the plan.

Does a premium theme create more lock-in than a custom one?

Not reliably, and the assumption catches people out. Lock-in follows where the content lives rather than what the theme cost, so a premium theme storing content in standard WordPress fields can be more portable than a bespoke one that models everything in custom fields only its own templates can read. Judge it by opening the database rather than by the invoice.