Yearly Archives: 2010

Install Google mod_pagespeed with DirectAdmin

Earlier this week, Google released an open source Apache module to simplify the optimization of your content.  The module, mod_pagespeed, will do all sorts of magic like minify your JS/CSS and optimize images, and a handful of other optimizations that seem (from limited testing) to improve your servers performance considerably.

Google has provided a couple of RPM’s to help with installation, unfortunately, if you’re running DirectAdmin on CentOS, they won’t work.  DirectAdmin runs a compiled Apache with some slightly different defaults and installing using YUM or RPM will fail dependency checks.

In this article, I’ll explain how to get around the dependency issues and adjust your configuration.  I have to warn you that this is NOT something I recommend you do on a regular basis unless you’re an experienced Linux Admin, in which case you probably won’t need this tutorial. Overriding RPM dependencies can have some adverse effects on your system.  In this case we know most DirectAdmin / CentOS systems share a very similar configuration, so it’s not much of a risk.

Download a copy of the CentOS RPM or wget it from your shell:

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm <– 32bit
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_x86_64.rpm <– 64bit

Since you’re running on a DirectAdmin server, trying to install using YUM or RPM will fail dependency checks since Apache is built from source.  We’ll have to force the installation and make a couple of changes to our systems configuration files:

rpm -i –nodeps mod-pagespeed-beta_current_.rpm

vi /etc/httpd/conf/extra/httpd-includes.conf

And add the following to the top of the file:

#Google PageSpeed Module
Include /etc/httpd/conf.d/pagespeed.conf

Next you’ll need to edit your main httpd.conf file:

vi /etc/httpd/conf/httpd.conf

Find and remove the line:

Include conf/extra/httpd-deflate.conf

If you’d like to change the options for PageSpeed, it’s configuration file is located in /etc/httpd/conf.d/pagespeed.conf

Once everything is set, we’ll need to restart Apache and test to see if the module loaded properly:

service httpd restart

and

apachectl -t -D DUMP_MODULES | grep pagespeed

If you get the following output, everything should be installed and functioning properly:

Syntax OK
pagespeed_module (shared)

You should also check any .htaccess files you may use and remove any instances of ‘setoutputfilter’ as this will probably override what mod_pagespeed is doing.

There you have it!  Load up a copy of FireFox with the PageSpeed installed and check out how your score has improved.  In my case, with all other caching disabled, I went from a score of 60 to an 82.  Not a bad improvement if you ask me!

 

rpm -i --nodeps (the right version of mod_pagespeed).rpm

WordPress themes and plugins DO NOT inherit the GPL v2

Last week, the WordPress scene once again exploded with debate about the GPL v2.  The fuse?  A WordPress developer was removed from the CodePoet.com directory because he actively supported the commercial theme “Thesis” 1.  The community ruckus  spawned several articles about the subject, including this article I wrote as a response to the situation.

This post is an update to my previous article.  Though I think I made a valid argument, I no longer think it’s accurate and it’s doesn’t cover the “whole truth” which I’m going to do here.

While reading all the articles that have been written recently, I came to an epiphany!  Most of these articles, including my own, make one critical error:  They missed facts and focused on beliefs.

I’ll have to thank Matt Mullenweg for pointing out this fantastic quote:

“In reality, we often base our opinions on our beliefs, which can have an uneasy relationship with facts. And rather than facts driving beliefs, our beliefs can dictate the facts we chose to accept. They can cause us to twist facts so they fit better with our preconceived notions. Worst of all, they can lead us to uncritically accept bad information just because it reinforces our beliefs. This reinforcement makes us more confident we’re right, and even less likely to listen to any new information.”

– Joe Keohane in How facts backfire.

One of the most well written articles on the subject of Derivative Works and WordPress would probably be Mark Jaquith’s “Why WordPress Themes are Derivative of WordPress” 2.  It spends most of it’s space explaining why WordPress themes should be considered “derivative works” without ever quoting a single line of the GPL v2.  He spent 2,000+ words on defining what makes something derivative but he missed one fact that qualifies, or in this case, disqualifies his entire opinion.

I commented:

Your article does a detailed job of describing your opinion. I truly appreciate hearing your point of view.

That said, I can’t help but notice that you don’t mention which part of GPLv2 you’re basing this opinion on. I think it’d be helpful to the readers to see what part of the license brings you to your conclusions.

Mark responded with the following:

The crux of it, to me, is this:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, 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

I do not consider themes independent and separate works. They form one work, when combined with WordPress, and necessarily contain WordPress code and WordPress-derivative code.

