Open-Source Licenses in Commercial Software: What Actually Bites

Open-Source Licenses in Commercial Software: What Actually Bites

Every commercial codebase I review is mostly other people's code. Your product is a thin layer of business logic on top of hundreds of open-source packages. Each one carries a license — a contract you accepted by npm install. Most teams never read any of them until a client's legal team, an acquirer's due-diligence checklist, or a vendor's enforcement email forces the issue.

The good news: you don't need to read 400 licenses. You just need to know which category each dependency falls into — the same way you don't read every rental lease before signing, you just check whether you're renting, financing, or buying outright. The categories, not the individual texts, decide what you owe. (Usual note: this is engineering guidance, not legal advice.)

The three risk tiers

Permissive — MIT, Apache-2.0, BSD, ISC. Do almost anything, keep the copyright notice. Apache-2.0 adds an explicit patent grant, which is why corporate legal teams prefer it. Obligation in practice: ship the license texts with your product. Risk: near zero.

Weak copyleft — LGPL, MPL-2.0. You can use the library inside proprietary software, but the library itself must stay swappable and open. For LGPL that classically means dynamic linking: the user must be able to replace the LGPL component with their own build. Risk: real, but manageable if you know the boundary rules.

Strong copyleft — GPL, AGPL. If you distribute software that incorporates GPL code, your software must be GPL too. AGPL closes the SaaS loophole: even serving the software over a network triggers the source-sharing obligation. Risk: this is where commercial products get burned.

Where teams actually get burned

The AGPL dependency nobody flagged

The most common real-world case right now is computer vision. Ultralytics YOLO — the default object-detection stack half the industry reaches for — is AGPL-3.0 with a paid commercial license. Pull it into a closed-source product and you have exactly two compliant options: buy the commercial license, or open-source your product under AGPL.

In commercial CV work the practical answer is often a third one: build on Apache-2.0 model families instead, and make that decision before the architecture hardens, not after the pilot succeeds.

LGPL binaries hiding inside vendor products

Proprietary hardware ecosystems — access control, CCTV, kiosk systems — love to bundle FFmpeg. Crack open a vendor's SDK folder and you'll find avcodec.dll and avformat.dll sitting next to closed binaries. That's LGPL code inside a proprietary product, which is allowed as long as the license text ships with it, the LGPL parts remain replaceable, and source for those parts is available. When you integrate such an SDK into your own deliverable, its compliance gaps become your compliance gaps.

The permissive wrapper illusion

An MIT-licensed npm package can be a thin wrapper over an LGPL native library. The wrapper's license tells you nothing about what you're actually linking against. License scanners that only read package.json miss this completely — you have to look at what the code loads at runtime.

The SDK with no license at all

Hardware vendors — vending controllers, biometric readers, camera SDKs — often ship binary SDKs with no license text whatsoever. No license does not mean "do whatever you want." It means default copyright, all rights reserved, and your right to redistribute it inside your product is legally undefined. The fix is contractual: get redistribution rights in writing in the supply agreement before the SDK goes anywhere near production.

A five-minute triage

What I check before any commercial delivery

1. Inventory everything — direct and transitive dependencies, plus native libraries and vendor binaries that never appear in a manifest.
2. Flag the copyleft and the unlicensed — those two buckets are where all the real risk lives.
3. Check what the code loads, not just what the manifest says — wrappers and bundled DLLs are the blind spots.
4. Put vendor SDK rights in the contract — redistribution, sublicensing, and what happens if the vendor disappears.

One more trap deserves its own article: in AI products, the code license, the model weights license, and the dataset license are three different things, and a green light on one says nothing about the others. That's the next post in this series.

For how licensing decisions interact with hardware integration work, see normalizing multi-protocol IoT devices — vendor SDKs are where both problems meet.