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?
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.
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.
@carlos_r_15 - 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.
AI-generated content copyright is still unsettled. The Copyright Office has said AI output without meaningful human creative input can't be copyrighted. But if you substantially modify or curate the AI output, there might be a human authorship argument.