Found some old screenshots…

When I first came to Penn, the website for the Nominations & Elections Committee looked like this:

Old NEC site circa 2011
No, this wasn’t the year 1999… this was in 2011.

NEC website redesign

I set out to redevelop and redesign this, upgrading it from a static HTML site edited over SFTP to a WordPress CMS on Canvas. More importantly, the website redesign in 2012 needed to fit the rebranding that Penn underwent that academic year. In other words, I wanted it to look more like the university’s design. (An email to the Communications office responsible for web assets clarified that we could, in fact, do this.)

Continue reading “Found some old screenshots…”

Spambots gone wild

On one of my sites running WordPress, Akismet (and other antispam plugins) is not installed. In some ways, it has served as a honeypot, revealing interesting tidbits about how spambots work.

Fascinatingly, there were several hundred of these comments, all identical to each other. They look like templates for comments to be generated by spam-producing software, except that the software never processed the templates and posted them verbatim instead:

Tracking the #thesiswp matter: Part 2

« Read how it all started in Part 1.

Synopsis

While the initial controversy about the Thesis-not-being-under-GPL issue was focused on themes and derivative works, an unclear area that probably needs to be resolved in court, it seems there is a far sounder reason why Thesis has to be released under the GPL: it blatantly copies WordPress code.

It all started with this tweet by Andy Peatling (@apeatling):

Not a clear GPL violation, because it’s extending WordPress classes, which, in effect, copies WordPress functionality into Thesis.

Code analyses

Andrew Nacin (@nacin) started going through the code of Thesis and started to make some encouraging/discouraging tweets:

I just found a line of code I wrote for #WordPress, but in #thesiswp. Funny, when I wrote it, it was under the GPL. #

And then, an initially uncorroborated claim:

This is really pissing me off. I’m up to a few hundred lines directly lifted from WP. A part of me is crushed. #thesiswp #

And then Drew Blas (@drewblas) did an automated analysis (like I suggested 🙂 ) and found clear evidence of copied WordPress code:

Code analysis of WordPress and Thesis
Clear evidence of GPL code in Thesis

Impact

At this point, it seems clear: Thesis isn’t merely building on top of WordPress, it literally incorporates WordPress code through copy-paste.

That makes Chris Pearson liable to fulfill his obligations under the GPL and distribute GPL derivatives under the GPL.

[acm-tag id=”468×60″]

Most damning

Andrew Nacin eventually found this in Thesis:

* This function is mostly copy pasta from WP (wp-includes/media.php),
* but with minor alteration to play more nicely with our styling.

GPL test case? YES.

Chris Pearson indicated during his interview that he is fundamentally opposed to the GPL and will absolutely refuse to license Thesis under the GPL. By the end of the dialogue, he was practically saying “sue me”.

Matt Mullenweg responded:

Matt: Are you saying you want to be a test case for the GPL? You want us to sue you? I mean, that would break my heart. I’d rather you be part of the family.

While the themes = derivatives basis might have been shaky for a legal trial, I think the fact that there’s copied code clearly indicates one outcome in the end, in favour of the GPL.

Temporarily back to the case for themes = derivatives

WordPress isn’t the first community to issue the directive that extensions (themes, plugins) are derivatives. Joomla! did so a few years ago (I recall because I used Joomla! before finding WordPress) and Drupal makes it extremely clear.

If this matter can’t be determined by the GPL’s applicability to themes/plugins, maybe WordPress should just re-license, starting with a future version, with GPLv3 and add a specific requirement that themes/plugins are licensed under GPL.

Tracking the #thesiswp matter: Part 1

Twitter erupted into argument last night in a fairly important battle for open source, the GPL, and WordPress. At the centre of the issue is a theme framework called Thesis which plugs into WordPress, sold with a restrictive license that does not permit redistribution.

Background

To provide some background, WordPress is a blogging platform licensed under the GPLv2, which specifically forces all copies of a work licensed under GPL, as well as derivative works, to be licensed under the GPL:

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

The Free Software Foundation explicitly addresses plugins in its FAQ, making it clear that plugins that share data structures with the main program and make function calls to each other are derivative works to which the GPL also applies.

Themes were an uncertain matter prior to last year’s legal opinion from the Software Freedom Law Center, because these works from third parties certainly build on top of the WordPress platform, but often extend it with original artwork and programming. The analysis states clearly that:

… it is our opinion that the themes … contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.

