Safeguard
Licensing

Software License Types: The Complete Guide

Permissive, copyleft, proprietary, and public domain: how the main software license types differ, what each one obligates you to do, and how to pick one for your project.

Yukti Singhal
Head of Product
Updated 6 min read

Software licenses are legal instruments that define what you may do with a piece of code: use it, copy it, modify it, and redistribute it, and under which conditions. The main types of software licenses fall into four buckets: permissive open source, copyleft open source, proprietary, and public domain equivalents. A software license agreement is the same thing by another name — whichever term your legal team uses, the types of software license agreement you'll encounter map onto these same four buckets. Which bucket a component sits in determines your obligations, so identifying the license type of every dependency is a compliance task, not a formality.

Without a license, code is not free to use. Copyright law applies by default, so "no license" means all rights reserved. That is why every serious project, open or closed, declares one.

How Do Software Licenses Actually Work?

A software license is a grant of permission from the copyright holder. The author owns the code the moment it is written; the license is the document that lets anyone else legally use it. Open source licenses grant broad rights up front in exchange for conditions such as attribution or share-alike terms. Proprietary licenses grant narrow rights, usually for payment, and keep everything else reserved.

For engineering teams, the practical consequence is that every dependency in your tree carries terms you have implicitly accepted. Most software licenses in the open source world are low-friction, but a handful of them carry obligations that can affect how you ship your own product.

Which Software License Types Should You Know?

Permissive and copyleft are the two types of license you will meet most often in open source. Here is how the four main categories compare:

CategoryExamplesCore conditionCommercial-friendly
PermissiveMIT, Apache-2.0, BSD-2/3-ClauseKeep the attribution noticeYes
Weak copyleftLGPL-2.1/3.0, MPL-2.0, EPL-2.0Share changes to the licensed files/libraryYes, with care
Strong copyleftGPL-2.0, GPL-3.0, AGPL-3.0Derivative works must use the same licenseDepends on your model
Public domain equivalentUnlicense, CC0, 0BSDNoneYes

Permissive licenses

Permissive open source license types (MIT, Apache-2.0, BSD) let you use, modify, sell, and close-source the code. The main obligation is preserving the copyright notice and license text. Apache-2.0 adds an explicit patent grant and requires you to state significant changes, which is why many enterprises prefer it over MIT for anything patent-adjacent.

Copyleft licenses

Copyleft flips the deal: you get the same broad rights, but derivative works must be released under the same terms. Strong copyleft (GPL family) applies to the whole combined work you distribute. Weak copyleft (LGPL, MPL) confines the obligation to the licensed component itself, so linking against an LGPL library from proprietary code is generally workable. AGPL-3.0 extends the trigger to network use, which is why many SaaS companies flag it in policy.

Proprietary licenses

Proprietary or commercial licenses reserve all rights not explicitly granted: typically a right to run the software, with no right to inspect, modify, or redistribute. EULAs and enterprise agreements fall here, as do "source-available" licenses like BUSL, which look open but restrict production use.

Public domain equivalents

The Unlicense, CC0, and 0BSD waive copyright as far as the law allows. No attribution is required. They are rare in dependency trees but trivially safe when they appear.

How Do You Choose a License Type for Your Own Project?

The license type you choose signals what you want back from users of your code:

  • You want maximum adoption: MIT or Apache-2.0. Companies can embed the code in commercial products without legal review friction. Apache-2.0 is the safer default when patents could be relevant.
  • You want improvements shared back: GPL-3.0 forces distributors of derivative works to publish their changes. This protects against closed forks but excludes some commercial users.
  • You want to protect a SaaS business: AGPL-3.0 closes the "run it as a service without sharing" gap, which is why databases like MongoDB (before SSPL) and Grafana adopted it.
  • You are publishing a library and want wide use with some protection: LGPL or MPL-2.0 keep changes to your code open without infecting applications that merely link to it.

Whatever you pick, apply it properly: a LICENSE file in the repository root and an SPDX identifier (MIT, Apache-2.0, GPL-3.0-only) in your package manifest so scanners can detect it.

Why Do License Types Matter for Compliance?

Comparing different types of licenses stops being academic the moment you ship. Distributing a product that includes GPL code without releasing your source, or stripping an MIT attribution notice, is copyright infringement. Enforcement is real: the Software Freedom Conservancy has litigated GPL violations, and license claims routinely surface in acquisition due diligence.

The operational problem is scale. A mid-sized application resolves hundreds of packages, and checking which type of license each one carries by hand does not work. Software composition analysis tooling automates this: it inventories every component, extracts the declared license, and flags policy violations such as an AGPL package appearing in a proprietary service. Safeguard's SCA scanner does this alongside vulnerability detection, so license risk and CVE risk show up in the same report. If you are evaluating tooling in this space, our comparison with Snyk covers how license policy enforcement differs between platforms.

FAQ

What are software licenses?

Software licenses are legal agreements that grant permission to use, copy, modify, or distribute code under stated conditions. Open source licenses grant broad rights with conditions like attribution or share-alike; proprietary licenses grant narrow usage rights and reserve everything else.

What are the main types of licenses for software?

The main types of licenses are permissive open source (MIT, Apache-2.0, BSD), copyleft open source (GPL, LGPL, AGPL, MPL), proprietary or commercial licenses, and public domain equivalents (Unlicense, CC0).

What are the open source software license types specifically?

Open source software license types split into permissive (MIT, Apache-2.0, BSD, 0BSD) and copyleft (GPL, LGPL, AGPL, MPL), which differ mainly in whether derivative works must be released under the same license. Both categories are open source; the distinction is what obligation, if any, attaches to your changes.

Can I use open source code in a commercial product?

Usually yes, but the license type controls the terms. Permissive licenses only require attribution. Weak copyleft requires sharing changes to the licensed component. Strong copyleft can require open-sourcing your whole derivative work when you distribute it, and AGPL extends that to software offered over a network.

What happens if code has no license?

Default copyright applies, meaning you have no right to use, modify, or redistribute it. Treat unlicensed code in a dependency tree as a compliance blocker and either get the author to add a license or remove the component.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.