Commercial WordPress Product Descriptions Can Mislead Customers into Purchasing More Licenses Than Necessary

WordPress the open-source software project is licensed under the GPLv2. This license grants users and developers the following freedoms.

  1. The freedom to run the program, for any purpose.
  2. The freedom to study how the program works, and change it so it does your computing as you wish.
  3. The freedom to redistribute copies so you can help your neighbor.
  4. The freedom to distribute copies of your modified versions, giving the community a chance to benefit from your changes.

A number of commercial WordPress themes and plugins have followed WordPress’ lead and are also GPL licensed or compatible. Developers are not allowed to add restrictions to GPL licensed software which is why some product descriptions may be confusing to potential customers.

For example, this GPL licensed product has three different purchase options available. One of the features highlights how many sites the plugin can be used on, or at least that’s the impression.


Further down the same page is information that explains each license gives users access to one year of support and updates. What the text in the image fails to explain is that you’re not limited to using the plugin on a specific number of sites. Rather, those are the number of sites you can apply a license key to in order to receive updates and support.

The wording is misleading and could cause potential customers to purchase the plugin multiple times if they need to use it on more than one site or in this case, three sites.

An excellent example of a product page that eliminates this confusion is the store page for Utility Pro. The license options are clear and tells customers the number of sites they’ll receive support and updates for.


I get pitched to review WordPress products all the time and one of the first things I look for is if it’s GPL licensed. Too often, I come across product descriptions that give me the impression the product can only be used on a certain number of sites. This raises a red flag as it’s a restriction of the product’s use.

To the benefit of potential customers and people like me, I respectfully ask that WordPress developers who sell GPL licensed products review their feature listings and clearly define that people are purchasing support for a specific number of sites. This way, customers know exactly what they’re buying.


