GPL feed

GPL

Posts filed under GPL
2010Fri10Dec

Only Download WordPress Themes From Trusted Sources

Permalink | Shortlink | Comments (12) | TrackbackFiled in Web DevelopmentTags: GPL, Malware, Themes, WordPress

Earlier this week, I released version 1.0 of my Oenology Theme. As I tend to do occasionally, after the release I decided to browse the Google search results for "Oenology WordPress", just to keep track of any mentions of the Theme.

I was somewhat surprised to discover, among the first-page search results, a site that was re-distributing a modified version of the Theme. Now, there is nothing inherently wrong with re-distribution of the Theme in either its original form or modified; I released it under the GPL, which explicitly permits modification and redistribution. However, these Theme modifications turned out to be insidiously malicious. As Otto explains, Themes distributed by the site in question had been hacked to (among other things) include a well-hidden PHP shell that would allow the hacker a backdoor to access the site on which the Theme is installed.

It is generally-accepted knowledge within the WordPress developer community that such malicious sites have over-run the search engines, and dominate the search results for WordPress Theme-related search queries. Thus, following the above discovery, I decided to audit those search results, to get an idea of just how bad the current situation is. I performed a Google search for "Free WordPress Themes". The results are sobering.

For each of the first 30 results (first three pages), I evaluated the domain name against the WordPress Domain Name Trademark Policy, determined whether the Themes were original, or taken from elsewhere, and whether the Themes had SEO/Spam links, encoding, and/or other forms of malware.

A note on the original source of the Themes: while some sites simply modified existing Themes, and some developed "original" Themes (derivatives of Kubrick, or Artiseer-generated, etc.), a great many of the audited sites distributed many of the same Themes. There apparently exists a rather incestuous relationship among these Theme-distribution sites - and especially among the sites distributing the worst-offending Themes.

SEO/Spam Links, Encoding, and Malware

Of those top-30 search results for "Free WordPress Themes":

  • 2/30 were links to the Official WordPress Theme repository
  • 1/30 was a "Top 100 Themes" blog post from a legitimate source
  • 1/30 was an affiliate-link aggregator to legitimate Premium Themes

Of the remaining 26 results:

  • 8% (2/26) were (at least somewhat) legitimate WordPress Theme sites
  • 35% (9/26) violated the WordPress Trademark
  • 88% (23/26)had Themes with Spam/SEO links
  • 76% (19/25) had Themes with base64 or other encoding (note: 1/26 not verified)
  • 12% (3/26) had Themes with other malware (note: 17/26 sites not verified)

Of the sites that added base64 or other encoding, many of them (at least 5/19) included encoded "kill codes" that prevented the Theme from loading if the footer code was modified. All of them included SEO/Spam footer links.

Of the sites that added other malware, one added the well-known "Verify Widgets" worm to the functions.php file, and another added a sort of backdoor that allows for remote management of spam links, and phones home data back to the hacker.

WordPress Trademark-Violating Sites

I noticed what appeared to be a correlation between WordPress trademark-violating domains and the presence of SEO/Spam links, encoding, and malware. That appearance seems to be valid, though I make no claim on the statistical significance of the correlation. One of the 9 WordPress trademark-violating sites was the aforementioned affiliate-link aggregator; of the remaining 8 WordPress trademark-violating sites:

  • 100% (8/8)had Themes with Spam/SEO links
  • 100% (8/8) had Themes with base64 or other encoding
  • 13% (1/8) had Themes with other malware (note: 4/8 sites not verified)

Just to determine if my sample size was too small, I did a quick audit of the next two pages' worth of results (thus including the top 50 results). I found an additional 4 sites (for a total of 13 out of 48 sites (27%) that violated the WordPress trademark).

Including those 4 sites with the previous results:

  • 100% (12/12) had Themes with Spam/SEO links
  • 100% (12/12) had Themes with base64 or other encoding
  • 17% (2/12) had Themes with other malware (note: 4/9 sites not verified)

Are you beginning to notice a trend?

Restrictive Licensing

But mere inclusion of malware isn't the extent of the problem. Themes are also encumbered either with restrictive licensing, or else mal-applied licensing, in order to prevent the user from removing the crap that the sites added to the Themes.

Of the 27 above-referenced, all 27 incorporated some form of license encumbering. Most sites simply distributed the Themes with some sort of "Terms of Use" statement that (among other things) prohibited modifying the footer. The next most-popular licensing strategy was to distribute the Themes under some variation of a Creative Commons Attribution license, with the claim that the "footer links" were the license-conforming attribution. Quite a few Themes even attempted to claim that they were licensed under GPL, and that the GPL allowed the restriction against removal of footer credit links.

