Auditing WordPress Plugins for License Information

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

The wordpress.org Plugin Repository requires adherence to a few simple guidelines in order for plugin authors to have their plugins hosted there:

  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.

Lately, however, those guidelines have apparently been interpreted somewhat more strictly (emphasis added):

(13:27:03) KnxDT: By the way: Is the GPL header necesary?
(13:27:18) markr: very.
(13:27:28) KnxDT: because WP didn't mention in the standar readme.txt
(13:27:37) markr: Ideally you would include the gpl in a gpl.txt file
(13:27:57) markr: not including the declaration will get it removed
(13:28:10) markr: users have to know what they can do if they wish

I find the assertion that not including explicit license information with a plugin would result in the plugin being removed from the repository to be at odds with the current state of plugins in the repository. To confirm my suspicion that a significant number of plugins hosted at the wordpress.org Plugin Repository did not conform to this requirement, I did a quick audit of both my own installed plugins, and the current Top Ten Most Popular plugins in the repository. I posted my findings in the WPTavern forum. In short:

  • Almost 2/3 of the plugins I personally have installed don't have GPL information in the plugin
  • 2 of the Top Ten most popular plugins at Extend don't have GPL information in the plugin
  • 1 of the Top Ten most popular plugins at Extend violates the requirement that the entire plugin be distributed under a GPL-compatible license

Based on these findings, I decided to audit a few well-known and influential plugin authors - not to pick on the more high-profile developers per se, but rather to determine the state of license inclusion in plugins developed by those who, ideally, should be leading by example.

Here's what I found:

Matt Mullenweg

Plugins:
Notes:
  • bbPress was originally a stand-alone script, that included a license.txt file.
  • SyntaxHilighter Plus was written by Viper007Bond, but credited to Matt.
  • Top Comments was written by Andrew Ozz.
  • Sympathy For The Devil was written by Jeff Schult
Summary:

(0/19) of Matt Mullenweg's plugins written as a plugin and maintained by him have license notice of some kind. Shockingly, the majority of Matt's plugins lack even a readme.txt file.

Mark Jaquith

Plugins:
Summary:

(13/21) of Mark Jaquith's plugins have license notice of some kind (including one with both a license.txt file and plugin header license notice).

Ozh

Plugins:
Summary:

(0/16) of Ozh' plugins have license notice of some kind.

Peter Westwood (westi)

Plugins:
Summary:

(4/9) of Westi's plugins have license notice of some kind (including one with both a license.txt file and plugin header license notice).

Viper007Bond

Plugins:
Notes:
  • SyntaxHighlighter Evolved includes license.txt file from original SyntaxHighlighter written by Andrew Ozz
  • SyntaxHighlighter Plus includes license.txt file from original SyntaxHighlighter by Alex Gorgatchev
Summary:

(11/33) of Viper007Bond's plugins have license notice of some kind.

Overall Summary

Overall, for the plugin authors listed, only 28 out of 107 plugins (26%) have license notice of some kind (including two plugins that have both a license.txt file and a plugin header license notice). And the number is only that high thanks to Mark Jaquith, without whom the percentage of plugins with license notice of some kind would drop to less than 18%. Only 2 out of 107 plugins (<2%) include both a license.txt file and license information in the plugin header.

I find these numbers to be downright shocking, considering the unwritten rule now being enforced regarding removal from the repository of plugins that lack license disclosure, as well as the assertion that plugins should "ideally" include a license.txt file.

Let me be clear: I fully support the effort to ensure that plugin authors explicitly disclose license information in their plugins, either in the plugin header or in a separate license.txt file. The assertion that users need to be given explicit explanation of their rights to use, modify, and distribute plugins.

That said, perhaps those in the WordPress project leadership, and the plugin developers whom others look up to, should ensure that they are leading by example before a more-strict interpretation of the Plugin Repository guidelines is enforced against plugin developers at large.

