What are your legal concerns?
If you are a startup or haven’t used an outside firm to develop software for you there are 3 basic documents you need to consider – a Mutual Non-Disclosure Agreement, A Master Services Agreement and a Statement of Work. This is from a business person’s view, not an attorney’s.
Mutual Non-Disclosure Agreement – the purpose of this document is to protect your idea, i.e. your Intellectual Property (IP). If you feel your idea is unique or if you will be discussing proprietary things during initial discussions, this should be executed before sending detailed requirements to the software firm. It should be mutual, because it is likely the software development firm has as much or more IP than you to protect and you want them to use that to your benefit.
You can find sample documents on the internet, just make sure the one you select has all of the standard exclusions, including reponsibilities in the event a court requires one of the parties disclose confidential information.
Master Services Agreement (MSA) – although small one time projects can be handled by a Statement of Work (SOW), for long or ongoing engagements you should have an MSA in place.
Generally, a MSA will include all of the standard legal terms related to the engagement, but none of the specifics of a particular project. This includes definition of who owns the code and IP from the engagements. This is extremely important. Make sure your attorney is involved, ideally one experienced with software development contracts. One way to tell is to look at the IP section. If it doesn’t reflect modern practices that involve incorporating Open Source or low cost proprietary modules into the code, you need to find more up-to-date wording. The software development firm cannot grant you IP for those modules since they aren’t the owners. They can make sure you have the proper “use” licenses and make sure they are implemented in a way that doesn’t jeopardize your IP for the custom portion of the code.
It is imperative that this be defined in the MSA, or in the SOW if no MSA is in place. Not all states handle code ownership the same in the event it isn’t specifically addressed in a contract. Sometimes it defaults to the client and sometimes it defaults to the developer. A firm I was talking with recently didn’t have this defined and the software company decided they should have ownership of the code.
The MSA should also address such things as: type of services to be performed, cooperation responsibilities, project management responsibilities, term, termination procedures, non-exclusivity, fees/payments, non-solicitation, publicity, jurisdiction and survivorship.
If it is likely that you will be working with the software firm on multiple engagements or if they will be involved in ongoing support of the resultant application, you should do the two step process of an MSA and SOW. There are two main reasons for. First, it covers any gaps for work done between or outside of existing SOWs. Secondly, it eliminates the need to include heavy legalese in each SOW. This speeds the approval process for subsequent SOWs and reduces legal review fees. In general, the less legalese in the SOW, the clearer it is for both sides.
Statement of Work (SOW) – The SOW should cover the specifics of the work to be done on a project – the features to be developed, the costs and the governance process at a minimum so that you know if you’re on track as the project progresses and you know when you’re done. It also should include any terms that are different that the standard terms in the MSA if one is in place. If there is no MSA in place, you need to add a more comprehensive Terms section.