Of the 2 legitimate Theme sites, only one - ThemeLab, run by well-known WordPress community member Leland Fiegel -  distributed unencumbered, GPL-licensed Themes. The other distributed Themes encumbered with a mal-applied CC-Attribution license.

Mal-Applied Creative Commons Attribution Clause

Of course, the requirement to keep a public-facing link to an SEO/Spam link has nothing to do with the Attribution clause of the CC-Attribution license [emphasis added]:

If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.

The license requires that attribution of the original author, the original author's copyright, and a link to the same, must be retained within the work. It does not require that such attribution be public-facing, nor does it require that the author may specify any link other than one directly related to attribution to the author and his copyright of the original work. In fact (as noted above), the attribution clause specifically excludes URIs unrelated to the copyright notice or licensing information of the original work.

Mal-Applied GPL Attribution

Similarly, the requirement to keep public-facing attribution links is not only part of the GPL (in any version), but such a use restriction directly contradicts the wording of the license itself. Some confusion may arise regarding the requirement to retain appropriate copyright and licensing information in conveyed works (whether original or derivative), but under no circumstance does the GPL require that such information be portrayed in a public-facing manner. (The accepted standard for PHP code is to add this copyright and licensing information as PHP comments in the header of one or more PHP files.) And in fact, the GPL even states that if further restrictions are imposed upon a GPL-licensed work, that such restrictions may be ignored.

But Wait, There's More!

Theme Quality

As if SEO/Spam links, encoding, malware, and encumbered licensing weren't enough, I cannot fail to discuss the quality of the Themes distributed by the audited sites.

Again, with the lone exception being the one legitimate Theme site that distributes malware-free, GPL-licensed Themes, the remainder of the sites distributed Themes of - there's no better way to say it - utterly horrible quality. The Themes are, generally speaking, woefully obsolete. Trudging through this morass renewed my appreciation for the current effort to improve the quality standard of Themes submitted to the official WordPress Theme Repository.

Conclusion

If you are looking for free WordPress Themes, avoid the search engines; stick to known, trusted sources. Otherwise, you will end up with a poor-quality, license-encumbered Theme full of SEO/spam links, encoded content, and other malicious malware. If your primary objective is to find a free Theme, I strongly suggest that your search start - if not end - with the Official WordPress Theme Repository. (Although, I fully endorse ThemeLab as well.)

As a corollary: sites whose domain names violate the WordPress trademark policy cannot be trusted. It is safe to assume that a site that violates the trademark policy is not directly involved with the WordPress community. Such a site is either intentionally flaunting the trademark policy - likely in order to gain SEO from the domain name, and likely to be doing so for nefarious purposes - or else is not closely enough involved with the WordPress project or community to have the necessary experience and expertise.

Posted by Chip Bennett December 10, 2010 at 5:30 pm
Licensed under a CC By-NC-ND 3.0 United States license.All WordPress code is licensed under GPL, Version 2 (or later).
2010Tue20Jul

WordPress Themes, GPL, and Copyright Case Law

Permalink | Shortlink | Comments (77) | TrackbackFiled in Web DevelopmentTags: Copyright, GPL, Judiciary, Plugins, Themes, WordPress

Within the WordPress community, the question of GPL inheritance of WordPress themes erupts into contentious debate with the reliability - if not the frequency - of Old Faithful. While I understand that, according to the GPL interpretation of Matt Mullenweg, the Free Software Foundation (FSF), and the Software Freedom Law Center (SFLC), WordPress themes are derivative of WordPress and therefore must necessarily inherit WordPress' GPL, I would like to investigate the issue not in light of their interpretation but rather in light of copyright law and precedent case law.

Before I begin, let me add an important caveat: I have no qualms with the GPL. I have always released - and will continue to release - under GPL anything I develop related to WordPress. I do so because I choose to do so, as a means of making even a minor contribution to a project from which I believe I have personally benefited. I do have issues with how the GPL-inheritance question has been handled - but those issues are out-of-scope for this post.

Having (hopefully) made that point clear, let's begin!

What US Copyright Law Says

US Copyright law defines a "derivative work" as such:

A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.

Note the key adjectives: recast, transformed, and adapted.

Consider also Section 102(b), which states:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

This clause establishes the boundary around copyright between copyrightable expression, and non-copyrightable ideas.

Summarizing GPL Inheritance Requirements

To summarize GPL requirements regarding license inheritance for derivative works 1:

  1. The GPL only applies to distribution of a (modified or unmodified) GPL-licensed work, or a derivative work. Any activity involving use, modification, or creation of derivative works that does not involve distribution is outside of the scope of the GPL.
  2. Distribution of a (modified or unmodified) GPL-licensed work, or a derivative work, requires that such distribution be licensed under GPL.

The GPL is what is now referred to as a "copyleft" license: a modified public-domain license that takes advantage of the exclusive rights granted by copyright law to prevent derivative works from being restrictively licensed. Since the copyright owner has exclusive right to produce and to distribute derivative works based on the copyrighted work, the GPL intends to grant unlimited usage rights (to use, study, modify, etc.) to the end-user, while forcing follow-on developers of derivative works to release those works under the same license.

It is important to understand that, because the GPL explicitly defines any activity not involving distribution to be out of the scope of the license, and since right of distribution is solely derived from copyright law, that GPL derives its legal basis from copyright law alone. This distinction separates the GPL from most other traditional software licenses, which derive their basis for usage and modification restrictions not from copyright law, but from contract law.

Page: 1 2 3 4

Notes:

  1. WordPress is released under GPL version 2.0. I'll try to summarize below the parts of the license germane to derivative works.

    First, from the Preamble:

    The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such.

    ...

    The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, while the latter only works together with the library.

    Terms and Conditions, Clause 0:

    The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)

    Terms and Conditions, Clause 2:

    These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

    Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.

    Terms and Conditions, Clause 5:

    A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

    However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

    ↩

Posted by Chip Bennett July 20, 2010 at 5:40 pm
Licensed under a CC By-NC-ND 3.0 United States license.All WordPress code is licensed under GPL, Version 2 (or later).
2010Sat13Feb

Free Your Mind, Not Just Your Software

Permalink | Shortlink | Comments (9) | TrackbackFiled in Web DevelopmentTags: Free Software Movement, GPL, WordPress

The Free Software Philosophy

The philosophy behind the free software movement is noble and well-intentioned. Projects that have chosen to operate under this philosophy have been wildly successful and have produced outstanding products. In many ways, I enjoy the fruits of free-software projects. My laptop runs Kubuntu Linux. OpenOffice.org is my office suite of choice. Firefox is my default browser. WordPress is my blogging platform of choice. Rockbox is my MP3 player firmware.

Having benefitted so greatly from using free software products, I have even done what I am able to contribute to free software projects, from introducing others to the software, to writing tutorials, to attempting to help other users in support forums, and even trying my hand at contributing code in the form of plugins and themes.

One of the fundamental principles of free software philosophy is the right of users to form a community, to use, share, change, improve, and help others to use software. This philosophy states that users should be free to use, to study, to modify, and to redistribute both the original and modified copies of software.

Thus, the free software philosophy inherently encourages those who might not otherwise choose to do so, to get involved with the project. This involvement  from the users' sense of altruism (for the good of others/the project), sense of belonging (to be part of the group/project), or sense gratitude (to give back to a project from which one has benefitted).

Unfortunately, I have seen those who espouse this free-software philosophy also exemplify stifling closed-mindedness and attitudes that actively drive would-be contributors away from, rather than bring them into, the project community. A few recent cases in the WordPress community belie close-mindedness, arrogance, condescension, and nepotistic hypocrisy - attitudes that are counter-productive to building free-software communities.

The Unforgivable Prodigal Son

In the first case, a WordPress plugin author was using some practices that are clearly unacceptable within the WordPress community. This plugin author was allowing users to download and install his plugins, but upon attempting to use the installed plugin, the plugin forced the user to register his email address with the plugin author, and was also forced to double-opt-in subscribe to the plugin author's internet-marketing-focused email list - an email list that many users complained of being "spam"-like, due to its frequency and lack of focus on the users' installed plugins from the author.

Clearly, these practices are outside the acceptable bounds for the WordPress community - and, especially, the wordpress.org plugin repository. Thus, the author's plugins were removed from the repository.

However, after weeks of back-and-forth discussion with this plugin author, he decided that being a part of the WordPress community and having his plugins listed in the wordpress.org plugin repository was more important than forcing users to subscribe to his email list. He decided to modify his plugins to make the email-list subscription optional.

What was the response of the wordpress.org repository? Rather than welcome him with open arms, and celebrate that a "prodigal son" would embrace even a bit of the free-software philosophy, the response was instead, "Thanks, but no thanks." This plugin author was told that, no matter what changes he made, his plugins would never again be accepted into the repository.

As one might expect, this response discouraged the plugin author to the point that he decided that pursuing making his plugins repository-acceptable not worth his time and effort. Further, he decided that he would no longer continue to develop free-cost plugins.

While I question the widespread usefulness of most of this author's plugins, he did develop several very useful plugins. So, not only did the response from the WordPress project actively push a developer away from the WordPress community and away from free-software philosophy, but it also reduced the availability of plugins to end users of WordPress.

