Much of what is written below has already been covered in interviews ad-nauseum with Matt Mullenweg. And if you’re already ‘pro at GPL’ then there probably isn’t much new you could learn here, unless you’re looking for a refresher course. But for additional insight from a one-man-army developer, read on. You may just learn a thing or two.
When I first got into WordPress development I was admittedly a bit fuzzy on what my rights were when it came to the subject of selling my work online. I had a vague idea that anything I produced under the WordPress framework was ‘public’ or ‘open’ to some degree, but I didn’t know to what extent.
Not everyone who works with WordPress for a living necessarily knows exactly where they stand relative to the GPL, and depending on who you ask you may get varying degrees of opinions on the subject.
To cite an anecdotal example, I once had a developer email me a few years ago demanding that I “hand over a copy” of the Rocket Apps website theme (the original theme that I do not distribute and that I custom designed and built specifically to market my own products) because, he said – and I’m paraphrasing here – “WordPress is open source and you have to give it to me whether you like it or not” – or some misguided reasoning to that effect. While he was laughably misinformed, it still serves to illustrate that not everyone knows what rights the GPL actually affords those who work within the WordPress ecosystem.
I’m sure other developers have similar stories but in case you’re wondering, you absolutely do not have to hand over a copy of your custom WordPress theme or plugin – under certain conditions (more on this subject later).
The General Public License (which WordPress utilises) allows users the freedom to run, study, share, modify or even sell any software that is licensed under the GPL. In the context of WordPress this extends to any software that uses the WordPress framework and APIs in order to function and – this is the key distinction – only if you are distributing said software.
The key here is worth repeating: the GPL only applies to software you plan on distributing.
The basic principle is: the same rights that were afforded to you while developing your WordPress software should be inherited by the people using your WordPress software.
In other words, as you were happy to build your software on top of established GPL licensed WordPress APIs, functions, hooks etc, the same license applies to whatever you were able to derive from it. This is a condition of working with any software licensed under the GPL, not just WordPress.
Absolutely not, but it’s easy to interpret it that way.
As mentioned the GPL affords many freedoms, including the right to sell (distribute) your software to paying customers. But it’s worth keeping in mind that the person who paid money for your software also inherits the right to do exactly the same with it, and neither party can dictate any conditions (aside from keeping a copy of the GPL license with the software).
At this point it’s very easy to form a picture in your head where one person buys a copy of your software and then distributes it to all his friends, and although that’s a legitimate concern and it might feel like piracy, it’s not even close.
So try to think of it this way: When you’re selling your WordPress software you should be selling the value in other areas, instead of just ‘the theme’ or ‘the plugin’. For example, many theme and plugin developers put up a paywall to sell their products and make you enter a license key (which is legit and the GPL is totally cool with it), but in reality what they’re really selling is the support, time and resources that are required to maintain the product for you.
This is something that most customers are willing to pay for because:
- it provides reassurance to know they can get support for the product when they need it
- the product they paid for will continue to work into the future with updates
- they typically don’t have the technical expertise or the budget to roll and maintain their own solution
- they may not trust or have had a good experience with any of the free offerings
This is also why it’s important to make sure your potential customers understand what they are getting for their money, such as ongoing software updates, fast support, access to community forums, documentation etc, and make this known when marketing the product. Most customers probably don’t care (or are even aware) that they can share, modify or sell the software they just purchased from you.
That’s totally up to you. If you want to employ a different license for the CSS, JS, Images, SVGs, documentation, branding or anything else that is your own original work, you are free to do so. Some developers will offer a separate ‘developer license’ (usually paid for) that will give the user the right to include all your original assets when they share your software.
A good real world example of this happened a few years ago, when Sean Lang forked the excellent commercial Migrate DB Pro plugin on Github, and stripped out the licensing code so everyone could have access to all the pro features for free. It would be easy to interpret this as a dick move, but Lang was well within his rights (as is anyone) because even though Migrate DB Pro is a paid-for product, it is still licensed under the GPL. He did, however, have to remove all instances of copyrighted material owned by the plugin developer.
If you’re contracted to build a website for a client on WordPress, in this instance the GPL does not apply. The GPL would only apply if you or your client plan on distributing the software, but this is typically not the case when a client has contracted you to build them something that will only be used in a single instance.
That said, if you handed over the software (website files) to your client and they decided to start distributing it, then the software would become bound by the GPL. This might be worth mentioning to your client if you’re in a situation where you need to hand over the theme or plugin you created to them.
No. If you have other developers working on your software, say in a web development agency scenario or even remotely for example, this does not constitute distribution. The software developer (typically the company or agency producing it) with all its employees and contractors is considered to be a single entity and therefore retains copyright ownership of the code regardless of how many employees it has been distributed to for development purposes.
As mentioned earlier many developers put up a paywall for their products. But you don’t have to do this for all your products. An excellent real-world example of this is WooCommerce, who give access to their core plugin for free (a good strategy for encouraging mass adoption) and only charge for their extensions, premium store themes and support (all of which is optional). But that model doesn’t necessarily agree with everyone and if you’re not comfortable with it, there are other options.
Some developers offer a free ‘lite’ version of their theme or plugin but charge to upgrade to a pro version.
Another (perhaps financially riskier) scenario is to simply give all your software away for free but charge to help customers set it up, customise it, or solve other problems for them.
There are even WordPress developers who don’t produce specific products for sale as such, but instead market themselves as WordPress solutions experts who will build custom theme and plugins for your business needs.
It all depends on what model your comfortable with (and you can change anytime), but the point here is that there are options available that don’t violate the terms of the GPL.
Usually it always does. But if in doubt, ask yourself: Will my code function normally if I take WordPress out of the equation? If the answer is no, then your code is considered WordPress derivative and therefore the GPL applies.
The more you know.