Any new software is guaranteed to have a few bugs. Clients who use your software or who hired you to make the software for them assume that you will fix the bugs sooner or later. There are a few different variations on how you can commit to fixing bugs. We will discuss those variations below.
Methods of Providing Software to Clients
Bugs will exist in any software. The obligations to fix bugs can arise for custom-built software you have developed for a client and which the client will own once created. Fixing bugs is also a part of software provided as a service where clients expect regular patches and fixes along with periodic upgrades.
Custom-Built Software
Software fixes are usually dealt with in the development contract. It is common to see payment obligations for a client trigger once you have fixed any bugs they have been able to identify.
Being legally obligation to fix bugs in software is a multi-layered matter. The reason is that you as developer have competing interests. On the one hand, you need the development contract to be completed so that you are not obligated to fix bugs for however long the client uses the software. On the other hand, you wish to maintain good relations with your clients that you will stand behind your custom-built software product. From the developer’s perspective, you would prefer to limit your legally obligation to fix any software and instead be empowered to exercise your discretion
For those reasons it is important to specify the actions that will be taken to address bugs which include addressing the testing of the software, the discovery of the bugs, the timelines during which fixes are made, and the reasonableness of the fix made.
Deadline. Pick a deadline date after which the developer will no longer be legally obligated to fix bugs. It is not unusual for a developer to have a contractual obligation to fix bugs found within 6 or 12 months of the client’s acceptance of the software. Fixing bugs found within 6 months of the acceptance of the software is reasonable, as not all bugs will be discovered during testing.
Testing. It is possible to restrict the bugs that the developer will fix to those found during the client’s testing. Once the software product is substantially complete, have the client discover and tell you what bugs exist so that you can fix them. It’s not that the developer should be required to fix all bugs, but rather restrict that obligation to only those bugs the client finds during testing.
Discovery. Developer should only be obligated to fix those bugs that the client discovers. A legal contract that requires the developer to fix any and all bugs without qualification could potentially mean that the developer will be fixing bugs in the software product for years later. Further, though an odd outcome, the developer could have contractually obligated itself to fix all bugs on software delivery or deliver the software without bugs, when the developer would have had no way to make certain of that fact – potentially putting the developer in breach of contract. Therefore bugs have to be those that are discovered, identified, and brought to the attention of the developer.
Reasonableness of Fix. Whether the bug is fixed as a part of testing before deployment or whether it is fixed after the client has been using the software, the fix made has to be to the satisfaction of the client or the developer. As the developer you would prefer that the contracts says that you are obligated to fix the bug, as determined in the sole discretion of the developer or as reasonably determined; the client will like the fix to be made to the satisfaction of the client, perhaps acting reasonably. The quality of the fix can be a bone of contention between the parties so as developer ensure that you do not agree that such discretion will sit solely with the client who can be unreasonable in their demands as to the quality and type of fix.
* * * * *
Ryan K. Smith is a Lawyer and Trademark Agent at Nakano Smith Law Group. He is a corporate and commercial lawyer and also has expertise in all manner of intellectual property matters including trade-marks, copyrights, domain names, and confidential information. Ryan is the author of Intellectual Property in Commercial Transactions (Thomson Reuters). You can reach Mr. Smith at (647) 806-6133 and [email protected]. This article is provided for information purposes only and is not legal advice and may not be relied upon.