Open-Source Licenses in Commercial Software

Business software often includes third-party components. Their licenses govern use, distribution, and source-code obligations. Before accepting a vendor delivery, request component versions, license texts, and compliance evidence. Distinguish parts permitted in a paid product from those needing further review.

Many commercial codebases I review rely heavily on third-party code. Your product is a thin layer of business logic on top of hundreds of open-source packages. Each carries license terms that need review before use and distribution. 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.

License categories help triage risk, but the answer follows the exact license text, how components are combined, and who receives or accesses them. This guide supports engineering questions; counsel assesses their application to your contract and product.

Three permission groups to check

Permissive — MIT, Apache-2.0, BSD, ISC. These generally allow commercial closed-source products. Preserve license and copyright notices; check applicable change notices, NOTICE files, trademark and patent terms. Permissive does not mean obligation-free.

Limited copyleft — LGPL, MPL-2.0. Copyleft preserves freedoms or source availability for covered parts. LGPL boundaries depend on the library and how it is combined; users need the modification or replacement mechanisms required by the license version. MPL follows covered files rather than LGPL’s library-replacement rules. Modifications and distribution determine required notices and source availability.

Strong copyleft — GPL, AGPL. Distributing a combined covered work can require GPL licensing and corresponding source for that work. Independent components do not automatically make an entire business system GPL. AGPL Section 13 adds a source offer for users interacting with a modified version over a network. Examine covered-work boundaries and integration; neither “SaaS” nor “internal” is a complete assessment.

Where teams actually get burned

The AGPL dependency nobody flagged

Ultralytics offers YOLO code under AGPL-3.0 and a commercial license. Before using it in a closed-source product, assess covered parts, modification, distribution, and user access. If source obligations conflict with the product plan, evaluate a commercial license or alternative components. Apache-2.0 alternatives still need checks of model weights, datasets, and on-site performance. Decide before replacement becomes expensive.

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. Check the actual FFmpeg build: its enabled components can change the applicable license. An LGPL build can be included in a proprietary product when the version's obligations are met, including required notices, source, replacement mechanisms, and relevant reverse-engineering rights. 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 groups need particular attention; permissive licenses can also impose obligations.
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. See code, model weights, and dataset licenses for that separate review.

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