Basics of Reviewing Software Development Agreements: Definitions, Checklist, and Risks by Position

Hello, I'm Noriaki Asato, Representative Attorney at LegalAgent.

I find software development agreements to be one of the most difficult areas of corporate legal work to review. This is because they require not only a legal understanding of the Civil Code, intellectual property law, and information security, but also an integrated grasp of how development processes work in practice and how requirements definition proceeds.

From the perspective of the client's business department, it is tempting to see this simply as "a contract to have a completed system delivered," but in reality, not every project has its specifications fixed in detail from the outset. There are many situations in which the user company and the vendor build something together, such as a PoC (proof of concept), migration from an existing system, or phased feature expansion. If the contract provisions diverge from this reality of development, it can escalate into major trouble over schedule delays, additional costs, and ownership of rights in the deliverables.

Organizing Development Methods and Contract Structure

A software development agreement is a contract under which a user company entrusts a vendor with the design and development of business systems, web services, applications, or similar. A two-tier structure is often used, in which a master agreement sets common terms and individual agreements or purchase orders set the specific development target, delivery date, and fees. Because the risks of an individual transaction cannot be judged by checking only the provisions of the master agreement, it is important to read the purchase order, proposal, and specifications together as a whole.

As for the legal nature of the contract, it cannot be uniformly determined to be a contract for work or a quasi-mandate merely from the development method or the names of the phases. Even in waterfall development, there are examples where the requirements definition and basic design phases are treated as quasi-mandate and the detailed design phase onward as a contract for work, and even in iterative development such as agile, there are examples that incorporate acceptance of deliverables for each sprint. Also make clear whether the deliverables include not only executable files but also source code, design documents, and administrator rights to the various accounts needed for operation, and how they are separated from the vendor's existing assets and OSS (open source software).

Requirements Definition and Procedures for Specification Changes

Issues that tend to cause problems in development projects are unfinalized requirements and the handling of specification changes. A typical mismatch in understanding is when the user thinks "this feature described in the proposal is included," while the vendor sees it as "an additional request not included in the assumptions of the estimate." If the vendor promises completion for a fixed amount while the specifications remain unfinalized, it may end up bearing work beyond the estimate. Where there are commitments described only in the proposal, they need to be expressly incorporated into the agreement or the agreed individual specifications.

For specification changes, set out in the contract in advance the method of requesting changes, the vendor's presentation of an estimate and the scope of impact, the user's approval procedure, and the procedure for adjusting costs and schedules, so that free work does not balloon through casual requests made orally or by chat. If the change procedure is too heavy, it hinders agile development, while if it is vague, it causes the burden in the field to fall disproportionately on one side. It is also a practical safeguard to include the client's duty to cooperate and a schedule extension clause for delays, so that the vendor alone is not held responsible for late delivery when development delays result from delays in the user's cooperation, such as finalizing specifications, providing materials, or obtaining internal approvals. This is because project delays and failures often arise from a combination of factors, such as unfinalized specifications, approval delays, and outages of external cloud services.

Acceptance Criteria and Contractual Non-Conformity Liability

The acceptance clause is the pivotal provision where the obligation to pay fees and the determination of deliverable quality intersect. If the pass criteria remain vague, the two sides will disagree about which defects justify withholding acceptance, and the vendor will also find it hard to foresee when it will be paid. The mere absence of stated criteria does not mean that quality claims based on other agreed terms of the contract can no longer be made. It is effective to specify the acceptance period, the obligation to repair upon failure, and pass criteria according to the severity of defects. Agree whether acceptance will be passed for the time being if minor defects remain but do not hinder production operation, with remaining defects repaired within the response period set in the contract, and whether acceptance can be withheld if there are serious defects.

For contractual non-conformity liability, check the period for claiming free repair, price reduction, and the requirements for termination. While structuring post-delivery maintenance and operation as a separate contract is itself common, check whether gaps or omissions in coverage arise between the handling of initial defects immediately after acceptance and the scope of the maintenance contract. The scope of maintenance, SLAs, and items to check regarding additional costs are organized in Checkpoints for Maintenance Agreements and System Maintenance Agreements. In damages provisions, a limitation of liability clause capping liability at an amount equivalent to the service fee or similar is often included, while whether to exclude from the cap damages arising from information leaks, intellectual property infringement, or willful misconduct or gross negligence is negotiated. The validity of the limitation of liability clause itself is judged separately in light of the applicable laws, case law, and the specific circumstances of the case.

Designing Intellectual Property Rights and Data Management

Ownership of intellectual property rights in the deliverables is also a key item to consider. The user generally requests assignment of copyright so that it can modify and deploy the deliverables in its own business, but unless the agreement specifically states that the rights under Article 27 (rights of translation, adaptation, etc.) and Article 28 (rights of the original author regarding the use of derivative works) of the Copyright Act are assigned, they are presumed not to transfer to the client (Article 61, Paragraph 2 of the same Act). Even if the rights remain with the vendor, confirm that the user can obtain a license sufficient for the intended use and modification. In addition, because moral rights of authors are personal rights that cannot be assigned (Article 59 of the same Act), whether to include a covenant not to exercise them is also an issue. The vendor should clearly exclude existing assets it held before the development, such as common modules and frameworks, so that they are not swept into the assignment, and should also confirm that the form of use does not violate OSS license terms.

In development using AI or the incorporation of machine learning into systems, the rights relating to input data, trained models, and generated output also need to be sorted out, bearing in mind that AI generative models and their output are not necessarily protected as works under the Copyright Act. In addition, when production data is used in the development environment, set out security control measures under the Act on the Protection of Personal Information (APPI) and an obligation to report promptly in the event of an incident. Even if the agreement says "anonymized test data," it does not necessarily meet the detailed requirements of "anonymously processed information" under the law, so check the consistency between the actual data processing and the contract provisions.

Contract review using generative AI is convenient for identifying issues, but if you do not convey the development method and the status of specification finalization, or indicate whether fees are fixed or hourly, the results will remain formalistic comments. Use as review materials not only the background in the proposal and specifications but also the cloud services and OSS planned to be used. It is essential to check with developers whether the proposed revisions can actually be operated technically in the field. Details on entrusting the review of development agreements to an outside provider as part of routine work can be found at Legal Outsourcing.