12 Dec Key Legal Documents that Software Companies Need to Understand
If you make, sell or license software, you’ll want to have a basic understanding of the common legal documents that are used in your profession. Here’s a field guide to these documents. My goal here is to demystify some terminology that can be confusing, explain what you need to know about each document, and arm you with confidence as you negotiate deals. This is relevant to all of our clients that are custom software developers, Software-as-a-Service developers and licensors, DevOps firms, managed I.T. providers, and website developers. Note: while we represent software firms worldwide, we are an American law firm and some of these terms reflect conventions of the U.S. legal and software worlds.
Independent Contractor Agreement (ICA)
An ICA is typically used by a company or individual hiring another individual to provide a professional service. Common examples include a company hiring a contractor (rather than an employee) as a software developer, graphic designer or marketing consultant. The ICA defines the key terms of the relationship: who gets paid what and when; what is the scope of the contractor’s work; and the contractor, critically, agrees to “assign” intellectual property that she creates to the company hiring her (see “Work-for-Hire Agreement” below).
Letter of Intent (LOI)
Letters of Intent (sometimes also called “Memoranda of Understanding” or MOUs) are agreements that establish two parties’ preliminary agreement to high-level, bare-bones terms of a deal they intend to document in more depth later once they have negotiated further. They are extremely useful tools to use early in a complex negotiation. Before investing serious time (and legal fees) in negotiating an agreement that could run to many dozens of pages and require input from multiple company employees, it can be useful to first quickly establish that the two parties at least agree on some of the major terms. An LOI therefore is a short document that sets out those key terms while making clear that a final agreement has not yet been reached. Sometimes it will also describe the efforts that the parties will make to continue exploring the deal they hope to sign.
You may also find LOIs useful in another, different situation: when seeking capital from angel investors, venture capital firms or other investors or banks. This is generally not as applicable to SaaS companies as it is to custom developers. But if you have potential customers that are prepared to place orders with you as soon as you gain more capital (for example, to hire more developers to build out a new product), you can ask them to provide you with a LOI saying so. Showing that LOI to potential investors can be helpful in demonstrating the market’s demand for your interest.
MSA (Master Services Agreement)
MSAs are often used by companies that do repeat or ongoing work for the same client repeatedly (rather than a company hired to provide a one-off service). In these cases, if the two companies know they’ll be working together for some time, it makes no sense to repeatedly negotiate lengthy contracts each time they do a project together. (In fact, that tends to both drive up legal fees on all sides as well as delay the work while lawyers review the documents each time). Instead, the companies in these cases often enter into two related agreements at the same time:
- a Statement of Work (SOW) that defines a particular project that Company 1 is hiring Company 2 to do in the immediate future; and
- an MSA, an overall agreement that’s intended to be negotiated just once and cover all issues that are likely to arise both under the SOW as well as any other projects that the companies may do together in the future (each of which will entail the creation and approval of a new SOW, which is far more lightweight than an MSA that can often be 30 or 40 pages). The MSA typically addresses all of those issues that are not likely to vary from project to project: compensation and invoicing terms, insurance requirements for either party, clauses that manage business risks (liability and indemnification), and intellectual property license and ownership agreements.
The dual MSA-SOW structure is extremely common for custom software development work, website developers, DevOps firms and managed I.T. companies. It’s also popular with marketing firms, graphic designers and anybody else who anticipates future return business from clients.
While “MSA” is one common name for these types of agreements, they are also sometimes titled “Software Development Agreement,” “Software Development & License Agreement” or other names.
Non-Compete Agreement
In a non-compete agreement, party A agrees with party B that A will not work for companies other than B for a defined period of time. Often that period of time is [the period in which the two parties are doing business] plus [a defined period of time afterwards, like one or two years]. From the viewpoint of the company that is hiring a service provider, they are helpful in reducing the risk that its vendor leverages the knowledge it will gain about the first company to help its competitors.
Non-competes are fairly controversial in the American software community in 2018. Many companies view them as a legitimate and important way to protect trade secrets and manage risk. Others decline to use them, believing they are contrary to the value of encouraging the free circulation of information and talent. Whatever approach you take, it’s helpful to know that non-compete agreements cannot be enforced in all cases. Software firms generally find it difficult to make courts enforce them more than a year or two after an employee leaves the company. And in some states, like California, they’re generally not allowed at all.
Non-Disclosure Agreement (NDA, aka Confidentiality Agreement)
Companies generally use NDAs in two cases: 1) a company asks its employees and freelancers to sign NDAs promising to protect the company’s business secrets and 2) two companies sign an NDA as part of a business deal in which they will exchange sensitive business information. In both cases, the NDA usually says that both that the parties will not disclose the business information to third parties and that they will not use it for their own purposes in ways not contemplated by their business relationship.
Pro tip: legal documents that are titled “Non-disclosure agreement” often in fact contain additional provisions that are unrelated to confidentiality. In particular, it’s common for an “NDA” to also contain a non-solicitation or non-compete agreement. So read those documents very carefully and don’t rely on the characterization used by the person asking you to sign it.
Non-Solicitation Agreement
Non-solicitation agreements require one person or company not to steal customers away from the other. Companies often require their employees to agree that for a period of time after leaving the company, they will not try to poach their former employer’s customers; often they must promise not to try to hire their former coworkers away as well.
Privacy Policy
Virtually all consumer software products and websites are required to show consumers a “Privacy Policy” that discloses how the company collects, shares and uses personal information provided by its users. A California consumer protection law requires this for most of these companies; more importantly, it’s required by the Terms of Use of Google Analytics, Squarespace, and dozens of other companies that most website operators use. (Here’s our deeper dive into why failing to have a Privacy Policy can threaten your ability to use all of those juicy marketing tools). If you’re a business in certainly highly regulated industries — financial services, education and health care, among others — then there may be other privacy laws that your Privacy Policy must also comply with, such as FERPA and HIPAA.
Scope of Work (aka Statement of Work or SOW)
A SOW usually refers to a short, bare-bones document that defines project specifications for a one-off service engagement, and it’s typically only used after two companies have already agreed to a much longer document (see MSA, above) that sets out other terms of their working relationship. In a typical software development SOW, the parties will agree on terms like:
- business requirements that must be met by the software to be built
- deadlines for each major milestone of the development process, from wireframes to acceptance testing to beta testing and public launch
- system requirements: with which operating systems and platforms will the product be compatible?
Service Level Agreement (SLA)
SLAs are common with Software-as-a-Service (SaaS) products. They usually appear as Exhibits to MSAs. They set out the SaaS company’s promises about uptime guarantees that the product will meet, and specifies consequences if the product fails to meet those guarantees. (Often, those consequences are credits that the customer receives against future invoices).
Pro tip: if you’re a SaaS company, see if you can avoid using SLAs. Larger customers will insist on SLAs, but many customers are content instead to receive more general promises from you about the product’s quality and performance. Those alternative promises require less work for your lawyer and the customer’s, saving you both on legal fees and getting the deal signed faster.
Terms of Use (aka Terms of Service)
A Terms of Use is a common name for the contracts that companies use with users of their software or visitors to their website. “Terms of Use” is a popular convention, but they can also be called Terms of Service, End User License Agreements, or Terms & Conditions. Whatever the name, this document establishes the ways that users can and cannot use the product.
Work-for-Hire Agreement (aka “I.P. Transfer Agreement”)
“Work-for-Hire” is a popular name for agreements in which one person or company gives ownership of intellectual property that it creates to another person or company. (“Work-for-Hire” is somewhat inaccurate – we prefer “I.P. Transfer Agreement” even though many people use the terms interchangeably).
Why are I.P. transfer agreements necessary? Because under the U.S. copyright laws, by default, intellectual property is owned initially by the party who creates it. This applies to anything that is subject to copyright protection, including source code, frameworks, scripts, wireframes, UI design elements — all the stuff that designers and developers make that becomes the product.
So when a company hires a freelancer or an outside firm to make software for it, the company does not own that I.P. without an I.P. transfer agreement. If you’re a company hiring freelancers or custom dev shops to build your software, you absolutely must have one of these in place. It must be in writing and it is not a good Do-It-Yourself project. The cost of writing this agreement incorrectly is that you end up without ownership of the software that you paid for.
Related Content
- An overview of Opticliff Law’s Software, Technology and Privacy Law Practice
- Avoiding Legal Headaches When You Change Web Designers
- Website Terms of Use and Privacy Policies: Your Questions Answered!
- Simple Rules for Hiring Independent Contractors
- How Good Software Development Agreements Can Make a Developer’s Life Easier
