Contract Drafting: Software Development Agreements

Recently, I was presented with a form software development Agreement. I asked a junior associate to give it a markup for outstanding issues as a learning exercise. It reminded me that many critical areas of contract drafting are simply not taught in law school, so consider this a first in a series of tips and pointers for drafting practical agreements.

Software development contracts are a lot like other creative development agreements, in that a person or corporation is creating a new work and transferring the IP rights to its employer. As a result, here are a few things to consider in any contract that controls the transfer of IP rights:

  • Clearly define "Intellectual Property." Make sure that such definition includes not just copyright, but trademark, trade secret, and all patent rights. This definition covers what will, and will not, be owned by the client at the end of the engagement. 
  • Work for Hire. As a client, you will want to ensure that all materials are being made as work for hire, and, if they are not deemed to be work for hire, then all IP rights are assigned to the employer.
  • Further Assurances. Again, as a client, you will want to ensure that the the party rendering the services will agree to execute any documentation acknowledging that the employer owns the IP created, assigning IP created, etc.
  • Further Assistance. Often, the developer's assistance will be needed in the future, whether for the purposes of litigation or aid in filing patents. Typically, such assistance is compensated at the averages rates paid during the original engagement.
  • Limitation of Liability. As a developer/contractor, you are going to want to waive all special and consequential damages, lost profits, interruption of services, and limit only to actual damages. Alternatively, you can limit to the fees paid to the contractor over the last [x] months, or a mutually agreed upon cap. It is not unusual for there to be a separate cap for indemnification liability over IP infringement, i.e., the general cap is at the fees paid over the last three years, but liability for indemnification provisions at 2x-3x those fees. There is often a lot of negotiation on this issue. 
  • Warranty. It is typical to disclaim any and all warranties, but often a client is going to want some sort of warranty that the work product is non-infringing. Carefully consider, either as contractor or client, the level of IP representations made: are you going to make a strict representation of non-infringement? One based on knowledge or negligence? As above, there will usually be negotiation on this issue. I find that, generally, as risk increases for the contractor / developer, rewards should increase as well. So it doesn't make a ton of sense to make a strict IP representation if you aren't getting well paid, as you are basically extending an insurance policy over the IP delivered for very little money.
  • Indemnification. largely the same considerations as the previous two. Consider what acts, either as a contractor or client, you want to indemnify the other party for. It is not unusual to indemnify the other party against third party claims made for breaches of the representations and warranties in the contract or due to your own negligence of willful misconduct.

A few things make software development, in particular, different than most other creative materials development contracts. Let's review them:

  • Pre-existing Materials. Often a contractor will include software developer prior to engagement, outside the scope of engagement, or generally applicable to the contractor's business, to the client. The contractor will want to retain ownership of this material, so they should make sure that the agreement specifies which software, if any, falls into this category, or specify which mechanisms will be used during the engagement for identifying such software. The client will want to consider how this affects pricing as well: essentially, the client will be leasing, and not buying, such software, so they should not expect to pay full freight for it. 
  • Open Source Materials. Contractors may include open source materials in final deliverables. Both parties will want to be up front about what open source agreements they are comfortable with (for instance, corporations tend to really dislike LGPL, for pretty understandable reasons), and make sure that both parties will have clearly established mechanisms for complying with the terms of such licenses. Additionally, the contractor must be sure that they are not incorrectly representing that they are transferring ownership of these materials, as that is simply not within their power.
  • Third party materials. Rather like open source materials, but privately owned software. For instance, if the developer delivers say, copies of Word® or OSX Server® to the client, the client will typically be responsible for procuring / maintaining such licenses. Again, as above, the developer must make sure that it is not incorrectly representing it has the power to transfer ownership of those materials.
  • Residuals. This one is often a big sticking point: typically, there are very strong non-disclosure provisions in software development agreements. Residuals clauses usually read something like this: 
    The Receiving Party shall be free to use for any purpose the Residuals resulting from access to or work with the Confidential Information of the Disclosing Party. "Residuals" means information retained in unaided memory by persons who have had access to the Confidential Information, including ideas, concepts, know-how or techniques contained therein. The Receiving Party shall not have any obligation to pay royalties for work resulting from the use of Residuals. However, this clause shall not be deemed to grant to the Receiving Party a license under the Disclosing Party’s copyrights or patents.
  • Often, developers gain a lot of important insight from complex projects. If clients are unwilling to agree to the above residuals clause, it may be worth considering if extra compensation is warranted.

Next time, I'll discuss how Statements of Work - the above notes are only for the Master Services Agreement. On top of that, in order to ensure that both parties are happy, there should be a detailed Statement of Work that explains what is being developed, milestones, testing criteria, etc. It is a document that requires as much careful thought as the underlying contract itself, and worthy of its own post. 

After that more to come on NDAs, Software Licenses, EULAs, TOS's...

In the meantime, happy drafting.


  1. When you work with the best web development company like , complex agreement is usual things. So this article is good description for everyone, what you need to know before sign an agreement.

  2. Numerous companies are using these apps to reach millions of people and naturally there is a huge competition in the market. And to be in this race one needs to have dedicated software here

  3. Thanks for sharing this useful information. I can also suggest ideals VDR that I had experience with.

  4. Cost is an obvious factor, however it is by no means the most important - what is more important is value-for-money. offshore development company

  5. Hi. If you need any help in programming, we will help you

  6. Today I was pleased with one site better casino web here you will spend time with benefit


Post a Comment

Popular posts from this blog

The Most Important Bitcoin News of the Week: SEC Statement

Why Stack Overflow Doesn’t Care About Ad Blockers – Stack Overflow Blog – A destination for all things related to development at Stack Overflow

“Huge” number of Mac apps vulnerable to hijacking, and a fix is elusive | Ars Technica