Though almost all of the other theme foundries have adopted the GPL license for their PHP code, Chris Pearson stands nearly alone in asserting the GPL’s viral clause is inapplicable to him.

Initial controversy

On a live webcast with both Chris Pearson, the developer of Thesis, and Matt Mullenweg, the founder of Automattic and the WordPress project, Chris expressed his personal belief that the viral nature of the GPL goes against his personal freedoms and rights as a developer:

Chris: One, it would require me to make a concession about something that I don’t think that I need to concede to. Why should I change? I’m protected right now. My work is protected, which it should naturally be. I want to retain that right. If I go GPL then I am ceding that right. The number one issue for me is the personal concession that I would be making. Not of any real impact to my business. I don’t want to make that personal concession, because I don’t have to. Okay?

Note: it is possible, in terms of the GPL’s legality, that Chris never had the right to prevent users from redistributing his code; if the GPL applies, a developer cannot restrict redistribution.

Matt, on the other hand, debates to defend the applicability of the GPL to themes and plugins:

Matt: … If you build a module for Drupal or a module for WordPress or a theme for WordPress or anything like that, the license says that you do have to follow the GPL. I think that it’s just a matter of choosing the platform. If you disagree with the GPL, just use a platform that doesn’t have the GPL.

I listened to all of the long back-and-forth encounter, which was interesting until Chris began to assert his importance in the community:

Chris: I’ve done great things with WordPress since 2006. I have been arguably one of the top three most important figures in the history of WordPress. You, Mark Jaquith, and myself, are the three people that I am talking about.

Wait, what? A developer whose theme accounts for such a small fraction of WordPress’s usage puts himself in the top three figures in WordPress history? Jane Wells had a similar encounter with his ego.

» See the top 10 figures in WordPress history.

[acm-tag id=”468×60″]

Analysis of this part of the controversy

The crux of the controversy is summarized by Chris’s sentences here:

Chris: I think the license, the GPL, is at odds with how I want to distribute my software and what I want it to be. I don’t think that it necessarily should inherit WordPress’ license when over 99% of the code within Thesis is Thesis code based on the actual process of building a website.

As someone who also contributes to open source software, I can certainly understand his sentiments on the ‘infectious’ nature of the GPL, which forces derivatives to inherit the GPL. It’s pretty hard to release projects under even more permissive licenses (for example, the Apache License), or in Chris’s case, extremely restrictive proprietary licenses, when so many open source projects enforce the GPL.

That really is, though, the purpose of the GPL: to keep open source open by prohibiting its inclusion in fully closed-source or proprietary (and restrictively-distributed) projects.

Are themes derivative works?

A lot of the open source advocates and lawyers seem to think so. After all, themes do things like:

<?php if ( get_comment_pages_count() > 1 && get_option( 'page_comments' ) ) : // Are there comments to navigate through? ?>

and

<?php if ( $wp_query->max_num_pages > 1 ) : ?>

which show clear integration with WordPress core functionality, much like a program in C would use the MySQL library with

mysql_real_connect()

Granted, the MySQL developers explicitly allow derivatives to use non-GPL licenses even though MySQL is GPL, through an additional license exception. The reason such an exception is necessary is that they understood that works which link to library code are derivatives.

The biggest problem is that the GPL was written with compiled code in mind, where derivatives would have to bundle the libraries (e.g. DLLs or SOs) in their releases. It’s sort of unclear for interpreted languages like PHP; is it an indication of derivation if one piece of code makes a function call to another?

It’s a bit unfortunate WordPress wasn’t licensed under GPLv3, because version 3 is much clearer about what it means to make a “modified version” or a work “based on” another work. It would also make for a better court case.

Caleb Jenkins (@CalebJenkins) iterates an interesting point: dependent != derivative. While I can see this being an interesting legal argument, it would have a lot of implications for open source in general, completely contrary to the way things have been operating.

If using a dependency is not being a derivative of that work, then it is conceivable that one can produce a C application which links to a GPL library (for example, the FOSS-licensed version of the MySQL client library) without bundling it and is released commercially under a closed-source, restrictive license. It is conceivable that a PHP program might require() WordPress to use its functionality, but simply not bundle WordPress, and would then avoid classification as a derivative.

I’m afraid I can’t entirely lend my support to that argument.

People have argued that making function calls to WordPress is akin to making system calls to the underlying operating system. Unfortunately, only GPLv3 is clear about distinguishing the system and compiler libraries from other general code; of course it doesn’t make sense that every application on the GPL Linux kernel must be open source. It’s a valid argument.

