How to Check an Open Source License for Commercial Use
Find the actual licence file and any extra terms, identify the licence family, then map it to how you will use the code: internal use, distributing software, or offering it as a network service. Permissive licences mostly require notices; copyleft adds source obligations; source-available licences may restrict commercial use outright.
Is this legal advice?
No. This guide explains how developers commonly read open-source licences so you can ask better questions and spot obvious problems. Consult a lawyer for high-stakes cases, such as building a product on copyleft code, due diligence for an acquisition or anything involving patents.
What does “commercial use” actually depend on?
Almost every licence approved by the Open Source Initiative allows commercial use. The real question is what obligations your specific use triggers. Those obligations depend far more on how the code reaches other people than on whether you make money.
Three situations cover most cases. Internal use means running the software inside your company without giving it to anyone. Distribution means shipping binaries or source to customers, including mobile apps, desktop apps, devices and on-premise installs. Network use means users interact with the software over the internet without receiving a copy.
Most copyleft obligations are triggered by distribution. The AGPL is the notable exception, because it extends source obligations to users who interact with modified software over a network.
Modification matters too. Using a library unchanged usually carries lighter duties than shipping a modified copy, and some licences, such as the MPL, attach obligations only to the files you change.
How do the main licences compare?
The table is a simplified orientation, not a substitute for the licence text. Each licence has conditions this summary does not capture.
| Licence | Family | Main obligations | Typical commercial fit |
|---|---|---|---|
| MIT | Permissive | Keep the copyright and licence notice | Very broad; easy to use in closed products |
| BSD 2-Clause and 3-Clause | Permissive | Keep notices; 3-Clause also bars using contributors’ names for endorsement | Very broad |
| Apache 2.0 | Permissive | Keep notices and NOTICE file, state changes; includes an explicit patent licence | Broad; common choice for companies |
| MPL 2.0 | Weak copyleft (file level) | Share changes to MPL-covered files when distributing | Usable in closed products if you keep changes in those files open |
| LGPL | Weak copyleft (library) | Share changes to the library; allow users to replace it | Usable via dynamic linking with care |
| GPL v2 and v3 | Strong copyleft | Distribute complete corresponding source of the combined work under the GPL | Hard fit for closed distributed products |
| AGPL v3 | Network copyleft | GPL obligations plus offering source to network users of modified versions | Hard fit for closed SaaS built on modified code |
| Source-available (BSL, SSPL, Elastic License, fair-code) | Not open source | Custom limits, often on competing hosted services | Read every clause; may prohibit your use |
How do you check a licence step by step?
- Open the repository’s LICENSE or COPYING file, not just the licence badge or the package registry field, which can be outdated.
- Look for additional files and sections: NOTICE, PATENTS, COMMERCIAL, EE or enterprise folders, and licence headers in individual source files.
- Check whether different directories use different licences. Open-core projects often keep an enterprise directory under separate terms.
- Identify the SPDX identifier if one is given, which removes ambiguity such as GPL-2.0-only versus GPL-2.0-or-later.
- Decide your use case: internal, distributed, or network service, and whether you will modify the code.
- List the obligations that use triggers, such as notices, source offers or licence compatibility for your own code.
- Scan dependencies too, because a permissive project can pull in copyleft or source-available packages.
- Use a scanner such as ScanCode Toolkit or an SBOM tool to list licences across the dependency tree, then review anything unusual by hand.
- Record the result, the commit you checked and any open questions for legal review.
What do permissive licences require?
MIT, BSD and Apache 2.0 let you use, modify and sell the software, including in closed-source products. The core obligation is attribution: include the copyright notice and licence text with what you distribute, often in an open-source notices screen or file.
Apache 2.0 adds a few more duties: carry forward the NOTICE file contents where applicable and mark files you changed. It also includes an express patent grant from contributors and a clause that ends that grant if you sue over patents in the work, which is one reason companies like it.
None of these licences grant trademark rights. You can ship the code; you cannot necessarily use the project’s name and logo for your product.
In practice, keep a generated third-party notices file in every release. Most package ecosystems have tools that collect licence texts from dependencies, which turns attribution into a build step rather than a manual chore.
What changes with GPL and AGPL?
The GPL requires that when you distribute a work based on GPL code, you provide the complete corresponding source under the GPL. Using GPL tools internally, or running a GPL program on your server without distributing it, generally does not trigger that requirement.
The AGPL closes that server gap. If you modify AGPL software and let users interact with it over a network, you must offer those users the source of your modified version. That is why many companies restrict AGPL dependencies in SaaS products.
What counts as a combined or derivative work, especially across process boundaries, APIs and plugins, is a genuinely contested area. This is where a lawyer is worth the cost.
Licence compatibility is the other trap. Code under GPL v2 only and Apache 2.0 are widely considered incompatible, while GPL v3 was written to be compatible with Apache 2.0. Mixing licences inside one distributed product needs a deliberate check.
How are source-available licences different?
Licences such as the Business Source License, the Server Side Public License, the Elastic License 2.0 and fair-code licences like n8n’s Sustainable Use License publish code but add restrictions that open-source definitions do not allow. Typical limits target offering the software as a competing hosted service or using it commercially beyond internal purposes.
Some, like the BSL, convert to an open-source licence after a stated period. Others include additional use grants that permit many uses. The only reliable approach is to read the specific licence and any grant text for the exact version you use, since projects sometimes change licences between releases.
Where does it break? Common mistakes
- Trusting the GitHub sidebar or package metadata instead of the licence file and per-file headers.
- Assuming “open source” in a README means an OSI-approved licence.
- Forgetting that model weights, datasets and documentation can carry different licences from the code.
- Ignoring transitive dependencies, which is where many copyleft surprises hide.
- Treating “no licence” as permission. Code without a licence is by default all rights reserved.
- Checking once and never again, even though a later release may switch licences.
What about repositories with no licence or AI model licences?
A public repository without a licence is visible, not free to use. Unless the author grants rights, copyright law generally reserves them. If you need the code, ask the author to add a licence rather than relying on its public visibility.
Open-weight AI models deserve extra care. Some use standard licences such as Apache 2.0 or MIT, while others use custom model licences with acceptable-use policies, user thresholds or attribution rules. Check the model card and licence for each model, separately from the inference code.
RepoLoot’s catalog notes the licence family for each project, which helps you shortlist, but the licence file in the exact version you adopt is always the source of truth.
Frequently asked questions
- Can I use MIT-licensed code in a commercial closed-source product?
- Generally yes. The MIT licence permits commercial use, modification and distribution in closed products. The key condition is including the copyright notice and licence text with copies you distribute. It gives no trademark rights and comes without warranty. For high-stakes cases, consult a lawyer.
- Can I build a SaaS on GPL software?
- Often yes, because running GPL software on your servers without distributing it usually does not trigger its source requirement. AGPL is different: modified AGPL software used by people over a network requires offering them the source. Check the exact licence and consult a lawyer for high-stakes cases.
- Is Apache 2.0 safer than MIT for companies?
- Both are permissive and business-friendly. Apache 2.0 is longer and includes an explicit patent licence plus rules about NOTICE files and marking changes, which many legal teams value. MIT is shorter and simpler. Neither is universally safer; your policies and dependencies decide which fits.
- Are source-available licences safe for commercial use?
- Sometimes, depending on the terms. Many allow internal commercial use but restrict offering the software as a hosted or managed service, or competing with the licensor. Read the specific licence and any additional use grant for the version you use, and get legal review before building a business on it.