Copy a standard "all rights reserved, no redistribution, no reverse engineering" EULA onto a commercial WordPress plugin or theme, and part of it will not survive contact with reality. WordPress itself is licensed under the GPL, and any PHP code that hooks into WordPress's own functions is, by WordPress.org's own stated position, a derivative work that inherits that license. A EULA that tries to lock down that code the way it would lock down a standalone desktop application is either unenforceable for that part, or a direct conflict with the license terms the code already carries. The fix commercial WordPress vendors have settled on is not skipping a EULA. It is splitting one: the functional code stays GPL, and the EULA governs everything around it that legitimately is not.
Why WordPress code cannot be locked down like normal software
WordPress core ships under the GPLv2, or later, and the WordPress.org plugin and theme directories require every listed plugin to be "compatible with the GNU General Public License v2, or any later version," accomplished either by an unmodified GPL statement, a GPL-compatible license, or a public domain release. That is not a suggestion for hosted plugins, it is a listing requirement. Themes hosted on WordPress.org go further still, requiring the bundled resources that make up the design itself to carry a GPL-compatible license too, not just the PHP.
The underlying reasoning, which WordPress.org and the Free Software Foundation both hold and which the broader WordPress ecosystem has followed for close to two decades, is that PHP code calling WordPress's own GPL-licensed functions and hooks is a derivative work of WordPress, and a derivative work of GPL code has to carry the GPL forward. Practically, this means once someone has legitimately obtained a copy of your plugin's PHP files, the GPL already grants them the right to run, study, modify, and redistribute that code, including a modified copy, and a EULA clause saying "you may not copy, modify, or redistribute this software" cannot take that right back for the parts of the codebase the GPL actually covers.
What is actually GPL, and what is not
The mistake is not writing a EULA for a WordPress product. It is writing one that treats the whole download as a single, uniformly proprietary bundle. A typical premium plugin or theme is not one thing, it is several things zipped together, and they do not all carry the same license.
The PHP that runs your plugin's logic, registers your custom post types, or builds your theme's template hierarchy sits squarely in the derivative-work category and needs to stay GPL or GPL-compatible, whether or not you distribute through WordPress.org. Original creative assets that do not call any WordPress function, a set of custom icons, a bundled font, stock photography, a Figma-designed demo layout exported as static images, are a different matter. Nothing about the GPL requires an unrelated image file to be free just because it ships in the same zip archive as GPL code, and this is the gap a split-licensing EULA is built to occupy.
GPL code vs proprietary bundled assets
| GPL PHP code | Proprietary assets | |
|---|---|---|
| Covers | Plugin/theme logic, hooks, templates | Images, fonts, icon sets, demo content |
| License | GPLv2 or later, or GPL-compatible | Your own commercial license terms |
| Buyer can redistribute it | Yes, the GPL already grants this | No, unless your EULA says otherwise |
| Buyer can modify and resell it | Yes, for the code itself | No, without a separate license |
| What your EULA can restrict | Little to nothing | Copying, resale, redistribution |
What a EULA can still legitimately restrict
None of this means a commercial WordPress product is stuck giving everything away. Three things remain genuinely restrictable, and a well-scoped EULA earns its keep by covering exactly these instead of overreaching into the GPL code.
Bundled non-code assets are the clearest case. A custom icon set, a library of stock photography licensed for your use only, a set of premium web fonts, or a polished demo-content package are original creative works with no WordPress function calls in them, so nothing about the GPL touches them. Your EULA can say a buyer may use these assets on the sites their license covers and may not extract, resell, or redistribute them separately, the same way a stock photo license or a font license would.
Updates, support, and the license-key gate are a service relationship, not a copyright question, so they sit outside the GPL argument entirely. Your EULA can condition access to automatic updates, priority support, and premium add-ons on an active license key tied to a specific number of sites, and can state plainly that the key is not transferable and that support is not owed once a license lapses. A buyer who forks the GPL code they legitimately obtained still is not entitled to your update server or your support inbox, those are things you provide, not things the GPL grants.
Your product name, logo, and brand are governed by trademark, not copyright, so they sit outside this whole discussion. A EULA can require that a redistributed or modified copy of the GPL code drop your product's branding, even though it cannot stop the redistribution of the code itself.
- You may not copy, modify, reverse engineer, or redistribute this software in whole or in part.
- Applied to the entire plugin download, PHP included.
- Plugin PHP code is licensed GPLv2 or later; you may copy, modify, and redistribute it freely.
- Bundled icons, fonts, and demo content are licensed for your sites only, no redistribution.
Writing the license grant clause
The clause that most commercial WordPress EULAs get wrong is the license grant itself, because it is usually copied from a template written for installed desktop software, where "all rights reserved except what we explicitly grant you" is the correct default. For a WordPress product, that default is backward for the code portion. Instead of granting rights the buyer already has under the GPL, state plainly which parts of the download are GPL, point to the license itself rather than restating it, and then write your actual restrictions around the parts that are genuinely yours to restrict.
A workable structure separates the download into two labeled parts early in the document: the plugin or theme's functional code, identified as licensed under the GPLv2 or later, with a short note that nothing in the rest of the agreement limits the rights that license already grants; and everything else, the bundled assets, described specifically enough that a buyer can tell what is covered, licensed for use on the number of sites their plan allows, with copying and resale restricted the normal way. Naming the split explicitly, rather than leaving a buyer to guess which restrictions apply to which files, is what keeps the document from contradicting itself the first time anyone reads it closely.
Where you sell it changes what is required, not what is true
Selling through the WordPress.org directory makes the GPL-compatible requirement a listing rule enforced by the Plugin Review Team, not just a licensing argument, so there is no version of "GPL for the code, all rights reserved for everything" that survives review there if the restriction touches PHP. Selling outside the directory, through your own site or a marketplace like Envato's ThemeForest, removes that enforcement mechanism, but it does not remove the underlying license position. Marketplaces built specifically for premium WordPress products, ThemeForest is the largest example, have their own split-license structure for exactly this reason: the PHP and any WordPress-derivative code is GPL, and a separate marketplace license (Envato's own regular or extended license terms) covers the images, fonts, and other non-code components bundled with the item. A EULA you write for a product sold on your own site is free to use different specific language, but it should land on the same underlying split rather than trying to route around it.
Building this without guessing at the split
The hard part of this document is rarely the prose, it is correctly sorting your own product's files into the GPL bucket and the proprietary bucket before you write a word of license language, since a EULA that gets that sort wrong is either unenforceable where it overreaches or accidentally gives away something you meant to protect. Once that sort is done, walk the same checklist as any software license: state the license source for the code plainly, describe the proprietary assets specifically enough to be enforceable, scope your restrictions to updates, support, and those assets, and keep your trademark terms separate from both.
Our EULA Generator builds a license agreement you can adapt to this split, license-grant language for the parts you actually control, seat and redistribution limits scoped to bundled assets rather than GPL code, and standard update and support terms, so the document matches how WordPress licensing actually works instead of reading like it was written for a different kind of software entirely.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
