Open-Source Licenses Explained for Founders: MIT, Apache, GPL, AGPL, SSPL

You do not need to be a lawyer to make good licensing decisions. You do need to know what a handful of licenses mean in practice, because "open source" covers everything from "do whatever you want" to "run this as a service and you must open your entire platform."

This is a founder's-eye view. It is not legal advice, and for anything high-stakes you should still ask a lawyer. But it will let you read a project's LICENSE file and know roughly where you stand.

The one distinction that matters most

Almost every question comes down to: is this license permissive or copyleft?

Permissive licenses let you use, modify, and redistribute the code with almost no strings. You can put it in a closed-source product and sell it. MIT, Apache 2.0, BSD.
Copyleft licenses say: you can use and modify this, but if you distribute it, you must pass on the same freedoms, which usually means releasing your changes under the same license. GPL, LGPL, AGPL.

Then there is a third bucket that is not open source at all but is often mistaken for it: source-available licenses like the SSPL and the BSL. The code is public, but commercial use is restricted.

The permissive licenses

MIT. The shortest and most common. Do anything, just keep the copyright notice. No patent grant. For most startups building on top of libraries, this is the ideal case: zero friction.

Apache 2.0. Like MIT, plus an explicit patent grant (contributors promise not to sue you over patents in the code) and a requirement to note significant changes. Slightly more paperwork, meaningfully more protection. Common for larger projects and anything corporate-backed.

BSD (2- or 3-clause). Effectively MIT with minor wording differences. The 3-clause version adds "don't use our name to endorse your product."

What this means for you: you can build a commercial, closed-source SaaS on permissive-licensed code without obligations beyond attribution. Keep a NOTICES file listing what you used.

The copyleft licenses

GPL (v2, v3). If you distribute software that includes GPL code, the whole combined work must be GPL, and you must offer the source. The key word is distribute. Running GPL software on your own servers to power a SaaS is not distribution, so the source requirement is not triggered. This is the "SaaS loophole," and it is why the AGPL exists.

LGPL. A softer copyleft meant for libraries. You can link to an LGPL library from a closed-source program as long as users can swap in their own version of the library. Using it as a normal dependency is usually fine; statically compiling it into your binary needs more care.

AGPL. GPL plus one big addition: if users interact with the software over a network, you must offer them the source, including your modifications. This closes the SaaS loophole. If you run an unmodified AGPL tool internally, you are fine. If you modify it and expose it to users over a network, you owe them your changes.

What this means for you:

Using AGPL software as an internal tool: fine.
Running an unmodified AGPL product as a service: fine, though best practice is to link to the upstream source.
Modifying AGPL code and building a product on it: you must publish your modifications. For some companies that is a dealbreaker; for others it is a non-issue.
Copying GPL or AGPL source into your own closed codebase: do not, unless you intend to open that codebase.

The source-available licenses

These exist because companies got tired of cloud providers reselling their software.

SSPL. Looks like AGPL but goes much further: if you offer the software as a service, you must open source everything you use to provide that service, including your management and orchestration tooling. In practice this makes it impossible to offer as a commercial service unless you are the copyright holder. It is not an OSI-approved open-source license.

BSL (Business Source License). The code is source-available with a restriction (typically "you may not offer this as a commercial hosted service") that expires after a set period, often four years, at which point that version becomes truly open source, usually Apache 2.0.

Fair Source, Elastic License, and friends. Various "free to use, not free to compete with us" terms. Read them individually.

What this means for you:

Internal use is almost always allowed. Read the specific terms, but self-hosting one of these for your own team is generally fine.
Building a product that competes with the vendor's hosted offering is the thing these licenses exist to stop.
Do not assume "the repo is public" means "I can do what I want."

Quick reference

License	Type	Closed-source SaaS on top?	Must publish your changes?
MIT / BSD	Permissive	Yes	No
Apache 2.0	Permissive	Yes	No (note changes)
LGPL	Weak copyleft	Yes, as a linked library	Only to the library
GPL	Copyleft	Yes, if you only run it on servers	Only if you distribute binaries
AGPL	Network copyleft	Yes, if unmodified; changes must be shared	Yes, if modified and network-exposed
BSL	Source-available	Not until the term expires	Per the specific terms
SSPL	Source-available	Effectively no	Yes, and your whole service stack

A simple decision process

Open the LICENSE file. Do not trust the marketing page's use of "open source."
If it is MIT, BSD, or Apache 2.0: build freely, keep an attribution file, move on.
If it is GPL or AGPL: are you modifying it, and will users touch it over a network? If no to either, you are almost certainly fine for self-hosting. If yes to both, plan to publish those modifications.
If it is SSPL, BSL, or something custom: internal use is likely fine; anything resembling reselling it is likely not. If your product is close to the vendor's, get a lawyer to read it.
When a project relicensed recently (several have moved from Apache or AGPL to BSL or SSPL), check which version you are on. Older releases keep their old license.

Most of the time the answer is "it's MIT, go ahead." Knowing the other cases just means you will not get surprised.