Software development is an undertaking no longer limited to technology companies. If you run a business that sells, produces, or licenses software, it’s critical that you have a working understanding of common legal documentation which you will inevitably be asked to sign by your clients, vendors, and (even) adversaries.
We have worked with individuals in the software space, including front-end developers, back-end developers, DevOps firms, IT providers, production support, business analysts, product owners, and scrum masters. We believe there are common concepts that all of these professionals must understand–especially you, the entrepreneur. Why? Because if you’re building a technology platform, you’re probably going to need to hire them at some point. You don’t have to be an expert here, but you need to know enough to be dangerous.
We’ve set out to provide you with a working guide to these documents. Our guide is divided into three sections–getting the deal, managing people, and helping customers.
At ESQx, we understand that the technology space is rife with confusing terminology. However, we believe that good legal representation begins and ends with clear communication–what we are doing, why we are doing it, and most importantly–why it matters to you.
Part I: Getting the Deal
A business arrangement between a software developer and a third party usually follows the same formula. One party will send a Letter of Intent when ready to partake in business. This is followed up with a Master Services Agreement and Statement of Work, usually written together. Lastly a Service Level Agreement will often be appended to the MSA to clarify terms further.
Letter of Intent (LOI)
This letter is an agreement which establishes the basis for two parties to enter into a business agreement with each other. It lays out all of the high-level details of what they intend to accomplish together at the outset of the relationship. LOIs are useful because they can serve as an efficient precursor to further business negotiation, which often involves attorneys entering the fray. This is the purest way to unlock a “meeting of the minds” between two founders before things get complicated.
If you’re a business leader who wants to quickly negotiate a deal before investing a substantial sum of money into legal documentation and fees, it’s very efficient to agree to specific terms at the beginning of the deal. An LOI, ideally, should be short and to the point on what the parties intend to do. It’s also important to explain the efforts that each party will make as they continue to contemplate the deal. It’s just you and your client talking at this stage. Talking is always fun, right?
Wrong. Talking isn’t fun when lawyers get involved (except at ESQx, of course).
Here’s one more situation where LOIs come in handy: when talking to investors, venture capital firms, or banks. These people love using LOIs because they love efficiency, just like you. If you are in a situation where you have potential customers who are prepared to place orders on the condition that you gain additional capital, like hiring a team of software developers to complete your API integrations, it’s standard practice to indicate these terms in the LOI. Doing so is likely to demonstrate your confidence to potential suitors as you demonstrate your business strategy in advance.
Master Services Agreement (alternatively, Software Development Agreement)
Master Services Agreements are contracts that promote efficiency between parties who seek to avoid constantly re-negotiating their contracts, typically in situations where there is repeat or ongoing work happening between parties. Issues which are likely to be addressed by the MSA include costs, invoicing, insurance, licensing, risk management, and intellectual property. The result of an MSA is: reduce legal fees, increase efficiency, and speed up the process.
Companies using an MSA usually use a dual (MSA-SOW) structure, which is common for bespoke software development projects, website projects, and IT projects. Further, it’s increasingly used by graphic designers and marketing firms.
Here’s how it works:
- An overall MSA, which sets out to cover all of the issues likely to come up as these parties work together in the future, contemplating not only the current project at hand, but future projects as yet to be determined. Such projects will require an SOW; yet the MSA creates efficiencies by defining and explaining certain terms that will be referenced in all future SOWs. Think of it as an umbrella contract.
- An SOW defining a project that Party 1 is completing for Party 2, which takes effect in the near future, and relies on the terms set forth in the MSA. It is dependent upon the “master” agreement.
Statement of Work (SOW)
An SOW is a concise contract that defines the basic specifications of a project for a single engagement, typically drafted after two parties have already completed and agreed to their Master Services Agreement. The MSA will define the “big picture” items of the contract, where the SOW is more targeted to specific elements of the work to be completed in this phase of the project.
The SOW will likely contain elements articulating business requirements, system requirements, milestones and deliverables, dates, user acceptance testing, production support, analytics, and warranties. Make sure your SOW references the MSA in a way that allows both documents to work together seamlessly.
Service Level Agreement (SLA)
Typically, you will first see an SLA as an addendum or annex to a Master Service Agreement. Where the MSA outlines critical project details, the SLA clearly defines the operating and procedural guidelines to which the end-product software will be held accountable; for example, if a website does not achieve 99.9% uptime, the SLA may allocate for a credit or discount. SLAs are used extensively by large companies who like to minimize risk and clearly define what to expect from your software service, but a well-crafted MSA may be able to avoid an SLA addendum altogether. It’s less work for your lawyers–and more money in your pocket.
Part II: Managing People
It’s critical you are going into business with people you can trust. This section comprises common agreements you may want to sign with future partners, employees, or independent contractors.
Independent Contractor Agreement (ICA)
Typically, an independent contractor agreement (“ICA” for short) is a document which memorializes and confirms the terms of hiring between a contractor and a contractee. For example, you may employ one of these agreements when hiring a “contractor” (we really should call these people contractees, but we don’t) as a software developer. We don’t hire these people as employees because we likely have a fixed engagement, limited scope of work, and a set amount of money. As such, they do not rise to the level of employees, which saves you a major headache.
Like any good contract, the ICA lays out the major terms of the working relationship: like who gets paid, when they get paid, how much they earn; what is the scope of the work to be done; and (here’s where it gets good…) the contractor will agrees to “assign, now and forever” his intellectual property, thus quieting any future claim on the ownership of his work product. Basically, anything he makes is yours, and yours alone.
Non-Compete Agreement (or Restrictive Covenant)
Non-competes are used extensively in industries where companies want to prevent the loss of clients who are associated with certain markets. For example, TV news personalities often have non-compete agreements barring them from working for competitors within a certain physical distance (typically 100 miles), as not to take viewers from one rival station to the other. In these agreements, the employee agrees that he will not work for rival companies within a certain period of time.
From the viewpoint of the employer, this mitigates risk. From the view of the employee, he probably hates it. There’s no benefit to the employee.
There is an ongoing effort at the federal level to restrict non-competes from use, with the exception of a few notable industries like finance and media. Despite widespread opposition from lawmakers, generally they are legal in Pennsylvania as long as they are not overbroad. Moreover, there are certain contractual obligations employers must satisfy to ensure that the non-compete “sticks.” Courts are not hesitant to throw out non-competes that are incorrectly drafted.
Non-Disclosure Agreement (NDA)
NDAs unilateral contracts where one party, typically an employer, divulges information to a third party or employee and wants the information to stay a secret. The receiving party who signs the NDA has an obligation to not disclose confidential information revealed during the course and scope of his employment. This is a common tool used to safeguard proprietary information to employees or contractors during a business agreement. Being a unilateral contract, it is a “one way” agreement, where the receiving party will agree typically for a sum of consideration (a payment in the course and scope of employment will usually suffice). The NDA will define the term of the engagement, which will usually be “now and forever,” thus continuing on after the project ends.
NDAs are typically bundled with additional provisions that are unrelated to non-disclosure, such as work product ownership, non-compete provisions, and non-solicitation provisions. It’s important to remember that they are often written to be as broad as possible. If possible, get a lawyer to help you understand it.
Confidentiality Agreement
While there are similarities between NDAs and confidentiality agreements, these two oft-confused terms have distinct differences. Where an NDA is a unilateral contract, a confidentiality agreement is a bilateral contract. This means that both parties entering into the agreement have a duty to uphold the confidentiality of what is discussed.
For example, if you are attempting to start a food additive business and have an idea for a new product, you might ask a chemist to sign a confidentiality agreement in contemplation of your future business partnership. Confidentiality agreements, in general, are more “serious” than NDAs in the sense that they require a proactive commitment to safeguard information, and parties may be held liable for negligent disclosure. These agreements are common in the formation stage of new partnerships, military meetings, and corporate transactions.
Work Product Release
While the name sounds confusing at first, a Work Product Release agreement is one whereby a person, typically an employee or contractor, releases any intellectual property right to what he produces during the course and scope of his employment.
For example, if a person employed at a marketing firm designs a beautiful new billboard for a client, it’s essential that the designer does not make any claim of her own to the design. Her work–or work product–is owned exclusively by the company who employed her when she created the design. This agreement is very important for companies because it protects them from lawsuits later. It can apply to any work that is subject to the protection of federal copyright, such as source code, UI design, wireframes, and many of the elements created by developers and designers during a project. If you are hiring an outside company to do this kind of work for you, it’s essential that you have a WPR in place.
Managing Customers
Lastly, customers will “make or break” your success. Therefore it’s critical to factor in their needs as well. This can be done with a privacy policy and terms of service.
Privacy Policy
Data privacy is one of the greatest challenges of the 21st century. As of this writing, almost all end-user-facing software products must show consumers a policy that discloses how the company collects, uses, and shares your personal information. If you are a business contemplating developing software that customers will use, it’s almost certain you will need to develop a cohesive and adaptive privacy policy that clearly states what you plan to do with users’ data.
Terms of Service (TOS)
A Terms of Service is an agreement delivered to customers at the outset of the business relationship, usually at or near the introduction of the privacy policy, that states how the customer is permitted to use the product.
Conclusion
There you have it, folks. We presented you with a full guide to the most important legal documents you’re likely to encounter as a technology business. We hope this guide was most helpful. For more information, please contact an ESQx attorney today.
