Theme Frameworks

What’s the next big thing in themes right now? Theme frameworks. Everyone is doing it. WooThemes has their own core framework, StudioPress has Genesis, now MojoThemes has partnered with Themify to use that as their own in-house framework. Plus there’s themes that can be used as frameworks all over the place, from Builder to Justin Tadlock‘s Hybrid to WordPress’ own Twentyten.

What’s the big deal with frameworks?

Frameworks make a theme designer’s job easier — even an armchair one who just wants to recolor the background and add a couple fonts.  They also make it infinitely easier to maintain a bunch of themes.  Think about it: you’re a theme developer and you have written a handful of themes.  Which is easier to maintain?  Six individual themes, or a single theme framework upon which all of those themes are based?  The answer is simple: it’s much easier to deal with a single framework and only have to tweak the individual themes if there’s a specific bug or feature enhancement.  And the WordPress API makes it easy to take a function built into your framework of choice — or even WordPress itself — and change the behavior of it, tweaking it to the particular needs of the theme you’re designing.

This is a concept we’ve been playing around with for a while, trying to figure out how to build a model out of it.  Up to now, all of our themes have been loosely based on the free AP-Blueprint theme framework we built and maintain here.  Each theme starts with that framework and evolves from there.  That gives us  good starting point for coding, but it doesn’t solve the problem with having to maintain half a dozen or more individual themes.  There’s got to be a better way, right?

Here’s the plan…

This is the idea I came up with the other night: we do the theme framework thing.  We build a single theme framework upon which all of our themes will be based.  We adapt all the current themes we have to use this single theme framework as child themes.

Then we make the framework completely free.  Ideally, we get it added to the official WordPress theme repository.

If you want to use our framework to build your own themes, or even start your own business: go for it.  Once we get it added to the repository, you’ll benefit from automatic updates and the knowledge that the framework meets WordPress’ high quality standards.  All of our themes will stay the same, simply enhanced by a core framework that can be regularly updated.  Not only that, but having a single framework and building all of our themes as child themes means that we can design new themes much faster.

Win-win, right?  You may applaud politely now.

So when’s the switch?

I’m currently mulling over a new theme design that will hopefully be ready in the next month or so.  Said new theme design will be the first to be built entirely on the new theme framework.  Once that’s done, I’ll start porting over the other themes to use the framework.  The framework will most likely be a modification of the AP-Blueprint theme but will be able to be used as a standalone theme if you so desire.

I won’t say anything about what the new theme design will be, but I will say this: it rhymes with Mean Crunk.

How to upgrade your Museum Theme to the most current version after you’ve made changes to the files

Our themes are released under the GPL.  That means that you are free to take them, change them, and even redistribute them under the terms of the GNU Public Licence.  We’ve seen what a couple of you have done with our themes and we couldn’t be happier to see you taking our code and bending it to fit your site.

But what happens when there’s a new version and you want to upgrade?

The first things you’ll want to do to keep your customizations and also keep the core code up-to-date is to create your own “fork” of the theme.  This is a lot less complicated than it sounds, and all it means at this point is to rename the folder that holds the theme files (so if you’re using Museum zine, you could change the folder name from AP-Museum_zine to YourDomain-Museum_zine or YourDomain_zine or just YourDomain — whatever you want as long as it makes sense to you) and to make some minor edits to the main stylesheet (style.css).

Why do you need to edit the stylesheet if you’re not making any CSS changes?  Well, WordPress checks the style.css to grab some basic information that’s used on the Appearance → Themes page.  All of that stuff is located above all the code, so if we’re looking at zine again, you’d see this:

Theme Name: AP-Museum zine
Theme URI:
Description: AP Museum zine is a set of grungy, magazine-style themes inspired by the underground fanzine movement
Version: 1.1
Author: Arcane Palette Creative Design
Author URI:

If you have two themes with the same name in the Themes page, both will display, but it gets confusing (for the record, WordPress tells you the location of the files underneath the description, where it says All of this theme’s files are located in /themes/AP-Museum_zine so even if you skip this step, you can still sort of tell which is which).  So what you may want to do is change the Theme Name so it appears as something different on the Themes page.  All you need to do is change AP-Museum zine next to Theme Name: to something else of your choosing.

