Software Developers near you

Section 13(1) of the Copyright Act states that the author of a work is the first owner of the copyright in it. Section 13(3) gives first ownership to the employer where the author made the work in the course of employment under a contract of service, absent an agreement to the contrary. An independent development firm is not your employee, so that exception does not apply, and section 13(4) requires that no assignment or grant is valid unless it is in writing signed by the owner of the right or their duly authorized agent. Software is protected as a literary work, which the Canadian Intellectual Property Office confirms in listing computer programs among the literary works copyright covers.

The practical implication is that a quote, a purchase order and a paid invoice do not transfer copyright. You need a signed assignment, and it should be explicit about what it covers: the source code, the build and deployment scripts, the database design, the documentation and the design assets. Alternatively a licence may be appropriate, where the developer keeps ownership and grants you defined rights to use and modify the software. Both are legitimate; what causes trouble is not knowing which one you have.

Moral rights sit separately and survive an assignment. CIPO explains that moral rights cannot be assigned or transferred but can be waived, covering the rights of integrity, attribution and association, and that once waived they cannot be reacquired. This matters more than it sounds for software that will be heavily modified later by other people. Assignments can also be registered with CIPO, which keeps a record of the documentation and returns a certificate of registration. This is general information, not legal advice: have a lawyer draft or review the intellectual property terms on anything substantial.

Almost no custom software is written entirely from scratch. A typical application assembles dozens or hundreds of third-party and open-source components, and the developer cannot assign to you rights they never owned. Your assignment covers what they wrote; everything else reaches you under the terms of whoever published it, and those terms vary from near-unrestricted to conditions that attach obligations when software is distributed.

Ask for an inventory of third-party components and their licences as a deliverable, refreshed at handover rather than written once at the start. It is an ordinary request, it is generated automatically by standard tooling, and a developer who resists it is telling you something. The inventory also becomes your starting point for security, since a vulnerability in a widely used component is one of the most common ways otherwise well-built applications become exposed.

Commercial components deserve particular attention. If the application depends on a paid library, a hosted service or a subscription, establish whose name that agreement is in, what happens when it renews, and whether the software still functions if it lapses. The same applies to any proprietary framework the developer reuses across clients: you may be licensing it rather than owning it, which is workable if you know, and unpleasant if you discover it while trying to move to another firm.

If the software will be used by the public, accessibility may be a legal requirement rather than a refinement. In Ontario, designated public sector organizations and businesses or non-profits with 50 or more employees must make their websites and web content conform to WCAG 2.0 Level AA, with exceptions for live captions and pre-recorded audio descriptions. The requirement applies to content published after 1 January 2012 and the compliance date has passed, so this is an existing obligation rather than a future one for organizations of that size.

Accessibility is dramatically cheaper to build in than to retrofit, because it affects markup structure, colour and contrast choices, keyboard navigation, form labelling and error handling — decisions made early and expensive to revisit once an interface is complete. Put the conformance target in the specification, ask how the developer tests against it, and ask for the result as a deliverable. A firm that treats accessibility as an optional extra at the end has usually not built it before.

Requirements differ across the country and by sector, so confirm what applies to your organization where it operates and to the audiences it serves. This is general information, not legal advice. Note also that internal-facing tools are treated differently from public websites in Ontario's rules, which does not make inaccessible internal software a good idea when your own staff need to use it.

Ask for repository access from the first day rather than at the end. The cleanest arrangement is a source control organization owned by your business, with the developer's accounts added to it, so the work accumulates somewhere you control and you can see progress. Where the developer hosts the repository, agree in writing how and when you get a complete copy, and take one periodically instead of trusting a final delivery that may coincide with a disagreement.

Source code escrow, where a third party holds a copy released to you if agreed conditions occur, is a reasonable alternative when the developer will not give direct access, and it is more common with product vendors than with custom builds. It is not a substitute for ordinary access, since escrowed code without documentation, build scripts and deployment knowledge can be difficult for anyone else to use.

Handover should include the source code, build and deployment instructions, environment configuration, the third-party component inventory, database schema and migration scripts, administrative credentials, and hosting and domain accounts registered in your name. Ask specifically whether another competent developer could take this package and deploy the application without contacting the original firm. If the honest answer is no, the handover is incomplete regardless of what was delivered.

Custom software is not finished at launch; it needs someone to keep it running. Third-party dependencies release security updates, platforms and browsers change, and an application left untouched becomes harder to update the longer it is neglected, because the gap between its components and current versions widens. The Cyber Centre's baseline controls include applying patches to operating systems and applications, and meeting recognised security standards for web applications, which for a public-facing application is ongoing work rather than a launch checklist item.

Agree what happens after the warranty period ends. A maintenance arrangement typically covers dependency and security updates, monitoring and uptime, backups and tested restores, and a defined response when something breaks, with new features quoted separately. Be clear which of those you are buying, since agreements described as maintenance sometimes cover only defects in the original build and leave security updates to nobody.

Ask how you would be told about a security issue in a component your application relies on, and who decides when an urgent update is applied. Where the application stores personal information, that judgement connects directly to your safeguards obligations, which require protection appropriate to the sensitivity of the information and expect the approach to be revisited as technologies evolve and new risks emerge.