Software development agreements contain obligations on software developers to develop applications by making more than minor modifications to standard software or developing bespoke software that address the specific needs of the user. 

Legal nature of software development contract 

Software development contracts are generally considered to be contracts for services. This paragraph provides that the laws on the sale of goods apply to the delivery of moveable goods to be manufactured or produced. In principle, Chinese law qualifies software as a movable good. However, due to the statutory regime on performance guarantees and supplementary performance, the law on the sale of goods does not really reflect the nature of software development. Instead, it is the development process, which can often be long and arduous, as opposed to the simple performance of mutual obligations that is at the core of a software development relationship. 

In the event that the contractual parties would prefer for the law on the provision of services to apply to a software development contract, it is important to expressly include such a provision in the preamble of the contract. The provision will not be decisive, but will act as an indication as to which rules the parties wish to govern the contract. 

Important provisions of software development agreement 

The software development agreement must clearly define the software to be developed under Chinese law. As China software development agreement expert lawyer, we suggest a list of obligations is drawn up together with the client and will contain a precise description of the software’s specifications. In addition, the software developer must remember to grant the client a licence over the software. Finally, the contract should contain provisions concerning the time period for use (which should be at least “permanent use”) and remuneration for the developer. 

In the event that the parties wish to derogate from the statutory provisions concerning liability for defects, express provisions should be included in the software development agreement. 

We meet many of my clients after they’ve been on one side or the other of a software development project begun, and sometimes completed, without a detailed written agreement. Either the scope of the project has expanded, or the complexity of the work was underestimated, and the developer winds up performing additional work the user doesn’t want to pay for. Or the user, assuming it owns the software it paid the developer to code, objects to the developer providing a modified version to one of the user’s competitors. Or the developer, assuming it owns the software and only gave the user the right to use it for the user’s internal business purposes, objects to the user’s efforts to commercially distribute the software -- without royalties to the developer.  

The cost of a failed or disputed software development effort can be extremely high for both the user and the developer. The user has often paid substantial sums to the developer and may sue to recoup those costs if the system does not perform as intended. The time lost in an unsuccessful development effort could severely effect the user’s business operations, which may entitle the user to recover consequential damages from the developer. Similarly, the developer may be expecting to receive a significant fee which it may have to sue to recover if the user disagrees with the developer as to what was supposed to be delivered.  

Get a Written software development contract 

Without a comprehensive written agreement governing the arrangement and serving as a blueprint for the development effort, it’s one side’s word against the other’s as to what the parties originally intended. Further, whether the project involves custom original code, third party application software, customization of existing programs, or some combination of all three, it is essential to clearly state the parties’ respective intellectual property ownership and licensing rights. This is a very complicated task best not left to the user’s Director of Marketing or the developer’s V.P. of Sales (each experts in their own fields) who may wish to personally savor the joys of contract drafting and save on legal expenses.  

Documenting the Development Process  

A complex custom software development engagement is often divided into several distinct phases: preparation of preliminary functional specifications, preparation of detailed design specifications, software coding from the detailed specifications, data conversion to the new system (if it replaces an existing one), and acceptance testing. Each should be reflected in the overall written agreement.  

The preliminary functional specifications serve as a high-level blueprint identifying, in non-technical business terms, the needs the user expects the system to address. In many cases, they will have been prepared by the user and included in a Request for Proposal. If the developer believes the specifications are unrealistic, it should persuade the user to modify them at this early stage, before development is begun. The developer should not agree to design a system to conform precisely to the preliminary functional specifications. The software may evolve during the development process into a different form than originally envisioned by either party. Nevertheless, the developer should expect that the user will want the preliminary functional specifications to become part of the contract and may require the user to agree that the software will "substantially perform" the stated business functions.  

While the preliminary functional specifications will in many cases have been prepared by the user, the detailed design specifications will usually be prepared by the developer and build upon the preliminary functional specifications. They will typically include flowcharts, system documentation, descriptions of output, examples of the user interface, telecommunications requirements, data and file layouts, documentation requirements, acceptance test criteria and schedules. The contract should provide that the user will have a specified period of time, such as 30 days, to review and either approve or suggest modifications to the detailed design specifications. The user should have the right to terminate the contract if it is not satisfied with the specifications produced by the developer. On the other hand, if the developer is asked to include additional features and functions, the user should expect to pay additionally.

The acceptance testing process typically involves testing each software module individually, and the entire system as a whole, to determine whether it conforms to the detailed design specifications. The testing mechanism should be set forth in detail in the contract. It should state objective acceptance criteria which can be developed with the assistance of an independent third party if the user and developer cannot agree on what such criteria should be. From the developer’s standpoint, the contract should require the user to provide written acceptance or rejection of the system within a specified time period, or it will be deemed accepted. The developer should be afforded several opportunities and reasonable time periods to correct any defects that may cause the system to fail the acceptance tests before the user can consider the developer to have breached the development agreement.  

Software developers and their clients who embark on development projects without clear written agreements stating each party’s responsibilities -- and defining the expected results -- have often unwittingly sown the seeds for future conflict. In May’s issue, we covered some of the reasons why both developers and their clients should have a detailed written agreement governing their projects. We also reviewed some of the critical provisions such an agreement should contain and a variety of positions each party should reasonably expect the agreement to reflect. This month’s article addresses how software development agreements typically address these key areas: scope changes, payment terms, ownership rights, and warranties and liability.  

Scope Changes  

Changes in project scope or software functionality from what the parties originally envisioned are almost inevitable during a custom software development engagement. Disputes between the developer and the client often arise concerning whether the developer was obligated to make a change, who should bear the cost of the change, the cost itself, and who should be responsible for any resulting delay.  