And what was the reaction of many in the WordPress community? In essence: good riddance; once a spammer, always a spammer.

This response assumes that the plugin author's only intent was to be a "spammer" - that he was up to no good whatsoever. In reality, the plugin author's intent - misguided and completely unacceptable as it was - was to support his free plugin development and free plugin support by driving traffic to his profitable email list.

Such a response is both unacceptable and unwarranted.

First, the author's plugins were not "spammy" or otherwise harmful. They provided value and usefulness to those who use them. While the author's tactics for forcing subscription to his email list were wrong, the author fully and appropriately complied with un-subscribe requests. While the email newsletter is not useful to many users, it does not meet any of the accepted definitions of "spam".

Second, it is important to understand that, prior to his plugins being removed from the repository, the plugin author was given no official warning whatsoever that his plugins violated the repository guidelines. Several users complained about the plugins in the wordpress.org support forums (to which the plugin author responded), but he was never formally notified that he would need to modify his plugins or face their removal from the repository.

Third, regardless of his reasoning, the plugin author relented, and decided to accept the terms specified in the repository guidelines. Whether or not he agreed with them, he willingly chose to modify his plugins so that they would conform.

So, this plugin author was given no warning in the first place, and then was given no opportunity to resolve the problems with his plugins: no warning, no forgiveness, and no attempt to bring this plugin author into the WordPress community or the free-software philosophy.

As a result, a potential community member was actively driven away from the community, and the community has less code contributions to show for it.

No Learning Curve Allowed

In the second case, a new developer decided to develop and release a WordPress plugin. This developer, being new to the GPL and to developing for WordPress - and thus mostly ignorant of GPL requirements and the free-software philosophy of WordPress - made a mistake.

This plugin author noticed that users were removing or replacing a public-facing attribution link he had put into his plugin. So, in response, he base64-encoded this attribution link - not realizing that he was, in effect, thwarting the user's intent in using his plugin. This author also had not explicitly declared in his plugin that it was released under the GPL.

This plugin author - also without warning or notice - found that his plugin had been removed/disabled from the repository. He inquired at the WPTavern Forum, and was told that the reasons for his plugin being removed were primarily the base64-encoding of the attribution link, and secondarily the lack of license disclosure.

The plugin author confirmed this information with the wordpress.org plugin repository moderator, and based on this information, demonstrated his understanding for why the encoding was unacceptable and immediately made the necessary changes to his plugin.

(Side note: kudos to the repository moderator, for working with this plugin author and for restoring the plugin once the changes were made.)

Again, it is important to understand the context. This plugin author did nothing that explicitly (or implicitly) violated the stated repository guidelines. His plugin was removed, he inquired as to why, received - and accepted - an explanation, and immediately made the necessary changes.

This situation - primarily the assertion that not disclosing license information in the plugin would result in the plugin being removed from the repository - caused me to take a look at how well the plugins from some of the more high-profile plugin authors conformed to that (unpublished) requirement.

What I found astounded me. Only 26% of the repository-hosted plugins written by Matt Mullenweg, Mark Jaquith, Peter Westwood, Ozh, and Viper007Bond explicitly disclosed license information - yet none of these plugin authors was under threat of having his plugins removed from the repository.

I published my results (in a blog post that was generally well-received by the authors whose plugins I audited), which led to Peter Westwood (Westi) adding to the upcoming dev chat a discussion point regarding proper means of license disclosure for plugins.

What I soon discovered was that some of the core developers - including Matt Mullenweg and Viper007Bond - dismissed the concerns out of hand, claiming that the plugin author in question clearly must be a "dirty" (or "lame") "spammer", and thus up to no good, due to his use of base64 encoding.

Once again, apparently the WordPress project would rather actively drive away a potential community member, rather than accept that he made an honest mistake and that he resolved the problem once he understood it. Likewise apparently, the project would prefer arrogantly and condescendingly to declare that, "with regard to the GPL and WordPress, ignorance isn't an excuse," and that "no good intention could ever come from code obfuscation," rather than show any patience with a developer new to the GPL and free software or to offer any forgiveness for mistakes that he made.

Membership Has Its Privileges

In the third case, a plugin author decided to fork an existing, very popular plugin. The plugin author intended to write a case study on "creating a clean plugin, with emphasis in source code’s good practices." This author also discovered that his plugin had been removed from the repository without warning.

Upon inquiring, this author learned that his plugin had been removed because an unnamed source alleged that his plugin contained certain security vulnerabilities. (Note: I discuss the handling of this issue elsewhere.)