Congratulations, you’re now officially a theme developer and have made your own version of a WordPress theme! (If you wanted to distribute it to others at this point, there’s a few more things you’re required to do by the GPL before you’re good to go on that point, and “forks”, in particular, have some special rules.  It’s a good idea to be familiar with the terms of the GPLv3 — which is what our themes are released under — before actually releasing your own theme.  For the most part, however, you probably don’t have any intention of redistributing your theme, so you don’t need to worry about GPL guidelines or restrictions — the GPL only affects you in that sense when you choose to distribute your theme — customizing your theme for your own personal use is fair game.)

Nothing we’ve done so far has actually changed anything. In reality, you’ve already changed the theme, so all we’re doing is changing the name and the directory to reflect that.  (As such, any of the other things in the style.css you want to change, like the version or the author, you’re free to do also.)  Now we’ll concentrate on incorporating the new code into your theme (or vice-versa: your customized code into the new version).  To do that, you first need to know what files you’ve changed.  Every time a piece of GPL software is modified, the new version is required to include some form of documentation saying what you changed and when.  This is primarily to keep developers accountable for their code, so that if you fork a piece of software, someone else can come along and figure out where the software was forked from the original source and what things were added or changed.  But even more than that, keeping this kind of documentation — which can be in the form of a Changelog — keeps you honest, and provides important reference notes for when you need to make future updates.  All our themes include a changelog.txt file in the theme folder which includes all the changes up to that date.  You may want to check this before you start so you know what we updated in the new version.  It might save you some work if you’ve modified a file that we didn’t make any changes to this time around — in that case, you could just keep your version rather than copying your code into the version of the file included in the theme zip package.

Let’s say you’ve edited the header (header.php), the sidebar (sidebar.php) and the single post template (single.php).  The first thing you’ll want to do is put those files aside — create a temp directory within your theme and copy those files in, or just copy them to the desktop.  For that matter, it’s probably a good idea to back up your whole theme, just in case there’s anything you might have forgotten about.  Once you’ve gotten your customized files out of the way — including the style.css that you just modified — copy the contents of the updated theme into your theme folder.  This will most likely involve extracting the zip somewhere on your computer, then navigating to that folder, selecting all the files inside and copying/pasting them into your theme.

Occasionally, we reference specifically in the changelog what files we’ve created or modified, and moving forward we’ll be doing a better job of being more specific in this regard.  If it doesn’t look like we’ve made any changes to any of the files you’ve modified, you can just copy your customized versions into the theme folder and be done.  However, if we (explicitly or implicitly) reference in the changelog that we updated any of the files you’ve customized (including changes to style.css, which should be fairly rare in most cases), you’ll need to go into your version and copy your customizations into the code of the updated version.  Presumably you remember (or at least have a general idea) of what you did last time, and if all the code surrounding yours remained the same (which it should), it will be fairly easy to do a stare-and-compare with the two files and figure out what you need to do.

If you’ve been making the changes live on your site, everything should be ready to check and make sure it worked at this point.  If you’ve been editing the files offline (recommended), you should be good to upload them and see if anything else needs to be tweaked.  Now’s when you’ll find out if your customizations were actually limited to the files you updated in the new version, or if there were other modifications that slipped your mind.  However, if you have a backup of the original theme, you can always go back, find what you added, and copy that into the new version of that file, too.

That’s it.  Now you’ve got all the benefits of the new version of the software with your own customizations.  If you have any questions along the way, feel free to let us know in the Support Forums.  If you’re using a modified version of our Museum Themes, we’d love to see links posted in the comments!

That Thesis Thing

Update 7/22/2010: Thesis adopts the GPL!

Over the last few days, the WordPress community has exploded into debate over one thing: Thesis and it’s restrictive, non-GPL-compliant license.  If you’re already familiar with the particulars of what Thesis is and what the debate is, you can skip the summary (to be honest, I’m sick of reading people rehashing the whole thing in order to provide enough background for casual visits, but I understand it’s necessry). I’ve taken the last several days absorbing all the information, the arguments on both sides, and held off writing anything about it until there was more information available.  As GPL-supported commercial themes developers, we’re a bit biased on which side of the fence Chris Pearson — the author of Thesis and DIYThemes — should be, the question is whether it is accurate to require him to comply with WordPress’ GPLv2 license.

What is Thesis?

Thesis is a WordPress theme, plain and simple.  What separates Thesis from some other commercial themes is its’ fairly exhaustive options pages which allow you to control various aspects of the front-end layout and design, as well as its claim of “airtight SEO.”  You have several pages of options allowing you to customize just about every aspect of the layout and colors of your site with an option to use custom-coding to expand it even more.  It promises “lightning-fast” page loads and encourages you to “just add killer content.”