BAM!  There it was.  The qualifier.  Not the quote from the GPL v2, but his words:  ”when combined with WordPress”.  As Matt Mulenweg’s post quoting Joe Keohane helped me realize, Mark Jaquith twisted some facts by omitting this one statement from his entire article.  Perhaps he did this intentionally, or maybe it was just his beliefs driving his facts.

Mark made some very valid points throughout his article and it is VERY well written.  Points about how themes are run, how they interact with WordPress the same way that WordPress interacts with itself and how a theme uses the same functions as the core uses.

Yes, valid and convincing points indeed, except none of his points qualified until after a theme is distributed.  The GPL v2 is a distribution license, after all.  Until a theme is combined with WordPress, none of his points are valid.  If you go back and re-read his post, adding “when combined with WordPress” to each point, the article takes on a completely different meaning than what it’s title implies.

Now lets take a second to review James Vasile’s “official legal opinion” 3 as posted on WordPress.org back in July of 2009.  Since his legal opinion tends to be the de facto go-to when issues of WordPress and commercial themes come into question, I think it’s a very important read for everyone.  Since Mark and several others pointed to this Legal Opinion, I decided to read it one more time — really trying to absorb it this time, opening my mind to any new information that I may have missed in the past.

Now, I’m guessing I can’t be the first person to notice this — and I’m sure someone will point it out (please do).  James Vasile qualifies his entire legal argument with the following statement:

On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works.

As James sates, it’s his official legal opinion is that themes AS IF THEY HAD BEEN ADDED TO WORDPRESS BY A THIRD PARTY are derivative works.

How the HELL did I miss this the first 10 time I read it?  Perhaps because I wasn’t expecting the go-to, “Official Opinion”, to support my opinion of commercial themes and plugins as they are currently distributed.  I read right over that statement because I was looking at the information and trying to find ways to refute it rather than agree with it.

So, there ya go – I now officially agree with the official WordPress.org published legal opinion of James Vasile.

WordPress themes and plugins that do not contain actual code from within WordPress and that are distributed without WordPress are NOT derivative works.  They do not become derivative works until a third party places them within the codebase of WordPress.  As we all know, people selling commercial plugins almost NEVER distribute them with WordPress and if they’re on the up-and-up, they’re not distributing copy pasta 4 that could possibly cause their code to inherit the GPL v2.

Now, many of you may wonder why I’m so adamant about this subject.  Those of you that know me, know that I wholeheartedly support Open Source and what it stands for.  WordPress and other Open Source projects have been putting food on my table for over a decade.  Why would I speak out against people like Matt Mullenweg and other GPL evangelists?

Well, the answer to that is very simple:  I believe in freedom in its purest form.

Just as much as I appreciate the work of people like Mark Jaquith, Matt Mullenweg, Andrew Nacin and all the many other contributors to WordPress, I also appreciate the fact that not everyone is able to put food on their table as a side-effect of freely contributing to a project such as WordPress.  I understand that some people might be creating original work that simply doesn’t have as much broad appeal or is amazingly innovative but simple, and the only way they’re time and effort will be repaid is by keeping the creation their own.

Yes, there are plenty of people that code commercial software that could contribute to the open source community and still make money, but it’s not my place, nor do I think it’s the intent of the GPL, to force those people to do the right thing.

Other good reads:

For a ton of research and potentially related case law, Chip Bennett did a very in depth write-up on this same topic, from a slightly different angle.

A short note on Chris Pearson:

Since I started this post with mention of Thesis, I feel I need to add a note about it.  As I don’t want to make Thesis a focus here, I’ll keep it brief.

Chris Pearson allowed code from within WordPress and other GPL’ed plugins into his code-base.  Because of this I believe he has, at least to some extent, violated the GPL.  If he had kept it clean and used only his own code in the making of Thesis, I would probably be supporting him and would be rejoicing a precedent-setting lawsuit against him.  As it stands I cannot support him, nor do I find any joy or purpose (other than to compel him to re-release his code under the GPL) in any legal action against him.  Thats is all.  I will not respond, and will probably delete any comments in direct regards to Chris or Thesis.

Notes:

  1. a commercial theme written by Chris Pearson, which Automattic, Matt Mullenweg and several others claim to be in “blatant violation of the GPL” ↩
  2. http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-derivative-of-wordpress ↩
  3. I’m referring to his opinion and not the introduction which I find wholly inaccurate - http://wordpress.org/news/2009/07/themes-are-gpl-too/ ↩
  4. Nerd Slang for software that contains copy and pasted code from other peoples work ↩