This post is about how to protecting your own IP as a contractor. I have three clients who spend their time developing toolsets for three very different business disciplines. One develops websites. Another works in grid computing. A third does cleantech business analysis. They are consultants, or contractors. What this really means that each spends a lot of time building “expertise”–a way of doing things–that can actually be applied to any number of business situations. As such, all three share a problem: Each has received some form of a Consulting Agreement from a customer that says everything my client does on customer time belongs to the customer. In time, each of my clients has turned to me to ask: *How can I protect my methods while giving my customers the deliverables I am being hired to provide?*
The answer is that there are no magic words that will perfectly distinguish your tools from the work product you are developing. However, *paying attention to a few important details* can tip the balance into your favor.
I. *Mind your language*
Many “customer-friendly” consulting agreements have very standard language saying that anything you develop on behalf of the customer is a *Work for Hire.* This is a term under copyright law that gives the customer rights to what you develop. It’s perfectly fine as far as it goes, but you want to distinguish the tools you develop from the actual work product developed for the customer. Make sure you agreement is specific about this – * your engagement agreement should say you are being hired to deliver certain “Work Product” instead of generalized services.* There’s no guarantee that this will avoid conflicts, but it shifts the burden a bit so that the customer will have to show that XYZ was Work Product and not something else.
II. *Define the deliverables carefully*
Going a step further, Work Product should refer to the Statement of Work at the back of a consulting contract. Too often the Statement of Work gets filled with high-level notes from an early email. Your attorney probably won’t know enough about your business to comment on specifics here, so it’s up to you to be careful. Take the time to *write down exactly what you are providing with specificity* – preferably that someone not in your field (e.g. a judge) can understand.
III. *Retain your Residuals*
Residuals are the ideas that stick in your head after you talk to people and work on things. They aren’t part of the Work Product directly – that definitely belongs to the customer. *Residuals are the knowledge you pick up along the way* that aren’t part of the project, but that you learned as a result of the project. It’s a really squishy concept and I wouldn’t stake a business on it, but if your ideas and toolsets are part of the value you provide your clients it may be worth providing that you own the residuals as well. Again, it doesn’t guarantee you won’t have a dispute, but it gives you a little more leverage to negotiate if the customer tries to claim rights to your toolset.
IV. *Scope of License*
Consulting agreements frequently include a “fallback” so that even if some piece of work isn’t considered Work Product or Work for Hire outright, you’ve give the customer a license to it. This is also well and good, but be sure you are getting paid adequately for what you give up. Is the Work Product license exclusive? Is it worldwide in any type of application or is it limited by geography, business use, target market, etc.? *The more exclusivity a customer gets, limiting your ability to license to someone else, the more they should pay you for it.*
IV. *Consult an Attorney*
General thoughts are no substitute for legal advice grounded in your company’s circumstances.
This is not an exhaustive list of things to consider, of course, but I hope it gives readers some ideas on what to watch out for in a consulting agreement. _Disclaimer: Although I am an attorney, this is not legal advice._