Making Money With WordPress Plugins – Mixing the GNU License With Others

Aug 8, 2009   //   by Hackadelic   //   WordPress  //  8 Comments

Open Source street signFrom time to time the topic “Mixing GPL software with non-GPL software” crosses my www ways, and I often find there is a lot of misunderstanding about what GPL open source is about (as opposed to other open source software license models). This is not surprising, given that the GPL is probably one of the most complex software licenses around. Time to clarify some fundamentals…

Two typical situations when you start asking yourself questions about GPL-compatibility are these:

A) You happen to simply not like the GPL, so you’d like to select an alternative, less restrictive license. This was the case with me several years ago, and the original inducement for me to dive into GPL’s mysterious ways.

B) You want to implement a commercial extension (i.e. a plugin) for a GPL’ed platform. Now the GPL does not explicitly forbid selling software, but it explicitly guarantees the recipient the right to freely copy and redistribute the software. Hell, you can’t even add an extra clause that restricts its use to non-commercial, because that restriction is not compatible with the GPL.

But are you allowed to make your plugin non-free?

The surprising answer is: Yes you can!

The clue is: The GPL does not restrict usage (if it did, it wouldn’t qualify for a free license). What it does restrict is distribution. You can run GPL and non-GPL1 software together, but you cannot distribute GPL and non-GPL software in one package.2

Ever wondered why some software websites sometimes require you to separately download pre-requisite or additional software, and they say it’s because of licensing issues? Well, this is exactly the reason.

Let’s see what this means to the prospect WordPress plugin author.

It means, as long as you don’t package WordPress with your plugin (and why on earth would you do that?), you can use whatever license you want.

Better yet, the “GPL-ness” of the underlying platform now works in your favor. Whew, how that? Read on…

One of the major “leaks” where WordPress plugins “go” is in websites created by freelance website “developers”, who build a business around quickly putting together a website on top of WordPress and the plethora of plugins around it. (I know mine are used a lot, and I never see a dime for it.)

However, when they compile/develop a WordPress website and give it to their client, they are effectively distributing the code. And that’s where GPL jumps in.

If your plugin is non-GPL1, but the platform is, the platform’s license will prohibit the (obviously illegal) addition of your plugin. Strictly speaking, the only way for the final recipient to use your plugin legally is to purchase a copy from you.

Of course, this doesn’t mean your software will not be bootlegged. But at least it gives you some level of legal foundation to fight back.

If you are interested in details about mixing GPL and  non-GPL1 software, here’s some further reading

  1. For the sake of conciseness I’m using the term “non-GPL software” for software put under a license incompatible with the GPL. [] [] []
  2. You can however put GPL and non-GPL software on the same CD/DVD and distribute the disk. []


  • I know it wasn’t very clear back in 2009 but it’s crystal clear now – plugins actually are derivatives of WordPress and therefore must be licensed under GPL2:

    • It is “crystal clear”???

      Here’s what they say on the site you appointed (emphasis mine):

      There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license.

      So they don’t know whether their position is legal or not, but they feel they are right. And from that you conclude that it is “crystal clear” plugins are derivative, even if they say they don’t know themselves?

      What a ridiculous bunch of propaganda BS.

  • Excellent info. The wordpress codex certainly doesn’t make this clear. they say:

    It is customary to follow the standard header with information about licensing for the Plugin. Most Plugins use the GPL2 license used by WordPress or a license compatible with the GPL2.

    Obviously, they don’t say you cannot use a non-GPL license.

    So, based on what you said, you could create a GPL theme for WordPress, and instead of including the non-GPL plug-ins, you can include a GPL plug in that downloads and installs non-GPL plug-ins. (I don’t know technically if you can activate one plug-in from another but you can at least download it to the plugins directory.) Maybe the GPL version can have a “buy now” button or something.

    Not that I have plans to do that, just a thought.

  • Interesting post, but GNU seems to disagree on the plugin issue:

    On the issue of Web Devs ‘selling’ WordPress, I see it more as the web dev installing and configuring the software for the customer, and then providing the customization code as required. So it’s a combination of labour to install/configure GPL software, and the labour of producing custom code.



    • Paul, I wasn’t talking about “selling”, and definitely not about selling WP. My point was that passing on a plugin or theme a dev has received is, ultimately, distribution, and as such is covered by copyright law. Particularly, the “customization” you mention is a prime example of a “derivative work”, while a newly developed plugin is not. See my recent post, also on the GPL FAQ you referred to.

  • […] Making Money With WordPress Plugins – Mixing the GNU License With Others […]

  • You make a good point, but it doesn’t adress the question of whether plugins are “derivative works”. If they are, they still have to be GPL-licensed even if not distributed together with WordPress.

    • W-Shadow, basically the main (and actually only) argument that a plugin is “derivative work” is that it is calling platform code. IMO that’s a misconception. I just commented on the topic elsewhere, so I’ll simply quote myself here: 🙂

      Calling WP functions is essentially executing code, not deriving from it. You build every software in the context of some knowledge, and in case of WP plugins it is the knowledge about the WP API. That doesn’t mean you derive your plugin’s functionality from that of WordPress. That would be a ridiculous statement, no matter the lines of code. It would mean that interfacing with 3rd party software is “deriving” from it. Or that coding a PDF reader from scratch is work derived from Adobe’s PDF code, just because you rely on the PDF format definition (which IS your interface in that case).

      The point is, plugins are not derivative work (except they are indeed a variation of some WP code, and are not merely interfacing with it), even if they are dependent work.

      I’m not a lawyer though…

Blog Categories

I have come here to chew bubblegum and kick ass...
and I'm all out of bubblegum.
-- Nada in They Live