Open-Source Software Licensing Risks for Ontario Businesses

Almost every modern software product is built on open-source code — libraries, frameworks, and components that other developers have made freely available. Using open-source software is not the problem. The problem is that "free" does not mean "no obligations," and a lot of businesses discover the strings attached only after a customer, investor, or acquirer's lawyer asks to see a list of every open-source component in the product.

This article walks through the main open-source software licensing risks an Ontario business should understand before building — or selling — a product on open-source foundations.

Open-Source Licences Are Still Licences

Open-source code is protected by copyright just like proprietary code. The difference is that the copyright holder has published a licence granting broad permission to use, copy, modify, and often redistribute the code — but that permission almost always comes with conditions. Ignore the conditions, and you are using someone else's copyrighted work without a valid licence, which exposes you to an infringement claim regardless of how well-known or "free" the code seemed.

Two Broad Categories of Open-Source Licence

Open-source licences generally fall into two rough categories, though many individual licences have their own variations:

The exact obligations depend entirely on the specific licence text attached to each component — this table describes general tendencies, not a substitute for reading the actual licence.

Where the Risk Actually Shows Up

• The "viral" copyleft problem. If a strong copyleft-licensed component is combined with your proprietary code in a way the licence treats as a single derivative work, you may be obligated to release your own source code under the same terms — the opposite of what most businesses want for a commercial product.
• Unknown provenance. Developers frequently pull in dependencies (and dependencies of dependencies) without anyone tracking which licences apply. You cannot manage a risk you cannot see.
• Patent and warranty exposure. Most open-source licences disclaim all warranties and offer no protection if the code turns out to infringe a third party's patent or copyright — the risk sits with whoever ships the product commercially.
• Due diligence failures. Buyers, investors, and enterprise customers increasingly ask for a full accounting of open-source components before closing a deal or signing a contract. Finding a licensing problem during due diligence can delay or kill a transaction.
• Attribution and notice obligations. Even permissive licences often require you to keep copyright notices intact and include specific attribution language in your documentation or "about" screen — an easy requirement to overlook and technically breach.

Building an Open-Source Governance Practice

1. Maintain an inventory. Keep a running list — sometimes called a software bill of materials — of every open-source component your product uses, including its licence type.
2. Set an approval policy. Decide in advance which licence categories your business will use freely, which need legal review before approval, and which are off-limits for your product.
3. Review before you ship, not after. Licence review is far cheaper before a component is embedded throughout your codebase than after.
4. Document how each component is used. Whether code is statically linked, dynamically linked, or merely called as a separate service can affect whether copyleft obligations are triggered — a technical question with legal consequences, best answered by someone who understands both.
5. Revisit before any sale, financing round, or major customer contract. These are the moments someone else's lawyer will actually check your work.

Frequently asked questions