At Crowd Favorite we work primarily with WordPress, but also with many other Open Source projects. We are often working with larger companies that have standard Master Services Agreements (MSAs) or Professional Services Agreements (PSAs). These agreement templates are designed so that these companies have a known legal foundation to work from, and include a variety of requirements and terms that apply to the consultants working for them and governing the Deliverables created by those consultants. These agreements often have standard language in them that have some interesting side-effects when you are working with Open Source.

It’s common for services agreements to have these components:

1. Deliverable
2. Warranty
3. Indemnification

with a set of terms around each. The standard terms in these agreements likely contain language that may be somewhat problematic when applied to projects built on Open Source.

Deliverable

Let’s look at the Deliverable first. In a standard web site build the deliverable might be loosely defined in this manner:

A custom web site powered by WordPress, using existing and custom created plugins and themes to achieve custom functionality. Consultant will deliver the entire package along with documentation and installation instructions, and will assist with the initial installation and configuration of the site.

The Deliverable described above has five potential parts: WordPress, existing plugin(s), custom plugin(s), existing theme(s), custom theme(s). The Deliverable is generally what the Warranty and Indemnification clause are tied to, so the way it’s defined is important.

Of these five parts, you will probably only have created the custom plugins and custom themes from scratch. The others will be created and licensed by other companies and/or individuals. You do not want to take on full responsibility for these parts of the deliverable in the Warranty and Indemnification clauses.

Warranty

The Warranty part of the contract generally has two parts: terms that cover how bugs will be fixed and for how long; and terms that declare that all of the intellectual property (IP) in the Deliverable is free and clear of infringement.

I’m assuming that you don’t want to be on the hook for every bug that might exist in WordPress (or whatever other Open Source package you are working with), so you need to make sure you get the language here adjusted so that it reflects this. You’ll probably end up in some middle ground on this, as your client will just want the solution you’re building for them to work, but you need to limit what you are willing to take on.

It’s the second part of the Warranty that is particularly dangerous. While you may take on some responsibility for fixing bugs in the overall deliverable, you definitely don’t want to take on responsibility for all of the IP in any Open Source project. If you do this, and it turns out someone in another country committed code that wasn’t legal for them to commit, you’ve just taken on responsibility for that.

We typically resolve this with a “to our knowledge” clause, which covers the client for code we create, but absolves us of responsibility from other Open Source code (assuming we are using code that was properly licensed, etc.). It also covers us in the event we are asked to build something that infringes on an existing patent.

If you breach one or more of the Warranties, then the Indemnification clause comes into play.

Indemnification

Indemnification ties in with the same issues discussed in the Warranty section. In this clause, there is typically language that makes you (the consultant) responsible for any legal issues with the Deliverable (instead of the client, who is using the Deliverable). Like the Warranty clause, the Indemnification clause is a fair and reasonable thing to have in a contract. We just need to tweak it a little so that it makes sense in the Open Source world.

It’s very reasonable to take on this responsibility in regards to any part of the deliverable you build, subcontract out, or are somehow responsible for. However, like with the Warranty clause, you don’t want to take on responsibility for every piece of IP that has made it into the Open Source project you are using.

We typically resolve this by adding either a “to our knowledge” clause or explicitly excluding parts of the deliverable in this area.

In addition, you may want to include something in the Indemnification clause to cover features that are requested by your client, but might infringe on a patent or similar concerns. Typically, the Indemnification clause does make you responsible in these cases and most consultants I know don’t have the resources to do patent searches on every feature that is requested by their clients. If you write code that contains infringing IP and your client is sued, you would be on the hook to pay for any and all or your client’s damages, including legal fees. The knowledge qualifier we use handles this situation as well, and you can also handle it with a specific carve-out if needed.

Hopefully this information will be useful to some of you the next time you’re reviewing a contract for a project. If all of this is new to you and you work in this space – I highly recommend talking with a lawyer who has experience with Open Source.

If you’re in the Denver area, I highly recommend working with Ryan Howell at Rubicon Law Group. We met in 2007 at the first StartupWeekend in Boulder and he’s been working with me and Crowd Favorite ever since.

Some contracts also expressly forbid the use of Open Source software and/or software licensed under a specific license as part of their standard terms. Getting this fixed is generally not a problem since you and the client should be in agreement that you are planning to use Open Source tools in the project. I’m assuming we’re all used to dealing with this one already, but wanted to call it out as well.

We put up the first entry in the showcase (the Carrington web site – very meta) and will be adding a few more sites in the near future; but really we’re excited to see what you have been building with the Carrington framework. Hopefully this is a nice way for us to offer a little publicity for Carrington designers and developers and a nice way for people to see what can be done with Carrington.

Of course, not everyone uses all of this flexibility. A number of conventions are typically followed in theme development; mostly stemming from the structure of the “default” theme that ships with WordPress. One of these is the footer.php file.

In many themes the footer.php includes the wp_footer(); call, which in turn allows plugins to add information to that part of your HTML page. This is commonly used by analytics, widgets, etc. that need to load code in the page.