Our initial bias

When we first started doing web design, particularly design based on WordPress, the internet was littered with requests to “customize Thesis theme.”  We took one look at what it was, and made a decision then to never work with it.  Our decision was based on this: if you have a theme that is built to offer unlimited customization options what’s the point of hiring a designer?  The entire point of Thesis is that you shouldn’t need a designer, and if you still do need a designer, obviously the theme isn’t doing its job.  At the same time, it’s easy to  understand without even looking what the pitfalls of a theme like that would be: the very fact that it offers unlimited possibilities is, in fact, more limiting than if it did not.  The typical user is not going to be able to look at a color wheel and say “yep, I want #EAFF63.”  They’re going to look at the range of 16 million colors, maybe pick a combination that looks horrid, and then ask someone else who knows what they’re doing to tell them what they want.  The entire point of hiring a designer to build a custom WordPress theme is that you don’t want to deal with the design elements or the coding, and would rather put your trust and faith in a professional who makes it their business to create attractive websites.  To us, customizing Thesis represented a conflict of interest.

What is GPL?

As stated on our GPL page, the GPL is a software license.  WordPress was forked from an earlier blogging platform that was no longer being developed, called B2.  B2 was released under the GPLv2 license.  Under the terms of the license, any derivative software, modifications, or forks must be released under the same license (or a later version of the license).  So, for example, WordPress could potentially be released under the GPLv3 license, but it could not be released under a more restrictive, proprietary license (like Thesis), or even an alternate open source license like a  Creative Commons license, BSD license or MIT license.  This is an important point, as there has been some discussion of WordPress simply adopting a less-restrictive license: they can’t.  By the terms of the GPL under which the original code was written for B2, WordPress cannot legally adopt another license.  Period.

Our bias towards the GPL

I’ve been a fan of open source for years, ever since I discovered that you could find a free, open source alternative to just about any application you were looking for.  I’ve dabbled more than a little with Linux and used a variety of different open source web software applications for different tasks.  When we finished building our Museum Themes and started getting the site ready for distribution, we were forced to think about licenses.  When Museum Themes was just an idea, licensing wasn’t something we thought about much.  We considered doing a user license and a developer license and a multi-use license.  But when it came closer and I was building up the site, I did extensive research on WordPress, the GPL, and the pros, cons, and debate about whether it’s even applicable (or whether that matters at all).  In the end, we embraced the GPL not because we believed, as derivative software, we’re required to use the GNU Public License or a GPL-compatible license ourselves, and not because StudioPress, WooThemes and many others have embraced it.  It came down to what we wanted to do with our themes and what we wanted our users to do with our themes.

I can — without question — understand not wanting people to steal your code.  We worked long and hard on these themes.  The last thing we’d want is someone else to sell them cheaper than what we are (or put them somewhere for free) after spending so much time on them and losing our fledgling business before it’s even had a chance to spread its wings.  So I can understand Chris Pearson putting a restrictive license on his software; he wants to protect his investment and his intellectual property.  On the other hand, we asked ourselves: what do we want our users to be able to do?  Do we want our users to take our themes and modify them to their heart’s content? Yes.  Do we ever want to limit or restrict how our users use our themes or in what context or otherwise prevent them from using it in any way they see fit? No.  We really don’t.  Do we want to be compensated for putting in weeks and months of hard work designing and coding and then maintaining this site and all future updates? Yes.  Would we be willing to fully offer support to users who purchased our themes through official channels? Absolutely.  Broken down into those terms, adopting the GPL seemed like a no-brainer, and a perfect fit for us.

So we have a partial bias towards the GPL, although we did explore all avenues when we were considering licensing for Museum Themes.

The argument

The debate comes down to this: Matt Mullenweg, founder of Automattic and WordPress, believes themes are derivative works, and therefore require a GPL-compatible license if you are planning on distributing your theme.

Chris Pearson, founder of DIYThemes and Thesis, believes the GPL doesn’t apply to themes, or to him, and doesn’t feel right about releasing his work under any license that requires you to provide the source for free.

There is no precedent in any United States court on this topic, though a some related cases have been tossed around.  According to Matt, in the United States, any time the GPL came into question on an issue like this, the major companies have backed down and settled out of court.

Chris Pearson cites a Florida lawyer’s analysis on the GPL as it relates to WordPress themes, and ultimately determines that themes are not derivatives, fall within the scope of “fair use” and, therefore, the GPL not only does not apply, but doesn’t matter.

