Open Source Software Risks: What Canadian Businesses Need to Know

Almost every commercial software product built in British Columbia today runs on code that somebody else wrote and gave away. That is not a problem — it is how modern software gets made. The problem is that “gave away” is not the same as “no strings attached.” Open source software risks arise because open source is licensed, not donated, and those licence conditions are legally enforceable.

For a Vancouver SaaS company preparing for a financing round, or a BC hardware business shipping firmware inside a product, an overlooked licence obligation tends to surface at the worst possible moment: midway through a buyer's due diligence, inside an enterprise customer's security questionnaire, or in a demand letter from a copyright holder.

This article sets out how open source software risks arise under Canadian copyright and contract law, how a dispute would actually be resolved in British Columbia, and what a defensible open source policy looks like for a BC business.

Open source is a licence, not a gift

Copyright in Canada is governed by the federal Copyright Act. It applies the same way in British Columbia as it does in Ontario or Nova Scotia — copyright is federal, and there is no separate provincial copyright regime.

Under the Copyright Act, the owner of copyright in a computer program holds the exclusive right to reproduce it, publish it, and produce derivative works from it (s. 3). Anyone who does one of those things without the owner's consent infringes copyright (s. 27).

An open source licence is that consent — but it is conditional consent. Permission to copy, modify and distribute is granted on terms: preserve the copyright notice, include the licence text, identify modifications, or make your own source code available. Fail the condition, and the permission you were relying on falls away. What remains is unlicensed copying.

That is the entire legal mechanism, and it is why “but it was free” is not a defence.

The licence families every BC business should be able to identify

Open source software risks are not evenly distributed across the ecosystem. Development teams should be able to sort every dependency into one of four buckets.

Permissive licences

MIT, BSD and Apache 2.0 impose light obligations: keep the copyright notice and licence text, and — under Apache 2.0 — flag significant changes. Apache 2.0 also contains an express patent grant and a patent-retaliation clause. These licences are generally compatible with closed-source commercial distribution.

Weak copyleft licences

LGPL, MPL 2.0 and EPL require that modifications to the covered files themselves be released under the same licence, but generally permit combination with proprietary code. The compliance work is real but contained — and under LGPL, linking method and relinking rights matter.

Strong copyleft licences

GPLv2 and GPLv3 are the licences behind the “contamination” concern. When you distribute a work that incorporates GPL code, the licence requires the complete corresponding source of that combined work to be offered under the GPL. For a company whose core asset is proprietary source code, that outcome can be commercially unacceptable.

Network copyleft

AGPLv3 closes the so-called “SaaS loophole.” Where GPL obligations are triggered by distribution, AGPL obligations can be triggered simply by letting users interact with the software over a network. A BC SaaS business that never ships a binary can still trigger AGPL source-disclosure obligations.

The practical takeaway: open source software risks do not come from using open source. They come from using a strong-copyleft or network-copyleft component in a way that triggers disclosure, without anyone having checked.

How does an open source licence breach become a legal problem in British Columbia?

A BC business facing an open source complaint is usually looking at two overlapping claims.

Copyright infringement. If a licence condition fails, the copying is unlicensed. The Copyright Act provides for injunctions, damages, an accounting of profits and delivery up (s. 34). A defendant who infringed for commercial purposes may also face statutory damages of between $500 and $20,000 per work (s. 38.1) — a figure that compounds quickly where a project involves many contributors and many protected works.

Breach of contract. Most open source licences can also be read as contracts. Framed that way, the claim is governed by ordinary British Columbia contract principles, and the remedy is contractual damages or specific performance.

The distinction is not academic. It affects forum, remedies and limitation period:

• The Copyright Act gives the Federal Court jurisdiction concurrent with the provincial superior courts, so a copyright claim can be brought in the Supreme Court of British Columbia or in the Federal Court. A pure contract claim belongs in the BC courts.
• A copyright claim is subject to the Copyright Act's three-year limitation period, running from when the claimant knew or ought reasonably to have known of the act. A contract claim in BC is subject to the two-year basic limitation period under the Limitation Act (BC).
• Interlocutory injunctive relief in the BC Supreme Court is sought under the Law and Equity Act (BC) and the Supreme Court Civil Rules, and is assessed on the familiar three-part test: a serious question to be tried, irreparable harm, and the balance of convenience.

