MaxBlogPress and the WordPress Plugin Repository

Filed in Web DevelopmentTags: Geekery, GPL, Plugins, WordPress

Related Plugins

Automatically activate all MaxBlogPress plugins:

Forks of existing MaxBlogPress plugins, with registration/subscription activation removed:

The So-Called WordPress "Ban Hammer"

The latest WordPress-related minor controversy involves the removal of MaxBlogPress plugins from the WordPress plugin repository. The action appears to be in response to numerous complaints and calls for their removal, due to the behavior of the plugins.

The news of the removal of MBP plugins from the WordPress repository first appeared on the Warrior forum (h/t WPKid), and then on WPTavern, the WPTavern forum, and BloggingPro.

The removal took place presumably for violation of the guidelines for hosting a plugin on the WordPress repository:

  1. Your plugin must be GPL Compatible.
  2. The plugin most not do anything illegal, or be morally offensive (that’s subjective, we know).
  3. You have to actually use the subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.
  4. The plugin must not embed external links on the public site (like a "powered by" link) without explicitly asking the user's permission.

The MBP plugins, which offer a range of functionality from basic blog management (Ping Optimizer, Different Posts Per Page, Multi Author Comment Notification, Duplicate Post Checker) to internet-marketing tools (Stripe Ad, Unblockable Popup, Optin Form Adder, SEO Post Link, etc.), exhibit some abnormal behavior for WordPress repository-hosted plugins.

MaxBlogPress Plugin Behavior

All MBP plugins behave as follows:

  • Upon installation of the plugin, a notification message is displayed on the Plugin Management page, indicating that the plugin needs to be registered.
  • The options page, instead of displaying plugin options, first displays a two-part registration form. The first form requires a name and email address.
  • Upon submission of this form, the user receives an email list subscription confirmation email. The user is required to click the link in the email to confirm their subscription. Until the user does so, the plugin options page displays only a message that the email must be responded to.
  • Once the user clicks the link in the email, confirming the double-opt-in of the email list subscription, returning to the options page will, before displaying the plugin options, perform an update check - not through the WordPress SVN that hosts the plugin, but from the MaxBlogPress web site. If an update is available, the plugin updates itself.
  • Only then does the options page (finally) display the plugin options, and enable use of the plugin.

The plugins are problematic in further ways:

  • Not all MBP plugins hosted at the WordPress repository were released under the GPL (or a compatibile license).
  • Some MBP plugins embed external (i.e. public-facing) "powered by MaxBlogPress" links on users' blogs.
  • Many users complained that the email list to which they were forced to subscribe behaved in a "spammy" manner, sending far too many emails (daily or near-daily) with content that only marginally (if at all) had anything to do with the plugin they installed.
  • If you unsubscribe from the email list, existing MBP plugins will continue to work, but if you install any new MBP plugins, you will have to re-register, including re-subscribing to the email list from which you already unsubscribed.

Problems With MBP Plugin Behavior

There are several problems with this behavior for a WordPress repository-hosted plugin:

  • This behavior violates the GPL under which the plugins were released.
  • This behavior uses WordPress repository SVN merely for listing, rather than for hosting.
  • Some have speculated that this behavior may be illegal in some jurisdictions. (Note: this speculation is outside the scope of this blog post.)
  • This behavior violates the guideline against embedding external "powered by" links.
Violates GPL

The GPL defines itself as a free-software license, and defines the term "free software". From the preamble of the GNU GPL v2 [emphasis added]:

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To make this point even more explicit, from the GNU.org website GPL FAQ:

See the definition of free software. The GPL is a free software license...

And from that linked definition of free software [emphasis added]:

The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.

Comparing the behavior of MBP plugins to this definition of "free software":

  • Requiring "registration" or "activation" in order to use an MBP plugin is clearly a violation of this principle.
  • Requiring email-list subscription (forced opt-in) in order to use an MBP plugin is clearly a violation of this principle.