39 responses to “Commercial WordPress Product Descriptions Can Mislead Customers into Purchasing More Licenses Than Necessary”

  1. There’s a lot of confusion with licensing and GPL. In some cases the sites limit permission is misleading, but not always. It really depends on the implementation of the licensing enforcement.

    Like with other software license protected WordPress products, when purchasing a premium only plugin or theme via Freemius Checkout, after installing the product the site owner required to enter a valid license key as a gateway to start using the product. This has nothing to do with the GPL. Practically, the plugin/theme is usless for users (not hackers) because the features are locked.

    Therefore, in those cases writing “Use in up to X sites” is actually accurate. Otherwise, the user will install the plugin on the X+1 site and won’t be able to run it.

    There was a discussion about the same multi-site licensing restriction topic on WPChat last year.

    • Yes, I know there is a lot of confusion regarding the GPL but in the specific example above, the wording implies that the customer can only use the product on a specific number of sites or unlimited sites which is a restriction. What those words in the description really mean is how many sites that customer will receive support for. That’s what I want commercial WordPress product developers to focus on. Specifically say how many sites the customer will get support for, not something that says *Can be used on # of sites*. This eliminates one bit of confusion for both people who want to cover a commercial GPL product and customers who know a thing or two about the license.

      Thanks for highlighting this example and for linking to that discussion.

      • What those words in the description really mean is how many sites that customer will receive support for. That’s what I want commercial WordPress product developers to focus on.

        @Jeff what you want is not aligned with what is good for a business :) Personally, I don’t think that binding a license only to support and updates, without any features restrictions is good (for a business). In the end of the day, as a business owner you want to maximize your net revenues (either by more income or less expneses, in that case less support).

        Allowing unlimited installations of your product can only increase support, and obviously you are leaving money on the table.

        1. Support is a rare thing (for a solid product). And even if there’s a support request, the developer will need to have a system in place to recognize if this ticket is related to a licensed site or not. That’s not easy, and require integration between the ticketing system, the licensing system and trusting the user.

        2. If you allow installation on unlimited sites, it practically means that the user can update the product on the licensed site, and then copy the new version to the other unlicensed sites. That’s relatively easy, don’t require code at all, and it’s fast.

  2. I don’t know that it would make it that much clearer. What if the buyer uses the licensed copy on Site A and Site B but they have support for one site.
    If they register the software with Site A, and then they have a problem with Site B, they don’t qualify for support with Site B, since that’s not the one they registered the paid support copy of the product for with the author.
    Is the author supposed to allow the buyer to change the registered site whenever they like so they can get support on every usage instance? Or say no, you’re not allowed to change the site that’s registered, now buy another license if you want support?

    The large majority of people who are confused about how the GPL/GNU/MIT licensing etc are new to WP or new to open source.
    They have a hard enough time trying to figure out what a child theme is and I’m not sure there’s a way to eliminate the confusion that occurs.

    • As long as the product’s site is up front in telling the customer exactly how many sites they receive support for for each license they purchase, then everything else is a moot point. The GPL compliance isn’t in question and customers are better informed in what they’re purchasing.

    • updates are updates and support is support, they should not be confused. There is a point in “selling” automatic upgrades to each site, but support is obviously per human and not per server. So first what is “support” needs to be defined.

      IMO support should fall under a different contract which is not related to licensing.

  3. This is a topic that I have encountered less than a handful of times in the last decade with real customers and real money. They in most cases rarely, if ever, intend to use a theme or plugin on more than one site and those who do have expressed a willingness to pay for additional site support and updates.

    I think this is an issue that is overly-exaggerated as a problem. I sell GPL, buy GPL, and am absolutely thrilled to pay (as a customer) for multi-site licenses, support, help, updates, or whatever other flowery language we’d like to put on our product pages to obscure the fact that as GPL providers we’re in a tough spot.

    I can’t remember having substantive conversations with clients or customers about the GPL, ever, only within the echo chamber. Your gripes might be better suited with how people communicate in English or how well their products’ copywriting is, not with intent.

    In general I think most of us are focused on client acquisition, customer support, revenue streams that will support our businesses, ad spends, and strategy rather than making other people in the WordPress world happy with how we communicate our licensing.

    I love the GPL and absolutely will defend it forever but I care much much much much more about making cool stuff than I do about misleading someone about a license that’s not understood outside of our bubble. Our value proposition has nothing to do with the GPL or site usage. Why would we spend user attention on it?

      • Possibly. Write a style guide if you’d like. Keep in mind there’s a big big big world out there that doesn’t have your English chops. You’re a writer and a VERY good one. You understand nuance. Some developers, especially those who come from other countries or are just terrible readers, don’t.

        Spin up a style guide or proposed language matrix for how you as a customer would like to be communicated to and possibly developers will respond well. I think intent is mostly good, but misunderstood because the focus of a business, mine included, isn’t to spend time fretting over every syllable of our GPL-friendly stance.

    • I gripe about this and will continue to gripe about this, because when someone — intentionally or unintentionally — misleads WordPress users about the rights they have when using WordPress and 100% GPL WordPress derivatives, they weaken WordPress overall.

      If we care enough to embrace the GPL, why is it NBD if we obfuscate the benefits that the GPL provides? If the rights protected by the GPL don’t matter, why WordPress at all? We might as well just send everyone to Wix and SquareSpace.

      • If it’s that important then the Foundation should write a style guide. I would follow it 10000% and encourage others to as well.

        The issue here isn’t obfuscation but literally lack of writing skills and product copywriting. I very much trust that most of us are trying to do the right thing but with no official style guide or strongly recommended language guide we’re going to continue griping.

        From someone who lives in a place where the only English people know is “Hello, how are you?”, I sincerely think this doesn’t get remedied until a top-down style guide gets created.

        • I agree with you in that most people are trying to do the right thing. I’ve contacted a number of people over the years and they changed the wording without any problems after I explained my concerns. I also think the language barrier is a legitimate concern. I don’t know if a style guide is the solution but it probably wouldn’t hurt.

        • I’m working on a better handbook page to help people with GPL vetting; maybe that will help. :) It’ll have negative and positive examples (no direct call-outs), plus terrible hand-drawn illustrations by me!

          In my observation, the language barrier ends up meaning that folks copy license/purchasing language from other people whose work they admire. Thus if the “major players” clarify their terms, it is likely to echo throughout the ecosystem.

        • The term “style guide” seems to be creeping into the Dev world these days—as more and more people are morphing skill sets. I’ve seen the term used improperly, out of context, per numerous fast-growing industries. I come from over 2 decades in the Creative world, where we present Style Guides as visual representations of “style” guidelines to enforce strict compliance of “style” across all forms of media. Style Guides should not be confused with Coding Standards. In the context of GPL, a Style Guide should not be confused with an Ethical Use Policy. Although this may first appear as just semantics… Style, Standards and Policies are not interchangeable. So in terms of the GPL, an Ethical Use Policy would seem more appropriate—alongside a Style Guide :)

      • @Andrea, absolutely this.

        Vietnam is nothing but copy/pasta land. They want foreign customers but don’t know English. So they copy and copy and copy as much language as possible.

        Strong business culture (IMO) usually happens top-down. I’d absolutely support you and every measure the Foundation is taking to fix the language and user confusion issues, especially around the GPL. I’ve been fighting for people to understand it in Vietnam for a long time and glossy eyes happen more than I’d wish.

        I’m with you.

  4. GPL says I can buy a “1 site” license, and use the plugin on 300 sites. That is perfectly allowed under GPL.

    So many authors (themes/plugins) know about GPL yet they chose to ignore this part.

    No, I don’t need to buy the dev/multiple sites license.

    I have paid for plugins many times. specially for clients.

    • the GPL gives you a permission to do whatever you want with the code. A license do not fall in any way under GPL.

      You can code the licensing away from the plugin/theme and distribute it, but I fail to see the point for anyone to put the effort into it.

  5. I’m sorry to say that the situation is worse than you described. It’s not true that descriptions are misleading, they often say the truth, or they are misleading the other way around.
    Take for example MemberPress, one of the most popular membership plugins. If you go to this page it says that in the business edition you have updates and support for one site only plus a staging site. That seems ok, unfortunately without the activation key the plugin’s menu remains hidden and you cannot use the plugin. So they don’t just limit updates, they limit the use of the plugin to one site only.

    This was an example because I am using that plugin right now in a client’s work but there is plenty of plugins out there that do the same thing. This is against GPL license, and it’s becoming a very common practice. I’m not talking a bout a SAAS where this is legitimate, I’m talking about a standalone plugin.

    • There is nothing in the GPL that says this isn’t allowable.

      Because of the freedoms provided by GPL license there is nothing stopping a user from editing the plugin files and bypassing the activation if they wish to do so.

      So no, doing what you describe is not against the GPL.

      The idea that the GPL requires you to make things easy for the user in this regard is a myth. It doesn’t. The code can do whatever you want the code to do as long as the user still has the freedoms provided by the GPL.

      Updates themselves are SaaS. They are also extremely important. I see nothing wrong, from a security and brand protection standpoint, with going this route to make sure the site the plugin is installed on has access to automatic updates.

      If a user purchases the plugin for 1 site and installs it on a 100 sites that means 99 of his sites are not going to have automatic update. Do you think that user is going to keep those 99 sites updated manually? They are not. This means any security vulnerabilities that come up that you then patch via an automatic update are likely not going to be installed in a timely manner on those 99 other sites. Who do you think the user is going to blame in this situation? Himself? Unlikely. He’s going to blame us. And he’s going to do so publicly.

      Having developed and supported one of the most popular commercial plugins in the WordPress ecosystem I can tell you I would prefer someone not use our product if they don’t have automatic update access because of the negative impact it can have on our brand when they do so.

      Deal with a security vulnerability in a popular commercial plugin and then let me know what you think of this scenario. You would have a massively different perspective.

      We do not currently do this, but I see nothing wrong with it. It certainly isn’t against the terms of the GPL.

  6. So, I paid for a plugin or theme, means I have the freedom according to GPL. If that Theme or plugin has renewal and I did not renew, I will be able to keep using it, but won’t get support. What if I need to download again? And when I was looking at WooThemes, I had a lifetime developer account, which was discontinued, I was given 1+1(had to request) of license and just noticed that is expired as well. Now I cant even download the themes I paid for. All I see it says –

    Missing something? Some of your downloads may not show up here, as their subscriptions have expired. You’ll need to renew your subscriptions to get your downloads.

    That’s fine with GPL?

    If you look at WooCommerce extension on their official site, you will see they call is “Subscription” and explains it this way –

    A subscription enables access to the product, updates and support for one year from the date of purchase. Every site installation requires a subscription key.

    You see it adds the words “Product” in it too, not only the updates and support. So, according to your definition GPL gives me right to use it the way I want, I was supposed to be limited for support, license key on given number of site, but WooCommerce even will not let you access the product (which is a plugin for WordPress in this case) as you want.

    How about this? Here I have taken WooThemes just as an example, as they are the biggest business out there on WordPress and owned by Automattic it self so we could certainly take them as ideal scenario.

    • Yes that is perfectly fine by the GPL and is standard practice within the commercial WordPress plugin and theme space.

      The GPL has absolutely nothing to do with access to download the product, access to updates, access to support, or access to SaaS services which the GPL code may interact with.

      It is strictly a license related to the code itself once it is in your possession. It doesn’t mean they have to also provide you with that code via download perpetually.

      You should always keep WordPress, your plugins and your theme updated for security reasons. Because of this you should never use a plugin or theme that you do not have access to updates for. Doing so potentially makes your environment open to security vulnerabilities that have been patched but you no longer have access to. You should always renew your license if you are using a commercial plugin or theme OR stop using the plugin or theme.

      Using a plugin or theme you can’t get updates for is asking for your site to be exploited. Security patches are extremely important when managing a WordPress site.

      The GPL doesn’t grant you access to these updates. That’s what you pay for (and renew) when purchasing a plugin or theme. The GPL is a code license and nothing more.

    • Ah yes, Woo did that to us BEFORE our licenses had expired recently and while we were lucky and an employee ran across my comments in a FB group, other people shared stories of the same happening and being unable to get a current copy of the plugin before their expiry.

      While they did capitulate and place the “missing” file in our admin for download before the expiration, we determined that since we were already revamping our marketing funnel, we could drop Woo and run all of our sales directly through Gravity and continue to offer subscription based services.

      One of my partners and myself have been involved in subscription based online models since ’98, so we understand how the models work ;)

    • Hi Matt,

      Thanks we’ll certainly review our wording.

      We are in a unique position where we will support any user who uses Layers, regardless if they use Layers Pro, a 3rd party theme or extension, so we cannot guarantee that support would be limited, in fact we would never limit support.

      When we sold Layer Pro on Envato, regardless of what GPL says, advanced users felt (perhaps by good will) obliged to purchase “1 copy at a time”, therefore it was by popular demand which brought us to the decision to introduce more license options, as users felt that paying $35 every time they wanted to use Layers Pro on a site was not viable.

      I think it’s also important to note that users who are buying multi-domain are advanced users and often times choose to pay more for higher usage regardless if there are limitations or not.

      • Thanks Marc for responding and to Matt for bringing up another good example, I’m glad I’m not the only one who caught it.

        While the licensing page does a good job explaining the GPL and the freedoms it allows, there are a couple of things that are suspect.

        You can fork Layers, create a modified derivative (it must be 20% unique)

        Who says the code has to be 20% unique for it to be a derivative? What makes a product derivative is subjective to everyone as there hasn’t been a court case that proves otherwise.

        Layers may be included on a WordPress Multisite implementation where you charge for themes or a service built on Layers. However, it must be under the terms of the GPL license. Therefore, you must make the source code available to the users of the program as described in the GPL, and they must be allowed to redistribute and modify it as described in the GPL.

        If I take Layers which is GPL Licensed and make it a part of a service offering to customers without any distribution occurring, then the GPL doesn’t apply. The GPL is only transferred to customers if distribution occurs.

        Layers Pro has special licensing that governs resale, access to updates and support. If you plan to resell Layers Pro as part of a platform, service or theme/extension, you must acquire a developer license to do so. This license grants you the necessary copyright transfers to support the redistribution rules put forth by the GPL.

        This sounds to me like you’re saying Layers Pro is GPL licensed but I can’t resell it unless I purchase a developer license. The GPL doesn’t say I need to purchase a developer license to resell someone’s code. The redistribution rules of the GPL don’t require money to be transferred.

        When it comes to the GPL license, less is more.

        I’m not a lawyer, I’m not even a license expert but I have written about the GPL License extensively over the years and some of the wording in this document is on the borderline of being restrictive or at the very least, inaccurate.

  7. Jeff, good points, and as some of the comments indicate, a good topic for discussion and clarification.

    For the most part whenever I’ve asked about license and use I’ve found WordPress vendors to be very transparent. They want you to understand what you are paying for so that expectations are clear. The only time I ever got an evasive reply was from a company whose plugin was not GPL.

    Carl’s comments about the importance of updates is an important point. While you can install on as many sites are you want, you need to consider if you want to take on the extra responsibility of keeping things updated without the automated convenience or access to the vendor’s changes. Some people have the time and attention for that, but many do not.

  8. Always read the terms provided with plugins and themes carefully. They may not be entirely covered by the GPL.

    In particular plugins are expected to offer GPL terms for the html and php code but are not obligated to provide the CSS, images and Javascript under GPL terms. See the following article.

    An example of this would be the S2MemberPro plugin. See the S2MemberPro terms.

    Another example would be any theme or plug-in purchased through Envato where the author-provided license does not extend GPL cover to all the provided files. The Envato default license considers the CSS, JavaScript and images to NOT be covered by GPL unless the author-provided license says otherwise. See license terms and split license terms.

    I am a supporter of Jeff’s proposal for theme / plug-in authors to clearly state what their GPL license covers. In particular whether the GPL license applies to ALL the supplied files including css, images and JavaScript.

  9. The author was modest enough to omit the name of the plugin cited as an example of poor licensing terms, but I’m not, Gravity Forms is a very popular plugin with excellent support, and it’s GPL licensed.

    A side note, I’ve often times been shocked at how little the typical WordPress professional knows about the GPL. Usually when I post in Facebook groups or in comments sections that it’s legal and praiseworthy to share whichever premium theme or plugin under discussion, I’m met with gaping mouths.

    • Sharing is great, but in situations where the code is used on a production web site and the admin of the sites does not have access to software updates for a commercial plugin they are using that is a recipe for a security nightmare.

      So while the GPL allows code to be shared like this it doesn’t mean that using that code in a production environment is prudent from a site administration standpoint unless you have access to software updates.

      From a security standpoint along, above everything else, you should purchase any commercial plugins you utilize and make sure you keep them updated when updates are released.

  10. What about the “Woocommerce Url Cleanner”? It states:

    1 site, unlimited servers

    No distribution (hosted use only)

    Oh wait, there’s the 689$ Plan:

    “Can distribute code and binary products”

  11. How can this even be hard to understand? Thousands of OSS projects thrive under the terms of GPL without muddying the waters.

    Those plugin devs here who justify your lying licensing practices, how do you sleep at night? Or are you just willfully ignorant?

    As someone who’s been involved with FLOSS for over 15 years, it appears a great number of WP plugin devs to be disingenuous opportunists who prey on the lack of knowledge of end users.

    The WordPress org. needs to clean up this mess. Start by only allowing free plugins on and then enforce punitive measures towards companies that deliberately misinform.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: