When a company hires a software developer to develop custom software, it is important that the written software development agreement appropriately addresses several key issues such as ownership, proper specifications, acceptance criteria, compensation, warranties, IP indemnification, and confidentiality. As an attorney who has drafted and negotiated many software development agreements over the years, I have learned that the hiring company often fails to appreciate this importance at first.
It is important to understand that, as with most technology-related agreements, one size does not fit all when it comes to software development agreements. A software development agreement, when drafted properly, will be a highly customized document that is thoughtfully tailored to the particular situation at hand. There are a lot of ways that one might try to categorize software development agreements, but I like to think of them as coming in two basic flavors: (1) Owned Software, where the custom software to be developed will be owned by the hiring company; and (2) Licensed Software, where the custom software to be developed will be licensed to the hiring company.
In the typical Owned Software situation, the hiring company has a choice of software developers, i.e. there are many developers that would be able to do the development. The software developer chosen may have expertise in the relevant area of software, but does not have any unique proprietary technology that is a fundamental requirement for the custom software in mind. In this situation the hiring company is hiring the developer (which usually is primarily a programming house) for the developer's programming expertise and usually is paying the full cost of the programmers needed plus overhead and profit. When the hiring company pays full price for the developed software, the hiring company should get to own the customized software.
By contrast, in the typical Licensed Software situation, the hiring company is hiring a particular software developer because that developer owns some unique proprietary technology that is a fundamental requirement for the custom software in mind. Here the engine or core of the software system has already been developed by the developer, and the hiring company wants the developer to develop a customized version of that software system for the hiring company. In this situation the economics, the negotiating dynamics, and the compensation structure will be much different; e.g., the hiring company will have to pay for more than just the cost of the customized development work, probably including some kind of royalties. Here the developer (which usually is not just a programming house) will have more bargaining power and will insist that the hiring company only receives a license to the customized software (and subject to many limitations).
Of course there are hybrids of these two basic situations and then the software development agreement can get even more complex because it has to differentiate and handle both properly. In this column I will focus on identifying the major issues and explaining some solutions that arise in the Owned Software situations from the hiring company's point of view (the Licensed Software situation and the hybrid situation are subjects for another day and column):
Drafting Dynamics. Before I discuss specific issues, let's take a step back and look at the bigger picture. What does the software developer want? The main things that it wants are to get paid for its effort and to avoid future liability, i.e. it wants to make money on the project. These things do not require much custom drafting; the provisions for getting paid can be fairly simple and routine, the provisions for trying to avoid future liability can be complete boiler-plate language. It is easy for the developer to know if it has received what it has bargained for, i.e. money. If the developer had its way, the hiring company would just pay the developer promptly for all of the time and expenses spent on the project, and that would be the basic deal. Consequently, the developer would prefer a very simple and routine agreement. But what does the hiring company want? It wants to get things from the developer that are very complex: it wants custom software that satisfies a set of technical requirements; it wants the development to be done on schedule; it wants mechanisms that ensure it meaningful progress reports during the development process; it wants flexibility in the development process as requirements may change; it wants software that works properly; it wants the developer to fix the software if it does not work properly; it wants source code that is properly documented so that it can be maintained and updated in the future; it does not want to have to pay unless it gets all of what it has bargained for; it wants full and unencumbered ownership of the software; it wants software that does not infringe on the intellectual property rights of anyone else; i.e., it wants a lot of complex things. These things do require a fair amount of custom drafting. It is much more difficult for the hiring company to know if it has received what it has bargained for; and if things go wrong, it will want there to be clear provisions in the software development agreement that spell out its rights and protect it. My bottom line point here is that careful and thorough custom drafting of the software development agreement and related documents is much more important to the hiring company than the developer.
Specifications. One of the first things I tell my hiring company clients is that we are going to need clear, detailed, and thorough specifications for the software to be developed. I use the generic term Specifications to include any and all of the following: a high-level business description of the software, a preliminary requirements document describing the functional requirements, any written proposal by the developer to meet those requirements, any statement of work prepared which would include a more detailed description of the technical requirements and the schedule for development, and any other specifications or technical documents (including test protocols and technical acceptance criteria) developed in connection with or as part of the development effort. These are all more technical than legal documents and will be attached to (or incorporated by reference into) the software development agreement; obviously no form of software development agreement is going to have these Specifications in any meaningful detail, so they will have to be written from scratch, usually by the hiring company's technical personnel. Although these are more technical than legal documents, I try to emphasize how important it is that they be clear and thorough. In my experience I have found that most technical personnel tend to use shorthand in their writing and often use many different names to refer to the same thing. They also tend to write assuming that the reader knows as much about the subject as they do. This can result in language that is cryptic and ambiguous and thus difficult to interpret if there ever is a dispute later as to its meaning. So I try to get the technical personnel to write in complete sentences, without abbreviations, assuming that the reader does not know anything about the subject, and always trying to use consistent names for things.
Defined Terms. A well-drafted software development agreement will begin with a thoughtfully and carefully drafted set of defined terms that are then used consistently throughout the agreement. Unfortunately, many of the form agreements that are prepared by the developers do not do this; they tend to have too few defined terms and the definitions that they do have are not very clear or comprehensive. We will need a different and comprehensive defined term for each separate category of things that we want to deal with in the agreement. At a minimum, we should define the "Developed Software" as all of the software that is delivered pursuant to the agreement, the "Deliverables" as all of the deliverables to be delivered pursuant to the agreement (which includes more than just the Developed Software), and the "Specifications" as including all of the documents mentioned in the Specifications paragraph above. And if the Deliverables are to be delivered in phases (or stages), then we may need separate defined terms for each phase. The defined terms may seem like a mundane part of the agreement, but I cannot overemphasize the importance of getting this right. Having a well-thought-out set of defined terms will make the drafting and negotiation of the rest of the agreement more straight-forward and much easier. It will be difficult for the developer to object in negotiations to either a comprehensive set of specifications or a comprehensive set of defined terms; but the catch is that it will usually take some time and effort on the part of the hiring company to produce these.
Compensation. There are two basic methods of structuring the compensation in this setting: (1) Fixed Price, where the hiring company will pay a fixed price for the Deliverables (or fixed prices for each phase of the Deliverables); and (2) Time and Materials, where the hiring company will pay for the development work based on the actual amount of time and materials spent by the developer on the project. (Where the developer is primarily developing the software according to the hiring company's specifications, I would not recommend that any royalty arrangement be part of the compensation structure; and the developer would rarely ask for this anyway.) The form agreements prepared by most developers for the Fixed Price method will provide that the fixed price is paid in fixed installments, heavily front-loaded, with the last payment due upon final delivery (not acceptance). The form agreements prepared by most developers for the Time and Materials method will simply provide that the developer invoices the hiring company on a monthly basis and that the entire amount of each invoice is due within a certain period after the date of the invoice. With either of these two basic methods however, I strongly recommend that the structure should also provide that all or at least part of the compensation is contingent upon the Deliverables satisfying specific acceptance criteria; the compensation structure usually can and should be negotiated to introduce this concept. The developer might suggest that 10% will be held back until final acceptance; this is not enough in my view. Software is a complex animal and there is always a certain level of bugs in any software. We want there to be major incentives for the developer to make the software as good and bug-free as possible, not just spend time on developing it; I usually recommend that a substantial portion (at least 30%), if not all, of the compensation should be held back until final acceptance of each phase.
Phases of Development. Unless the development project is relatively small, straight-forward, and well-defined, I usually recommend for several reasons that the development should be structured in phases and that the compensation should be broken up and tied to each development phase. If a detailed set of specifications has not been prepared by the hiring company and/or developer prior to signing the agreement, then the first phase of the project should be to develop a mutually-acceptable detailed set of specifications (including test protocols and other acceptance criteria), and no development on additional phases should start until these specifications have been developed and agreed to. Getting a good blue-print for the software may be more important than the writing of the software itself, and structuring the development this way will incentivize the developer to take this phase very seriously and do a more thorough job. Also, if the hiring company has not worked with the developer before, this will allow the hiring company to evaluate the skill of the developer in a meaningful way before it gets too deep into the project. If the specifications cannot be agreed to, then the hiring company should have the right not to proceed with the rest of the project. Structuring the rest of the development project in phases also makes it easier to tie the compensation to acceptance of each phase. This gives the hiring company more control over the project and makes it more likely that the hiring company will get what it pays for.
Acceptance Criteria. I cannot overemphasize the importance of providing for meaningful acceptance criteria and meaningful and fair acceptance procedures. The developer's standard form of agreement will give little if any attention to this issue; if anything, it will provide that the hiring company is deemed to accept the Delivered Software if the hiring company does not give written objections within a fixed (and usually way too short) period of time after delivery. From the hiring company's point of view, silence should never be deemed to be acceptance; if anything silence should be deemed to be non-acceptance. There needs to be a meaningful period of time for the hiring company to evaluate and test the Delivered Software (and by the way, there should be a requirement that the developer has to perform identified testing procedures successfully before the software is delivered). I also strongly recommend that a detailed set of objective acceptance criteria should be written (either before the agreement is signed or during the initial specifications-development phase). I also usually recommend that the first part of the evaluation and testing phase should include the developer demonstrating to the hiring company that the Developed Software successfully meets these objective acceptance criteria.
Ownership. As discussed above, there should be appropriate provisions to ensure that the hiring company will own the customized software; and the hiring company should own it from the moment it is created (i.e., it should be a "work made for hire"), ownership should not be conditioned on acceptance or final payment or anything else. The developer's form may also have some vague language that the developer retains ownership of any pre-written library software that is incorporated into the Developed Software. While this position has some merit, it needs to be spelled out clearly and carefully. If the developer does use its own pre-written library software in the development, then it would be OK for the developer to retain ownership to that pre-written library software, as long as: (1) the hiring company receives an irrevocable, fully-paid up license to use that library software with no restrictions; and (2) the developer is required to identify at the time of final delivery the exact library routines that fall into this category.
Warranties. What happens if after the Developed Software is accepted, the hiring company finds out that the Developed Software does not in fact conform to all of the Specifications? This will almost certainly happen at least to some extent because the testing and acceptance procedures cannot ever catch all of the bugs and items of nonconformance; and there will be bugs and items of nonconformance. One of the reasons for having clear and comprehensive defined terms is that the hiring company will want the developer to make something like the following warranties: "The Deliverables shall conform to the Specifications. The Developed Software shall operate correctly and in conformance with the specifications, functionality, and capabilities contained in the Specifications." The developer will want these warranties to be limited to a certain time period if at all, and the developer will try to argue that we know there will always be some bugs so the developer should get paid for fixing them and maintaining the software. My view is that there should be at least a reasonable period of time during which the developer has to fix bugs and nonconformance items for no additional charge; this will add to the incentive for the developer to get the software as correct as possible in the first place. The resolution of how strong the warranty language is and how long the warranty period will last usually will depend on the relative bargaining power of the two parties, but I push for (and usually get) meaningful warranty language for a meaningful length of time.
Confidentiality. Everyone who deals with technology-related agreements has seen a lot of confidentiality provisions and some may think that these provisions are all fairly similar and standard. However, there are two different situations that need to be distinguished: (1) the Disclosure of Information situation, where each party wants to protect the confidential information that it discloses to the other party; and (2) the Transfer of Ownership situation, where the ownership of the confidential information will be transferred from one party to the other. The typical provisions that are used in the Disclosure of Information situation will not work in the Transfer of Ownership situation. The hiring company needs to end up owning both the information that it discloses to the developer and the information that the developer creates in the development process and discloses to the hiring company. The definition of Confidential Information in the Disclosure of Information situation typically has exceptions for knowledge prior to receipt and for independent creation; but these exceptions are not appropriate for the Transfer of Ownership situation, so the hiring company needs to be careful here.
IP Indemnification. What happens if it turns out that the developed software infringes on the intellectual property (IP) rights of some third party? The hiring company will want an indemnification provision in the agreement that requires the developer to indemnify the hiring company if this happens. The developer's form agreements will almost never contain such a provision, but it is entirely appropriate for the hiring company to ask for this if the developer's work is what caused the infringement. The developer may argue that it is a small company and cannot afford to indemnify the hiring company for the unknown and unlimited risks of IP infringement, especially possible patent infringement. There are good arguments on both sides of this issue, and the resolution usually comes down to which party has more bargaining power. At the very least the developer should represent that to the best of its knowledge the developed software will not infringe any IP rights of any third party. I also am usually successful in negotiating that the developer will indemnify the hiring company for IP infringement at least to the extent of the price paid by the hiring company.
The subject of software development agreements is obviously quite complex and I have just scratched the surface above. The bottom line is that the drafting and negotiation of the software development agreement should be taken seriously, and the hiring company should not simply sign the developer's standard form if the hiring company wants to have its interests protected.
Steven R. Foletta, a Silicon Valley corporate and licensing attorney, specializes in the area of licensing, technology transfer, and other technology-related transactions, as well as in the area of general corporate law. He can be reached at steven@folettalaw.com, 1560 Latham Street, Mountain View, CA 94041, (408) 316-6136. This information in this article is not intended to constitute legal advice and should not be relied upon in lieu of consultation with an attorney.
Copyright 2005 Steven R. Foletta. All Rights Reserved.