All themes should have the wp_footer(); code in them – it’s important so that plugins that need that call can work properly. It’s important enough that the theme upload process at WordPress.org checks to make sure that the call exists. I think this sort of sanity checking is excellent – it allows WordPress plugins and themes to work nicely in conjunction with each other.

That said…

As previously mentioned, one of the great things about WordPress themes is their flexibility. The wp_footer(); can exist in any file, not just in one called footer.php.

When a plugin makes an assumption about where to look for this call and shows an warning message like this one:

Warning wp_footer(); not found in your footer.php file, this might mean this plugin will not work!

without checking the other theme files to see if wp_footer(); is there or not, it causes the user to think that the plugin and/or theme may be broken. If you’re going to take the trouble to check files for a function call, don’t make assumptions about where you decide to look for the call. Allow themes to innovate, create new best practices and do interesting things – without concern of plugins complaining because they are expecting a certain convention.

This was brought up recently with our Carrington Blog theme¹ – but it’s a bigger issue than just one person using this particular theme; hence this post for the general community.

1. For users of our Carrington themes, I can assure you that all required theme hooks are present and anything requiring wp_footer(); has what it needs to work just fine. [back]

Changes since beta 1:

• Added tag reports. I’m pretty pleased at how these work – you type in the name of a tag you want a report on, it will auto-complete just like in the tags form on the New Post page, and then bring back the tag report when you hit Add.
• Added nice re-flowing code so that reports take up all available horizontal space when displaying.
• Added some additional refinements to the overall Popularity list at the top of the reports page.
• Added a Last (n) Days option to the widget (you can configure the # of days for the widget).
• Removed tags from category reports list.
• Fixed an issue with AJAX deletion of comments.
• Fixed a divide by 0 error that I’m not sure how could happen, but apparently did for someone. The code is more robust now anyway.
• Don’t add JavaScript code to the post content if not using the API (default) method of recording views.
• Works around a broken data situation where there are no rows in the Popularity Contest options table. I have no idea how you’d trigger this situtation, and still can’t reproduce the issue – but now the code works around it. Thanks to Dave (who apparently has never heard of Hanlon’s Razor) for finding the cause of the issue.

Known Issue in beta 2:

When installing for the first time, the WordPress plugins page reports an error:

Plugin could not be activated because it triggered a fatal error.

with an empty “fatal error” message. It also successfully activates the plugin and creates the proper default settings – everything seems to work just as planned. I spent a few minutes playing with various things, but without any error message or anything in the error log, I haven’t found the cause of this yet. If any other devs have time to check this out, I’d certainly appreciate the help.

Aside from this and perhaps a few minor tweaks based on feedback, I think this is just about ready for the final 2.0 release.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter or you can try the WP Support Forums.

The new version of WordPress Mobile Edition is really a developer release. This version adds API access so that other plugins can participate in mobile device checking and add to the settings page for WordPress Mobile Edition.

I was contacted by a developer who was interested in adding to the plugin, and after reviewing his proposed changes that integrated with his (account required) service, I thought they were interesting but would be better as a separate plugin rather than part of the default distribution.

As a result, I added a couple of simple APIs that gave him the access he needed. I’m releasing this new version so anyone can build a plugin that leverages, enhances or extends WordPress Mobile Edition.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter (512-788-9236) or you can try the WP Support Forums.

I get a lot of requests for features/changes that are specific to someone’s needs. Since (unfortunately) I can’t build specific features for each user into the general plugin, I’ve done the next best thing – I’ve added hooks and filters so that other folks can write plugins for Twitter Tools just like they can for WordPress.

To make sure these hooks and filters work properly, I’ve created three plugins for Twitter Tools that provide commonly requested features:

• Bit.ly for Twitter Tools – enables shortening your URLs with Bit.ly and tracking them on your Bit.ly account.
• #hashtags for Twitter Tools – enables adding hashtags to your blog post tweets.¹
• Exclude Category for Twitter Tools – enables not tweeting posts in chosen categories.

Each of these plugins needs to be activated individually from your Plugins page, and adds their configuration options to the Twitter Tools settings page. You can grab the latest development version of Twitter Tools and these additional plugins from the official SVN repository:

http://svn.wp-plugins.org/twitter-tools/trunk/

I’ve been working on these and doing a bunch of testing this weekend, but I’d love to get some additional testing and feedback on these before I do an official release. Let me know how they work for you – and think about some plugins of your own to write.

1. This uses a fairly complex method of trimming the title as needed to make room for the hashtags – patches to improve/simplify that system while maintaining the functionality are very welcome. [back]

# | Visit Site »

Regardless of my intent, in retrospect I regret the way in which I raised the topic and how I authored the post. I’ve never (intentionally) used this blog as a lightning rod or flame bait, and I didn’t intend to start with that post. My sincere apologies to the theme devs that have recently GPL’ed their code (WooThemes, StudioPress, iThemes and any others).

At the risk of sticking my other foot in my mouth (wouldn’t be the first time), I’d like to revisit one of the core issues around these paid GPL themes, using the following scenario as an illustration.

Imagine: a client comes to me and asks to me to build a site for them using WordPress and a paid GPL theme. The ciient also wants a set of customizations made to the theme and site functionality. Some of the custom functionality requested is different visual treatments for each post, based on the post category. This is a fairly common request for larger publishing sites, and one of the reasons we built the Carrington CMS theme framework (which automates this).

The approach I’d take here is to use the paid GPL theme, and integrate the Carrington framework for handling the post display with custom templates in the paid GPL theme.

Now (assuming the client is fine with releasing the code) I have at worst a reference implementation and at best a working theme that could be useful to other developers, end-users, etc. in the WordPress community.

Everything in the chain (WordPress, the paid GPL theme and the Carrington framework) are all GPL licensed. My preference would be to make this code available so that others can build on it as well. Developers love examples, and I think it would be useful to show how easily the Carrington framework can be surgically integrated into a theme to provide certain functionality and make their lives easier.

What would the reaction be if I released this code?

I think it’s clear from the comments on my last post, there are some people in the community that would think this “isn’t playing fair” or “shows lack of respect”.

Isn’t that the opposite of the spirit of Open Source and the GPL? Shouldn’t we be celebrating the ability to share code and build on what each other has created?

I obviously have a vested interest in the WordPress ecosystem remaining strong. I also want people to be able to make a commercial living in that ecosystem (my team included).

However, I don’t think it’s reasonable to build that ecosystem on the premise that we should ignore certain freedoms of the GPL – and I feel like some folks are asking for that to happen.

I think it’s worth discussing.

The main issue with updating it was that I felt that the old implementation was somewhat broken. It didn’t work with caching, it didn’t handle tags and other new features introduced in recent versions of WordPress. In short, it needed a rewrite. And that is what it got in version 2.0.

• This version is completely cache compatible. It uses JavaScript and image loading techniques to do the view counting. It also has a nice widget options for showing various reports on the front-end.
• There is now an option to exclude views from site authors, which was a commonly requested feature.
• The back-end reports have been redone a bit, and tag reports still need to be added. Those will take a little more work to implement properly.
• We also updated the code to use more official WordPress API functions (many of which didn’t exist when this plugin was originally created).

It’s been a good deal of work getting it all updated and ready for release, but hopefully this version will work better than ever for everyone.

This is a beta release because it hasn’t had widespread testing (yet). Your feedback is requested – please let me know if you run into issues. Posting issues in the comments here is ok for this one.

The download and more information are available on my WordPress Plugins page.

If you have any general trouble with this, please contact the WordPress HelpCenter or you can try the WP Support Forums.

1. Did not work on versions of WordPress greater than 2.3. [back]

It’s great to see theme developers doing the right thing and releasing their themes under the GPL. Examples: WooThemes, Revolution.

The GPL v2 has the following clause in it (right at the top – emphasis mine):

1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

The GPL v3 has a similar clause (again, emphasis mine):

4. Conveying Verbatim Copies.

You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

While there is absolutely nothing wrong with charging for GPL’ed themes (not making them available for free), if I receive a theme under the GPL I can then redistribute it (for free or for a fee) as a right granted by the GPL.

So I can then choose to set up site where I make all of the GPL licensed themes that I purchased available for free download, under the terms of the GPL.

The GPL also allows for derivative works.

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: [...]

So I can make a few changes to the themes (for example, port parts of them to the Carrington framework for easier development and modification), and distribute those as well.

Yay for software freedoms!

I purchased all of the WooThemes and StudioPress themes this morning. Which should I do first, set up free distribution of these GPL themes or start integrating the Carrington CMS theme framework into them?

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter or you can try the WP Support Forums.

In this release I’ve added a nicer UI for marking posts as articles, and as a side effect any users of previous versions will need to use the Upgrade button (on the settings page) to migrate their data to the latest version.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter or you can try the WP Support Forums.

I’ve had to upgrade a bunch of my plugins in the process, bringing them current with the latest and greatest WordPress code and best practices. Expect a couple more plugin releases soon.

I also took the opportunity to switch everything from Prototype to jQuery – resulting in lighter JavaScript and lighter page loads.

So a bunch of stuff was changed, if you see breakage around the site I’d appreciate it if you let me know.

UPDATE: feeds should be working again. Oops!

This version has a couple of changes:

1. Added support for the Palm Pre (and other Palm webOS devices).
2. Added the Palm Pre as a touch device.
3. Fixed a CSS bug that was referencing a non-existent image.

This includes a new version of Carrington Mobile as well, which includes updated README files and version 2.3 of the core Carrington framework.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter or you can try the WP Support Forums.

I’ll also be helping staff the Genius Bar from 2:55-3:30pm, so feel free to stop by (perhaps with some Carrington questions). I’m looking forward to helping out.

Unfortunately I’ll miss the developer day since we booked our flights before it was planned. That’s a shame, but maybe next time – I’m sure I’ll get a chance to hang out with a bunch of the devs on Sat.