Using open source in commercial product — license compliance basics

Building a commercial SaaS that uses a bunch of open source libraries. My package.json has like 200 dependencies. How do I even know if I'm compliant? Some say MIT, some say Apache 2.0, saw one GPL thing in there. Help?

Quick guide to common licenses:

MIT/BSD: Do whatever you want, just include the license text somewhere (usually in your about page or docs). Super permissive.

Apache 2.0: Same as MIT but includes patent grant. Also requires noting any modifications. Still very commercial-friendly.

GPL: The "viral" one. If you distribute GPL code, you must make YOUR source code available under GPL too. For SaaS this usually doesn't apply since you're not distributing binaries.

AGPL: Like GPL but applies to SaaS specifically. This is the dangerous one for commercial products.

wait so if I have ONE GPL dependency buried in node_modules, I have to open source my entire product??

For SaaS (code runs on your servers, not distributed): Regular GPL doesn't apply. You only need to worry about AGPL.

For desktop/mobile apps (code distributed to users): Then yes, GPL matters. But it's about "distribution" — if GPL code is linked into your distributed binary, your code may need to be GPL too.

There are nuances (dynamic vs static linking, etc.) but that's the basic framework.

Practical advice: run `npx license-checker` on your project. It'll list all licenses in your dependency tree. Scan for GPL/AGPL/SSPL. If you find any, investigate whether you can swap for a permissive alternative (usually you can).

Just ran license-checker. Found one LGPL and one GPL-2.0. The GPL one is a dev dependency (testing framework) — does that matter if it's not in production?

Dev dependencies that don't ship with your product: not a problem. The license terms kick in when you distribute the code.

LGPL is usually fine even for distributed software — it only requires you to make the LGPL component's source available, not your whole codebase. But double-check how it's linked.

FYI: this matters a lot if you ever get acquired. We went through M&A due diligence and they scanned our entire codebase for license issues. Had to swap out two AGPL dependencies before closing. Easier to deal with now than during a transaction.

Reviving this thread because we just dealt with a tricky situation. Client was using a library that changed from MIT to GPL-3.0 in version 2.0. They had auto-updated without checking. Important lesson: pin your versions and review license changes before upgrading major versions.

Also worth noting: some projects are dual-licensed. You might be able to use the commercial license option if GPL doesn't work for your use case.

Update from my side: ended up setting up automated license scanning in our CI pipeline. Using FOSSA for this now. Every PR gets checked, and anything with AGPL/GPL/SSPL gets flagged before it can be merged. Saved us twice already.

Question though: what about the BSL (Business Source License) that some projects are using now? Seen it on a few databases and tools.

Good question on BSL. It's a "source available" license, not truly open source. Typically restricts production use for a certain period (often 3-4 years), after which it converts to a permissive license like Apache 2.0.

Key things to check with BSL: (1) What's the "Additional Use Grant" — some allow internal production use, others don't. (2) What's the conversion date and target license. (3) Whether your use case falls under the restricted competitive uses.

MongoDB's SSPL, Elastic's ELv2, and HashiCorp's BSL move all came from companies trying to prevent cloud providers from reselling their work. If you're building a SaaS that competes directly with the project, these licenses may restrict you.

Adding investor perspective: we now include OSS compliance in our standard technical due diligence checklist. We've passed on deals where founders couldn't produce a clean SBOM (software bill of materials) or had AGPL contamination throughout the stack.

Practical advice for founders: maintain a license inventory from day one. Tools like Snyk, FOSSA, or even the free `license-checker` mentioned earlier. Document your compliance decisions. It'll pay dividends when you're raising or selling.

Also be careful with AI-generated code — some models were trained on GPL code and may suggest GPL-licensed snippets without attribution. Emerging area of risk.

This thread is still so relevant. Just set up license-checker in our CI pipeline based on advice here from back in 2024. Already caught 2 problematic dependencies before they made it into production.

One thing I'd add: dont forget to check your container base images too. We were pulling Alpine Linux which is fine but some teams use images with more complex licensing situations.

@VCFundCounsel - your point about AI-generated code is super timely. We just had a situation where GitHub Copilot suggested code that was basically verbatim from a GPL project. Thankfully caught it in code review.

Any best practices for scanning AI-generated code specifically? The usual license checkers wont catch copied snippets that arent in package.json.