A written development agreement should state a clear mechanism for requesting, approving and implementing any changes in scope or software functionality. The procedure should require the client to request the change in writing and the developer to respond, again in writing, with a proposal describing the fee and schedule impact of implementing the requested change. The developer should not be obligated to proceed with making the change until the parties have agreed on the cost and schedule impact, as well as the specifications for the revised software. In the absence of a clear contractual provision addressing change orders, the developer is particularly at risk in fixed price projects. The client might request a change it perceives to be minor but which actually entails a significant amount of extra effort by the developer.  

Payment Terms  

Software development engagements are typically paid for on either a fixed price/milestone or time and materials basis. Since developing software is extremely labor-intensive and complex projects can take years to complete, the developer will usually prefer to be paid on a time and materials basis so as to recoup all its costs and maintain its profit margin. The client will usually want the job to be done on a fixed fee basis so as to be able to budget for a known expense.  

It is hardly reasonable for the developer to be expected to fund the entire development process and wait until project completion before receiving any payment. Accordingly, many development agreements provide for regular periodic payments. An initial payment may be made upon signing the agreement, followed by a second payment upon completion of the detailed design specification phase. Subsequently, payments can become due after completion of the coding phase, completion of the program testing phase, and finally, upon successful acceptance testing including operation of the system in production using live data.  

The client will typically want to avoid making large payments at the beginning of the project so as to keep the developer’s interest in performing promptly. Similarly, in order to maintain an incentive for the developer to provide needed assistance during the often painful conversion from an old system to a new one, the client may find it useful to withhold a final payment until after the system has proven itself capable of successfully operating in a live environment for some period of time. 

A very clear payment schedule in a written agreement also benefits the developer. Once a project milestone has passed, the developer can rightfully refuse to proceed with further work until it receives the required payment.  

Ownership Rights  

The area of ownership or proprietary rights presents a challenging and complex range of issues. Without a written contract clearly stating the parties’ agreement on ownership of the software created by the developer, copyright law will apply to vest ownership of the copyright in the developer. Ownership of the copyright is, for practical purposes, ownership of the software. The copyright owner has the exclusive rights to copy, distribute and modify the software. The client will own the actual copies of the software delivered by the developer and residing on its computers, but without ownership of the copyright it cannot market, distribute or duplicate the software.  

In many cases, however, the client may only be interested in using the software for its internal business purposes, in which case ownership of the software, as opposed to a license to use, is not a critical concern. The client may object, however, if after paying millions of dollars to fund the development of new system, the developer then wishes to commercially distribute the software to others, including the client’s competitors. 

Warranty & Limitation of Liability  

Software is so inherently complex that even the most extensive battery of acceptance tests will not uncover every programming error. Some will usually be found after the system has been delivered and the client begins using it. Accordingly, the client should insist on a provision in the written agreement requiring the developer to fix software errors at no charge for a specified period of time.  

Typically, the developer will be expected to warrant that the software will substantially conform to agreed upon performance specifications. If it doesn’t, the developer will be expected to correct the defect if it is brought to its attention within, such as the date the client accepts the software.  

The developer will want to limit its warranty responsibility to correcting the defective software brought to its attention during the warranty period. A carefully drafted warranty provision will usually include a disclaimer of all other warranties other than the one specifically stated, along with a clause limiting the developer’s total liability under the contract. For example, if the developer is unable after numerous attempts to correct defective software and it remains unusable to the client, the developer will not want to be responsible for potentially ruinous "consequential" damages, such as the client’s lost business opportunities or lost profit. A reasonable remedy for the client in this situation may be a complete refund of the fees paid to the developer.  

The client’s remedies and the developer’s liabilities are very often hotly negotiated issues. Without a written agreement limiting its liability, the developer’s liability is potentially unlimited, which may be the most compelling reason of all for the developer to insist on a written agreement. Conversely, a carefully drafted warranty clause gives the client specific enforceable rights and a bit more comfort than the developer’s verbal assurance. 

General terms of a software development agreement 

• Definitions
• Development Services
• Duties And ResponsibilitiesSpecifications
• Development
• Delivery
• Acceptance
• Acceptance Period
• Completion
• Rejection
• Notification
• Rectification
• Continued Failure
• Assignment Of Rights
• Training
• Training Scope
• Training Dates And Locations
• Training Costs
•  
• Support And Maintenance
• Development FeesDevelopment Costs
• Expenses
• Change In SpecificationsChange Orders
• Additional Time Or Expense Term
• Representations And Warranties
• Ownership Rights
• Limited Warranty
• No Open Source
• No Infringement
• Warranty Disclaimer
• No Third Party Property
• No Obligation
• Repair Or Replace
• Exclusions
• Acknowledgement
• Proprietary Rights
• Independent Contractor
• No Partnership
• Obligations
• Confidentiality
• Liability Insurance
• Source Code Escrow
• Delivery Of Object Code
• Escrow Of Source Code
• Delivery And Update Of Source Code
• Contingent License
• Rights And Remedies
• Indemnification
• Limitation Of Liability
• Termination
• Termination For Cause
• Effect Of Termination
• General Provisions
• Entire Agreement
• Counterparts
• Amendment
• Assignment
• Successors
• Notices
• Dispute Resolution
• Governing Law
• Force Majeure
• No Waiver
• Severability
• Headings

 Call our China IP lawyer now for a FREE, no-obligation consultation with one of our experienced account executives, and let us show you the difference that professionalism, quality and teamwork can make.