On 10 August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad and its other flagship products from the Mozilla Public License to the Business Source License. Within weeks a group of users and vendors had forked Terraform. That fork, OpenTofu, landed at the Linux Foundation and shipped version 1.6.0 as its first stable release on 10 January 2024.
That sequence — license change, community fork, foundation adoption, competing project — has now played out at MongoDB, Elastic, HashiCorp and Redis. Two of those companies later reversed course. The whole cycle turns on the text of a license file that most developers copy into a repository without reading.
This is a guide to what those files actually say: which obligations attach to what, which combinations are legal, and which of the recent “source available” licenses are open source and which are not.
This article is general information, not legal advice. License obligations depend on your jurisdiction, your specific facts, and how you distribute software. For anything with real money or real risk attached, talk to a qualified lawyer.
What makes a license “open source”
The term has a definition, maintained by the Open Source Initiative. The Open Source Definition lists ten criteria, and a license has to satisfy all of them to be OSI-approved. The ones that do the most work in practice:
- Free redistribution. The license cannot stop anyone selling or giving away the software, and cannot demand a royalty.
- Source code. It must be available in the form a programmer would actually edit.
- Derived works. Modifications must be allowed and redistributable under the same terms.
- No discrimination against persons or groups.
- No discrimination against fields of endeavor. This is criterion six, and it is the one every recent source-available license fails. You cannot say “free for everyone except cloud providers” and still call it open source.
- No restrictions on other software distributed alongside it.
Nothing here says “free of charge” in the price sense, and nothing prohibits commercial use. Those two misconceptions cause more confusion than anything else in the field.
Permissive versus copyleft
Almost every open source license sits somewhere on one axis: what you must do when you give the software to someone else.
Permissive licenses — MIT, BSD, Apache 2.0 — ask for attribution and disclaim warranties. You can take the code, modify it, link it into a closed-source product and ship binaries with no obligation to release anything. Keep the copyright notice and the license text and you are done.
Copyleft licenses — the GPL family, MPL, LGPL — use copyright to force reciprocity. If you distribute software built from copyleft code, recipients get the same rights you got, which means they get the source. The licenses differ in how far that obligation reaches.
- File-level (MPL 2.0): only the files containing MPL code carry the obligation. The Mozilla FAQ is explicit that new files containing no MPL code are not Modifications, so you can combine MPL files with proprietary files in one product.
- Library-level (LGPL): modifications to the library must be released, but a program that merely links to it need not be.
- Program-level (GPL): the whole combined work must be GPL when distributed. This is the “viral” property people mean, though the word overstates it — nothing happens until you distribute.
- Network-level (AGPL): the GPL plus a clause for servers, covered below.
The licenses side by side
| License | Type | Copyleft scope | Express patent grant | Attribution required | OSI approved |
|---|---|---|---|---|---|
| MIT | Permissive | None | No | Yes, notice only | Yes |
| BSD 3-Clause | Permissive | None | No | Yes, plus no-endorsement clause | Yes |
| Apache 2.0 | Permissive | None | Yes, with retaliation clause | Yes, plus NOTICE file and change notices | Yes |
| MPL 2.0 | Weak copyleft | Per file | Yes | Yes | Yes |
| LGPL 3.0 | Weak copyleft | The library | Yes | Yes | Yes |
| GPL 3.0 | Strong copyleft | Whole distributed work | Yes | Yes | Yes |
| AGPL 3.0 | Strong copyleft | Whole work, plus network use | Yes | Yes | Yes |
| BSL 1.1 | Source available | N/A | No | Yes | No |
| SSPL v1 | Source available | Service source code | N/A | Yes | No |
“Distribution” and “derivative work”: the two words that decide everything
Copyleft obligations are triggered by distribution, not by use. If you download GPL software, modify it heavily and run it on your own servers for your own purposes, you owe nobody anything. Internal use is not distribution. Neither, in most readings, is handing a modified copy between two entities under common control.
Distribution happens when a copy leaves your organization: a downloadable binary, an appliance, firmware in a shipped device, a container image on a public registry, a mobile app in a store.
The AGPL exists because SaaS sidestepped all of that. Running modified GPL code on a public server was never distribution, so the source never had to be shared. The FSF’s explanation of the Affero GPL describes the fix plainly: if you run a modified program on a server and let users interact with it there, the server must let those users download the corresponding source. Note the word modified — running an unmodified AGPL program as a service does not by itself create an obligation to publish your own code.
“Derivative work” is the harder term, because it is a copyright concept and courts, not licenses, decide where its edges are. Statically linking a GPL library into your binary is treated as creating a derivative work by essentially everyone. Calling a GPL program over a network socket is generally treated as not. Dynamic linking sits in between and has been argued about for twenty-five years without a definitive ruling. If your product’s viability depends on which side of that line you fall, that is exactly the situation for a lawyer.
Patents, and why Apache 2.0 exists
Copyright and patents are separate rights. A license that grants copyright permission does not automatically grant patent permission, which means a contributor could in principle release code under MIT and then sue users over a patent covering it.
Apache 2.0 closes that. Section 3 grants every recipient a perpetual, worldwide, royalty-free, irrevocable patent license covering claims necessarily infringed by the contribution. It also adds retaliation: sue anyone alleging the work infringes your patents, and your patent license to that work terminates on the day you file.
GPLv3 added comparable protection. The FSF’s guide to GPLv3 notes that distributors must grant patent licenses to recipients, and that using a patent suit to stop someone exercising their rights terminates the attacker’s own license.
MIT and BSD say nothing about patents. Some lawyers argue an implied license arises; others do not. This is the main reason large companies and foundations tend to prefer Apache 2.0 over MIT for anything substantial, despite MIT being shorter and more popular.
Compatibility: it usually runs one way
Two licenses are compatible if code under both can be combined and distributed lawfully. The relationship is directional, and this trips people up constantly.
The Apache Software Foundation’s own compatibility page spells out its case: Apache 2.0 code can be included in GPLv3 projects, but GPLv3 code cannot be included in Apache projects, because that would force the combined work to be GPLv3. It also notes that the FSF has never regarded Apache 2.0 as compatible with GPL version 2, citing the patent termination and indemnification provisions. That specific incompatibility matters in practice, because the Linux kernel is GPLv2.
Useful rules of thumb:
- Permissive code flows into copyleft projects freely. Copyleft code does not flow back out.
- Combining GPL and AGPL code with proprietary code and distributing the result is the classic violation. Most real compliance failures are this, not exotic edge cases.
- MPL 2.0 includes a mechanism in section 3.3 for combining with GPL and LGPL works, provided the code is not marked “Incompatible With Secondary Licenses.”
- Two strong copyleft licenses with different terms are usually incompatible with each other, even though both are open source.
The source-available turn, and the partial reversal
Between 2018 and 2024, several infrastructure companies concluded that permissive and even AGPL licensing let cloud providers monetize their work without contributing. Their responses were not open source, and mostly did not pretend to be.
MongoDB moved from AGPL to the Server Side Public License on 16 October 2018. SSPL section 13 says that if you offer the software as a public service, you must release the source of the entire service stack — management, APIs, monitoring, backup, hosting — under the SSPL. MongoDB withdrew it from OSI review. The OSI stated in January 2021 that the SSPL is not an open source license, because restricting cloud providers violates the field-of-endeavor criterion.
Elastic followed on 14 January 2021, moving Elasticsearch and Kibana from Apache 2.0 to a dual SSPL and Elastic License arrangement before the 7.11 release. AWS forked the last Apache-licensed version into OpenSearch.
HashiCorp adopted BSL 1.1 in August 2023. The BSL text is unusual in being honest about itself: it states outright that it is not an open source license, but that the code converts to a specified open source license on a Change Date, or on the fourth anniversary of a version’s first public release, whichever comes first. So BSL code becomes open source eventually. Everything before that is a delay, not a permanent restriction.
Redis left the 3-clause BSD license on 20 March 2024, dual-licensing version 7.4 onward under RSALv2 and SSPLv1. Valkey, a Linux Foundation fork, appeared shortly after.
Then two of them reversed. Elastic announced in August 2024 that it would add AGPL as an option alongside ELv2 and SSPL. And Redis added AGPLv3 with Redis 8, released in May 2025; original author Salvatore Sanfilippo wrote that the SSPL had failed to be accepted by the OSI or the wider community.
The lesson is not that license changes always fail. It is that for infrastructure software with viable forks, the community’s ability to route around a change is real, and companies have found the resulting fragmentation expensive.
Dual licensing
If you own all the copyright in a project, you can offer it under two licenses at once and let each user pick. The common commercial pattern is AGPL plus a paid proprietary license: hobbyists and open source projects take the AGPL, companies that cannot accept the network copyleft buy their way out. Qt and MySQL are long-running examples.
The catch is ownership. To relicense you need rights to every line, which means either writing it all yourself or making every contributor sign a contributor license agreement assigning or licensing their work to you. CLAs are why some projects can change license overnight and others cannot change at all.
SBOMs and the compliance side
Knowing which licenses apply to your dependencies used to be optional diligence. It is becoming a documentation requirement.
US Executive Order 14028 directed NTIA to define minimum SBOM elements, and its July 2021 report set seven data fields per component: supplier name, component name, version, other unique identifiers, dependency relationship, SBOM author, and timestamp. It named SPDX, CycloneDX and SWID tags as the interoperable formats. CISA’s SBOM program continues that work and adds VEX, a companion format for stating whether a listed vulnerability actually affects a product.
In the EU, the Cyber Resilience Act entered into force on 10 December 2024. Reporting obligations start on 11 September 2026 and the main obligations apply from 11 December 2027. It applies to products with digital elements sold in the EU and takes a specific, lighter approach to free and open source software and to open source stewards.
Practically: run a license scanner in CI, generate an SBOM at build time, and record the license of every transitive dependency. Doing this before a customer or acquirer asks is far cheaper than doing it afterwards.
What this means for you
If you are releasing code
- Widest adoption, least friction: MIT or Apache 2.0. Choose Apache 2.0 if patents are a plausible concern or if companies will rely on it.
- You want contributions back: MPL 2.0 for a library, GPL for an application, AGPL if the obvious competitor is a hosted service.
- You plan to sell licenses later: require a CLA from day one. Retrofitting one across hundreds of contributors is close to impossible.
If you are consuming code
- Track licenses automatically. A manual spreadsheet is out of date the day it is written.
- Decide your policy on AGPL before an engineer adds an AGPL dependency, not after.
- Preserve NOTICE files. Apache 2.0 requires it and it is the single most commonly missed obligation.
- Check whether a “free” tool is BSL or SSPL rather than open source, and if it is BSL, check the Change Date.
- Assume a license can change. Prefer projects under neutral foundation governance for anything load-bearing.
Frequently asked questions
Can I use GPL software in a commercial product?
Yes. The GPL has never prohibited commercial use or charging money. What it requires is that anyone you distribute the binary to can get the corresponding source under the same terms. That is incompatible with a closed-source product, not with commerce.
Does using an AGPL library force me to open source my SaaS?
It can, and this is the highest-risk common scenario. The obligation attaches to modified versions made available to users over a network, and how far it reaches into surrounding code is a derivative-work question. Many companies simply ban AGPL dependencies rather than analyze each case.
Is MIT or Apache 2.0 better?
Apache 2.0 gives you an express patent grant and clearer terms about modifications and attribution. MIT is shorter and more widely recognized. For a small utility either is fine; for anything a business will build on, Apache 2.0 removes an uncertainty MIT leaves open.
What happens if I violate a license?
GPLv2 terminates automatically on breach; GPLv3 provides for reinstatement if you cure the violation promptly after notice. In practice most enforcement starts with a compliance request, and the usual remedy is publishing the source you should have published. Reputational cost and deal-blocking during due diligence are often the bigger consequences.
Is “source available” the same as open source?
No. You can read the code and often modify it, but there are restrictions on how you may use it. The OSI’s position on the SSPL is the clearest statement of where the line sits. BSL is a distinct case because its restrictions expire.
Picking a license without regretting it
Licensing looks like paperwork and behaves like architecture. It determines who can build on your work, whether you can accept a particular dependency, and whether you can change your mind in three years. The projects that got into trouble in the last decade were not confused about copyright law. They picked a license that fit their business at launch and outgrew it.
Two questions get you most of the way. What do you want to happen when someone builds a business on this — and if you needed to change the answer later, could you? If the honest reply to the second is no, decide the first one carefully now.
Sources
- Open Source Initiative — The Open Source Definition
- Open Source Initiative — The SSPL is Not an Open Source License
- Apache Software Foundation — Apache License, Version 2.0
- Apache Software Foundation — Apache License v2.0 and GPL Compatibility
- Free Software Foundation — A Quick Guide to GPLv3
- Free Software Foundation — Why the Affero GPL
- Mozilla — MPL 2.0 FAQ
- MariaDB — Business Source License 1.1
- HashiCorp — HashiCorp adopts Business Source License
- OpenTofu — OpenTofu is going GA
- MongoDB — Server Side Public License FAQ
- Elastic — Doubling down on open, Part II
- Elastic — Elasticsearch is Open Source, Again
- Redis — Redis Adopts Dual Source-Available Licensing
- Salvatore Sanfilippo — Redis is open source again
- NTIA — The Minimum Elements For a Software Bill of Materials (SBOM)
- CISA — Software Bill of Materials (SBOM)
- European Commission — Cyber Resilience Act
Image credit: Photo: USAID Indonesia — Public domain (via Wikimedia Commons)
