Open source licenses: what businesses need to check

Open source code is free to use, but it isn’t free of conditions. Every component comes with a license, and that license decides what you owe when you use, change or distribute it. For most businesses the obligations are light: keep the copyright notices and move on. A few licenses, though, can require you to publish your own source code, and missing that can derail a customer deal, a funding round or the sale of your company.

Open source is licensed, not public domain

The people who write open source code keep their copyright. They give everyone a license to use it on certain terms, and if you break those terms you can lose the license and end up infringing. Code posted online with no license at all isn’t open source. By default all rights are reserved, and you don’t have clear permission to use it.

You probably use more of it than you think. Picture a SaaS startup in Toronto with a React front end and a Node back end. Run a scan and it’s common to find 800 or 900 packages in the dependency tree, most pulled in by other packages the team never chose directly. Nobody picked those licenses. They just arrived.

The licenses fall into two families. Permissive licenses let you do almost anything as long as you keep the notices. Copyleft licenses say that, in certain situations, you have to release the source code of your modified or combined work under the same license.

The further right a license sits, the more it can ask of your own code.

The main licenses side by side

License	Type	What you mainly owe	Typical business risk
MIT, BSD	Permissive	Keep copyright and license notices	Low
Apache 2.0	Permissive	Keep notices, include the NOTICE file, flag changed files; includes an express patent license	Low
MPL 2.0	Weak copyleft (file level)	Share the source of modified MPL files when you distribute	Low to moderate
LGPL	Weak copyleft (library level)	Share changes to the library; let users swap in their own version of it	Moderate
GPL v2, GPL v3	Strong copyleft	If you distribute a combined work, provide its full source under the GPL	High for software you ship
AGPL v3	Network copyleft	As GPL, plus offer source to users who interact with modified software over a network	High for SaaS

What exactly counts as a combined or derivative work under the GPL family is still argued about, especially for dynamic linking and plugins. Treat the table as a list of questions to ask, not a set of final answers.

What actually triggers the obligations

For most licenses, the key event is distribution. If you hand software to someone outside your company, as a download, a mobile app, an installed agent or firmware in a device, the license terms apply to that copy.

If the software only runs on your own servers and customers reach it through a browser, you’re generally not distributing it. That’s why GPL code sits in plenty of SaaS back ends without trouble. The AGPL was written to close that gap. Modify AGPL software, let people use it over a network, and you have to offer those users the source of your modified version.

Decision tree: if you give the software to anyone outside your company, license terms apply to that copy; if not, and it is modified AGPL code used over a network, you must offer the source to those users; otherwise obligations usually are not triggered but you should still keep a record — Distribution, or network use of modified AGPL code, is what usually switches the obligations on.

Watch for these triggers in particular:

Shipping a mobile or desktop app that includes GPL code
Selling hardware with embedded Linux or other open source firmware
Giving an enterprise customer an on-premise version of your SaaS product
Modifying an AGPL database, CMS or tool that users reach over the internet
Delivering custom software to a client, which is itself a distribution

Where businesses get caught out

Missing attribution. Permissive licenses are easy to comply with, yet loads of products ship without the notices. An “open source notices” screen or file usually fixes it in an afternoon.
Copyleft in a shipped product. A developer adds a GPL charting library to a desktop app you sell for $49 a seat. Nobody notices until a buyer’s lawyers run a scan during due diligence.
Licenses that don’t mix. Some can’t be combined. Apache 2.0 code, for example, is generally considered incompatible with GPL v2 but compatible with GPL v3.
Source-available licenses. Licenses like the Business Source License or the Server Side Public License look open but restrict commercial or competing use. They aren’t approved as open source by the Open Source Initiative, and they deserve a closer read.
License changes. Some projects move to a stricter license for new versions. The version you pinned two years ago may be on different terms from the one you upgrade to next month.

Open source in your contracts

Open source turns up in contracts in three places.

Contracts with developers and agencies

If you hire someone to build software, ask them to disclose the open source components they use and confirm none is under a license that would force you to release your own code without your approval. Their IP assignment can only cover the code they wrote, not the open source parts, so their warranties should deal with those parts directly.

Contracts with your customers

Enterprise customers often ask you to promise that your product contains no copyleft code that would affect them, and to give an indemnity for IP infringement. Make sure your promises match what’s actually in your codebase, and check the limitation of liability covers these claims the way you expect.

Investment and acquisitions

Due diligence almost always includes an open source review. Buyers look for copyleft code in shipped products, missing notices and unclear ownership. Problems found late can knock money off the price or delay closing. Problems you found and fixed yourself rarely do.

A policy that fits on one page

You don’t need a legal department for this. For a team of five developers, a one-page policy and an automated scanner is honestly plenty.

Keep a list of pre-approved licenses (typically MIT, BSD and Apache 2.0) that developers can use without asking.
Require a quick review before adding anything under GPL, LGPL, AGPL, MPL or a source-available license.
Generate a software bill of materials (SBOM) listing each component, version and license, and keep it current.
Run a scanning tool in your build pipeline to flag new dependencies and license changes.
Maintain a notices file with the required copyright and license texts, and ship it with the product.
Write down decisions, such as why a particular GPL tool is fine because it’s only used internally.

Next steps

Scan your main codebase and list any components under copyleft or source-available licenses.
For each one, note whether you distribute it, modify it or offer it over a network.
Add an attribution file to your product if you don’t have one.
Review your developer and customer contracts for open source warranties and indemnities.

If a customer contract asks for sweeping open source warranties, you can review the clause and your liability position with LegalWolf before you sign.

This article is general information, not legal or tax advice. Laws differ between countries and states and change over time, so check the rules that apply to you or speak to a qualified professional.