As it turns out, the alleged security vulnerabilities in question originated not with this author's plugin, but rather with the original plugin he forked. Not only that, but the same alleged security vulnerabilities were propogated into other forks of the same original plugin.

On the positive side, the author was able to fix the alleged security vulnerabilities in his own plugin as well as alert the authors of both the original and the other forks regarding those vulnerabilities. Further, in the end, the author's plugin was restored to the repository.

However, the case demonstrates a double standard applied to this plugin author. His plugin was removed merely on the word of an unnamed informant. As far as I could tell, neither the other forks nor - more importantly - the original plugin were ever treated similarly by being removed from the repository until the same vulnerabilities were fixed.

In fact, to date, the original plugin is still available in the repository, without the now-known security vulnerabilities still not fixed. What is the difference? Usage and Popularity.

The author in question had only several hundred downloads of his plugin. The original plugin is currently the #2 Most Popular plugin in the repository, with over four million downloads. The author in question was relatively unknown, while the author of the original plugin is one of the most well-known.

If the security vulnerabilities were severe enough and the risk sufficiently high to remove from the repository a plugin downloaded a few hundred times, then the risk posed to users by the original plugin must be immesurable - and yet, the plugin remains in the repository, with severe security vulnerabilities intact. The unknown author's plugin was removed immediately and without warning, while the well-known author's plugin remains, after weeks of notice of the vulnerabilities. The well-known author was informed directly regarding the security vulnerabilities before any action was taken, while the unknown author was never contacted directly before or after action was taken.

This practice is a nepotistic double standard, applied based on the relative popularity of both plugins and authors. It is also hypocritical: the plugin that - by far - posed the greatest risk was left, unpatched, in the repository, likely due to the very reason that it posed the greatest risk (sheer number of downloads), while the plugin that posed little-to-no risk (both because of its miniscule number of downloads, and because it didn't actually call the functions that contained the vulnerable code) was removed from the repository without warning, hesitation, or question.

Leading By Example

While all of the scenarios I have mentioned deal with the wordpress.org plugin repository, my statements are in no way intended to reflect upon the repository moderator, whose responsibilities are as arduous as they are thankless. MarkR works incredibly hard moderating the repository, and has been one of the lone bright spots in each of these scenarios. He was the one who worked with the plugin authors in the latter two cases, to help them restore their plugins to the repository.

I would also like to point out that Mark Jaquith has also been nothing but helpful, both in helping the plugin authors correct the problems with their plugins and also in helping to explain to the community the actions that were taken and the reasoning behind them. He has shown patience, understanding, and respect in dealing with the WordPress community regarding these issues.

Perhaps more of the WordPress community needs to follow the example set by MarkR and Mark Jaquith.

Conclusion

This is no way to build a community.

All of these actions, behaviors, and attitudes are damaging to the WordPress community. Because of them, would-be community members are driven away, less code that might benefit the community is contributed, and WordPress users are left exposed to security vulnerabilities. Because of them, new and non-expert developers are discouraged from attempting to contribute. Because of them, opportunities to reach out and to bring others into both the WordPress community and the free-software philosophy are squandered.

Free software projects (and the communities built upon and around them) are best-served by attracting to the community all who would participate - whether that participation is contributing code, just using the software, or somewhere in-between - by encouraging contributions from all who would contribute, and by displaying patience, understanding, and a willingness to help such contributors when they make mistakes as they are learning how to contribute.

Rather than close-mindedness, display acceptance, understanding, and tolerance. Rather than arrogance and condescension, display respect, humility, and a willingness to forgive.  Rather than hypocrisy, display openness and truth. It is in an environment that displays such attitudes that a free-software community can best thrive, and in which the most noble and well-intentioned principles of free-software philosophy are exemplified and promoted.

Posted by Chip Bennett February 13, 2010 at 8:14 am
Licensed under a CC By-NC-ND 3.0 United States license.All WordPress code is licensed under GPL, Version 2 (or later).
2010Wed10Feb

Auditing WordPress Plugins for License Information

Permalink | Shortlink | Comments (30) | TrackbackFiled 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?

Posted by Chip Bennett February 10, 2010 at 4:23 pm
Licensed under a CC By-NC-ND 3.0 United States license.All WordPress code is licensed under GPL, Version 2 (or later).
2010Fri08Jan

MaxBlogPress and the WordPress Plugin Repository

Permalink | Shortlink | Comments (15) | TrackbackFiled 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.

Posted by Chip Bennett January 8, 2010 at 6:00 pm
Licensed under a CC By-NC-ND 3.0 United States license.All WordPress code is licensed under GPL, Version 2 (or later).