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:
- Deliverable
- Warranty
- 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.