Software Development Agreements in Alberta: Key Terms

Custom software projects fail commercially far more often than they fail technically. The usual cause is not bad code. It is an agreement that never defined what “done” meant, never allocated ownership, and never priced change.

This guide from the Business Law team at Libra Law covers the terms that decide whether a software development project ends in a working product or a dispute, for both the company commissioning the work and the developer delivering it.

Start With Whether It Is Services or a Product

A development agreement is a contract for services with a deliverable attached. That distinction matters because it shapes what warranties apply, how termination works, and what happens to work in progress.

It also affects the ownership analysis. Custom development typically involves three overlapping categories of code:

Newly written custom code for this client
The developer’s pre-existing tools, libraries, and frameworks reused across clients
Third-party and open-source components

Almost every ownership dispute traces back to a contract that treated all three as one thing.

Scope and the Statement of Work

The commercial core of the agreement is the statement of work, and it should be a separate, dated schedule rather than prose buried in the main body.

A workable statement of work covers:

Functional requirements, in enough detail to be testable
Technical environment, platforms, and target browsers or devices
Deliverables and milestones, with dates
Client dependencies, meaning what the client has to provide and by when
Assumptions the pricing relies on
Explicit exclusions, which are as valuable as inclusions

Vague scope is the most expensive term in a software contract. “A modern, user-friendly portal” is not a specification. It is the beginning of an argument.

Change Control

Requirements will change. The question is whether change is a process or a fight.

A change control clause should define who can request changes, how the developer responds with an impact assessment on cost and schedule, who must approve, and what happens while approval is pending. Without it, the developer absorbs unpaid scope or the client receives surprise invoices, and both outcomes damage the relationship.

Acceptance Testing: Defining “Done”

Acceptance criteria and testing procedure deserve their own clause. Address:

Objective acceptance criteria tied to the statement of work
The testing period, and what happens if the client does not test
Deemed acceptance after a defined period of inaction or after the client puts the software into production use
How defects are classified by severity
How many correction cycles the developer must perform before the parties escalate

Deemed acceptance protects developers from projects that never formally end. A defect severity framework protects clients from being told a critical failure is a cosmetic issue.

Intellectual Property: The Clause That Matters Most

Default rules will not give you what you assume. Under Canadian copyright law, the employer of an employee generally owns copyright in work created in the course of employment, but that provision does not apply to independent contractors. A development firm you engage is a contractor. Absent a written assignment, the developer generally owns the copyright in what it wrote, and the client has an implied licence to use it for the commissioned purpose.

That is usually not what the client intended, and it becomes acute during a financing or sale when a buyer asks for clean title to the product. Our article on who owns employee inventions explains the underlying default rules in more depth.

A well-drafted IP clause typically does the following:

Assigns the custom deliverables to the client, using present-tense assignment language, effective on creation or on payment
Retains the developer’s background IP, with a broad, perpetual, royalty-free licence to the client to use that background IP as embedded in the deliverables
Waives moral rights to the extent permitted by law
Discloses open-source components and their licences, with a warranty that no component imposes copyleft obligations on the client’s proprietary code without disclosure
Requires the developer to have written assignments from its own staff and subcontractors, which is the gap most clients never verify
Includes further assurances, obliging cooperation with future registrations

The open-source point is not academic. A single component under a strong copyleft licence, integrated into a product the client intends to license commercially, can create obligations the client never contemplated.

Payment Terms

Tie payment to milestones and acceptance rather than to elapsed time. Also address:

Whether pricing is fixed fee, time and materials, or capped time and materials
Expenses and third-party costs, and who pays for licences and hosting
Holdback on final milestone until acceptance
Interest on overdue accounts, expressed as an annual rate and set lawfully. See the criminal interest rate in Canada
Whether the IP assignment is conditional on full payment, which is a meaningful lever for developers

Warranties, Limitations, and Indemnities

Developers should give a defined warranty period during which defects are corrected, and should resist an open-ended promise that the software will be error-free. Clients should require:

A performance warranty tied to the specification
A non-infringement warranty and an IP indemnity
A warranty that the code is free of malicious code

Limitation of liability is normally the most negotiated clause. Expect a cap tied to fees paid and an exclusion of indirect and consequential loss. Common carve-outs from the cap include IP infringement, breach of confidentiality, privacy breaches, and wilful misconduct.

For clients, be realistic: a developer paid $80,000 will not accept unlimited liability for your lost revenue. For developers, be realistic too: a cap set at one month of fees on a mission-critical system will not survive negotiation with a serious counterparty.

Confidentiality, Data, and Privacy

If the developer will access personal information, the agreement needs data-protection terms, not just a confidentiality clause.

Alberta’s Personal Information Protection Act governs how private-sector organizations handle personal information, and includes obligations around safeguards and breach reporting to the Office of the Information and Privacy Commissioner where there is a real risk of significant harm. Federal privacy legislation may also apply depending on the nature of the business and whether information crosses borders.

Cover, at minimum: permitted purposes, subcontractor and cloud-hosting disclosure, data location, security standards, breach notification timelines to the client, and what happens to data on termination.

Source Code, Escrow, and Exit

Two questions clients forget to ask until the relationship sours:

Do we get the source code? If the deliverable is compiled software and the agreement is silent, you may have a licence to run it and no ability to maintain it. Specify delivery of source code, build scripts, documentation, and credentials.

What happens if the developer disappears? For business-critical systems built by a small firm, source code escrow with defined release triggers is worth the cost.

A termination and transition clause should address termination for convenience and for cause, payment for work performed, delivery of work in progress, transfer of credentials and accounts, and a defined cooperation period for handover.

Independent Contractor Status

Long-term embedded developers can begin to look like employees, which creates payroll, benefit, and termination exposure the client never budgeted for. State the relationship clearly, and then make the working reality match the paper. See employee vs. contractor in Alberta.

Dispute Resolution and Governing Law

Specify Alberta law and Alberta courts, or a defined arbitration process. For projects with an offshore development partner, this clause is the difference between a manageable dispute and an unenforceable judgment.

Final Thoughts

Define scope in a schedule, price change through a process, decide ownership explicitly across all three categories of code, and tie payment to acceptance. Those four choices prevent most software development disputes.

Before you sign a development agreement, on either side of it, talk to a business lawyer at Libra Law.

This article is for general informational purposes only and does not constitute legal advice. For advice specific to your situation, consult a qualified professional.