OSS license types fall into two broad families, permissive and copyleft, and the difference decides whether you can use a component freely or whether it can force you to open-source your own code. Every open source package you pull in comes with a license, and that license is a legal contract, not a formality. Choosing dependencies without reading their license terms is how a startup ends up rewriting a feature weeks before an acquisition closes because a single AGPL component tainted the codebase.
The two families
Permissive licenses let you do almost anything, use, modify, distribute, and sell, as long as you preserve the copyright notice and license text. They impose no obligation to share your own source code. MIT, BSD, and Apache 2.0 are the common examples.
Copyleft licenses require that derivative works be released under the same license. If you distribute software that includes copyleft code, you may be obligated to release your combined work under those same terms, including your proprietary source. The GPL family is the classic case.
Almost every practical licensing decision comes down to knowing which family a dependency belongs to and what "derivative work" and "distribution" mean for your situation.
The permissive licenses worth knowing
MIT is the most common license in the npm and PyPI ecosystems. It is short, permissive, and imposes only attribution. You can build a closed-source product on MIT-licensed dependencies without sharing anything.
Apache 2.0 is permissive like MIT but adds an explicit patent grant, contributors grant you a license to any patents their contribution embodies, and a termination clause if you sue over patents. That patent grant is why many companies prefer Apache 2.0 for larger projects.
BSD comes in 2-clause and 3-clause variants. Both are permissive; the 3-clause version adds a no-endorsement clause. Functionally similar to MIT for most uses.
The compliance obligation for all of these is real but light: preserve the license text and attribution, typically in a NOTICE file or a bundled licenses page. Skipping attribution is still a license violation even for permissive terms.
The copyleft licenses that need care
GPL (v2 and v3) is strong copyleft. Distributing a work that incorporates GPL code generally requires releasing the whole combined work under the GPL, source included. For internal-only tools this may never trigger, because internal use is not distribution, but the moment you ship the software to a customer, the obligation can attach.
LGPL is a weaker copyleft aimed at libraries. You can link to an LGPL library from proprietary code without your code becoming GPL, provided users can replace the library, which for dynamically linked libraries is usually straightforward and for statically linked ones requires more care.
AGPL is the one that surprises teams. It closes the "SaaS loophole" in the GPL: if you run modified AGPL software as a network service, letting users interact with it over a network counts as distribution, so you may owe them your source. A single AGPL dependency in a hosted product can create an obligation to publish your service's source code. This is the license most commercial policies flag as prohibited by default.
The murky and the missing
Some licenses do not fit the two families cleanly. The MPL (Mozilla Public License) is file-level copyleft, obligations attach per-file rather than to the whole work. The "source-available" licenses such as BSL and SSPL are not open source by the OSI definition at all and carry usage restrictions that can bite a competitor.
The worst case is no license. Code with no license attached is not free to use, default copyright law reserves all rights to the author. A GitHub repo without a LICENSE file is legally "all rights reserved," regardless of how public it is.
Managing this at scale
You cannot review licenses by hand once your dependency count passes a few dozen, and transitive dependencies mean the license you need to worry about may belong to a package you never chose. This is where a software bill of materials (SBOM) and automated license detection matter. A tool that generates an SBOM records the license of every component, direct and transitive, and can gate your build against a policy, for example blocking any AGPL or unlicensed component from entering a distributed product. An SCA tool such as Safeguard can flag a copyleft license buried three levels deep in your tree that no manual review of your package.json would ever catch.
Write the policy down: which license types are allowed, which need legal review, and which are prohibited. Then enforce it in CI rather than relying on developers to remember it. The Safeguard Academy has a template policy you can adapt.
FAQ
What are the main OSS license types?
They divide into permissive licenses (MIT, BSD, Apache 2.0), which allow closed-source use with attribution, and copyleft licenses (GPL, LGPL, AGPL, MPL), which require derivative works to be shared under the same terms. Source-available licenses like BSL and SSPL are a separate, non-open-source category.
Which open source license is safest for a commercial product?
Permissive licenses, MIT, BSD, and Apache 2.0, carry the lowest obligation and are safest for closed-source commercial products. Apache 2.0 additionally includes a patent grant, which many companies prefer for larger dependencies.
Why is AGPL considered risky?
AGPL treats offering modified software as a network service as distribution, so a hosted SaaS product using AGPL code can be obligated to publish its source. Most commercial license policies prohibit AGPL by default for this reason.
What happens if a dependency has no license?
Code without a license is not open source, default copyright reserves all rights to the author, so you have no legal right to use it. A public repository with no LICENSE file is effectively "all rights reserved."