It is worth being candid about the state of the authorities. There is no reported Canadian appellate decision squarely determining the enforceability of a copyleft licence. Canadian courts would apply established copyright and contract principles rather than any open-source-specific doctrine, which means the outcome turns on close analysis of the licence text and of what the company actually did with the code.

Exposure also arrives long before litigation. In practice, most open source software risks materialise as a stalled transaction or a lost enterprise deal rather than as a claim filed in court.

Five places open source software risks actually bite

1. Copyleft obligations in a product you licence commercially

A single GPL-licensed library compiled into a shipped binary can leave a company choosing between releasing proprietary source code, re-engineering the product, or negotiating a commercial licence from the copyright holder. All three are expensive, and the third is only available if the holder is willing to grant one.

2. Financing and M&A due diligence

Open source disclosure is now standard in Canadian technology transactions. Share and asset purchase agreements routinely include a representation that the company has not incorporated code under a licence requiring disclosure of proprietary source. A company that cannot substantiate that representation faces price adjustments, escrow holdbacks, special indemnities or a delayed closing.

Directors of a BC company should treat software governance as part of their statutory duty under the Business Corporations Act (BC) to act honestly and in good faith with a view to the best interests of the company (s. 142). An unmanaged licensing liability sitting inside the company's principal asset is a governance issue, not merely an engineering one.

3. Customer contracts, IP warranties and indemnities

Enterprise and public-sector customers expect a non-infringement warranty and an intellectual property indemnity. Those clauses do not carve out open source. If a copyleft obligation surfaces in the delivered product, the vendor typically owes defence and indemnity.

British Columbia provides no statutory implied warranty of non-infringement for software licensing that would soften those commitments. What the contract says is what governs — which is why the warranty language and the actual composition of the codebase need to be reconciled before signature, not after a customer audit.

4. Security and privacy exposure

Unmaintained dependencies are a security problem before they are a legal one. Log4Shell in 2021 and the xz-utils backdoor in 2024 both demonstrated how a single upstream component can compromise thousands of downstream products.

The legal consequences in BC follow quickly. The Personal Information Protection Act (BC) requires an organization to protect personal information in its custody or under its control by making reasonable security arrangements (s. 34). Shipping a known-vulnerable component with no patch management process is difficult to reconcile with that standard.

Note the federal-provincial split. PIPA governs private-sector personal information handling within British Columbia, while PIPEDA applies to federal works, undertakings and businesses, and to personal information collected in the course of commercial activity crossing provincial or national borders. PIPEDA imposes a mandatory breach-reporting regime; BC's PIPA does not currently contain an equivalent statutory reporting section, although notifying affected individuals and the Office of the Information and Privacy Commissioner for British Columbia is widely treated as best practice.

5. AI coding assistants

Generative coding tools trained on public repositories can reproduce licensed code without attribution or licence notice. That code arrives in your repository with no package manager entry and no licence metadata, so ordinary dependency scanning does not see it. It is now one of the least-controlled sources of open source software risks in a BC development team.

What about components with no licence — or a custom one?

No licence at all. Public code without a licence is not in the public domain. With no grant of permission, the default position under the Copyright Act is that copying, modifying and distributing the code infringe. “It was on a public repository” is not consent.

Custom or modified licences. A hand-drafted licence, or a familiar licence with an added clause, has to be read on its own terms. Some contain field-of-use restrictions, non-commercial limits or ethical-use clauses that are incompatible with a commercial product. Several projects have also relicensed from open source to source-available terms in recent years, so the licence that applied when a dependency was first adopted may not be the licence that applies to the version you are shipping today.

Is a software bill of materials required in Canada?

Not yet as a matter of general application — but the direction of travel is unambiguous.

Canada has no statute of general application requiring a software bill of materials (SBOM). Bill C-8, which received royal assent on 16 June 2026, enacted the Critical Cyber Systems Protection Act and amended the Telecommunications Act, creating cyber security programme, supply-chain risk and incident-reporting obligations for designated operators in the finance, telecommunications, energy and transportation sectors. It is being brought into force on a phased basis. Most BC businesses are not designated operators — but many are suppliers to them, and those obligations flow downstream through procurement terms.

