Course 8 covered the GPL requirement at the level a free listing needs. This lesson goes further, into the parts that actually trip up commercial developers once real licensing revenue, bundled libraries, and paid add-ons sold outside WordPress.org enter the picture. The rules aren’t ambiguous where WordPress.org states them directly, and they get genuinely nuanced exactly where developers most want a simple answer: what happens to your paid add-on’s license once it leaves the directory.
This lesson assumes you’ve read Course 8’s GPL and licensing coverage already. It doesn’t repeat that ground, it goes past it into bundled dependencies and paid add-ons specifically.
Step 1: What the directory actually requires, precisely
WordPress.org’s detailed plugin guidelines state the requirement directly: everything hosted in the plugin directory, “all code, data, and images,” must comply with the GPL or a GPL-compatible license. GPLv2 or later is strongly recommended, since it’s the license WordPress core itself uses and removes any ambiguity about compatibility with the platform your plugin runs on. This is Guideline 1, and it’s not optional for anything you submit to WordPress.org.
Guideline 2 puts the responsibility for checking this squarely on you, the developer: you have to ensure every file in your plugin complies, “from original source code to images and libraries.” The review team checking your submission is a backstop, not the party responsible for auditing every dependency you bundled. If you vendor a Composer package (the kind of reusable dependency Course 8’s ability-library packaging lesson covered), verifying its license is compatible is your job before you submit, not something you find out from a rejection email.
Step 2: A specific rule that catches developers off guard
Guideline 13 prohibits bundling libraries that WordPress core already ships, jQuery, SimplePie, PHPMailer, and similar. If your plugin needs one of these, it has to use the version already packaged with WordPress rather than shipping its own copy. This isn’t primarily a licensing issue, it’s about avoiding version conflicts and bloat, but it’s exactly the kind of rule a developer used to a non-WordPress PHP or JS stack forgets to check, since bundling your own known-good version of a library feels like the safer default everywhere else.
| What developers do | What the guideline says |
|---|---|
| Bundle a specific jQuery version for consistency | Use the version WordPress core ships; don’t bundle your own |
| Vendor a Composer package under an MIT or similar permissive license | Generally fine, MIT is GPL-compatible, but verify the specific package and its own dependencies, don’t assume |
| Bundle a package under a source-available or “no commercial use” license | Not GPL-compatible; this is a real, common rejection reason |
| Include stock photography or icon packs with restrictive licenses | Images hosted in the directory must also comply with the GPL or a compatible license |
Step 3: Where it gets genuinely nuanced, assets and paid add-ons
Two areas are worth being precise about rather than confidently wrong.
First, bundled non-code assets. The directory’s own language covers “code, data, and images” hosted in the directory, which is a broad standard. In practice, some purely decorative assets (certain CSS purely for visual styling, some fonts) are treated differently in the wider WordPress ecosystem than functional code, but this is a real gray area rather than a clean rule, and the safest position for anything you submit is to verify the license of every bundled asset yourself rather than assume a category of file is exempt.
Second, paid add-ons sold entirely outside WordPress.org. The directory’s GPL requirement applies to what’s hosted in the directory. A separate “Pro” plugin, sold and distributed only through your own site or a service like the ones in Lesson 3, isn’t hosted there and isn’t directly bound by the directory’s licensing rule the way your free listing is. That’s the mechanic Course 8 already described for the freemium-versus-trialware distinction. Where this gets genuinely debated in the WordPress community is whether that Pro add-on’s own PHP and JavaScript are, as a legal matter, a derivative work of WordPress itself (which is GPL) and therefore obligated to be GPL regardless of where it’s sold. This is a real, long-running discussion inside the WordPress project, not a settled point of law with one universally agreed answer, and it’s the reason many established commercial plugin and theme businesses choose to license their PHP and JS as “100% GPL” even for add-ons sold entirely off WordPress.org, while still restricting things like their own trademark, support access, or update delivery through licensing rather than code license.
Selling a paid add-on off WordPress.org changes where the directory’s specific enforcement applies, it doesn’t settle the broader derivative-work question the community still debates. If your business depends heavily on this distinction, get advice specific to your situation rather than assuming either the strictest or the most permissive reading is automatically correct.
Test it
Before submitting anything to WordPress.org, or before finalizing a paid add-on’s license terms, audit every bundled dependency directly rather than assuming.
# List every Composer dependency and its declared license
composer show --format=json | grep -E '"name"|"license"'
# Search for any bundled copy of a library WordPress core already ships
grep -rl "jquery\|simplepie\|phpmailer" --include="*.js" --include="*.php" -i .For every dependency, confirm its declared license against a known GPL-compatibility list rather than assuming a popular package is automatically fine, and confirm nothing matched in the second search unless you’ve verified it’s actually needed and not duplicating a WordPress core library.
Recap
WordPress.org requires all code, data, and images hosted in the directory to comply with the GPL or a GPL-compatible license, and it’s your responsibility, not the review team’s, to verify every bundled file and dependency, including any you vendor from Composer. Bundling libraries WordPress core already ships (jQuery, SimplePie, PHPMailer, and similar) is specifically prohibited regardless of license. Paid add-ons sold entirely outside the directory aren’t directly bound by the directory’s rule, but whether their own code is nonetheless a GPL derivative work is a genuine, ongoing community debate, not a settled question, and it’s worth treating carefully rather than confidently either way.
Resources & further reading
- Detailed Plugin Guidelines, developer.wordpress.org
- Plugin Developer FAQ, developer.wordpress.org
- GNU General Public License, version 2, gnu.org