So, compelling the user to register/"activate" software is a violation of the GPL - much less, requiring the user to opt-in to an email list. Such functionality clearly violates the user's freedom of use of the software without being required to communicate about it with the developer or any other specific entity. Thus, as written and distributed by MBP, the plugins in question do not conform to the GPL, which by its own definition is a free software license.

Released Under GPL-Incompatible License

Further, some of the MBP plugins hosted by the WordPress repository were released under licenses that are not compatible with the GPL.

For example, MaxBlogPress Stripe Ad is released under the following license:

MaxBlogPress Stripe Ad Library
End User License Agreement
Copyright (c) 2008, Pawan Agrawal
All rights reserved.

By using the software, you agree to be bound by the terms of this license.

1. You may install and use the software on as many computers and websites/blogs as you wish. You may make back-up copies of the software for archival purposes.

2. You can distribute this software in its original form with any other products or stand alone.

3. You are not allowed to use this script library for creating any other software or plugin without expressed permission from us.

4. The software is protected by the copyright laws of the U.S. and other countries, and we retain all intellectual property rights in the software. You may not separately publish, sell, market, distribute, lend, lease, rent, modify, reverse engineer or sublicense the software code.

5. You must not make any modification to the software without express permission from us. If there is a feature you want included or a bug you want fixed, let us know.

Such a license is clearly incompatible with the GPL, and any plugin released under such a license should never be allowed in the WordPress repository.

Using WordPress SVN to List Rather Than to Host

The MBP plugins circumvent the built-in plugin-update functionality of WordPress, and instead query the MBP web site for updates. Consider the following update function from the Multi Author Comment Notification plugin:


function mcnExtractUpdateData() {
$arr = array();
$version_chk_file = "http://www.maxblogpress.com/plugin-updates/multi-author-comment-notification.php?v=".MCN_VERSION;

The plugin then uses this version check to determine if an update is available, downloads the update, and installs it - entirely circumventing the WordPress repository.

All MBP plugins have this same functionality. Thus, essentially, the plugins are using the WordPress repository merely as a listing site - a means to allow users to search for their plugins (or tags/keywords for their plugins) in order to get more exposure and more users installing their plugins.

Such exposure is intended to be a benefit of hosting a plugin on the WordPress repository, not the sole purpose - which is why the guidelines explicitly state that the repository is for hosting, not merely for listing.

Embedding External "Powered By" Links

But to go even further, some MBP plugins - including Stripe Ad - place a publicly visible "powered by MaxBlogPress" text/link, which explicitly violates WordPress repository guideline #4. And to make matters worse, the author actively seeks to enforce his non-GPL license to prevent users from removing such text from the front end of their blogs:

No it’s NOT licensed under GNU GPL. We are using that format of readme.txt as most people are familiar with that.

It’s illegal to remove the powered by link without notifying me about that.

My Response

While the response from WordPress was the removal of the MBP plugins from the WordPress repository, I decided to respond on my own.

When the news broke, several people suggested that the plugins should be forked, to remove the offending code. I thought that this suggestion would make for a good challenge, so I undertook it.

As it turns out, removing the offending code from the plugins proved to be incredibly easy. Thus, forks of Favicon, Ping Optimizer, Multi Author Comment Notification, and Different Posts Per Page are now available from the WordPress repository.

Further, as pointed out by Blogging Pro (linked above), making the MBP plugins think that they are activated is as easy as updating a single database option for each plugin. It seemed like it would be fairly easy to loop through each plugin's option, and set it to the appropriate value, and I thought that some enterprising plugin author should whip up a plugin to do so.

As it turns out, I ended up being that plugin author (with a great deal of help from my friends at the WPTavern forum). As a result, I have also released cbnet MBP Auto-Activate, which, when installed, will determine which MBP plugins are installed, and automatically activate them, without needing to register or subscribe to the email list. The plugin will auto-activate any MBP plugins subsequently installed, also.

If you use MBP plugins, please let me know if you find any of these plugins to be useful. And if I can improve them, please let me know that, as well.

Feedback

Comments (Comments are closed)

15 Responses to “MaxBlogPress and the WordPress Plugin Repository”
  1. chip_bennett says:

    MaxBlogPress and the WordPress Plugin Repository – http://www.chipbennett.net/wordpress/201

  2. Upon installation of the plugin, a notification message is displayed on the Plugin Management page, indicating that the plugin needs to be registered.

    The newsletter subscription is there to support the free updates, free bug fixes and free support.

    Once the user clicks the link in the email, confirming the double-opt-in of the email list subscription, returning to the options page will, before displaying the plugin options, perform an update check – not through the WordPress SVN that hosts the plugin, but from the MaxBlogPress web site. If an update is available, the plugin updates itself.

    The plugin doesn’t updates itself without users permission. Also, in the past there was no automatic notification and automatic installtion for the plugins. We custom developed such features for the support of our user. Talk about dedication. At that time no other plugin developer had thought in that way. I think we were the only one who provided such easy features to users.

    Later, wordpress built its own wordpress directory and then provided update notification and automatic install to the wordpress users. Those codes are there as it is from the past to be developed further for other features. Our plugins now gets updated by wordpress repository in the same way as other plugin does.

    I haven’t listed some of our plugins in the wordpress repo and they are still being updated using our custom install routine. That’s for user convenince and you should actually praise us for doing such a hard work for creating better user experience for the user.

    Ed. Response:

    You’ve made this same argument in about four different places. The plugin update notification has existed in WordPress core since version 2.3 – over two years. That is plenty of time to clean up your plugins so that they don’t use code they no longer need.

    WordPress.org SVN handles all versioning and update notification, and WordPress core handles all updating. What possible, future features could arise from obsolete plugin update functionality?

    I’ve pulled some two dozen plugins from the WordPress.org repository, and every single one of them had this update code. I have not seen one single MaxBlogPress plugin that didn’t have (and use) this code.

    And finally, I don’t have a problem with you supporting your work though subscriptions to your email newsletter. I have a problem with you forcing users to register and to subscribe to that newsletter after they have downloaded, installed, and activated the plugin. Either make the newsletter subscription opt-in optional at that point, or else require the registration/email subscription as a prerequesite for downloading the plugin in the first place.

    Once users have taken possession of your plugin (i.e. once they have downloaded it), you no longer have any right to compel them to do anything in order to use it – including registering or subscribing to an email newsletter. On the other hand, you are fully within your rights to require registration and/or email newsletter subscription as a condition for downloading the plugin in the first place.

    The difference might seem subtle, but it is critical.

  3. Not all MBP plugins hosted at the WordPress repository were released under the GPL (or a compatibile license).

    Show me which plugins hosted at WP repository are released under license other than GPL.

    Some MBP plugins embed external (i.e. public-facing) “powered by MaxBlogPress” links on users’ blogs.

    There are few plugins hosted at WP repository which have got the “powered by” link. However, user can choose to show it or not by simply choosing the option in the setting page.

    Many users complained that the email list to which they were forced to subscribe behaved in a “spammy” manner, sending far too many emails (daily or near-daily) with content that only marginally (if at all) had anything to do with the plugin they installed.

    There are thousands of subscribers who love the newsletter. However, we also include unsubscribe link in each and every email we send. If someone don’t like our newsletter then they can unsubscribe themselves instantly by clicking on the unsubscribe link.

    If you unsubscribe from the email list, existing MBP plugins will continue to work, but if you install any new MBP plugins, you will have to re-register, including re-subscribing to the email list from which you already unsubscribed.

    Unsubscribe means I shouldn’t use that email again. How can I identify the same user if I have already deleted the record? Also, if someone is coming back to use our other plugins then doesn’t it means we are providing excellent value?

    Ed. Response:

    MaxBlogPress Banner Ads and MaxBlogPress Unblockable Popup were hosted at the WordPress.org repository, and are released under a non-GPL compliant license.

    I didn’t look too deeply into the functionality of Stripe Ad, since when I saw that it was not released under GPL, I didn’t bother trying to do anything with it. Your original stance regarding he public-facing “powered by” link in your plugins was that it was illegal for users to remove it. If you have changed from that original stance, and now give users the option to disable it, then I applaud you.

    You can responsibly maintain a user registration database, that could keep track of which users are subscribed to your newsletter and which users have unsubscribed. Since you are the one forcing the email subscription, you should take responsibility for honoring users’ explicitly stated desires with respect to that email subscription – or, don’t force it on users in the first place.

  4. Requiring “registration” or “activation” in order to use an MBP plugin is clearly a violation of this principle.

    Requiring email-list subscription (forced opt-in) in order to use an MBP plugin is clearly a violation of this principle.

    So, compelling the user to register/”activate” software is a violation of the GPL – much less, requiring the user to opt-in to an email list. Such functionality clearly violates the user’s freedom of use of the software without being required to communicate about it with the developer or any other specific entity. Thus, as written and distributed by MBP, the plugins in question do not conform to the GPL, which by its own definition is a free software license.

    GPL allows developers to distribute the software as per their terms. Developers can choose to make the user pay thousands of dollars for the software or they can distribute it for free. Its there choice. Also, developers can make the software run the way they want. It even includes nag screen and all those crazy stuffs if developers choose to do so.

    But after the user receives the software they are allowed to do whatever they like with the software and run/modify it the way they like.

    Ed. Response:

    Indeed, the GPL allows you to *distribute* your work however you choose. You can charge for the download, require registration to download, etc.

    However, the GPL does *not* allow you to compel the user to do anything to *use* your work, once the user has taken possession of it.

  5. Further, some of the MBP plugins hosted by the WordPress repository were released under licenses that are not compatible with the GPL.

    MaxBlogPress Stripe Ad is not hosted in wordpress repository. Don’t tell that it is hosted there if it’s not. It is hosted in our website not in wordpress repository.

    The plugins which are not hosted in the WordPress repository are not the native wordpress plugins. They were never designed that way.

    They all were developed as a stand alone library. For example: MaxBlogPress Stripe Ad is actually a standalone library which can function in itself. It just requires user interface to work. I can take it and create a web service, or take it and connect it with joomla or connect anywhere by just designing the user interface.

    You can see it as a plugin because we coded an interface to connect this library with the wordpress. The connecting files are already licensed as GPL however the stripe ad itself is released under commercial license.

    Ed. Response:

    Well, technically, there now aren’t *any* MaxBlogPress plugins hosted in the WordPress.org repository. That said, it appears I was mistaken regarding Stripe Ad. I miread another user’s comments, which led me to believe he had downloaded Stripe Ad from the repo. Regardless, the point remains equally valid concerning Unblockable Popup and Banner Ads.

    You have essentially written a GPL plugin that uses (and is bundled with) non-free libraries. If you restrict the right to redistribute those libraries, then your plugin isn’t truly compatible with the GPL. If you resrict the right to modify the the plugin, then your plugin isn’t truly compatible with the GPL. And, that’s exactly what you do. from your license.txt:

    “2. You can distribute this software in its original form with any other products or stand alone.
    3. You are not allowed to use this script library for creating any other software or plugin without expressed permission from us.
    5. You must not make any modification to the software without express permission from us. If there is a feature you want included or a bug you want fixed, let us know.”

    So, the user has the right to re-distribute the original plugin, unmodified – but does *not* have the right to modify the plugin, or to distribute any such modifications.

    Also, the plugins themselves give no indication that they are, in fact, released under GPL. Where one normally finds the GPL notice in the plugin.php file, the following text is found instead:

    “* License: Copyright (c) 2008 Pawan Agrawal. All rights reserved.
    *
    * This plugin uses a commercial script library.
    *
    * Please refer to “license.txt” file located at “include/”
    * for copyright notice and end user license agreement.”

    So, even if you claim that such plugins are released under GPL, the user has absolutely no way of knowing – especially since your other plugins have a very explicit notice that they are released under GPL.

  6. The MBP plugins circumvent the built-in plugin-update functionality of WordPress, and instead query the MBP web site for updates. Consider the following update function from the Multi Author Comment Notification plugin:

    The plugin doesn’t circumvent the built-in plugin-update functionality of WordPress. All the plugins hosted at WordPress gets handled by wordpress repo itself for the updates.

    Those checks are there if we want to notify our users about some critical updates. I think you should praise us about devoting so much time to add such functions in the plugins at our cost for the benefits of the users.

    Ed. Response:

    Again, update notification is already available to *all* WordPress.org repository-hosted plugins. Update notification appears in three places (on the Admin menu under “Plugins”, on the Manage Plugins page, and on the Tools -> Upgrade page). On the Manage Plugins page, the update notice includes text explaining the reason for the update.

    Your update notification appears on your plugin’s options page – where, in all honesty, it is *less* likely to be seen, since most well-configured plugins do not require frequent use of the options page.

    The plugin then uses this version check to determine if an update is available, downloads the update, and installs it – entirely circumventing the WordPress repository.

    Have you seen our plugins downloading the update and installing itself? Show me the proof. It never behaved that way, neither it was designed that way.

    Ed. Response:

    All your plugins check for updates from the following URL: $version_chk_file = "http://www.maxblogpress.com/. If they are installing updates from plugins.svn.wordpress.org, why are they checking for updates at maxblogpress.com?

  7. Chip Bennett says:

    Pawan,

    Thank you for stopping by and offering your viewpoint.

    I have responded to each of your comments in-line.

  8. Ed. Response: You’ve made this same argument in about four different places. The plugin update notification has existed in WordPress core since version 2.3 – over two years. That is plenty of time to clean up your plugins so that they don’t use code they no longer need.

    WordPress.org SVN handles all versioning and update notification, and WordPress core handles all updating. What possible, future features could arise from obsolete plugin update functionality?

    I’ve pulled some two dozen plugins from the WordPress.org repository, and every single one of them had this update code. I have not seen one single MaxBlogPress plugin that didn’t have (and use) this code.

    … and I’ve receiving this same response each and every time. For the last time, let me clarify it more.

    The reason that code was developed was to notify the users about the new version of the plugin we have released and other useful notifications like the launch of our new plugin etc… It doesn’t automatically download and install the plugin without users’s permission as you have claimed in the post.

    Ed. Response:

    I’m not sure that I claimed that the plugin downloaded/installed an updated version on its own, but rather that it circumvented the built-in update functionality.

    Of course, it can automatically download and install the plugin if user wants to and click the update link. Now, since wordpress has similar feature by default, we use that same function for custom notification purpose only. (This feature is not available in the wordpress itself).

    We left the code as it is for further development in the future as we don’t use this feature much and have plan to use those more in the near future. Looking at the code, it might look that it looks for the plugin updates but technically we can use that same code to notify the user about critical updates and other notification without necessarily looking for the updates.

    Ed. Response:

    Again, WordPress core does have built-in notification – and in places that, IMHO, are as useful as they need to be.

  9. And finally, I don’t have a problem with you supporting your work though subscriptions to your email newsletter. I have a problem with you forcing users to register and to subscribe to that newsletter after they have downloaded, installed, and activated the plugin. Either make the newsletter subscription opt-in optional at that point, or else require the registration/email subscription as a prerequesite for downloading the plugin in the first place.

    Once users have taken possession of your plugin (i.e. once they have downloaded it), you no longer have any right to compel them to do anything in order to use it – including registering or subscribing to an email newsletter. On the other hand, you are fully within your rights to require registration and/or email newsletter subscription as a condition for downloading the plugin in the first place.

    The difference might seem subtle, but it is critical.

    I thought deeply on this and now decided to make the optin form optional. We are working on all the plugins to reflect this new change.

    I am glad you acknowledge that the registraion form is critical to support all the free developments we are doing and we don’t imply everything forcefully. Ok, the registration form may seem forceful but I look it as a way of paying in some other medium, which means users must pay in that medium to get access to the plugin. I had also put a way out for the users if they didn’t like my newsletter.

    Anyway, I’m now making the optin form optional so it won’t be problem for the users.

    Ed. Response:

    Pawan, I greatly respect this decision. I think it is the right approach, and will pay dividends with the WordPress community.

    As for the email subscription being a form of “payment” – again, I don’t have an inherent problem with that, provided that the “payment” is up-front (i.e. required before the user downloads the plugin). My issue has always been making that “payment” a use restriction on the plugin after it is already downloaded and installed.

  10. Ed. Response: MaxBlogPress Banner Ads and MaxBlogPress Unblockable Popup were hosted at the WordPress.org repository, and are released under a non-GPL compliant license.

    I didn’t look too deeply into the functionality of Stripe Ad, since when I saw that it was not released under GPL, I didn’t bother trying to do anything with it. Your original stance regarding he public-facing “powered by” link in your plugins was that it was illegal for users to remove it. If you have changed from that original stance, and now give users the option to disable it, then I applaud you.

    You can responsibly maintain a user registration database, that could keep track of which users are subscribed to your newsletter and which users have unsubscribed. Since you are the one forcing the email subscription, you should take responsibility for honoring users’ explicitly stated desires with respect to that email subscription – or, don’t force it on users in the first place.

    Max Banner Ads was never hosted at wordpress repository and it was never released on GPL license. It was designed in the same was as MaxBlogPress Stripe Ad. Max Banners Ads was designed as a stand alone library which can be used in any software platform or with any CMS. We have written just the interface part for the Max Banner Ads so that it can be plugged seamlessly with WordPress.

    Regards, MaxBlogPress Unblockable Popup, it was initially released under commercial license but later I decided to make it GPL and relase it as it is. I checked now and saw that we have forgotten to remove our commercial license notice. That’s a mistake and we have corrected that now. Since, no body complained about that license it slipped out of mind and the license was never got changed. (we can’t be perfect in everything :) )

    Ed. Response:

    Glad to hear that it was just an oversight. Indeed, we all make mistakes!

  11. Ed. Response: Well, technically, there now aren’t *any* MaxBlogPress plugins hosted in the WordPress.org repository. That said, it appears I was mistaken regarding Stripe Ad. I miread another user’s comments, which led me to believe he had downloaded Stripe Ad from the repo. Regardless, the point remains equally valid concerning Unblockable Popup and Banner Ads.

    See my response above for this.

  12. Ed. Response: All your plugins check for updates from the following URL: $version_chk_file = “http://www.maxblogpress.com/. If they are installing updates from plugins.svn.wordpress.org, why are they checking for updates at maxblogpress.com?

    See my response above for why our plugins to do that.

  13. I wanted to post this on the wptavern forum, but there’s moderation for new members so I’m posting here.

    It seems the changes are worthless as wordpress guys don’t want to accept it in anyway.

    This is the email I received from Mark:
    ————————————-
    Hi,
    The plugins will not be relisted.
    There are no changes that can be made, they are not going to be relisted.

    Mark

    ————————————-

  14. Chip Bennett says:

    I wanted to post this on the wptavern forum, but there’s moderation for new members so I’m posting here.

    It seems the changes are worthless as wordpress guys don’t want to accept it in anyway.

    This is the email I received from Mark:
    ————————————-
    Hi,
    The plugins will not be relisted.
    There are no changes that can be made, they are not going to be relisted.

    Mark

    ————————————-

    Pawan,

    I’m very disappointed in that response, and have brought it up for discussion over at WPTavern (here and here). I don’t know that I’ll have any luck getting that decision changed, but for what it’s worth, I think it’s wrong.

    Oh, also: your registration at the Tavern is approved, so feel free to join the conversation! (I think Jeff just uses registration approvals to help combat spam.)

    I hope that you still go through with making the registration/email list subscription optional. I’m sure that, if nothing else, it will help win you some points with the community – even if dealing with the repository will be another matter.

  15. Thank you, Chip for speaking for this.

    I have now lose the interest on getting my plugin in the wordpress plugin repository. I don’t care about it anymore.

    I don’t want the destination of my plugins to be determined by the wordpress repo’s moderator. I’ll promote the plugins on my own and I have also decided to drop the idea of developing more free plugins.

Trackbacks

  1. MaxBlogPress Plugins Removed From WP Repository - Page 4 - WordPress Tavern Forum
  2. Free Your Mind, Not Just Your Software » cb.blog