Whether you are an independent contractor or a software development company, you should have a software development agreement with any customer for whom you are developing custom software. There are specific don’ts you should include to make sure your IP is protected and your liability is limited.
1. Don’t grant your customer exclusive rights to your reusable common components.
When you write custom software, the software is either considered a “work made for hire” which means the customer is the owner of the software once it has been delivered or you grant the customer an exclusive, irrevocable, perpetual license to use the software. In either case, you are no longer allowed to use the code contained in that software for any other purpose. That can be very problematic.
Over the years, you have probably realized there is functionality that you use in almost every project. Instead of reinventing the wheel, you cut-and-paste this code or perhaps you have created libraries (either static or dynamic) that are linked in to your codebase when you need the particular functionality. This is not only the most efficient way to implement common tasks but it also makes your code more bulletproof because these core components have been tested over and over again in the field. This is where things get messy. If you have embedded this commonly-used code in the custom software that you have either assigned (i.e., given ownership) to the customer or granted the customer an exclusive license to use, you no longer have the right to use this code in either your own software or any software you write for another customer. Not what you intended, I am certain.
How do we solve this problem? The common components should be “packaged” into libraries that can be licensed separately in your custom software development agreements. You can then grant your customer a non-exclusive license to use this common code allowing you to use it in other projects.
2. Don't grant your customers exclusive rights to what is yours going into their project
In your years of software development experience and/or education, you have learned a lot of things. You have general know-how that is uniquely yours. You understand many algorithms and know how to implement them. You know how to design and architect systems. You understand how to structure, sequence, and organize your code.
Your customers have no right to claim ownership of this prior knowledge. Your software development agreement should reserve your rights in the knowledge you have when you come into the project.
3. Don't grant your customers exclusive rights to what you learned while working on their project
Of course, you cannot use a customer’s trade secrets, confidential data, or other proprietary information in your own or other customer’s projects but you gain general knowledge and experience when working on any new project. This knowledge is called “residual” information or knowledge. A customer cannot expect you to unlearn this residual information.
Your software development agreement should reserve your rights in the residual knowledge you acquire while working on their project. There is a caveat to this reservation of rights, however. This residual information can only “leave” your customer’s project in a non-tangible form; in other words, this residual knowledge is only the knowledge and experience you have retained in your head.
4. Don't guarantee that your software will be defect free
Many of my clients push back when I tell them we have to explicitly state that they don’t warrant that their software will be free of defects. Understandably, they are proud of their work and want to stand behind it. But, let’s be serious, there is no such thing as bug-free software.
So, how do you guarantee that you are creating and delivering a quality product without making an unrealistic claim? Well, first, your software development agreement should contain a warranty that states your software will “substantially” conform to all “material” operation features. This is legal-speak that means your software will do what you agreed it will do. It means that you will fix the software or replace it if the customer discovers major features are missing or if the software crashes when doing a task which is core to its functionality.
However, to protect yourself legally, you then need to have a warranty exclusion that states that you do not guarantee that your software will be defect free. Because, we all know that is an impossibility. If your customer pushes back on this exclusion, refer him back to your warranty section. Explain to the customer that you aren’t saying you can or will deliver a non-functional product; you are just protecting yourself because no software is completely bug-free.
5. Don’t guarantee the performance of third-party dependencies
All software depends on third-party components to some extent. Some software uses third-party APIs. Most rely on the Internet. And, almost all depend on the underlying operating system.
Your software development agreement must explicitly state that you cannot guarantee the performance of these third-party dependencies because you cannot control them. You cannot fix a bug in a third party’s code. You cannot control the service level of an ISP. And, you cannot know when the operating system will be updated and cause an unexpected problem in your code.
Hopefully, this helps you understand some common don’ts that are needed in a software development agreement and why they are important to you. Need a software development agreement? I’d be happy to help.