If you’ve never worked through contracting for custom software development services, it can be challenging. Your existing software development contract templates may be rooted in business relationships focused on purchasing tangible goods or pre-existing software. Custom software development contracts have unique considerations and require a slight shift in mindset.
I work with Atomic’s clients and our legal team through many of our contract discussions. I’ve found common, recurring considerations in contract discussions, and I’m sharing my experience and insights to help you understand the logic behind the legal language and redlining that you might experience in the contracting process.
Disclaimer
This post is not formal legal advice. I’m not a lawyer. I recommend you work with legal professionals for all of your software contract needs.
For long-term relationships or large projects, contracts are usually separated into two types: the Master Service Agreement (MSA) and the Statement of Work (SOW).
When I write about contracts, I will be referring to the terms included in an MSA. Different organizations will use different names for an MSA like an “Independent Contractor Agreement” or “Professional Services Agreement.” Regardless of the specific contact name, the intent is the same.
The MSA will contain the legal language framing all project work done under the MSA. Other considerations covered in an MSA may include:
MSAs usually have agreement terms that span multiple years or have an indefinite term unless they are terminated by one of the parties. Putting all of the general, legal language in a long-term MSA means SOWs can focus on specific project details and be reviewed and executed more expediently.
SOWs will contain specifics about a project. SOWs will commonly include a high-level project plan including:
SOWs will reference the MSA and be bound the terms of MSA as if the MSA terms were logically included in the SOW.
Note: This post assumes you’re hiring a partner to provide you with software development services. And that you’re planning to allow your customers, employers, or other stakeholders to use the software they make.
An established company may have created many MSAs over the year. But most are for purchasing physical materials/equipment, pre-developed software, or professional services like legal, accounting, marketing, etc.
What do these all have in common? The deliverables are:
Neither of these is true for custom software services.
Providing custom software services is different from delivering pre-built software. And it needs a different kind of MSA.
Custom software contracts need to be clear about intellectual property rights—the ownership and use rights for each component in the final product. A software product can have some components that are custom, some that are open-source, and others that are commercially licensed. And each can have separate IP rights.
The author of any creative work inherently owns the intellectual property rights to their work. Without agreeing otherwise, the code a software developer writes belongs to that developer.
You want to make sure your contract assigns ownership of all original, creative works developed under the contract to your company. Your contract should define all deliverables created as original work under your contract as “works made for hire” and assign your company as exclusive owner of all original works and their related intellectual property rights.
Your partner needs to own the deliverables and related intellectual property rights in order to assign them to you. They should have similar agreements in place with their employees and contractors in order to assign the creative works and related intellectual property rights created by the people who work for them to their business. This chain of agreements assigns ownership and IP rights from the author to your partner, and then to you.
You can expect your partner to have terms specifying when ownership is assigned. It’s common for custom software firms to assign ownership of deliverables upon payment for the deliverables. Assuming your projects are using Agile software practices and deliverables are being continuously delivered, you will be receiving deliverables on a daily basis.
Many custom software providers invoice based on the time spent creating deliverables. You will receive invoices for a period of time (e.g. hours, or development team weeks, etc.) and will own the received deliverables created during the duration of the invoice upon payment of the invoice.
Custom software applications commonly include pre-existing work. For example, a web application will include pre-existing work like a web framework and supporting libraries.
Pre-existing work is used by your partner for your benefit. Instead of creating everything from scratch, your partner is using pre-existing work to save you time and money.
This type of work can be created by your partner or a third party.
It’s important for you to know what pre-existing work is included in your deliverables and to understand your rights and limitations related to the pre-existing work.
I recommend asking your partner to maintain and supply an inventory of all pre-existing work included in your deliverables. It should include the specific version and source of any pre-existing work, along with related license information. The inventory will serve as a reference for you to help manage your rights and limitations related to the portions of the deliverables you don’t exclusively own.
You should expect your partner to use their professional expertise to guide your selection of any pre-existing work included in the deliverables. Based on your commercial expectations for the deliverables, your partner should be able to recommend pre-existing work with the appropriate licenses.
Keep in mind that your partner’s expertise will be primarily focused on the technical and functional considerations related to the included pre-existing work. Your software partner will not likely take on a contractual obligation to provide you formal, legal advice of any kind.
You should also expect to own the responsibility of managing the benefits, limitations, and risks of including pre-existing work in your deliverables, based on your intentions of using the deliverables. You need to carefully consider your rights and limitations related to pre-existing work from third parties and your partner.
A competent software partner will help steer you toward frameworks and libraries that, to their knowledge, have appropriate licenses. However, you should also engage the help of a legal professional to carefully consider the license terms of any pre-existing work you will include in your product in the context of how you will be using the pre-existing work.
When you include and use third-party, pre-existing work in your product, you are creating another relationship with those parties. You shouldn’t expect the contract you have with your partner to make representations or promises about any license terms related to third-party, pre-existing work, as those terms are defined in each third-party license.
Some pre-existing work may be open-source software and have a generally-known, publicly available license.
Other pre-existing work may be closed-source, purchased, and have a unique license agreement.
You will want to make sure the license terms of all third-party, pre-existing software enable you to meet your commercial goals. Some people unnecessarily fear open-source software due to common license terms that require any solution using the open-source software to also be open-source. However, there are many open-source software licenses with more commercially friendly terms.
You can expect the contract with your partner to include license terms for any pre-existing work provided by your partner.
It’s common for custom software partners to have tools and libraries they created for general use across many of their development projects.
At Atomic, we make revenue from the custom software we write for our clients. We don’t charge license fees for our pre-existing work. We include our pre-existing work, as appropriate, to help speed development and focus the project budget on custom development work.
Even if your partner includes their pre-existing work like Atomic does, and you don’t have to purchase it, I recommend that your contract includes general license terms related to all partner-developed, pre-existing work included in their deliverables.
I also recommend making the general license terms as permissive as possible. You should expect a non-exclusive license, as your partner will likely be using their pre-existing work in other client projects. However, you should be able to use the pre-existing in any way possible to further your commercial goals. For instance, you should be able to use, reproduce, sub-license, and make derivative works of your partner’s pre-existing work as necessary to achieve commercial success with your broader software product.
Your partner may reasonably expect that you don’t do things like publish or sell their pre-existing work independently from the overall software solution.
When it comes to IP infringement risk, I like to keep the following principles in mind:
When you are buying custom software services, you are effectively buying your partner’s time to create original work on your behalf. Your partner will likely charge you an hourly rate for their time. They have no greater reward or leverage other than the agreed-upon compensation for their time.
You will be working to create leverage from your custom software investment. When you make an upfront investment of capital, you’ll want to maximize the recurring revenue it can generate.
Your contract should obligate your partner to own the risks of copyright, trademark, and trade secret infringement for their works made for hire and their pre-existing work included in your deliverables. You should expect that your partner isn’t copying code that they (or others) have previously written and delivering it you represented as original work. You should also expect that your partner is not misappropriating a trade secret they have learned through their work with another client.
If such an infringement occurs, it’s reasonable to expect your partner to replace or pay for the replacement of any infringing deliverables. This remedy is on scale with the level of value exchange for the original services.
Your partner probably won’t take on liability for any indirect damages resulting from the infringement, as those potential damages scale with your level of commercialization success and are best managed by you.
It’s also unlikely that your partner will take on liability for copyright, trademark, or trade secret infringement risk in any third-party, pre-existing work included in the deliverables. Because you are receiving the speed and cost benefits from using pre-existing work, you should be willing to take on the risk of needing to replace third-party, pre-existing work for infringement or any other reason. You can work to manage infringement risk with third-party materials by relying on legal professionals during your review of the third-party license terms.
Your partner will also likely include contract terms that they will not take on infringement risk for including any deliverables supplied by you or created under any detailed specifications you provide.
While you can expect your partner to not knowingly violate any patents in their works made for hire or pre-existing work, you shouldn’t expect them to take on patent infringement liability for any of the deliverables.
Custom software engagements are highly collaborative, and your partner will be creating original work that is guided by your goals, needs, industry expertise, and existing knowledge. You know your industry and competitive landscape better than your partner. Patent infringement risk belongs as a key consideration of your broader risk management activities related to product development and commercialization.
Your partner will be evaluating third-party materials from a technical perspective, but not from a legal one. Because you will be getting the speed and cost benefits from using pre-existing work, you should be willing to take on the infringement risk.
Your risk of a patent infringement claim, legitimate or not, scales with your commercial success. Unfortunately, the more successful you are, the bigger target you become. This is another reason for you to own patent infringement risk management and liability. You are pursuing the bigger reward, and the value you create from your investment should be able to cover any risk that materializes.
If your partner held patent infringement risk, their risk would grow as you become more successful. This doesn’t make sense, as your partner had the fixed upside of the fees for their service. Also, remember that you are only engaging your partner for their time and technical expertise. Your software partner is not providing legal services related to patent infringement.
I recommend you work with legal professionals early on to understand if there are parts of your software product that could be infringing. You then should let your partner know of any legal considerations they should use as constraints when designing and developing your product. With that preparation, you will be ready to show due diligence and documentation if an infringement claim is ever made.
Custom software services contracts should call out the promises you and your partner make to each other. The contract should also define who will be responsible, and to what degree, if certain issues arise.
Warranties are promises between you and your partner related to the services being performed.
It’s reasonable to expect some guarantees from your custom software partner.
In general, you should expect your partner’s services to be performed:
I believe the points above adequately convey what you should generally expect your partner to guarantee. However, you may want to call out other expectations you have.
In my experience, I’ve seen additional warranty expectations include:
When it comes to warranties, it’s important to remember that purchasing custom software development services is much different from buying a pre-existing software package.
Your partner will be collaboratively and iteratively working with you to define a specification for the solution. The Agile design and development process allows for specification definition, implementation, and refinement throughout an engagement. You can expect to discover and fix minor defects and bugs during custom software projects.
Agile methodology is essentially like going through a research and development process that results in a high-quality solution you can commercialize. It’s a world apart from buying a mostly pre-developed solution to use or resell with minor modifications.
Once the software is delivered, your partner likely has no control over:
Due to the points above, your partner will likely provide the solutions “as is.” They will not explicitly or implicitly guarantee that the created solution:
Indemnifications are guarantees between you and your partner to hold one another harmless and assume costs related to defined events.
It’s important to remember that you are taking on the risk of developing and commercializing a custom software product. You can expect your partner to provide warranties related to the things they can control, but it’s not common for a development partner to protect you or compensate you for any other harm or loss in your efforts.
Your partner can control that their custom work for you is original and not copied or taken from another source. You should expect them to indemnify you against copyright, trademark, and trade secret infringement related to their original works.
It’s also unlikely that your partner will indemnify you from any other risks of commercializing the software solution or running your software-related business. Any other promises you want from your partner can be defined as warranties.
It might seem odd at first, but your partner will probably ask for you to indemnify them from certain risks. Because you will likely be running a software business with the collaboratively created solution as a core offering, your partner will want to be protected from the risks you take on in reward for growing your customer base. Once delivered to you, your partner has no control over how you use the solution or what promises you make to your customers about the solution.
Your partner will likely ask you to protect them from harm or loss resulting from:
Your partner should agree to some level of liability that is related to the warranties and indemnifications in your agreement.
It’s important to remember that your partner is essentially selling their time to collaboratively create a software solution with you. They will have a limited, maximum return for the services they provide. Accordingly, they will want a limited, cumulative level of liability. Liability can be limited based on dollars and the time frame when a liability obligation occurs.
In my experience, I’ve set liability caps based on:
You can expect your partner to assume liability for the things they can control and offer as warranties and indemnifications. Your partner will have no control over how you sell or use the software solution you have collaboratively created. Your partner also has no control over the value or risks related to how your customers use your software solution.
Therefore, your partner will probably not explicitly assume any liability to you or any third party for any other loss, additional expense, or damages that might arise from the sale and use of the software solution.
Sometimes, an engagement doesn’t go according to plan, and it’s a good idea to agree on what to expect if this occurs. Custom software contracts commonly define how to fix a situation if expectations aren’t being met, and they may also define rights for terminating an engagement.
Contract breaches occur when one partner doesn’t fulfill a promise made in the contract or in a specific statement of work. You can define specific actions and time periods for fixing a breach in the warranties section of your contract. Fixing a breach is commonly called a cure.
Some contracts specify a review and acceptance process and period for deliverables, allowing you to reserve the right to review deliverables and make sure they meet your expectations. A common pattern I see is:
Sometimes, the process above gets even more complicated, allowing multiple attempts and different time periods to replace the deliverables, affect payment, etc.
I dislike defining an overly specific process for curing a breach. I believe terms like the ones above are holdovers from contracts for parts suppliers (e.g. the bolts you delivered are out of spec, and we want you to deliver new bolts within 30 days because that’s when our inventory will run out and cause production issues).
Agile software development already has a built-in process for continuous delivery and review. Detailed acceptance criteria are commonly defined during the project and validated through automated testing practices. Minor defects or bugs are part of the development process, identified during regular reviews, and fixed in the next sprint of work.
Instead of including all of the specifics of an Agile development process in a software development contract, I believe it’s better to:
My points above are related to review and acceptance, but I’ve observed contracts getting overly detailed on a cure process for infringement, compliance with policies, etc.
My general point of view is that less is more when it comes to defining cure processes for various kinds of breaches. I recommend:
Termination terms define what happens if you and your partner want to end a specific project defined by a statement of work or the business relationship defined by a master service agreement.
I recommend keeping these terms as simple as possible so that you and your partner can end a project or the active business relationship without cause. You should expect and want a notice period (such as 30 days) for termination so you and your partner can responsibly disengage.
During the disengagement period, you and your partner will work to finalize all deliverables, return materials as appropriate, and finalize payment for all services rendered.
You can expect to see a survivability clause in the termination section, outlining sections in the contract that will survive the termination of the active business relationship. These surviving terms may include:
Keeping termination language simple and taking a straightforward, high-level approach to curing breaches focuses you and your partner on keeping your business relationship healthy if something goes wrong. Assuming the business relationship is valuable to you both, each of you will do what’s right to preserve the health of the long-term relationship. I believe this is a better approach than getting into a debate about what does or doesn’t constitute a breach, a failed cure, or adherence to other specific terms that can be open to interpretation.
It’s important to remember that you and your partner will likely both have limited leverage when working together to correct an issue. The common incentive will be the value of the future business relationship.
In Agile software development projects, deliverables are provided continuously. Software is usually committed multiple times every day. Progress reports and other higher-level deliverables are delivered every one to two weeks. Often, all digital deliverables are stored in infrastructure you control. Your partner will probably be invoicing you every two or four weeks.
This situation means you will always have possession of nearly all deliverables from active work. Commonly, your partner will have outstanding payment risk if they don’t require pre-payment, invoice in arrears, and net payment terms at 15 or 30 days. This means you will likely have more negotiation leverage with your partner when you are working to correct an issue. Your partner will want to reduce outstanding payment risk and work to preserve the value of the future relationship.
We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.