For BC companies selling into Europe, the EU Cyber Resilience Act is the more immediate driver. It entered into force on 10 December 2024, its reporting obligations applied from 11 September 2026, and its main obligations apply from 11 December 2027. The Act requires manufacturers of products with digital elements to identify and document the components they use, including through a machine-readable software bill of materials.

In practice, the first pressure most BC companies feel is commercial rather than regulatory: enterprise customers are already requesting SBOMs in security questionnaires and writing them into master services agreements.

Building an open source policy that holds up

A written policy is the single most effective control over open source software risks, and a workable one is short, enforceable and owned by a named person. The core elements:

• Maintain an inventory. Generate an SBOM automatically as part of the build. You cannot manage what you cannot list.
• Set an approval matrix. Pre-approve permissive licences. Require sign-off for weak copyleft. Prohibit strong copyleft and network copyleft in distributed or hosted products absent written approval.
• Distinguish the use case. Internal tooling, distributed binaries and hosted SaaS trigger different obligations from the same licence. The policy should say so explicitly.
• Automate scanning. Licence and vulnerability scanning belongs in the build pipeline, not in an annual review.
• Fulfil attribution obligations. Ship a complete notices file. Most permissive-licence breaches are nothing more than missing attribution.
• Govern AI-generated code. Require review of AI-assisted contributions and keep a record of the tools in use.
• Align the paper with the practice. Your customer warranties, your supplier contracts and your actual development practices should describe the same reality.
• Assign ownership. Name the person accountable for the policy and review it annually.

The cost of doing this proactively is a fraction of the cost of remediating it during a live transaction, when the timeline belongs to someone else.

Frequently asked questions

Is it legal to use open source software in a commercial product in Canada?

Yes. Open source licences expressly permit commercial use. The legal question is never whether you may use the code, but whether you have complied with the conditions attached to that permission — attribution, licence inclusion, and, for copyleft licences, source disclosure.

Does using a GPL library force us to open source our entire product?

Not automatically. The obligation attaches to the work you distribute that incorporates the GPL code, and the analysis depends on how the components are combined and whether distribution occurs at all. It is a fact-specific question that should be answered before the product ships, not after.

Can we be sued in British Columbia over an open source licence?

Yes. A copyright claim may be brought in the Supreme Court of British Columbia or in the Federal Court, and a contractual claim in the BC courts. In practice, enforcement more often begins with a compliance demand than a filed claim — but the demand is backed by real statutory remedies.

What if the open source project has no identifiable owner?

Copyright still exists and is held by the contributors. A diffuse contributor base may make enforcement less likely; it does not make the obligation less real. It also offers no help in due diligence, where the buyer's counsel is assessing the licence terms rather than the probability of a lawsuit.

Our developers used an AI coding assistant. Are we exposed?

Possibly. If the tool reproduced licensed code, the licence obligations travel with it, and routine dependency scanning will not detect it because there is no package manifest entry. Reviewing AI-assisted contributions and documenting your tooling are sensible controls.

How far back can an open source claim reach?

A copyright claim under the Copyright Act is subject to a three-year limitation period running from when the claimant knew or ought reasonably to have known of the infringing act. A contract claim in British Columbia is subject to the two-year basic limitation period in the Limitation Act (BC). Ongoing distribution may amount to continuing conduct, so the analysis is rarely a simple count-back from today's date.

Managing open source software risks: the bottom line for BC businesses

Open source is not a risk to be avoided. It is an asset to be governed. The companies that run into difficulty are almost never the ones that used open source aggressively — they are the ones that used it without knowing what they had used.

Build the inventory, set the rules, automate the checks, and make sure your contracts reflect what your code actually does.

If you are preparing for a financing or a sale, negotiating an enterprise software agreement, or building an open source policy from scratch, our business law team advises British Columbia technology companies on software licensing, intellectual property due diligence and commercial contracts. Contact us to arrange a consultation.

_{Informational Purposes Only}

_{This article is intended for general informational purposes only and does not constitute legal advice. It does not create a solicitor-client relationship. Commercial leasing disputes are highly fact-specific, and the law may have changed since publication. You should consult a qualified BC commercial real estate lawyer before taking any steps to assign, sublet, or otherwise transfer your commercial lease.}