Blog

BIG FAT DISCLAIMER: I am not a lawyer, nor do I play one on TV. I have, however, been working in the Open Source consulting and development space for a number of years and think this is an important issue for all Open Source consultants to consider. Please consult your own lawyer, don’t blame me, etc.

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.

Popularity: 1% [?]

A new beta of my Popularity Contest plugin for WordPress is available – this has some minor bug fixes and some new features and nicer handling of some edge cases. Since this version is the best known version, I have made it the default download at WordPress.org’s plugin hosting.

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.

Popularity: 1% [?]