Further, since new plugin developers will likely refer to the official wordpress.org Plugin Repository Readme File standard (which currently is silent on the matter of license disclosure) when determining what information needs to be included with their plugins, I would recommend that the standard be modified to include a License section - perhaps something like such:

== License ==

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

This way, new plugin authors would have a standard means of disclosing license information in their plugin - and also, users searching Extend for new plugins would have a known means of determining the license of any given plugin.

What are your thoughts?

Feedback

Comments (Comments are closed)

30 Responses to “Auditing WordPress Plugins for License Information”
  1. chip_bennett says:

    Auditing WordPress Plugins for License Information – http://www.chipbennett.net/wordpress/201

  2. chip_bennett says:

    Only 26% of plugins by @photomatt, @markjaquith, @westi, @ozh, @Viper007bond in #wordpress .org repo disclose license http://www.chipbennett.net/wordpress/201

  3. Interesting.

    I wonder if a Licence: GPL2 style header might be a better solution.

  4. Chip Bennett says:

    @Peter Westwood

    I think that would be a great solution, too – and it fits with what I currently do.

    What I do right now is put the following in the plugin header:

    * License: GNU General Public License, v2 (or newer)
    * License URI: http://www.gnu.org/licenses/old-licenses/gpl-2.0.htm

  5. Brad says:

    To be honest I never include a license.txt file with my plugins. I try to always include a plugin header license, but I’m sure I’ve forgotten in some of my plugins.

    I always just assume anything I put on WordPress.org is GPL. I think everyone should have that assumption.

  6. @Chip Bennett:

    I’ve added this to the Agenda for tomorrows dev chat as I would like to close the loop on it and publish some recommended best practise.

    I prefer a slug type approach for the Licence: field as it would be easier to automate review.

    So we could have GPL2 like in my example.

    I like the idea of using a URI to link to the licence rather than cluttering svn with many licence.txt files.

  7. Chip Bennett says:

    @westi:

    Hey, that’s great! Hopefully I’ve been able to contribute something positive to the discussion.

  8. Chip Bennett says:

    @Brad:

    To be honest I never include a license.txt file with my plugins. I try to always include a plugin header license, but I’m sure I’ve forgotten in some of my plugins.

    Yeah, I really think requiring a license.txt file with every plugin is overkill. For a web application, it is reasonable to assume that the user can click a link to read the text of the license.

    I always just assume anything I put on WordPress.org is GPL. I think everyone should have that assumption.

    I would assume so, as well, to be honest. Since the repository requires that all plugins hosted there be GPL-compatible, it is reasonable to assume that, if nothing is explicitly disclosed, that the license is GPL-compatible.

    But, ultimately, it is better to have explicit disclosure, to eliminate any confusion.

  9. It might be annoying, but actually, the GPL requires the license be included.

    http://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude

    I don’t know how this would work, but I wonder if there is a way to add it after the fact to those plugins in extend that don’t include already include it. Not sure how that would affect Subversion repos and currently active development in them.

  10. Chip Bennett says:

    @Kenneth Younger:

    It might be annoying, but actually, the GPL requires the license be included.

    So, since the plugin is a derivative of WordPress, what if the plugin simply referred the user to the license.txt included with WordPress itself?

    While the gnu.org GPL link may change or disappear, presumably the license.txt included with WordPress would always exist, in perpetuity.

    Would that be acceptable?

  11. The recent discussions you have been involved with have given me cause to add to each plugin I release (and subsequent updates) into the WordPress repository a notice to the effect they are released under a GPL license, with an appropriate link to the license text.

    I add the GPL reference to the “Other Notes” part of the readme.txt file; and, the header details of the primary plugin file as well. I do not include a full license text file as that, IMHO, would simply create bloat.

  12. a7bab says:

    Thank you very much

Trackbacks

  1. Auditing WordPress Plugins for License Disclosure - WordPress Tavern Forum
  2. Unwritten Guidelines Suck
  3. Free Your Mind, Not Just Your Software » cb.blog