Developer Contracts in the Real World

You’ve heard this before: never work without a contract. The problem is, contracts can take different forms and shapes.

This is actually a good thing, as it means that the law allows you to be flexible in allocating the various obligations between you and the client, but it can also make you feel overwhelmed by options and legalese.

Let’s try to shed some light over developers’ contracts.

Important stuff

Some basic legal information, first. I promise I’ll try to keep it short and simple. Web developers usually go with one of two types of contract. One is the “work for hire”, and one is a version of a “service agreement”, that can be more or less long and complicated according to how big the project is. In both cases, you’re considered as an independent contractor under labor and tax laws (while laws my change across states, every civilized country should have some form of independent contractor relationship).

The main difference between the two types of document is in the management of intellectual property (IP — normally IP just means copyright, but the concept includes also patents and trademarks). Copyright belongs to the creator, in the moment the work is “born” (technically, the moment your creative work is embedded in a “fixed format”, that is, you write it down in an text editor).

If you work under a “work for hire”, the copyright of your work is automatically assigned to the client. Instead, if you use a “service agreement”, you can decide if, when and how the copyright of the work created will be assigned. In both cases, you’re exchanging intellectual work — the so-called “deliverables” — with money or equivalent (shares, future revenues, etc).

The List

Contracts are a little bit like code. There are some formulaic parts that are always repeated to make sure everything is covered, and there are the important sections that are unique for every deal. This is why templates are useful: they take care of the formulaic parts for you, so you can concentrate on the relevant parts.

You, and only you, can spell out what you’ll build and how to deliver it. Remember, as you should never deploy code you don’t understand, don’t sign a contract you don’t fully comprehend. I will try to explain some of the main things, but don’t hesitate to go to a lawyer for help.

Time for the exciting stuff: let’s go through the most popular real world examples.

1. AIGA’s Service Agreement for Interactive Projects. This is the gold contractual standard set by AIGA, the professional association of designers. While it was drafted for design jobs, it’s the perfect contract for big projects that involve a lot of design and code. This document is very long (there’s a short version), but is also very protective of the designer/developer interests. If you look at the section that deals with IP, you can see four main possible variations:
   1. Full assignment: after the price has been paid in full (don’t forget this part) you “assign” the copyright to the client, in full as well. This means that he now owns what you created and he can do whatever he wants with it. He usually doesn’t even have to credit you for the work, but this contract lets you keep the right to display the work in your personal portfolio.
   2. Limited license: you keep the ownership of the work, the client pays you a licensing fee to use it. The terms of the license can be as flexible as you want. You might want to let you client use the code for only that specific project, for example. Of course, the broader the license, the higher the price.
   3. Exclusive license: you guarantee to the client that you won’t use the same code or design for other, third party projects. While exclusivity is usually a perfectly acceptable request, you might not want to license exclusively those snippets of code that you recycle for every project (so-called “design tools”). But wait, this has to be subdivided further:
      1. Exclusive with modifications allowed: the clients get not only to use your work, but to edit / adapt it as he pleases.
      2. Exclusive with modifications not allowed: the client can’t change or add into what you did. A pretty rare, but absolutely legal, provision. If you are such a big shot to negotiate this for a good price, cheers for you.
2. Andy Clarke’s Contract Killer is a very different approach compared to AIGA’s. It’s a short contract in plain English, that sets the terms rather bluntly and doesn’t waste much time in miscellaneous legal clauses. Loved by designers, it’s getting popular among developers and UX people, too.
3. Eric Adler’s Website Designer Contract is a good compromise between the AIGA’s legalese party and Clarke’s British humor. While focusing on design, it takes into consideration coding, and has some nice tips to guide you through it to make sure it works for you.
4. Daniel Bearsdley’s Development Service Contract is more oriented to back-end developers, and takes into consideration parts of the code you might want to release under an open source license. This one’s really short though, and for more complicated projects you might want to check out the next examples.
5. Ross Kimbarovsky, a developer and former attorney, published this Contract for Developers Who Hate Contracts with a handy guide to contracts that’s definitely a recommended read. It talks about stuff that a lawyer can’t really help with, like setting milestones, negotiating the agreement without much hassle and writing a decent statement of work.
6. Speaking of SOWs, while they’re not strictly legal documents, statements of work are legally binding and often govern the operational side of the contract. There’s really no single school of thought on writing a good SOW, as it highly depends on your type and style of work, but here’s an example for Digital Advertising.
7. Remember that independent contractor agreements can be also called work for hire.
8. While you’ll mostly use independent contractor agreements like the ones shown so far, you can’t really go without a classic Software License. For large custom software projects, a licensing agreement might be precisely what you need. This example comes from a lawyer, who goes a long way to explain what the different parts mean and the business decisions behind them.
9. App developer? Don’t worry, this Contract for Mobile Application Development Services is a great starting point.
10. Last but not least: consulting. Everybody’s done it or will consult at least once, so bookmark a Technology Consulting Contract.

Conclusion

I hope this curated and explained list of sample developer contracts was useful. If you’re looking for some other template that you might need, see if you can find it in this larger list. Also, feel free to share comments and suggestions in the comments!

Disclaimer: This article wants to be useful and informational, but keep in mind it is not legal advice and all the legal documents cited are only to be used as a starting point. The author, the publisher, Docracy and the original authors of the documents cited disclaim any liability connected to the use of these material without a licensed attorney.