Matt Mullenweg asked the Software Freedom Law Center (a pro bono consortium of legal experts with regards to the GPL) to analyse the way WordPress used themes and provide their analysis.  They determined that themes, based on how they interacted with the core WordPress software, were derivatives and therefore fell under the scope of the GPL (although images and CSS files didn’t need to be GPL explicitly since they had no direct relationship with the core WordPress functionality).

And so the debate has been.  Now we’re all caught up to right about where we were last Wednesday when two things happened almost simultaneously: 1) Bill Erickson, a WordPress developer and consultant was dropped from the list of WordPress consultants on the official WordPress site for endorsing Thesis and 2) Thesis 1.7 and 1.8-beta downloads were injected with malicious code.  This started some heated comments to get thrown back and forth on Twitter by both Pearson and Matt Mullenweg and their respective legions, culminating in both appearing live on Mixergy to duke it out (figuratively).  (You can listen to the replay, watch the whole thing, or read the transcript on Mixergy.)

As much as I’d like to, I won’t get into the actual debate and some of the classic comments that will likely be tossed around the internet for months, if not years to come.  The Reader’s Digest version is this: it amounted to nothing.  Both parties were pissed off (though Matt did a much better job of handling it diplomatically while Chris seemed to be verging on hysteria for the last half of the interview), but in the end, Chris Pearson said he would be “personally fraudulent” if he adopted any sort of license that went against his own personal beliefs (in adopting the GPL).  Furthermore, he said the GPL was one of those laws that wasn’t enforceable, comparing it to a Georgia law that prohibited blowjobs.

Despite claims of “character assassination” that Chris made on Twitter, really, the only character assassin by the end of the interview — if there was one — was Chris himself.  However, anyone who’s followed him for any amount of time would know that this is not a new thing.  He’s always been brash and argumentative, verging on nonsensical at times with his perpetual habit of getting lost in tangents and forgetting the question.  Here he is bullying a poor Thesis fanboy into pulling down the theme he created that was designed to emulate (at least in appearances) Thesis.  Here he is going ballistic about Matt Mullenweg giving credit to the open source community for the 7 year anniversary of WordPress.

Chris Pearson’s personality does not prove or disprove the issue of GPL violation.  It doesn’t look good, and certainly explains (at least to some extent) his resistance at adopting the GPL, but it doesn’t matter no matter how much his attitude seemed similar to a person walking into a grocery store and saying “I don’t really feel like paying five bucks for these apples, here’s one, which is what I feel they’re worth.”  At this point in the story, that’s where things would sit.


Various theories and arguments have been tossed back and forth.  The, now standard, defense that themes are not required to be GPL and it doesn’t matter anyway by Mike Wasylik continued to be Thesis’ main defense.  He contends:

It’s just not enough to say that themes running on top of, and using function calls from, a piece of software are “derivative” of that software. If that were the case, then any software application would be a derivative work of the operating system it runs on – such as Windows, Linux, or OS X – which in turn would be a derivative work of the software hard-coded into the chips running the computer. For that is the way all software works, down to the bare iron – it sits on top of, and makes function calls to, the software layer beneath it, until to get down to the silicon pathways in the chip itself. No software could run without those lower layers, and nothing is truly independent of them. But “dependent” and “derivative” are not the same thing.

Programmer Drew Blas sums it up this way:

The long and short is that SFLC’s opinion could be applied to any software that runs on Linux. Meaning you could never have a closed-source software product running on the linux kernel (“Oh, your code calls fork()? GPL!”). It is commonly accepted that simply integrating with an existing product does not produce a derivative work. If your code is totally your own, the GPL has no say over how you license it.

However, WordPress’ lead developer Mark Jaquith has a well-written counter-argument to that the thesis to which is that “themes interact with WordPress (and WordPress with themes) the exact same way that WordPress interacts with itself.”  “They do not run separately,” he says.  “They run as one cohesive unit. They don’t even run in a sequential order. WordPress starts up, WordPress tells the theme to run its functions and register its hooks and filters, then WordPress runs some queries, then WordPress calls the appropriate theme PHP file, and then the theme hooks into the queried WordPress data and uses WordPress functions to display it, and then WordPress shuts down and finishes the request. On that simple view, it looks like a multi-layered sandwich. But the integration is even more amalgamated than the sandwich analogy suggests.”

I’m not a software developer, or a legal expert (this much should be obvious), but it seems to me, using the same Linux comparison, that this would be less like a single application running on the Linux platform (which would be allowed under the GPL if the application didn’t call any GPL-specific libraries or functions or include any GPL code) and more like an entire distribution of Linux (Ubuntu, RedHat, Slackware, Gentoo, etc).  Sure, for the 5 seconds it takes to boot up to GRUB, you’re free and clear, but everything after that is touched by the specific distribution, from the loading screen to the desktop environment.  Saying that could be released under a non-GPL license would mean that all the software used in that distribution would need to be proprietary — no GPL software could be used as part of the closed-license distribution.  It’s like booting up Linux and getting a Windows desktop instead.  (In recent history SCO attempted to claim copyright over Linux code, which would have resulted in Linux users and developers being required to pay a royalty fee to use it.  They lost.)

But then the plot thickened…

See, the derivative (or not) argument is an interpretation.  Now, granted, it’s an interpretation that Joomla! and Drupal both stand by, but still, it’s an interpretation, and whether it would stand up in court is the subject of much debate.  However, after a couple WordPress developers (Andy Peatling & Andrew Nacin) started picking through Thesis code, they found lines that were literally copied and pasted from WordPress into Thesis — a clear GPL violation.  That prompted a programmer, the aforementioned Drew Blas, to write a script that compared Thesis source code with WordPress and identified each bit of substantial code that was obviously lifted from core WordPress.  And that lead to the discovery of what has come to be known as the “copy pasta,” a chunk of code deliberately lifted from WordPress that included this comment:

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

This was added by Rick Beckman (aka KingdomGeek) when he was working for DIYThemes, which he acknowledges on Matt’s blog.  Even the liberal “fair use” argument would no longer apply if large chunks of code were lifted from WordPress.  And this throws a major wrench in Thesis’ operation.  Because even if Chris Pearson removes the offending code (which he says he is working on), all previous versions of Thesis are still GPL.  And arguably, any subsequent versions of Thesis would be considered derivative works and therefore the GPL would still apply.  The only way to avoid the issue entirely would be to rewrite all of Thesis.  Good luck with that.

The thing is, Thesis isn’t even all that fantastic.  From a design standpoint it’s okay, but nothing phenomenally groundbreaking.  As a designer who has worked very closely with users, though, I can guarantee that putting a color wheel and allowing your users to choose the colors for their site is a monumentally bad idea (it’s why we don’t do it).  The problem is that all those options, all that unlimited possibility is overwhelming.  It’s why people buy Thesis and then hire a designer to customize it for them.  It’s failing to do its job.  Other themes, or theme frameworks, can do similar things without as much headache: ShiftNews by WPShift has a lot of the same sorts of customization options and Thematic by ThemeShaper has a solid framework upon which to build child themes.  For that matter, we took all these things into account when we were building Museum Themes, and provided ways to allow you to customize your blog design without making it look like this.  It was sort of the point behind Museum One.  Even then, though, we were careful not to put too much stuff so as to overwhelm casual users, and I think that’s Thesis’ main failing.

Honestly, I can’t see Thesis continuing to be a lasting one-trick-pony.  Increasingly, free and other GPL-compatible premium themes are able to match any level of originality or innovation Thesis may once have had.  And if 1.7 (and many previous versions) are GPL from the code that was copied from WordPress, then Chris Pearson’s worst fear may come true — someone re-releasing it for free, protected by the GPL, or else using it as a framework for another competing theme.  Chris Pearson was right about one thing: users don’t (generally) care about the GPL.  But that’s fine, because they don’t have to; the GPL only really applies if you intend to distribute your theme.  Additionally, it gives you permission to modify the code as much as you please (compare that to a typical Microsoft EULA which defines the terms under which you can use the software, and manipulating any core systemic functions or hacking the software to add customization options or additional functionality is expressly prohibited).  However, a look at Matt’s Twitter stream over the days since he and Chris debated on Mixergy gives evidence that people do care about software licenses, and they care if their theme violates the license under which the software it uses was released.  The cat is out of the bag, and there’s no way to shove it back in.  It will be interesting to see how this progresses and what effect it has on WordPress themes in general, and Thesis in particular.

We’re GPL!