However, I agree more completely with Matt’s contention that a dependency = derivation when it gets to the point that a WordPress theme without WordPress will not work (just try loading any theme’s index.php in a browser) while WordPress without any themes will still function — it won’t show anything, but its backend is still fully functional.

Chris Pearson is wrong when he says “I think that what I’ve done stands alone outside of WordPress completely.” Interestingly, read the context of this quote:

Chris: How is that? I think that what I’ve done stands alone outside of WordPress completely. Why should I respect that? It’s not that I don’t respect WordPress. I do. I only build on WordPress and push people in its direction…

» Now here: Part 2 of Tracking the #thesiswp matter.

» Also read: Why WordPress Themes are Derivative of WordPress by Mark Jaquith (@markjaquith), a lead developer.

Subversion for Beginners

I mentioned previously that I wanted to post how Subversion works (on the surface, for beginners) and how I use it for my development needs.

To create my WordPress plugins, Simpler iPaper and Simpler CSS, using SVN has been a must; after all, the only way to release new versions of the plugins is through SVN. I also keep this site’s WordPress installation up-to-date on the development version using Subversion. Additionally, in my current efforts to develop a working solution for HDTV’s in business and organizational settings, Display UI is being developed using Subversion for version control.

You get the idea. I use it on a daily basis, and for practical purposes. I don’t claim to understand the fine details, but hopefully this post gives you an idea of how I use it and how you can, too.

Source Code SnapshotSo what is version control? Simply put, it’s a way of keeping track of the changes made to files. It’s often impractical to make manual backups of a file before every set of changes to it, so version control systems like CVS and SVN emerged to help people — especially developers and programmers — keep track of their files, share changes with team members, and prevent stupid mistakes.

Accidentally deleted your code? Revert your changes. Came up with an ingenious way (that works) to do something? Commit your changes. Need to get the latest revision of all the files? Update the working copy.

Perhaps the most practical application of systems like Subversion is in team development. When three or more people are working on the same set of files, it’s useful to be able to merge the changes seamlessly, see the changes others have made, or even work separately on branches (kind of like forks) and tags (usually released versions that are being maintained).

I did write that I don’t claim to understand the fine details. If you really want to understand Subversion, I highly recommend this book by members of the development team: Version Control with Subversion, or the book online.

Let’s talk about how to use it. Hard-core programmers often choose to use the command line tools, where they type commands like svn up to update the files. Beginners will be glad to know that there are implementations with GUI‘s, like RapidSVN and TortoiseSVN. Eclipse users may use Subversive or Subclipse, “team providers” that let coders easily perform version control tasks inside the IDE.

Subversion tasks can be done in Windows Explorer
Subversion tasks can be done in Windows Explorer

Assuming that you’re using the command line binaries — which you can get from the Subversion site, and I recommend official CollabNet builds where possible — most of the basic tasks are rather easy.

Instead of right-clicking and picking options from a menu, tasks are done by typing commands.

First of all, a ‘repository’ is a hosted location containing all of the code, revisions and metadata. Often, one can access a repository via HTTP, as in the case of WordPress, which is found at http://core.svn.wordpress.org/ .

To ‘checkout’ a repository means to make a local copy (known as a ‘working copy’) of the contents. That’s what we have to do first when working with an established project: get the code from the repository.

To do so, type the following at an open shell (on Linux/Mac OS X) or command prompt: (don’t type the ‘$’ — that’s just a placeholder for the prompt you’ll see, such as frederick@ubuntu-pc:~# or [frederick@fedora-vm Desktop]$ — the specific prompt will differ depending on your machine and platform)

$ svn checkout http://core.svn.wordpress.org/trunk/ wordpress/

Windows users would do the same, but at a command prompt — again, without the dollar sign.

That command invokes the svn executable and tells it to checkout the WordPress trunk directory to the local folder wordpress.

Continue reading “Subversion for Beginners”

Yay for WordPress 2.8 Release Candidate

Awesome! WordPress has just released the release candidate of WordPress 2.8, which seems to contain an awesome amount of improvements over WordPress 2.7 (most of them subtle and unexposed to the end user). I’ve been running the trunk version of WordPress for months now, and I have to say that WordPress 2.8 is stable and usable.

If you want to stay up-to-date with WordPress, you can try running it from SVN. I’ll post a little guide on how I do it soon.