The Pricey GPL Thought Experiment

Let’s create the most expensive GPL licensed WordPress plugin and call it the Pricey GPL. It is offered as a free download from WordPress.org and by default it displays a random paragraph from the most downloaded book at Project Gutenberg in the WordPress dashboard. Of course, there is a widget available, too.

However, to enjoy the real value of the Pricey GPL, you have to purchase a monthly subscription to the PriceyGPL.com service (an API key) which displays a random paragraph from one of the GPL licenses.

Questions

  1. Can software released under GPL be pricey or does it have to be a service or a subscription tied to it which can be pricey?
  2. How are these two ways of pricing different from the users’ viewpoint whose rights the GPL is protecting?

Use Contact Form 7 to collect business leads and enquiries? I created Storage for Contact Form 7 plugin which stores them safely in WordPress database.

Get it now for only $19 →

11 Comments

  1. Andrew says:

    Releasing a GPL plugin that interfaces with a paid service is entirely within the spirit of the GPL in my opinion. The plugin user has the option to rewrite it to use the information it gets in another way, that is their right, but there is no reason why they need access to the data or the code that underlies the web service.

    Or am I misunderstanding the question?

    • Kaspars says:

      I completely agree with you on that, Andrew.

      Let’s say we have this plugin that must interact with an API to be fully functional. We want to monetize it, so we can either (a) charge for the plugin (download) and give the API access for free, or (b) give the plugin away for free and charge for the API key.

      Is either of the option more in line with GPL or are they exactly the same from the users’ perspective?

  2. Andrew says:

    One is clearly more in line with the GPL.

    You can’t sell code that already exists, you can only sell a license to use it. If it is under GPL you have already made the licensing choice so you can pretend to offer useage licenses but they are uninforcable because the GPL prevents you from creating those restrictions.

    On the other hand, charging for a web service is actually making a charge for providing something. It is on your server, it is doing processing of information on demand, there are running costs involved. It makes sense to charge for that.

    Finally, even if all the code on your web service is GPL, it doesn’t matter. You don’t have to give the code away and nothing stops you charging for or restricting access to the information that results from running the code.

    (In my opinion :-) )

  3. Andrew says:

    The big difference between the two from a user perspective is that, in one you are trying to restrict their rights to use the plugin code, perhaps to access someone elses API or present the information differently, in the other you are letting them do what they want.

    Even though they technically have that right in either case.

  4. Kaspars says:

    You can’t sell code that already exists, you can only sell a license to use it.

    In case of GPL it would mean selling users their freedom to use the software, because that is the only thing GPL license protects, right?

    Therefore, I think that the only thing I can sell is the access to my version of the software, isn’t it? Once they buy it, it becomes their version with all the attached freedoms of GPL. It would be the access that I charge for, not the code.

    On the other hand, charging for a web service is actually making a charge for providing something.

    So I can’t charge for my work and time improving my copy and giving it away, but I can charge for a service that is, in a way, exclusive and proprietary?

    I still fail to understand how charging for a service is better.

  5. Andrew says:

    I think your conclusion is correct. You can only sell access to your version. That might include distribution, postage, etc, bandwidth costs if it is on your server, but if you assign it a GPL license you are assigning freedoms that then stop you charging for anything else.

    The problem you have here is that you are confusing recouping costs you have voluntarily incurred (time and effort) with being paid for your time. You cannot be paid for your time and effort without agreeing beforehand that the customer will pay for that.

    For example, if I ask you to build me something you can charge me an amount per hour for the time it takes you. If you create it first and then try and sell me something you are trying to recoup your costs by selling me the product, but I am paying for the product, not your time.

    If you have chosen to give me the freedom to do what I want with that product, once I have it, it is mine. I can give it to everyone else for free. That doesn’t stop you charging for access to your version, you just have to hope that no one figures out they can get it from me.

    Charging for the service isn’t better for the user. But it doesn’t contradict anything in the GPL. They are still paying for access but they are paying for something where you can control that access without contradicting the license.

    The best thing for the user is for you to GPL the plugin and offer the API for free because they can then get your plugin from another source, pay nothing, and use the API for nothing. It would suck for you though.

  6. Andrew says:

    Or am I misunderstanding what you mean by ‘better’?

    Are you fundamentally questioning the benefit of GPL for all users in the long run?

  7. Kaspars says:

    Andrew, you understood and answered my questions perfectly, thank you.

    You cannot be paid for your time and effort without agreeing beforehand that the customer will pay for that.

    But I need to create a product before I can sell it. In fact, every product is created in hopes of recouping the costs only after it has gone on sale.

    Or are you saying that my time spent working on a GPL plugin doesn’t qualify as work for which I can charge (indirectly) by applying a price to the resulting product? Does it even matter if I am charging for my work or for hosting the API?

    I am trying to figure out a way to generate revenue from WordPress plugins or themes which doesn’t limit the access to the product and at the same time gives reason to pay for it. Here is what I have come up with, so far:

    1. Release a plugin and charge users $10 for downloading it.
    2. Make the source code available freely through an SVN repository, so that those who know how to use it and are most likely to improve or help fix it can use it for free.
    3. Charge $5 for any update that adds new features while bug fix and security releases are free for everyone.

    If someone decides to fork the plugin and upload it to the WordPress repository everytime there is a new update, they are free to do it and I wouldn’t mind. I would still remain the trustworthy source of the original.

    This way the whole community could enjoy the continued development of the plugin while the contributing users would receive certain percentage of the revenue generated by that particular update.

    I don’t see any downside of this approach.

    p.s. I am no thinking about ways have maximum profits. I am only looking for alternatives to the donation model.

  8. Andrew says:

    My point about charging for time and effort was really that there are two models. The service model where you agree to provide something for a price and then provide it, and the product model where you produce something and then ask someone if they want one.

    In the first you can charge based on time irrespective of the value, in the second you need to factor in your development costs in the sale price then figure out if you can sell enough at the necessary price to make a return. If you can’t then all your time and effort does indeed go unrewarded.

    What you have come up with seems entirely reasonable. Anyone who wants the code can get it and end users pay for your product.

    The downside is that your entire model relies on trust. There are a number of whatifs that kill your revenue stream:

    First: what if someone forks it, releases it, and promotes it better than you? You seem like the untrusted copy instead of the original.

    Second: What if WordPress 3.0 has your code added to it?

    Of course, licensing doesn’t prevent this, it just means you can have your day in court, if you can afford it, to try and reclaim revenue, but GPL makes it easy to happen. That is why the premium themers are promoting support services so heavily.

    There are people who already successfully charge for plugins and they do it by just not putting it on wp.org. In effect they sell to people who sell it on to end users and it never goes any further so it is entirely feasible as long as the target market is right.

  9. Chip Bennett says:

    Either option is valid under the terms of the GPL, which only stipulates that if the work is conveyed, it must be done so under the GPL (or compatible) license and source code must be made available upon request. Both of those requirements can be met, whether the work is sold (cost to download) or connected to a service (cost for subscription).

  10. watt says:

    Stop obsessing about charging for plugin code. Give plugin code away as GPL, this will be your marketing. (People can see that plugin code is clean, is not harmful to run, that plugin is safe to use.)

    Charge for [optional, but essential] access to your servers (API). End of story.

    And yes, if plugin is GPL, and somebody provides a patch (bugfix or feature), that’s a net benefit for you.

Leave a Reply