Compliance

Open-Source Licensing

Intermediate

Open-source libraries are essential and mostly free to use. But "open source" does not mean "no rules". Every dependency comes with a licence that grants rights and sets obligations. Some licences can force us to open our own source code or limit commercial use. Check the licence before you add a dependency, not after a customer's lawyer does.

This is the legal partner to Dependency & Supply-Chain Security, which is about vulnerabilities. Here the risk is licence obligations. Most common licences (MIT, Apache 2.0, BSD) are permissive and fine for commercial use, with few obligations (usually attribution). Others, such as strong copyleft licences like GPL/AGPL, can require us to release the source of our own software. For a commercial SaaS that may not be acceptable.

For newer engineers the rule is simple: do not just pull in a package because it works. Check that its licence is fine for commercial use, and when in doubt, ask. Licence problems are cheap to avoid up front and expensive to fix once shipped, or during certification and due diligence.

Check before you add

DoCheck a dependency's licence before adopting it, and prefer permissive licences (MIT, Apache 2.0, BSD) for commercial use.
DoMeet the obligations of the licences you use. This usually means attribution and including the licence text. Some require more.
DoKnow what licences are in your dependency tree (a generated licence report or SBOM helps), including indirect ones (see Dependency & Supply-Chain Security).
ConsiderAutomated licence scanning in the pipeline to flag disallowed licences before they merge.
AvoidAdding a dependency under an unfamiliar or restrictive licence without checking. Also avoid copy-pasting code from the internet without knowing its licence.
NeverAdd a strong-copyleft (such as GPL/AGPL) or otherwise commercially-incompatible dependency into our proprietary product without explicit approval. It can legally force us to disclose our source.

Respect rights both ways

DoHonour attribution and notice requirements (for example, a third-party notices file) so we meet our obligations to the projects we use.
DoRespect others' intellectual property. Do not paste proprietary or unlicensed code into our codebase. This includes AI-suggested code that may copy licensed snippets (see AI-Assisted Development).
ConsiderWhen we contribute to or release open source, doing it through the approved process with the right licence and approvals.
AvoidAssuming "it's on GitHub" means it is free to use however we like. Public does not mean unrestricted.

Self-review checklist

AskWhat licence is this dependency under, and is it compatible with our commercial, proprietary product?
AskAre there obligations (attribution, notices) I need to meet?
AskHave I checked transitive dependencies, not just the top-level package?
AskIs any code here copied from somewhere without a clear right to use it?

Why it matters: Licence violations are a legal and commercial risk that shows up at the worst times: during acquisition due diligence, certification, or a customer's review. A copyleft obligation can, in principle, force us to disclose our proprietary code. Checking licences up front keeps our dependency use lawful, our IP protected, and our deals unblocked.