Licences decide what you can do with software and, more importantly for anyone building on it, what somebody else can do to you later.

The classic split

Permissive licences let you do essentially anything provided you keep the notices.

• MIT: use it however you like, keep the copyright notice
• BSD 2-Clause and 3-Clause: near-identical, 3-Clause adds a no-endorsement term
• Apache 2.0: permissive plus an explicit patent grant and a requirement to note changes

Copyleft licences require that derived works stay open.

• GPLv2: distribute a derived work, distribute its source under GPLv2. The Linux kernel’s licence
• GPLv3: adds anti-tivoisation and patent terms
• LGPL: linking a library does not infect your program, modifying the library does
• AGPL: GPL plus a network clause, covered below

The real difference is what each optimises for. MIT maximises adoption, because anyone can use it in anything including a closed product. GPL keeps derivatives open, at the cost of some companies refusing it outright.

Neither is morally superior and the choice is strategic. Apache 2.0’s patent grant is the reason it is common in corporate projects: contributors grant patent rights, and that grant terminates if you sue over patents, which is a mutual disarmament clause.

Why AGPL exists

The GPL triggers on distribution. Running software as a network service is not distribution.

So a company could take GPL code, modify it heavily, run it as a hosted product serving millions of users, and never publish a line. That is legal under the GPL and it is exactly what the authors did not intend.

AGPL closes it by triggering on network use: if users interact with your modified version over a network, they are entitled to its source.

This is why many companies ban AGPL internally. The concern is usually overstated, since using AGPL software unmodified triggers nothing, and it is real enough that AGPL reduces corporate adoption substantially. Projects choose it deliberately for that reason.

Source-available, and why it is the live argument

This is where the last few years of ecosystem drama have come from.

BSL (Business Source License): you can read and generally use it, but not offer it as a competing service, and each release converts to an open licence after a set period, commonly four years.

SSPL: if you offer it as a service, you must open source your entire service stack, which is practically impossible and therefore functions as a prohibition.

“Fair source” and similar terms: newer framings of the same idea.

None of these are open source, because the Open Source Definition prohibits restricting fields of use. That is a definitional point rather than a moral one.

The motivation is not unreasonable. A company invests years building something, a large cloud provider offers it as a managed service, and the provider captures most of the revenue while contributing comparatively little. Relicensing is an attempt to stop that.

The consequence is consistent and predictable: the community forks from the last open release.

Original	Relicensed to	Fork
Redis	RSAL and SSPL	Valkey
Terraform	BSL	OpenTofu
Elasticsearch	SSPL	OpenSearch
MongoDB	SSPL	no major fork

The forks that succeeded did so by attracting the contributors and the institutional backing, which is why Valkey landing under the Linux Foundation mattered more than the code did.

What this means when you choose infrastructure

For self-hosting, which our self-hosting introduction frames as being about control, the licence is part of the control question.

If terms change in a direction you dislike, your options are the version you already have and a migration. That is survivable and it is not free.

Before adopting something load-bearing:

• Is the licence OSI approved? A yes or no question with a published list
• Who holds the copyright? One company holding all of it can relicense
• Do contributors sign a CLA? Contributor licence agreements assigning copyright are how a project keeps the ability to relicense
• Who owns the trademark? A fork can take the code and cannot take the name, which shapes how a fork plays out

A single company holding copyright, requiring a CLA, and owning the trademark is precisely the configuration that produced every relicensing above. That is not a prediction, and it is the structure that makes one possible.

Dragonfly, the Redis-compatible in-memory store, is BSL today. It is fast and well engineered, and adopting it is a decision about terms as much as performance. Knowing that going in is the whole point.

Practical checks

# what a package claims
dpkg -s <package> | grep -i license
rpm -qi <package> | grep -i license

# the actual text
ls /usr/share/doc/<package>/copyright
find / -name 'LICENSE*' -path '*/<project>/*' 2>/dev/null

# scan a project tree
licensee detect .
scancode --license .

For containers, licence information usually lives in image labels or the SBOM, which our supply chain guide covers generating.

A few corrections to common beliefs

“GPL means I have to publish my code.” Only if you distribute a derived work. Internal use, however modified, triggers nothing.

“MIT means no obligations.” You must keep the copyright notice and licence text. People omit this constantly and it is the one thing MIT actually requires.

“Public domain is simplest.” It is not a coherent concept in many jurisdictions. Use CC0 or the Unlicense if that is the intent, and be aware neither includes a patent grant.

“Dual licensing is a trick.” It is a legitimate and old model: GPL for the community, a commercial licence for companies that will not accept copyleft. Qt has operated this way for decades.

“Someone can close the source of an open project.” They cannot close what already exists. Every release stays under the licence it shipped with, permanently, which is why forking from the last open version always works.

This is not legal advice, and none of the above substitutes for a lawyer when a real commercial decision depends on it.

Frequently Asked Questions

What is the practical difference between GPL and MIT?

MIT lets anyone use the code in anything, including closed proprietary products, as long as they keep the copyright notice. GPL requires that anyone distributing a derived work also distributes its source under the GPL. MIT maximises adoption, GPL keeps derivatives open.

Is the Business Source License open source?

No. BSL is source-available: you can read and generally use the code, but there are restrictions on offering it as a competing service, and each release converts to an open licence only after a set period. It fails the Open Source Definition because of the use restriction.

Why does the AGPL exist when the GPL already requires source?

Because the GPL triggers on distribution, and running software as a network service is not distribution. A company could modify GPL code, run it as a hosted product, and never share anything. AGPL closes that by triggering on network use as well.

Can a project change its licence whenever it wants?

Only if it holds or has been assigned the copyright for all the code, which is why projects planning this collect contributor licence agreements. Existing releases stay under their original licence forever, which is what makes forking from the last open version possible.

Does using GPL software in my company force me to publish my code?

Only if you distribute a derived work. Running GPL software internally, however modified, is not distribution and triggers nothing. The obligation attaches to giving the software to someone else, not to using it.

What should I look for before adopting a project for infrastructure?

Whether the licence is OSI approved, who holds the copyright, whether contributors sign a CLA, and who controls the trademark. A single company owning all of those can relicense later, which is exactly the situation that produced the recent forks.