Who owns the code your contractor wrote?
Your product runs on code written by a contractor, an agency, or a technical co-founder who was never on payroll. Do you own it?
Under Canadian law, probably not, unless a signed document says so. Two Ontario decisions this year show how the question gets litigated, and what settles it.
The default rule favours the developer
Software is protected by copyright as a literary work. Under the Copyright Act, RSC 1985, c C-42, the author is the first owner (s 13(1)). An employer owns what an employee writes in the course of employment, absent agreement otherwise (s 13(3)). A contractor is not an employee, and keeps the copyright unless it is assigned in writing and signed (s 13(4)).
Whether a developer is an employee or a contractor depends on the whole relationship, not the label in the agreement (671122 Ontario Ltd v Sagaz Industries Canada Inc, 2001 SCC 59). The question can turn on something as simple as a pleading. In DeliveryEase Inc v Tahir, 2026 ONSC 4558, a co-founder argued on an injunction motion that he had been a contractor. Yet, his own statement of defence had admitted he was an employee, and the court treated the admission as bringing subsection 13(3) into play (at paras 58–61).
What you have without a written assignment
An implied licence to use the software for the purpose it was commissioned for (Netupsky v Dominion Bridge Co Ltd, [1972] SCR 368). That lets you run it. It leaves open whether you can modify it, hire someone else to maintain it, license it to customers, or sell it with the business, and it does nothing to stop the developer from using the same code for a competitor.
For a company whose product is the software, an implied licence is not ownership, and investors and acquirers will not treat it as such.
The code the developer brought with them
Most developers do not start from nothing. They bring libraries, frameworks, and repositories of earlier projects. If the agreement does not say who owns that pre-existing code, both sides are relying on an argument.
That argument was made and lost in Bruce Community Futures Development Corporation v Future Health Technologies Inc, 2026 ONSC 5662. A consultant built a patient-monitoring platform for a client under an agreement giving the client all intellectual property "developed or produced under this Agreement", while the consultant kept property "identified as Consultant Intellectual Property". No list was ever attached (at paras 12–13). When the client went into receivership, the consultant claimed the core platform, which it said had been largely built before the agreement.
The court held that the platform belonged to the client. It was produced under the agreement, since the service could not have run without it, and the consultant's reading would have left the client with no usable system and no licence, which the court called commercially absurd (at paras 17, 24–25). The agreement was also a sufficient assignment under subsection 13(4) (at paras 30–32).
The lesson runs both ways. A developer who wants to keep reusable components must identify them. A client whose product depends on them needs ownership or a licence that survives the engagement.
Who holds the keys
Ownership on paper is one thing. Control of the repositories, hosting accounts, domains, and app store listings is another. A company whose only copy of its product sits in accounts controlled by one person has given that person a veto, whatever the contract says.
In DeliveryEase, the company had an assignment. It still had to go to court, because the co-founder held the only credentials to the source code and the company could not serve its main customer. Read more about the DeliveryEase case here.
Open-source and third-party components
Most modern software incorporates open-source code. The developer can assign only what they wrote. The rest comes with licence terms, and some of those terms attach conditions to your own code, such as an obligation to release it under the same licence. A developer who cannot tell you what is in the build has given you a product you cannot fully diligence.
What the development agreement should say
An assignment in the present tense. "The developer assigns", not "will assign". State when it takes effect, for example on payment of each milestone.
A waiver of moral rights. Developers rarely assert them, but an acquirer will ask.
A schedule of pre-existing code the developer is bringing in, with a perpetual, royalty-free licence to use, modify, and sublicense whatever is built into the deliverables.
A bill of materials. Disclosure of every open-source and third-party component and its licence, with a warranty that nothing in the build imposes conditions you have not accepted.
Company-owned accounts. Repositories, cloud infrastructure, domains, app stores, and third-party services registered to the company, with at least two administrators.
Delivery of source, build instructions, and documentation at each milestone, not only at the end.
A handover clause that survives termination, however the relationship ends.
Further assurances. A promise to sign whatever is needed later to confirm or record the transfer.
If the code is already written
Ask for a confirmatory assignment now, while the relationship is good, and move the accounts into the company's name at the same time. Both are short tasks. Both become difficult, and expensive, once there is a dispute, a financing, or a sale.
If you are the developer
The default is in your favour, and it is negotiable. A client may need only a licence, and a full assignment is worth more and can be priced accordingly. If you intend to reuse components, say so in the agreement before you start; relying on the argument that the code predates the engagement did not work in Future Health. And keep your own records of what you brought, what you built, and when.
This post is general information about Canadian law. It is not legal advice about your situation.