Last night, I spent some time reading about the GNU Public License (GPL).  There’s been a rich and heated debate for years about how the GPL applies to “premium” (generally defined as commercial, for profit, or otherwise non-free) themes and/or how it doesn’t apply/shouldn’t apply/doesn’t matter.  At the heart of the argument is this:

  1. WordPress is free.  Free as in “free beer” and free as in “free speech”.  You can download WordPress for free, you are free to make changes to the core software, install whatever themes or plugins you like, use it for any purpose you wish, or create new themes or new plugins for it for free (or for profit, but more on that later).
  2. Themes take a lot of hard work.  There’s a lot of free themes available (a plethora, in fact), but if there wasn’t a market for “premium” themes — non-free themes that often include support, advanced customization features, custom code, etc — companies like StudioPress, WooThemes and DIY Themes (the makers of Thesis) wouldn’t exist.
  3. Designers and developers — understandably — want to protect their intellectual property.  In the case of a download that can easily be transferred to multiple computers (and, potentially, multiple computer owners), the ownership of their intellectual property is one of the few things they can really lay claim to and there’s very little they can do (other than exclude support and publicly criticize) if someone copies their theme or uses it in a way that they don’t approve of.  It’s precisely the easy transference of  digital files that gets the RIAA all bothered about piracy: it’s really easy to copy an mp3 or a zip file from one computer (and therefore from one person) — who may have actually paid for said file — to another (who probably didn’t).

But here’s the key element: WordPress is released under the GPL, and, as a component of the WordPress software — like it or not — by the terms of the GNU Public License itself, your theme is also under the GPL.

Here’s the difference between open source and closed source: open source means everything in #1 above — you can take the code, change it, use it however you want, and put it back.  You can even sell it.  In fact, the GNU Public License actually specifies that you can — if you so desired — take something, change absolutely nothing at all, and sell it (so long as the you include a copy of the GPL in the copy you’re selling).  So I could take WordPress software — which is free as in beer — and then sell it to someone else.  I wouldn’t, of course, that’s kind of dumb, and, if anyone bought it, it would essentially be taking advantage of the fact that they didn’t realize they could get it for free (probably).  The point is that the GPL is not saying you can’t sell your stuff.  There are companies selling open source software — or extensions of open source software — all over the place; Red Hat Linux is one example, Joomla!’s commercial themes is another.  What the GPL is saying you can’t control what people do with your stuff.

Closed source software, on the other hand, disallows tinkering.  It means that, while you may own a copy of the software (or in the case of non-GPL WordPress themes, the source code), you really only own a license to use said software, and are subject to all sorts of rules and requirements about how you can use it.  Let’s use Microsoft Word as an example; you purchase a copy of Word.  You install it on your system.  You can’t change the software to, say, make it more visually appealing (not outside the confines of what’s built in, anyway).  You can’t add functions to make it behave differently.  You can’t get into the code to see how it works for purely educational or research purposes.  You can’t get into the code, period, since you’re given an executable and not the original source.  Let’s take another example: Google Apps.  I can use Google Docs absolutely free.  What I can’t do is take the Google Apps software and make it work on a computer or device that is completely disconnected from the net.  I can’t customize how it works.  I can’t add features.  I have, literally, no control at all over the software since the software resides on Google’s computers, not mine.  In fact, I don’t even have direct access to the data that I create with the software since it’s stored on Google’s servers!  If Google lost my data, I’d be completely at their mercy with no way of getting it back.

Open source encourages a rich interaction of users, designers and developers working together to make the software better.  Closed source may allow that in certain contexts (such as a developer preview or public beta) but, on the whole, excludes a wider community involvement and potentially alienates tinkerers who would otherwise have been able to learn from and contribute to the project.

What I decided last night was: why are we even having this discussion?

I mean, if we can take WordPress, a platform we love working with and designing for, and build custom themes for individuals or a wider audience through our Museum Themes and make a living from it, why fight it?  Why say you can’t use the software in this or that way?  I understand protecting your work, and I understand that, from a legal standpoint, there isn’t really all that much you can do to a theme developer who decides to release their software under a license that is not compatible with the GPL because almost anything a theme designer does can fall under the umbrella of “fair use”.  I just think it’s a little counter-productive.  It’s like taking the WordPress software and selling it.  Sure, those themes are probably great to use and they won’t disappear anytime soon, and I don’t think the folks that make them are “evil.”  I just think maybe they’re a little lame.

We will never tell you what you can or can’t do with our themes.  And, if you purchased them from this site, we’ll even help you do what you want to do.  You can read more about our stand on free software and the GNU Public License on our GPL page and you can find us, along with many other theme developers, on WordPress’s own Commercially Supported GPL Themes page in the Themes Directory.