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.
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.
This is the second post in a series that will cover common considerations in the following categories:
- Overview & Principles
- Intellectual Property Rights
- Warranties, Indemnifications, and Liability
- Breaches and Termination (June 26)
This post will discuss intellectual property rights and risks in three areas:
- Custom Deliverables – Who owns the rights to the custom software created for you by the software developer?
- Pre-Existing Work – What are your rights related to any pre-existing software included in deliverables?
- Intellectual Property Infringement – Who owns each type of intellectual property infringement risk?
Custom Deliverables
The author of any creative work inherently owns the intellectual property rights to their work. Without agreeing otherwise, the code a developer writes belongs to the 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 team weeks, etc.) and will own the received deliverables created during the duration of the invoice upon payment of the invoice.
Pre-Existing Work
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.
Inventory of 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.
Rights and limitations related to pre-existing work
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.
Pre-existing work from a third party
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.
Pre-existing work from your partner
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.
Intellectual Property Infringement
When it comes to IP infringement risk, I like to keep the following principles in mind:
- Risk and reward should be correlated.
- Risk should be owned by the party who can best control and manage the risk.
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.
Copyright, trademark, and trade secret infringement
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.
Patent infringement
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.
Writing a Software Development Contract
This post is part of a series on writing a great software development contract: